Foliensatz 8
Kerberos, LDAP
Inhalt
• Kerberos
• LDAP
Kerberos
• Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das für das Athena-Projekt des MIT entwickelt wurde. Die aktuelle Version 5 ist in RFC4120 definiert.
• Mittels Kerberos kann man eine sichere Authentifizierung in einem ungesicherten Netzwerk auf sicheren Rechnern anbieten, wobei die Authentifizierung durch eine dritte Partei, dem Kerberos-Server, übernommen wird.
Der Kerberos-Server authentifiziert den Client gegenüber dem Server, den Server gegenüber dem Client und sich selbst gegenüber dem Client und den Server. Dabei werden sogenannte Tickets verwendet, um die Identität nachzuweisen. Diese Tickets erlauben auch ein Single-Sign-On, d.h.
Passwörter müssen nur einmal eingegeben werden. Zudem kann die Kommunikation zwischen den Parteien verschlüsselt werden.
• Bekannte Implementierung sind MIT Kerberos, Heimdal Kerberos und Microsoft Active Directory.
Links: Designing an Authentication System: a Dialogue in Four Scenes
Kerberos - Funktionsweise
• Ein Kerberos-Server verwaltet ein Realm, in welchem jeder Benutzer und jeder Dienst einem Principal zugeordnet ist, der wiederum einen einzigartigen Schlüssel besitzt.
• Der Kerberos-Server ist unter dem Namen Key Distribution Center (KDC) bekannt und besteht aus zwei separaten Diensten: dem Authentication Server (AS) und dem Ticket Granting Server (TGS).
• Der Authentication Server wird benutzt, um einen Principal zu authentifizieren und ein Ticket Granting Ticket (TGT) auszustellen.
• Mit diesem TGT kann der Principal dann über den Ticket Granting Server spezielle Tickets für Dienste anfordern.
• Ein Princpal hat die Form Komponente/Komponente/...@REALM. Für Benutzer gibt es üblicherweise nur eine Komponente mit dem Benutzernamen, eventuell auch eine zweite für die Funktion. Bei Diensten hat der Principal die Form Dienstname/FQDN@REALM.
Kerberos - Protokoll
Kerberos - Vor- und Nachteile
Vorteile:
• Kerberos-Nachrichten sind gegen Lauschangriffe und Replay-Attacken geschützt.
• Die Kommunikation zwischen Client und Server kann verschlüsselt werden.
• Der Client und der Server können gegenseitig ihre Identität verifizieren.
• Single-Sign-On wird unterstützt.
• Das Protokoll funktioniert über ungesicherte Netzwerke hinweg.
Nachteile:
• Ohne Kerberos-Server funktioniert die Authentifizierung von Benutzern und Diensten nicht mehr (kann durch Verwenden von mehreren Kerberos-Servern behoben werden).
• Die Uhren aller Rechner müssen wegen der Benutzung von Zeitstempeln unbedingt synchron gehalten werden.
• Wird der Kerberos-Server geknackt, sind alle Schlüssel kompromitiert.
Kerberos - Installation
• Wichtig: Damit Kerberos richtig funktioniert, müssen alle Domainnamen aufgelöst werden können!
• Die für den Kerberos-Server nötigen Pakete sind krb5-admin-server und krb5-kdc. Bei der Installation wird man nach einigen Daten gefragt (Werte für das Beispielszenario sind angegeben):
• „Voreingestellter Realm für Kerberos Version 5“ → HOME
• „Kerberos-Server für Ihren Realm“ → ict-infrastruktur.home
• „Administrations-Server für Ihren Kerberos-Realm“ → ict-infrastruktur.home
• Danach muss der Realm mit Hilfe von krb5_newrealm angelegt und mit einem Passwort geschützt werden.
• In die Datei /etc/krb5.conf trägt man dann noch in der Sektion [domain_realm] folgende Definitionen für den eigenen Realm ein:
.home = HOME home = HOME
Links: Ubuntu Kerberos Seite, Kerberos Installation von Spinlock Solutions
Kerberos - Konfiguration
• In der Datei /etc/krb5.conf sind Daten für die Grundkonfiguration von Kerberos eingetragen (z.B.
welche Realms es gibt und wie deren Server heißen). Diese Datei muss es auch auf Clientrechnern geben.
• Im Verzeichnis /etc/krb5kdc gibt es die folgenden Dateien:
• kdc.conf → Konfigurationsdatei für den KDC
• kadm5.acl → Enthält ACLs für den Zugriff auf die Kerberos-Datenbank
• stash → Enthält den Schlüssel für die Kerberos-Datenbank
Damit Administratoren (Principals der Form Benutzername/admin@REALM) Vollzugriff auf die Kerberos-Datenbank haben, wird folgender Eintrag zu kadm5.acl hinzugefügt und danach der krb5- admin-server neu gestartet:
*/admin *
• Über das Programm kadmin.local wird nun ein Benutzer für die Administration angelegt, in dem man das Programm startet und addprinc root/admin sowie ein Password für den Benutzer eingibt.
Danach mit quit das Programm beenden.
• Ab sofort kann nun mittels kadmin über das Netzwerk die Kerberos-Datenbank administriert werden.
Kerberos - Clientprogramme
Die Clientprogramme für Kerberos sind im Paket krb5-user enthalten.
kinit - Holt Ticket Granting Tickets.
» Wird benutzt, um ein TGT vom KDC zu holen und lokal zu speichern.
» $ kinit praxis
Password for praxis@HOME:
kdestroy - Zerstört zwischengespeicherte Tickets.
» Die Tickets werden durch Löschen der Datei mit den Tickets zerstört.
» $ kdestroy
klist - Zeigt zwischengespeicherte Tickets an.
» Optionen: -f → zeige zusätzlich Flags an.
» $ klist -f
Ticket cache: FILE:/tmp/krb5cc_1515 Default principal: praxis@HOME
Valid starting Expires Service principal 2014-05-18 16:24:47 2014-05-19 02:24:47 krbtgt/HOME@HOME renew until 2014-05-19 16:24:42, Flags: FPRIA
2014-05-18 16:34:16 2014-05-19 02:24:47 host/ict-infrastruktur.home@HOME renew until 2014-05-19 16:24:42, Flags: FPRAT
Kerberos - OpenSSH-Server
• Damit man via OpenSSH per Kerberos einloggen kann, muss man einen Principal mit zufälligem Schlüssel für OpenSSH erzeugen und dann nach /etc/krb5.keytab (der Standardpfad für lokale Schlüssel) exportieren:
kadmin: addprinc -randkey host/FQDN
kadmin: ktadd -k /etc/krb5.keytab -norandkey host/FQDN
• Nun muss in /etc/ssh/sshd_config noch die Option GSSAPIAuthentication yes gesetzt und der OpenSSH-Dämon neu gestartet werden.
• Hat man auf dem Clientrechner kein TGT, dann mit kinit eines holen. Danach kann man sich ohne Passwort am OpenSSH-Server anmelden.
Die Option -K erlaubt zusätzlich das Weiterleiten des TGT, damit man am Server auch Kerberos- Dienste ohne Eingabe eines Passwortes benutzen kann.
Kerberos - NFSv4-Server
• Am NFS-Server muss in /etc/default/nfs-kernel-server die Option NEED_SVCGSSD=yes gesetzt werden, am NFS-Client in /etc/default/nfs-common die Option NEED_GSSD=yes.
• Sowohl für den Server als auch für den Client wird ein Principal der Form nfs/FQDN@REALM in /etc/krb5.keytab gebraucht (siehe Anleitung bei „Kerberos - OpenSSH-Server“).
• In /etc/idmapd.conf muss der Realm-Name als NFS-Domain gesetzt werden.
• Beim Exportieren am NFS-Server muss man über die sec= Option eine oder mehrere durch Doppelpunkte getrennte Sicherheitsstufen definieren:
• krb5 → Host-Authentifikation mit Kerberos
• krb5i → Host-Authentifikation mit Kerberos und Integritätsprüfung
• krb5p → Host-Authentifikation mit Kerberos und Verschlüsselung
• Danach den NFS-Server, idmapd und rpc.gssd neu starten.
Kerberos - Apache HTTP-Server
• Das Single-Sign-On von Kerberos lässt sich auch auf den Zugriff auf den Apache HTTP-Server ausdehnen. Dazu muss das Paket libapache2-mod-auth-kerb installiert werden. Nach der Installation ist das Modul automatisch aktiviert.
• Der HTTP-Server braucht wieder einen eigenen Principal der Form HTTP/FQDN@REALM. Diesen sollte man in einer eigene Schlüsseldatei (z.B. /etc/apache2/http.keytab) speichern, weil der Server unter dem Benutzer „www-data“ läuft und Zugriff darauf braucht.
• Um nun einen Bereich des HTTP-Servers zu schützen, kann man folgende Konfiguration verwenden:
<Location />
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On KrbMethodK5Passwd Off KrbAuthRealms HOME
Krb5KeyTab /etc/apache2/http.keytab require valid-user
</Location>
Kerberos - Microsoft Active Directory
• Microsoft Active Directory (AD) verwendet für die Authentifizierung von Rechnern, Diensten und Benutzern auch Kerberos v5.
• Jeder AD Server fungiert dabei als KDC, die Kerberos-Datenbank wird automatisch auf alle AD Server verteilt.
• Die nötigen Schlüssel für Rechner, Dienste und Benutzer werden im entsprechenden Objekt im LDAP-Teil des AD gespeichert.
• Hat man eine gemischte Systemumgebung bestehend aus Windows- und Linux-Rechnern, so ist es meistens am einfachsten, das AD zum Speichern der Benutzerdaten zu verwenden und dann die Benutzerdaten auf den Linux-Rechnern über LDAP vom AD abzufragen bzw. die Benutzer über Kerberos zu authentifizieren.
LDAP
• Das Leightweight Directory Access Protocol (LDAP) ist ein Protokoll zur Abfrage von Daten eines Verzeichnisdienstes. Die aktuelle Version LDAPv3 ist in den RFCs 4510 bis 4519 definiert.
• Ein LDAP-Server ist ein Verzeichnisdienst (Directory Server), der über LDAP abgefragt werden kann und dessen interne Struktur der LDAP-Spezifikation entspricht.
• Über LDAP kann man sich an einem Server anmelden (LDAP-Bind) und Suchabfragen bzw.
Änderungsanfragen tätigen.
• Bekannte Implementierungen von LDAP-Servern sind OpenLDAP und Microsoft Active Directory.
LDAP-Verzeichnis
• Der LDAP-Server speichert die Daten in einer Baumstruktur, dem Directory Information Tree (DIT). Die Struktur des DIT wird durch ein genormtes, erweiterbares LDAP-Schema festgelegt.
• Jeder Eintrag im DIT ist ein LDAP-Objekt, das zu einer oder mehreren Objektklassen gehört, die festlegen, welche Attribute im Objekt entweder zwingend oder optional vorhanden sein müssen.
• Jedes Attribute hat einen festgelegten Namen und kann einen oder mehrere Werte enthalten.
Attributnamen sind z.B. „dc“ (domain component), „cn“ (common name), „ou“ (organisational unit) und „sn“ (surname).
• Jedes Objekt besitzt einen auf seiner Hierarchieebene eindeutigen Relative Distinguished Name (RDN). Die Zusammensetzung des RDNs eines Objekts mit den RDNs seiner übergeordneten LDAP- Objekte bis zur Wurzel des DIT wird Distinguished Name (DN) genannt. Jeder DN ist eindeutig im DIT.
Beispiel für DN: cn=Administrator,ou=Users,dc=univie,dc=ac,dc=at
• Objekte eines LDAP-Verzeichnisses können mittels LDAP Data Interchange Format (LDIF) als ASCII-Text dargestellt werden.
LDAP - Beispielobjekt im LDIF-Format
# Thomas Leitner, Admin, Benutzer, math
dn: CN=Thomas Leitner,OU=Admin,OU=Benutzer,DC=math objectClass: top
objectClass: person
objectClass: organizationalPerson objectClass: user
cn: Thomas Leitner sn: Leitner
givenName: Thomas
displayName: Thomas Leitner
homeDirectory: \\share1\users\leitner homeDrive: U:
profilePath: \\share2\profiles\leitner\leitner userPrincipalName: leitner@math
uid: leitner
mail: thomas.leitner@univie.ac.at loginShell: /bin/bash
unixUserPassword: ABCD!efgh12345$67890 gecos: Thomas Leitner
unixHomeDirectory: /users/leitner gidNumber: 501
uidNumber: 850
LDAP - Programme und LDAP-Abfragen
• Die CLI-Programme zur Kommunikation mit einem LDAP-Server können mittels des Pakets ldap-utils installiert werden.
• Die wichtigsten dieser Programme sind ldapadd (zum Hinzufügen von LDAP-Objekten), ldapmodify (zum Ändern von Objekten) und ldapsearch (zum Durchsuchen des Verzeichnisses).
• Für das Hinzufügen bzw. Ändern von LDAP-Objekten wird LDIF benutzt, für das Abfragen eine spezielle Filtersyntax, die in RFC4515 definiert ist.
• Beispiele für die Filtersyntax:
• (givenName=Thomas)
Objekte, bei denen das Attribut „givenName“ den Wert „Thomas“ hat
• (sn=*)
Objekte, bei denen das Attribut „sn“ irgendeinen Wert hat
• (&(objectClass=posixAccount)(!(uid=leitner)(sn=*leitner*)))
Objekte, deren Attribut „objectClass“ den Wert „posixAccount“ hat und entweder „uid“ den Wert
„leitner“ hat oder „sn“ den Wert „leitner“ enthält.
OpenLDAP
• Der Standard-LDAP-Server für Linux ist OpenLDAP. Dieser LDAP-Server wird schon seit fast 20 Jahren entwickelt, ist schnell, weit verbreitet und sehr stabil/gut getestet.
• OpenLDAP kann zum Speichern der Daten sehr viele verschiedene Backends verwenden (z.B.
Berkeley DB, LDIF, SQL, LMDB, LDAP, …). Standarmäßig wird derzeit Berkeley DB verwendet, in Zukunft LMDB.
• Die eingebaute Replikation erlaubt den Betrieb mehrer LDAP-Server mit den gleichen Daten, was die Verfügbarkeit erhöht.
• OpenLDAP hat noch weitere Funktionalitäten, z.B. können Anfragen an den Server über Module dynamisch geändert werden. Siehe OpenLDAP Administrationshandbuch.
OpenLDAP - Installation
• OpenLDAP kann unter Ubuntu mittels des Pakets slapd installiert werden. Bei der Installation wird die Eingabe des Administrator-Passworts für den LDAP-Server verlangt.
• Bei der Installation wird ein DIT mit der Domain des Rechners als Wurzel angelegt (z.B. dc=home) und ein Administratorkonto (z.B. cn=admin,dc=home). Dieser DIT kann dann über dieses Konto administriert werden.
• Standarmäßig läuft der Server nur auf Port 389, also ohne Verschlüsselung. Wenn man LDAPS verwenden will, muss man zuerst die nötigen Zertifikate erstellen und deren Pfad OpenLDAP mitteilen sowie in /etc/default/slapd bei SLAPD_SERVICES den Wert ldaps:/// hinzufügen.
• Die Konfigurationsdateien für den Server befinden sich in /etc/ldap/slapd.d im LDIF-Format.
Obwohl es so aussieht, als könnte man diese direkt dort ändern, sollte man das nicht tun! Es ist gedacht, die Konfiguration mittels LDAP-Anfragen durchzuführen!
Links: Ubuntu OpenLDAP Server Installation/Konfiguration, OpenLDAP Installation von Spinlock Solutions
OpenLDAP - Konfiguration
• Detailierte Informationen zur Konfiguration von OpenLDAP finden sich im Administrationshandbuch.
• Die Konfiguration des Servers wird in einem speziellen DIT mit der Wurzel cn=config durchgeführt.
Bei Änderungsanfragen über LDAP werden die Änderungen automatisch aktiv und zusätzlich nach /etc/ldap/slapd.d gesichert.
Wichtig: Konfigurationsänderungen müssen als Benutzer root und den CLI-Optionen -Y EXTERNAL -H ldapi:/// gemacht werden!
• Die Schema-Definitionen core, cosine, nis und inetorgperson sind standardmäßig aktiviert.
• Systemweite LDAP-Client-Einstellungen können in der Datei /etc/ldap/ldap.conf hinterlegt werden (z.B. Standardserver, Suchbasis, …).
OpenLDAP - Konfiguration 2
• Beispiel für das Anzeigen der Objekte im Konfigurations-DIT:
$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0
dn: cn=config
dn: cn=module{0},cn=config dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config dn: olcBackend={0}hdb,cn=config
dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}hdb,cn=config
OpenLDAP - Konfiguration 3
• Beispiel für das Ändern einer Konfigurationsoption:
$ echo "dn: cn=config
> changetype: modify
> replace: olcLogLevel
> olcLogLevel: 256" | ldapmodify -Y EXTERNAL -H ldapi:///
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0
modifying entry "cn=config"
$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(cn=config)' SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0
dn: cn=config
objectClass: olcGlobal cn: config
olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1
olcLogLevel: 256
OpenLDAP - Beispielszenario
• Der LDAP-Server ist nun in einer Grundkonfiguration fertig. Wenn man einen Produktivserver einrichtet, muss man natürlich noch Verschlüsselung (SSL/TLS) sowie Zugriffsbeschränkungen (ACLs) aktivieren.
• Jetzt kann das LDAP-Verzeichnis organisiert, i.e. hierarchisch gegliedert, und mit Objekten befüllt werden. Zum Beispiel könnte man Äste für Organisationseinheiten erstellen und darunter Objekte speichern, die Computer, Benutzer und Gruppen innerhalb dieser Organisationseinheiten beschreiben.
• Im Beispielszenario werden wir zwei Organisationseinheiten für Personen und Gruppen definieren und dann einen Beispielbenutzer und eine Beispielgruppe hinzufügen.
OpenLDAP - Beispielszenario 2
dn: ou=Benutzer,dc=home ou: Benutzer
objectClass: organizationalUnit dn: ou=Gruppen,dc=home
ou: Gruppen
objectClass: organizationalUnit
dn: cn=ict-infrastruktur,ou=Gruppen,dc=home cn: ict-infrastruktur
gidNumber: 20000 objectClass: top
objectClass: posixGroup
dn: cn=Nomen Nescio,ou=Benutzer,dc=home uid: nn
uidNumber: 20000 gidNumber: 20000 cn: Nomen Nescio sn: Nescio
gecos: Nomen Nescio
objectClass: person objectClass: posixAccount objectClass: shadowAccount loginShell: /bin/bash homeDirectory: /home/nn
OpenLDAP - Beispielszenario 3
• Die Einträge werden mit folgendem Befehl dem Verzeichnis hinzugefügt:
$ ldapadd -x -D cn=admin,dc=home -W -f /tmp/entries.ldif
Die Option -D gibt dabei den DN an, mit dem authentifiziert werden soll, -W fragt das Passwort ab und -x verlangt die einfache Authentifizierung.
• Jetzt muss noch das Passwort für den Benutzer gesetzt werden:
$ ldappasswd -D cn=admin,dc=home -x -W -S "cn=Nomen Nescio,ou=Benutzer,dc=home"
• Nun können die Einträge auch abgefragt werden:
$ ldapsearch -xLLL -b dc=home '(uid=nn)' dn: cn=Nomen Nescio,ou=Benutzer,dc=home uid: nn
uidNumber: 20000 gidNumber: 20000 cn: Nomen Nescio sn: Nescio
gecos: Nomen Nescio objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount loginShell: /bin/bash homeDirectory: /home/nn
OpenLDAP - Systemeinbindung
• Nachdem wir nun im LDAP-Verzeichnis Benutzer und Gruppen definieren können, werden wir das System so anpassen, dass diese auch am System aufscheinen (NSS) und Benutzer sich authentifizieren können (PAM).
• Dazu werden die Pakete libnss-ldap und libpam-ldap benötigt. Bei der Installation werden einige Daten abgefragt (Werte für das Beispielszenario sind angegeben):
• „LDAP server Uniform Resource Identifier“ → `ldap://localhost/
• „Distinguished name of the search base“ → dc=home
• „LDAP version to use“ → 3
• „Make local root Database admin“ → Nein
• „Does the LDAP database require login?“ → Nein
• Nach der Installation ist PAM schon fertig eingerichtet, für NSS muss noch in der Datei /etc/nsswitch.conf LDAP aktiviert werden, was mit auth-client-config -t nss -p ldap_example erledigt werden kann.
OpenLDAP - Systemeinbindung 2
• Zum Testen der LDAP-Anbindung können folgende Befehl ausgeführt werden:
$ getent group ict-infrastruktur ict-infrastruktur:*:20000:
$ getent passwd nn
nn:x:20000:20000:Nomen Nescio:/home/nn:/bin/bash
$ getent shadow nn nn:*:::::::
Anschließend muss man noch testen, ob sich der Benutzer mit seinem LDAP-Passwort auch wirklich einloggen kann.
OpenLDAP und Kerberos, Sudoers, Autofs
• Möchte man zur Authentifizierung Kerberos anstatt LDAP verwenden, so kann man einfach das entsprechende PAM-Modul dafür verwenden. Allerdings muss man dann weiterhin zwei getrennte Datenbanken (LDAP und Kerberos) vorhalten bzw. synchronisieren.
• Die bessere Methode ist für Kerberos als Datenbankbackend LDAP zu verwenden. Dann kann man die Schlüssel für Benutzer, Computer und Services im LDAP-Verzeichnis direkt bei den entsprechenden LDAP-Objekten speichern. Eine Anleitung für die Einrichtung findet sich im Ubuntu Kerberos and LDAP Guide und im Kerberos Admin Guide von MIT Kerberos.
• Weiters ist es möglich, sowohl die sudo-Konfiguration als auch die autofs-Konfiguration in das LDAP- Verzeichnis zu verlagern. Dazu müssen die entsprechenden Schema-Dateien in den LDAP-Server geladen und dann die nötigen Objekte angelegt werden.
Copyright und Lizenz
• Copyright: Thomas Leitner thomas.leitner@univie.ac.at
• Lizenz: Creative Commons CC BY-NC-SA
„Namensnennung-Keine kommerzielle Nutzung-Weitergabe unter gleichen Bedingungen 3.0 Österreich.“ - http://creativecommons.org/licenses/by-nc-sa/3.0/at/
Abweichendes Copyright von Inhalten:
• Die Grafik „Kerberos Protokoll“ steht unter der CC BY-SA 3.0 Lizenz.
