Active Directory – 2000Trainers.com

Securing Active Directory Using a Roles-Based Approach

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 seen in this table.

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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

1. 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.

2. 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.

3. 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.

1. From the Advanced Security Settings window select the Auditing tab.

2. Select the Add button and add the DLG_Create_Modify_Delete_Users Domain Local Group. Click OK.

3. 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.

4. 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.

Active Directory Quick Start Guide

Setting up Active Directory is far from difficult. However, many people experience problems with their installation shortly after completing it because they neglect to properly plan their implementation of DNS. I receive emails on almost a weekly basis from users who have gone ahead and run dcpromo, and then wonder why client systems can’t properly connect to the Internet. The purpose of this article is to act as a quick primer towards ensuring that Active Directory works, while at the same time allowing your network systems proper Internet access.

Before I begin, it’s worth mentioning that this article is aimed at users who are looking to install and work with Active Directory on a small or home network. It is not aimed at users upgrading from NT 4, or planning a major Active Directory deployment including Exchange 2000, although the central concepts outlined still hold true. However, if you are looking for a quick and easy guide to setting up an AD test network, then this article should help to ensure that you get started on the right foot. I assume that the server we are configuring will be the first domain controller in your new Active Directory domain, and that your internal systems can already access the Internet via some method, such as Internet Connection Sharing, NAT, or perhaps some type of connection-sharing hardware router.

Pages: 123

DHCP and Active Directory

The first thing you’ll need to understand about Windows 2000 DHCP is that if your DHCP server is part of a Windows 2000 domain, the server must be ‘authorized’ in Active Directory. If a DHCP server has not been authorized, it will not hand out IP addresses to clients. The purpose of DHCP server registration stems from the fact that unwanted DHCP servers can wreak havoc on a network. At times this is done maliciously, but often an inexperienced administrator installs the service not understanding that any DHCP server who hears a request will reply offering an address. Windows 2000 tries to solve some of these problems by requiring that DHCP be authorized, thus eliminating the problems posed by ‘rogue’ DHCP servers. While this sounds great, unfortunately the total benefit is more limited. The only servers that will check to see whether or not they are authorized are Windows 2000 DHCP servers – your NT 4 DHCP servers (and others) will continue to hand out IP addresses regardless.

The authorization process itself is very simple. Using the DHCP console tool, simply right-click the DHCP icon, choose Manage Authorized Servers, and then authorize the server by adding its name or IP address, as shown below. Note that the only person who can authorize a DHCP server is a user who is a member of the Enterprise Admins group (this ability can be delegated if required)

When the DHCP server service attempts to start (which happens automatically during a reboot), it will send a DHCPINFORM message to Active Directory to determine its authorization state. If it has been authorized, the service starts correctly. If it hasn’t, the service does not start. The DHCP server will query Active Directory periodically (every 5 minutes by default) to ensure that its authorization status hasn’t changed.

Managing Operations Masters

Having already looked at what the operations masters roles are responsible for in previous articles, in this section we take a look at the actual management of the 5 roles, which includes the transfer or seizing of the roles. Just to quickly recap, the operations masters roles are special role held by certain domain controllers on a per domain/ per forest basis. The 5 roles are:

Schema Master – controls originating updates to the Schema. One domain controller per forest holds this role.
Domain Naming Master – controls the addition / deletion of domains from the forest. This system must also be a Global Catalog Server. One domain controller per forest holds this role.
PDC Emulator – acts as the PDC for BDCs when the domain is in mixed mode, manages password changes for downlevel (pre-win2k) clients, is the focus for group policy changes, and is immediately forwarded all password changes. One domain controller per domain holds this role.
RID Master – allocates the pool of relative identifiers (RIDs, which are the unique part of SIDs) to each domain controller in the domain. One domain controller per domain holds this role. Note that you can view the RID pool allocation using a utility called dcdiag, the domain controller diagnostic utility.
Infrastructure Master – is responsible for updating user-to-group references between domains. This role should not be held on a domain controller which is also acting as a global catalog server – the infrastructure master will not function in this scenario because it holds a copy of all objects, and therefore has no external references. One domain controller per domain holds this role.

