15 OpenLDAP mit Kerberos

15.7	Kerberos Policies

Beim Anlegen eines Principals haben Sie wahrscheinlich schon die Meldung gelesen, dass für den gerade angelegten Principal keine Policy festgelegt wurde. Das ist auch korrekt, denn noch gibt es keine Policies. In diesem Abschnitt geht es darum, Policies anzulegen und bestimmten Benutzer zuzuweisen.

Um die Richtlinien der Passwörter hinsichtlich der Passwortlänge und -komplexität zu ändern, gibt es im Kerberos die Policies. Mit diesen Policies können Sie unterschiedliche Passwortrichtlinien für verschiedene Benutzer erstellen. Die Policies werden mit dem kadmin erzeugt. Für die Policies gibt es die folgenden Parameter:

maxlife
maxlife legt die maximale Gültigkeit des Passworts fest.

minlife
Mit minlife legen Sie die minimale Gültigkeit des Passworts fest. Immer wenn Sie den Parameter maxlife verwenden, ist es sinnvoll, dass Sie zusätzlich den Parameter minlife verwenden. Denn sonst könnte ein Benutzer beliebig oft sein Passwort ändern und somit die im Parameter history festgelegte Anzahl an alten Passwörtern erreichen und dann sein ursprüngliches Passwort wieder setzen.

minlength
Verwenden Sie minlength, legen Sie damit die minimale Länge des Passworts fest.

minclasses
Auch die Komplexität des Passworts können Sie bestimmen, dafür gibt es den Parameter minclasses. In dem Parameter legen Sie die Anzahl der unterschiedlichen Klassen der Sonderzeichen fest, die ein Passwort enthalten muss.
Die folgenden Klassen werden von Kerberos verwendet:

Kleinbuchstaben

Großbuchstaben

Zahlen

Punkte

andere Sonderzeichen

history
Möchten Sie eine History der bereits verwendeten Passwörter Ihrer Benutzer führen, können Sie im Parameter history festlegen, wie viele alte Passwörter für jeden einzelnen Principal gespeichert werden.

Hinweis: Diesen Parameter können Sie nicht verwenden, wenn Sie Kerberos zusammen mit LDAP für die Benutzerverwaltung einsetzen wollen.

maxfailure
Wollen Sie die Anzahl der fehlerhaften Anmeldungen eines Benutzers begrenzen, können Sie dazu maxfailure nutzen. Die hier vergebene Zahl legt fest, nach wie vielen fehlerhaften Anmeldungen das Konto des Benutzers gesperrt wird.

failurecountinterval
Sie können mit failurecountinterval festlegen, wie lange die Zeit zwischen zwei fehlerhaften Anmeldungen sein darf. Ist die Zeit abgelaufen, wird der Zähler für die falschen Anmeldungen zurückgesetzt. Tragen Sie hier einen Wert von 0 ein, würde der Zähler nie zurücksetzen. Ist die eingestellte Zeit abgelaufen, wird der Zähler maxfailure zurückgesetzt.

lockoutduration
lockoutduration legt fest, wie lange ein Konto gesperrt wird, wenn der Wert von maxfailure erreicht wurde. Ein Wert von 0 sperrt das Konto für immer oder so lange, bis Sie das Konto mit dem Kommando kadmin: modify_principal -unlock <Konto> wieder freischalten.

Da es sich bei den Policies um Eigenschaften des Kerberos-Servers handelt, werden die Policies wieder mit dem Programm kadmin auf dem Admin-Server angelegt und verwaltet. In Listing 15.38 sehen Sie im ersten Teil, wie Policies erstellt werden. Im zweiten Teil des Listings werden dann alle gerade erstellten Policies aufgelistet. Zum Abschluss des Listings sehen Sie dann noch, wie Sie bestehende Policies verändern können:

Listing 15.38 Erstellen und Auflisten von Policies

kadmin: add_policy -minlength 8 -minclasses 3 admin kadmin: add_policy -minlength 8 -minlife "2 days" \ -maxlife "90 days" -minclasses 3 user kadmin: add_policy -minlength 8 -minclasses 3 guests kadmin: list_policies admin guests host kadmin: get_policy user Richtlinie: user Maximum password life: 90 days 00:00:00 Minimum password life: 2 days 00:00:00 minimale Passwortlänge: 8 minimale Anzahl von Passwortzeichenklassen: 3 Anzahl aufbewahrter alter Schlüssel: 1 maximale Anzahl falscher Passworteingaben vor dem Sperren: 0 Rücksetzintervall für zu viele falsch eingebene Passwörter: 0 days 00:00:00 Passwortsperrdauer: 0 days 00:00:00 kadmin: modify_policy -minlength 10 admin kadmin: get_policy admin Maximum password life: 0 days 00:00:00 Minimum password life: 0 days 00:00:00 minimale Passwortlänge: 10 minimale Anzahl von Passwortzeichenklassen: 3 Anzahl aufbewahrter alter Schlüssel: 1 maximale Anzahl falscher Passworteingaben vor dem Sperren: 0 Rücksetzintervall für zu viele falsch eingebene Passwörter: 0 days 00:00:00 Passwortsperrdauer: 0 days 00:00:00

Hinweis: Der Name der Policies hat nichts mit bestimmten Principals zu tun, Sie können an der Stelle beliebige Namen verwenden und auch beliebig viele Policies erstellen.

In den Beispielen werden für die Principal-Gruppen admin, user und guests eigene Policies erstellt.

Bis zu diesem Zeitpunkt haben Sie zwar Policies erstellt, aber um die Einstellungen wirksam werden zu lassen, müssen Sie die Policies auch noch den Principals zuweisen. Da Sie bereits Principals angelegt haben, sehen Sie in Listing 15.39, wie Sie einem bestehenden Benutzer eine Policy zuweisen können:

Listing 15.39 Zuweisung an bestehenden Benutzer

kadmin: modify_principal -policy user skania Principal skania@EXAMPLE.NET wurde geändert. kadmin: get_principal skania Principal: skania@EXAMPLE.NET Ablaufdatum: [niemals] Letzte Passwortänderung: Di Feb 21 12:36:44 CET 2023 Passwortablaufdatum: Mo Mai 22 13:36:44 CEST 2023 maximale Ticketlebensdauer: 0 days 10:00:00 maximale verlängerbare Lebensdauer: 7 days 00:00:00 zuletzt geändert: Mi Feb 22 10:33:31 CET 2023 (root/admin@EXAMPLE.NET) letzte erfolgreiche Authentifizierung: Di Feb 21 17:43:13 CET 2023 Last failed authentication: [never] Fehlgeschlagene Anmeldeversuche: 0 Anzahl der Schlüssel: 2 Key: vno 2, aes256-cts-hmac-sha384-192 Key: vno 2, aes128-cts-hmac-sha256-128 MKey: vno 1 Attribute: REQUIRES_PRE_AUTH Richtlinie: user

Wenn Sie jetzt neue Principals anlegen, können Sie beim Anlegen sofort eine Policy vergeben. Wie Sie einen neuen Principal gleich mit einer Policy anlegen, sehen Sie in Listing 15.40:

Listing 15.40 Anlegen eines Principals mit Policy

kadmin: add_principal -policy admin admin/ptau Geben Sie das Passwort für Principal admin/ptau@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal admin/ptau@EXAMPLE.NET erneut ein.: add_principal: Das Passwort ist zu kurz. while creating "admin/ptau@EXAMPLE.NET". kadmin: add_principal -policy admin admin/ptau Geben Sie das Passwort für Principal admin/ptau@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal admin/ptau@EXAMPLE.NET erneut ein.: add_principal: Das Passwort enthält nicht genug Zeichenklassen. while\ creating "admin/ptau@EXAMPLE.NET". kadmin: add_principal -policy admin admin/ptau Geben Sie das Passwort für Principal admin/ptau@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal admin/ptau@EXAMPLE.NET erneut ein.: Principal "admin/ptau@EXAMPLE.NET" created.

Sie sehen hier, dass die ersten beiden Versuche, den Principal anzulegen, fehlgeschlagen sind, weil das Passwort nicht den Kriterien der Policy entsprochen hat. Denn auch beim Anlegen eines Principals, anders als bei der Vergabe eines lokalen Passworts durch den Benutzer root, müssen Sie sich schon an die Policy halten, wenn Sie das Passwort für den neuen Principal festlegen.

So sind Sie jetzt in der Lage, für unterschiedliche Benutzergruppen unterschiedliche Passwortrichtlinien über Policies zu implementieren.

Tipp: Wenn Sie Ihren Kerberos in den LDAP einbinden wollen, kann es sinnvoll sein, die Policies nicht über den Kerberos zu verwalten, sondern über das Overlay ppolicy des OpenLDAP. Mit dem Overlay haben Sie mehr Möglichkeiten und können die Policies auch mit dem LAM in der PRO-Version bearbeiten.

15.8	Kerberos im LDAP einbinden

Im Moment haben Sie noch zwei Datenbanken: zum einen die LDAP-Datenbank mit allen Benutzereigenschaften und zum anderen die Kerberos-Datenbank mit den Principals und den dazugehörigen Passwörtern. In diesem Schritt sollen die Principals mit den Passwörtern auch in die LDAP-Datenbank verlagert werden. Durch das Einbinden der Kerberos-Datenbank erleichtern Sie sich die Administration Ihres Systems. Damit werden auch alle Eigenschaften eines Benutzers zentral verwaltet.

Hinweis: Hier gehen wir davon aus, dass Sie bereits einen wie in Kapitel 3, «Installation des ersten OpenLDAP», eingerichteten LDAP-Server in Ihrem Netz haben. Wenn das nicht der Fall ist, richten Sie als Erstes einen LDAP-Server ein, da hier nur noch die Änderungen am LDAP-Server angesprochen werden.

Vorhandene Benutzer

In diesem Abschnitt soll eine bestehende Kerberos-Datenbank mit einer bereits vorhandenen LDAP-Struktur zusammengebracht werden. Es geht dabei darum zu sehen, was aus den jeweiligen Datenbanken zusammengeführt wird und an welchen Stellen Handarbeit angesagt ist. Damit Sie eine Übersicht haben, welche Benutzer im LDAP und welche Principals im Kerberos vorhanden sind, sehen Sie hier in Listing 15.41 alle im LDAP vorhandenen Benutzer:

Listing 15.41 Liste aller LDAP-Benutzer

dn: cn=u1-Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net uid: u1-prod dn: cn=u2-Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net uid: u2-prod dn: cn=prod-al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net uid: prod-al dn: cn=u1-Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net uid: u1-verw dn: cn=U2-Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net uid: u2-verw dn: cn=Verw-al,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net uid: verw-al dn: cn=Stefan Kania,ou=users,dc=example,dc=net uid: skania dn: cn=Andreas Ollenburg,ou=users,dc=example,dc=net uid: aollenburg

Alle bereits im Kerberos eingetragenen Principals sehen Sie in Listing 15.42:

Listing 15.42 Alle Kerberos-Principals

andreas@EXAMPLE.NET skania@EXAMPLE.NET u1-prod@EXAMPLE.NET u1-verw@EXAMPLE.NET

Am Ende der Zusammenführung sehen Sie dann, welche Informationen aus dem Kerberos in den LDAP übernommen werden und welche Sie von Hand neu anlegen müssen.

15.8.1

Vorbereitung des LDAP-Servers

Der erste Schritt betrifft alle Ihre Kerberos-Server in Ihrem Netz. Stellen Sie sicher, dass auf allen Kerberos-Servern das Paket krb5-kdc-ldap installiert ist, da ohne dieses Paket die Einbindung des Kerberos im LDAP nicht möglich ist.

Der MIT-Kerberos bringt für OpenLDAP ein eigenes Schema mit, und ohne dieses Schema können Sie Ihre Benutzer nicht um die benötigten Attribute erweitern.

Auf Ihrem Kerberos-Server finden Sie das Schema, das Sie benötigen, als gepackte Datei unter /usr/share/doc/krb5-kdc-ldap/kerberos.openldap.ldif.gz. Kopieren Sie die Datei auf alle Ihre LDAP-Server und entpacken die Datei im Verzeichnis /opt/symas/etc/openldap/schema.

Wichtig: Im Verzeichnis /usr/share/doc/krb5-kdc-ldap/ finden Sie zwei verschiedene LDIF-Dateien. Es gibt dort mittlerweile ein eigenes Schema für den OpenLDAP. Verwenden Sie auf gar keinen Fall das Schema kerberos.ldif.gz, sondern unbedingt das Schema kerberos.openldap.ldif.gz.

Wie Sie das Schema jetzt in die dynamische Konfiguration einbinden, sehen Sie in Listing 15.43:

Listing 15.43 Einspielen des Schemas

root@provider01:/opt/symas/etc/openldap/schema# ldapadd -QY EXTERNAL \ -H ldapi:/// -f kerberos.openldap.ldif adding new entry "cn=kerberos,cn=schema,cn=config"

