Rheinwerk Computing :: Linux-Server

14.11 Kerberos in LDAP einbinden

Bis zu diesem Zeitpunkt 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.

[+] Hier gehen wir davon aus, dass Sie bereits einen wie in Kapitel 17, »LDAP«, eingerichteten LDAP-Server in Ihrem Netz haben. Wenn das nicht der Fall ist, sollten Sie als Erstes einen LDAP-Server einrichten, da hier nur noch die Änderungen am LDAP-Server angesprochen werden.

14.11.1 Konfiguration des LDAP-Servers

[+] Stellen Sie sicher, dass auf allen Kerberos-Servern das Paket krb5-kdc-ldap installiert ist, da ohne dieses Paket die Einbindung von Kerberos in den LDAP-Server nicht möglich ist.

Damit der LDAP-Server die benötigten Objekte verwalten kann, müssen Sie das entsprechende Schema in die Konfigurationsdatei Ihres LDAP-Servers eintragen.

Dazu kopieren Sie die Datei /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz in das Verzeichnis /etc/ldap/schema und entpacken es dort. Anschließend können Sie das Schema in der Datei slapd.conf so wie in Listing 14.39 eintragen:

# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/kerberos.schema

Listing 14.39 Schemaeintrag in der Datei »slapd.conf«

Anschließend starten Sie den LDAP-Dienst neu. Für die Verwaltung der Objekte legen Sie am besten eine neue Organizational Unit ou 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-Baum immer den rootdn des LDAP-Servers nehmen. 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 14.40 sehen Sie die entsprechenden LDIF-Einträge:

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: {SSHA}35OXDd6OCjyvI3yzH/YW+05lNbtH3AAh

dn: cn=kadmin,ou=kerberos-adm,dc=example,dc=net
cn: kadmin
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword: {SSHA}QD5NHgP5EL+/7avq/yTil/fy9R31J9OM

Listing 14.40 LDIF-Einträge für die ersten Objekte

[+] Die Passwörter können Sie mit dem Kommando slappasswd 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. Sie müssen nur schon jetzt mit ACLs im LDAP-Verzeichnis dafür sorgen, dass die beiden administrativen Objekte später auch schreibenden Zugriff auf die Kerberos-Daten haben.

[ ! ] Anpassen der Limits

Denken Sie daran, dass eventuell die maximal angezeigten Suchlimits auf 500 begrenzt sind. Kerberos muss aber alle Objekte durchsuchen können. Deshalb müssen Sie auf jeden Fall für beide Objekte diese Limits aufheben, so wie Sie das in Listing 14.41 sehen.

Die beiden Objekte cn=kdc und cn=kadmin benötigen im LDAP-Verzeichnis Schreibrechte an den Benutzerobjekten und den Kerberos-Objekten. In Listing 14.41 sehen Sie die ACLs, die sicherstellen, dass die beiden Objekte die benötigten Rechte erhalten:

limits dn.exact="cn=kdc,ou=kerberos-adm,dc=example,dc=net"
        size=unlimited time=unlimited

limits dn.exact="cn=kadmin,ou=kerberos-adm,dc=example,dc=net"
        size=unlimited time=unlimited
access to dn.sub="ou=users,dc=example,dc=net"
        by dn.exact="cn=kdc,ou=kerberos-adm,dc=example,dc=net" write
        by dn.exact="cn=kadmin,ou=kerberos-adm,dc=example,dc=net" write
        by * break

access to dn.sub="cn=kerberos,dc=example,dc=net"
        by dn.exact="cn=kdc,ou=kerberos-adm,dc=example,dc=net" write
        by dn.exact="cn=kadmin,ou=kerberos-adm,dc=example,dc=net" write
        by * break

Listing 14.41 ACLs für die Objekte »kdc« und »kadmin«

[+] Die Zeilen by * break sorgen dafür, dass diese ACL für alle anderen Objekte übersprungen wird.

Um die Performance des LDAP-Servers zu verbessern, sollten Sie immer die beiden Attribute krbPrincipalName und krbPwdPolicyReference indizieren. Dazu ergänzen Sie Ihre slapd.conf durch die Zeile aus Listing 14.42:

