I am trying to create a forest trust between a Server 2008 and Server 2003 domain controller. If I create the trust, then the trust will show up in the Trusts tab on the domain properties of AD Domains and Trusts on both DC's. But when the trust is verified during the trust creation wizard I always get the error below. Regardless of the domain controller from which I attempt to create the trust. ------ The verification of the incoming trust failed with the following error(s): The trust password verification test was inconclusive. A secure channel reset will be attempted. The secure channel reset failed with error 1311: There are currently no logon servers available to service the logon request. The verification of the outgoing trust failed with the following error(s): The trust password verification test was inconclusive. A secure channel reset will be attempted. The secure channel reset failed with error 1311: There are currently no logon servers available to service the logon request. ------ Details: Server 1: - Server 2008 x64 - Domain: domein.local - Server FQDN: dc.domein.local - IP: 192.168.20.210 / 255.255.255.0 Server 2: - Server 2003 R2 - Domain: rollen.local - Server FQDN: dc.rollen.local - IP: 192.168.0.2 / 255.255.255.0 AD Topology A single DC is installed in each forest. Each forest contains only 1 domain. Both domains and forests are on the "Windows Server 2003" functionality level. Firewalls, networking and DNS The firewalls are disabled on both DC's. The subnets are connected using a routed VPN tunnel. I have tried creating a trust using both a CISCO-FORTIGATE router to router tunnel, and an OpenVPN tunnel. The error appears with both tunnels. DC's can ping each other. No WINS servers are installed on either of the forests. DC.domein.local has a secondary DNS server for the domein.local and _msdcs.domein.local zones which runs on a non-DC server 2008 installation in "Secondary Zone" mode (non-AD). These DNS zones are synchronized with DC. DC's can resolve each other's domain names and the FQDN's of the DC's/clients within the respective domain names. I have tried the following DNS configurations: Conditional forwarding, Secondary zone, Stub zone. Trust creation fails with each of these configuration options. I have tried waiting a night or two to make sure all DNS changes are propagated to the respective zones / secondary DNS servers. A PortQryUI test from dc.rollen.local to dc.domein.local shows the following non 0x00000000 codes: Sending LDAP query to UDP port 389... LDAP query to port 389 failed. Server did not respond to LDAP query portqry.exe -n 192.168.20.210 -e 389 -p BOTH exits with return code 0x00000001. * TCP port 389 does however work and show results. TCP port 88 (kerberos service): LISTENING UDP port 88 (kerberos service): LISTENING or FILTERED portqry.exe -n 192.168.20.210 -e 88 -p BOTH exits with return code 0x00000002. UDP port 138 (netbios-dgm service): LISTENING or FILTERED portqry.exe -n 192.168.20.210 -e 138 -p UDP exits with return code 0x00000002. TCP port 42 (nameserver service): NOT LISTENING portqry.exe -n 192.168.20.210 -e 42 -p TCP exits with return code 0x00000001. I get the same results if I run the PortQryUI tool on dc.domein.local to it's local 192.168.20.210 IP. A PortQryUI test from dc.domein.local to dc.rollen.local shows the following non 0x00000000 codes: TCP port 88 (kerberos service): LISTENING UDP port 88 (kerberos service): LISTENING or FILTERED portqry.exe -n dc.rollen.local -e 88 -p BOTH exits with return code 0x00000002. UDP port 138 (netbios-dgm service): LISTENING or FILTERED portqry.exe -n dc.rollen.local -e 138 -p UDP exits with return code 0x00000002. TCP port 42 (nameserver service): NOT LISTENING portqry.exe -n dc.rollen.local -e 42 -p TCP exits with return code 0x00000001. I get the same results if I run the PortQryUI tool on dc.rollen.local to it's local 192.168.0.2 IP. DCDiag results from dc.domein.local DCDiag on dc.domein.local 2008 server passes all tests but the NCSecDesc test which I believe tests readyness for ReadOnly DC's. Furthermore the following eventlog error is showed: "No suitable default server credential exists on this system. This will prevent server applications that expect to make use of the system default credentials from accepting SSL connections." (EventID: 0x80009008) Could this be what's causing my problem? I googled this error and other sites tell me I can safely ignore this if there is no Enterprise CA is configured in my organization. ( http://support.microsoft.com/?kbid=261196 ) DCDiag /test:dns on dc.domein.local shows a warning that no AAAA records have been configured. IPV6 is however disabled on the NIC so I guess that makes sense. DCDiag results from dc.rollen.local DCDiag on the dc.rollen.local 2003 server passes all tests. DCDiag /test:DNS on the dc.rollen.local 2003 server passes all tests. Netdiag on the dc.rollen.2003 server passes all tests, but shows this warning: - [WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing. I now am at my wits' end, I have no idea in what direction to look for the cause of this problem. Any input would be greatly appreciated!

