I work as a Systems Administrator for a small company (user base), it is easy to manage users and groups. It used to be mostly ad-hoc with no planning whatsoever. You create a group when needed and add users to that group.

The company started doing well things started picking up. I don’t want to be in a position creating user accounts for the first half of my day. Growth began challenging the practices of administering users and groups within Active Directory.

A best practice from Microsoft is utilizing a strategy called AGDLA: Accounts are members of Global groups which are members of Domain Local groups which are added to Access control lists.

Accounts are the user accounts created for logins which have a unique security identifier (SID).

Global groups determine roles within the organization. I like to think of them as departments such as Accounting or Human Resources.

Domain Local groups are very similar to ACLs except that it is used to define which global groups will have access to a resource and what kind of access which is placed in an ACL of the resource.

Implementing This Strategy

My environment was full of ad-hoc groups and permissions to resources. It got so ugly and unmanageable. For example:

• Dozens of individual users with different permissions to an Accounting folder on the file server.
• Dozens of individual users with permissions to an email account.

What I’ve done to resolve this issue is create organizational units for each department. Within those OUs I created a global group that contained all the department users. So continuing with the Accounting department, I created a domain local group called ACL_AccountingShare_MOD and added the Accounting global group to the domain local group. If other departments collaborated within this shared folder I can add their global group to the domain local group as well.

Let me analyze the naming convention of the domain local group:

ACL_AccountingShare_MOD

ACL = this tells me that this group specifies who has access to a resource

AccountingShare = tells me that this group is an ACL resource group to the AccountingShare

MOD = tells me that this ACL resource group to the AccountingShare is able to modify all documents within that resource

Open the group and document as much as you can. In the Description I state what the group is for and within the Notes field I will list the path to the resource.

Closing Notes

Managing users, groups and resources with this method keeps everything clean. So when it comes to account creation, I create a template account that contains access to the necessary groups. It’s a disabled account within each department’s OU.

Whenever a department gets new employees all I have to do is copy the template and change the name of the account to the new user. Now I don’t have to manually set permissions to every resource that user will need.

This also eliminates the ghost accounts. A ghost account is an account that was given permissions to a resource but then that user account is deleted from Active Directory leaving just the SID within the resource’s ACL.

{ 0 comments }