/etc/systemd/timesyncd sollte denselben NTP-Server haben, am besten einen lokalen
root@linux:~# timedatectl
Local time: Tue 2025-01-01 02:01:01 CET
Universal time: Tue 2025-01-01 01:01:01 UTC
RTC time: Tue 2025-01-01 01:01:01
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no_kerberos.domain.tld TXT "DOMAIN.TLD"
_kerberos._tcp.domain.tld. IN SRV 1 0 88 auth.domain.tld.
_kerberos-adm._tcp.domain.tld. IN SRV 1 0 749 auth.domain.tld.
_kpasswd._tcp.domain.tld. IN SRV 1 0 464 auth.domain.tld.Kerberos scheint nicht auf UDP zu lauschen, ich setze daher nur _tcp.
Wer OpenWRT hat und die TXT-Einstellungen sucht die ab 2024 auf wundersame Weise in Luci verschwunden sind: Die TXT-Records kann man in /etc/dnsmasq.conf setzen:
txt-record=_kerberos.domain.tld,"DOMAIN.TLD"Wir brauchen diese Records zwar nicht zwingend, aber die Client-Config ist so schlanker und der Laptop z.B. auch in anderen Domänen ohne Angabe von @DOMAIN.TLD daheim.
https://ubuntu.com/server/docs/how-to-set-up-kerberos-with-openldap-backend
taugt als Tut
krb5-kdc verteilt, krb5-admin-server nimmt alle kadmin-anfragen entgegen. krb5-kdc-ldap brauchen wir um Kerberos-Daten im LDAP-Verzeichnis zu hinterlegen (🦴 Principals)
root@server:~# apt install krb5-user krb5-kdc krb5-admin-server krb5-kdc-ldapAls erstes brauchen wir LDAP als Backend für 🦴 Kerberos Principals und ein paar Kerberos-Server-Einstellungen wie Ticket-Lebenszeit, etc.
Schema auf OpenLDAP-Server installieren:
root@ldap:~# cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz /etc/ldap/schema/
root@ldap:~# gunzip /etc/ldap/schema/kerberos.schema.gz
root@ldap:~# schema2ldif /etc/ldap/schema/kerberos.schema /etc/ldap/schema/kerberos.ldif
root@ldap:~# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/kerberos.ldifDazu einen neuen Index in der gewünschten DB (olcDatabase={1}mdb,cn=config i.d.R.) eintragen: olcDbIndex: krbPrincipalName eq,pres,sub
Wir brauchen in LDAP jetzt 2 User für die Dienste kdc und kadmin (Verteiler von Tickets und Kerberos-Admin)
Wo die liegen ist zwar egal, aber ou=Dienste,dc=domain,dc=tld bietet sich natürlich an:
uid=kdc,ou=Dienste und uid=kadmin,ou=Dienste anlegen (objectClass account und simpleSecurityObject)
dn: uid=kadmin,ou=Dienste,dc=domain,dc=tld
objectClass: account
objectClass: simpleSecurityObject
objectClass: top
uid: kadmin
description: Kerberos Admin-Server-Account
dn: uid=kdc,ou=Dienste,dc=domain,dc=tld
objectClass: account
objectClass: simpleSecurityObject
objectClass: top
uid: kdc
description: Kerberos Key-Distribution-Center (TGT-Server)für beide manuell Passwörter (userPassword SSHA) setzen, das geht in Apache Directory Studio oder per CLI:
root@ldap:~# ldappasswd -Y EXTERNAL -H ldapi:/// -S uid=kdc,ou=Dienste,dc=domain,dc=tld
... enter new password ...
root@ldap:~# ldappasswd -Y EXTERNAL -H ldapi:/// -S uid=kadmin,ou=Dienste,dc=domain,dc=tld
... enter new password ...Das Thema olcAccess behandeln wir nochmal ausführlicher in OpenLDAP-olcAccess
Für Kerberos ist wichtig, dass wir allen DNs die einen krbPrincipalKey haben (also ein Passwort) ähnliche Rechte wie für userPassword geben und beiden uid=kdc und uid=kadmin ähnliche Rechte wie anderen lookup- oder users-Diensten die Nutzerdaten selektiv lesen /schreiben können.
Die Reihenfolge kann im Einzelfall anders sein, die Regeln sehen aber dann in etwa so aus:
# Kerberos Passwörter nur für Authentifizierung, für kdc lesen, kadmin und der User selbst dürfen schreiben
{~2} to attrs=krbPrincipalKey by anonymous auth by dn.exact="uid=kdc,ou=Dienste,dc=domain,dc=tld" read by dn.exact="uid=kadmin,ou=Dienste,dc=domain,dc=tld" write by self write by * none
# Dieser Eintrag MUSS sein wenn in OpenLDAP nicht alle alles lesen dürfen, da kadmin den ganzen Baum durchsucht. 👷👷👷 - prüfen ob man das noch weiter einschränken kann.
{~8}to * by dn.exact="uid=kdc,ou=Dienste,dc=domain,dc=tld" search by dn.exact="uid=kadmin,ou=Dienste,dc=domain,dc=tld" read by * none break
# Lese/Schreibrechte für den Kerberos-Container
[~9] to dn.subtree="cn=krbContainer,ou=Dienste,dc=domain,dc=tld" by dn.exact="uid=kdc,ou=Dienste,dc=domain,dc=tld" read by dn.exact="uid=kadmin,ou=Dienste,dc=domain,dc=tld" write by * none breakhttps://wiki.debian.org/LDAP/OpenLDAPSetup#Kerberos
/etc/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 750,88
[realms]
DOMAIN.TLD = {
database_module = openldap_ldapconf
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
# Wird in LDAP überschrieben
# max_life = 24h 0m 0s
# means you can get a new ticket with the old one
# max_renewable_life = 7d 0h 0m 0s
#master_key_type = aes256-cts
#supported_enctypes = aes256-cts:normal aes128-cts:normal
# default_principal_flags = +preauth
}
[dbmodules]
openldap_ldapconf = {
db_library = kldap
#ldap_kerberos_container_dn = cn=krbContainer,ou=kerberos,ou=Services,dc=domain,dc=tld
ldap_kerberos_container_dn = cn=krbContainer,ou=Dienste,dc=domain,dc=tld
# if either of these is false, then the ldap_kdc_dn needs to
# have write access as explained above
disable_last_success = true
disable_lockout = true
ldap_conns_per_server = 5
ldap_servers = ldaps://ldap.domain.tld/
# this object needs to have read rights on
# the realm container, principal container and realm sub-trees
#ldap_kdc_dn = "uid=kdc,ou=kerberos,ou=Services,dc=domain,dc=tld"
ldap_kdc_dn = "uid=kdc,ou=Dienste,dc=domain,dc=tld
# this object needs to have read and write rights on
# the realm container, principal container and realm sub-trees
#ldap_kadmind_dn = "uid=kadmin,ou=kerberos,ou=Services,dc=domain,dc=tld"
ldap_kadmind_dn = "uid=kadmin,ou=Dienste,dc=domain,dc=tld"
# this file will be used to store plaintext passwords used
# to connect to the LDAP server
ldap_service_password_file = /etc/krb5kdc/service.keyfile
# OR, comment out ldap_kdc_dn, ldap_kadmind_dn and
# ldap_service_password_file above and enable the following
# two lines, if you skipped the step of creating entries/users
# for the Kerberos servers
#ldap_kdc_sasl_mech = EXTERNAL
#ldap_kadmind_sasl_mech = EXTERNAL
#ldap_servers = ldapi:///
}Jetzt nutzen wir das coole kdb5_ldap_util um den Kerberos-Container in LDAP anzulegen und für die beiden Dienst-DNs die Passwörter in /etc/krb5/service.keyfile zu speichern.
ldap-sachen anlegen:
#neues DB-Master passwort setzen, cn=krbContainer,ou=Dienste,dc=domain,dc=tld anlegen
root@auth:~# kdb5_ldap_util -D cn=Verwalter,dc=domain,dc=tld create -subtrees dc=domain,dc=tld -r DOMAIN.TLD -s -H ldaps://ldap.domain.tld/Jetzt die Passwörter für uid=kdc und uid=kadmin hinterlegen die Kerberbos braucht um sich zu LDAP zu verBinden
root@auth:~# kdb5_ldap_util -D cn=Verwalter,dc=domain,dc=tld stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kdc,ou=Dienste,dc=domain,dc=tld
root@auth:~# kdb5_ldap_util -D cn=Verwalter,dc=domain,dc=tld stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kadmin,ou=Dienste,dc=domain,dc=tldWer jetzt schon etwas verwirrt ist: Wir nutzen LDAP als Speicher für Kerberos-Daten, aber LDAP auch weiterhin für die Nutzeranmeldung, z.B. durch Postfix. Jetzt wäre natürlich blöd, wenn wir für Kerberos und für Nutzer in LDAP 2 Passwörter einstellen müssten oder unsere wundervolle LDAP-Ordnung verlieren.
Daher können wir für bestimmte Nutzer als Passwort den Platzhalter {SASL}user@DOMAIN.TLD einstellen den OpenLDAP versteht und das Passwort mit SASL an Kerberos zur Prüfung weiterreicht. Meeeeega, oder? :)
Dafür installieren wir sasl2-bin (sollte schon laufen)
root@ldap:~# apt install sasl2-binund für much more fun später
apt install libsasl2-modules-gssapi-mit /etc/default/saslauthd ändern
START=yes
MECHANISMS="kerberos5"ldapuser in sasl gruppe holen
usermod -a -G sasl openldap/etc/ldap/sasl2/slapd.conf
pwcheck_method: saslauthd👷👷👷 wofür brauchen wir den? Ich bin müüüüde
Auch wenn Du müde bist, in cn=DOMAIN.TLD,cn=krbContainer,ou=Dienste,dc=domain,dc=tld
unbedingt noch krbMaxRenewableAge auf 604800 setzen und krbMaxTicketLife auf 86400, diese Werte auch in sssd.conf für Clienten eintragen.
kadmin.local starten, neues principal für den ldap-server erstellen:
kadmin.local
addprinc -randkey ldap/ldapserverhostname.domain.tld
ktadd -k /etc/ldap/krb5.keytab-ldap ldap/ldapserverhostname.domain.tld
q
chown openldap:openldap /etc/ldap/krb5.keytab-ldap
chmod 600 /etc/ldap/krb5.keytab-ldapDiesen key noch in /etc/default/slapd exportieren:
export KRB5_KTNAME=/etc/ldap/krb5.keytab-ldap👷👷👷 Warum liegt diese Datei in /etc/ldap/sasl2 und heisst so? Das klingt zwar wie eine Einstellung die man in OpenLDAP / OLC einträgt, aaaber das ist einfach der Pfad in dem SASL2 seine Einstellungen für openldap / slapd abholt.
// brauchen wir nicht mit LDAP: Jetzt an die Instances denken. Die sind standardmässig unter /etc/krb5kdc/kadm5.acl
/etc/krb5kdc/kadm5.acl
*/admin@DOMAIN.TLD *kadmin/admin ist der einzige Principal der in der Kerboros-Datebank alles darf. Wenn Du das wieder vergisst: Das legt NICHT fest welcher Principal welchen Service nutzen darf.
cn=config SASL stuff for GSSAPI:
If you configure the olcSaslRealm then it will be inserted as an extra component in the authorization DN, regardless of any Kerberos realms in use. For domain, if you set olcSaslRealm to domain.tkd then you will get:
das brauchen wir also nicht zwingend, auch olcSaslHost scheint entweder ignoriert zu werden oder ist mit localhost gut dran.