locked
Windows 7 Clients on 2003 DC Group Policy Problem RRS feed

  • Question

  • We have Windows 7 Enterprise clients managed by a Server 2003 R2 Ent domain controller. I know I need to get Server 2008 to fully realize group policy compatibility but here's the problem in the meantime.

    I didn't build the Windows 7 image, but as it is, a domain user can run gpedit.msc and then make alterations in certain parts of local machine policy (those not controlled by the policy objects of Server 2003).

    If I restrict authoring under User Configuration > Administrative Templates > Windows Components > Microsoft Management Console, it applies the exact same restrictions to administrators. In fact you can lock the admins completely out of all MMC and related components.

    The funny part is, when a user does access gpedit.msc, they don't even get a UAC prompt, whereas if an administrator does (local or domain), they do get the UAC prompt.

    Until I get Server 2008, is there anyway to rectify this? Users should have no access to any group policy editing features, yet with the image I'm working with, they can and do, and have the necessary rights to actually turn on and off settings under both Machine and User Administrative Template settings.

    Totally stumped here...any assistance greatly appreciated.

    Thursday, April 26, 2012 9:32 PM

Answers

  •  
    > We have Windows 7 Enterprise clients managed by a Server 2003 R2 Ent
    > domain controller. I know I need to get Server 2008 to fully realize
    > group policy compatibility but here's the problem in the meantime.
    >
     
    No, you don't. The client does not really care about the DC, the only
    thing you need is a schema update to be able to use wireless policies
    and bitlocker AD integration. Everything else (regarding GPOs) is just
    file system (sysvol) based.
     > If I restrict authoring under User Configuration > Administrative
    > Templates > Windows Components > Microsoft Management Console, it
    > applies the exact same restrictions to administrators. In fact you can
    > lock the admins completely out of all MMC and related components.
     
    Then apply the appropriate security filter to your policy - exclude the
    administrators group.
     
    > The funny part is, when a user does access gpedit.msc, they don't even
    > get a UAC prompt, whereas if an administrator does (local or domain),
    > they do get the UAC prompt.
    >
     
    This is a result of mmc.exe's Manifest - it has "highestAvailable", and
    that means "normal user - no prompt", "admin user - prompt". Same is
    true for the event viewer.
    BTW: Are you SURE they are not - by accident possibly - local
    administrators? If they can make changes through gpedit.msc, I would
    believe that in fact they ARE admins...
     
    regards, Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    • Marked as answer by Highspeedlane Monday, April 30, 2012 9:04 PM
    Friday, April 27, 2012 10:28 AM

