[[Vorlage(archiviert)]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Terminal: Ein Terminal öffnen] [:sudo: Root-Rechte] [:Archiv/Kerberos: Kerberos] }}} [[Inhaltsverzeichnis()]] [[Bild(Wiki/Icons/service.png, 48, align=left)]] 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: * LDAP nutzt Kerberos als Authorisierungs-Dienst und Passwortspeicher, hält also keine Passwort-Informationen in der eigenen Datenbank mehr. * Kerberos nutzt LDAP als Keystore und hält selber keine Benutzer-Informationen. Welches Szenario eingesetzt wird, ist stark davon abhängig, welche Sicherheitsanforderungen vorliegen und welcher Dienst/Protokoll besser abgeschottet werden kann. {{{#!vorlage 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: {{{#!vorlage Paketinstallation 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. {{{#!vorlage Befehl 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 }}} ##aasche: was ist ein "config-Node"? 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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl sudo testsaslauthd -u user -p password -r REALM -s ldap }}} {{{#!vorlage 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 }}} {{{#!vorlage 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: {{{#!vorlage Befehl ldapwhoami -x -D "uid=user,ou=users,dc=example,dc=com" -W }}} {{{#!vorlage 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. {{{#!vorlage Paketinstallation krb5-kdc-ldap, universe }}} {{{#!vorlage Befehl 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. {{{#!vorlage Befehl 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 }}} ##aasche: was ist ALC?? Das fertige LDIF muss ins LDAP eingespielt werden, die ACL angepasst und ein Index über krbPrincipalName angelegt werden. LDIF-Einspielen: * {{{#!vorlage Befehl 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. {{{#!vorlage Experten 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: {{{#!vorlage Paketinstallation libsasl2-modules-gssapi-mit, universe }}} Zum Aktivieren der GSS-Api muss der Parameter `-Y` angegeben werden. {{{#!vorlage Befehl 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 }}} = Links = * [ubuntu_doc:lts/serverguide/kerberos-ldap.html:Ubuntu-Serverguide: Kerberos-LDAP] * [http://aput.net/~jheiss/krbldap/howto.html HOWTO: Replacing NIS with Kerberos and LDAP] {en} * [http://www.itp.uzh.ch/~dpotter/howto/kerberos HOWTO: Kerberos/LDAP/NFSv4] {en} * [http://research.imb.uq.edu.au/~l.rathbone/ldap/gssapi.shtml Kerberos, GSSAPI and SASL Authentication using LDAP] {en} - Fehler, die beim Zusammenspiel Kerberos/LDAP auftreten können * [http://www.mpipks-dresden.mpg.de/~mueller/docs/suse10.3/opensuse-manual_de/manual/sec.kerbadmin.ldap.html Verwenden von LDAP und Kerberos] {de} * [:Serverdienste:] {Übersicht} Übersichtsseite # tag: Netzwerk, System, Sicherheit, Server, Kerberos