LDAP Kerberos-Authentifizierung in JDisc Discovery

Einführung

Der Zugriff auf Ihr Directory ist ein wichtiger Bestandteil der Network Discovery. Wie sich ein Discovery-Tool authentifiziert, verdient dabei genauso viel Aufmerksamkeit wie die Informationen, die es erfasst.

JDisc Discovery unterstützt jetzt Kerberos-Benutzerauthentifizierung für LDAP-Verbindungen. Bisher war Simple Bind die einzige Authentifizierungsoption für diese Verbindungen. Mit Kerberos können Sie nun eine Alternative wählen, die Tickets zur Identitätsprüfung verwendet und die LDAP-Authentifizierung in Ihre bestehende Kerberos-Vertrauensinfrastruktur integriert.

Für Teams, die die Sicherheit ihres Directory-Zugriffs überprüfen, eröffnet das eine praktische neue Möglichkeit: weg von passwortbasierten LDAP-Binds, ohne auf Directory-Zugriff im Discovery-Workflow zu verzichten.

Was ändert sich bei LDAP-Verbindungen?

Die neue Funktion ergänzt Simple Bind um Kerberos. Damit können Sie die Authentifizierungsmethode auswählen, die zu Ihrer Directory-Umgebung und Ihren Sicherheitsanforderungen passt.

Diese Entwicklung folgt auf die frühere Einführung der Kerberos-Authentifizierung für WMI, SMB und Windows Remote Login in JDisc. Die neue Funktion bezieht sich speziell auf die LDAP-Benutzerauthentifizierung. Einstellungen und Voraussetzungen eines Protokolls sollten nicht unverändert auf ein anderes übertragen werden.

Für Administratoren lautet die zentrale Frage damit: Soll sich diese LDAP-Verbindung per Simple Bind oder mit Kerberos-Tickets authentifizieren?

Wie sich Simple Bind und Kerberos unterscheiden

Bei einem passwortbasierten LDAP Simple Bind sendet der Client eine Identität und ein Passwort an den Directory-Server. Der Bind selbst schützt diese Anmeldedaten nicht. Für Vertraulichkeit muss TLS sorgen, zum Beispiel über LDAPS oder StartTLS. Korrekt konfiguriertes TLS verifiziert den Server außerdem über dessen Zertifikat. Eine bestehende Simple-Bind-Verbindung mit TLS darf deshalb nicht mit einer unverschlüsselten Verbindung gleichgesetzt werden. Die LDAP-Sicherheitsspezifikation erläutert diese getrennten Sicherheitsmechanismen.

Kerberos verfolgt einen anderen Ansatz. Ein vertrauenswürdiges Key Distribution Center, kurz KDC, stellt Tickets aus, mit denen ein Client seine Identität gegenüber einem Dienst nachweisen kann. In Active Directory übernehmen Domain Controller die KDC-Rolle.

Auf hoher Ebene besteht der Ablauf aus drei Schritten:

1. Der Client authentifiziert sich beim KDC und erhält ein Ticket-Granting Ticket.
2. Mit diesem Ticket fordert er ein Service Ticket für den vorgesehenen LDAP-Dienst an.
3. Er übermittelt das Service Ticket und den kryptografischen Nachweis an den LDAP-Server.

Bei der LDAP-Authentifizierung wird damit ein Ticket verwendet, anstatt das Passwort des Benutzers als Simple-Bind-Anmeldedaten zu übertragen. Microsoft beschreibt diese Vertrauensbeziehung und den Ticket-Austausch in der Übersicht zur Kerberos-Authentifizierung.

Woher mehr Sicherheit und Vertrauen kommen

Der unmittelbarste Vorteil liegt darin, wie der LDAP-Client seine Identität nachweist. Kerberos vermeidet die Übertragung eines wiederverwendbaren Passworts im LDAP-Bind und verwendet stattdessen Anmeldedaten, die für einen bestimmten Dienst ausgestellt wurden.

Kerberos unterstützt außerdem gegenseitige Authentifizierung: Der Client kann die Identität des Dienstes prüfen, während der Dienst zugleich den Client verifiziert. Diese Fähigkeit stärkt das Vertrauen in den vorgesehenen Endpunkt, wenn Mutual Authentication ausgehandelt wird. Daraus sollte jedoch nicht geschlossen werden, dass jede Anwendung automatisch jede Kerberos-Sicherheitsoption aktiviert. Microsoft erläutert den Mechanismus in der Dokumentation zur gegenseitigen Authentifizierung mit Kerberos.

Für Ihr Operations-Team ermöglicht die neue LDAP-Option, die Discovery-Authentifizierung enger an eine bestehende Kerberos-Umgebung anzupassen. Wenn Ihre Sicherheitsrichtlinie eine Abkehr von Simple Bind vorsieht, bietet JDisc Discovery jetzt eine Authentifizierungsalternative, die Sie prüfen können.

Kerberos setzt weiterhin voraus, dass Anmeldedaten und die verwendeten Systeme geschützt werden. Tickets besitzen eine begrenzte Gültigkeitsdauer, doch auch ein gestohlenes, noch nutzbares Ticket ist sensibel. Die Kerberos-Protokollspezifikation beschreibt sowohl die Schutzmechanismen als auch die zugrunde liegenden Annahmen.

Authentifizierung und Verbindungsschutz gehören zusammen

Die Auswahl von Kerberos beantwortet die Frage, wie sich der Client authentifiziert. Der Schutz von Directory-Abfragen und Antworten ist eine separate Betrachtung.

TLS sorgt für Transportverschlüsselung. LDAP-SASL-Mechanismen können abhängig von Mechanismus und Konfiguration ebenfalls Sicherheitsschichten aushandeln. Allein die Auswahl von Kerberos legt daher nicht fest, welcher Schutz für den gesamten nachfolgenden LDAP-Datenverkehr aktiv ist. Prüfen Sie Authentifizierung und Verbindungsschutz gemeinsam anhand der Anforderungen Ihres Directory. Die LDAP-Sicherheitsspezifikation beschreibt diese Unterscheidung.

Das ist besonders bei einer Migration hilfreich: Dokumentieren Sie zunächst den Schutz Ihrer bestehenden Verbindung, bevor Sie die Authentifizierungsmethode ändern, und prüfen Sie anschließend die neue Verbindung anhand derselben Anforderungen.

Bereiten Sie Ihre Umgebung vor dem Wechsel vor

Kerberos benötigt mehr als nur ein gültiges Kontopasswort. Einige Infrastrukturprüfungen können bei der Fehlersuche viel Zeit sparen:

• DNS und Servernamen: Prüfen Sie, ob der Hostname des Directory-Servers korrekt aufgelöst wird. Kerberos-Serviceidentitäten hängen von Namen ab; eine IP-Adresse oder ein unerwarteter Alias kann zu einem anderen Ergebnis führen.
• Service Principal Names: Stellen Sie sicher, dass der vorgesehene LDAP-Dienst den passenden SPN besitzt und doppelte Registrierungen keine Mehrdeutigkeit erzeugen.
• Zeitsynchronisierung: Halten Sie Discovery Server und Domain-Infrastruktur zeitlich synchron. Kerberos verwendet Zeitstempel bei der Validierung von Authentifizierungsvorgängen.
• KDC-Erreichbarkeit: Stellen Sie sicher, dass der Discovery Server sowohl die benötigte Kerberos-Infrastruktur als auch den LDAP-Endpunkt erreichen kann.

Dies sind allgemeine Kerberos-Abhängigkeiten und keine zusätzlichen Discovery-Berechtigungen. Microsofts Leitfaden zur Kerberos-Fehlerbehebung ist ein guter Ausgangspunkt, wenn die Authentifizierung fehlschlägt. Die JDisc-Discovery-Szenarien zeigen außerdem, wie Active-Directory-Zugangsdaten in eine umfassendere Discovery-Konfiguration eingebettet werden.

Beginnen Sie mit einer einzelnen LDAP-Verbindung und einem Konto, das über die erforderlichen Leseberechtigungen im Directory verfügt. Prüfen Sie zunächst die Authentifizierung und anschließend, ob die erwarteten Directory-Informationen tatsächlich gelesen werden können. Eine erfolgreiche Anmeldung und ausreichende Zugriffsrechte sind zwei getrennte Prüfungen: Kerberos stellt die Identität fest, während die Directory-Berechtigungen bestimmen, worauf diese Identität zugreifen darf. Wenn die Erreichbarkeit Teil des Problems ist, bietet die JDisc-FAQ zu Discovery-Anforderungen und Fehlerbehebung eine hilfreiche Referenz zu Protokollen, Ports und häufigen Zugriffsproblemen.

Ein sinnvoller nächster Schritt für Ihre Directory-Sicherheit

Mit der Kerberos-Unterstützung ist Simple Bind nicht mehr die einzige Möglichkeit, Benutzer für LDAP in JDisc Discovery zu authentifizieren. Sie verfügen jetzt über eine Ticket-basierte Option, die Ihre Directory-Sicherheitsziele unterstützen und Ihre bestehende Kerberos-Vertrauensinfrastruktur nutzen kann.

Prüfen Sie zunächst gemeinsam mit Ihren Directory-Administratoren eine bestehende LDAP-Verbindung. Stimmen Sie Authentifizierungsmethode, Verbindungsschutz und erforderliche Berechtigungen ab und validieren Sie die Konfiguration, bevor Sie sie breiter einsetzen.