ubuntuusers.de

LDAP

Archivierte Anleitung

Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Wiki/Icons/service.png Sowohl LDAP als auch Kerberos bieten in den aktuellen Versionen schon standardmäßig Schnittstellen zum Einbinden des jeweils anderen Protokolls/Dienstes. Ziel dieser Integration ist immer das Delegieren von Teilaufgaben an eine andere Autorität. Es gibt folgende Konfigurationsszenarios:

Welches Szenario eingesetzt wird, ist stark davon abhängig, welche Sicherheitsanforderungen vorliegen und welcher Dienst/Protokoll besser abgeschottet werden kann.

Hinweis:

Für alle weiteren Schritte wird ein funktionierender OpenLDAP und Archiv/Kerberos-Server vorausgesetzt.

GSS-API/SASL - Anfragen über Kerberos-Ticket authentifizieren

Um die GSS-API zu nutzen benötigt man folgendes Paket:

  • libsasl2-modules-gssapi-mit

Befehl zum Installieren der Pakete:

sudo apt-get install libsasl2-modules-gssapi-mit 

Oder mit apturl installieren, Link: apt://libsasl2-modules-gssapi-mit

LDAP nutzt die GSS-API (Generic Security Services API), um Benutzer nicht mehr über Usercredentials (Login/Password) zu autorisieren, sondern Kerberos-Tickets zu nutzen. Damit LDAP Kerberos Tickets für Abfragen annimmt, muss dem slapd eine Kerberos Keytab zur Verfügung gestellt werden. Standardmäßig ist das unter Ubuntu die Datei /etc/krb.keytab. Diese ist jedoch nur für root zugänglich. Es ist daher besser, eine eigene Keytab für slapd anzulegen.

sudo kadmin -p someadmin/admin
addprinc -randkey ldap/ldap.server.realm
ktadd -k /etc/ldap/ldap.keytab ldap/ldap.server.realm
exit
sudo chown openldap /etc/ldap/ldap.keytab 

Anschließend muss der slapd diese keytab nutzen. Dazu in der /etc/default/slapd folgende Anpassung machen:

export KRB5_KTNAME=/etc/ldap/ldap.keytab

Nach einem Neustart des slapd-Daemons kann man die GSS-API über die LDAP-Befehle aktivieren. Dazu müssen in der config-Node ein paar Attribute gesetzt/hinzugefügt werden.

Folgendes Zeilen können via ldapmodify ausgeführt werden:

dn: cn=config
changetype: modify
add: olcSaslHost
olcSaslHost: sasl.server.realm

dn: cn=config
add: olcSaslRealm
olcSaslRealm: REALM

# Das hier nur einkommentieren, wenn ein User existiert, der cn=config bearbeiten darf. Sonst sperrt man sich aus!
#dn: cn=config
#add: olcSaslSecProps
#olcSaslSecProps: noplain,noactive,noanonymous,minssf=56

#Usermapping setzten
#Kerberos -> LDAP Object
#username -> username.users.example.com
dn: cn=config
add: olcAuthzRegexp
olcAuthzRegexp: {0}"uid=([^/]*),cn=GSSAPI,cn=auth" "uid=$1,ou=users,dc=example,dc=com"

#username@realm -> username.users.example.com
dn: cn=config
add: olcAuthzRegexp
olcAuthzRegexp: {1}"uid=([^/]*),cn=realm,cn=GSSAPI,cn=auth" "uid=$1,ou=users,dc=example,dc=com"


#host/hostname.realm@realm -> hostname.hosts.example.com
dn: cn=config
add: olcAuthzRegexp
olcAuthzRegexp: {2}"uid=host/([^/]*).realm,cn=realm,cn=gssapi,cn=auth" "cn=$1,ou=hosts,dc=example,dc=com"

Anschließend kann man bei vorhandener Kerberos-Umgebung folgenden Test machen:

kdestroy      #alte Tickets löschen
kinit         #Tickets aktualiseren

ldapwhoami 

SASL - Kerberos als Passwordspeicher

Damit LDAP die Authentisierung an Kerberos weiterreicht, wird ein SASL-Daemon als Vermittler benötigt. Standardmäßig ist dieser bei Ubuntu deaktiviert. Über /etc/default/saslauthd kann man ihn aktivieren und auf Kerberos als Backend umstellen.

START=yes
...
...
...
MECHANISMS="kerberos5"

Nach einem Start des SASL-Daemons kann man einen ersten Test durchführen:

sudo testsaslauthd -u user -p password -r REALM -s ldap 

Hinweis:

Damit der SASL-Daemon Abfragen gegen Kerberos absetzt kann, wird ein gültiger Host-Key benötigt: host/server.fqdn. Sollte es dennoch zu Problemen beim Authentisieren kommen, ist es hilfreich, Kerberos und den SASL-Daemon in einer Shell zu starten und den Debug-Level hoch zu setzen.

Ist der SASL-Auth-Daemon korrekt konfiguriert, muss LDAP angewiesen werden, auf SASL als Password-Backend zurück zugreifen. Dazu wird die Datei /etc/ldap/sasl2/slapd.conf bearbeitet:

pwcheck_method: saslauthd

Nach einen Neustart des LDAP-Dienstes muss nun für jeden Benutzer getrennt der SASL-Modus aktiviert werden. Dazu wird im Feld olcPassword folgender String hinterlegt werden.

{SASL}user@REALM

Hinweis:

Der LDAP-User muss Zugriff auf die SASL-Pipe bekommen. Dazu muss er der Gruppe SASL angehören!

Als abschließenden Test kann man über die "SimpleAuth" überprüfen, ob das Kerberos-Password korrekt überprüft wird:

