locked
How to use Restricted Groups to assign user to the local admin group on a specific computer RRS feed

  • Question

  • It's important to assign specific users to specific computer admin rights.  I'm aware some of this can be done using restricted groups, but how can this group be used to only add a specific user to specific computer and not all computers?
    Wednesday, April 3, 2013 6:07 PM

Answers

  • Am 05.04.2013 04:05, schrieb W. Bob:
    > Item level targeting is more administrative overhead to define each
    > user. I would explore the path of a wmi query logon script that checks
    > for a custom attribute, that way you only have to define a custom
    > attribute on each user and the script works the same regardless. Plus
    > it would be easier to manage if the machine name ever changed for
    > whatever reason. Either way, the granularity that is being asked for
    > will require some time to fully implement.
     
    It's not a lot of work... Anyway, you need to define which user is admin
    on what workstation. This can be done several ways... The easiest way
    I'm aware of:
     
    Let's say we have a computer named WS01. And we have a user John that
    needs to be Admin on WS01.
     
    Create a DL Security Group "WS01_Admins". Add John to this group. (This
    has to be done for each computer, but you can partially automate it with
    Excel and the "net group" command...)
     
    Then create one (repeat: ONE single!) Group Policy Preferences "Local
    Users and Groups" Item in the user part of a GPO with the following
    settings. Take note of the Item Level targeting based on User group
    membership ;-)
     
    <Group uid="{984BC780-1140-45AB-9C98-B16459D8290C}" changed="2013-04-05
    11:50:46" removePolicy="0" userContext="0" image="2"
    name="Administrators (built-in)"
    clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}">
      <Properties groupName="Administrators (built-in)"
    groupSid="S-1-5-32-544" removeAccounts="0" deleteAllGroups="0"
    userAction="ADD" deleteAllUsers="0" description="" newName="" action="U"/>
      <Filters>
        <FilterGroup userContext="1" name="%Computername%_Admins"
    localGroup="0" primaryGroup="0" sid="" not="0" bool="AND"/>
      </Filters>
    </Group>
     
    Done you are. For reporting purposes, just print out the group
    memberships to see who is admin on what computers (can be more than one,
    of course). That's quite easy, isn't it?
     
    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!
    • Proposed as answer by Loren Davis Friday, April 5, 2013 1:05 PM
    • Marked as answer by Vivian_Wang Tuesday, April 9, 2013 1:36 AM
    Friday, April 5, 2013 12:08 PM