Tipp: Wenn Sie Ihren LDAP bereits auf einen oder mehrere Consumer replizieren, installieren Sie dort auch sofort das Schema. Denn sonst kann es zu Problemen bei der Replikation kommen, wenn die ersten Kerberos-Objekte eingespielt werden.

Jetzt können Sie das Schema nutzen. Um zu testen, ob das Schema auch eingebunden ist, haben Sie zwei Möglichkeiten. Beide sehen Sie in Listing 15.44:

Listing 15.44 Testen des Schemas

root@provider01:~# ls -l /opt/symas/etc/openldap/slapd.d/\ cn\=config/cn\=schema ’cn={0}core.ldif’ ’cn={1}cosine.ldif’ ’cn={2}nis.ldif’ ’cn={3}inetorgperson.ldif’ ’cn={4}kerberos.ldif’ root@consumer01:~# ldapsearch -QY EXTERNAL -H ldapi:/// \ -b "cn=config" | grep kerberos # {4}kerberos, schema, config dn: cn={4}kerberos,cn=schema,cn=config cn: {4}kerberos

15.8.2

Konfiguration des LDAP-Servers

Für Kerberos ist es sinnvoll, bestimmte Objekte im LDAP anzulegen. Aus Gründen der besseren Übersichtlichkeit legen Sie für die Objekte am besten eine neue Organizational Unit an. Innerhalb dieser OU werden zwei weitere Objekte angelegt: zum einen ein Objekt für den kdc und zum anderen ein Objekt für kadmin.

Diese Objekte werden nicht unbedingt benötigt. Sie können auch für die Verwaltung des Kerberos-Servers im LDAP immer den rootDN des LDAP-Servers nehmen und in die nachfolgende Konfiguration eintragen. Aus Sicherheitsgründen ist es aber angebracht, mit zwei zusätzlichen Objekten zu arbeiten, da diese beiden Objekte nur Zugriff auf den Kerberos-Teil Ihres LDAP-Baums benötigen. In Listing 15.45 sehen Sie die entsprechenden LDIF-Einträge:

Listing 15.45 Einträge für die Kerberos-Objekte

dn: ou=kerberos-adm,dc=example,dc=net ou: kerberos-adm objectClass: organizationalUnit objectClass: top dn: cn=kdc,ou=kerberos-adm,dc=example,dc=net cn: kdc objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$dGd.... dn: cn=kadmin,ou=kerberos-adm,dc=example,dc=net cn: kadmin objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$dGR....

Tipp: Die Passwörter können Sie mit dem Kommando echo -n "passwort" | argon2 "saltsaltsalt" -e erzeugen und dann in die LDIF-Datei eintragen.

Die Organizational Unit wird später nicht für die eigentliche Datenbank verwendet, sondern dient nur dazu, die beiden administrativen Objekte anzulegen. Der Container für die Kerberos-Principals wird während der Initialisierung der Datenbank angelegt. Sorgen Sie nur schon jetzt mit ACLs im LDAP dafür, dass die beiden administrativen Objekte später auch schreibenden Zugriff auf die Kerberos-Daten haben. Denn die Änderungen des LDAPs werden bei der Initialisierung der LDAP-Objekte schon mit den beiden Objekten durchgeführt. Fehlen die Rechte, schlägt die Initialisierung fehl.

Wichtig: Denken Sie daran, dass eventuell die maximal angezeigten Suchlimits auf 500 begrenzt sind. Kerberos muss aber alle Objekte durchsuchen können. Deshalb heben Sie auf jeden Fall für beide Objekte diese Limits auf.

Die beiden Objekte cn=kdc und cn=kadmin benötigen im LDAP Schreibrechte an den Benutzerobjekten und den Kerberos-Objekten. In Listing 15.46 sehen Sie die Anpassung der limits und die geänderten ACLs. Passen Sie die ACLs so an, dass sie zu Ihrer Struktur passen.

Listing 15.46 Kerberos-ACLs

dn: olcDatabase={2}mdb,cn=config changetype: modify delete: olcAccess olcAccess: {8} - delete: olcAccess olcAccess: {7} - delete: olcAccess olcAccess: {3} - delete: olcAccess olcAccess: {2} - delete: olcAccess olcAccess: {1} - add: olcAccess olcAccess: {1}to attrs=userPassword by anonymous auth by self write by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by dn.exact=uid=chain-user,ou=users,dc=example,dc=net write by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by set="[cn=pw-set,ou=groups,dc=example,dc=net]/Member* & user" write by * none - add: olcAccess olcAccess: {2} to attrs=shadowLastChange by anonymous auth by self write by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by dn.exact=uid=chain-user,ou=users,dc=example,dc=net write by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by set="[cn=pw-set,ou=groups,dc=example,dc=net]/Member* & user" write by * none - add: olcAccess olcAccess: {3} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=sssd-user,ou=users,dc=example,dc=net read by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by dn.exact=uid=lam-user,ou=users,dc=example,dc=net write by dn.exact=uid=chain-user,ou=users,dc=example,dc=net write by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by * break - add: olcAccess olcAccess: {7}to dn.sub=ou=verwaltung,ou=firma,dc=example,dc=net by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by set="this/manager & user" write by set="this/manager/secretary & user" write by "dn.children=ou=users,ou=verwaltung,ou=firma,dc=example,dc=net" read by * none - add: olcAccess olcAccess: {8}to dn.sub=ou=produktion,ou=firma,dc=example,dc=net by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by set="this/manager & user" write by set="this/manager/secretary & user" write by "dn.children=ou=users,ou=produktion,ou=firma,dc=example,dc=net" read by * none - add: olcLimits olcLimits: {2}dn.exact="cn=kadmin,ou=kerberos-adm,dc=example,dc=net" \time=unlimited size=unlimited - add: olcLimits olcLimits: {3}dn.exact="cn=kdc,ou=kerberos-adm,dc=example,dc=net" \time=unlimited size=unlimited

Um die Performance des LDAP-Servers zu verbessern, sollten Sie immer die beiden Attribute krbPrincipalName und krbPwdPolicyReference indizieren. Spielen Sie die Indexeinträge mit einer LDIF-Datei mit dem Inhalt aus Listing 15.47 ein:

Listing 15.47 LDIF-Datei für die Indexeinträge

dn: olcDatabase={2}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: krbPrincipalName eq - add: olcDbIndex olcDbIndex: krbPwdPolicyReference eq

Mit diesen Schritten haben Sie den LDAP-Server für die Umstellung vorbereitet.

Wichtig: Besitzen Sie mehrere LDAP-Server, sorgen Sie dafür, dass die Indexeinträge auf allen LDAP-Servern vorhanden sind.

15.8.3

Umstellung des Kerberos-Servers

Im ersten Schritt erzeugen Sie ein Backup der Kerberos-Datenbank. Dieses Backup benötigen Sie später noch, um die bestehenden Daten in den LDAP zu übernehmen.

Stoppen Sie alle KDCs und den Admin-Server auf Ihren Kerberos-Servern. Wenn Sie die Replikation der Kerberos-Server eingerichtet haben, stoppen Sie auch den kpropd auf allen Slave-KDCs. Denken Sie daran, den Dienst auch zu deaktivieren, denn der kpropd wird bei der Verwendung von LDAP nicht mehr benötigt, da alle Kerberos-Server immer auf dieselbe LDAP-Datenbank zugreifen.

Mit dem Kommando kdb5_util dump /root/example.net.backup erstellen Sie das benötigte Backup. In diesem Backup finden Sie alle Principals und alle Richtlinien, die Sie bis zu diesem Zeitpunkt in Kerberos erzeugt haben.

Wichtig: Vergessen Sie nicht, die alte lokale Datenbank mit den Principals zu löschen. Diese Datenbank wird nach der Umstellung nicht mehr benötigt. Am einfachsten löschen Sie die Datenbank mit dem Kommando kdb5_util destroy.

Auf Ihren Kerberos-Servern passen Sie jetzt die Datei /etc/krb5kdc/kdc.conf an, sodass die Kerberos-Server die Datenbank auf Ihrem LDAP-Server suchen und nicht mehr in der lokalen Datenbank. In Listing 15.48 sehen Sie die neue Datei krb5.conf:

Listing 15.48 Die geänderte kdc.conf

