LDAP(s) timeouts auf allen DCs

[wranger 0]

Moin,

 

ich weiß nicht mehr weiter, folgendes Bild:

 

Wir haben 3 DCs, (Server2019) alle im selben Netz. Diese DCs beantworten auch LDAPs Anfragen, nun kommt es auf allen DCs in unterschiedlichen Abständen zu Ausfällen in der Verbindung für so etwa 90Sekunden. Dann heilt sich das Ganze als wäre nie etwas gewesen. Es passiert nicht auf allen DCs zeitgleich, die Abstände zwischen den Ausfällen sind unterschiedlich (30Min - 90Min) und auch die Dauer eines Ausfalls kann variieren, meist aber so 90Sekunden.

 

Ja ich bin mir sicher dass es die DCs sind (Netzwerk, FW usw habe ich eigentlich durch Test vorab ausgeschlossen).

 

Wenn ich während so eines Ausfalls "ldap.exe" starte, oder eine bereits bestehende Session wiederbelebe, friert das Fenster für die Dauer des Aussetzers ein: Fehlermeldung

 

ld = ldap_sslinit("dc3", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to dc3.

Nach so etwas 90Sekunden gehts dann wieder.

0x0 = ldap_unbind(ld);
ld = ldap_sslinit("dc3", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 256 bits
Established connection to dc3.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: CN=Configuration,DC=domain,DC=dir; 
currentTime: 08.09.2020 08:23:09 Mitteleuropäische Somm; 
defaultNamingContext: DC=domain,DC=dir; 
dnsHostName: dc3.domain.dir; 
domainControllerFunctionality: 7 = ( WIN2016 ); 
domainFunctionality: 7 = ( WIN2016 ); 
dsServiceName: CN=NTDS Settings,CN=DC3-,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domaint,DC=dir; 
forestFunctionality: 7 = ( WIN2016 ); 
highestCommittedUSN: 7577552; 
isGlobalCatalogReady: TRUE; 
isSynchronized: TRUE; 
ldapServiceName: domain.dir:dc3

Ein windump/tcpdump zeigt den 3 Wege-Handshake, die SSL-Aushandlung aber erst nach (x-Sekunden). Neue Verbindungen werden noch angenommen, aber ohne Datenübertragung.

 

- Das LDAP-Logging habe ich in der Registry schon erhöht, kann aber keine (anderen) "Fehler/Warnings" in diesem Zeritraum feststellen.

- Wir haben eine Windows PKI, auch das Zertifikat dieses Servers habe ich temporär gegen eine OpenSSL erstellte CA/Server-Zertifikat getauscht -> keine Besserung.

- dcdiag und repadmin zeigen keine Fehler

 

-------- Zur History

dc3 wurde als Server 2019 der Domäne/den Servern dc1 und dc2 (2012) hinzugefügt.

Dann wurden dc2 und dc1 demoted und entfernt und zwei neue Server2019 als dc1 und dc2 mit der gleichen IP wieder hinzugefügt.

 

Vielleicht haben das Problem ja mehrere, man bemerkt es eigentlich nur wenn man genau die Logs der Clienten liest (Radiusserver). Oder man sich manchmal über Verzögerungen bei der Anmeldung wundert.

 

Jemand noch Ideen?

Danke + Gruß

 

 

[NilsK 2.930]

Moin,

 

nur mal so geschossen:

• die DCs sind virtuell und es gibt Probleme mit den NICs auf den Hosts (Treiber, Konfig)
• die DCs sind physisch, dort NIC
• der CRL Distribution Point, der im DC-Zertifikat angegeben ist, ist nicht erreichbar
• das Zertifikat hat eine irre kurze Laufzeit
• DC1 und DC2 haben nicht den Private Key für ihre Zertifikate (durch den Austausch)

Besteht das Problem erst seit dem DC-Wechsel?

Ist der "hängende" DC auch bei anderen Diensten/Verbindungen eingeeschränkt?

Zeigt sich während eines Hängers lokal auf dem DC eine Besonderheit?

 

Gruß, Nils

 

[wranger 0]

Moin,

 

ja sind VMs, die Hosts habe ich schon getauscht. NIC-Problem würde ich ausschließen da u.A RDP während des Ausfalls geht.

 

- CRL wie im Zert angegeben übern IE erreichbar.

- DC1,2 habe sich selber ihr Zert geholt und besitzen den PK.

 

Schwer zu sagen seit wann das Problem besteht, würde uns das weiter bringen?

Gerade ein Ausfall miterlebt und per RDP auf dem Server gearbeitet. Gleich ne neu Fehlermeldung in ldp.exe beim Verbinden:

Error <81>: ldap_bind_s() failed: Server heruntergefahren.

Nein, nichts Auffällig auf dem DC. Es verabschieden sich dann die Clients:

  - Provider 

   [ Name]  Microsoft-Windows-ActiveDirectory_DomainService 
   [ Guid]  {0e8478c5-3605-4e8c-8497-1e730c959516} 
   [ EventSourceName]  NTDS General 
  - EventID 1216 
   [ Qualifiers]  32768 
   Version 0 
   Level 3 
   Task 16 
   Opcode 0 
   Keywords 0x8080000000000000 
  - TimeCreated
   [ SystemTime]  2020-09-08T13:08:30.462725300Z 
   EventRecordID 906750
   Correlation
  - Execution
   [ ProcessID]  684 
   [ ThreadID]  1580 
   Channel Directory Service 
   Computer dc3 
   Security
- EventData 
   3 
   c060613 
   IP:56116 
   Das System kann den angegebenen Pfad nicht finden. 

 

[NilsK 2.930]

Moin,

 

dann würde ich nicht mehr lange zögern, den Herstellersupport einzubinden.

 

Gruß, Nils

 

[daabm 1.348]

Hm - auch wenn's nicht wirklich hilft: Wir nutzen LDAPS seit Jahren ohne Probleme. Und alle Connect-Fehler waren eigentlich immer Fehler in der Infrastruktur - bevorzugt Firewalls... Nur können wir das immer schlecht beweisen

Ein Hinweis auf "Infrastruktur" wäre ein ganz schnell durchzuführender Test - wenn ich das richtig verstanden habe, kannst Du per RDP weiterarbeiten, wenn LDAPS nicht geht? Dann probier in dem Moment mal LDP lokal auf dem DC mit Bind auf sich selbst. Wenn das geht -> Netzwerk...

[NilsK 2.930]

Moin,

 

Hat er schon getestet, führt zu Fehler.

 

Gruß, Nils

[testperson 1.674]

Hi,

 

läuft auf den DCs ein Virenschutz (oder andere 3rd Party Software) der (die) evtl. auch "das Netzwerk" schützt?

Hast du im Fehlerfall mal (plain) LDAP oder "StartTLS LDAP" über Port 389 getestet? Ein weiterer Test könnte LDAPs über den Global Catalog (3289) sein.

 

Gruß

Jan

[wranger 0]

Moin,

 

der LDAP ist auch betroffen, ich monitore noch mal etwas genauer. Es spricht auch für einen internen Fehler, da sich zum Zeitpunkt des Ausfalls der ADWS meldet:

 

"Von Active Directory-Webdiensten konnte nicht bestimmt werden, ob es sich bei dem Computer um einen globalen Katalogserver handelt."

 

Daraus lese ich, auch der ADWS bekommt keine Verbindung zur lokalen LDAP Instanz.

 

Paar Ideen habe ich noch:

- Monitoring der TCP Verbindungen zum NTDS (Vielleicht zu viele Anfragen)

- Den Prozess monitoren, mal gucken wie das geht.

- Versuchen mit vielen Anfragen das Ereignis auszulösen.

[NilsK 2.930]

Moin,

 

zu viele Anfragen? Wie groß ist denn die Umgebung? Halte ich für unwahrscheinlich.

 

Also, wie gesagt, ich würde den Herstellersupport ins Boot holen.

 

Gruß, Nils

 

[wranger 0]

Sag mal, ich habe jetzt die letzten 10 Tage für meine LDAPS Anfragen vom Radius-Server den DC3 benutzt. Nun habe ich heute morgen  wieder auf den DC1 gewechselt und siehe da.

 

10 Tage hat sich der ADWS auf DC1 nicht gemeldet (siehe Meldung von oben), jetzt bereits die zweite Meldung. (Zeitgleich mit den Ausfällen auf den Radiusservern und PRTG).

 

Das würde doch bedeuten, die Radius-LDAPs Verbindung kann den AD stören. Ich meine, wenn ich das einem sage, sagt der Linux-Mensch Windows ist schuld und der Windows-Mensch Linux ist schuld ...

 

------

- Mit nem PHP-Skript und 10.000 neuen Verbindungen (100Connections/s) konnte ich das nun nicht repoduzieren.

 

[lefg 276]

Moin

 

Den Begriff Ereignisanzeige habe ich nicht finden können in diesem Thread. Wurde schon einmal nachgeschaut auf allen beteiligten Geräten?

 

Bei mir begann Fehlersuche in der Ereignisanzeige, besonders und auch bei MS Produkten. Aber auch bei deneen der Infrastruktur, Switches.

 

Versucht da Etwas oder Jemand einen Download und bekommt ein grosses Paket nicht durch den Antivirus auf den Proxy?

 

 

bearbeitet 15. September 2020 von lefg