[2008&2003]Fout bij Domain Trust: No logon servers available

[JasperE]

Ik probeer een trust op te bouwen tussen een Server 2008 en een Server 2003 domeincontroller. Als ik de trust instel, dan verschijnt deze in de tab "Trusts" van de domeineigenschappen in beide domeinen.

Maar als de trust geverifieerd moet worden tijdens de Wizard, dan krijg ik telkens de onderstaande foutmelding. Daarbij maakt het niet uit vanaf welke domeincontroller ik de trust instel.

----------
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.
----------

Wat ik er nog bij moet vertellen is dat er in het verleden een werkende domain trust was. Die is toen verbroken voordat domein.local van server 2003 naar 2008 geupgrade werd. Enkele weken nadat die migratie voltooid was moest de domain trust weer opgebouwd worden, maar dat is tot op heden dus niet gelukt.

Details:

Server 1:
- Server 2008 x64
- Domein: domein.local
- Server FQDN: dc.domein.local
- IP: 192.168.20.210 / 255.255.255.0

Server 2:
- Server 2003 R2
- Domein: rollen.local
- Server FQDN: dc.rollen.local
- IP: 192.168.0.2 / 255.255.255.0

AD Topologie
Ieder domein heeft een enkele domeincontroller
Elk forest heeft 1 domein.
Beide domeinen en forests staan op "Windows Server 2003" functionality level.

Firewalls, networking & DNS
Firewalls staan uit op beide DC's.

De system32\drivers\etc\hosts bestanden hebben alleen de localhost entries.

Subnets praten met elkaar via een geroute VPN tunnel. De bovenstaande fout verschijnt als ik een CISCO-FORTIGATE VPN tunnel gebruik, maar ook als ik een OpenVPN tussen de twee vestigingen gebruik.

DC's kunnen elkaar pingen op de FQDN.

Er zijn geen WINS servers geinstalleerd.

DC.domein.local heeft een secondary DNS server voor de zone domein.local en _msdcs.domein.local. Deze DNS server draait op een non-DC server 2008 in "Secondary Zone" mode (non-AD). De DNS zones zijn gesyncrhoniseerd met de DC.

De DC's kunnen elkaars domeinnamen resolven, en ook elkaars FQDN hostnames.

Ik heb de volgende DNS configuraties getest: Conditional forwarding, Secondary zone, Stub zone.
De validatie van de trust geeft de no logon servers available foutmelding, het maakt niet uit welke DNS configuratie ik gebruik.
Ik heb al geprobeerd een aantal nachten te wachten voor de trust op te bouwen om te kijken of er nog updates moeten propagaten, maar ook dat biedt geen oplossing.

Vanaf dc.domein.local [192.168.20.210] command prompt:

code:

c:\>nslookup dc.rollen.local
Server:  dc.domein.local
Address:  192.168.20.210

Naam:    dc.rollen.local
Address:  192.168.0.2

Vanaf dc.rollen.local [192.168.0.2] command prompt:

code:

C:\>nslookup dc.domein.local
Server:  dc.rollen.local
Address:  192.168.0.2

Name:    dc.domein.local
Address:  192.168.20.210

Connectivity test
Een PortQryUI test van dc.rollen.local naar dc.domein.local laat de volgende 0x00000000 codes zien:

code:

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 werkt wel en laat resultaten zien.

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.

Ik krijg dezelfde resultaten als ik PortQryUI draai op dc.domein.local op het lokale 192.168.20.210 IP.


Een PortQryUI test vanaf dc.domein.local naar dc.rollen.local laat de volgende 0x00000000 codes zien:

code:

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.

Ik krijg dezelfde resultaten als ik PortQryUI draai op dc.rollen.local op het lokale 192.168.0.2 IP.


DCDiag resultaten van dc.domein.local
DCDiag op dc.domein.local 2008 server slaagt alle testen, behalve de NCSecDesc test die volgens mij alleen relevant is voor ReadOnly DC's.

