Cannot create domain trust relationship

When I tried to create a trust relationship from one Windows 2003 domain to another Windows 2003 domain. I got the following error:

The name you specified is not a valid windows domain name. Is the specified name a kerbores v5 relam.

Anyone has any idea what is wrong?
alan_w76Asked:
Who is Participating?
 
MSE-dwellsConnect With a Mentor Commented:
If domain A trusts domain B then the direction of access is actually that workstations in B access resources in A.  Stated another way, you've got clients in the DMZ requiring access to internal resources.  Is this correct?  If so, you're forced to open (the server) ports inbound from the DMZ ... as I said earlier, I believe this aspect of your solution perhaps needs a rethink since the DMZ's capabilities and purpose in life are not well served if you continue down this road.
0
 
MSE-dwellsCommented:
Name resolution of some kind is required.  Have you configured DNS on both sides such that the two domains are able to resolve one another.

In addition, are you entering the short (NetBIOS) name or the fully qualified DNS name?
0
 
Netman66Commented:
DNS is the issue.

Use Conditional Forwarding (on the Forwarder tab of DNS) to add the opposite domain so it will resolve.

0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
alan_w76Author Commented:
i tried both NetBIOS and FQDN. Conditional forwarding is configured on DNS server at each site. Still got the same error.
0
 
MSE-dwellsCommented:
Did you do that after the fact?  If so, the negative cache will be preventing you from moving forward but that'll age out shortly.

Have you verified that name resolution works via NSlookup or ...?
0
 
alan_w76Author Commented:
Also tried the STUB method, still no luck. NSLOOKUP against each domain returns good result. But, still I am getting this error. One domain is actually located in the DMZ, would that be problem? But, I was able to ping any machine to that domain by FQDN
0
 
MSE-dwellsCommented:
Can you verify port 135/tcp is open between the two domains -

portqry -n <target domain> -e 135 -p tcp

... do this on both sides.
0
 
alan_w76Author Commented:
the domain controller in the source domain has IP of 10.1.3.2.
the domain controller in the DMZ domain has IP of 10.0.16.11.

Command run from 10.1.3.2 succeeded. However, it says Name Resolved to 10.1.3.35. (I don't know why it said that. It should have said 10.0.16.11, right?)

Command run from 10.0.16,1 did succeed. It said TCP Port 135 Filtered.

0
 
MSE-dwellsCommented:
Filtered is not good in this context.  This (along with the name resolution oddity) is almost certainly what's preventing the trust from being established.  It's likely you'll encounter a number of other ports that also blocked.  A rethink is perhaps necessary before blindly opening them though (as I imagine you already know).

The following ports spring to mind for consideration -

135/tcp,88/udp/tcp,389/tcp,3268/tcp,53/udp/tcp,445/tcp (perhaps 137-139/tcp)
0
 
alan_w76Author Commented:
On 10.1.3.2, the result is below:

Name resolved to 10.0.16.11
TCP Port 135 (epmap service): NOT LISTENING

On 10.0.16.1, the result is below:

Name resolved to 10.1.3.3
TCP Port 135 (epmap service): FILTERED.

Does this mean the firewall before the DMZ is blocking traffic?

Thanks,
0
 
MSE-dwellsCommented:
It does if the name is being resolved correctly (but that's an important 'if').  A Windows Domain Controller is required to listen on 135 for a variety of reasons including remote admin and replication.
0
 
alan_w76Author Commented:
Why 10.0.16.11 is not listening on port 135? And what does FILTERED mean? I also tried port 389, got good result from 10.1.3.2, but FILTERED on 10.0.16.11 as well.
0
 
MSE-dwellsCommented:
You'll need to determine why the addresses coming back aren't as you expect because we may be seeing false-negatives.  The port 389 check does lend additional weight to the theory that these ports are blocked though.

Filtered indicates that portqry believes there to be a firewall between the two end points that does not permit a certain port across either or both udp and tcp (depends on what you tested).
0
 
alan_w76Author Commented:
Got this from Microsoft:
Client Port(s)                  Server Port               Service
1024-65535/TCP             135/TCP                    RPC
1024-65535/TCP             1024-65535/TCP      LSA RPC Services (*)
1024-65535/TCP/UDP  389/TCP/UDP             LDAP
1024-65535/TCP              636/TCP                    LDAP SSL
1024-65535/TCP              3268/TCP           LDAP GC
1024-65535/TCP              3269/TCP           LDAP GC SSL
53,1024-65535/TCP/UDP      53/TCP/UDP    DNS
1024-65535/TCP/UDP        88/TCP/UDP      Kerberos
1024-65535/TCP               445/TCP            SMB

Say Domain A is trusting Domain B and domain B is in DMZ. What ports should I open on the firewall, the client ports or the server ports if I only need to do a one-way trust.

0
 
alan_w76Author Commented:
It's just gonna be one time shot. What I am going to do is to use ADMT to copy some user accounts from Domain A to domain B. And after that, the trust will be removed. I was told that to use ADMT, you have to establish a interforest trust or external trust, correct?
0
 
MSE-dwellsCommented:
Nod, ADMT does indeed require a trust (and that's just one dependency among many).  If this is a one-time thing, then it all sounds good to me (assuming you remember to remove the trust after the fact ;0).
0
 
alan_w76Author Commented:
Thanks for all your support. So I should open above ports on the firewall to allow traffic flowing from Domain B DC to Domain A DC. I'll give it a shot.
0
 
MSE-dwellsCommented:
Nod ... I would mention though that Windows domain-related communication through firewalls has proven tedious in most of the scenarios with which I have first-hand experience.  That's not to say it didn't work out in the end; just that it was cumbersome.
0
All Courses

From novice to tech pro — start learning today.