The ability to transfer roles is important, since a domain controller may need to be taken offline for maintenance. In this scenario, we simply transfer the role as will be described shortly. However, in the event that a DC holding an operations master role should crash, we might need to transfer the role by seizing it, a more drastic action. If you are taking a domain controller offline for a significant period of time, be sure to transfer the roles that the domain controller holds. Note that since changes to the schema and adding and removing domains are both rare, it may not be necessary to transfer these roles, even if a domain controller needed to be taken offline for a longer period of time.

Pages: 12

Active Directory Database Management

The Active Directory database is where all information relating to the directory is stored, including domain objects and attributes, schema, configuration, and global catalog information if applicable. As such, you must have an awareness of how the database works, as well as how it can be maintained. This includes knowing how to do a backup/restore, defragmentation, as well as how to move the database.

The Active Directory database is referred to as a transactional database, which means that every change to the database is treated as an individual transaction. The transactional nature of the database helps maintain integrity in the event of a failure. The Active Directory database is actually made up of a number of files that you need to be aware of:

Ntds.dit – this is the actual AD database file, where all objects are stored. By default you will find this file (and the others mentioned here) in the %systemroot%\NTDS folder.

Edb*.log – these files are transaction logs. Before any update is written to the database, it is first written to the transaction log. Each edb.log file is 10 MB in size. By default Windows 2000 uses circular logging, meaning that once full, the log file begins overwriting the oldest changes. If circular logging is turned off once the log files are full they are renamed ebdxxxxx.log, with xxxxx representing the number of the file starting at 00001.

Edb.chk – this is a checkpoint file, used by AD to track which changes have been written to ntds.dit. This is used for recovery purposes. For example, if a domain controller crashed and information had not yet been written to the database, the checkpoint file would server as the marker/pointer as to what from the log file still needs to be written to the database.

Res1.log and Res2.log – These are reserved log files, 10 MB each. Their purpose is to allow Active Directory to continue to log changes, in the event that all disk space in filled. As such, these 20 MB of files are actually just empty files reserving space, and are not used unless needed.

Remember from our earlier look at installing Active Directory that Microsoft recommends placing the log files and database on separate disks for best performance.

Pages: 123

Active Directory Replication

Windows 2000 implements replication much differently than Windows NT 4. In Windows NT domain environments, replication was single-master, meaning that only one domain controller actually accepted updates – the PDC. In Windows 2000, the model is multi-master, meaning that any domain controller can update Active Directory. This presents some challenges in terms of tracking changes on the network and resolving conflicts that might occur, as I’ll discuss in a moment. However, along with the challenges that Windows 2000 Active Directory replication presents, it also presents an opportunity in that replication can finally be easily controlled, through the use of sites, site links, and schedules.

I could easily have devoted this entire article to only replication, since there is so much that takes place behind the scenes. Thankfully, what is most important to understand is a handful of concepts (albeit a rather large handful), most of which are rather straightforward. Lets begin by taking a look at how replication works.

In an Active Directory environment, all domain controllers do not contact one central domain controller for changes. Instead, they create relationships with one another which track which domain controllers are sources of replication changes for them. These relationships are called connection objects, and I’ll discuss how they work and how they are created shortly. Since every domain controller can accept updates, there is actually a distinction as to which domain controller made the original update. This update is called the originating update. Any update that is received on a DC as a result of replication is referred to as a replicated update.

Pages: 123456

Active Directory Forests and Trust Relationships

As I outlined in previous articles, all domains within an Active Directory forest are capable of accessing one another due to the nature of the trust relationships that are automatically created. A transitive two-way trust relationship exists between every child domain and its parent domain, and transitive two-way trust relationships exist between the roots of all trees and the forest root. It should be noted that in some cases you will need to create additional trust relationships, both within and external to your forest.