All replies

  • We have Windows 7 Enterprise clients managed by a Server 2003 R2 Ent domain controller. I know I need to get Server 2008 to fully realize group policy compatibility but here's the problem in the meantime.

    I didn't build the Windows 7 image, but as it is, a domain user can run gpedit.msc and then make alterations in certain parts of local machine policy (those not controlled by the policy objects of Server 2003).

    If I restrict authoring under User Configuration > Administrative Templates > Windows Components > Microsoft Management Console, it applies the exact same restrictions to administrators. In fact you can lock the admins completely out of all MMC and related components.

    The funny part is, when a user does access gpedit.msc, they don't even get a UAC prompt, whereas if an administrator does (local or domain), they do get the UAC prompt.

    Until I get Server 2008, is there anyway to rectify this? Users should have no access to any group policy editing features, yet with the image I'm working with, they can and do, and have the necessary rights to actually turn on and off settings under both Machine and User Administrative Template settings.

    Totally stumped here...any assistance greatly appreciated.

    Thursday, April 26, 2012 9:14 PM
  • Hello,

    please ask in the GPO forum http://social.technet.microsoft.com/Forums/en/winserverGP/threads and see here about using the Central store: http://support.microsoft.com/kb/929841 belongs also the newer OS versions.


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.


    • Edited by Meinolf Weber Thursday, April 26, 2012 9:20 PM
    • Proposed as answer by MYousufAli Thursday, April 26, 2012 9:21 PM
    Thursday, April 26, 2012 9:19 PM
  • Will do, thanks.
    Thursday, April 26, 2012 9:33 PM
  • I'm currently working in a 2003/Xp environment, so I don't have all the tools in front of me, so excuse me if I'm a bit vague.

    What you need is RSAT http://www.microsoft.com/en-us/download/details.aspx?id=7887 

    The Remote Server Administration Tools need to be installed on a Win7 client, once these tools are installed (and "Run As") from a domain admin account. You will have the tools you need to fully manage your windows 7 clients. RSAT basically replaces Windows Server 2003 Administrative Tools Pack.

    By upgrading to Server a 2008 (use 2008R2 if possible, as that's the win7 equivalent) native domain you will gain additional functionality, but RSAT is all you need at this stage.

    Once that’s installed, you should be able to do what you need.  

    Friday, April 27, 2012 1:48 AM
  • Mike,

    Thanks for the information. I understand what you're saying with respect to RSAT as the Windows 7 replacement for Admin Pack, but how would I use that to block a particular user OU from accessing gpedit.msc and other MMC tools on other Windows 7 workstations?

    Thanks for your help.

    Friday, April 27, 2012 6:34 AM
  • Hi,


    The funny part is, when a user does access gpedit.msc, they don't even get a UAC prompt


    >> Please following the steps to make sure the user is not a member of Admin (both domain and local).


    1. For Local: start -> right click computer -> manage -> Local Users and Groups -> Groups -> Administrators
    2. For Domain: Start -> Administrative Tools -> Active Directory Users and Computers -> Users -> Domain Admins -> Members


     
    Hope this helps!


    Best Regards
    Elytis Cheng


    Elytis Cheng

    TechNet Community Support

    Friday, April 27, 2012 7:43 AM
  • Elytis,

    I just checked a machine on the network by Start > Computer > Manage > Local Users and Groups > Groups > Administrators > and Users are not members of the administrators group.

    Our domain members are simply domain\users, they are not members of the administrators group either.

    The odd thing is, users are denied many administrative rights such as they cannot uninstall or install software, yet they can change local group policy settings in the administrative templates by accessing Start > gpedit.msc

    I have Windows 7 Ultimate on my personal home computer and it does not behave the same way. A local user is denied access to gpedit.msc

    Where else could permissions be set that allow the users group to execute gpedit.msc that I'm overlooking?

    The version in question is Windows 7 Enterprise that is being built for us by another office. I have not gotten a response from them yet on this question.

    Thanks for your help


    Friday, April 27, 2012 9:53 AM
  •  
    > We have Windows 7 Enterprise clients managed by a Server 2003 R2 Ent
    > domain controller. I know I need to get Server 2008 to fully realize
    > group policy compatibility but here's the problem in the meantime.
    >
     
    No, you don't. The client does not really care about the DC, the only
    thing you need is a schema update to be able to use wireless policies
    and bitlocker AD integration. Everything else (regarding GPOs) is just
    file system (sysvol) based.
     > If I restrict authoring under User Configuration > Administrative
    > Templates > Windows Components > Microsoft Management Console, it
    > applies the exact same restrictions to administrators. In fact you can
    > lock the admins completely out of all MMC and related components.
     
    Then apply the appropriate security filter to your policy - exclude the
    administrators group.
     
    > The funny part is, when a user does access gpedit.msc, they don't even
    > get a UAC prompt, whereas if an administrator does (local or domain),
    > they do get the UAC prompt.
    >
     
    This is a result of mmc.exe's Manifest - it has "highestAvailable", and
    that means "normal user - no prompt", "admin user - prompt". Same is
    true for the event viewer.
    BTW: Are you SURE they are not - by accident possibly - local
    administrators? If they can make changes through gpedit.msc, I would
    believe that in fact they ARE admins...
     
    regards, Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    • Marked as answer by Highspeedlane Monday, April 30, 2012 9:04 PM
    Friday, April 27, 2012 10:28 AM
  • Hello Martin,

    I have checked the Users group and Administrators group and users do not belong to the admin group. This is before even joining the computer to the domain, so I know it has nothing to do with policy pushed from domain level.

    Users are restricted from many of admin functions such as add/remove programs (they are prompted for admin credentials at that point), yet when logged in as the same local user, I can type Start > type gpedit.msc, hit Enter, then make changes to the local group policy in either Computer or User hive administrative templates and the setting takes effect.

    With regards to filtering, where I see filter options under Administrative Templates, but where can I exclude the administrators group? Under filter options I have 3 drop boxes: Managed, Configured and Commented. Is that the location I want to be in?

    Sorry for being a pain but I appreciate the help.


    Friday, April 27, 2012 10:43 AM
  •  
    > With regards to filtering, where I see filter options under
    > Administrative Templates, but where can I exclude the administrators
    > group? Under filter options I have 3 drop boxes: Managed, Configured
    > and Commented. Is that the location I want to be in?
     
    Oh, I didn't mean "filtering administrative templates", but "security
    filtering". Are the computers member of a domain? Then, in group policy
    management console, you have "security filtering" at hand. For local
    filteriing, start mmc.exe (NOT gpedit.msc), then add the group policy
    editor snap in.This will give you a selection for what type of account
    you want to create a local policy.
     
    regards, Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Friday, April 27, 2012 11:02 AM
  • Yes ultimately they will be joined to a Server 2003R2 Enterprise DC, but the existing policy settings of 2003 (as we have currently configured on it) don't translate to all of the settings of the new Win 7 clients.

    Okay Martin, I believe that is a good clue for me to start with, that I hadn't been aware of (creating a local GPO for non-administrators). If that can be implemented and applied as such, it will be the fix.

    Unfortunately I will not be back in front of my network until Monday, in which case I will implement and test. I'm a huge noob with Windows 7 in a networked environment.

    This copy of of Windows 7 Enterprise is not "out of the box" but is an image built by an agency we work with to deploy our workstations where I work. Thus, they may have made some changes to the standard Win 7 Enterprise config that somehow has permitted the issue that started this post. I have made them aware of it but pending a response I need to rectify this issue at the next opportunity because as it exists it is a huge security loophole.

    I will fully test Monday and report back here. Thanks again for all your help.

    Friday, April 27, 2012 11:15 AM
  • Martin,

    Thanks for the helpful info. The immediate resolution to restrict users in the Local Computer Policy / Users hive of group policy is to use Group Policy Object Editor (MMC > Add/Remove Snap-in > Group Policy Object Editor) and make a policy which applies to non-Administrators. This worked for restricting access to gpedit.msc by non-administrative users.

    >

    Following this, the folder %Sysvol%\Windows\System32\GroupPolicyUsers can be exported to any other computer to apply this same policy, so no need to re-create dozens or more individual settings on each machine.

    >

    As mentioned previously, this is not an out of the box copy of Windows 7 Enterprise. It is a proprietary build that is issued to us. It is also the first edition of its type and they have made other errors I have to post about elsewhere in the Technet forums as it isn't applicable to group policy.
    >

    However with respect to this issue the question is resolved and I appreciate your help.

    Monday, April 30, 2012 9:04 PM