While Windows 2000 and 2003 offered a few new Built-In security groups to use in granting permissions to administrative resources, they both still leave much to be desired when designing security models. With the advent of Sarbanes-Oxley (thanks again Enron), System Administrators are now tasked with not only increasing security, but also auditing changes to the environment. (Note – change management also plays a major role regarding Sarbanes-Oxley; however, that topic is too expansive to be discussed here.)
LetÂ’s take a slight step backwards and define exactly what role-based security is. In a nutshell, role-based security is creating ACEÂ’s (Access Control Entries or users and groups) based upon job function and then using very specific ACLÂ’s(Access Control Lists) to lock them down allowing administrators to have the ability to perform only their job function and nothing more. For example, if we have a junior administrator that performs basic user creation and administration as well as basic workstation management, we probably donÂ’t want this person to have the ability to delete server accounts from AD, or modify Cisco Unity attributes on user accounts, or alter PKI certificate settings in the environment, etc. Using the built-in groups, this is quite cumbersome to do but using a role-based approach, we suddenly discover a new level of granularity that makes such detailed permissions possible.
First Steps
Before we can start creating groups for our different permissions, we must first define our roles. This will more than likely entail some interaction with the management team and HR staff to obtain the company accepted titles and their required job functions. (If you are fortunate enough to have input into this, now is a great time to redefine job responsibilities if they are misaligned to new technologies because they havenÂ’t been updated in a while.)
Once weÂ’ve obtained the roles within the company, we can begin to create the role-based groups in AD. These groups will mimic the roles in title so we know what they represent. For example, if we have a Sr. AD Engineer, AD Engineer II, System Administrator, and Jr. System Administrator we might want to use the following naming schemes for the groups:
GG_Sr_AD_Eng
GG_AD_Eng
GG_SysAdmin
GG_Jr_SysAdmin
We prepend the “GG” to the name so that we know it’s a Global Group. We will use Global Security Groups to nest within Domain Local Groups explained next. Remember, we can only nest Global Groups with Domain Local Groups, not the other way around. In addition, this allows us the ability to nest the Global Group within Domain Local Groups in other domains if we have a multi-domain forest (must be at least 2000 native mode).
Defining the Access Groups
Now that we have our role-based groups, it is time to create the groups that will allow the actual access to the AD resources. Since domains are simply security boundaries we would create the access groups as Domain Local Groups within each domain in our forest. (Note – we can also apply this same functionality to Forest and Site objects as well. In addition, in Windows2003 we could use Universal Groups as the replication traffic is greatly reduced since only attribute level deltas are replicated instead of the entire object.)
This part is a bit trickier than before as we need to be careful to allow for all necessary permissions for each role to be able to perform their job functions. An easy method to use in visualizing this is a spreadsheet matrix format. LetÂ’s define the job functions of the aforementioned roles as follows (these examples are vastly simplified as there are thousands of possible configurations):
Sr_AD_Eng
Create, modify, delete users
Create, modify, delete workstations and servers
Create, modify, delete groups
Create, modify, delete OU
Create, modify, delete GPO
AD_Eng
Create, modify, delete users
Create, modify, delete workstations and servers
Create, modify, delete groups
Create, modify OU
Create, modify GPO
SysAdmin
Create, modify users
Create, modify workstations and servers
Create, modify groups
Jr_SysAdmin
Modify users
Create, modify workstations
Modify groups
*Remember, each of these are Domain Local Groups that need to be created as listed below.
Our matrix would be as follows:
Sr. AD Eng
AD Eng
SysAdmin
Jr. SysAdmin
Create,modify,delete users
X
X
Create,modify users
X
X
X
Modify users
X
X
X
X
Create,modify,delete computers
X
X
Create,modify computers
X
X
X
X
Create,modify,delete groups
X
X
Create,modify groups
X
X
X
Modify groups
X
X
X
X
Create,modify,delete OU
X
Create,modify OU
X
X
Create,modify,delete GPO
X
Create,modify GPO
X
X
By using our matrix, we can better visualize who has permissions to do what in the environment. Each cell in the leftmost column represents a Domain Local Group that will be created and the cells in the top row represent the Global Groups we used to define roles. This can be easily be tailored to meet any needs for any AD environment and depending upon the security definition requirements can grow to be quite large depending on how granularly the permissions in the left column are defined.
Implementing the Security Model
The next step is to actually modify the ACL’s on AD resources to meet our security requirements defined in our matrix. To do this we initially use the Delegation Wizard to create the security framework and then the ACL Editor to “tweak” the settings. We will use the DLG_Create_Modify_Delete_Users Domain Local Group in our example.
First, open up ADUC and navigate to the Users OU. (ItÂ’s always a good idea to move users out of the default Users container into a separate custom OU so that more granular GPOÂ’s can be applied.) Right click on the OU and select Delegate Control. Next, click the Add button and select the DLG_Create_Modify_Delete_Users Domain Local Group created earlier then click Next to get to the Tasks to Delegate window.
We will want to select Create a custom task to delegate as the standard common tasks are too broad and will grant more permissions than we want which will require us to go back and make more edits in the ACL Editor later. Click Next.
As we are only interested in modifying the ACLÂ’s for User objects in this OU, select the Only the following objects in this folder button. In the object window, select the User objects checkbox. Next, select the Create and Delete checkboxes underneath as we want the Domain Local Group to be able to both create and delete user objects in the Users OU. Click Next.
In the Permissions window, select the Property-Specific checkbox in addition to the already checked General checkbox. This brings up many more attribute options for us to work with.
Note – The list of attributes in the Permissions window is NOT a complete list of all the attributes for an object. This list is controlled by the dssec.dat file located in the %SYSTEMROOT%\System32 directory on the Domain Controllers. This file can be edited using Notepad and defines what appears in this list. For example, the City attribute does not appear by default. To modify the file to enable this attribute to appear, open the dssec.dat file in Notepad and navigate towards the bottom to the [user] section. Look for the “l” (lowercase L) attribute and change the number from a 7 to a 0 (zero) and save the file. This setting will make the City attribute appear in the list and be Read/Write enabled. You must close and open the ADUC for the changes to take effect.
Select the following settings in the Permissions window to grant the DLG_Create_Modify_Delete_Users Domain Local Group the ability to create, modify, and delete user accounts:
· Read
· Write
· Read all Properties (enables the Read flag on all other attributes)
· Write all Properties (enables the Write flag on all other attributes)
· Change Password
· Reset Password
Review the rest of the permissions and then click Next and then Finish to apply the changes.
Follow steps one through four for the other Domain Local Groups. Modify the selections in step five to reflect the correct settings in the matrix we used earlier for each access role.
Review and Edit Permissions using the ACL Editor
Right click on the User OU again and select Properties. Next, select the Security tab and then the Advanced button to bring up the Advanced Security Settings window.
Highlight the entry for the DLG_Create_Modify_Delete_Users Domain Local Group that has Special underneath the Permissions column and select Edit. In the editor we can view the currently selected Permissions as well as make modifications to the settings.
Modify the existing ACL permissions that were created by the Delegation Wizard as needed.
Configure Auditing
In order to track changes made to an object in AD, we must enable Auditing on that object and then specify the ACE (a user or group object) that will be audited as well as what parameters we are going to audit.
From the Advanced Security Settings window select the Auditing tab.
Select the Add button and add the DLG_Create_Modify_Delete_Users Domain Local Group. Click OK.
This brings up the Auditing Entry window in which we will define the level of auditing we want to perform for the DLG_Create_Modify_Delete_Users Domain Local Group on User objects in the Users OU. In the following example, we have selected to audit whenever a member of this group deletes a user object from this OU.
Repeat these steps for each additional Domain Local Group on each object that needs to be audited.
Final Steps
To bring it all together we will now nest the Global Groups into the appropriate Domain Local Groups. Using the Jr. SysAdmin role as an example we would place the GG_Jr_SysAdmin Global Group into the DLG_Modify_Users, DLG_Create_Modify_Computers, and DLG_Modify_Groups Domain Local Groups.
The final step is to add users to the Global Groups we used to define the actual roles. For example if Joe Smith is a Sr. AD Engineer and Kathy Johnson is an AD Engineer, we would add Joe to the GG_Sr_AD_Eng and Kathy to the GG_AD_Eng Global Groups. As these Global Groups would already be nested into the appropriate Domain Local Groups using our matrix as a guide and the Jr. SysAdmin group mentioned above as an example, Joe and Kathy would automatically obtain the appropriate permissions necessary to perform their jobs. They would not be required to have Domain Admin access or use similar Built-In groups as we would have already defined the proper access for these roles in our design.
It should be noted that we will not be able to do away with the Built-In groups altogether. There are specific rights and permissions that these groups have which must be used to access certain AD features or install application such as Exchange. There should always be an account that has Domain Admin, Enterprise Admin, Schema Admin, etc permissions (either altogether or as separate accounts). This method simply allows us to minimize the usage of those accounts and the inherit security exposure they present.
Although this is simply an introductory view to what can sometimes become an extremely complex undertaking, using an RBAC (Role Based Access Control) approach to AD can make securing AD extremely manageable once implemented. The ability to simply add a new employee (or remove an old employee) from a single group to assign or remove permissions is extremely timesaving and valuable in AD administration not to mention killer job security depending upon how complex you decide to make your implementation.
Alan Finn has designed and implemented Active Directory and Exchange infrastructures for companies with global presence and currently works as the Senior Engineer on the AD Team for a major media company. He is also the co-founder of a consulting company based in North Dallas, Texas catering to small to mid-size businesses in regards to AD and Windows Operating Systems architecture design, implementation, tuning, and security.
LetÂ’s take a slight step backwards and define exactly what role-based security is. In a nutshell, role-based security is creating ACEÂ’s (Access Control Entries or users and groups) based upon job function and then using very specific ACLÂ’s(Access Control Lists) to lock them down allowing administrators to have the ability to perform only their job function and nothing more. For example, if we have a junior administrator that performs basic user creation and administration as well as basic workstation management, we probably donÂ’t want this person to have the ability to delete server accounts from AD, or modify Cisco Unity attributes on user accounts, or alter PKI certificate settings in the environment, etc. Using the built-in groups, this is quite cumbersome to do but using a role-based approach, we suddenly discover a new level of granularity that makes such detailed permissions possible.
First Steps
Before we can start creating groups for our different permissions, we must first define our roles. This will more than likely entail some interaction with the management team and HR staff to obtain the company accepted titles and their required job functions. (If you are fortunate enough to have input into this, now is a great time to redefine job responsibilities if they are misaligned to new technologies because they havenÂ’t been updated in a while.)
Once weÂ’ve obtained the roles within the company, we can begin to create the role-based groups in AD. These groups will mimic the roles in title so we know what they represent. For example, if we have a Sr. AD Engineer, AD Engineer II, System Administrator, and Jr. System Administrator we might want to use the following naming schemes for the groups:
GG_Sr_AD_Eng
GG_AD_Eng
GG_SysAdmin
GG_Jr_SysAdmin
We prepend the “GG” to the name so that we know it’s a Global Group. We will use Global Security Groups to nest within Domain Local Groups explained next. Remember, we can only nest Global Groups with Domain Local Groups, not the other way around. In addition, this allows us the ability to nest the Global Group within Domain Local Groups in other domains if we have a multi-domain forest (must be at least 2000 native mode).
Defining the Access Groups
Now that we have our role-based groups, it is time to create the groups that will allow the actual access to the AD resources. Since domains are simply security boundaries we would create the access groups as Domain Local Groups within each domain in our forest. (Note – we can also apply this same functionality to Forest and Site objects as well. In addition, in Windows2003 we could use Universal Groups as the replication traffic is greatly reduced since only attribute level deltas are replicated instead of the entire object.)
This part is a bit trickier than before as we need to be careful to allow for all necessary permissions for each role to be able to perform their job functions. An easy method to use in visualizing this is a spreadsheet matrix format. LetÂ’s define the job functions of the aforementioned roles as follows (these examples are vastly simplified as there are thousands of possible configurations):
Sr_AD_Eng
Create, modify, delete users
Create, modify, delete workstations and servers
Create, modify, delete groups
Create, modify, delete OU
Create, modify, delete GPO
AD_Eng
Create, modify, delete users
Create, modify, delete workstations and servers
Create, modify, delete groups
Create, modify OU
Create, modify GPO
SysAdmin
Create, modify users
Create, modify workstations and servers
Create, modify groups
Jr_SysAdmin
Modify users
Create, modify workstations
Modify groups
*Remember, each of these are Domain Local Groups that need to be created as listed below.
Our matrix would be as follows:
Sr. AD Eng
AD Eng
SysAdmin
Jr. SysAdmin
Create,modify,delete users
X
X
Create,modify users
X
X
X
Modify users
X
X
X
X
Create,modify,delete computers
X
X
Create,modify computers
X
X
X
X
Create,modify,delete groups
X
X
Create,modify groups
X
X
X
Modify groups
X
X
X
X
Create,modify,delete OU
X
Create,modify OU
X
X
Create,modify,delete GPO
X
Create,modify GPO
X
X
By using our matrix, we can better visualize who has permissions to do what in the environment. Each cell in the leftmost column represents a Domain Local Group that will be created and the cells in the top row represent the Global Groups we used to define roles. This can be easily be tailored to meet any needs for any AD environment and depending upon the security definition requirements can grow to be quite large depending on how granularly the permissions in the left column are defined.
Implementing the Security Model
The next step is to actually modify the ACL’s on AD resources to meet our security requirements defined in our matrix. To do this we initially use the Delegation Wizard to create the security framework and then the ACL Editor to “tweak” the settings. We will use the DLG_Create_Modify_Delete_Users Domain Local Group in our example.
First, open up ADUC and navigate to the Users OU. (ItÂ’s always a good idea to move users out of the default Users container into a separate custom OU so that more granular GPOÂ’s can be applied.) Right click on the OU and select Delegate Control. Next, click the Add button and select the DLG_Create_Modify_Delete_Users Domain Local Group created earlier then click Next to get to the Tasks to Delegate window.
We will want to select Create a custom task to delegate as the standard common tasks are too broad and will grant more permissions than we want which will require us to go back and make more edits in the ACL Editor later. Click Next.
As we are only interested in modifying the ACLÂ’s for User objects in this OU, select the Only the following objects in this folder button. In the object window, select the User objects checkbox. Next, select the Create and Delete checkboxes underneath as we want the Domain Local Group to be able to both create and delete user objects in the Users OU. Click Next.
In the Permissions window, select the Property-Specific checkbox in addition to the already checked General checkbox. This brings up many more attribute options for us to work with.
Note – The list of attributes in the Permissions window is NOT a complete list of all the attributes for an object. This list is controlled by the dssec.dat file located in the %SYSTEMROOT%\System32 directory on the Domain Controllers. This file can be edited using Notepad and defines what appears in this list. For example, the City attribute does not appear by default. To modify the file to enable this attribute to appear, open the dssec.dat file in Notepad and navigate towards the bottom to the [user] section. Look for the “l” (lowercase L) attribute and change the number from a 7 to a 0 (zero) and save the file. This setting will make the City attribute appear in the list and be Read/Write enabled. You must close and open the ADUC for the changes to take effect.
Select the following settings in the Permissions window to grant the DLG_Create_Modify_Delete_Users Domain Local Group the ability to create, modify, and delete user accounts:
· Read
· Write
· Read all Properties (enables the Read flag on all other attributes)
· Write all Properties (enables the Write flag on all other attributes)
· Change Password
· Reset Password
Review the rest of the permissions and then click Next and then Finish to apply the changes.
Follow steps one through four for the other Domain Local Groups. Modify the selections in step five to reflect the correct settings in the matrix we used earlier for each access role.
Review and Edit Permissions using the ACL Editor
Right click on the User OU again and select Properties. Next, select the Security tab and then the Advanced button to bring up the Advanced Security Settings window.
Highlight the entry for the DLG_Create_Modify_Delete_Users Domain Local Group that has Special underneath the Permissions column and select Edit. In the editor we can view the currently selected Permissions as well as make modifications to the settings.
Modify the existing ACL permissions that were created by the Delegation Wizard as needed.
Configure Auditing
In order to track changes made to an object in AD, we must enable Auditing on that object and then specify the ACE (a user or group object) that will be audited as well as what parameters we are going to audit.
From the Advanced Security Settings window select the Auditing tab.
Select the Add button and add the DLG_Create_Modify_Delete_Users Domain Local Group. Click OK.
This brings up the Auditing Entry window in which we will define the level of auditing we want to perform for the DLG_Create_Modify_Delete_Users Domain Local Group on User objects in the Users OU. In the following example, we have selected to audit whenever a member of this group deletes a user object from this OU.
Repeat these steps for each additional Domain Local Group on each object that needs to be audited.
Final Steps
To bring it all together we will now nest the Global Groups into the appropriate Domain Local Groups. Using the Jr. SysAdmin role as an example we would place the GG_Jr_SysAdmin Global Group into the DLG_Modify_Users, DLG_Create_Modify_Computers, and DLG_Modify_Groups Domain Local Groups.
The final step is to add users to the Global Groups we used to define the actual roles. For example if Joe Smith is a Sr. AD Engineer and Kathy Johnson is an AD Engineer, we would add Joe to the GG_Sr_AD_Eng and Kathy to the GG_AD_Eng Global Groups. As these Global Groups would already be nested into the appropriate Domain Local Groups using our matrix as a guide and the Jr. SysAdmin group mentioned above as an example, Joe and Kathy would automatically obtain the appropriate permissions necessary to perform their jobs. They would not be required to have Domain Admin access or use similar Built-In groups as we would have already defined the proper access for these roles in our design.
It should be noted that we will not be able to do away with the Built-In groups altogether. There are specific rights and permissions that these groups have which must be used to access certain AD features or install application such as Exchange. There should always be an account that has Domain Admin, Enterprise Admin, Schema Admin, etc permissions (either altogether or as separate accounts). This method simply allows us to minimize the usage of those accounts and the inherit security exposure they present.
Although this is simply an introductory view to what can sometimes become an extremely complex undertaking, using an RBAC (Role Based Access Control) approach to AD can make securing AD extremely manageable once implemented. The ability to simply add a new employee (or remove an old employee) from a single group to assign or remove permissions is extremely timesaving and valuable in AD administration not to mention killer job security depending upon how complex you decide to make your implementation.
Alan Finn has designed and implemented Active Directory and Exchange infrastructures for companies with global presence and currently works as the Senior Engineer on the AD Team for a major media company. He is also the co-founder of a consulting company based in North Dallas, Texas catering to small to mid-size businesses in regards to AD and Windows Operating Systems architecture design, implementation, tuning, and security.
