Single-Sign-On mit Kerberos V

Transkript

1 Single-Sign-On mit Kerberos V Jörg Rödel <[email protected]> 21. Oktober 2005 Jörg Rödel

2 Was ist Single-Sign-On? oft nur verstanden als ein Nutzer/Passwort-Paar für alle Dienste eines Netzwerkes so wird es dann auch häufig implementiert, z.b. mit LDAP als Backend bei echtem Single-Sign-On meldet man sich allerdings nur einmal am Netzwerk an und ist damit gegenüber allen Diensten authentifiziert Implementierungen des Kerberos 5 Protokolles (RFC 4120) stellen einen solchen Dienst im Netzwerk zur Verfügung Jörg Rödel 1

3 Was ist Kerberos? ein dreiköpfiger Hund aus der griechischen Mythologie, welcher den Eingang zum Hades bewacht heute ein hauptsächlich am MIT entwickelter Authentifizierungsstandard erste öffentliche Version war Kerberos 4, Versionen 1 bis 3 waren nur experimentell aktuell ist die Version 5, zuerst standardisiert in RFC 1510, aktualisiert in RFC 4120 arbeitet nach dem Trusted-Third-Party-Prinzip und symetrischer Verschlüsselung Jörg Rödel 2

4 Wie funktioniert Kerberos - Begriffe eine Authentifizierungszone wird als Realm bezeichnet; alle Nutzer und angebotenen Dienste sind Teil dieses Realms ein Principal ist entweder ein Nutzer oder ein Dienst; jeder Principal hat einen eideutigen Namen und eine Reihe geheimer Schlüssel ein Ticket ist ein verschlüsseltes Datenpaket, mit dem sich ein Principal gegenüber einem Dienst ausweisen kann als KDC (Key Distribution Center) wird der eigentliche Kerberos-Server bezeichnet Jörg Rödel 3

5 Wie funktioniert Kerberos - Authentifizierung 1 um einen Dienst mit Kerberos zu nutzen, benötigt man ein Ticket Granting Ticket (TGT) das TGT bekommt man vom Authentication Service (AS) das TGT wird von einem Principal angefordert und ist mit dessen Schlüssel kodiert der Nutzer auf der Clientseite berechnet den Schlüssel zum dekodieren aus einem Passwort oder der Schlüssel ist direkt auf der Festplatte hinterlegt Jörg Rödel 4

6 Wie funktioniert Kerberos - Authentifizierung 2 will ein Nutzer einen Dienst (z.b. HTTP) nutzen, so fordert er vom Ticket Granting Service (TGS, Teil des KDC) ein Ticket für genau diesen Dienst an die Authentifikation erfolgt dabei mit dem TGT dieses Ticket ist kodiert mit dem Schlüssel des Dienst-Prinicipals und enthält unter anderem die Identität des Clients der Client schickt dieses Ticket an den Dienst, den er nutzen möchte der Dienst entschlüsselt das Ticket und verfiziert die Indentität des Clients Jörg Rödel 5

7 Wie funktioniert Kerberos - Das Bild Bei der Anmeldung holt sich der Nutzer ein Ticket Granting Ticket vom Authentication Server 1. Kerberos Server 2. Mit dem Ticket Granting Ticket holt der Nutzer beim TGS ein Ticket fuer den Service Client Der Nutzer schickt dieses Service Ticket an den Server und ist damit authentifiziert 3. Webserver LDAP Server usw. Jörg Rödel 6

8 Implementierungen MIT-Kerberos ist die Referenzimplementierung und wird auch häufig genutzt Heimdal-Kerberos ist eine weitere Implementierung aus Europa Microsoft Kerberos ist fester Bestandteil seit Windows 2000 Ich werde an dieser Stelle nur auf Heimdal-Kerberos eingehen. Die MIT-Version ist in der Konfiguration ähnlich, allerdings hat Heimdal einige Vorteile. Heimdal ist einfacher zu benutzen, unterstützt inkrementelle Updates bei mehreren Servern und hat auch eine bessere Client-Implementierung. Doch dazu mehr beim Thema Webserver. Jörg Rödel 7

