NETDOM

Anyone who manages a large network knows that although Windows NT provides a broad suite of administrative tools, the tools' GUIs can be a pain. The fact that User Manager for Domains is a GUI tool is wonderful for first-time administrators, because they can leverage skills they learned playing Solitaire when they maintain their network. But User Manager for Domains isn't fit for administering hundreds of user accounts because you can't automate the tool's functions.

One administrative function that has always been difficult to automate is fixing broken trusts. However, the NETDOM utility in Microsoft Windows NT Server 4.0 Resource Kit, Supplement Two can maintain trust relationships. NETDOM lets you build new trust relationships and reset existing trusts from the command line.

Think about how you build trust relationships without NETDOM. Suppose your network contains two domains—TRUSTED and TRUSTING—and you want to create a trust relationship that makes TRUSTING trust TRUSTED. To create this trust, you need an administrative account in the TRUSTING and TRUSTED domains. Log on to a TRUSTING domain controller with your TRUSTING administrative account, and log on to a TRUSTED domain controller with your TRUSTED administrative account. Then, fire up User Manager for Domains, point the tool at the TRUSTED domain, and tell User Manager for Domains that TRUSTING can trust TRUSTED. Refocus User Manager for Domains on the TRUSTING domain, and NT sets TRUSTING to trust TRUSTED. Whew!

NETDOM's approach is easier. Like User Manager for Domains, NETDOM requires you to have two administrative accounts, one in TRUSTED and one in TRUSTING. NETDOM sometimes becomes confused if your username in TRUSTED is the same as your username in TRUSTING and the two accounts have different passwords. I recommend using different account names in the two domains or using accounts with identical names and identical passwords.

NETDOM accepts the username and password for your TRUSTING account but not for your TRUSTED account—I'm not sure why NETDOM has this discrepancy. However, you can use the old NET USE ... IPC$ trick to establish your credentials in the TRUSTED domain. Just type

net use \\<name_of_PDC_in_TRUSTED_domain>\IPC$ /user:TRUSTED\<your_username>

Or you can run NETDOM from a domain administrator account in TRUSTED, in which case you don't need to use NET USE to connect to the IPC$ share.

Suppose the name of your administrative account in TRUSTING is admin and the account's password is swordfish. If you're logged on as a TRUSTED administrator, you make TRUSTING trust TRUSTED by typing

netdom /domain:TRUSTING /user:TRUSTING\admin /password:swordfish master TRUSTED /trust

That's a long command line; it boils down to

netdom <info_about_the_trusting_domain> master <name_of_the_trusted_domain> /trust

You might be thinking, "So what? I rarely build trusts." Remember that you can run NETDOM to do more than just build trust relationships; you can use the utility to rebuild trust relationships. If you come to work one morning and find domain controllers complaining that they can't establish a link with a trusted domain, what do you do? Until now, your best option was to reboot the domain controller—not a great answer for a production server. Your worst option was to rebuild the trust relationship. Now, NETDOM offers a better solution than either of those: Run NETDOM /trust to rebuild an existing trust relationship in a flash. As a bonus, NETDOM breaks trust relationships, too. For example, type

netdom /domain:TRUSTING /user:TRUSTING\admin /password:swordfish master TRUSTED /delete

In a future column, I'll look at some of NETDOM's other functions. But don't wait to play around with NETDOM.