You need to do the zone transfers in both of your dns servers (2003 and 2008), once zone transfers are done you should be able to contact the domains and make the trust. http://www.techrepublic.com/article/step-by-step-how-to-migrate-dns-information-to-windows-server-2003/5084484~Santosh

@Santosh, that's exactly how I have configured it. But yet the error as described above appears and I cannot validate the trust relationship. The zones have properly been transferred between the two domains on both ends, as you can see in the command line output below. From the dc.domein.local [192.168.20.210] command prompt: c:\>nslookup dc.rollen.local Server: dc.domein.local Address: 192.168.20.210 Naam: dc.rollen.local Address: 192.168.0.2 From the dc.rollen.local [192.168.0.2] command prompt: C:\>nslookup dc.domein.local Server: dc.rollen.local Address: 192.168.0.2 Name: dc.domein.local Address: 192.168.20.210 Furthermore I can see all DNS records of the secondary zone rollen.local on the DNS mmc of dc.domein.local, and vice versa. As far as I know this indicates the zones have been correctly transferred.

See if following article helps in your case Trusting Domains when Windows 2008 Domain has a single label domain name http://community.spiceworks.com/how_to/show/1137 Also, Information about configuring Active Directory domains by using single-label DNS names http://support.microsoft.com/kb/300684~Santosh

@Santosh, As far as I can tell the domains between which I'm trying to create a trust relationship, both are not using single label domain names. I therefore don't think the articles you mentioned apply to my situation. The DNS for the "DOMEIN" domain is: domein.local The DNS for the "ROLLEN" domain is: rollen.local

Hi JasperE, It looks to be a DNS Problem, but can you check your SMB and NTLM settings in Group Policy? Ideally these should match, but I'm curious about the settings in this scenario since there are difference between the defaults settings in Windows 2003 and Windows 2008 and R2. Microsoft network client : digitally sign communications (always) Microsoft network client : digitally sign communications (if server agrees) Microsoft network server : digitally sign communications (always) Microsoft network server : digitally sign communications (if client agrees) Lan Manager authentication level: ?

Hi Tony, Regarding the DNS problem, I have tried setting up the zones as stub zone, secondary zone and conditional forwarding. Using either type, all records which I manually attempt to resolve from one domain to the other seem to work fine. The secondary zones are populated on both servers. And dcdiag /test:dns does not show any problems on either domain controller. About those settings: From the default domain controller policy->Computer config->Security Settings->Local Policies->Security Options. These are the settings on dc.rollen.local, the 2003 R2 server: - Microsoft network client : digitally sign communications (always) - Not Configured - Microsoft network client : digitally sign communications (if server agrees) - Not Configured - Microsoft network server : digitally sign communications (always) - Disabled - Microsoft network server : digitally sign communications (if client agrees) - Enabled - Network Security: Lan Manager authentication level: Send NTLM response only And these are the settings on dc.domein.local, the 2008 server: - Microsoft network client : digitally sign communications (always) - Not Configured - Microsoft network client : digitally sign communications (if server agrees) - Not Configured - Microsoft network server : digitally sign communications (always) - Enabled - Microsoft network server : digitally sign communications (if client agrees) - Enabled - Network Security: Lan Manager authentication level: Send NTLM response only I have tried disabling "digitally sign communications (always)" on the 2008 server and running gpupdate /force, this unfortunately doesn't solve the problem. Some further DNS test results (which as far as I can tell indicate everything is normal) On dc.rollen.local: C:\>nltest /dsgetdc:domein.local DC: \\DC.domein.local Address: \\192.168.20.210 Dom Guid: b7b50849-7c7a-4609-91d5-66a894c83383 Dom Name: domein.local Forest Name: domein.local Dc Site Name: Organization1Name Our Site Name: Organization1Name Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE 0x1000 The command completed successfully C:\>nslookup Default Server: dc.rollen.local Address: 192.168.0.2 > set type=srv > _ldap._tcp.dc._msdcs.domein.local Server: dc.rollen.local Address: 192.168.0.2 Non-authoritative answer: _ldap._tcp.dc._msdcs.domein.local SRV service location: priority = 0 weight = 100 port = 389 svr hostname = dc.domein.local dc.domein.local internet address = 192.168.20.210 On dc.domein.local c:\>nltest /dsgetdc:rollen.local DC: \\DC.Rollen.local Adres: \\192.168.0.2 Dom Guid: eb7ddbf4-221d-4b46-af7a-bc4aee1a958e Naam Dom: Rollen.local Naam Forest: Rollen.local Dc Site-naam: Default-First-Site-Name Naam van onze site: Default-First-Site-Name Vlaggen: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FORE ST CLOSE_SITE De opdracht is uitgevoerd. c:\>nslookup Standaardserver: dc.domein.local Address: 192.168.20.210 > set type=srv > _ldap._tcp.dc._msdcs.rollen.local Server: dc.domein.local Address: 192.168.20.210 Niet-bindend antwoord: _ldap._tcp.dc._msdcs.rollen.local SRV service location: priority = 0 weight = 100 port = 389 svr hostname = dc.rollen.local dc.rollen.local internet address = 192.168.0.2