9 Dienstprogramme von Heimdal-Kerberos kinit: wird verwendet, um sich ein TGT vom AS zu besorgen klist: zeigt alle vorhandenen Tickets an kdestroy: löscht alle vorhandenen Tickets kpasswd: ermöglicht einem Principal sein Passwort und damit seinen Key zu ändern kadmin: Administrationsshell für Heimdal-Kerberos; setzt ein Admin-Ticket voraus und ist Scripting-fähig Jörg Rödel 8

10 Installation von Heimdal-Kerberos (1/6) Als Beispiel soll hier ein Kerberos-Server mit dem Realm ZLUG.ORG installiert werden. Nach der Installation der Binaries ist zunächst die Datei /etc/krb5.conf zu bearbeiten. Es sollte mindestens folgendes enthalten sein: [libdefaults] default realm = ZLUG.ORG [realms] ZLUG.ORG = { kdc = kdc1.zlug.org:88 } [domain realm].zlug.org = ZLUG.ORG Jörg Rödel 9

11 Installation von Heimdal Kerberos (2/6) Im nächsten Schritt ist der Master-Key der Kerberos-Datenbank zu erstellen. Mit diesem Key wird die komplette Datenbank verschlüsselt. Daher ist er entsprechend wichtig und sollte nicht verloren gehen. # kstash Master key: Verifying - Master key: kstash: writing key to /var/lib/heimdal-kdc/m-key # Von der Datei /var/lib/heimdal-kdc/m-key sowie der heimdal.db im gleichen Verzeichniss sollten unbedingt regelmäßig Backups angelegt werden. Jörg Rödel 10

12 Installation von Heimdal Kerberos (3/6) Jetzt kann die Datenbank mit den Principals initialisiert werden. Das erfolgt mit dem Programm kadmin. Die Option -l gibt dabei an, dass kadmin direkt auf der Datenbank arbeitet und nicht über einen Admin-Server. # kadmin -l kadmin> init ZLUG.ORG Realm max ticket life [unlimited]: Realm max renewable ticket life [unlimited]: kadmin> Damit wurde der Realm ZLUG.ORG initialisiert und die ersten Principals angelegt, welche für den Betrieb von Kerberos erforderlich sind. Diese sind auf der nächsten Folie zu sehen. Jörg Rödel 11