index           krbPrincipalName eq
index           krbPwdPolicyReference eq

Listing 14.42 Indexeinträge in der Datei »slapd.conf«

Anschließend erzeugen Sie, wie in Listing 14.43 zu sehen, die Indexdatenbanken. Denken Sie daran, den LDAP-Server vorher zu stoppen:

root@adminbuch:/etc/ldap# slapindex -f /etc/ldap/slapd.conf

WARNING!
Runnig as root!
There's a fair chance slapd will fail to start.
Check file permissions!

Listing 14.43 Erzeugung der Indexdatenbanken

Da Sie das Kommando slapindex als Benutzer root ausgeführt haben, stimmen die Berechtigungen der Datenbankdateien nicht. Diese müssen Sie im Verzeichnis /var/lib/ldap so anpassen, dass der LDAP-Dienst das Schreib- und Leserecht hat. Anschließend können Sie den LDAP-Server wieder starten.

[+] Da bei der Neueinrichtung des Servers zu diesem Zeitpunkt noch keine Objekte mit den entsprechenden Attributen existieren, werden die Indexdatenbanken noch nicht erzeugt. Die Datenbanken werden dann beim Anlegen des ersten Objekts automatisch erzeugt.

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

14.11.2 Umstellung des Kerberos-Servers

Im ersten Schritt erzeugen Sie ein Backup der Kerberos-Datenbank. Dieses Backup benötigen Sie später auch noch, um die Daten in den LDAP-Baum zu übernehmen. Als Erstes stoppen Sie den KDC und den kadmin-server auf Ihrem Kerberos-Master-Server. Dann erstellen Sie das Backup mit dem Kommando kdb5_util dump /root/example.net.backup. In diesem Backup finden Sie alle Principals und alle Richtlinien, die Sie bis zu diesem Zeitpunkt im Kerberos erzeugt haben.

[ ! ] Alte Datenbank löschen

Vergessen Sie nicht, die alte 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 Ihrem Kerberos-Server müssen Sie jetzt die Datei /etc/krb5.conf so anpassen, dass der Kerberos-Server die Datenbank in Ihrem LDAP-Server sucht und nicht mehr in der lokalen Datenbank. In Listing 14.44 sehen Sie die neue Datei krb5.conf:

[libdefaults]
        default_realm = EXAMPLE.NET

[realms]
        EXAMPLE.NET = {
                admin_server = k1.example.net
                database_module = ldapconf
       }

[domain_realm]
        .example.net = EXAMPLE.NET

[logging]
        kdc = FILE:/var/log/krb5/kdc.log
        admin_server = FILE:/var/log/krb5/kadmd.log
        default = SYSLOG:NOTICE:DAEMON

[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 = "ldap://k1.example.net"
                ldap_conns_per_server = 5
                }

Listing 14.44 Die neue Datei »krb5.conf«

