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..
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 595893
Url: https://administrator.de/forum/ldapsearch-auf-active-directory-595893.html
Ausgedruckt am: 03.04.2025 um 13:04 Uhr
4 Kommentare
Neuester Kommentar
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 -1
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:
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

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