Using NetDOM to Control Name Suffix Routing in a Cross-Forest Trust

By using the NetDOM command's togglesuffix switch, you can disable all of the numbered items in Table 1 except for the Domain DNS name types (items 2 and 5). Note that every time you call the togglesuffix switch, the name suffix order will change. Therefore, always run the namesuffixes switch before toggling any additional values. For items 2 and 5, you must use the by AddTLNEX and RemoveTLNEX switches to add or remove the Domain DNS name types from the excluded domain list. To understand what these switches really do, I created Table 2, which maps each switch with its possible equivalent configuration in Active Directory Domains and Trusts, and I show the result of throwing each switch. For example, Table 2 shows that to disable the *.adatum.com name suffix, you type:

netdom trust fabrikam.com
  /namesuffixes:adatum.com
  /togglesuffix:1 

This command is equivalent to clicking the Disable button from the Name Suffix Routing tab of the forest Properties dialog box, as Figure 1 shows. You reach this dialog box from the properties of a forest appearing in the Active Directory Domains and Trusts MMC snap-in. It effectively disables all name-suffix routing from *.adatum .com and any domains below that, such as corp.adatum.com.

Although the previous example is important for a general understanding of name-suffix routing across a forest, more often you'll want to exclude a child domain from routing across a forest trust. I suggest that this scenario is more common because if you really don't want anyone from one forest authenticating to resources in another forest, you probably shouldn't create a forest trust in the first place.

Before looking for a scripting solution for making system changes, it's useful to know exactly what's being changed when you use the NetDOM command line tool, change the values graphically from the Name Suffix Routing tab in the Active Directory Domains and Trusts MMC snap-in, or click Edit to reach the Edit dialog box that Figure 2 shows.

The first place to look for AD changes is in the various directory partitions in an AD implementation. You can accomplish this task by using a tool that searches AD for changes between two points in time: before a change was made and right after. You can create a program that uses the DirSync control LDAP server extension or a program that performs USN queries against a directory. You can read about these approaches in the Microsoft article "How to poll for object attribute changes in Active Directory on Windows 2000 and Windows Server 2003" at http://support.microsoft.com/?kbid=891995. You could write a script that searches all uSNChanged attributes of every object in a directory, but some important limitations are associated with this approach, including the length of time it would take for a script to perform this type of intensive search operation. The Microsoft article also outlines other important considerations. In addition, I wrote a MSDN Magazine article about leveraging the DirSync control, "Got Directory Services? New Ways to Manage Active Directory using the .NET Framework 2.0" (http://msdn.microsoft.com/msdnmag/issues/05/12/DirectoryServices/default.aspx). You could modify the source code included with that article to perform DirSync operations against any location in AD.

After exploring how to poll AD for changes, it turns out that enabling or disabling name suffix routing doesn't change attributes in AD. The next obvious place to look, then, is in the registry. SysInternals' RegMon tool is a great way to poll for registry activity such as value modifications. By running RegMon and enabling or disabling name suffix routing, you'll see that you are actually making several changes in the registry. When name suffix routing is toggled, it calls the lsass process to set security policy in the HKEY_LOCAL_MACHINE\SECURITY\Policy\PolMod registry key and it logs the change in the HKEY_LOCAL _MACHINE\SECURITY\RXACT\Log registry key. The lsass process (also known as the Local Security Authority or LSA Shell), manages local security, domain authentication and some aspects of an AD configuration on domain controllers. Both of these registry keys contain default values of type REG_NONE and they store binary data. Scripting registry changes to these keys would be difficult—or even impossible.

Although you could call Netdom from WScript or a batch file, it's not necessary to do so. The Netdom switches I've explored here let you control routing for all domains and sub-domains. In addition, such an operation isn't common. You might run it after you have set up a forest trust or after additional domains have been added to an existing forest trust. Both activities are relatively infrequent in most AD implementations. If you do find a good reason to script this command, you can do so easily from a shell script by simply calling the Netdom command and passing the domain name or suffix number in as a parameter on the command line. If you want to accomplish this task in VBScript, read Bob Wells' Rem article "Running a Command-Line Utility in VBScript" (http://www.windowsitpro.com/windowsscripting, Instant-Doc ID 25285).