winmadness 79 Geschrieben 4. September 2021 Melden Teilen Geschrieben 4. September 2021 Konfiguration: Windows 2016 Hyper-V VM als DC, Clients Windows 10 Anmeldung über VPN mit User Zertifikaten, kein Domainmitglied. Wie kann ich den LDAPS (SSL/TTLS) vom Client erzwingen? Ich habe auf dem DC das notwendige Computer Zertifikat erstellt. Der Test auf dem DC mit ldp.exe über Port 636 mit TLS verschlüsselt funktioniert. Auch der Test mit der Software "Softerra LDAP Administrator" mit den gleichen Einstellungen auf dem VPN Client funktioniert. D.h. der Client kann eine verschlüsselte Verbindung über Port 636 erfolgreich aufbauen. Wenn ich jetzt eine LDAP Abfrage auf dem Client z.B. über die Anzeige die Sicherheitseinstellungen einer Netzwerkfreigabe ausführe, dann sehe ich in der Firewall nur den Port 386. Laut MS Dokumentation erfolgt eine verschlüsselte Anfrage über Port 636. Deshalb die Frage wie kann die LDAP Verschlüsselung von einem Nicht-Domain-Mitglied erzwungen werden? Weitere Frage: ich habe die entsprechenden Einstellungen für LDAP Channel Binding und Signing auf DC und den Clients gesetzt. Wie kann ich überprüfen, ob die Einstellungen greifen? Die erweiterte Protokollierung über die Registry ("16 LDAP Interface Events" = 2) habe ich aktiviert. Im Ereignisprotokoll finde ich keine Einträge. Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 4. September 2021 Melden Teilen Geschrieben 4. September 2021 389 heißt nicht zwingend Klartext. Das geht auch mit tls ;) vor 5 Minuten schrieb winmadness: Frage wie kann die LDAP Verschlüsselung von einem Nicht-Domain-Mitglied erzwungen werden? Am Client gar nicht. Aber du kannst am dc erzwingen, dass nur noch signed möglich ist, und das geht nicht mit ohne domainmember afaik. Heißt dann bleibt nur noch 636 für ldaps. Zitieren Link zu diesem Kommentar
winmadness 79 Geschrieben 4. September 2021 Autor Melden Teilen Geschrieben 4. September 2021 vor 41 Minuten schrieb NorbertFe: Aber du kannst am dc erzwingen, dass nur noch signed möglich ist, und das geht nicht mit ohne domainmember afaik. Danke für die schnelle Antwort. Was ist mit ".. geht nicht mit ohne ..." - meinst Du ".. geht nicht ohne domainmember"? Ich habe am DC CBT und Signing bereits erzwungen - Sicherheitsoptionen "Domänencontroller: Anforderungen an das LDAP-Serverkanal-Bindungstoken" auf "Immer" und "Domänencontroller: Signaturanforderungen für LDAP-Server" = "Signatur erforderlich". Auf dem Client zusätzliche "Netzwerksicherheit: Signaturanforderungen für LDAP-Clients" = "Signatur erforderlich" (wenn ich richtig verstanden habe, benötige ich diese Option aber eigentlich nicht). Wie gesagt wird nur Port 386 verwendet. Kann ich auf dem Server (Client) irgendwo sehen, ob die Verbindung verschlüsselt ist? Ich habe einen zusätzlichen Test vorgenommen: auf dem DC das Computerzertifikat in "Eigene Zertifikate" gelöscht. Wie erwartet ist damit keine TLS Verbindung (ldp.exe) mehr möglich. Jetzt auf dem Client wieder über Eigenschaften -> Sicherheit eines Netzwerklaufwerk eine LDAP Anfrage erzwungen. Diese war erfolgreich über Port 389 und somit unverschlüsselt. Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 5. September 2021 Melden Teilen Geschrieben 5. September 2021 vor 10 Stunden schrieb winmadness: Wie gesagt wird nur Port 386 verwendet. 389 vermute ich? vor 10 Stunden schrieb winmadness: Kann ich auf dem Server (Client) irgendwo sehen, ob die Verbindung verschlüsselt ist? Das kannst du mit ldp oder jedem beliebigen LDAP Browser testen. Du wirst einen simple Bind nicht hinbekommen auf Port 389. alternativ nimm dir Wireshark oder den netmon und schau nach, ob das Klartext ist. ;) 1 Zitieren Link zu diesem Kommentar
Beste Lösung cj_berlin 1.329 Geschrieben 5. September 2021 Beste Lösung Melden Teilen Geschrieben 5. September 2021 Moin, alles hier beschrieben: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536 TLDR; Auditing einschalten (hast Du ja schon gemacht) Event 2889 im Directory Service Log: Verbindungen ohne Signierung ODER ohne TLS Event 3039 im Directory Service Log: Verbindungen mit TLS, aber ohne Channel Binding Wenn keines dieser Events kommt, wird TLS ausgehandelt und offenbar auch CB verwendet. Wenn Du es ganz genau wissen willst, kannst Du den Diagnostic Level höher drehen und Dich auf einen Haufen Events vorbereiten NB: Die Einstellung "Require Signing" erzwingt die Signierung nur dann, wenn TLS nicht verwendet wird! @NorbertFe Warum sollte ich keinen Simple Bind auf 389 hinbekommen? Wenn die Signierung klappt, muss es doch gehen, und dafür braucht es keine Domänen-Mitgliedschaft... oder übersehe ich ob der frühen Stunde etwas? 1 Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 5. September 2021 Melden Teilen Geschrieben 5. September 2021 (bearbeitet) vor 27 Minuten schrieb cj_berlin: Wenn die Signierung klappt, muss es doch gehen, und dafür braucht es keine Domänen-Mitgliedschaft. Bist du sicher, dass die SIgnierung bei Nicht-Domänenmitgliedschaft möglich ist? Ich bin da nicht sicher, deswegen oben auch das AFAIK. Edit: OK im verlinkten Artikel steht es wäre common bei Nicht-Windows Clients, also muss es wohl gehen. ;) Vermutlich meinte ich, dass man keinen Klartext Simple Bind hinbekommt. Ich hatte dazu damals auch einen Artikel bei Nils veröffentlicht: https://www.faq-o-matic.net/2018/07/16/ldap-signing-auf-domnencontrollern-erzwingen/ bearbeitet 5. September 2021 von NorbertFe Zitieren Link zu diesem Kommentar
winmadness 79 Geschrieben 5. September 2021 Autor Melden Teilen Geschrieben 5. September 2021 Danke an euch für die Tipps. Ich habe mit Wireshark festgestellt, dass die Anfragen nicht verschlüsselt werden. Ein "Simple Bind" wird ohne Verschlüsselung abgelehnt - Fehlermeldung res = ldap_simple_bind_s(ld, 'domain\user', <unavailable>); // v.3 Error <8>: ldap_simple_bind_s() failed: Strenge Authentifizierung erforderlich Server error: 00002028: LdapErr: DSID-0C090273, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839 Error 0x2028 Eine sicherere Authentifizierungsmethode wird für diesen Server benötigt. 1 Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 5. September 2021 Melden Teilen Geschrieben 5. September 2021 Na dann ist doch alles gut. Oder wo ist das Problem? Zitieren Link zu diesem Kommentar
winmadness 79 Geschrieben 5. September 2021 Autor Melden Teilen Geschrieben 5. September 2021 Gerade eben schrieb NorbertFe: Oder wo ist das Problem? Kein Problem, Post war nur als Rückmeldung gedacht. Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 5. September 2021 Melden Teilen Geschrieben 5. September 2021 Achsoooo :) Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 6. September 2021 Melden Teilen Geschrieben 6. September 2021 Am 5.9.2021 um 10:07 schrieb NorbertFe: Bist du sicher, dass die SIgnierung bei Nicht-Domänenmitgliedschaft möglich ist? Ja, absolut sicher. https://www.google.com/search?q=ldap+sasl+bind 1 Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 6. September 2021 Melden Teilen Geschrieben 6. September 2021 Hab ich mich doch oben schon korrigiert. Da brauch ich doch kein lmgtfy ;) trotzdem danke. :) Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 14. Oktober 2021 Melden Teilen Geschrieben 14. Oktober 2021 Am 5.9.2021 um 09:46 schrieb cj_berlin: Moin, alles hier beschrieben: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536 da steht u.a. Zitat March 2020 update will add new Auditing capabilities into group policies related to LDAP Channel Binding and LDAP Signing (this one has been around for a while) Through new Group Policy setting you can configure LDAP Channel Binding and LDAP Signing "auditing" NOTE: Auditing can also be enabled via Registry, on each Domain Controller Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2 Reg Add ist mir klar. Aber wie heißen denn die neuen Policies fürs "Auditing"? Bin irgendwie grad blind. :) Bye Norbert Zitieren Link zu diesem Kommentar
cj_berlin 1.329 Geschrieben 14. Oktober 2021 Melden Teilen Geschrieben 14. Oktober 2021 (bearbeitet) Anscheinend haben die Jungs das vergessen Ich finde das zumindest nicht. bearbeitet 14. Oktober 2021 von cj_berlin Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 16. Oktober 2021 Melden Teilen Geschrieben 16. Oktober 2021 Ja, sieht so aus. Grad gpedit.msc und secpol.msc auf einem 2022 DC aufgerufen, da ist _nichts_ dazu zu finden... Naja, das GP-Team bei MS ist "klein"... Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.