Kerberos auf den Clients konfigurieren

Ausgangslage: Virtuelle Ubuntu Kombination

Auf dem Client wird zusätzlichen zu den bereits besprochenen und installierten PAM-Modulen das kerberos Paket krb5-user eingespielt:

sudo apt-get install krb5-user

Das Modul verwendet als Konfigurationsdatei eine Kopie der /etc/krb5.conf des Servers. Also zuerst die Datei vom Server auf den Client kopieren

[root@itoko /usr/home/ijin/]# scp /etc/krb5.conf ijin@haruka:/home/ijin
[root@itoko /usr/home/ijin/]# ssh -l ijin haruka
[ijin@haruka /home/ijin/]# sudo mv /home/ijin/krb5.conf /etc
[ijin@haruka /home/ijin]#sudo chown root:root /etc/krb5.conf

Jetzt versuchen wir uns mal als User ijin unser Ticket beim Server (Itoko) abzuholen.

ijin@haruka:/etc$ kinit ijin
Password for ijin@CALMAR.NET:
ijin@haruka:/etc$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ijin@CALMAR.NET

Valid starting     Expires            Service principal
04/05/11 11:25:54  04/06/11 11:25:50  krbtgt/CALMAR.NET@CALMAR.NET
ijin@haruka:/etc$

Will man jetzt z.B von Haruka aus den LDAP Dienst befragen so sollte das so funktionieren:

ijin@haruka:/home$ ldapsearch -h itoko -Y gssapi  -U jhubar

und ich bekomme

ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
        additional info: SASL(-4): no mechanism available: No worthy mechs found

Er kennt die Authentifizierungsmethode nicht: Anscheinend fehlt auf dem Client die libsasl2-gssapi Bibliothek Wird sofort nachinstalliert (hier für heimdal)

ijin@haruka:/home$ sudo apt-get install libsasl2-modules-gssapi-heimdal

Und jetzt bekomme ich die Ausgabe:

ijin@haruka:/home$ ldapsearch -h itoko -Y gssapi  -U jhubar
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
        additional info: SASL(-1): generic failure: GSSAPI Error:  No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown)

Der Fehler liegt serverseitig. Der slapd kann nicht auf den in der /etc/krb5.keytab gespeicherten Schlüssel für ldap/itoko,calmar.net zugreifen. Ich ändere die Zugriffsrechte:

[root@itoko /usr/home/ijin]# chmod 640 /etc/krb5.keytab
[root@itoko /usr/home/ijin]# chgrp ldap  /etc/krb5.keytab

Jetzt ist er lesbar. Wenn ich die obige Abfrage nun wiederhole bekomme ich:

ijin@haruka:/home$ ldapsearch -h itoko -b uid=schoener,ou=people,dc=calmar,dc=net -Y gssapi  -U jhubar
SASL/GSSAPI authentication started
SASL username: jhubar@CALMAR.NET
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <uid=schoener,ou=people,dc=calmar,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# schoener, people, calmar.net
dn: uid=schoener,ou=people,dc=calmar,dc=net
objectClass: account
objectClass: posixAccount
cn: schoener
uid: schoener
uidNumber: 10003
gidNumber: 10000
homeDirectory: /home/schoener
loginShell: /bin/bash
gecos: schoener
description: User account
userPassword:: ZmlyZWZveA==

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1

Jetzt müssen noch die Clients mittels PAM konfiguriert werden. Hier ein Vorschlag: http://www.ncsa.illinois.edu/UserInfo/Resources/Software/kerberos/krb5_pam_config.html

Dazu müssen auf den Clients erst mal noch zusätzliche Module installiert werden.

sudo apt-get install libpam-krb5

Jetzt noch ein ein

sudo pam-auth-update

Hier gibt man nun

Kerberos Authentification
Unix Authetifikation

an. Da ich die LDAP Authetification damit abgeschaltet habe sollte beim nächsten Login - Kerberos aktiviert sein.

Dienste (auf dem Server) konfigurieren

Hier gibt es eigentlich nichts zu tun. OpenLDAP versucht automatisch sobald eine Abfrage nach der GSSAPI-Methode (Kerberos V) erfolgt, den Schlüssel aus der /etc/krb5.keytab zu lesen und sich beim Server zu authentifizieren.

Wichtig ist der Name des Prinzipals ist immer Dienst/Server also hier ldap/itoko.calmar.net.Wahrscheinlich wird auf eine lokale Kopie des /etc/krb5.conf benötigt.

Test

Klappt alles dann loggen wir uns auf Haruka mit einem der User an. Im Erfolgsfalle erscheint ein graphischer Desktop.

Nun Prüfen wir ob die Kerberos Aktivierung geklappt hat :

Wir öfnnen ein Terminal lassen unser Ticket ausgeben.

jhubar@haruka:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1001_tfCmwq
Default principal: jhubar@CALMAR.NET

Valid starting     Expires            Service principal
04/05/11 16:57:02  04/06/11 16:57:02  krbtgt/CALMAR.NET@CALMAR.NET
jhubar@haruka:~$

Sehen wir kein Ticket, dann haben wir uns nicht über Kerberos sonder über das alternative "Unix Authetifikation" Modul angemeldet.

Und jetzt noch die Kontrolle on der LDAP funktioniert.

jhubar@haruka:~$ getent passwd 
.......
fritz:*:10001:10000:Fritz  Müller:/home/fritz:/bin/bash
jhubar:*:10002:10000:jhubar:/home/jhubar:/bin/bash
schoener:*:10003:10000:schoener:/home/schoener:/bin/bash
jhubar@haruka:~$ 

(V 1.04)