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

I support a large Windows Server 2003 Active Directory (AD) forest that contains several forest trusts that in turn contain other large forests. Can I use a script to control (enable and disable) routing name suffixes across my large forest?
Before answering this question, I think it's useful to explain this somewhat obscure Active Directory Forest trust setting and point you to references for more information. When a user in an account domain (trusted domain) attempts to authenticate across a forest trust, AD routes the request to a resource domain (trusting domain) that's capable of authenticating the user's request. You can disable or enable this routing graphically from Active Directory Domains and Trusts, from the command line by using the NetDOM utility (a Windows Support Tool), or programmatically by using the new System.DirectoryServices. ActiveDirectory namespace in the .NET Framework 2.0. To see how this functionality works, consider the two types of canonical names for user account authentication: a Domain DNS name (e.g., corp.adatum.com) and a NetBIOS name (e.g., CORP).

Assuming both name examples I provide represent a domain named corp.adatum.com in the adatum.com forest and a user account named john.doe exists in corp.adatum.com, then john.doe can log on to the local account domain with either of the following names: [email protected] or CORPjohn.doe.

If the fabrikam.com forest trusts the adatum.com forest and john.doe has been given access to a folder on a resource server in the fabrikam.com domain, then john.doe in the corp .adatum.com domain can authenticate across the forest trust and access the folder in the fabrikam.com domain.

To block all users in corp.adatum .com (including john.doe) from authenticating to any resource in the fabrikam.com domain, an enterprise administrator in the fabrikam.com forest can exclude the corp.adatum.com domain from the forest trust. Because trust relationships are confusing enough, here's a generalized explanation of the pattern:

Later in this answer, I describe two ways to complete this name-suffix exclusion task, one graphically and the other from the command line. If you want to know how to perform this task from managed code, see my Microsoft white paper "A Developer's Introduction to System. DirectoryServices.ActiveDirectory." As of this writing it hasn't yet been published. However, it should be published around the same time as this article. In addition, you can learn more about name suffix routing by reading Jan De Clercq's Windows IT Security article "Windows 2003 Forest Trusts " (http://www.windowsitpro.com, Instant-Doc ID 38436) and the Microsoft article "Accessing Resources Across Forests" at http://technet2.microsoft.com/WindowsServer/f/?en/library/517b4fa 4-5266-419c-9791-6fb56fabb85e10 33.mspx. You can also refer to the topic "Routing name suffixes across a forest" in the Windows Server 2003 Active Directory Help documentation.

Now that you're more familiar with name suffix routing, let's talk about how to configure this setting from the command line. You can use the Netdom command-line tool to enable or disable forest-name suffix routing, exclude top-level domain-name routing, or disable specific name-suffix routing. For a variety of examples using the Netdom command line, see the Microsoft article "Netdom Examples" at http://technet2.microsoft.com/WindowsServer/en/library/539c5381-db4f-445f-aac0-2df5448181c11033.mspx?mfr=true.

By using the Netdom commandline tool, you can list and manage the name suffixes allowed for cross-forest authentication. For example, to see the status of all name suffixes between the fabrikam.com forest and the adatum.com forest, type:

netdom trust fabrikam.com  /namesuffixes:adatum.com 

Note that you should list name suffixes from the forest that contains the resource domains because you control name-suffix routing from the outgoing side of a forest trust (the trusting forest).

If you created a cross-forest trust between fabrikam.com and adatum .com, and adatum.com also contained a sub-domain named corp.adatum .com, then you would see return results similar to those in Table 1. I put the results in table format to make it easier to delineate one column from the next. Obviously, SID values will differ between one AD implementation and the next.

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_MACHINESECURITYPolicyPolMod registry key and it logs the change in the HKEY_LOCAL _MACHINESECURITYRXACTLog 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).