NT4 Trust Hell (how to fix!)

So I just spent the better part of about three hours hassling to setup a two way trust between a 2k3 domain and a NT4 domain. First I had to write a batch script and smb it onto the PDC to psexec from a remote console since my domain admin account on there was somehow denied like every right interactively in some good old NT4 system policy. So I magic’ed up a batch script to make myself a good account on there:


net user bcdesmond MyPass /add /domain
net group “Domain Admins” bcdesmond /add /domain


That did the trick of course the box had like 2MB of free disk when I logged on, and I spent 45 minutes wondering what was wrong with it before I realized it was time to make room on the 2GB C drive. I freed up 60MB. Time to make a trust. So, of course like many enterprises, I have DCs spread all over the place and the WAN isn’t fully routed (well it is, but we drop Microsoft ports (aka 135, 137, 139, 445, etc) between satellites. So I fired up usrmgr in NT4 and headed into Policies to make my trust. Punch in the remote domain and the password. Just hangs. Great ok must be a name resolution problem, bust out notepad and pull up lmhosts in c:\winnt\system32\drivers\etc and punch in some records:


10.10.10.11 COREDC1 #PRE #DOM:COREDOM
10.10.10.12 COREDC2 #PRE #DOM:COREDOM


and then nbtstat -R (flag case sensitive!), must be good to go, so I fire up task manager over my VNC console and kill usrmgr, great good to go this will be a breeze, get my remote domain name and trust password punched in, lookin good CPUs doing something (only one chipmunk in this old POS), give it a few, damn it’s hung again. So, off I go to my core domain DCs and punch some lmhosts and hosts records in there in the same fashion:


10.20.10.11 REMOTEPDC #PRE #DOM:REMOTEDOM


nbtstat -R and an ipconfig /flushdns and I’ve just got to be set. What else could go wrong? It’s like midnight and then some this should have been done like 90 minutes ago. So, I go rinse and repeat on the kill usrmgr and setup the trust. Of course it doesn’t work. At this point I’ve wasted a ton of time screwing around with all sorts of irrelevant crap taking traces here and there not really seeing anything valuable, so, I decide to load ethereal on the remote DC and say a prayer libpcap doesn’t blow NT’s network stack to hell, because then I’m totally screwed.


So, I get Ethereal downloaded to my desktop on here over the combination slow Ethereal mirror and slow T1. Get that installer fired up low and behold ethereal needs nearly 60MB of disk! I don’t have 60MB to give especially after I just forked over 12 for the compressed installer, and my profile and temporary Internet files. So I see I’ve got some free space on D, I’ll just install ethereal there. Great, good, in business. Then, the installer hangs at the libpcap install, just what I feared – keep tapping on the keyboard in a notepad session waiting for notepad to stop refreshing as the box explodes somewhere on the west side. It doesn’t, so after I close 19 explorer windows (remember NT4 likes to pop up a new windows explorer for every single directory?), I find an error message from libpcap – apparently it tried to install libpcap on C even though I said D for Ethereal. I just don’t have space C. So, kill the ethereal install, and go Googling on my management station for libpcap (I can’t browse the internet on the NT4 PDC – it’s crawling with adware), and I find a download link, of course copy and paste to VNC is just hosed so I key it into the run dialog, install to D, then I rerun the Ethereal setup making sure to install to D and not load libpcap. 5 minutes later it’s done, and wow I don’t have to reboot. That’s just short of an act of god on NT4.


At this point, I’ve got Ethereal fired up and a “not tcp.port==5900” in there and I’m ready to go for round 5 million in usrmgr to set this damn trust up. It’s got to be 1 AM at this point and I still don’t have what I think is a trivial task complete, no less milestone 1 on this project. Got the trace taken usrmgr is hanging and all and I start reading through it, it’s trying to setup a session with the DC I put in LMHosts. Perfect. It’s trying to do so anonymously, I gave it a trust password, but, whatever, I really don’t remember how this is supposed to work, and frankly I don’t care at this point. So I see it successfully setting up a session, but it’s still hanging. Scroll down a bit and suddenly this NT4 POS has decided to talk to a 2k3 DC for this central domain on the far southwest side – several router hops and one or two sets of drop ACLs away. So, at this point I’ve identified my problem, but I have no solution. netdom and nltest from the NT4 reskit are like so primitive they’re useless. Netdom trust is totally missing. I’m not even going to hassle with getting a 2k3 copy of netdom out to this box it probably won’t run, so I start looking at my remote possibilities.


Low and behold netdom trust works remotely from a 2k3 box. So, I hop on to the core DC and dump netdom trust help to my second monitor and start figuring out what I want to do, this one is a little confusing with the trusting and trusted domain stuff. Fortunately I know the common netdom switches like the various /user? (d, f, o, a, etc) since I write scripts with it all the time. Little bit of tinkering and I got two working commands to do the two way trust:


This sets up the trust from the remote domain to the core domain (what the remote domain calls a trusted domain)


netdom trust CRAPPYNT4DOM /domain:COREDOMAIN /add /oneside trusting /passwordt:!TrustPass1 /userCRAPPYNT4DOM\administrator /password!Password1


This sets up the trust from the core domain to the remote domain (what the remote domain calls a trusting domain)

netdom trust COREDOMAIN /domain:CRAPPYNT4DOM /add /oneside trusted /passwordt:!TrustPass1 /userd:CRAPPYNT4DOM\administrator /passwordd:!Password1



The netdom trust command will actually do the operations on the COREDOMAIN but, I chose to just use the wizard in AD Domains & Trusts and not confirm anything. Supposedly that wizard is supposed to create the remote components as well, but it was failing or I never would have had this fiasco. Moral of the story, netdom is your friend, and it can do a ton more stuff than this, so you might as well learn about it if you haven’t already. A good portion of my domain migration tools I write are netdom based. nltest is also helpful in this type of situation quite often (it can do things like reset trust secure channels).


I made up the names and IPs, can’t post those here, and nor can I post my trace that would have illustrated this problem so use your imagination for those parts.

Share this post: email it! | digg it! | bookmark it! | live it!

Leave a Reply

Your email address will not be published. Required fields are marked *