So far in this article series, I've discussed a variety of GUI and command-line utilities that you can use to perform basic maintenance on the Active Directory. In this article, I'll continue the discussion by showing you a few more such utilities.
The Security Descriptor Check Utility
As you're no doubt aware, implementing security is one of the Active Directory's biggest responsibilities. However, because Windows 2000 has such an elaborate security scheme, it's easy for an Active Directory object to accidentally have the wrong permissions. For example, an object may inherit undesirable permissions from a parent object. Under normal circumstances, an undesired inheritance can be difficult to track down. However, a Windows 2000 command-line utility called the Security Descriptor Check Utility can make this process simple.
Using the Security Descriptor Check Utility is easy. Simply enter the utility's executable file name (SDCHECK.EXE) followed by the name of the server and the object you want to check. After entering this command, you'll be presented with a summary of the object's permissions, as described by the Access Control List. You'll also see what permissions are inherited from parent objects, along with the object hierarchy that's causing the inheritance.
The SDCHECK command has a few extra parameters that you can use to do things like specify an alternate username or enable verbose logging. To display a full summary of the Security Descriptor Check Utility's syntax, simply enter the command SDCHECK /?.
One of my personal favorite command-line utilities for interacting with the Active Directory is NLTEST. This tool can provide you with a wealth of information about Active Directory objects without requiring excessively complicated commands. With NLTEST, you can do things like get a list of your network's primary domain controllers, or test the condition of a trust relationship. You can also use this utility to check domain controller replication, force a remote shutdown, or acquire information on Active Directory objects, such as user accounts. One of the best things about NLTEST, though, is that many of its commands work well in mixed-mode, and in some cases even in Windows NT 4.0 environments.
Before I demonstrate the capabilities of NLTEST, I want to point out a couple of things. First, NLTEST works only on X86-based systems. Second, it would be easy to write a very lengthy article on NLTEST. Because space restrictions prevent me from discussing all of the intricacies of this utility, I'll limit my discussion to the most useful features. To see a summary of all of NLTEST's functions and the syntax for them, just enter NLTEST /? at the command prompt.
This command will display all the domain controllers within a given domain. The cool thing about this command is that it works on both Windows NT 4.0 domains and Windows 2000 domains.
NLTEST /SERVER:servername /DSGETSITE
This command will tell you which site a server belongs to. If you haven't defined a site structure yet, the command will report that the server is a member of the Default First Site Name.
NLTEST /SERVER:servername /DSGETDC:domain
Need to get some detailed information on your domain controllers? The /DSGETDC parameter will allow you to do just that. As you can see in the sample output, the /DSGETDC parameter provides you with information such as the domain's GUID, the name and IP address of the domain controllers, and the roles that those domain controllers play:
Dom Guid: 25bc4dc2-13c9-4f78-8a69-98e6804d5c56
Dom Name: POSEY
Forest Name: posey.com
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE