Oh, es ist lange her. Mal sehen, woran ich mich erinnern kann.
Ja, das kann auf jeden Fall verwirrend sein, da Sie Kerberos zur Authentifizierung für LDAP verwenden können und Kerberos auch LDAP als Backend verwenden kann. Obwohl es sich nicht um dasselbe handelt, ist es oft schwer zu unterscheiden, worüber man gerade spricht, wenn man danach sucht. Ich kann nur über LDAP sprechen, das Kerberos für die Authentifizierung verwendet, da ich keine Erfahrung damit gemacht habe.
- Ihre Intuition hat Recht, dass der Kerberos-Server verwendet wird. Nach meinem Verständnis fordert der Client ein TGT vom Kerberos-Server für den LDAP-Server an (unter Verwendung des Dienstprinzipalnamens "ldap/hostname@DOMAIN.NAME" oder ähnlich). Damit kann sich der Client beim LDAP-Server anmelden, da er das Ticket validieren kann. Das Clientkennwort selbst wird niemals an den LDAP-Server gesendet.
- Dies ist, wenn Sie LDAP als Backend für Kerberos verwenden. Sie können hier ein LDAP-Verzeichnis verwenden, um Attribute und Werte für verschiedene Zwecke zu speichern. Sie müssen LDAP natürlich nicht als Backend für Kerberos verwenden.
Die Dinge werden noch schwieriger, wenn sie anfangen, über SASL zu sprechen, da es schwierig ist zu sagen, ob sie am Front-End oder am Back-End von LDAP über SASL sprechen. Werden die Clients also zur Authentifizierung bei LDAP verwendet? Oder wird es von LDAP verwendet, um das Kennwort an eine andere Authentifizierungsquelle weiterzugeben? Nur ein paar Vorsichtsmassnahmen.
Nebenbei: Es ist möglich, ein einfaches Binden mit LDAP zu verwenden. Senden Sie das Kennwort an den LDAP-Server, der das Kennwort an eine andere Authentifizierungsquelle (wie Kerberos) weiterleitet. Wenn Sie so etwas tun, ist es nett, weil das Kennwort selbst nicht in LDAP gespeichert ist. Da es sich bei einer einfachen Bindung jedoch um Klartext handelt, sollten Sie sicherstellen, dass TLS zwischen dem Client und dem LDAP-Server verwendet wird.
Hoffe das hilft nur ein bisschen. Klingt, als hätten Sie im Grunde die richtige Idee.