Het volgende wordt getoont in het event log:: "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)
Kan dit een oorzaak van het probleem zijn? Volgens google kan ik die fout negeren zolang er geen Enterprise CA geconfigureerd is in mijn organisatie. ( Event ID 36872 on a Windows 2000 domain controller or on a Windows Server 2003 domain controller )

DCDiag /test:dns op dc.domein.local toont een waarschuwing dat er geen AAAA records geconfigureerd zijn. IPV6 is disabled op de NIC dus dat kan kloppen..

DCDiag results van dc.rollen.local
DCDiag op de dc.rollen.local 2003 server slaagt voor alle testen.
DCDiag /test:DNS op de dc.rollen.local 2003 slaagt alle testen.

Netdiag op de dc.rollen.2003 server slaagt alle testen maar laat deze waarschuwing zien:
- [WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.

Nog meer diagnostiek
Vanaf dc.rollen.local:

code:

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

Vanaf dc.domein.local

code:

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

Volgens mij heb ik zo ongeveer alle probleem oplossende stappen die redelijkerwijs te vinden zijn via google nu wel uitgevoerd. Toch is het probleem nog niet opgelost
Heeft iemand nog ideeen?

[Question Mark]

JasperE schreef op dinsdag 28 februari 2012 @ 17:02:
DC.domein.local heeft een secondary DNS server voor de zone domein.local en _msdcs.domein.local. Deze DNS server draait op een non-DC server 2008 in "Secondary Zone" mode (non-AD). De DNS zones zijn gesyncrhoniseerd met de DC.

Wat bedoel je precies met bovenstaande? Op de primaire dns-server zijn dan niet de AD-srv records bekend?

De DC's kunnen elkaars domeinnamen resolven, en ook elkaars FQDN hostnames.

Ik heb de volgende DNS configuraties getest: Conditional forwarding, Secondary zone, Stub zone.
De validatie van de trust geeft de no logon servers available foutmelding, het maakt niet uit welke DNS configuratie ik gebruik.

Even voor mijn beeldvorming: je hebt hiermee op dns-servers binnen beide domeinen ingesteld dat dns-records voor het andere domain te resolven zijn?

Overigens complimenten voor je zeer heldere en uitgebreide topicstart!

[ Voor 3% gewijzigd door Question Mark op 29-02-2012 09:44 ]

[JasperE]

Question Mark schreef op woensdag 29 februari 2012 @ 09:40:
[...]
Wat bedoel je precies met bovenstaande? Op de primaire dns-server zijn dan niet de AD-srv records bekend?

In het DOMEIN domein wilde ik graag 2 DNS servers hebben, maar ik had geen licenties meer over om een extra DC aan te maken. Al mijn overige windows servers hebben namelijk al legio andere taken die niet zo goed combineren met een DC op dezelfde windows installatie (veiligheids, compatibility en performance redenen).
Daarom heb ik op één van deze servers gewoon een secondary DNS zone voor domein.local aangemaakt met DC als master.
Op die manier heb ik 2 DNS servers, één op de DC geïntegreerd met AD, en één in slave mode.

[...]

Even voor mijn beeldvorming: je hebt hiermee op dns-servers binnen beide domeinen ingesteld dat dns-records voor het andere domain te resolven zijn?

Overigens complimenten voor je zeer heldere en uitgebreide topicstart!

Dat klopt, ieder van die beschreven methodes is een methode om het externe domein te kunnen resolven. Dat is nodig zodat de DC's en clients in het ene domein, de computers in het andere domein kunnen benaderen via de FQDN; een voorwaarde voor goed werkende domain trusts.
Zoals je in de command line output kan je ook zien dat beide domeinen vanuit beide domeinen te resolven zijn.

Normaal gesproken krijg je de "no logon servers available" foutmelding wanneer dit resolven niet goed werkt, maar in mijn geval lijkt het probleem volgens mij ergens anders te liggen.
(Maar misschien zie ik iets over het hoofd)

[ Voor 11% gewijzigd door JasperE op 29-02-2012 17:15 ]