Using the Security Descriptor Check Utility and NLTEST
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
Many Active Directory problems can be caused by failed replication. To help you to quickly diagnose and correct such problems, NLTEST contains a variety of replication-related functions. One such function allows you to query BDCs to check replication status:
If you discover that your backup domain controllers (BDCs) are out of sync with your primary domain controller (PDC), you can begin the replication process with a couple of different commands. For example, you can force a partial synchronization with the following command:
NLTEST /SERVER:servername /REPL
If you decide that forcing a full synchronization would be more appropriate, you can use this command:
NLTEST /SERVER:servername /SYNC
As you probably know, in a mixed-mode or a Windows NT 4.0 environment, replication begins with the PDC notifying the BDCs that a change has occurred. You can force such a notification with the following command:
NLTEST /SERVER:servername /PDC_REPL
Finding Other Information
Sometimes you just need to find out more information about objects on your network. NLTEST provides several useful commands for doing so. One such command will tell you which domain that a given machine belongs to. The syntax for this command is:
NLTEST /SERVER:servername /PARENTDOMAIN
Another useful NLTEST function displays information on user accounts. Just enter the following command:
NLTEST /SERVER:servername /USER:username
When you enter this command, you'll see an extensive summary of the user account's Active Directory information:
AccountExpires: ffffffff 7fffffff = 9/13/30828 21:48:05
SecurityDescriptor: 80140001 00000088 00000098 00000014 00000030 001c0002 00000
01 0014c002 01050044 00000101 01000000 00000000 00580002 00000003 00140000 0002
35b 00000101 01000000 00000000 00180000 000f07ff 00000201 05000000 00000020 000
0220 00240000 00020044 00000501 05000000 00000015 4862e393 36d67c9a 65d637a8 00
001f4 00000201 05000000 00000020 00000220 00000201 05000000 00000020 00000220
AdminComment: Built-in account for administering the computer/domain
Groups: 00000201 00000007
LmOwfPassword: b626bcf7 b28d3099 bb8d1f17 4269c913
NtOwfPassword: 38f98739 c4c67eb4 3d3ecf99 5e8fc7ce
As you can see, the NLTEST utility can be very useful. As I mentioned earlier, I've only scratched the tip of the iceberg in discussing NLTEST's capabilities. Of course, the best way to keep your Active Directory healthy is to use a combination of all of the tools I've discussed in this article series. Some tools are more suited to certain tasks than others. //
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.