[kdcdefaults] kdc_ports = 749,88 spake_preauth_kdc_challenge = edwards25519 [realms] EXAMPLE.NET = { #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 = 749,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = aes256-cts-hmac-sha384-192 supported_enctypes = aes256-cts-hmac-sha384-192:normal \ aes128-cts-hmac-sha256-128:normal default_principal_flags = +preauth database_module = ldapconf } [dbmodules] ldapconf = { db_library = kldap ldap_kerberos_container_dn = "cn=kerberos,dc=example,dc=net" ldap_kdc_dn = "cn=kdc,ou=kerberos-adm,dc=example,dc=net" ldap_kadmind_dn = "cn=kadmin,ou=kerberos-adm,dc=example,dc=net" ldap_service_password_file = "/etc/krb5kdc/service.keyfile" ldap_servers = "ldaps://provider01.example.net" ldap_conns_per_server = 5 }

Hier sehen Sie, dass bei den Optionen ldap_kdc_cn und ldap_kadmin_dn die beiden Objekte eingetragen werden, die Sie vorher für die Administration angelegt und über ACLs mit Rechten versehen haben.

In der folgenden Auflistung finden Sie die Bedeutung der neuen Parameter:

database_module = ldapconf
Damit die Parameter für den Zugriff auf den LDAP-Server auch für jeden Realm anders gesetzt werden können, wird hier der neue Abschnitt für die Modulkonfiguration gesetzt. Den Namen können Sie frei wählen. So sind Sie in der Lage, mehrere Realms im LDAP zu verwalten.

[dbmodules]
Hier beginnt der neue Abschnitt für die Konfiguration des Zugriffs auf den LDAP-Server.

ldapconf = {
An dieser Stelle beginnt die Konfiguration für den ausgewählten Realm. Hier verwenden Sie den Namen, den Sie zuvor festgelegt haben.

db_library=kldap
Alle anderen als das Standard-Backend, die lokale Datenbank, werden beim MIT-Kerberos über Module geladen. Für die Verwendung von LDAP als Backend ist das Modul kldap verantwortlich, das an dieser Stelle geladen wird.

ldap_kerberos_container_dn = ”cn=kerberos,dc=example,dc=net”
Dieser Parameter legt den Container im LDAP-Baum fest, in dem die Kerberos-Objekte verwaltet werden. Bei dem Container handelt es sich nicht um die OU, die Sie bereits für die Verwaltung der Admin-Objekte ou=kerberos-adm angelegt haben. Diese OU wird beim Initialisieren der Datenbank automatisch angelegt. Erstellen Sie die OU also nicht selbst. Legen Sie die OU von Hand an, kommt es bei der Initialisierung zu einer Fehlermeldung.

ldap_kdc_dn = ”cn=kdc,ou=kerberos-adm,dc=example,dc=net”
Hier geben Sie das Objekt des KDC-Admins an.

ldap_kadmind_dn = ”cn=kadmin,ou=kerberos-adm,dc=example,dc=net”
Hier geben Sie das Objekt für den kadmin an.

ldap_service_password_file = ”/etc/krb5kdc/service.keyfile”
An dieser Stelle geben Sie die Datei an, in der später das Passwort für den LDAP-bind abgelegt wird.

ldap_servers = ”ldaps://provider01.example.net”
Hier können Sie, durch Leerzeichen voneinander getrennt, Ihre LDAP-Server angeben. Verwenden Sie in einem Produktivsystem immer mindestens zwei LDAP-Server, um eine Ausfallsicherheit zu gewährleisten.

ldap_conns_per_server = 5
Anzahl der Verbindungen, die der Kerberos-Server zum LDAP-Server geöffnet halten soll. Der Wert 5 ist dabei der Standardwert. Nur wenn die Authentifizierung über mehrere LDAP-Server geht, muss dieser Wert erhöht werden.

Im Anschluss daran können Sie die neue LDAP-basierte Datenbank mit dem Kommando kdb5_ldap_utils auf einem Ihrer Kerberos-Server initialisieren.

Bei dem Parameter ldap_servers verwenden wir LDAPS als Protokoll. Stellen Sie sicher, dass die Datei /etc/ldap/ldap.conf wie in Listing 15.49 konfiguriert ist:

Listing 15.49 Datei ldap.conf auf den Kerberos-Servern

BASE dc=example,dc=net URI: ldaps://provider01.example.net TLS_REQCERT demand TLS_CACERT /etc/ldap/cacert.pem

Ohne diese Einstellungen kann das Zertifikat des Providers nicht geprüft werden. Da hier keine Symas-Pakete installiert sind, liegt die Datei im Standardpfad Ihrer Distribution.

Wichtig: Verwenden Sie beim Initialisieren der Kerberos-Datenbank im LDAP unbedingt den Master-Key, den Sie für die lokale Datenbank verwendet haben. Dies ist notwendig, damit die Entschlüsselung der lokalen Datenbank, die Sie ja gesichert haben, während der Übernahme der Daten in den LDAP möglich ist.

In Listing 15.50 sehen Sie den Initialisierungsvorgang:

Listing 15.50 Initialisierung der Datenbank im LDAP

root@kerberos01:~# kdb5_ldap_util create -D "cn=admin,dc=example,dc=net" -r EXAMPLE.NET -s -sscope sub Passwort für cn=admin,dc=example,dc=net: Datenbank für Realm EXAMPLE.NET wird initialisiert Sie werden nach dem Master-Passwort der Datenbank gefragt. Es ist wichtig, dass Sie dieses Passwort NICHT VERGESSEN. Enter KDC database master key: Re-enter KDC database master key to verify:

Wichtig: Stellen Sie sicher, dass das hier vergebene Passwort an einem sicheren Ort verwahrt wird. Ohne das Passwort sind Sie nicht in der Lage, die Datenbank zu entschlüsseln. Das Passwort befindet sich in der Datei /etc/krb5kdc/stash.

Kopieren Sie die neue stash-Datei auf alle Kerberos-Server in das Verzeichnis krb5kdc.

Bei dem Kommando wird die Option -s verwendet, damit der Master-Key der Datenbank in eine stash-Datei geschrieben wird. Nach der Initialisierung der Datenbank sehen Sie im LDAP die neuen Objekte aus Listing 15.51:

Listing 15.51 Die Kerberos-Objekte im LDAP

root@provider01:~# ldapsearch -x -D "uid=ldap-admin,ou=users,\ dc=example,dc=net" -W -LLL dn dn: cn=EXAMPLE.NET,cn=kerberos,dc=example,dc=net dn: krbPrincipalName=K/M@EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,\ dc=example,dc=net dn: krbPrincipalName=kadmin/admin@EXAMPLE.NET,cn=EXAMPLE.NET,\ cn=kerberos,dc=example,dc=net dn: krbPrincipalName=kadmin/history@EXAMPLE.NET,cn=EXAMPLE.NET,\ cn=kerberos,dc=example,dc=net dn: krbPrincipalName=kadmin/changepw@EXAMPLE.NET,cn=EXAMPLE.NET,\ cn=kerberos,dc=example,dc=net dn: krbPrincipalName=krbtgt/EXAMPLE.NET@EXAMPLE.NET,cn=EXAMPLE.NET,\ cn=kerberos,dc=example,dc=net dn: krbPrincipalName=kadmin/kerberos01.example.net@EXAMPLE.NET,\ cn=EXAMPLE.NET,cn=kerberos,dc=example,dc=net dn: krbPrincipalName=kiprop/kerberos01.example.net@EXAMPLE.NET,\ cn=EXAMPLE.NET,cn=kerberos,dc=example,dc=net dn: cn=kdc,ou=kerberos-adm,dc=example,dc=net dn: cn=kadmin,ou=kerberos-adm,dc=example,dc=net

Bei diesen Objekten handelt es sich um dieselben Einträge, die schon bei der Initialisierung der Kerberos-Datenbank ohne LDAP erstellt wurden. Diese Objekte werden vom Kerberos-Server benötigt, Sie sollten diese Objekte nicht löschen oder verändern.

Fehlen nur noch die benötigten ACLs, denn ohne diese ACLs wird der Kerberos-Server nicht starten. In Listing 15.52 sehen Sie alle ACLs:

Listing 15.52 ACLs für die Kerberos-Objekte

dn: olcDatabase={2}mdb,cn=config changetype: modify delete: olcAccess olcAccess: {8} - delete: olcAccess olcAccess: {7} - delete: olcAccess olcAccess: {3} - delete: olcAccess olcAccess: {2} - delete: olcAccess olcAccess: {1} - add: olcAccess olcAccess: {1}to attrs=userPassword by anonymous auth by self write by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by dn.exact=uid=chain-user,ou=users,dc=example,dc=net write by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by dn.exact="krbPrincipalName=K/M@EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,dc=example,dc=net" write by set="[cn=pw-set,ou=groups,dc=example,dc=net]/Member* & user" write by * none - add: olcAccess olcAccess: {2} to attrs=shadowLastChange by anonymous auth by self write by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by dn.exact=uid=chain-user,ou=users,dc=example,dc=net write by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by dn.exact="krbPrincipalName=K/M@EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,\ dc=example,dc=net" write by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by set="[cn=pw-set,ou=groups,dc=example,dc=net]/Member* & user" write by * none - add: olcAccess olcAccess: {3} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=sssd-user,ou=users,dc=example,dc=net read by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by dn.exact=uid=lam-user,ou=users,dc=example,dc=net write by dn.exact=uid=chain-user,ou=users,dc=example,dc=net write by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by dn.exact="krbPrincipalName=K/M@EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,\ dc=example,dc=net" write by * break - add: olcAccess olcAccess: {7}to dn.sub=ou=verwaltung,ou=firma,dc=example,dc=net by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by dn.exact="krbPrincipalName=K/M@EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,\ dc=example,dc=net" write by set="this/manager & user" write by set="this/manager/secretary & user" write by "dn.children=ou=users,ou=verwaltung,ou=firma,dc=example,dc=net" read by * none - add: olcAccess olcAccess: {8}to dn.sub=ou=produktion,ou=firma,dc=example,dc=net by dn.exact=cn=kadmin,ou=kerberos-adm,dc=example,dc=net write by dn.exact=cn=kdc,ou=kerberos-adm,dc=example,dc=net write by dn.exact="krbPrincipalName=K/M@EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,\ dc=example,dc=net" write by set="this/manager & user" write by set="this/manager/secretary & user" write by "dn.children=ou=users,ou=produktion,ou=firma,dc=example,dc=net" read by * none

Die neue ACL für K/M@EXAMPLE.NET ist nur auf allen Providern relevant, da nur hier geschrieben wird.

Wie schon nach der Installation des Kerberos in einer lokalen Datenbank muss jetzt als Erstes das Passwort für den cn=kdc und den cn=kadmin in der stash-Datei abgelegt werden. In Listing 15.53 können Sie diesen Vorgang nachvollziehen:

Listing 15.53 Erzeugen der Passwörter für kadmin und kdc

root@kerberos01:~# kdb5_ldap_util stashsrvpw -D cn=admin,dc=example,dc=net \ -f /etc/krb5kdc/service.keyfile cn=kdc,ou=kerberos-adm,dc=example,dc=net Passwort für cn=admin,dc=example,dc=net: Passwort für cn=kdc,ou=kerberos-adm,dc=example,dc=net: Geben Sie das Passwort für cn=kdc,ou=kerberos-adm,dc=example,dc=net \ erneut ein.: root@kerberos01:~# kdb5_ldap_util stashsrvpw -D cn=admin,dc=example,dc=net \ -f /etc/krb5kdc/service.keyfile cn=kadmin,ou=kerberos-adm,dc=example,dc=net Passwort für cn=admin,dc=example,dc=net: Passwort für cn=kadmin,ou=kerberos-adm,dc=example,dc=net: Geben Sie das Passwort für cn=kadmin,ou=kerberos-adm,dc=example,dc=net erneut ein.:

Als Datei für die Passwörter wird hier die in Listing 15.48 angegebene Datei /pfad/zur/krb5kdc/service.keyfile verwendet. Achten Sie darauf, dass in der Datei service.keyfile der komplette DN der Objekte steht, nur so kann die Authentifizierung der Objekte später funktionieren. In Listing 15.54 sehen Sie den Inhalt der Datei:

Listing 15.54 Inhalt der Datei service.keyfile

root@kerberos01:~# cat /etc/krb5kdc/service.keyfile cn=kdc,ou=kerberos-adm,dc=example,dc=net#{HEX}67656865696d cn=kadmin,ou=kerberos-adm,dc=example,dc=net#{HEX}67656865696d

Kopieren Sie die Datei wieder auf alle Ihre Kerberos-Server in das entsprechende Verzeichnis.

Jetzt können Sie sich mit dem Kommando kadmin.local -q listprincs alle bis jetzt erstellten Principals auflisten lassen. Erst wenn das ohne Fehler funktioniert, sollten Sie mit dem nächsten Schritt fortfahren. Sie sehen bei der Auflistung erst nur die Standard-Principals. In Listing 15.55 sehen Sie das Ergebnis:

Listing 15.55 Standardobjekte aus dem LDAP

root@kerberos01:~# kadmin.local -q listprincs Authentifizierung als Principal root/admin@EXAMPLE.NET mit Passwort K/M@EXAMPLE.NET krbtgt/EXAMPLE.NET@EXAMPLE.NET kadmin/admin@EXAMPLE.NET kadmin/kerberos01.example.net@EXAMPLE.NET kiprop/kerberos01.example.net@EXAMPLE.NET kadmin/changepw@EXAMPLE.NET kadmin/history@EXAMPLE.NET

Sollten Sie die Principals nicht auflisten können, prüfen Sie als Erstes die ACLs, denn meist liegt es an fehlenden Rechten, dass die Principals nicht aufgelistet werden können.

15.8.4

Zurücksichern der alten Datenbank

Im nächsten Schritt können Sie das Backup der alten Kerberos-Datenbank wieder einspielen. Hierzu wird das Kommando kdb5_util verwendet. In Listing 15.56 sehen Sie den Vorgang des Imports und das anschließende Auflisten aller Principals:

Listing 15.56 Importieren der alten Datenbank

root@kerberos01:~# kdb5_util load -update example.net.backup root@kerberos01:~# kadmin.local -q listprincs Authentifizierung als Principal root/admin@EXAMPLE.NET mit Passwort K/M@EXAMPLE.NET krbtgt/EXAMPLE.NET@EXAMPLE.NET kadmin/admin@EXAMPLE.NET kadmin/kerberos01.example.net@EXAMPLE.NET kiprop/kerberos01.example.net@EXAMPLE.NET kadmin/changepw@EXAMPLE.NET kadmin/history@EXAMPLE.NET admin/ptau@EXAMPLE.NET andreas@EXAMPLE.NET host/client01.example.net@EXAMPLE.NET host/kerberos01.example.net@EXAMPLE.NET host/kerberos02.example.net@EXAMPLE.NET root/admin@EXAMPLE.NET skania@EXAMPLE.NET u1-prod@EXAMPLE.NET u1-verw@EXAMPLE.NET root@kerberos01:~# kadmin.local -q listpols Authentifizierung als Principal root/admin@EXAMPLE.NET mit Passwort admin guests user

Wie Sie in dem Listing sehen, wurden auch alle vorher erstellten Policies in den LDAP übernommen.

Hinweis: Obwohl Sie hier die Daten in den LDAP importieren, verwenden Sie das Kommando kdb5_util und nicht das Kommando kdb5_ldap_util, denn nur mit dem Kommando kdb5_util ist ein Importieren der Datenbank möglich. Das Kommando kdb5_ldap_util kennt die entsprechenden Optionen nicht. Das Kommando können Sie nur zur Verwaltung der Principals im LDAP nutzen.

Bild 15.2 zeigt alle importierten Principals.

Jetzt fehlt nur noch ein Principal, den Sie später für die Administration benötigen: der root/admin-Principal. Den können Sie jetzt mit dem Programm kadmin.lokal anlegen. In Listing 15.57 sehen Sie den Vorgang:

Bild 15.2 Übersicht der importierten Principals

Listing 15.57 Anlegen des Principals root/admin

root@kerberos-01:~# kadmin.local Authentifizierung als Principal root/admin@EXAMPLE.NET mit Passwort kadmin.local: addprinc root/admin Für root/admin@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird \ die Vorgabe keine Richtlinie verwandt. Geben Sie das Passwort für Principal root/admin@EXAMPLE.NET ein.: Geben Sie das Passwort für Principal root/admin@EXAMPLE.NET erneut ein.: add_principal: Principal oder Richtlinie existiert bereits while creating \ "root/admin@EXAMPLE.NET".

Anschließend können Sie wieder das Programm kadmin für die Verwaltung der Principals verwenden.

Testen Sie noch einmal mit kadmin.local -q listprincs, ob alle Principals im LDAP angelegt wurden. Wenn das der Fall ist, haben Sie die Datenbank erfolgreich zurückgesichert. Starten Sie jetzt den KDC auf allen Kerberos-Servern neu.

Tipp: Wenn Sie auf einer zweiten Konsole auf dem LDAP-Server und dem Kerberos-Server das Kommando journalctl -f starten, können Sie die folgenden Schritte verfolgen. So können Sie auch erkennen, dass der Kerberos-Server für die Authentifizierung jetzt auf den LDAP-Server zugreift.

Testen Sie, ob sich die bestehenden Benutzer, die schon einen Principal besitzen, auch authentifizieren können. Den Test können Sie mit dem Kommando kinit durchführen. Listing 15.58 zeigt die Anmeldung und den Test:

Listing 15.58 Beziehen eines Kerberos-Tickets

root@kerberos01:~# kinit skania Passwort für skania@EXAMPLE.NET: root@kerberos01:~# klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_0 Standard-Principal: skania@EXAMPLE.NET Valid starting Expires Service principal 23.02.2023 19:44:21 24.02.2023 05:44:21 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 24.02.2023 19:44:15

15.8.5

Erstellung der Keys für den LDAP-Server

Die Authentifizierung eines Benutzers funktioniert jetzt schon. Damit der LDAP-Server bei der Authentifizierung auch auf den Kerberos-Server zugreifen kann, müssen Sie jetzt noch den Principal für den LDAP-Server selbst erstellen. Welche Keys Sie benötigen, hängt davon ab, wo Sie den LDAP-Server installiert haben. Wenn Sie den LDAP-Server auf einem Kerberos-Server installiert haben, hat der Host bereits einen Host-Key in der Datei /etc/krb5.conf.Dann benötigen Sie nur noch den Service-Key für den LDAP. Läuft Ihr LDAP aber auf einer eigenständigen Maschine, benötigen Sie sowohl einen Host-Key als auch den Service-Key.

In unseren Setup laufen beide Dienste auf unterschiedlichen Systemen, aus diesem Grund werden in Listing 15.59 beide Principals und beide Keytab-Dateien erzeugt. Auf dem LDAP-Server wird der Host-Key und der Service-Key in getrennten Dateien verwaltet. Kopieren Sie anschließend die beiden Dateien auf den LDAP-Server:

Listing 15.59 Erstellen der LDAP-Principals und Keys

kadmin: addprinc -randkey host/provider01.example.net Für host/provider01.example.net@EXAMPLE.NET wurde keine Richtlinie \ angegeben, es wird die Vorgabe keine Richtlinie verwandt. Principal "host/provider01.example.net@EXAMPLE.NET" created. kadmin: addprinc -randkey ldap/provider01.example.net Für ldap/provider01.example.net@EXAMPLE.NET wurde keine Richtlinie \ angegeben, es wird die Vorgabe keine Richtlinie verwandt. Principal "ldap/provider01.example.net@EXAMPLE.NET" created. kadmin: ktadd -k /root/provider01-krb5.keytab host/provider01.example.net Der Eintrag für Principal host/provider01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ WRFILE:/root/provider01-krb5.keytab hinzugefügt. Der Eintrag für Principal host/provider01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ WRFILE:/root/provider01-krb5.keytab hinzugefügt. kadmin: ktadd -k /root/provider01-ldap.keytab ldap/provider01.example.net Der Eintrag für Principal ldap/provider01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ WRFILE:/root/provider01-ldap.keytab hinzugefügt. Der Eintrag für Principal ldap/provider01.example.net mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ WRFILE:/root/provider01-ldap.keytab hinzugefügt. kadmin: q root@kerberos01:~# scp provider01-krb5.keytab \ provider01:/etc/krb5.keytab root@kerberos01:~# scp provider01-ldap.keytab \ provider01:/opt/symas/etc/openldap/ldap.keytab

Damit der LDAP-Server den Service-Key auch lesen kann, achten Sie unbedingt darauf, dass die Rechte an der Service-Keytab-Datei richtig gesetzt sind. Die Datei sollte immer dem Benutzer root gehören, der dann die Rechte read und write besitzt. Als Gruppe tragen Sie die Gruppe ein, unter der der LDAP-Dienst läuft. Die Gruppe benötigt nur das Recht read. Ohne die passenden Berechtigungen kann der LDAP-Server später keine Authentifizierung mithilfe der Keytab-Datei durchführen.

Wichtig: Im Anschluss folgt die Bekanntmachung der Keytab-Datei und die Konfiguration der gewünschten SASL-Mechanismen. Die Einrichtung ist hier bei der Verwendung der Symas-Pakete anders, als Sie es von den Paketen der Distributionen gewohnt sind.

Damit der LDAP-Server auch weiß, wo er den Service-Key findet und welche SASL-Mechanismen er bereitstellen soll, benötigen Sie eine eigene Konfigurationsdatei im Verzeichnis /opt/symas/etc/sasl2. Das Verzeichnis existiert nicht und muss erst angelegt werden. In dem Verzeichnis erstellen Sie dann eine Datei slapd.conf mit dem Inhalt aus Listing 15.60:

Listing 15.60 Inhalt der Datei slapd.conf

mech_list: gssapi digest-md5 cram-md5 external keytab: /opt/symas/etc/openldap/ldap.keytab

Auch die Datei /opt/symas/etc/openldap/ldap.conf benötigt noch zusätzliche Einträge. Sie sehen die Einträge in Listing 15.61:

Listing 15.61 Anpassung an der Datei ldap.conf

KRB5_KTNAME="/etc/krb5.keytab" SASL_MECH=GSSAPI SASL_REALM=EXAMPLE.NET

Bevor Sie jetzt den LDAP-Dienst neu starten, um die Änderungen wirksam werden zu lassen, schauen Sie sicher erst einmal die Standardeinstellung für SASL an. Dazu verwenden Sie das Kommando aus Listing 15.62:

Listing 15.62 Standardeinstellung von SASL

root@provider01:~# ldapsearch -x -H ldapi:/// -b "" -LLL -s base supportedSASLMechanisms dn: supportedSASLMechanisms: SCRAM-SHA-512 supportedSASLMechanisms: SCRAM-SHA-384 supportedSASLMechanisms: SCRAM-SHA-256 supportedSASLMechanisms: SCRAM-SHA-224 supportedSASLMechanisms: SCRAM-SHA-1 supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: OTP supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN

Starten Sie jetzt den LDAP-Dienst neu und wiederholen Sie das Kommando. Das Ergebnis sieht dann so aus, wie es Listing 15.63 zeigt:

Listing 15.63 SASL mit der neuen Einstellung

root@provider01:~# ldapsearch -x -H ldapi:/// -b "" -LLL -s base supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL

Bei CentOS finden Sie die Einstellung für die Keytab-Datei in der Datei /etc/sysconfig/slapd. Passen Sie die Datei wie in Listing 15.64 an:

Listing 15.64 Bekanntmachung der Keytab-Datei unter CentOS

# Keytab location for GSSAPI Kerberos authentication KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"

Starten Sie anschließend den LDAP-Server neu.

Hinweis: Sollte beim zweiten Test GSSAPI nicht angezeigt werden, prüfen Sie den Pfad und die Berechtigungen der Datei ldap.keytab.

15.8.6

Bestehende LDAP-Benutzer um Kerberos-Principal erweitern

Bis zu diesem Zeitpunkt werden die Principals und die Benutzerinformationen noch in getrennten Objekten verwaltet. Jetzt sollen die Benutzerobjekte und die Principals zu einem Objekt zusammengefasst werden. Dazu muss der Suchpfad für die Principals des Kerberos-Servers erst einmal um den LDAP-Container erweitert werden, in dem Sie Ihre Benutzer verwalten. Diese Erweiterung der Suchpfade führen Sie mit dem Kommando kdb5_ldap_util aus, so wie Sie es in Listing 15.65 sehen:

Listing 15.65 Eintragen der Suchpfade für Benutzer

root@kerberos01:~# kdb5_ldap_util modify -D cn=admin,dc=example,dc=net \ -r EXAMPLE.NET -subtrees ou=users,dc=example,dc=net:\ ou=users,ou=produktion,ou=firma,dc=example,dc=net:\ ou=users,ou=verwaltung,ou=firma,dc=example,dc=net Passwort für cn=admin,dc=example,dc=net: root@kerberos-01:~# kdb5_ldap_util view -D cn=admin,dc=example,dc=net -subtrees Passwort für cn=admin,dc=example,dc=net: Realm-Name: EXAMPLE.NET Teilbaum: ou=users,dc=example,dc=net Teilbaum: ou=users,ou=produktion,ou=firma,dc=example,dc=net Teilbaum: ou=users,ou=verwaltung,ou=firma,dc=example,dc=net Suchbereich: SUB

Wenn Sie so wie hier im Beispiel mehrere Subtree-Einträge benötigen, trennen Sie die einzelnen Subtree-Einträge mit einem Doppelpunkt voneinander.

Hinweis: Führen Sie das Kommando erneut aus, werden alle Subtrees durch die neuen Werte ersetzt. Wollen Sie weitere Subtrees hinzufügen, geben Sie immer alle Subtrees an.

Nachdem Sie den Suchpfad erweitert haben, können Sie das Ergebnis auch mit dem Kommando ldapsearch überprüfen, zu sehen in Listing 15.66:

Listing 15.66 Prüfen der Suchpfade mit ldapsearch

root@provider01:~# ldapsearch -x \ -D "uid=ldap-admin,ou=users,dc=example,dc=net" \ -W "cn=example.net" -LLL Enter LDAP Password: dn: cn=EXAMPLE.NET,cn=kerberos,dc=example,dc=net cn: EXAMPLE.NET objectClass: top objectClass: krbRealmContainer objectClass: krbTicketPolicyAux krbSearchScope: 2 krbSubTrees: ou=users,dc=example,dc=net krbSubTrees: ou=users,ou=produktion,ou=firma,dc=example,dc=net krbSubTrees: ou=users,ou=verwaltung,ou=firma,dc=example,dc=net

Wichtig: Nach dieser Änderung ist es wichtig, dass Sie alle KDCs und den Admin-Server unbedingt neu starten.

Leider können Sie die alten Passwörter der bestehenden Benutzer nicht in den entsprechenden Principal migrieren, denn dazu müsste es möglich sein, die Verschlüsselung der Passwörter aufzulösen. Die Verschlüsselung der Passwörter der Benutzer im LDAP ist, genau wie die Passwörter der Kerberos-Principals, eine Einbahnstraße. Für alle Benutzer, die sich schon im LDAP befinden, ist es daher notwendig, dass Sie ein neues Passwort vergeben. Dieses Passwort wird dann als Principal-Credential gespeichert. Um nun die bestehenden Benutzer aus dem LDAP, die schon einen Principal im LDAP besitzen, zusammenzuführen, löschen Sie erst den alten Principal und erweitern dann das bestehende Benutzerobjekt um die entsprechenden Attribute. Das realisieren Sie wieder mit dem Kommando kadmin, so wie Sie es in Listing 15.67 sehen. Dieses Mal wird der Befehl für das Anlegen des Principals aber um den DN des Benutzers erweitert:

Listing 15.67 Erweitern eines bestehenden Benutzers

kadmin: delprinc u1-prod Sind Sie sicher, dass Sie den Principal u1-prod@EXAMPLE.NET löschen \ möchten? (yes/no): yes Principal u1-prod@EXAMPLE.NET gelöscht Stellen Sie sicher, dass Sie diesen Principal aus allen ACLs entfernt \ haben, bevor Sie ihn erneut benutzen. kadmin: addprinc -x dn="cn=u1 prod,ou=users,ou=produktion,\ ou=firma,dc=example,dc=net" -pw geheim "u1 prod" Für u1 prod@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird \ die Vorgabe keine Richtlinie verwandt. Principal "u1-prod@EXAMPLE.NET" created. kadmin: listprincs u1-prod@EXAMPLE.NET ...

Was ist dabei im LDAP passiert? Durch das Anlegen des neuen Principals wurden dem über die Option -x angegebenen Benutzerobjekt zusätzliche Objektklassen und Attribute zugewiesen. Listing 15.68 zeigt den geänderten Benutzer und die zusätzlichen Werte:

Listing 15.68 Das geänderte Benutzerobjekt

# u1 Prod, users, Produktion, firma, example.net dn: cn=u1 Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux loginShell: /bin/bash homeDirectory: /home/u1-prod uid: u1-prod cn: u1-prod uidNumber: 10001 gidNumber: 10000 sn: Prod givenName: u1 userPassword:: e1NTSEF9dmQ1T01hdTZCb3ZldkkxZnA0TkFrbG9QNm04eFYzSjQ= manager: cn=prod al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net businessCategory: Produktion telephoneNumber: 1234455 description: Ein Benutzer der Produktion krbLoginFailedCount: 0 krbPrincipalName: u1 prod@EXAMPLE.NET krbPrincipalKey:: MIG2oAMCAQGhAwIBAaIDAg.... fGaaGSInO+zAUXu3EtaQXSCZNN8Pvh7qc= krbLastPwdChange: 20230224183954Z krbExtraData:: AAJ6BPljcm9vdC9hZG1pbkBFWEFNUExFLk5FVAA= krbExtraData:: AAgBAA==

Wollen Sie einem LDAP-Benutzer mit Principal eine Policy zuweisen, geht das genauso wie bei der Verwendung einer lokalen Datenbank. Dem Objekt wird dann ein neues Attribut hinzugefügt. Listing 15.69 zeigt das Vergeben der Policy. Sie sehen dort, dass Sie nur den Principal angeben und nicht den DN des Objekts:

Listing 15.69 Zuweisen einer Policy

kadmin: modify_principal -policy user "u1-prod" Principal u1 prod@EXAMPLE.NET wurde geändert.

Lassen Sie sich das LDAP-Objekt noch einmal mit ldapsearch anzeigen, werden Sie feststellen, dass das Attribut krbPwdPolicyReference dem Objekt hinzugefügt wurde.

So können Sie jetzt alle bestehenden LDAP-Benutzer um die Kerberos-Informationen erweitern. Für Kerberos-Principals, die Sie nur für die Authentifizierung von Diensten benötigen, brauchen Sie keine LDAP-Benutzer anzulegen. Auch für etwaige Service-Principals, die Sie bereits in der lokalen Kerberos-Datenbank angelegt hatten, müssen Sie nichts ändern. Diese Principals haben Sie in den LDAP importiert, und sie sind sofort wieder nutzbar.

15.9	Neue Benutzer im LDAP

Wenn Sie jetzt neue Benutzer zum LDAP-Baum hinzufügen wollen, realisieren Sie das immer in zwei Schritten. Im ersten Schritt legen Sie den Benutzer mit einer LDIF-Datei im LDAP an. Ein Beispiel für eine LDIF-Datei sehen Sie in Listing 15.70:

Listing 15.70 LDIF-Datei für einen neuen Benutzer

dn: cn=ktom,ou=users,dc=example,dc=net cn: Kater Tom gidNumber: 10000 givenName: Kater homeDirectory: /home/ktom loginShell: /bin/bash objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person sn: Tom uid: ktom uidNumber: 10500

Wie Sie in dem Listing sehen, wird für den neuen Benutzer kein Passwort vergeben. Das benötigt der Benutzer auch nicht, denn im nächsten Schritt wird dem neuen Benutzer ein Kerberos-Principal zugewiesen, und er erhält dann das Passwort, das Sie beim Anlegen des Principals vergeben.

Im zweiten Schritt erweitern Sie den neuen Benutzer um die Kerberos-Attribute. In Listing 15.71 sehen Sie die Vorgehensweise:

Listing 15.71 Erzeugen des Principals für den neuen Benutzer

kadmin: add_principal -x dn="cn=ktom,ou=users,dc=example,dc=net" \ -pw geheim ktom Für ktom@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird die \ Vorgabe keine Richtlinie verwandt. Principal "ktom@EXAMPLE.NET" created. root@ldapserver:~# ldapsearch -x -W -LLL cn=ktom \ -D uid=ldap-admin,ou=users,dc=example,dc=net Enter LDAP Password: dn: cn=ktom,ou=users,dc=example,dc=net cn: Kater Tom cn: ktom gidNumber: 10000 givenName: Kater homeDirectory: /home/ktom loginShell: /bin/bash objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux sn: Tom uid: ktom uidNumber: 10500 krbLoginFailedCount: 0 krbPrincipalName: ktom@EXAMPLE.NET krbPrincipalKey:: MIG2oAMCAQGhAwIBAaIDAg.... fohjJF9CIUS28tCzrf2VYMc8frVebtnvI= krbLastPwdChange: 20230224190406Z krbExtraData:: AAImCvljcm9vdC9hZG1pbkBFWEFNUExFLk5FVAA= krbExtraData:: AAgBAA==

Natürlich gibt es auch grafische Werkzeuge, die Ihnen das Anlegen der Benutzer vereinfachen. Der LDAP Account Manager (LAM) in der Pro-Version unterstützt Kerberos bei der Benutzerverwaltung, ist aber nicht kostenfrei verfügbar.

In einer größeren Umgebung ist ein grafisches Werkzeug aber sicher eine sehr gute Hilfe. Das Schöne an der Verwaltung mit dem LAM-Pro ist, dass Sie dort die Benutzer sofort mit den entsprechenden Kerberos-Objektklassen und Attributen anlegen können. Wenn Sie den LAM-Pro gerne einmal testen wollen, schicken Sie eine Mail an post@rolandgruber.de mit dem Betreff OpenLDAP Buch, und Sie erhalten eine 90 Tage gültige Testlizenz.

15.10

Authentifizierung am LDAP-Server über GSSAPI

Nachdem Sie die Anmeldung der Benutzer auf die Verwendung von Kerberos umgestellt haben, geht es im nächsten Schritt darum, die Authentifizierung am LDAP für die ldaputils, wie zum Beispiel ldapsearch, über das Generic Security Service Application Programming Interface (GSSAPI) zu realisieren.

15.10.1

Einrichtung der Authentifizierung

Um die Authentifizierung über das GSSAPI durchführen zu können, benötigen Sie das Paket libsasl2-modules-gssapi-mit auf Ihrem LDAP-Server. Nach der Installation des Pakets ist es notwendig, dass Sie den LDAP-Server neu starten. Wenn Sie die Symas-Pakete mit unserem Skript installiert haben, ist das Paket bereits vorhanden.

Wenn Sie jetzt als Benutzer ein ldapsearch ausführen, werden Sie eventuell die Fehlermeldungen wie in Listing 15.72 erhalten. Diese Meldung ist abhängig von der verwendeten LDAP-Version:

Listing 15.72 Erster Versuch mit GSSAPI

root@provider:~$ su - u1-prod u1-prod@ldapserver:~$ kinit "u1-prod" Passwort für u1-prod@EXAMPLE.NET: u1-prod@provider01:/$ ldapsearch -LLL dn SASL/GSSAPI authentication started SASL username: u1 verw@EXAMPLE.NET SASL SSF: 56 SASL data security layer installed. dn: dc=example,dc=net dn: ou=firma,dc=example,dc=net dn: cn=u1-prod,ou=users,ou=produktion,ou=firma,dc=example,dc=net

Hinweis: Wenn das Kommando kinit auf dem LDAP-Server nicht gefunden wird, installieren Sie das Paket krb5-user.

Sollten Sie die Fehlermeldung ldap_sasl_interactive_bind: Can’t contact LDAP server (-1) erhalten, das aber nur als Benutzer, nicht aber als root, prüfen Sie die Berechtigung der Datei /opt/symas/etc/openldap/cacert.pem. An der Datei muss das Leserecht für other vorhanden sein.

Wenn Sie sich jetzt noch mit klist die Kerberos-Tickets ansehen, werden Sie feststellen, dass das LDAP-Ticket ebenfalls angezeigt wird. In Listing 15.73 sehen Sie ein Beispiel für die aktuelle Ticketliste eines Benutzers:

Listing 15.73 Auflistung der Tickets

u1-prod@provider01:/$ klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_10001 Standard-Principal: u1 prod@EXAMPLE.NET Valid starting Expires Service principal 27.02.2023 10:39:46 27.02.2023 20:39:46 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 28.02.2023 10:39:43 27.02.2023 10:40:01 27.02.2023 20:39:46 ldap/provider01.example.net@\ EXAMPLE.NET erneuern bis 28.02.2023 10:39:43

Interessant ist es, wenn Sie nach erfolgreicher Suche einen Blick in die Systemlog-Datei des LDAP-Serverswerfen und sich den Ablauf der Authentifizierung und der Suche ansehen. In Listing 15.74 sehen Sie einen Auszug aus dem Log:

Listing 15.74 Auszug aus dem Systemlog

ACCEPT from IP=192.168.56.61:47790 (IP=0.0.0.0:636) TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=\ TLS_AES_256_GCM_SHA384 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" SRCH attr=supportedSASLMechanisms SEARCH RESULT tag=101 err=0 qtime=0.000013 etime=0.000144 nentries=1 text= BIND dn="" method=163 RESULT tag=97 err=14 qtime=0.000015 etime=0.010229 text=SASL(0): \ successful result: BIND dn="" method=163 RESULT tag=97 err=14 qtime=0.000008 etime=0.000048 text=SASL(0): \ successful result: BIND dn="" method=163 BIND authcid="u1-prod" authzid="u1 prod" BIND dn="uid=u1-prod,cn=gssapi,cn=auth" mech=GSSAPI bind_ssf=56 ssf=256 RESULT tag=97 err=0 qtime=0.000005 etime=0.000114 text= SRCH base="dc=example,dc=net" scope=2 deref=0 filter="(objectClass=*)" SRCH attr=dn SEARCH RESULT tag=101 err=0 qtime=0.000008 etime=0.000878 nentries=3 text= UNBIND

Aus dem Benutzer-DN cn=u1 prod,ou=users,ou=produktion,ou=firma,dc=example,dc=net ist ein gssapi-Principal uid=u1 prod,cn=gssapi,cn=auth geworden. Auch ein ldapwhoami zeigt als Ergebnis den Principal des Benutzers an. Das sehen Sie auch in Listing 15.75:

Listing 15.75 ldapwhoami ohne Umschreibung des Principals

u1-prod@provider01:/$ ldapwhoami SASL/GSSAPI authentication started SASL username: u1 prod@EXAMPLE.NET SASL SSF: 56 SASL data security layer installed. dn:uid=u1-prod,cn=gssapi,cn=auth

Da sich jetzt der Benutzer mit seinem Principal authentifiziert und auch alle Zugriffe auf den LDAP-Baum mit dem Principal durchführt, kommt es zu Problemen, wenn Sie Ihren LDAP-Baummittels ACLs abgesichert haben.

Durch die geänderte Authentifizierung können Ihre bisherigen ACLs natürlich nicht mehr greifen. Aber auch dafür gibt es eine Lösung: die authz-regexp im globalen Teil der Konfiguration. Über die authz-regexp lassen sich die Principals in LDAP-DNs umschreiben. In Listing 15.76 sehen Sie eine einfache Umsetzung der Principals auf LDAP-DNs:

Listing 15.76 Umschreibung mit nur einer Benutzer-OU

dn: cn=config changetype: modify add: olcAuthzRegexp olcAuthzRegexp: {0}uid=(.+),cn=gssapi,cn=auth \ uid=$1,ou=users,dc=example,dc=net

Das Beispiel geht davon aus, dass alle Benutzer immer im Container ou=users,dc=example, dc=net liegen. Haben Sie mehrere OUs, in denen sich Benutzer befinden, können Sie mehrere dieser Regeln in Ihre Konfiguration eintragen, um in einer komplexeren Umgebung die Umsetzung der Principals zu realisieren.

Wenn Sie Ihre Benutzer aber in vielen verschiedenen Containern im LDAP-Baum abgelegt haben, würden Benutzer in anderen Containern als ou=users,dc=example,dc=net nicht gefunden und daher auch nicht auf einen LDAP-DN umgesetzt. Deshalb sehen Sie in Listing 15.77 eine zweite Möglichkeit, wie Sie die Principals auf den LDAP-DN umsetzen können:

Listing 15.77 Umschreiben aller Benutzer in allen OUs

dn: cn=config changetype: modify add: olcAuthzRegexp olcAuthzRegexp: {0}uid=(.+),cn=gssapi,cn=auth \ ldap:///dc=example,dc=net??sub?(uid=$1) - add: olcAuthzRegexp olcAuthzRegexp: {1}cn=(.+),cn=gssapi,cn=auth \ ldap:///dc=example,dc=net??sub?(cn=$1)

Hinweis: Sollten Sie Benutzer im DN sowohl mit uid als auch mit cn definiert haben, benötigen Sie beide in Listing 15.77 aufgeführten Umschreibungen.

Hier wird der gesamte LDAP-Baum durchsucht. Wichtig ist jetzt nur, dass Ihre Principals im Kerberos und die Benutzernamen im LDAP identisch und eindeutig sind. Auf www.openldap.org/doc/admin24/sasl.html finden Sie eine sehr ausführliche Beschreibung von authz-regexp. Da diese Methode weitaus effizienter ist, als für jede OU eine eigene Regel zu erstellen, werden wir hier im Buch nur diesen Weg weiterverfolgen.

Fragen Sie jetzt erneut mit ldapwhoami ab, werden die Namen immer noch nicht umgeschrieben. Ein Blick in das Logging mit journalctl -f, bei gesetztem Loglevel acl, zeigt, dass noch Berechtigungen fehlen. Das Umschreiben für ldapwhoami wird anonym durchgeführt, und es werden dazu die Attribute entry und uid benötigt. Das bedeutet für Sie, dass Sie eine weitere ACL benötigen, mit der der Zugriff auf die Attribute für anonyme Zugriffe bei einer Authentifizierung gewährt wird. In Listing 15.78 sehen Sie die ACL für die statische Konfiguration:

Listing 15.78 ACL für den Zugriff auf die Attribute entry und uid

dn: olcDatabase={2}mdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attr=entry,uid by anonymous auth by * break

Fügen Sie die ACL am Anfang Ihrer ACLs in die Liste ein, damit bei einem anonymen Zugriff das Recht auf jeden Fall gewährt wird. Vergessen Sie nicht, diese ACL auf allen LDAP-Servern, auch den Consumern, zu installieren.

Nachdem Sie die ACLs angepasst haben, fragen Sie erneut die eigene Kennung mit dem Kommando ldapwhoami ab, dann erhalten Sie den vollständigen DN so wie in Listing 15.79:

Listing 15.79 Neues Ergebnis von ldapwhoami

u1-verw@provider01:~$ ldapwhoami SASL/GSSAPI authentication started SASL username: u1-verw@EXAMPLE.NET SASL SSF: 56 SASL data security layer installed. dn:cn=u1-verw,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net

Nach dem Umschreiben des Principals in den DN des Benutzers wirken jetzt auch wieder alle ACLs, die Sie vor der Einrichtung von Kerberos gesetzt haben, da der Benutzer jetzt alle Anfragen an den LDAP wieder mit seinem eigentlichen DN durchführt.

Da die Authentifizierung jetzt über das Kerberos-Ticket durchgeführt wird, können Sie einfach das Kommando ldapsearch ohne weitere Parameter eingeben und erhalten alle Objekte angezeigt, auf die der Besitzer des Tickets Zugriff hat.

15.10.2

Der sssd mit GSSAPI

Um die Anmeldung komplett über GSSAPI durchzuführen, fehlt jetzt nur noch der sssd, denn dort haben Sie bis jetzt immer noch einen Benutzer eingetragen, zusammen mit dem Klartextpasswort. Um den sssd auf allen Clients auf GSSAPI umzustellen, benötigen Sie als Erstes für jeden Host, auf dem der sssd läuft, einen Host-Principal. Sofern Sie nicht schon einen Host-Principal auf dem ersten System angelegt haben, erstellen Sie jetzt einen Host-Principal und eine Keytab-Datei, damit der Host in der Lage ist, sich am Kerberos zu authentifizieren. Bis zu diesem Zeitpunkt steht in der sssd.conf noch der cn=sssduser,ou=users,dc=example,dc=net mit seinem Passwort im Klartext. Erstellen Sie jetzt einen Principal für den sssd-user und eine Keytab-Datei. Den Principal für den Benutzer können Sie dabei mit einem zufälligen Passwort anlegen. In Listing 15.80 sehen Sie den kompletten Vorgang:

Listing 15.80 Anlegen des Principals für den sssd-user

kadmin: add_principal -x dn="uid=sssd-user,ou=users,dc=example,dc=net" \ -pw geheim sssd-user Für sssd-user@EXAMPLE.NET wurde keine Richtlinie angegeben, es wird die \ Vorgabe keine Richtlinie verwandt. Principal "sssd-user@EXAMPLE.NET" created. kadmin: ktadd -k /root/sssd-user.keytab sssd-user@EXAMPLE.NET Der Eintrag für Principal sssd-user@EXAMPLE.NET mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der \ Schlüsseltabelle WRFILE:/root/sssd-user.keytab hinzugefügt. Der Eintrag für Principal sssd-user@EXAMPLE.NET mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der \ Schlüsseltabelle WRFILE:/root/sssd-user.keytab hinzugefügt.

Kopieren Sie anschließend die Keytab-Datei auf jeden Client in das Verzeichnis /etc/sssd und sorgen Sie dafür, dass nur der sssd-user die Datei lesen kann.

Testen Sie, ob Sie mit dem Benutzer und der dazugehörigen Keytab-Datei ein Ticket beziehen können. In Listing 15.81 sehen Sie das entsprechende Kommando:

Listing 15.81 Erstellen eines TGT mit dem sssd-user

root@provider01:~# kinit -k -t /etc/sssd/sssd-user.keytab sssd-user root@provider01:~# klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_0 Standard-Principal: sssd-user@EXAMPLE.NET Valid starting Expires Service principal 27.02.2023 13:58:57 27.02.2023 23:58:57 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 28.02.2023 13:58:56

Wenn Sie das TGT für den Benutzer erhalten haben, passen Sie jetzt die Datei /etc/sssd/sssd.conf so an wie in Listing 15.82:

Listing 15.82 Umstellung des sssd auf GSSAPI

[sssd] config_file_version = 2 domains = EXAMPLE [nss] reconnection_retries = 4 [pam] reconnection_retries = 4 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 [domain/EXAMPLE] ldap_schema=rfc2307 ldap_dns_service_name=ldaps ldap_uri = _srv_ ldap_search_base=dc=example,dc=net id_provider = ldap auth_provider = krb5 chpass_provider = krb5 krb5_realm = EXAMPLE.NET dns_discovery_domain = EXAMPLE.NET ldap_sasl_mech = GSSAPI ldap_sasl_authid = sssd-user ldap_krb5_keytab = /etc/sssd/sssd-user.keytab ldap_chpass_dns_service_name=kerberos ldap_chpass_uri = _srv_ cache_credentials = True ldap_tls_cacertdir = /opt/symas/etc/openldap/ ldap_tls_cacert = /opt/symas/etc/openldap/cacert.pem

Was hat sich hier geändert?

Der auth_provider und der chpass_provider wurde von ldap auf krb5 geändert.

Die beiden Parameter krb5_realmund dns_discovery_domain wurden mit dem entsprechenden Namen des Realms und der Domäne hinzugefügt. Achten Sie dabei auf die Großschreibung.

Dadurch, dass dns_discovery_domain gesetzt wurde, ist es nicht notwendig, die Kerberos-Server anzugeben. Die Kerberos-Server werden dann über die SRV-Records des DNS-Servers gefunden. Tragen Sie deshalb an der Stelle den Parameter krb5_server = _srv_ein.

Mit dem Parameter ldap_sasl_mech legen Sie den zu verwendenden SASL-Mechanismus fest; in diesem Fall soll das GSSAPI sein.

Bei der Konfiguration ohne GSSAPI stand in der Konfiguration der DN ein simple-SecurityObject. Dieser Eintrag ist bei der Konfiguration über GSSAPI nicht mehr notwendig. Das Gleiche gilt für den Parameter ldap_default_authtok, in dem das Passwort in Klartext eingetragen war. An diese Stellen treten der Parameter ldap_sasl_authid, in dem Sie den Realm des Benutzers angeben, und der Parameter ldap_krb5_keytab, bei dem Sie die Keytab-Datei des Benutzers angeben.

Hinweis: Bei dem Parameter ldap_sasl_authid können Sie entweder die kurze Form des Principals angeben, so wie hier im Beispiel, oder den vollständigen Realm sssduser@EXAMPLE.NET.

Wenn Sie den sssd auf allen Clients, die den sssd zur Anmeldung nutzen, auf GSSAPI umgestellt haben, sollten Sie bei dem sssd-user in Ihrem LDAP das Passwort auf einen langen zufälligen Wert umstellen, denn das wird jetzt nicht mehr benötigt. Löschen können Sie das Passwort nicht, da es sich bei dem sssd-user um ein simpleSecurityObject handelt, und das benötigt zwingend ein Passwort.

Alternativ können Sie das simpleSecurityObject auch komplett löschen und einen neuen Kerberos-Principal für den sssd anlegen. Bei der Replikation via Kerberos werden wir diesen Weg einschlagen.

15.10.3

Anbinden des zweiten KDCs an den LDAP

Nachdem nun der Kerberos-Server seine Informationen im LDAP abgelegt hat und dort sucht, ist es sinnvoll, dass Sie im nächsten Schritt einen zweiten Kerberos-Server einbinden, um die Ausfallsicherheit des Dienstes zu gewährleisten. Hier wird jetzt der in Abschnitt 15.6.3, «Konfiguration des KDC-Slaves», eingerichtete Slave-Kerberos-Server mit an den LDAP angebunden werden. Gehen Sie dazu wie folgt vor:

1. Stoppen Sie den Kerberos-Dienst auf dem Server.

2. Installieren Sie das Paket krb5-kdc-ldap.

3. Löschen Sie die lokale Kerberos-Datenbank mit dem Kommando kdb5_util destroy.

4. Kopieren Sie die Konfigurationsdateien /etc/krb5.conf, /etc/krb5kdc/service.keyfile sowie die /etc/krb5kdc/kdc.conf vom Master-KDC auf den Slave-KDC.

5. Kopieren Sie die Dateien /etc/ldap/ldap.conf und /etc/ldap/cacert.pem des kerberos01 auf den zweiten Kerberos-Server kerberos02. Auf Redhat-Systemen liegen die Dateien im Verzeichnis /etc/openldap.

6. Starten Sie den Kerberos-Dienst neu.

Mit diesen Schritten haben Sie jetzt den Kerberos-Slave-Server ebenfalls an den LDAP gebunden. Der Vorteil dieser Konfiguration ist der, dass Sie so die Replikation der Kerberos-Datenbank nicht mehr über Skripte und den cron realisieren müssen. Beide Kerberos-Server greifen auf die LDAP-Datenbank zu, die immer aktuell ist. Die Replikation der Datenbank ist jetzt Aufgabe des LDAP-Servers. Trotzdem wird es immer nur einen Admin-Server geben.

15.10.4

Replikation mit Kerberos absichern

In Kapitel 12, «Replikation des OpenLDAP-Baums», haben Sie gesehen, wie Sie die Replikation zwischen zwei oder mehr OpenLDAP-Servern einrichten können. In dem Kapitel wurde aber lediglich die Möglichkeit des simple-bind beschrieben. Dabei ist leider nicht möglich, verschlüsselte Passwörter in die Konfiguration einzutragen. Deshalb möchten wir Ihnen hier zeigen, wie Sie die Authentifizierung der Replikation über Kerberos einrichten können. Wir werden in diesem Kapitel nicht mehr auf die Replikation selbst eingehen, hier geht es nur um die Umstellung der Authentifizierung für die Replikation.

Wenn Sie Ihren zweiten LDAP-Server soweit installiert haben, dass die Datenbank bereits repliziert wird, und Sie nur noch die Authentifizierung umstellen möchten, dann sind Sie an dieser Stelle richtig. Denn als Erstes ist es immer sinnvoll, eine funktionierende Replikation einzurichten, sodass die ACLs stimmen und Sie sich nur noch um die Umstellung der Authentifizierung kümmern brauchen. Dabei ist es unerheblich, ob Sie die Replikation zwischen einem Provider und einem Consumer einrichten, oder eine komplexe Umgebung mit einer Multi-Provider-Replikation und verschiedenen Consumern mit Teilreplikation.

15.10.5

Vorbereitung des zweiten LDAP-Servers

Im ersten Schritt sorgen Sie dafür, dass der zweite LDAP-Server über einen Kerberos-Principal, eine Host-Keytab und eine Service-Keytab für den LDAP verfügt. Kopieren Sie die Dateien in die gleichen Verzeichnisse wie schon auf dem ersten LDAP-Server. Vergessen Sie auch nicht den Pfad zur Service-Keytab, abhängig von Ihrer verwendeten Distribution, dem OpenLDAP bekannt zu machen.

In Listing 15.83 sehen Sie alle Kommandos, die Sie für die Erstellung im Programm kadmin ausführen müssen:

Listing 15.83 Alle Kommandos zur Erstellung der Principals

kadmin: add_principal -randkey host/consumer01.example.net Für host/consumer01.example.net@EXAMPLE.NET wurde keine Richtlinie \ angegeben, es wird die Vorgabe keine Richtlinie verwandt. Principal "host/consumer01.example.net@EXAMPLE.NET" created. kadmin: add_principal -randkey ldap/consumer01.example.net Für ldap/consumer01.example.net@EXAMPLE.NET wurde keine Richtlinie \ angegeben, es wird die Vorgabe keine Richtlinie verwandt. Principal "ldap/consumer01.example.net@EXAMPLE.NET" created. kadmin: ktadd -k /root/consumer01-krb5.keytab host/consumer01.example.net Der Eintrag für Principal host/consumer01.example.net mit KVNO 3 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ WRFILE:/root/consumer01-krb5.keytab hinzugefügt. Der Eintrag für Principal host/consumer01.example.net mit KVNO 3 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ WRFILE:/root/consumer01-krb5.keytab hinzugefügt. kadmin: ktadd -k /root/consumer01-krb5.keytab ldap/consumer01.example.net Der Eintrag für Principal ldap/consumer01.example.net mit KVNO 3 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ WRFILE:/root/consumer01-krb5.keytab hinzugefügt. Der Eintrag für Principal ldap/consumer01.example.net mit KVNO 3 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ WRFILE:/root/consumer01-krb5.keytab hinzugefügt. kadmin: q root@kerberos01:~# scp consumer01-krb5.keytab consumer01:/etc/krb5.keytab root@kerberos01:~# scp consumer01-ldap.keytab consumer01:/opt/symas/etc/openldap/ldap.keytab

Die folgenden Schritte sind noch nötig, damit Sie den LDAP-Server komplett vorbereitet haben:

Sorgen Sie dafür, dass der LDAP-Server auch die Authentifizierung über GSSAPI nutzen kann. Installieren Sie das Paket libsasl2-modules-gssapi-mit, wenn Sie Debian verwenden, und das Paket cyrus-sasl-gssapi, wenn Sie Redhat einsetzen.

Kopieren Sie die Datei /opt/symas/etc/sasl2/slapd.conf vom Provider auf den Consumer.

Kopieren Sie die Datei /etc/krb5.conf vom Provider auf den neuen Consumer.

Installieren Sie das Paket krb5-user auf dem Consumer, wenn Sie dort die Tickets verwalten möchten. Das kann am Anfang hilfreich sein, ist aber für die Funktion nicht erforderlich.

Starten Sie den LDAP-Dienst auf dem Consumer neu.

15.10.6

Einrichtung von k5start

Bei der Replikation via GSSAPI wird immer auch ein TGT benötigt, um das entsprechende Ticket für die Authentifizierung zu bekommen. Es reicht aber nicht, einfach ein Ticket beim Start für den LDAP-Server zu beziehen, denn die Kerberos-Tickets haben immer ein Ablaufdatum, sprich das Ticket muss regelmäßig erneuert werden. Dieser Vorgang lässt sich mit dem Programm k5start aus dem Paket kstart realisieren. Um automatisch ein Ticket zu beziehen und es auch automatisch zu verlängern, installieren Sie als Erstes das Paket auf dem Consumer.

Wenn Sie bereits eine Replikation mit einem simple-bind eingerichtet haben, gibt es bei Ihnen schon einen Benutzer, der alle Objekte auf dem LDAP-Master lesen kann. Sofern Sie für den Benutzer noch keinen Principal angelegt haben, holen Sie das jetzt nach und erstellen auch sofort eine Keytab-Datei für den Benutzer. Kopieren Sie die Keytab-Datei anschließend auf den Consumer.

Wie schon beim sssd angesprochen, können Sie das bestehende simpleSecurityObject auch durch einen reinen Kerberos-Principal ersetzen. Bei der Replikation wollen wir diesen Weg einschlagen.

Dazu legen Sie als Erstes einen neuen Principal im kadmin an, ohne aber ein simpleSecurityObject zu erstellen. Erstellen Sie gleichzeitig eine Keytab-Datei für den Principal. Hier im Beispiel verwenden wir den Namen krb5-repl. Kopieren Sie anschließend die Keytab-Datei auf den Consumer. Sorgen Sie dafür, dass die Gruppe openldap das Leserecht an der Keytab-Datei besitzt.

Testen Sie, so wie in Listing 15.84, ob Sie sich mit der Keytab-Datei authentifizieren und ob Sie anschließend eine LDAP-Suche mit dem Ticket starten können:

Listing 15.84 Testen der Keytab-Datei

root@consumer01:~# kinit -k -t /opt/symas/etc/openldap/krb5-repl.keytab \ krb5-repl root@consumer01:~# klist Ticketzwischenspeicher: FILE:/tmp/krb5cc_0 Standard-Principal: krb5-repl@EXAMPLE.NET Valid starting Expires Service principal 27.02.2023 16:21:30 28.02.2023 02:21:30 krbtgt/EXAMPLE.NET@EXAMPLE.NET erneuern bis 28.02.2023 16:21:30 root@consumer01:~# ldapsearch -H ldaps://provider01.example.net -LLL dn SASL/GSSAPI authentication started SASL username: krb5-repl@EXAMPLE.NET SASL SSF: 56 SASL data security layer installed. dn: dc=example,dc=net dn: ou=firma,dc=example,dc=net

Sie sehen hier, dass lediglich die oberste Ebene und die ou=firma angezeigt wird, wenn Sie auf den Provider zugreifen. Es fehlen noch die ACLs, sodass der neue Replikations-Principal auch auf die Objekte zugreifen kann.

Nur wem geben Sie die Rechte? Dazu führen Sie, nachdem Sie das Ticket für den Principal gezogen haben, das Kommando ldapwhoami aus. Dort sehen Sie, dass Sie die Suche mit dem dn:uid=krb5-repl,cn=gssapi,cn=auth durchgeführt haben. Dieses Objekt benötigt jetzt die Rechte Ihres Replikationsbenutzers, der momentan in Ihre Konfiguration eingetragen ist.

Hinweis: Denken Sie auch an die ACLs einer eventuell eingerichteten DeltaSync-Replikation. Der Principal benötigt dann auch die Leserechte an der accesslog-Datenbank. Wollen Sie die Multi-Provider-Replikation des cn=config einrichten, dann benötigt der Principal auch noch Rechte an der Konfiguration.

Wenn Sie mehrere Consumer oder eine Multi-Provider-Umgebung haben, können Sie auch erst beiden die Rechte geben. So können Sie nach und nach alle Consumer umstellen, und wenn alle Consumer umgestellt sind, dann löschen Sie das simpleSecurityObject, das Sie für die Replikation genutzt haben.

Für den nächsten Schritt benötigen Sie die UID des LDAP-Benutzers Ihres Systems. Die UID brauchen Sie, um automatisch die richtige Datei für den Ticket-Cache zu erstellen. Die Dateien für den Ticket-Cache setzen sich immer aus dem Präfix krb5cc_und der UID des Benutzers zusammen. Im Buch verwenden wir die UID 998 in den Beispielen.

Jetzt können Sie sicher sein, dass ein Zugriff auf alle Objekte des Masters mit dem Replikations-Principal unter Verwendung der Keytab-Datei möglich ist. Starten Sie jetzt mit einem Test, den Sie mit dem Kommando k5start auf der Kommandozeile durchführen. Starten Sie das Programm wie in Listing 15.85:

Listing 15.85 Ausführung von k5start auf der Kommandozeile

root@consumer01:~# k5start -k /tmp/krb5cc_998 -f /opt/symas/etc/openldap/\ krb5-repl.keytab -K 10 -l 10h krb5-repl & [1] 1380

Anschließend finden Sie im Verzeichnis /tmp die Datei kr5cc_998, in der sich das TGT befindet. Das Ticket wird mit der Keytab-Datei /opt/symas/etc/openldap/krb5-repl.keytab erzeugt. Alle 10 Minuten -K 10 prüft das Programm, ob das Ticket noch gültig ist. Kurz vor Ablauf des Tickets wird das Ticket automatisch erneuert. Das Ticket hat eine Gültigkeit vom 10 Stunden -l 10h und wird mit dem Principal host/consumer01.example.net angefordert.

Solange der Prozess im Hintergrund läuft, wird das Ticket jetzt regelmäßig erneuert. Aber was, wenn der Server einmal neu gestartet wird? Dann muss das Kommando immer wieder neu gestartet werden. Am einfachsten ist es daher, wenn Sie ein Systemd-Skript mit dem Namen k5start.service schreiben, das das Kommando wie einen Dienst behandelt und beim Neustart des Systems automatisch den k5start startet. In Listing 15.86 sehen Sie ein Systemd-Skript für k5start:

Listing 15.86 Systemd-Skript für k5start

[Unit] Description=k5start for generating tickets After=syslog.target network.target [Service] StartLimitInterval=5 StartLimitBurst=10 ExecStart=/usr/bin/k5start -k /tmp/krb5cc_998 \ -m 600 -o openldap -g openldap -U \ -f /opt/symas/etc/openldap/krb5-repl.keytab -K 10 -l 10h Restart=always RestartSec=120 [Install] WantedBy=multi-user.target

Im Skript haben wir anstelle des kompletten Principals den Parameter -U verwendet. Dieser Parameter liest den Principal aus der angegebenen Keytab-Datei aus – in diesem Fall den Host-Principal.

Hinweis: Achten Sie darauf, dass Sie die Parameter -m 600 -o openldap -g openldap nicht vergessen, denn ohne diese Parameter hat der LDAP-Benutzer keine Rechte, den Ticket-Cache zu lesen. Vergeben Sie mehr als diese Rechte, startet der LDAP-Server mit der Fehlermeldung:

GSSAPI Error: Miscellaneous failure (see text) (Refuses to open group/ other readable files FILE:/tmp/krb5cc_998)

Nachdem Sie das Skript im Verzeichnis /etc/systemd/system erstellt haben, starten Sie anschließend das Skript zum ersten Mal von Hand und prüfen den Status. Wenn k5start jetzt als Dienst läuft, sorgen Sie dafür, dass das Skript auch beim Systemstart automatisch gestartet wird. Den gesamten Vorgang sehen Sie in Listing 15.87:

Listing 15.87 Starten des Systemd-Skripts

root@consumer01:~# systemctl start k5start root@consumer01:~# systemctl status k5start . k5start.service - k5start for generating tickets Loaded: loaded (/etc/systemd/system/k5start.service; enabled; vendor \ preset: enabled) Active: active (running) since Mon 2023-02-27 17:07:48 CET; 2min 17s ago Main PID: 1476 (k5start) Tasks: 1 (limit: 1130) Memory: 652.0K CPU: 6ms CGroup: /system.slice/k5start.service 1476 /usr/bin/k5start -k /tmp/krb5cc_998 -m 600 -o openldap \ -g openldap -U -f /opt/symas/etc/openldap/krb5-repl.keytab -K 10 -l 10h root@ldapserver-02:~# systemctl enable k5start Created symlink /etc/systemd/system/multi-user.target.\ wants/k5start.service -> \ /etc/systemd/system/k5start.service.

15.10.7

Umstellung der Replikation auf GSSAPI

Erst wenn Sie das TGT automatisch für den Replikationsbenutzer erstellen können, dürfen Sie mit der Umstellung der Replikation beginnen.

Jetzt fehlt nur noch die Anpassung der syncrepl-Direktive in Ihrer Konfiguration des Consumers. Dafür benötigen Sie eine LDIF-Datei, um die bestehende Replikation anzupassen oder eine neue Replikation zu erstellen. Den Inhalt der LDIF-Datei sehen Sie in Listing 15.88:

Listing 15.88 Anpassung der Konfiguration

dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=000 provider=ldaps://provider01.example.net type=refreshAndPersist tls_reqcert=allow retry="60 10 120 5" searchbase="dc=example,dc=net" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=sasl saslmech=gssapi syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"

Wenn Sie jetzt noch zusätzlich das Loglevel repl aktivieren und den LDAP-Dienst neu starten, können Sie sehen, dass die Replikation jetzt via GSSAPI authentifiziert wird. Listing 15.89 zeigt die Einträge im Log:

Listing 15.89 Log-Einträge für die Replikation via GSSAPI

Started Symas OpenLDAP Server Daemon. GSSAPI client step 1 GSSAPI client step 1 GSSAPI client step 1 GSSAPI client step 2 do_syncrep1: rid=000 starting refresh (sending cookie=rid=000,\ csn=20230227163123.061023Z#000000#000#000000) do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - REFRESH_DELE

15.11

Konfiguration des LAM-Pro

Wenn Sie Ihre Benutzer nicht nur über die Kommandozeile verwalten wollen, sondern auch über ein grafisches Werkzeug, ist der LDAP Account Manager (LAM) eine gute Wahl. Die LAM-Pro-Version ist zwar nicht kostenfrei, bietet aber die Möglichkeit, Ihre Benutzer komplett grafisch zu verwalten, inklusive aller Kerberos-Parameter.

Um Ihnen einen Einblick in die Möglichkeiten zu geben, wollen wir Ihnen hier die Funktion der Benutzerverwaltung mit dem LAM zeigen. Die Pro-Version unterstützt, im Gegensatz zur Community-Version, die Verwaltung der Kerberos-Attribute. So ist es mit dem LAM möglich, neue Benutzer in einem Schritt anzulegen.

Hinweis: Durch den Kauf des Buchs haben Sie die Möglichkeit, eine Testlizenz für drei Monate zu erhalten. Mit dieser Lizenz können Sie die nachfolgende Anleitung und Verwaltung der Benutzer testen. Um die Testlizenz zu erhalten, schreiben Sie eine Mail mit dem Betreff OpenLDAP-Buch an post@rolandgruber.de.

Bei der Einrichtung des LAM haben Sie zwei Möglichkeiten: Sie können den LAM, samt der benötigten Pakete für den Apache-Webserver, auf einem Ihrer Kerberos- oder LDAP-Server anlegen oder Sie stellen eine eigene Maschine für den Webserver bereit. Den geringsten Aufwand bei der Einrichtung haben Sie, wenn Sie den LAM auf Ihrem Kerberos-Server einrichten, auf dem auch der Admin-Server des Kerberos läuft. Da der LAM die Passwörter ändern können soll, wird das Programm kadmin benötigt.

Da es sinnvoll ist, Dienste getrennt auf einzelnen Servern bereitzustellen, werden wir Ihnen hier zeigen, wie Sie den Webserver mit dem LAM auf einem extra Server einrichten können. Wir werden hier nicht auf die Installation des Webservers eingehen und auch nicht auf die Konfiguration einer https-Verbindung zum Webserver.

Hinweis: Tragen Sie den Webserver auf jeden Fall in Ihren DNS ein, denn ohne die Namensauflösung kann der Host nicht identifiziert werden.

15.11.1

Vorbereitung des Webservers

Im ersten Schritt laden Sie sich das Paket für den LAM von der Website https://www.ldap-account-manager.org/lamcms/lamPro herunter. Nach der Installation benötigen Sie als Erstes die Lizenz. Für die Verwaltung der Benutzer benötigen Sie nur den LDAP Account Manager. Den lamdaemon benötigen Sie nur dann, wenn Sie für neue Benutzer beim Anlegen auch ein Heimatverzeichnis auf einem Dateiserver anlegen wollen. Installieren Sie anschließend das Paket mit allen Abhängigkeiten.

Erzeugen Sie auf Ihrem Admin-Server einen Host-Principal für den neuen Host und erstellen Sie eine Keytab-Datei für den Host, die Sie im Anschluss auf dem neuen Host nach /etc/krb5.keytab kopieren. In Listing 15.90 sehen Sie die benötigten Schritte:

Listing 15.90 Erstellen des Host-Principals und der Keytab-Datei

kadmin: addprinc -randkey host/lam-pro.example.net Für host/lam-pro.example.net@EXAMPLE.NET wurde keine Richtlinie angegeben, \ es wird die Vorgabe keine Richtlinie verwandt. Principal "host/lam-pro.example.net@EXAMPLE.NET" created. kadmin: ktadd -k /root/lam-pro-krb5.keytab host/lam-pro.example.net Der Eintrag für Principal host/lam-pro.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der \ Schlüsseltabelle WRFILE:/root/lam-pro-krb5.keytab hinzugefügt. Der Eintrag für Principal host/lam-pro.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der \ Schlüsseltabelle WRFILE:/root/lam-pro-krb5.keytab hinzugefügt. kadmin: quit root@kerberos01:~# scp /root/lam-pro-krb5.keytab lam-pro:/etc/krb5.keytab

Kopieren Sie auch die Datei /etc/krb5.conf eines Kerberos-Clients auf den neuen Server. Damit haben Sie den Host für die Kerberos-Authentifizierung vorbereitet.

Damit Sie später auch über den LAM die Kerberos-Passwörter der Benutzer ändern können, sind vorab noch zwei Schritte für Webserver nötig.

Der Webserver wird später das Programm kadmin aufrufen, um die Passwörter zu ändern. Daher benötigt der Webserver auch das Recht dazu. Das Recht erhält der Webserver über einen Service-Principal. Diesen legen Sie als Erstes an, um anschließend eine Keytab-Datei exportieren zu können, die dann in dem Webserver eingebunden wird. In Listing 15.91 sehen Sie die Vorgehensweise:

Listing 15.91 Erstellen des Service-Principals und der Keytab-Datei

kadmin: addprinc -randkey HTTP/lam-pro.example.net Für HTTP/lam-pro.example.net@EXAMPLE.NET wurde keine Richtlinie angegeben, \ es wird die Vorgabe keine Richtlinie verwandt. Principal "HTTP/lam-pro.example.net@EXAMPLE.NET" created. kadmin: ktadd -k /root/lam-pro-web.keytab HTTP/lam-pro.example.net Der Eintrag für Principal HTTP/lam-pro.example.net mit KVNO 2 und \ Verschlüsselungstyp aes256-cts-hmac-sha384-192 wurde der Schlüsseltabelle \ WRFILE:/root/lam-pro-web.keytab hinzugefügt. Der Eintrag für Principal HTTP/lam-pro.example.net mit KVNO 2 und \ Verschlüsselungstyp aes128-cts-hmac-sha256-128 wurde der Schlüsseltabelle \ WRFILE:/root/lam-pro-web.keytab hinzugefügt. kadmin: q root@kerberos01:~# scp /root/lam-pro-web.keytab lam-pro:/etc/apache2/

Sorgen Sie jetzt noch dafür, dass der Webserver in der Lage ist, die Passwörter der Benutzer-Principals ändern zu können. Dazu passen Sie die Datei kadm5.acl wie in Listing 15.92 an:

Listing 15.92 Anpassung der Kerberos-ACLs

*/admin@EXAMPLE.NET * HTTP/lam.example.net c *@EXAMPLE.NET il */*@EXAMPLE.NET i

Der Service-Principal für den Webserver erhält dadurch das Recht, alle Passwörter zu ändern.

Wichtig: Passen Sie die Datei auf allen Kerberos-Servern an.

Starten Sie anschließend alle KDCs und den Admin-Server neu, um die Änderungen wirksam werden zu lassen. Jetzt können Sie, wie in Listing 15.93, das Ändern der Passwörter testen:

Listing 15.93 Testen der Passwortänderung

root@kerberos01:~# kadmin -k -t /root/lam-pro-web.keytab -p \ HTTP/lam-pro.example.net -q ’cpw -pw Gans!Geheim skania’ Authentifizierung als Principal HTTP/lam-pro.example.net mit \ Schlüsseltabelle /root/lam-pro-web.keytab Passwort von skania@EXAMPLE.NET geändert

Wenn Sie die Passwörter der Principals so direkt auf dem Kerberos-Server ändern können, testen Sie auch, ob Sie das Kommando ebenfalls auf dem Webserver fehlerfrei ausführen können. Erst dann sind Sie soweit, um mit den nächsten Schritten fortzufahren.

Hinweis: Das Kommando kadmin befindet sich im Paket krb5-user, zusammen mit den Kommandos zur Ticketverwaltung.

Ein Schritt fehlt noch auf dem Webserver. Die Gruppe, unter der der Webserver läuft, benötigt das Leserecht an der Keytab-Datei, die Sie auf dem Webserver kopiert haben. Achten Sie darauf, dass nur der Besitzer root und die Gruppe des Webservers Rechte an der Keytab-Datei besitzt. Others darf keine Rechte an der Datei haben, da sonst jeder diese Datei zur Authentifizierung nutzen könnte. An der Stelle können Sie jetzt das neue Profil anlegen, so wie Sie es in Bild 15.4 sehen.

Nachdem Sie den LAM mit allen Abhängigkeiten installiert haben, können Sie sich über http://<webserver>/lam mit dem LAM verbinden. Im Gegensatz zur Community-Version benötigen Sie jetzt den Lizenzschlüssel, den Sie auf der Website des LAMs in Ihrem persönlichen Bereich finden. Tragen Sie den Schlüssel in die Konfiguration ein, ändern das Master-Passwort und speichern Sie die Änderungen. Wenn Sie sich mit Ihrem LDAP-Server über TLS oder LDAPS verbinden wollen, benötigen Sie noch das Root-Zertifikat Ihrer CA. Laden Sie das Zertifikat im Abschnitt Security settings hoch. In Bild 15.3 sehen Sie das eingetragene Zertifikat.

Bild 15.3 Einbinden des Root-Zertifikats der CA

Anschließend können Sie den LAM konfigurieren. Klicken Sie dafür im Anmeldefenster oben rechts auf LAM CONFIGURATION. Jetzt können Sie direkt ein neues Profil erstellen, indem Sie auf EDIT SERVER PROFILES klicken. Im nächsten Fenster klicken Sie auf MANAGE SERVER PROFILES.

Bild 15.4 Erstellen des Profils

Nachdem Sie auf ADD geklickt haben, geben Sie das Master-Passwort ein. Sie werden dann automatisch auf die nächste Seite der Einrichtung weitergeleitet.

15.11.2

Konfiguration des LAM

Passen Sie dort die Bereiche Server settings wie in Bild 15.5 an:

Bild 15.5 Server settings des LAM

Vergessen Sie nicht, im Abschnitt Tool setting den Tree Suffix wie in Bild 15.6 einzugeben.

Bild 15.6 Der Tree suffix

Und Security settings wie in Bild 15.7:

Bild 15.7 Sicherheitseinstellungen der Anmeldung

Durch die Verwendung der Option LDAP-SEARCH können sich später alle Benutzer am LAM anmelden. Sie können aber auch über die Option FIXED-LISTE nur bestimmte Benutzer eintragen.

Anschließend klicken Sie am oberen Rand auf den Karteireiter ACCOUNT TYPES. An der Stelle haben Sie die Möglichkeit, weitere Kontenmodule zur Verwaltung hinzuzufügen. Für die Verwaltung des Kerberos werden an der Stelle keine weiteren Account types benötigt. Für die beiden Account types Users und Groups fehlt noch die Anpassung des LDAP suffix, so wie Sie es in Bild 15.8 sehen.

Bild 15.8 Anpassung des LDAP-suffix

Tipp: Wenn Sie hier bei den Benutzerobjekten noch das Attribute krbPrincipalName mit angeben, sehen Sie in der Kontoübersicht später auch die Principals, die keine Unix-Attribute besitzen.

Erst jetzt können Sie auf den Karteireiter MODULES klicken.

An der Stelle fügen Sie das Modul Kerberos(mitKerberos) zum Modul Users hinzu. So können Sie später alle Benutzer direkt mit den Kerberos-Attributen versorgen. Wählen Sie an der Stelle auf gar keinen Fall das Modul Kerberos(mitKerberosStructural) aus, denn Ihre Benutzer haben bereits eine structuralObjectClass, und jedes Objekt im LDAP kann nur eine structuralObjectClass besitzen. In Bild 15.9 sehen Sie das angepasste Modul.

Bild 15.9 Das angepasste Modul Users

Jetzt klicken Sie auf den Karteireiter MODULE-SETTINGS, dort geben Sie im Abschnitt Kerberos das Kommando zum Setzen des Passworts ein. Dabei handelt es sich um das Kommando, das Sie am Anfang dieses Abschnitts auf der Kommandozeile getestet haben. Passen Sie die Pfade an Ihre Umgebung an. In Bild 15.10 sehen Sie das eingefügte Kommando.

Bild 15.10 Kommando zur Passwortänderung

Speichern Sie jetzt die Einstellungen und verbinden sich dann mit dem LDAP-Server, indem Sie das neue Profil auswählen.

Ein Klick auf TREE VIEW zeigt Ihnen dann den kompletten Baum mit allen Objekten so wie in Bild 15.11:

Bild 15.11 Die Baumansicht aller Objekte

Bei dem hier ausgewählten Benutzer sehen Sie auch gleich, dass die Kerberos-Attribute direkt dem Benutzerobjekt zugeordnet sind.

Damit Sie jetzt neue Benutzer gleich mit dem korrekten Realm anlegen können, benötigen Sie noch eine Anpassung im Profil zur Benutzerverwaltung im LAM. Klicken Sie auf TOOLS, anschließend auf PROFIL EDITOR. Dort gibt es ein Profil für die Verwaltung der Benutzer. Editieren Sie das Profil und tragen Sie im Abschnitt Kerberos Ihren Realm ein, so wie Sie es in Bild 15.12 sehen:

Bild 15.12 Eintragen des Realms in das Benutzerprofil

Achten Sie darauf, den Realm in Großbuchstaben zu schreiben. Speichern Sie anschließend das Profil.

Über den Karteireiter USERS legen Sie neue Benutzer an und können bestehende Benutzer verwalten. Beim Neuanlegen eines Benutzers aktivieren Sie zusätzlich zu den Modulen Personal und Unix auch noch das Modul Kerberos. Dort wird auch sofort der Realm angezeigt. Setzen Sie noch das Passwort für den Benutzer über die Schaltfläche SET PASSWORD. Das Unix-Passwort benötigen Sie nicht. In Bild 15.13 sehen Sie die Einstellungen des Kerberos-Moduls:

Bild 15.13 Einstellungen des Moduls Kerberos

Wenn Sie jetzt auf SAVE klicken, wird der neue Benutzer mit allen Attributen im LDAP gespeichert. Schauen Sie sich den neuen Benutzer in der Baumansicht an, dann sehen Sie dort, dass alle Attribute des Benutzers zusammengefasst sind. So sind Sie jetzt in der Lage, alle Benutzer auch grafisch mit allen Attributen zu verwalten.

Über die Baumansicht des LAM-Pro können Sie auch die Policies der Kerberos-Credentials anpassen, erstellen oder löschen. In Bild 15.14 sehen Sie die ganz am Anfang erstellte Policy user.

Bild 15.14 Anpassen der Policies

Mehr zum Thema LAM finden Sie im Kapitel 7, «Grafische Werkzeuge».

Das Kapitel hat Ihnen gezeigt, wie Sie Ihre Umgebung erheblich sicherer machen können. Nicht jeder Host kann einfach auf Dienste zugreifen. Benutzer und Hosts müssen sich authentifizieren. Beim Einsatz von GSSAPI können Sie an vielen Stellen auf das simple bind verzichten und können so Klartextpasswörter aus Ihren Konfigurationen entfernen.

Trotz allem kann Kerberos das Leben auch erleichtern, denn Sie können so eine Single sign-on- Umgebung einrichten. Wenn Sie OpenLDAP produktiv in Netzen einsetzen, auf die auch externe Kunden oder Mitarbeiter Zugriff haben, sollte Kerberos immer in Ihre Planung einbezogen werden.