Die neuen Parameter haben die folgenden Bedeutungen:

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.
[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 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.
ldap_kdc_dn = "cn=kdc,ou=kerberos-adm,dc=example,dc=net"
Hier geben Sie das Objekt des KDC 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 = "ldap://k1.example.net"
Hier können Sie, durch Leerzeichen voneinander getrennt, Ihre LDAP-Server angeben.
ldap_conns_per_server = 5
Anzahl der Verbindungen, die der Kerberos-Server zum LDAP-Server geöffnet halten soll. Der Wert von 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 initialisieren. In Listing 14.45 sehen Sie den Initialisierungsvorgang:

root@k1:~# kdb5_ldap_util create -D cn=admin,dc=example,dc=net \
           -r EXAMPLE.NET -s -sscope sub
Password for "cn=admin,dc=example,dc=net":
Initializing database for realm 'EXAMPLE.NET'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

Listing 14.45 Initialisierung der Kerberos-Datenbank im LDAP-Baum

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-Baum die Objekte wie in Listing 14.46.

[ ! ] Wahl der Master-Keys

Sie sollten beim Master-Key für die Datenbank unbedingt denselben Schlüssel verwenden wie schon bei der lokalen Datenbank. Dies ist notwendig, damit die Entschlüsselung der lokalen Datenbank im LDAP-Server vorgenommen werden kann.

root@k1:/etc# ldapsearch -x attrs dn -LLL
[…]
dn: ou=kerberos-adm,dc=example,dc=net

dn: cn=kdc,ou=kerberos-adm,dc=example,dc=net

dn: cn=kadmin,ou=kerberos-adm,dc=example,dc=net

dn: cn=kerberos,dc=example,dc=net

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=krbtgt/EXAMPLE.NET@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/changepw@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/k1.example.net@EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,\
    dc=example,dc=net

Listing 14.46 Kerberos-Objekte im LDAP-Baum

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

In Abbildung 14.1 sehen Sie das Ergebnis im LDAP Access Manager (LAM Pro).

Abbildung 14.1 Kerberos-Objekte im »LAM Pro«

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 14.47 können Sie diesen Vorgang nachvollziehen:

root@k1:~# 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
Password for "cn=admin,dc=example,dc=net":
Password for "cn=kdc,ou=kerberos-adm,dc=example,dc=net":
Re-enter password for "cn=kdc,ou=kerberos-adm,dc=example,dc=net":

root@k1:~# 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
Password for "cn=admin,dc=example,dc=net":
Password for "cn=kadmin,ou=kerberos-adm,dc=example,dc=net":
Re-enter password for "cn=kadmin,ou=kerberos-adm,dc=example,dc=net":

Listing 14.47 Erstellung der »stash«-Datei

Als Datei für die Passwörter wird hier die in Listing 14.44 angegebene Datei /etc/krb5kdc/service.keyfile verwendet. Achten Sie darauf, dass in der Datei service.keyfile der komplette DN der Objekte steht, so wie es in Listing 14.48 zu sehen ist:

cn=kdc,ou=kerberos-adm,dc=example,dc=net#{HEX}67656865696d
cn=kadmin,ou=kerberos-adm,dc=example,dc=net#{HEX}67656865696d

Listing 14.48 Inhalt der Datei »service.keyfile«

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

14.11.3 Zurücksichern der alten Datenbank

Im nächsten Schritt kann jetzt die alte Kerberos-Datenbank, die Sie als dump gesichert haben, eingespielt werden. Hierzu wird das Kommando kdb5_util verwendet. In Listing 14.49 sehen Sie den Vorgang des Imports und das anschließende Auflisten aller Principals:

root@k1:~# kdb5_util -update load example.net.backup
root@k1:~# kadmin.local -q listprincs
Authenticating as principal root/admin@EXAMPLE.NET with password.
K/M@EXAMPLE.NET
krbtgt/EXAMPLE.NET@EXAMPLE.NET
kadmin/admin@EXAMPLE.NET
kadmin/changepw@EXAMPLE.NET
kadmin/history@EXAMPLE.NET
kadmin/k1.example.net@EXAMPLE.NET
host/k1.example.net@EXAMPLE.NET
host/k2.example.net@EXAMPLE.NET
ktom@EXAMPLE.NET
ptau@EXAMPLE.NET
root/admin@EXAMPLE.NET
stefan@EXAMPLE.NET

Listing 14.49 Importieren der gesicherten Kerberos-Datenbank

Testen Sie anschließend wieder mit ldapsearch -x attrs dn -LLL, ob auch alle Principals im LDAP-Baum angelegt wurden. Wenn das der Fall ist, haben Sie die Datenbank erfolgreich zurückgesichert. Starten Sie jetzt die Dienste für den Kerberos-Server.

[✓] Wenn Sie auf einer zweiten Konsole unter Debian oder Ubuntu ein tail -f /var/log/syslog oder bei openSUSE oder CentOS ein tail -f /var/log/messages parallel 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.

Jetzt können Sie testen, ob sich die bestehenden Benutzer am LDAP-Verzeichnisdienst, die schon einen Principal besitzen, auch authentifizieren können. Den Test können Sie mit dem Kommando kinit durchführen, wie Sie es in Listing 14.50 sehen:

root@k1:~# kinit stefan
Password for stefan@EXAMPLE.NET:
root@k1:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: stefan@EXAMPLE.NET

Valid starting       Expires              Service principal
25.05.2016 19:02:57  26.05.2016 05:02:57  krbtgt/EXAMPLE.NET@EXAMPLE.NET
        renew until 26.05.2016 19:02:55

Listing 14.50 Testen der Authentifizierung mit »kinit«

14.11.4 Erstellung der Service-Keys in der Standard-»keytab«-Datei

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 einen Service-Principal für den LDAP-Server erstellen und einen keytab-Eintrag in der Datei /etc/krb5.keytab erzeugen. Listing 14.51 zeigt diesen Vorgang:

kadmin:  addprinc -randkey ldap/k1.example.net
WARNING: no policy specified for ldap/k1.example.net@EXAMPLE.NET; \
         defaulting to no policy
Principal "ldap/k1.example.net@EXAMPLE.NET" created.

kadmin:  ktadd ldap/k1.example.net
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          des-cbc-crc added to keytab FILE:/etc/krb5.keytab.

Listing 14.51 Erstellen des Principals für den LDAP-Server

[+] Achten Sie auf die Rechte

Damit der LDAP-Server den Key auch lesen kann, müssen Sie unbedingt darauf achten, dass die Rechte an der keytab-Datei richtig gesetzt sind. Die Datei sollte immer dem Benutzer root gehören, der dann die Rechte read und write besitzt. Als Gruppe müssen Sie immer die Gruppe eintragen, 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.

14.11.5 Erstellung der Service Keys in einer eigenen Datei

Etwas mehr Aufwand müssen Sie treiben, wenn Sie eine eigene keytab-Datei für den LDAPServer erstellen wollen. Das hat aber den Vorteil, dass in der Datei dann nur der LDAP-Key enthalten ist und nur der LDAP-Server diese Datei nutzen kann. Der LDAP-Dienst kann anschließend auch nicht mit den anderen noch in der Standard-keytab-Datei enthaltenen Schlüsseln eine Authentifizierung durchführen.

In einem Produktivsystem sollten Sie immer für jeden Dienst eine eigene keytab-Datei erzeugen und mit den entsprechenden Rechten versehen. Listing 14.52 zeigt diesen Vorgang:

kadmin:  addprinc -randkey ldap/k1.example.net
WARNING: no policy specified for ldap/k1.example.net@EXAMPLE.NET; \
         defaulting to no policy
Principal "ldap/k1.example.net@EXAMPLE.NET" created.

kadmin:  ktadd -k /etc/ldap/slapd.keytab ldap/k1.example.net
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/ldap/slapd.keytab.
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          arcfour-hmac added to keytab FILE:/etc/ldap/slapd.keytab.
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          des3-cbc-sha1 added to keytab FILE:/etc/ldap/slapd.keytab.
Entry for principal ldap/k1.example.net with kvno 2, encryption type \
          des-cbc-crc added to keytab FILE:/etc/ldap/slapd.keytab.

Listing 14.52 Erstellen des Principals für den LDAP-Server

Jetzt müssen Sie dem LDAP-Server nur noch mitteilen, dass er die neue keytab-Datei auch verwenden soll. Dazu müssen Sie in der Konfigurationsdatei /etc/default/slapd die Variable export KRB5_KTNAME=/etc/ldap/slapd.keytab setzen. Nachdem Sie die Datei erzeugt und die Konfiguration angepasst haben, müssen Sie den LDAP-Server auf jeden Fall neu starten.

[+] Achten Sie auf die Rechte

Damit der LDAP-Server den Key auch lesen kann, müssen Sie unbedingt darauf achten, dass die Rechte an der keytab-Datei richtig gesetzt sind. Die Datei sollte immer dem Benutzer openldap gehören, der dann die Rechte read und write besitzt. Die Gruppe und andere benötigen keine Rechte.

14.11.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 können Sie wieder mit dem Kommando kdb5_ldap_util durchführen, so wie Sie es in Listing 14.53 sehen:

root@k1:~# kdb5_ldap_util modify -D cn=admin,dc=example,dc=net -r EXAMPLE.NET \
           -subtrees ou=users,dc=example,dc=net
Password for "cn=admin,dc=example,dc=net" :

root@k1:~# kdb5_ldap_util view -D cn=admin,dc=example,dc=net -subtrees
Password for "cn=admin,dc=example,dc=net":
               Realm Name: EXAMPLE.NET
                  Subtree: ou=users,dc=example,dc=net
              SearchScope: SUB

Listing 14.53 Erweitern des Suchpfads für Kerberos

Nachdem Sie den Suchpfad erweitert haben, können Sie das Ergebnis mit dem Kommando ldapsearch -x "(cn=EXAMPLE.NET)" -LLL überprüfen, wie Sie es in Listing 14.54 sehen:

root@kerberos1:~# ldapsearch -x "(cn=EXAMPLE.NET)" -LLL
dn: cn=EXAMPLE.NET,ou=kerberos,dc=example,dc=net
cn: EXAMPLE.NET
objectClass: top
objectClass: krbRealmContainer
objectClass: krbTicketPolicyAux
krbSearchScope: 2
krbSubTrees: ou=users,dc=example,dc=net

Listing 14.54 Suche im LDAP-Baum

[+] Hier sehen Sie, dass es jetzt ein Attribut krbSubTrees: ou=users,dc=example,dc=net gibt. Nach dieser Änderung müssen Sie den KDC- und den kadmin-server unbedingt neu starten.

Leider können Sie die alten Passwörter der bestehenden Benutzer nicht in den entsprechenden Principal migrieren. Für alle Benutzer im LDAP-Baum müssen Sie also ein neues Passwort vergeben. Um die bestehenden Benutzer, die schon einen Principal im LDAP-Baum besitzen, nun zusammenzuführen, müssen Sie erst den alten Principal löschen und dann das bestehende Benutzerobjekt um die entsprechenden Attribute erweitern. Das realisieren Sie wieder mit dem Kommando kadmin, so wie Sie es in Listing 14.55 sehen:

root@kerberos1:~# kadmin
Authenticating as principal root/admin@EXAMPLE.NET with password.
Password for root/admin@EXAMPLE.NET:

kadmin:  delete_principal stefan
Are you sure you want to delete the principal "stefan@EXAMPLE.NET"? (yes/no): yes
Principal "stefan@EXAMPLE.NET" deleted.
Make sure that you have removed this principal from all ACLs before reusing.

kadmin:  add_principal -x dn="uid=stefan,ou=users,dc=example,dc=net" -pw \
         geheim stefan
WARNING: no policy specified for stefan@EXAMPLE.NET; defaulting to no policy
Principal "stefan@EXAMPLE.NET" created.

Listing 14.55 Erweitern der bestehenden Benutzer

Nach dem Löschvorgang wurde ein neuer Principal erstellt. Diesem wurde mit dem Parameter -x dn="uid=stefan,ou=users,dc=example,dc=net" ein Benutzer im LDAPBaum zugewiesen. In Listing 14.56 sehen Sie, dass der neue Principal jetzt wieder vorhanden ist:

kadmin:  list_principals
stefan@EXAMPLE.NET
K/M@EXAMPLE.NET
krbtgt/EXAMPLE.NET@EXAMPLE.NET
kadmin/admin@EXAMPLE.NET
kadmin/changepw@EXAMPLE.NET
kadmin/history@EXAMPLE.NET
kadmin/adminbuch.example.net@EXAMPLE.NET
host/adminbuch.example.net@EXAMPLE.NET
host/adminbuch-repl.example.net@EXAMPLE.NET
host/lx-client.example.net@EXAMPLE.NET
ldap/adminbuch.example.net@EXAMPLE.NET
root/admin@EXAMPLE.NET

Listing 14.56 Neue Liste der Principals