Active Directory Services is the going standard for account provisioning, basic system management, and DNS authority in most environments. But having some accountability to determine what has changed over time can be a challenge. Here are some strategies for achieving accountability in your Active Directory environment. They'll help supplement your existing strategies, give you an extra dimension for testing, and provide a strong set of data to determine what has changed when you're troubleshooting issues.
Note: This information is also available as a PDF download.
#1: Export with CSVDE
Many Active Directory (AD) tools can be used at various levels to gather information about the current state. CSVDE is a favorite of mine because it is relatively quick and can be iterated through a scheduled task and the output is workable in Excel. I export certain organizational units (OUs) monthly as a record of the membership of user accounts. With this record, I can see what has changed in diagnosing issues that initially may not make much sense. This is especially helpful with a large AD environment.
#2: Copy for the quick test
I have had great success copying users to temporary user accounts to test permissions within Active Directory. This makes one key assumption that most, if not all, permissions are assigned via group membership. When group membership is the main mechanism for deploying access, copying users to test access in roles like service accounts, task accounts, and other restrictive operations, the copied user account is a quick and easy way to test without affecting the user in question. Be sure to perform the requisite housecleaning and remove the copied accounts.
#3: Have a copy of the domain available for testing
Core changes to an Active Directory installation are difficult to test and simulate. A development domain is good, but usually not configured exactly as in use on the live domain. Having a domain for testing that is exactly like your live domain makes testing schema extensions, Group Policy changes, and new security polices a breeze.
There are two principle ways to get this test environment created. The first is to create a new domain controller in the domain, then move it to a test network. Once in the test network, remove the domain controller from the live domain. When it is in the test network, the other domain controllers won't be available, but if it has all of the requisite roles, it can process logon requests and be the test environment for the changes or policies in question. The other strategy is to use a system conversion tool, such as Symantec BackupExec System Recovery, Symantec Ghost, Acronis True Image, VMware Converter, or PlateSpin PowerConvert, to take a snapshot of the domain controller in varyious ways and transport it to a physical or virtual test environment.
#4: LDIFDE for the whole thing!
The LDIFDE export tool can be helpful to move the entire domain out and have it available for importing. I would not recommend this as a backup and restore mechanism. But to create an exact replica of the live domain as described above, the LDIFDE tool can be the vehicle to export your domain to the test environment and keep it up to date. My issue with test domains is that they stray from the live environment, and keeping them current is important. You can export your entire domain as is with this easy one-liner:
LDIFDE -f C:domain-out.file
LDIFDE can interpret this file in an import, and it's readable in a text editor. It's easy to blur the differences between LDIFDE and CSVDE when you read their descriptions, but I like CSVDE because you can export by a particular organizational unit (OU). This is handy, as LDIFDE will take the entire directory, which includes user accounts as well as printers, computer accounts, domain controllers, and other Active Directory objects. LDIFDE will tend to have a larger export file because of its scope.
#5: Save queries in Active DirectoryDon't we all breeze right through this first option of Active Directory Users And Computers? Having a saved query can help administrators repeat mundane tasks and easily detect policy violations. I frequently run queries for disabled user accounts that have not logged in within 60 days. Figure A shows this query.
An AD query result set is a list of objects that meet the selected criteria. With this set, you can perform large scale account operations, such as deleting accounts, adding a group, moving to an account, and enabling or disabling an account. You can also perform mass operations on Exchange accounts from the results of a query. This TechRepublic blog post explains how to create and save an AD query.
#6: Use DSGET for AD object details
While CSVDE and LDIFDE are good for large collections of data, the DSGET command is the detail-oriented alternative. DSGET is the object tool for the Active Directory service command series, including DSADD, DSQUERY, DSMOVE, DSRM, and DSMOD. DSGET fits well in the space of documenting and benchmarking your AD installation because you can get information specifically for objects within the domain. Each object type in the directory is available to run from DSGET. You may find yourself wanting to use DSQUERY in conjunction with DSGET to save the hassle of working with the directory distinguished names.
#7: Export Group Policy objects
Managing Group Policy objects in AD is a challenging feat as well. How difficult is it to determine an issue with a complicated Group Policy? Exporting the Group Policy is a way to benchmark the configuration from a point in time. The Windows Resource Kit tool ADMX.EXE allows for an export of Group Policy objects from AD for archival and comparison purposes.
#8: Export your AD-integrated DNS zone
If your IP addressing is managed or tracked within Active Directory, you can export the zone that contains your domain systems. This will enable you to see how the addresses are used and where your domain systems are addressed across all networks in the domain. The DNSCMD command is the best utility to perform this export. The command to export a DNS zone for the sample WS2K3DEV.LOCAL zone from the DC001 server would be:
DNSCMD DC001 /zoneprint WS2K3DEV.LOCAL
You can optionally direct the command to a file for the archival. While you can also use DNSCMD for importing and modifications, the output functionality is very useful in the course of benchmarking the AD environment. The relevant output from this command is about the third line from the bottom. The output for individual systems and their addressing (in the form of DNS A records) is shown below:
DC001 [Aging:3569020] 3600 A 192.168.1.100
#9: Document with ADFind.exe
ADFind.exe provides a great way to take a quick snapshot outside Active Directory Users And Computers and outside of normal administrative rights situations. ADFind does not require special domain privileges or permissions through the Delegation Of Control wizard. So you can comfortably have your AD environment documented by computer operators, temporary employees, junior administrators, or anyone else whom you are not 100 percent comfortable giving additional rights.
Using ADFind is a little different than using the normal tools, as it is not a Microsoft tool. But a quick jog through the usage section of the Joeware Web site will have you making queries in no time at all. Here is an example I performed on a test domain (WS2K3DEV.LOCAL):
adfind -b dc=WS2K3DEV,DC=LOCAL -f "objectcategory=computer"
All computer accounts are returned, and they have a format like the following sample result:
>operatingSystem: Windows Server 2003
>operatingSystemVersion: 5.2 (3790)
>operatingSystemServicePack: Service Pack 2
>dSCorePropagationData: 20071109010838.0Z>dSCorePropagationData: 16010108151056.0Z
As with any good tool or procedure, I recommend learning the ropes in a test environment. While it is generally a query and lookup tool, you want to be sure of any load placed on your domain controllers for big queries or exports. Using these tools in a test environment first can ensure no surprises while running in the live domain.
#10: Minimize security group sprawl
We all agree that assigning permissions via group membership is the best practice for most situations. However, having too many groups in your AD environment poses a management challenge of its own. I have found it useful to determine which groups have either no members or very few members and to consider removal or consolidation. I generally do this with the CSVDE command within the organizational unit that contains the groups in question for a quick view of the membership inventory. In this fashion, the lesser groups will pave the way for simpler administration.
How do you benchmark your Active Directory environment for a look into the past? That can be the best indicator of the future use and needs as well as great troubleshooting for something that used to work. Many of the points above can be run as a scheduled task for automated documentation. Share the strategies your have implemented in your environment.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.