Ich habe einen vorhandenen OpenLDAP-Server auf Ubuntu Server 22.04 und versuche, damit einen Kerberos-Server einzurichten. Dabei folge ich dieser Anleitung:https://ubuntu.com/server/docs/service-kerberos-with-openldap-backend
Die Konten wurden erstellt und getestet, sie funktionieren einwandfrei (ich referenziere sie per cn, aber sie haben eine UID; ich habe sie erst im Apache-Verzeichnis Studio erstellt). Ich habe „dpkg-reconfigure krb5-config“ ausgeführt und /etc/krb5.conf bearbeitet, um meinen Server und Realm hinzuzufügen. Eine Sache, die nicht in diesem Dokument steht, die ich aber woanders gesehen habe, ist, einen Abschnitt „[domain_realm]“ zu erstellen und meine Domäne hinzuzufügen, was ich getan habe, aber es hat nicht geholfen. Ich habe einen Protokollierungsabschnitt erstellt, der eine Änderung der systemd-Dienste erfordert, um das Schreiben in /var/log/kerberos zu ermöglichen, aber das ist in Ordnung. Dann führe ich den Befehl „kdb5_ldap_util“ wie aufgeführt aus, und nach Eingabe der Passwörter scheint er erfolgreich abgeschlossen zu sein. Ich mache den Stash für die Passwörter für kdc-service und kadmin-service, das wird erfolgreich abgeschlossen. Ich erstelle die Datei kadm.acl, das ist in Ordnung, und wenn ich dann versuche, den Dienst zu starten, erhalte ich Folgendes in krb5kdc.log:
krb5kdc[712216](Error): Cannot find master key record in database - while fetching master keys list for realm SUBDOMAIN.DOMAIN.COM
Wenn ich dann "kadmin.local" ausführe, erhalte ich Folgendes:
Authenticating as principal root/[email protected] with password.
kadmin.local: Cannot find master key record in database while initializing kadmin.local interface
Wie sich herausstellt, wird die Datei /var/lib/krb5kdc/principal nie erstellt. Ich bin mir nicht sicher, was ich sonst noch tun soll, aber an diesem Punkt stecke ich fest und wäre für jede Hilfe dankbar. Nachfolgend die Konfigurationsdateien mit geänderter Domäne und Subdomäne:
/etc/krb5.conf:
[libdefaults]
default_realm = SUBDOMAIN.DOMAIN.COM
# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
# The following encryption type specification will be used by MIT Kerberos
# if uncommented. In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# The only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).
# default_tgs_enctypes = des3-hmac-sha1
# default_tkt_enctypes = des3-hmac-sha1
# permitted_enctypes = des3-hmac-sha1
# The following libdefaults parameters are only for Heimdal Kerberos.
fcc-mit-ticketflags = true
[logging]
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmin.log
default = FILE:/var/log/kerberos/krb5lib.log
[realms]
SUBDOMAIN.DOMAIN.COM = {
kdc = hostname.subdomain.domain.com
admin_server = hostname.subdomain.domain.com
default_domain = subdomain.domain.com
database_module = openldap_ldapconf
}
[domain_realm]
.subdomain.domain.com = SUBDOMAIN.DOMAIN.COM
subdomain.domain.com = SUBDOMAIN.DOMAIN.COM
[dbdefaults]
ldap_kerberos_container_dn = cn=krbContainer,dc=subdomain,dc=domain,dc=com
[dbmodules]
openldap_ldapconf = {
db_library = kldap
# if either of these is false, then the ldap_kdc_dn needs to
# have write access
disable_last_success = true
disable_lockout = true
# this object needs to have read rights on
# the realm container, principal container and realm sub-trees
ldap_kdc_dn = "cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com"
# this object needs to have read and write rights on
# the realm container, principal container and realm sub-trees
ldap_kadmind_dn = "cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com"
ldap_service_password_file = /etc/krb5kdc/service.keyfile
ldap_servers = ldapi:///
ldap_conns_per_server = 5
}
/etc/krb5kdc/kadm5.acl:
*/[email protected] *
/etc/krb5kdc/kdc.conf:
[kdcdefaults]
kdc_ports = 750,88
[realms]
SUBDOMAIN.DOMAIN.COM = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
#supported_enctypes = aes256-cts:normal aes128-cts:normal
default_principal_flags = +preauth
}
Bearbeiten: Laut dem Kommentar von user1686 kann ich jetzt sehen, dass ich ein potenzielles Zugriffsproblem für die Konten habe. Ich bin diesbezüglich etwas überfordert, aber mit „slapcat -b cn=config“ habe ich die folgenden olcAccess-Regeln:
olcAccess: {0}to * by dn="cn=admin,dc=subdomain,dc=domain,dc=com" manage by dn="cn=surfrock66,ou=accounts,dc=subdomain,dc=domain,dc=com" manage by dn="cn=ldapbinduser,ou=accounts,dc=subdomain,dc=domain,dc=com" read by * break
olcAccess: {1}to dn.children="ou=accounts,dc=subdomain,dc=domain,dc=com" attrs=userPassword,shadowExpire,shadowInactive,shadowLastChange,shadowMax,shadowMin,shadowWarning by self write by anonymous auth
olcAccess: {2}to attrs=krbPrincipalKey by anonymous auth by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by self write by * none
olcAccess: {3}to dn.subtree="cn=krbContainer,dc=subdomain,dc=domain,dc=com" by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by * none
olcAccess: {4}to dn.subtree="dc=subdomain,dc=domain,dc=com" by self read
2022.12.08-08-36 PST Edit: Ich bin also viel weiter und habe Folgendes gemacht:
addprinc ldap/[email protected]
ktadd -k /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab ldap/hostname.subdomain.domain.com
chown openldap:openldap /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab
chmod 640 /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab
Ich habe /etc/default/slapd bearbeitet und Folgendes hinzugefügt:
export KRB5_KTNAME="FILE:/etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab"
Als ich den Dienst neu gestartet habe, funktionierte testsaslauthd immer noch, aber ldapsearch -D nicht. Ich frage mich, ob ich eine Konfigurationsänderung in LDAP vornehmen muss. Aus einer der Ressourcen, mit denen ich gearbeitet habe, habe ich dieses ldif für die Konfiguration erstellt, aber letztendlich glaube ich nicht, dass ich verstehe, was es tun wird und ob es richtig war:
dn: cn=config
changetype: modify
add: olcSaslHost
olcSaslHost: hostname.subdomain.domain.com
-
add: olcSaslRealm
olcSaslRealm: SUBDOMAIN.DOMAIN.COM
-
add: olcAuthzRegexp
olcAuthzRegexp: {0}"cn=([^/]*),cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=accounts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {1}"cn=host/([^/]*).subdomain.domain.com,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=hosts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {2}"uid=ldap/admin,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=admin,dc=subdomain,dc=domain,dc=com"
Ich denke, das ist der letzte fehlende Schritt? Gibt es etwas in der Konfiguration, das LDAP auf SASL verweist? Oder gehe ich das völlig falsch an?
Antwort1
principalist die Datei, die die KDC-Datenbank im DB2-Format enthält. Sie wird nicht auf Ihrem System erstellt, da Sienicht verwendendas db2Backend – Sie verwenden LDAP, das ersetztallelokaler Speicher für das KDC – eine lokale Datenbankdatei ist also unnötig und für Ihr Problem irrelevant.
Wenn Sie den Anweisungen entsprechend vorgegangen sind kdb5_ldap_util create, sollten Sie über LDAP prüfen, ob die erforderlichen Einträge tatsächlich erstellt wurden. Es sollte mindestens ein Eintrag für K/M@<realm>und ein weiterer für vorhanden sein krbtgt/<realm>@<realm>. Die Fehlermeldung bezieht sich auf den Eintrag „K/M“, ein Pseudo-Principal, der den Datenbank-Mkey enthält (der mit dem Kennwort „Master Key“ verschlüsselt ist).
Überprüfen Sie LDAP unbedingt mit dem KDC-Konto, falls es nicht über die erforderlichen Berechtigungen zum Lesen der Kerberos-LDAP-Objekte verfügt. (Die Kontenbrauchenum eine UID zu haben; sie werden nur als LDAP-Bind-Konten verwendet, nicht als lokale Unix-Konten.)
Da Ubuntu manchmal AppArmor verwendet, achten Sie darauf, dass Sie dmesgnach AVC-Ablehnungsmeldungen suchen. Es könnte sein, dass dem KDC das Lesen von „service.keyfile“ oder der Zugriff auf Ihren OpenLDAP-Socket nicht gestattet ist.
Aktivieren Sie außerdem den statsProtokollierungsgrad in Ihrem LDAP-Server, damit alle Abfragen protokolliert werden. Dies könnte beispielsweise zeigen, dass das KDC unter einem anderen DN sucht (normalerweise würde „ldap_kerberos_container_dn“ neben anderen dbmodules-Parametern festgelegt).
Wenn sich schließlich strace kadmin.localherausstellt, dass das Tool keine Verbindung zu LDAP herstellt, sondern stattdessen versucht, auf eine lokale db2-Datei zuzugreifen, ist es möglich, dass Sie eine Konfiguration kdc.conf(die KDC-spezifische Konfigurationsdatei) haben, die die systemweiten Einstellungen in krb5.conf überschreibt. Normalerweise wird die KDC-Konfiguration aus /var/lib/krb5kdc/kdc.confden globalen Einstellungen von krb5.conf geladen und hat Vorrang vor diesen.
(Wenn Sie zusätzlichwarBei Verwendung von db2 wird die Hauptdatenbank beim ersten Start dennoch nicht automatisch erstellt – dies muss manuell erfolgen, indem Sie kdb5_util create [-s]den Hauptverschlüsselungsschlüssel ausführen und angeben, so wie Sie es für das LDAP-Backend mit „kdb5_ldap_util create“ getan haben.)
Eine Sache, die nicht in diesem Dokument steht, die ich aber woanders gesehen habe, ist, einen Abschnitt „[domain_realm]“ zu erstellen und ihm meine Domäne hinzuzufügen, was ich getan habe, aber es hat nicht geholfen.
Dies ist nur für Kerberos-Clients erforderlich, wenn Tickets für einen Hostnamen abgerufen werden, der nicht 1:1 seinem Realm zugeordnet werden kann (das typische Beispiel ist mit.edu → ATHENA.MIT.EDU). Für den Start des KDC ist dies nicht relevant.
Ich habe einen Protokollierungsabschnitt erstellt, der die Änderung der systemd-Dienste erfordert, um das Schreiben in /var/log/kerberos zu ermöglichen.
Dies ist nicht der Fall, wenn Sie sich stattdessen bei anmelden SYSLOG, was vermutlich die Absicht desjenigen war, der die systemd-Dienste für Ubuntu geschrieben hat.
ist das nicht da, da mein Speicher in LDAP ist?
Nein, die Datei /etc/krb5.keytab ist nicht Teil der KDC-Datenbank – sie gehört zurGastgeberals „Domänenmitglied“ und speichert das Äquivalent des Kerberos-Passworts des Computerkontos. Jeder Computer in Ihrem Kerberos-Bereich sollte seine eigene /etc/krb5.keytab mit mindestens dem host/<fqdn>Hauptcomputer haben.
Ich versuche, die LDAP-Passthrough-Authentifizierung zum Laufen zu bringen, damit das Kerberos-Passwort das echte ist. Ich stelle fest, dass ein Großteil der Dokumentation älter ist. Ich sehe, dass die meisten Leute saslauthd empfehlen, was ich, glaube ich, eingerichtet habe, aber jetzt sucht es nach /etc/krb5.keytab
Für OpenLDAP benötigen Sie im Allgemeinen saslauthd.
- Beim Binden an einen DN mit
userPassword: {SASL}foo@BARverwendet slapd die „Passwortprüfungs“-Funktionen von libsasl. - Abhängig von der konfiguriertenpwcheck_method, libsasl wird saslauthd kontaktieren, um das Passwort zu bestätigen.
- saslauthd verwendet das über seine
-aOption konfigurierte Backend, um die eigentliche Überprüfung durchzuführen. - Mit dem
-a krb5Backend versucht saslauthd, mit dem angegebenen Benutzernamen und Passwort (entsprichtkinit) ein erstes Kerberos-Ticket von einem KDC zu erhalten. - Wenn ein erstes Ticket erfolgreich erworben wurde, fordert saslauthd zusätzlich einServiceticket für sich selbstund versucht, es mithilfe des Keytabs der Maschine zu entschlüsseln.
- Wenn das Serviceticket erworben werden konnteund entschlüsselt,das Passwort wird akzeptiert.
Der letzte Schritt ist erforderlich, um KDC-Spoofing-Angriffe zu verhindern. Traditionell haben Kerberos-KDCs Tickets ausgegeben, ohne Ihr Passwort zu validieren (ein falsches Passwort bedeutete nur, dass der Client das empfangene Ticket nicht entschlüsseln konnte) und ein böswilliger KDC kann dies immer noch tun – „Preauth“ ist auf Protokollebene nicht obligatorisch. Daher muss saslauthd dasselbe tun wie jeder andere kerberisierte Dienst, um zu überprüfen, ob das Ticket legitim ist – versuchen, es mithilfe eines Service-Keytabs zu entschlüsseln. (Sowohl pam_krb5 als auch Windows tun dasselbe während AD-Anmeldungen.)
Ich habe host/hostname.fqdn@REALM und ldap/hostname.fqdn@REALM erstellt. Ich habe ein Keytab für LDAP erstellt; ich habe das Passwort eines Benutzers in „{SASL}name@REALM“ umgewandelt. Wenn ich testsaslauthd für diesen Benutzer verwende, ist das erfolgreich. Wenn ich ldapsearch für diesen Benutzer verwende, sind die Anmeldeinformationen ungültig. Ich glaube, LDAP kommuniziert nicht mit saslauthd? Unter „Kerberos-Authentifizierung“ habe ich hier die Konfigurationen hinzugefügt: help.ubuntu.com/community/OpenLDAPServer, aber wenn ich „ldapsearch -Y GSSAPI“ mache, erhalte ich „GSSAPI-Fehler: Es wurden keine Anmeldeinformationen bereitgestellt...“
-Y GSSAPIIstDirekteKerberos-Authentifizierung – völlig getrennt von saslauthd und Passwort-Passthrough. Das heißt, slapd erhält nicht einmal ein Kerberos-Passwort – es erhält nur ein KerberosFahrkarteund validiert es intern anhand seines Service-Keytabs.
Für SASL GSSAPI benötigt der slapd-Dienst selbst – nicht saslauthd – ein Keytab für
ldap/<fqdn>. (Standardmäßig suchen alle Dienste ihre Schlüssel im System /etc/krb5.keytab, aber aus Sicherheitsgründen ist es möglicherweise besser, die Dinge getrennt zu halten und KRB5_KTNAME von slapd auf einen anderen Pfad festzulegen – auf diese Weise müssen Sie ihm keinen Lesezugriff auf das System-Keytab erteilen.)Der Kunde muss außerdemwissendass es dazu gedacht ist, ein Ticket für anzufordern
ldap/<fqdn>, daher wird die Verbindung zu einer IP-Adresse wahrscheinlich nicht funktionieren (es sei denn, es ist das richtige rDNS eingestellt) – Sie sollten speziell eine Verbindung zu ldap://<fqdn> herstellen. (Es ist ein sehr ähnliches Problem wie TLS SNI oder Hostnamen in TLS-Zertifikaten).Führen Sie im Zweifelsfall einen Export durch,
KRB5_TRACE=/dev/stderrbevor Sie den Client aufrufen, um herauszufinden, für welchen Auftraggeber ein TGS-REQ erstellt werden soll (oder sehen Sie sich die KDC-Protokolle oder eine Netzwerkerfassung an).Der Kunde muss bereits über dieanfänglichKerberos-Ticket (krbtgt/REALM) vorhanden, das heißt, Sie müssen
kinitvorher. Wenn Sie noch kein TGT haben, Kerberos-Clientswerde nicht fragenfür Ihr Passwort – die Authentifizierung schlägt sofort fehl.
Die Passwortweiterleitung ist nur für „einfache“ Bindungen ( ldapsearch -D <user_dn> -W) und SASL PLAIN-Bindungen relevant. Testen Sie zuerst die „einfache“ Bindung (SASL PLAIN können Sie größtenteils ignorieren).
Antwort2
Sie müssen libsasl2 auf Ihrem Betriebssystem installieren und dem OpenLDAP-Benutzer den Besitz Ihrer krb5.keytab übertragen.
unter Debian:
sudo apt installiere libsasl2-2 libsasl2-modules-gssapi-mit
und dann
sudo chown openldap:openldap /etc/krb5.keytab oder anderer Keytab
Bearbeiten: aber seien Sie vorsichtig mit mehreren Keytabs auf derselben Maschine/demselben Container (mit mehreren Servern).