All replies

  • Target the specific workstation either by utalizing a WMI filter on your GPO or moving it to its own OU and applying the GPO only to that OU. I've included a link to WMI filtering overview for your consideration.

    WMI Filtering



    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Wednesday, April 3, 2013 6:18 PM
  • I have a list of over 400 desktops that I'd like to assign specific users too, but I don't want them to have admin rights on all the other desktops.

    I need to first remove those whom shouldn't have access and only allow some people admin rights to their specific desktop. 

    Will WMI filtering do that?  If so, do I need to create 400 + GPO's?

    I've removed admin rights from the local admin group in the past using WScripting, but the new requirement is for the script to reference a text for as an exception list.  I'm not confident that this is possible. and felt that Restricted groups would fit, but I see using this means that the user will have admin rights on all desktops, which will be pleasing to the company. 

    Any advice is appreciated

    Thank you

    Wednesday, April 3, 2013 6:38 PM
  • Restricted groups will work to make users local admins, but you will have to identify their machines; with that many, it may  be easiest to segment them off into their own OU or use some other unique identifier to target them. WMI filtering can target anything definable in the WMI schema so it is rather flexable, but without knowing your infrastructure, I wouldn't be able to make a recommendation as to how to target the specific users you are trying to target. A sub-OU within their current OU would be the easiest method and allow for the retention of all the existing GPOs. You won't have to create 400 GPOs, just one with all the admins defined and then attached to the OU with all the desired machines. If you want to explore WMI filtering, if all the machines have a specific preface on their naming convention or some other unique identifier that you could leverage, you would be able to target them based on that.


    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    • Edited by Loren Davis Wednesday, April 3, 2013 6:44 PM
    • Proposed as answer by Loren Davis Wednesday, April 3, 2013 7:22 PM
    Wednesday, April 3, 2013 6:42 PM
  • Ok, I have another concern.

    For example.  Joe Smith needs admin access to Computer 1, but not to the other 2000 computers.  This applies to all of the 400+ requests.  So basically one user to a specific computer and no other computer on the domain.

    All computers are positioned in groups for SCCM updates and other GPO's so I can't move them into a specific group.

    Wednesday, April 3, 2013 6:49 PM
  • Well, you CAN move them, it would just take adjusting the packages on the SCCM side to make things work correctly. Aside from that, with the requirement of one user to one machine, the simple (see time-consuming) way would be to add them manually to the local admin group. With 400 workstations, I wouldn't want to do that. Looking into it a bit, I did find a script to add the currently logged in user to the local admin group here. If you were to leverage such a script, this may get the majority of your clients. Then you could just run a query leveraging SCCM like this, or with a VBS script like this to check what machines you may have to touch manually. I realize this isn't a great solution, but I don't really see any other way to allow users to be local admins on their own machines without either segragating them to a mess of sub-OUs, manually touching every machine, or granting users the right to be local admins on more than just their boxes.



    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    • Proposed as answer by Loren Davis Wednesday, April 3, 2013 7:22 PM
    Wednesday, April 3, 2013 7:02 PM
  • Is there a script to remove users from the local admin group
    Wednesday, April 3, 2013 7:06 PM
  • You could modify the script, here to target all users rather than domain users.


    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Wednesday, April 3, 2013 7:12 PM
  • I see this only works with XP and not Windows 7, so I guess the only way is manual.  Is that accurate?
    Wednesday, April 3, 2013 7:57 PM
  • No, the responses in that thread provided guidance to correcting the issue in 7.


    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Wednesday, April 3, 2013 7:59 PM
  • Bob

    Thank you

    ' This script manages user membership to the local computers ' administrators group. It will add the current user as a member ' of the administrators group, remove "domain users" if a member ' then the script self destructs ' Last updated: 07/20/2010

    Does this only do as mentioned or will it just do what I'm needing to do which is remove a user from the local admin group?

    How do I customize this?

    cUser = GoGo.username  << What needs to be here?
    sNetBIOSDomain = GoGo.UserDomain  <<What needs to be here?
    cNode = GoGo.ComputerName  <<?  Do I need to put every computer name here?

    ' Remove "domain users" from local "administrators" group  << What if I want Domain users?
    If (lGroup.IsMember(dGroup.ADsPath) = True) Then
      lGroup.Remove(dGroup.ADsPath)
    End If

    Wednesday, April 3, 2013 8:11 PM
  • I am not a scripting person, unfortunately. I can tell you that those parameters do not need adjusting as they are defining the variables and as such are dynamic relative to the machine. I would hit up the Scripting Guys Forum for guidance on that. I apologize for not having an answer readily available. Hopefully someone over there can better assist.

    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    • Edited by Loren Davis Thursday, April 4, 2013 5:49 PM
    Thursday, April 4, 2013 5:31 PM
  • Am 03.04.2013 20:07, schrieb livingbeyond:
    > It's important to assign specific users to specific computer admin
    > rights.  I'm aware some of this can be done using restricted groups,
    > but how can this group be used to only add a specific user to specific
    > computer and not all computers?
     
    To give you (and W. Bob) a new direction that is more powerful:
     
    Use Group Policy Preferences "local users and groups"... Create one
    element at first, that removes all users from the local administrators.
    Then create a second element that adds users and groups you require on
    each computer. And then add one element that adds the current user
    (press F3 and select LogonUser or LogonUserSID) to administrators.
     
    Done you are. This makes the current user an admin on the computer he is
    currently logging on, and when another one logs on, it will remove the
    former user.
     
    If you need to assign given users to given workstations, it's just more
    work - use Item Level Targeting on the computer name.
     
    Job done.
     
    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!
    Thursday, April 4, 2013 8:57 PM
  • I like your approach, Martin. Setting up the administrators group like that would easily clear out all users. The only issue I can see with this is that the OP wants to limit the local administrators group to the owner of the machine and not allow users to login to multiple machines as administrators. Wouldn't your solution allow any user that logs in to any machine as a member of the local admin group?


    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, April 5, 2013 1:46 AM
  • The only thing I can think to do that would limit the membership of the administrators group on each machine to the owner of the box would be to set a custom attribute on the user's AD account defining their machine. Then run a logon script that states something along the lines of, if netbios name = custom attribute machine name, add current user to administrators group, else end. I really don't see a way to limit it the way you want without scripting.


    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, April 5, 2013 1:59 AM
  • Item level targeting is more administrative overhead to define each user. I would explore the path of a wmi query logon script that checks for a custom attribute, that way you only have to define a custom attribute on each user and the script works the same regardless. Plus it would be easier to manage if the machine name ever changed for whatever reason. Either way, the granularity that is being asked for will require some time to fully implement.


    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, April 5, 2013 2:05 AM
  • Am 05.04.2013 04:05, schrieb W. Bob:
    > Item level targeting is more administrative overhead to define each
    > user. I would explore the path of a wmi query logon script that checks
    > for a custom attribute, that way you only have to define a custom
    > attribute on each user and the script works the same regardless. Plus
    > it would be easier to manage if the machine name ever changed for
    > whatever reason. Either way, the granularity that is being asked for
    > will require some time to fully implement.
     
    It's not a lot of work... Anyway, you need to define which user is admin
    on what workstation. This can be done several ways... The easiest way
    I'm aware of:
     
    Let's say we have a computer named WS01. And we have a user John that
    needs to be Admin on WS01.
     
    Create a DL Security Group "WS01_Admins". Add John to this group. (This
    has to be done for each computer, but you can partially automate it with
    Excel and the "net group" command...)
     
    Then create one (repeat: ONE single!) Group Policy Preferences "Local
    Users and Groups" Item in the user part of a GPO with the following
    settings. Take note of the Item Level targeting based on User group
    membership ;-)
     
    <Group uid="{984BC780-1140-45AB-9C98-B16459D8290C}" changed="2013-04-05
    11:50:46" removePolicy="0" userContext="0" image="2"
    name="Administrators (built-in)"
    clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}">
      <Properties groupName="Administrators (built-in)"
    groupSid="S-1-5-32-544" removeAccounts="0" deleteAllGroups="0"
    userAction="ADD" deleteAllUsers="0" description="" newName="" action="U"/>
      <Filters>
        <FilterGroup userContext="1" name="%Computername%_Admins"
    localGroup="0" primaryGroup="0" sid="" not="0" bool="AND"/>
      </Filters>
    </Group>
     
    Done you are. For reporting purposes, just print out the group
    memberships to see who is admin on what computers (can be more than one,
    of course). That's quite easy, isn't it?
     
    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!
    • Proposed as answer by Loren Davis Friday, April 5, 2013 1:05 PM
    • Marked as answer by Vivian_Wang Tuesday, April 9, 2013 1:36 AM
    Friday, April 5, 2013 12:08 PM
  • Very nice, Martin. I believe that will get the OP what he wanted. Thanks for the lesson.



    Best Regards,
    Bob.

    If you found this comment to be the solution or helpful, consider marking it as such below.
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, April 5, 2013 1:06 PM
  • Am 05.04.2013 15:06, schrieb W. Bob:
    > Thanks for the lesson.
     
    That wasn't a lesson - it was just an advice ;-)
    If it were a  lesson, you would have noticed...
     

    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!
    Saturday, April 6, 2013 10:21 PM