Probleme mit LDAP(S)

[Emmermacher 16]

Moin.

Euch allen wünsche ich ein frohes, neues Jahr.

 

Wir haben nach der Installation der Dezember-Updates 2025 immer wieder Probleme bei der Nutzung von LDAP(S) bei diversen Drittanbietern, wie z.B Arpguard.

Hat MS hier Einstellungen verändert?

Arpguard hatte ich testweise von LDAPS auf LDAP geändert. Leider ohne Erfolg. 

Die Installation von Updates bei Arpguard hatte auch keine Veränderung gebracht.

 

Vielen Dank im Voraus für Eure Antworten.

 

Viele Grüße

 

Dirk

[cj_berlin 1.551]

Moin,
 

was sind denn die Probleme, die ihr habt? Lassen sie sich auch mit ldp.exe reproduzieren? 

Ich nehme an, dass LDAP(S) gegen Domain Controller versucht wird - welche Server-Version haben die?

[Emmermacher 16]

Hallo Evgenij.

 

Danke für Deine Antwort.

Server ist ein 2019.

Ergebniss von ldp:

Port 389: In Ordnung

Port 636, unabhängig, ob SSL aktiv ist, oder nicht: Connection fail

 

Ein netstat -ano zeigt an, das Port 636 offen ist.

 

Viele Grüße 

 

Dirk

[cj_berlin 1.551]

Moin,

636 ist immer offen, auch wenn noch gar kein Server-Zertifikat installiert ist. Vielleicht gibt es ein Problem mit der Zertifikatsauswahl, so dass kein Zertifikat gebunden werden kann? Darüber müsstest Du aber Event Log-Einträge beim Start des NTDS-Dienstes sehen...

Hier ein bisschen Lektüre: AwakeCoding ☀️💻 | Active Directory LDAPS certificate selection deep dive

[testperson 1.927]

Hi,

  

vor 36 Minuten schrieb Emmermacher:

Port 636, unabhängig, ob SSL aktiv ist, oder nicht: Connection fail

 

das hast du mit dem FQDN / Hostname getestet, der auch CN oder SAN ist, oder per IP?

 

Gruß

Jan

[Emmermacher 16]

Der Certificate Subject Name ist in Ordnung.

Bei Certificate Chain Validation bekomme ich nichts zurück geliefert.

 

Da werde ich heute auch nicht mehr weiter machen.

 

Schönen Feierabend :)

 

Dirk

vor 4 Minuten schrieb testperson:

Hi,

  

 

das hast du mit dem FQDN / Hostname getestet, der auch CN oder SAN ist, oder per IP?

 

Gruß

Jan

Ich hatte mit der IP-Adresse getestet. Mit dem FQDN funktioniert es.

[cj_berlin 1.551]

vor 14 Minuten schrieb Emmermacher:

Ich hatte mit der IP-Adresse getestet. Mit dem FQDN funktioniert es.

Das wäre dann wohl auch die Ursache, oder?

Ist in ARPGuard denn auch nur die IP-Adresse eingetragen?

 

[Emmermacher 16]

Hallo 

Hier ein kurzes Update.

 

In Arpguard werden die LDAP-Server mit der IP-Adresse eingetragen. Das Feld heißt jedenfalls so. FQDNs lassen sich hier auch ohne Fehlermeldungen eintragen.

Aktuell ist das System wieder auf LDAP über Port 389 eingestellt.

 

Die letzte Anmeldung mit einem AD-Account war am 15.12.

Die DCs wurden am 10.12 geupdatet.

Arpguard ujnd DOMOS habe ich am 19.12 aktualisiert.

 

Arpguard kann generell einen Import des AD durchführen. Der User darf das Flag "User sensitive, and cannot be delegated" nicht gesetzt haben.

Das haben wir getestet.

Mit einem weiteren Test habe ich Arguard einen User hinzugefügt, bei dem das Flag nicht gesetzt ist. Auch hier funktioniert eine Anmeldung nicht.

Hier kommt eine Meldung "Passwort nicht korrekt". Das einem das einmal passiert, kann vorkommen. Das kann ich aber ausschließen.

 

Warum hier Passwörter nicht mehr akzeptiert werden, weiß ich nicht. Zwischenzeitlich hatte ich schon mit unserem Systemhaus ein Meeting. Der Kollege konnte auch keine Ursache für das Verhalten finden.

 

Sobald ich neue Infos habe, gibt es ein Update von mir.

 

LG

 

Dirk

[daabm 1.460]

SSL mit IP-Adressen ist eher "schwierig"   Und Kerberos funktioniert mit IP-Adressen auch nicht. Also "gar nicht".