13 Installation von Heimdal Kerberos (4/6) Die Principals kadmin/* werden von dem kadmin-dienst verwendet. Darüber lässt sich die Principal-Datenbank administrieren. Am wichtigsten ist der krbtgt/zlug.org-principal. Dieser gehört zum TGS-Dienst. kadmin> list * [email protected] kadmin/[email protected] kadmin/[email protected] kadmin/[email protected] krbtgt/[email protected] changepw/[email protected] kadmin> Damit ist der Kerberos-Server einsatzbereit, wenn auch noch nicht fertig. Jörg Rödel 12

14 Installation von Heimdal Kerberos (5/6) Als nächstes ist es empfehlenswert, einen Admin-Principal für kadmin anzulegen. kadmin> add admin/admin Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes []: s Password: Verifying - admin/[email protected] s Password: kadmin> Jörg Rödel 13

15 Installation von Heimdal Kerberos (6/6) Nun muss man diesem Principal noch die entsprechenden Rechte geben. Dies wird in der Datei kadmin.acl konfiguriert. Diese sollte folgenden Inhalt haben: #principal [priv1,priv2,...] [glob-pattern] admin/admin all Der kadmin-dienst selbst wird über den inetd gestartet. In /etc/inetd.conf sollte deshalb folgende Zeile enthalten sein: kerberos-adm stream tcp nowait root /usr/sbin/tcpd /usr/lib/heimdal-servers/kadmind Damit ist auch der kadmin-dienst einsatzbereit. kadmin kann nun ohne die -l Option verwendet werden, ein TGT für admin/admin vorausgesetzt. Jörg Rödel 14

16 PAM-Konfiguration Damit die Nutzer direkt beim anmelden ihr TGT erhalten, kann man das PAM- Modul pam krb5.so verwenden: account sufficient pam unix.so account sufficient pam krb5.so auth sufficient pam unix.so debug nullok nodelay auth sufficient pam krb5.so debug use first pass auth required pam deny.so password required pam unix.so nullok obscure min=4 max=8 md5 session required pam unix.so session optional pam krb5.so Jörg Rödel 15

17 Anbindung an den Apache-Webserver Nun soll der erste Dienst angebunden werden, der Webserver Apache. Dazu muss zunächst ein Service-Principal erstellt und in eine Keytab-Datei exportiert werden: kadmin> add -r HTTP/triton Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes []: kadmin> ext -k /etc/apache2/apache.keytab HTTP/triton kadmin> Die Option -r gibt an, dass ein zufälliger Schlüssel generiert werden soll. Deshalb erfolgt keine Passworteingabe. Jörg Rödel 16

18 Anbindung an den Apache-Webserver Für den Webserver muss nun das Modul mod auth kerb bereit gestellt werden. Der Debian-Distribution liegt es bereits bei. Geschützt wird ein Verzeichniss dann wie folgt: <Location /geheim> AuthType Kerberos AuthName "Kerberos 5" Krb5Keytab /etc/apache2/apache.keytab KrbAuthRealms ZLUG.ORG KrbMethodK5Passwd on KrbMethodNegotiate on require valid-user </Location> Jörg Rödel 17

19 SASL-Konfiguration Applikationen die den Simple Authentication and Security Layer (SASL) unterstützen sind von Haus aus Kerberos fähig. Als Voraussetzung hierfür muss der SASL-spezifische Dienst saslauthd gestartet werden. Weiterhin muss das entsprechende SASL-Modul für GSSAPI-Authentifikation installiert sein. Dann kann man den saslauthd wie folgt starten: # /usr/sbin/saslauthd -a kerberos5 Der Parameter gibt an, dass als Authentifizierungsbackend Kerberos 5 zum Einsatz kommen soll. Damit ist die Vorbereitung für Dienste wie z.b. OpenLDAP oder den Cyrus-IMAP-Server fertig. Jörg Rödel 18

20 OpenLDAP-Konfiguration Der OpenLDAP-Server benötigt, wie jeder andere Dienst auch, einen eigenen Principal. Dessen Key muss in die Datei /etc/krb5.keytab exportiert werden: kadmin> add -r ldap/triton Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes []: kadmin> ext -k /etc/krb5.keytab ldap/triton kadmin> Jörg Rödel 19

21 OpenLDAP-Konfiguration Im nächsten Schritt sind noch Einstellungen in der slapd.conf vorzunehmen. Folgende Zeilen sollten enthalten sein: sasl-realm sasl-host ZLUG.ORG triton sasl-regexp "uid=(.*)/admin,cn=zlug.org,cn=gssapi,cn=auth" "uid=$1,ou=ldap,ou=techadmin,dc=zlug,dc=org" sasl-regexp "uid=([^/]*),cn=zlug.org,cn=gssapi,cn=auth" "uid=$1,ou=people,dc=zlug,dc=org" Nach einem Neustart des slapd sollte die Kerberos-Authentifizierung funktionieren. Jörg Rödel 20

22 Weitere Kerberos-fähige Dienste der Cyrus-IMAP-Server ist Kerberos fähig. Mit einem entsprechenden Client (z.b. Mozilla Thunderbird) kann man diesen auch für Single-Sign-On verwenden das AFS-Filesystem basiert auf Kerberos (eigentlich auf Kerberos 4, aber Version 5 lässt sich ebenfalls verwenden eine bedauernswerte Ausnahme bildet der CUPS-Daemon. Dieser ist leider nicht Kerberos-fähig Jörg Rödel 21

23 Vielen Dank für ihre Aufmerksamkeit Fragen? Die Vortragsfolien sind in Kürze unter der URL zu finden. Jörg Rödel 22