For example, you might have a domain that is still running Windows NT 4, whose users you wish to be able to access a domain in your Active Directory structure. This would require an external trust, which is very similar to the trust relationships that you should be familiar with from NT 4. These trusts are one-way and intransitive, meaning that they can only be used to provide access to a single domain. In the scenario I described above, the trust relationship might look something like the diagram below:

Figure: Trust relationship with an external domain

In this particular example, users from the domain NT4DOMAIN would have access to resources in the asia.win2000trainer.com domain only. Of course, a two-way trust could be created between the two, allowing users from asia.win2000trainer.com access to resources in NT4DOMAIN. If users in NT4DOMAIN needed access to resources in all 3 of the win2000trainer.com domains, 3 trust relationships would need to be created at a minimum.

The tool used to create external trust relationships is Active Directory Domains and Trusts. This tool is used to create, manage, and verify trust relationships between domains. Note that the tools will show both internal and external trust relationships that exist. By accessing the properties of a domain, you can view the trust relationships that exist on the Trusts tab.

Note that the domain name, relationship (internal/external), and whether the relationship is transitive will appear on this screen. Note that like NT 4, for security purposes external trust relationship information must still be entered in both domains participating. Note that external trust relationships can connect a Windows 2000 domain with NT 4 domains, Windows 2000 domains (from different forests), as well Kerberos v.5 realms.

The second type of trust relationship that can be created is referred to as a shortcut trust relationship. This type of trust is created to shorten the path that needs to be followed for the purpose of authentication. For example, if I had a forest as shown below, getting to china.asia.2000trainers.com from europe.2000trainers.com would require crossing 3 trust relationships.

If users in europe.2000trainers.com did need to regularly access resources in china.asia.2000trainers.com, it might make sense to create a shortcut trust (as shown below) to lessen the number of trust relationships that would need to be traversed. Note that shortcut trusts are two-way transitive trusts, and that they are also created in Active Directory Domains and Trusts.

In order to verify trust relationships, you can use the edit button in Active Directory domain and trusts when a domain in the list is selected. This will attempt a secure channel query to the other domain, and will return results as to whether it was successfully able to verify the relationship or not. Further to this, another tool that you should be aware of for verifying trust relationships is Netdom.exe, a command-line utility that can be found in the Windows 2000 resource kit.

Active Directory Object Security

A great way to begin looking at object security in the Active Directory environment is with an overview of the different security elements that you must be familiar with. Many of the concepts covered here were first introduced in earlier articles, though with much less detail.

The first thing you’ll need to remember when taking a look at object security is the concept of a security principal. In most simple terms, a security principal is an account type to which permissions can be assigned. This includes users, security groups, or computer accounts, which are characterized by the fact that they have a security identifier (SID) assigned to them. Every security principal is assigned a SID, made up of a domain identifier (also referred to as a SID), and a relative identifier (RID), the combination of which uniquely identifies the principal.

When a user attempts to access a resource (such as another object in Active Directory) the applicable SIDs (for the user, groups he/she is a part of, and the associated computer account) are compared to the object’s access control list (ACL). The ACL lists who can access the object and to what extent.

ACLs for Active Directory objects (such as users, groups, computers, etc) are very similar to those you might already be familiar with, such as those associated with NTFS permission assignment. Note, however, that the actual permissions found in the list (called access control entries, or ACEs) can be very different depending on the object type.

There are two types of ACL that you should be aware of – discretionary access control lists (DALCs) and system access control lists (SACLs). A DACL is the list of permissions that security principals have on an object (as shown in the previous screen shot), while a SACL is the list of entries set up for auditing purposes on an object.

You should also be aware of the concept of an access token. The access token contains the user and group SIDs, and is created when a user logs on to the domain. This token is subsequently compared to ACLs whenever a user attempts to access a network resource. The token is created with information provided by the domain controller that authenticates the user (user SID as well as SIDs for domain local and global group membership) as well as a global catalog server (which provides universal group SIDs).

Publishing Resources in Active Directory

