G
Guest
I need to find some way to centrally manage membership of the Administrators local group on workstations. If you're vaguely interested, please read the description of what they need, how they currently work and a few alternative proposals I've been able to think up. If anyone can come up with any bright ideas, or know of some way other people have already solved this problem, please let me know. You will be my hero for ever.
--------------------------------------------------------------------------------
Original requirement:
· Admin rights on workstations must be centrally controlled.
· As a rule, users may not have admin rights on their own computers.
· The local Administrators group on each computer must be pre-populated to contain only the users (such as central IT workstation admins) who need rights to manage the computers
Current implementation:
· Workstations are divided into regional OUs
· On each regional workstation OU, a Group Policy Object (GPO) assigns membership of the local built-in groups on the workstations (e.g. Administrators, Power Users) through a 'restricted groups' policy.
· This policy defines who should be members of the group and automatically adds required domain accounts/groups to the local group, but also removes any members who have not been added via the policy.
· When the policy is downloaded, it always overwrites the manually configured membership of a local group. Manually added group members are dropped.
· This makes it impossible to manually add someone into the local Administrators group on a single computer, as they will be automatically removed the next time the policy is checked (start-up, then every 90 minutes).
· A 'regional workstation admins' role group has been defined for each region. Administrators assigned to this role are automatically made members of the local Administrators group on each workstation in their region. All desktop support staff in a region (Charles Lospers' people) are assigned to the role group for that region.
Additional Requirement:
· Some users need to be permanently assigned membership of Administrators or Power Users on their individual workstations, to meet operational requirements.
· Sometimes administrators or users need to be temporarily assigned membership of Administrators or Power Users on a specific workstation, in order to perform a specific configuration task. This must be revoked after a short period (e.g. a day).
· The requirement for group membership to be centrally controlled (as a rule) should be maintained.
Solution Options:
1. Use start-up scripts to manage group membership.
· Overview:
· Drop GPO settings that do group management using restricted groups
· In the GPO on the regional workstations OU define a start-up script that modifies membership of local groups ('net localgroup /add').
§ This will cumulatively add users into the specified group.
§ Previous group membership will be unaffected.
· Pros:
· Changes made to group membership on individual machines will not be lost.
· Very little additional work required to make it work.
· Cons:
· Local changes to group membership are retained - i.e. you lose the ability to restrict membership of local groups.
2. Create a per-computer GPO for computers requiring exceptions.
· Overview:
· A 'Local Admins' OU is created under the existing regional workstations OU. All workstations requiring exceptions to the standard policy are moved there.
· A separate GPO is created on the 'Local Admins' OU for EACH computer in the OU.
· The GPO has the same name as the computer.
· A permissions filter is set on the GPO to ensure it applies only to that computer.
· The restricted groups policy in the computer-specific GPO is configured with the required membership of local groups.
· Each computer in this OU can thus be given a per-computer configuration.
· Reason for computer to be assigned 'exception' configuration can be recorded in the Description field - will show up in MMC for quick review.
· When a computer is moved back into the 'standard' OU, its configuration reverts back to 'standard'.
· Entire operation can be scripted, to work from HTML interface or MMC custom taskpad. This wont be easy, but will reduce complexity for operator.
· Pros:
· Gives you granular ability to perform per-computer configuration
· All computers with 'exception' configuration will be kept together in one OU - makes them easier to track.
· Cons:
· Lot of work, relatively complex, many steps to perform.
· Will probably force creation of huge number of GPOs (at least several 100) which will be bad for AD performance - increase size of DB and SYSVOL, increase replication. Bad idea for technical reasons.
· Someone will have to track why computers have been given local admin rights, which ones should revert to std. config., etc.
3. Create a single GPO for all computers requiring exceptions (Variation on option 2).
· Overview:
· This is essentially similar to Option 2, but requires less GPOs to be created.
· A 'Local Admins' OU is created under the existing regional workstations OU. All workstations requiring exceptions to the standard policy are moved there (like Option 2).
· A single GPO is created on the 'Local Admins' OU (to apply to all computers in the OU).
· The restricted groups policy in the computer-specific GPO is configured with the required membership of local groups, on ALL computers in the OU.
· Each computer in this OU thus has an identical configuration. (If the OU contains PC1 and PC2, and I need User1 to be an administrator of PC1, the policy will make him an admin on PC1 and PC2).
· When a computer is moved back into the 'standard' OU, its configuration reverts back to 'standard'.
· Entire operation can be scripted, to work from HTML interface or MMC custom taskpad. This wont be easy, but will reduce complexity for operator.
· Pros:
· Less GPOs are created than Option 2: Less work for admins, less performance impact on domain
· Cons:
· Because the security configuration of all 'exception' computers are identical, it means that the users assigned admin rights on one workstation is also granted it on all 'exception' workstations in the region. This will probably be unacceptable to security/internal audit, etc. Big security risk.
4. Use start-up scripts to manage group membership; Read membership from AD (Variation on option 1).
· Overview:
· Drop GPO settings that do group management using restricted groups
· In the GPO on the regional workstations OU define a start-up script that examines membership of local groups.
· The script must compare the current membership of the group against a pre-determined membership list
· Members defined in the list that are not currently members must be added
· Members manually added to the group, but not listed in the pre-determined membership list, must be dropped
· If the group membership matches the pre-determined list, no action should be taken.
· The pre-determined membership list must be stored in Active Directory.
· The schema must be modified to add additional (multi-valued?) attributes to the Computer object, for 'Local Admins Members', 'Local Power Users Members', etc.
· The membership of the local groups must be stored in these attributes.
· The AD Display Specifiers will also have to be modified to expose these attributes through the GUI of the 'AD Users and Computers' snap-in.
· Procedures will have to be put in place to manage the membership of local groups through AD
· An import operation will initially do a bulk-load of the standard local group membership attributes of all the computers in a regional OU.
· Exceptions to the standard configuration will be configured through the GUI of the 'AD Users and Computers' snap-in.
· Pros:
· Local group membership on individual machines can be managed separately (more flexible than restricted groups policy).
· Local group management is centralized and enforced (like restricted groups policy).
· Even if a computer is rebuilt its local group membership will be retained.
· Unauthorized changes to local group membership are prevented (like restricted groups policy).
· Cons:
· Schema change required - will have to fight a battle with schema change control to convince them change is safe.
· Not an easy script to write.
· Extra maintenance procedure for Computer objects in AD - now also have to look after local group memberships.
--------------------------------------------------------------------------------
Original requirement:
· Admin rights on workstations must be centrally controlled.
· As a rule, users may not have admin rights on their own computers.
· The local Administrators group on each computer must be pre-populated to contain only the users (such as central IT workstation admins) who need rights to manage the computers
Current implementation:
· Workstations are divided into regional OUs
· On each regional workstation OU, a Group Policy Object (GPO) assigns membership of the local built-in groups on the workstations (e.g. Administrators, Power Users) through a 'restricted groups' policy.
· This policy defines who should be members of the group and automatically adds required domain accounts/groups to the local group, but also removes any members who have not been added via the policy.
· When the policy is downloaded, it always overwrites the manually configured membership of a local group. Manually added group members are dropped.
· This makes it impossible to manually add someone into the local Administrators group on a single computer, as they will be automatically removed the next time the policy is checked (start-up, then every 90 minutes).
· A 'regional workstation admins' role group has been defined for each region. Administrators assigned to this role are automatically made members of the local Administrators group on each workstation in their region. All desktop support staff in a region (Charles Lospers' people) are assigned to the role group for that region.
Additional Requirement:
· Some users need to be permanently assigned membership of Administrators or Power Users on their individual workstations, to meet operational requirements.
· Sometimes administrators or users need to be temporarily assigned membership of Administrators or Power Users on a specific workstation, in order to perform a specific configuration task. This must be revoked after a short period (e.g. a day).
· The requirement for group membership to be centrally controlled (as a rule) should be maintained.
Solution Options:
1. Use start-up scripts to manage group membership.
· Overview:
· Drop GPO settings that do group management using restricted groups
· In the GPO on the regional workstations OU define a start-up script that modifies membership of local groups ('net localgroup /add').
§ This will cumulatively add users into the specified group.
§ Previous group membership will be unaffected.
· Pros:
· Changes made to group membership on individual machines will not be lost.
· Very little additional work required to make it work.
· Cons:
· Local changes to group membership are retained - i.e. you lose the ability to restrict membership of local groups.
2. Create a per-computer GPO for computers requiring exceptions.
· Overview:
· A 'Local Admins' OU is created under the existing regional workstations OU. All workstations requiring exceptions to the standard policy are moved there.
· A separate GPO is created on the 'Local Admins' OU for EACH computer in the OU.
· The GPO has the same name as the computer.
· A permissions filter is set on the GPO to ensure it applies only to that computer.
· The restricted groups policy in the computer-specific GPO is configured with the required membership of local groups.
· Each computer in this OU can thus be given a per-computer configuration.
· Reason for computer to be assigned 'exception' configuration can be recorded in the Description field - will show up in MMC for quick review.
· When a computer is moved back into the 'standard' OU, its configuration reverts back to 'standard'.
· Entire operation can be scripted, to work from HTML interface or MMC custom taskpad. This wont be easy, but will reduce complexity for operator.
· Pros:
· Gives you granular ability to perform per-computer configuration
· All computers with 'exception' configuration will be kept together in one OU - makes them easier to track.
· Cons:
· Lot of work, relatively complex, many steps to perform.
· Will probably force creation of huge number of GPOs (at least several 100) which will be bad for AD performance - increase size of DB and SYSVOL, increase replication. Bad idea for technical reasons.
· Someone will have to track why computers have been given local admin rights, which ones should revert to std. config., etc.
3. Create a single GPO for all computers requiring exceptions (Variation on option 2).
· Overview:
· This is essentially similar to Option 2, but requires less GPOs to be created.
· A 'Local Admins' OU is created under the existing regional workstations OU. All workstations requiring exceptions to the standard policy are moved there (like Option 2).
· A single GPO is created on the 'Local Admins' OU (to apply to all computers in the OU).
· The restricted groups policy in the computer-specific GPO is configured with the required membership of local groups, on ALL computers in the OU.
· Each computer in this OU thus has an identical configuration. (If the OU contains PC1 and PC2, and I need User1 to be an administrator of PC1, the policy will make him an admin on PC1 and PC2).
· When a computer is moved back into the 'standard' OU, its configuration reverts back to 'standard'.
· Entire operation can be scripted, to work from HTML interface or MMC custom taskpad. This wont be easy, but will reduce complexity for operator.
· Pros:
· Less GPOs are created than Option 2: Less work for admins, less performance impact on domain
· Cons:
· Because the security configuration of all 'exception' computers are identical, it means that the users assigned admin rights on one workstation is also granted it on all 'exception' workstations in the region. This will probably be unacceptable to security/internal audit, etc. Big security risk.
4. Use start-up scripts to manage group membership; Read membership from AD (Variation on option 1).
· Overview:
· Drop GPO settings that do group management using restricted groups
· In the GPO on the regional workstations OU define a start-up script that examines membership of local groups.
· The script must compare the current membership of the group against a pre-determined membership list
· Members defined in the list that are not currently members must be added
· Members manually added to the group, but not listed in the pre-determined membership list, must be dropped
· If the group membership matches the pre-determined list, no action should be taken.
· The pre-determined membership list must be stored in Active Directory.
· The schema must be modified to add additional (multi-valued?) attributes to the Computer object, for 'Local Admins Members', 'Local Power Users Members', etc.
· The membership of the local groups must be stored in these attributes.
· The AD Display Specifiers will also have to be modified to expose these attributes through the GUI of the 'AD Users and Computers' snap-in.
· Procedures will have to be put in place to manage the membership of local groups through AD
· An import operation will initially do a bulk-load of the standard local group membership attributes of all the computers in a regional OU.
· Exceptions to the standard configuration will be configured through the GUI of the 'AD Users and Computers' snap-in.
· Pros:
· Local group membership on individual machines can be managed separately (more flexible than restricted groups policy).
· Local group management is centralized and enforced (like restricted groups policy).
· Even if a computer is rebuilt its local group membership will be retained.
· Unauthorized changes to local group membership are prevented (like restricted groups policy).
· Cons:
· Schema change required - will have to fight a battle with schema change control to convince them change is safe.
· Not an easy script to write.
· Extra maintenance procedure for Computer objects in AD - now also have to look after local group memberships.