There is one thing that I forgot to mention in my problem descriptions so far. I'm not sure if it is relevant in this case: In the past a functioning domain trust relationship did exist between the two domains. This trust relationship was however removed on both ends when the servers of the domein.local had to be upgraded from server 2003 to server 2008. Now I'm trying to recreate this trust relationship with the newly installed domain controller on the domein.local domein.

Hi JasperE, What happens when you just do a lookup for the domain rather than for the DC? From dc.domein.local run: > nslookup rollen.local What is the response? Does it return 192.168.0.2? From dc.rollen.local run: > nslookup domein.local What is the response? Does it return 192.168.2.210? Assuming that works... can you modify the HOST file on each DC with the following entries? HOST file for dc.domein.local 192.168.0.2 dc.rollen.local 192.168.0.2 rollen.local HOST file for dc.rollen.local 192.168.2.210 dc.domein.local 192.168.2.210 domein.local Also, please check if there is an LMHOSTS file configred as well on either server and whether you have it checked. After you've accomplished this, please reboot both DCs and retry the validation. If it still fails, please get a network trace from both DCs. This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.

Hi Tony, Thanks for the feedback and taking the time to look into this issue. I have made those changes, added the host entries and rebooted both DC's. Unfortunately this doesn't solve the issue. Besides a localhost record, the hosts file contains no other records than the ones I added. There are no entries in LMHOSTS on either domain controller. I have attached tracert results using two different VPN tunnels which I have in place. I can easily switch between the two tunnels by changing static routes which are configured on the routers on both ends. (The no logon servers available error occurs on both tunnels.) Nslookup output and tracert using the Cisco-Fortigate VPN tunnel: On dc.domein.local c:\>nslookup rollen.local Server: dc.domein.local Address: 192.168.20.210 Naam: rollen.local Address: 192.168.0.2 c:\>tracert dc.rollen.local Traceren van de route naar dc.rollen.local [192.168.0.2] via maximaal 30 hops: 1 <1 ms <1 ms <1 ms 192.168.20.253 <--Cisco router 2 * * * Time-out bij opdracht. <-- Router to Router IPSec VPN tunnel 3 14 ms 9 ms 9 ms dc.rollen.local [192.168.0.2] De trace is voltooid. On dc.rollen.local C:\>nslookup domein.local Server: dc.rollen.local Address: 192.168.0.2 Name: domein.local Address: 192.168.20.210 C:\>tracert dc.domein.local Tracing route to dc.domein.local [192.168.20.210] over a maximum of 30 hops: 1 <1 ms 1 ms <1 ms 192.168.0.254 <-- Fortigate router 2 * * * Request timed out. <-- Router to Router IPSec VPN tunnel 3 11 ms 9 ms 9 ms domein.local [192.168.20.210] Trace complete. Tracert output using an alternative openvpn-openvpn tunnel On dc.domein.local c:\>tracert dc.rollen.local Traceren van de route naar dc.rollen.local [192.168.0.2] via maximaal 30 hops: 1 <1 ms <1 ms <1 ms 192.168.20.244 <-- Linux system with openvpn installed 2 17 ms 18 ms 9 ms 192.168.21.10 <-- OpenVPN IP of the openvpn client on the end of rollen.local 3 15 ms 17 ms 9 ms dc.rollen.local [192.168.0.2] De trace is voltooid. On dc.rollen.local C:\>tracert dc.domein.local Tracing route to dc.domein.local [192.168.20.210] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.0.254 <-- Fortigate router on the rollen.local end 2 <1 ms <1 ms <1 ms 192.168.0.4 <-- IP of the linux VM running OpenVPN 3 15 ms 18 ms 9 ms 192.168.21.1 <-- IP of the OpenVPN Server on the domein.local end 4 17 ms 9 ms 9 ms domein.local [192.168.20.210] Trace complete.

Anyone? Unfortunately this problem is getting increasingly urgent. Yet I haven't even figured out which domain is causing the troubles.

Hey there; I was wondering if you did solve your problem. I have exactly the same issue. I was hoping if you can help. Regards.