One of the benefits of Active Directory is that it is useful for more than just user authentication. As a store of information, Active Directory can be queried to find details about objects that we know about (such as a user’s telephone number), as well as to find objects that we perhaps didn’t know existed at all. Many objects are published in Active Directory by default, such as users, groups, and computers. However, it is also possible to publish information about other useful objects, most notably printers and shared folders. Once a resource has been published, the resource can be moved, and users will still be able to find it, as long as you update the shortcut to the object in Active Directory.

Let’s start with a look at printers. Printers are published automatically in Active Directory as long as they were created on a print server running Windows 2000. However, it is possible that you have a printer that is using a downlevel system as a print server, say Windows 98 or Windows NT. These can also be published to AD, either by using Active Directory Users and Computers, or by using the file pubprn.vbs found in the Windows 2000 system32 directory. Printers are published using their UNC path, in the format \\print_server\printer. The screen below shows a printer being published in AD Users and Computers.

The pubprn.vbs script needs to be run from the command prompt, using the cscript scripting host. The command needs to specify the container into which the printer(s) should be published, in LDAP format. The example below first shows a single printer being published into the printers OU, and then the command to have all printers from a print server published to the printers OU.

Cscript %systemroot%\system32\pubprn.vbs \\ntserver\hp4 “LDAP://OU=Printers, DC=2000trainers, DC=com”

Cscript %systemroot%\system32\pubprn.vbd ntserver “LDAP://OU=Printers, DC=2000trainers, DC=com”

Once the printer has been published, it is then possible for users to search for it in Active Directory, using the Search command from the Start menu. Note that the only printers that will be returned by a search are those to which the user has access.

Among the most useful features in the ability to search for a printer is the ability to search by location, according to the location listed on the properties of the printer itself. It is also worth noting that there is a very powerful option associated with locations called printer location tracking. In this setup the location field is automatically populated with the location name of the subnet where the user is located. Essentially subnets must be given location names (in AD Sites and Services, discussed below), printers must be given location names that correspond to their subnet location, and location tracking must be enabled in group policy. If these have been done, when a user tries to search for a printer, the location field will be populated with the name of the current location, based on the user’s subnet location. As such, the user would be presented with a list of printers which (in theory at least) should be close by. The screen shot below outlines the setting in group policy for printer location pre-population. The setting is found in \Computer Configuration\Administrative Templates\Printers.

In order for printer location tracking to work, all subnet objects must have an associated location. This is set in the properties of the subnet object in AD Sites and Services.

Location names follow the convention Name/Name/Name etc, where any name can be only 32 characters, and the maximum length for an entire location is 260 characters. It would be a very good idea to map out a location naming convention that makes sense and maps to the actual physical network topology. For example, in a multinational corporation with a presence in many countries might use the format:

Company/USA/Boston/Building 1/Floor 3

Company/Europe/Czech/Prague/HeadOffice

Just remember that location names correspond to IP subnets. Once enabled in policy, the printer search box changes to automatically include the location.

Shared folders can also be published in Active Directory in order to simplify the ability to find information. Any folder accessible by a UNC path can be published in Active Directory. To do this, in AD Users and Computers right click and choose New Shared Folder. Users can now browse for the folder in Active Directory, or a shortcut can be created to it. The UNC location of the folder can also be changed, by accessing the properties of the published folder, making it easy to change physical locations without affecting how users see resources. Just as importantly, you can also associate keywords with the folder (these are set in the properties of the published shared folder), which would allow users to search for it by those keywords. Searching by keyword is done by using the Find command in either AD Users and Computers, or by browsing to the AD domain in My Network Places, right clicking and choosing Find.

Note that the published object, like all objects in Active Directory, has a discretionary access control list (DACL) associated with it. As such, the permissions granted to the user via the published folder may differ from the NTFS or Share permissions set on the folder itself, which may restrict a user’s ability to access it with appropriate control. To view the permissions associated with the folder, remember that you will need to have the View – Advanced Features option selected in AD Users and Computers prior to accessing the object’s properties – this will allow you to view the DACL via the Security tab.