none
Windows 7 computer Joined to Domain - Proper way of removing Domain Users from the local machine Users group?

    Question

  • Recently, I converted to using Windows 7 Ultimate and immediately after installing and joining my company domain I tried to set my security a little tighter since I'm one of the IT staff for my company.  In Windows XP Pro I would remove the typical "Domain Users" was not part of the Local Machine users, and removed the "Domain Admins" from the local machine "Administrators" group for security reasons.  In Windows 7 I added my Domain account with explicit permissions to the local machine "Users" gorup.  Then I tried simply removing "Domain Users" from the local machine "Users" group and was till able to login with any of my other domain accounts.  In order to get it to deny the "Domain Users" from logging in I had to remove all the NT built-in members and then ensure only the explicit local and domain accounts that I wanted to use the computer are members of the local machine "Users" group.

    Is there a better way to do this in Windows 7?  It seems really odd that removing "Domain Users" isn't enough to stop them from logging in.
    Thursday, December 17, 2009 2:14 PM

Answers

  • NO! don't delete those user listings.

    A much better way to accomplish what you want is to use Group Policy.

    I would recommend you to create multiple Active Directory Group Policies, filter them using the computer object/OU/security group with computer objects etc. it should apply to, so that the GPO is applied only to the computers you want it to apply to. In the GPO you then use "User Rights
    Assignment" and the "Allow logon locally" option.

    User rights assignment you find under Computer Configuration - Windows
    Settings - Security Settings - Local Policies.

    This way you don't have to mess around with the local groups and you don't need to use a VB script, and you can at any time reverse or change the
    settings centrally by using Active Directory Group Policies

    When changing the log on locally user right I would also add Domain Admins.


    MCSE, MCSA, MCDST
    Thursday, December 17, 2009 8:27 PM

All replies

  • Okay, so I was wrong on what I wrote.. In Windows XP you did have to remove the special built-in groups:
    NT AUTHORITY\Authenticated Users (S-1-5-11)
    NT AUTHORITY\INTERACTIVE (S-1-5-4)

    In Windows 7 the built-in groups are the same as Windows XP.

    Does anybody know if this will cause problems later with services or apps without these built-in groups as member of Users?
    Thursday, December 17, 2009 2:33 PM
  • NO! don't delete those user listings.

    A much better way to accomplish what you want is to use Group Policy.

    I would recommend you to create multiple Active Directory Group Policies, filter them using the computer object/OU/security group with computer objects etc. it should apply to, so that the GPO is applied only to the computers you want it to apply to. In the GPO you then use "User Rights
    Assignment" and the "Allow logon locally" option.

    User rights assignment you find under Computer Configuration - Windows
    Settings - Security Settings - Local Policies.

    This way you don't have to mess around with the local groups and you don't need to use a VB script, and you can at any time reverse or change the
    settings centrally by using Active Directory Group Policies

    When changing the log on locally user right I would also add Domain Admins.


    MCSE, MCSA, MCDST
    Thursday, December 17, 2009 8:27 PM
  • cdobbs,

    I absolutely like handling things through the AD Group Policy objects a lot better.  It just seems like you may end up with an excessive number of OU entries to handle this.  I'll give it a try and see how I like it.  I just really wish removing the "Domain Users" would handle it.  Then if you could modify that setting via the AD computer object, that would be excellent.  Wishful thinking though!

    Of course, there's always the archaic AD User Account "Logon On To" field, but that isn't very userful in the larger scheme of things.

    So far my accounts working fine with the removed NT AUTHORITY accounts.  I'll find out when I break it.  =-)

    Thanks,
    Amaranthe
    Friday, December 18, 2009 8:30 PM
  • If a Windows 7 computer is in domain, although a domain user account is not in any local user group, it can still log on. If you would not like a user to log on with a computer, you can configure the user properties in AD to only allow the user to log on specified computers.
    Arthur Xie - MSFT
    Monday, December 21, 2009 5:22 AM
    Moderator
  • Arthur Xie,

    You're certainly right.  However, if you pay with removing the "NT Authority" accounts from the Local computer "Users" group it will definitely disable other Domain users from logging in.  If I can get away from my coding this week, I'm going to give cdobbs idea a workout.

    Thanks,
    Amaranthe
    Monday, December 21, 2009 3:45 PM
  • 1 - user - 1 computer

    With the exception of administrators, we would like to only have a single individual in our huge domain log into their specified computer ( while still allowing them to log into public computers located else where ).  All the above methods seem to suggest that by utilizing GPOs & the  User Right Assignment you can achieve some level of restriction but apparently only effectively manageable down to the Groups/OUs.  How can we use GPOs to effectively restrict the Log on Locally right down to the user as well?  Creating an OU/GPO per computer won't work.

    Has it been agreed that the best method is to remove the NT Authority/Authenticated Users group out of the local Users group on each system by a computer startup vpscript?

    My only concern with removing Authenticated Users is the issue that I've seen when trying to  'Remote Help' users with the RDP Remote Assistance feature in windows.  It basically broke that feature - so I'm guessing there might be more....  Microsoft missed that one in their 'Risks' section here; http://support.microsoft.com/default.aspx/kb/823659/?p=1

     

    Amaranthe - have you made any progress on this one?  -( we did not have this issue with our XP clients joined to the domain. )

     

    thanks!

    Monday, April 19, 2010 4:32 AM
  • Markiejee,

    Sorry, I haven't really messed with it since December.  I have been working fine for my laptop setup with my manual changes.  In your setup I'd say handling it through the "Logon To" in AD Users may work depending on what you are calling "public computers."  If there are a bunch of public computers then obviously that will not help.

    Was the 'Remote Help' feature you are referring to causing the remote controller to not be able to access?  Or is it that the end-user can not start up the 'Remote Help' feature?

    I'm probably a bad candidate for speaking about Remote Assistance or Remote Help.  My typical setup is to use UltraVNC with the MS AD Groups + encryption and can define different user groups View, View + Interact, etc.  I haven't used Remote Assistance since XP first came out.

    Amaranthe

     


    "Those who fear the darkness have never seen what the light can do." Magic: The Gathering
    Monday, April 19, 2010 4:41 PM
  • Amaranthe, thanks for the quick follow-up.  Yeah, the Log On To attribute for user accounts in AD only works for users under my purview and doesn't really address the management of many public terminals.  If this was a computer attribute, then it would make a lot more sense in my opinion. ( I hope MS is listening )

    The issue with Remote Assistance was with the controller trying to shadow the user session - once the NT Authority groups were removed from local Users groups - it broke.  It seems as though Windows 7/2008 almost uses this NT Authority/Auth account to do some magic with UAC, but I can't really prove it.  Who knows what else will break - I guess that's why user CDOBBs was so adamant  that you did not remove those two NT AUTHORITY groups from local Users...

    In my opinion your question hasn't been solved by any of the previous recommendations because using GPOs doesn't really allow for a good way to only allow a single user access to a specific box easily ( which is why it is probably called group policy objects :) ) and removing the default groups appear to break some things....

    thanks again!

    Monday, April 19, 2010 5:48 PM