Trust between NT domain and W2k domain -- "Access is denied"

jabo210 used Ask the Experts™
I have been unable to setup a trust between my NT domain and my new W2k domain, in preparation for migrating the old domain to the new (with ADMT).

The NT PDC (NT 4 SP 6a) and ping the W2k DC (W2k SP3), as well as access any shared folders, via Network Neighborhood (or even via IE).  Likewise, the W2k DC can access the NT PDC -- only noticeable difference is speed: the NT PDC is slow in accessing any other machine (regardless of domain or OS) on the network.

LMHOSTS files have the 1b  and 1c records for the other machine and domain.  


1. When attemtpting to set up either Trusted or Trusting relationship from the NT machine, "Access is Denied."

2.  W2k cannot verify any trust setup from its side.  "Secure channel reset (SC) on domain controller \\NTPDC on domain NTDOMAIN to domain W2KDOMAIN failed with error: The specified domain either does not exist or could not be contacted."

3. When testing migration settings in AD Migration Tool, ADMT returns: "You are not an administrator on the source domain. (domain=NTDOMAIN)."

No Failure Audits show up in the Security log after attempting to setup the trust in NT.

What do I do now?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
You have to upgrade the NT4 machine to 2k.

What your trying to do simply cannot be done!


Why not?  MS has a tool called Active Directory Migration Tool (see KB 260871) which is specifically designed to migrate users from a NT domain to a W2k domain.  It requires a trust relationship between the two domains.

I misread your question - sorry!. I thought you were trying to join the win2k server onto the existing nt4 domain.

Maybe your answer lies within the migration tool features?

goold luck.
Become a CompTIA Certified Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

Top Expert 2007
Also :

 How do I establish a trust across a firewall? netbios ports  TCPIP pports port needed to share

 You need to enable the following ports:

    PORT 135 (TCP or UDP) for the Remote Procedure Call (RPC) Service.
    PORT 137 (UDP) for the NetBIOS Name Service.
    PORT 138 (UDP) for NetBIOS datagram (Browsing).
    PORT 139 (TCP) for NetBIOS session (NET USE).
    ALL PORTS above 1024 for RPC Communication.

 See tip 0956 for using LMHOSTS for name resolution.

 NOTE: You would have multple IP_ADDRESS_OF_PDC PDCname #PRE #DOM:DomainName entries.

 If you use DNS and WINS, enable:

    PORT 53 (TCP and UDP) for DNS. DNS port
    PORT 42 (TCP and UDP) for WINS Replication. WINS port

 If you establish the trust through PPTP, enable:

    PORT (TCP) 1723 for PPTP.

 For SMS Remote Helpdesk, enable:

    PORT (TCP) 1761 for Verification of Rights (IPX 0x8138).
    PORT (TCP) 1762 for Remote Control (IPX 0x8238).
    PORT (TCP) 1761 for Remote Reboot (IPX 0x8138).
    PORT (TCP) 1763 for Remote Chat (IPX 0x845F).
    PORT (TCP) 1764 for File Transfer (IPX 0x4100).
    PORT (TCP) 1761 for Remote Execute (IPX 0x8138).

 Use NOTEPAD to read %SystemRoot%\System32\Drivers\Etc\Services for a more complete list.

Setting up trust relationship thru the Internet
From: lrmoore              Date: Wednesday, October 18 2000 - 11:37PM EDT

                     Setup PPTP on one server, then connect via DUN from the other side, and enable IP routing on the PPTP server...Once this secure channel is in
                     place, you should have full visibility from both sides to create your trust relationship. Be sure that you have LMHOST file on both sides with the other  domain's hosts, and/or WINS servers..
                     There are other alternatives such as IPSEC tunnels between routers at each site, or between firewalls at each site, but these will cost money.

Title: Domain Trusts in NT4
From: Deathshadow
Date: 11/11/2002 09:50AM PST
Here is the situation. I have a 2 way trust running with another domain, but the people on the other end messed with the passwords and such. What I did was remove the trusts and was going to re-set them back up but here is the problem, when I type in the domain name I get this error "The Account Already Exists". It only does it with this domain, I am able to add anything else and it takes fine. Any ideas?  
Question History
Comment from Blikkenman  11/11/2002 11:45AM PST  
Probally you now have a mismatch in password?
Or did you and the other domain changed the password both?

Look also in WINS for the domain record (IP of other domain)
[1Ch] indicates the domain name..

Comment from Deathshadow  11/11/2002 11:48AM PST  
I ended up finding the solution. WinNT4 creates hidden user accounts that are associated with the trust i.e. <trust$>. Since this is hidden it will not show up in user manager. Basically, when I tried to set the trust up, it tried to create that account but it was already there. I ended up using a program called Hyena to search out the hidden user and then deleted it. Everything worked well after that.  
Comment from Blikkenman  11/11/2002 11:55AM PST  
Great good to know,
I myself using Dameware NT Utils same sort of program as Hyena.


I hope this helps !

This shows the steps required. You can follow the link if you like or read it below;en-us;260871

HOW TO: Set Up ADMT for Windows NT 4.0 to Windows 2000 Migration
The information in this article applies to:
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server

This article was previously published under Q260871

Administrative Shares
User Rights

IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

You can use the Active Directory Migration tool (ADMT) to migrate users, groups, and computers from one domain to another. This article describes how to perform a migration from a Microsoft Windows NT 4.0-based domain to a Windows 2000-based domain.

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

NOTE: This article assumes that the source domain is running Windows NT 4.0 Service Pack 4 or later, and that the target domain is a Windows 2000-based domain in Native mode.

You should run ADMT from the primary domain controller (PDC) that is the Flexible Single Master Operation (FSMO) role holder in the target domain.

back to the top
Configure the source domain to trust the target domain.
Configure the target domain to trust the source domain.

back to the top
Add the Domain Admins global group from the source domain to the Administrators local group in the target domain.
Add the Domain Admins global group from the target domain to the Administrators local group in the source domain.
Create a new local group in the source domain called Source Domain$$$ (this group should have no members).

back to the top
Enable auditing for the success and failure of user and group management on the source domain.
Enable auditing for the success and failure of Audit account management on the target domain in the Default Domain Controllers policy.

back to the top
On the PDC in the source domain, add the TcpipClientSupport:REG_DWORD:0x1 value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA.

back to the top
Administrative Shares
Administrative shares must exist on the domain controller (DC) in the target domain on which you run ADMT, as well as on any computers on which an agent will be dispatched.

back to the top
User Rights
You must log on to the computer on which you run ADMT with an account that has the following rights:
Domain Administrator rights in the target domain
Is a member of the Administrators group in the source domain
Administrator rights on each computer you migrate
Administrator rights on each computer on which you translate security
Therefore, logging into the PDC that is the FSMO role holder in the target domain with the source domain\Administrator account suffices, assuming that the source domain\Domain Administrators group belongs to each computer's Administrators group.


As you can see from the KB on the ADMT, one must have the TRUSTS setup to use ADMT.  The TRUSTS are the problem, not ADMT.


At this point, I have decided to migrate using Exmerge to export all my users' mailboxes and personal folders and then import them into Exchange 2000 server, after setting up the users in Active Directory.

It is not the ideal solution, but since we have only a few users, it will suffice.
did you add the following entry in the registry of your pdc? You also must reboot after adding the entry.
On the PDC in the source domain, add the TcpipClientSupport:REG_DWORD:0x1 value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA.

Sorry I didn't pay that much attention to the KB article sequence of events. I have done this several times in our lab and I always have created the trusts as the last step.

This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
Post your closing recommendations!  No comment means you don't care.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial