4
Ldapsearch auf active directory
Hallo,
weis jemand ob es auf einem dc restriktionen gibt welche standardmäßig das durchsuchen des ldap verhindern könnten.
Wenn man per ubuntu mit ldapsearch auf den dc zugreifen möchte, sagt der: Can't contact LDAP server (-1)
Ein connect per openssl s_client funktioniert am port 636..
weis jemand ob es auf einem dc restriktionen gibt welche standardmäßig das durchsuchen des ldap verhindern könnten.
Wenn man per ubuntu mit ldapsearch auf den dc zugreifen möchte, sagt der: Can't contact LDAP server (-1)
Ein connect per openssl s_client funktioniert am port 636..
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 595893
Url: https://administrator.de/contentid/595893
Printed on: May 4, 2024 at 08:05 o'clock
4 Comments
Latest comment
Moin,
genereller openldap tipp:
der parameter
gibt etwas mehr debuginfo, also mehr als das "can't connect to"
Zum Thema:
Port 636 nutzt LDAPS - also S für Secure, ergo TLS.
Bei TLS ist immer ein Thema ob ich dem präsentierten Zertifikat der Gegenstelle auch vertraue (ergo ist es ein Man in the Middle oder der vertrauenswürdige Server?)
Wenn du in deinem Labor bist und dir 100% sicher bist das das Zertifikat wirklich vom DC stammt, kannst du den Check überspringen mit einem vorangestellten:
Also so:
In einer Produktivumgebung, in der du dem Netzwerk nicht trauen kannst (also überall :D ) - musst du schaun das du der CA traust die das Zertifikat vom DC ausstellt, also die CA, ggf. die CA-Chain in ein file einlesen, und dann dem openldap mitgeben mit einem vorangestellten:
Wenn du noch mehr als nur ldapseach machst, macht es ggf. sinnvoll den/der WindowsCA zu vertrauen, und Sie in den Certificate Store hinzuzufügen
hope this helps
MFG N-Dude
genereller openldap tipp:
der parameter
-d -1Zum Thema:
Port 636 nutzt LDAPS - also S für Secure, ergo TLS.
Bei TLS ist immer ein Thema ob ich dem präsentierten Zertifikat der Gegenstelle auch vertraue (ergo ist es ein Man in the Middle oder der vertrauenswürdige Server?)
Wenn du in deinem Labor bist und dir 100% sicher bist das das Zertifikat wirklich vom DC stammt, kannst du den Check überspringen mit einem vorangestellten:
LDAPTLS_REQCERT=never Also so:
LDAPTLS_REQCERT=never ldapsearch -H ldaps://nameoderipvomdc -x -w geheim -D "user@domain.com" -b "dc=domain,dc=com" -s sub "hier_noch_filterkram" userPassword In einer Produktivumgebung, in der du dem Netzwerk nicht trauen kannst (also überall :D ) - musst du schaun das du der CA traust die das Zertifikat vom DC ausstellt, also die CA, ggf. die CA-Chain in ein file einlesen, und dann dem openldap mitgeben mit einem vorangestellten:
LDAP_CACERT=/pfad/zum/CA.pem ldapseach (...)Wenn du noch mehr als nur ldapseach machst, macht es ggf. sinnvoll den/der WindowsCA zu vertrauen, und Sie in den Certificate Store hinzuzufügen
hope this helps
MFG N-Dude
Moin,
Dankeschön! der "LDAPTLS_REQCERT=never" hat mich weitergebracht.
Hast du vielleicht noch eine Idee wie man auf einem 16er Server (außer Whireshark wg. pcap !livebetrieb!) Ldap traces mitschneiden kann?
VG user217
Dankeschön! der "LDAPTLS_REQCERT=never" hat mich weitergebracht.
Hast du vielleicht noch eine Idee wie man auf einem 16er Server (außer Whireshark wg. pcap !livebetrieb!) Ldap traces mitschneiden kann?
VG user217
Zitat von @user217:
Dankeschön! der "LDAPTLS_REQCERT=never" hat mich weitergebracht.
Hast du vielleicht noch eine Idee wie man auf einem 16er Server (außer Whireshark wg. pcap !livebetrieb!) Ldap traces mitschneiden kann?
Mirror-Port am Switch aktivieren und LDAP Traffic mit tcpdump oder Wireshark auf nem anderen Device mitschneiden.Dankeschön! der "LDAPTLS_REQCERT=never" hat mich weitergebracht.
Hast du vielleicht noch eine Idee wie man auf einem 16er Server (außer Whireshark wg. pcap !livebetrieb!) Ldap traces mitschneiden kann?
Event ID 1644
https://www.msxfaq.de/windows/ldap_tracing.htm
https://www.msxfaq.de/windows/ldap_tracing.htm