ldapwhoami -x -D "uid=user,ou=users,dc=example,dc=com" -W 

Hinweis:

Der SASL-Dienst speichert die Kerberos-Tickets nach der ersten Authentisierung zwischen (Cache). Wird am Kerberos das Password geändert, kann es ein bisschen dauern, bis der SASL-Daemon die Änderung übernimmt.

LDAP als KDC

Der Einsatz von LDAP als Keystore für Kerberos ist ungleich einfacher zu konfigurieren. Als erstes muss man das Kerberos eigene Schema im LDAP hinterlegen.

  • krb5-kdc-ldap (universe)

Befehl zum Installieren der Pakete:

sudo apt-get install krb5-kdc-ldap 

Oder mit apturl installieren, Link: apt://krb5-kdc-ldap

sudo gzip -d /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz
sudo cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema /etc/ldap/schema/ 

Anschließend wird die Schema-Datei in eine LDIF-Datei überführt. Dazu eine Datei mit beliebigen Namen (im Beispiel schema.convert) mit folgendem Inhalt anlegen:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/kerberos.schema

Mit folgendem Befehl wird eine LDIF-Datei erzeugt, wobei die {12} durch die Zeilennummer des "include" der kerberos.schema zu ersetzen ist, wenn man eine andere Schema-Datei hat.

mkdir -p ~/ldif_convert/tmp
slapcat -f schema.convert -F ~/ldif_convert/tmp -n0 -s "cn={12}kerberos,cn=schema,cn=config" > ~/ldif_convert/kerberos.ldif 

Die kerberos.ldif muss mit einem Editor bearbeitet werden. Folgende Zeilen müssen angepasst werden:

dn: cn=kerberos,cn=schema,cn=config
...
cn: kerberos

Und am Dateiende muss alles ab "structuralObjectClass: olcSchemaConfig" gelöscht werden.

structuralObjectClass: olcSchemaConfig
entryUUID: {UUID}
creatorsName: cn=config
createTimestamp: {TIMESTAMP}Z
entryCSN: {TIMESTAMP}Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: {TIMESTAMP}Z

Das fertige LDIF muss ins LDAP eingespielt werden, die ACL angepasst und ein Index über krbPrincipalName angelegt werden. LDIF-Einspielen:

  • ldapadd -D cn=admin,cn=config -f ~/ldif_convert/kerberos.ldif 
  • Folgende Zeilen per ldapmodify ausführen, um einen Index über krbPrincipalName anzulegen:

    dn: olcDatabase={1}hdb,cn=config
    add: olcDbIndex
    olcDbIndex: krbPrincipalName eq,pres,sub
  • Folgende Zeilen per ldapmodify ausführen, um die neuen Kerberos-Attribute ACLs gegen unprivilegierten Zugriff zu schützen:

    dn: olcDatabase={1}hdb,cn=config
    replace: olcAccess
    olcAccess: to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn=admin,dc=exampl
     e,dc=com" write by anonymous auth by self write by * none
    -
    add: olcAccess
    olcAccess: to dn.base="" by * read
    -
    add: olcAccess
    olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read

Anschließend muss der Kerberos auf LDAP als KDC umgestellt werden. Dazu in der /etc/krb5.conf folgende Anpassung machen:

[libdefaults]
        default_realm = EXAMPLE.COM

...

[realms]
        EXAMPLE.COM = {
                kdc = kdc01.example.com
                admin_server = kdc01.example.com
                default_domain = example.com
                database_module = openldap_ldapconf
        }

...

[domain_realm]
        .example.com = EXAMPLE.COM


...

[dbdefaults]
        ldap_kerberos_container_dn = dc=example,dc=com

[dbmodules]
        openldap_ldapconf = {
                db_library = kldap
                ldap_kdc_dn = "cn=admin,dc=example,dc=com"
                ldap_kadmind_dn = "cn=admin,dc=example,dc=com"
                ldap_service_password_file = /etc/krb5kdc/service.keyfile
                ldap_servers = ldaps://ldap.example.com
                ldap_conns_per_server = 5
        }

Nach einem Neustart des Kerberos wird nun LDAP als Keystore genutzt.

Experten-Info:

Bei einem bestehenden Kerberos-System sollte man nicht direkt auf LDAP als KDC umstellen, da man so alle bisherigen Keys/Principals verliert. Besser ist es einen temporären zweiten Kerberos aufzusetzen, diesen LDAP als Backend nutzen zu lassen und anschließend einen Sync zwischen beiden Kerberos-Servern anzustoßen.

Client-Konfiguration

Prinzipiell wird auf Clientseite keine zusätzliche Konfiguration benötigt. Nur wenn die LDAP-Befehle über Kerberos authentifiziert werden sollen, wird auf Clientseite folgendes Paket zusätzlich benötigt:

  • libsasl2-modules-gssapi-mit (universe)

Befehl zum Installieren der Pakete:

sudo apt-get install libsasl2-modules-gssapi-mit 

Oder mit apturl installieren, Link: apt://libsasl2-modules-gssapi-mit

Zum Aktivieren der GSS-Api muss der Parameter -Y angegeben werden.

ldapsearch -Y "dc=example,dc=com" 

Will man diese Parameter dauerhaft setzen, muss man in der Datei /etc/ldap/ldap.conf den SASL_MECH-Parameter hinterlegen:

BASE    dc=example,dc=com
URI     ldap://ldap.example.com
SASL_MECH GSSAPI

Diese Revision wurde am 4. Januar 2022 17:45 von noisefloor erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Server, Netzwerk, System, Sicherheit, Kerberos