Un serveur http kerbérisé, c'est bien pour la démo, mais dans ce cas, kerberos ne prend en charge que l'authentification, tout le reste du dialogue http sera en clair. Dans la pratique, https sera sans doute plus indiqué pour un site sensible. Il suffit juste de transformer son serveur http en https, ce n'est pas très compliqué et ce n'est pas l'objet de ce chapitre.

Mais on peut utiliser kerberos pour d'autres applications. Il peut être aussi intéressant de centraliser les comptes d'utilisateurs et d'utiliser pam avec le module libpam-krb5, évitant ainsi à l'utilisateur de manipuler la commande kinit.

Cette autre usine qu'est PAM permet d'employer un module spécifique à kerberos. Sur Debian (et donc Ubuntu), l'installation du paquet libpam-krb5. La simple installation de ce paquet va modifier la configuration de PAM pour prendre en charge l'authentification kerberos.

Pour les spécialistes de PAM (ce que j'aimerais bien arriver à devenir un jour), voici, pour une Ubuntu « karmic », les modifications apportées, dans common-auth :

auth	[success=2 default=ignore]	pam_krb5.so  minimum_uid=1000
auth	[success=1 default=ignore]	pam_unix.so nullok_secure try_first_pass
auth	requisite			pam_deny.so
auth	required			pam_permit.so

password	requisite			pam_krb5.so minimum_uid=1000
password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass sha512
password	requisite			pam_deny.so
password	required			pam_permit.so
password	optional	pam_gnome_keyring.so 

session	[default=1]			pam_permit.so
session	requisite			pam_deny.so
session	required			pam_permit.so
session	optional			pam_krb5.so minimum_uid=1000
session	required	pam_unix.so 
session	optional			pam_ck_connector.so nox11

session	[default=1]			pam_permit.so
session	requisite			pam_deny.so
session	required			pam_permit.so
session	optional			pam_krb5.so minimum_uid=1000
session	required	pam_unix.so 

account	[success=1 new_authtok_reqd=done default=ignore]	pam_unix.so 
account	requisite			pam_deny.so
account	required			pam_permit.so
account	required			pam_krb5.so minimum_uid=1000

• l'utilisateur doit disposer d'un compte local. S'il ne dispose que d'un principal kerberos, il ne pourra pas ouvrir de session sur la station de travail. Kerberos ne réalise que l'authentification, les autres informations nécessaires nécessiteraient par exemple LDAP en appui ;
• un utilisateur change son mot de passe avec passwd :
  • le mot de passe kerberos sera également changé, mais si l'utilisateur a choisi un mot de passe trivial, la sécurité par défaut de la karmic va faire échouer le changement du pass local ;
  • l'utilisateur va se retrouver avec deux pass pour ouvrir une session :
    • l'ancien ouvrira une session avec pam_unix ;
    • le nouveau le fera avec pam_krb5 ;
  • dans tous les cas, si l'utilisateur dispose de comptes sur d'autres stations de travail, les mots de passe locaux resteront bien entendu ce qu'ils étaient et l'utilisateur se retrouvera dans le cas précédent, sur ces autres stations ;
  • si les pass sont désynchronisés, l'utilisateur ne sait pas par quel moyen il a ouvert une session.
• un utilisateur change son pass avec kpasswd :
  • seul le mot de passe kerberos est changé, bien entendu, pass kerberos et pass local ne sont plus synchronisés.

Vérifions tout de même, dans le cas où c'est kerberos qui a authentifié l'utilisateur. Ce dernier a juste ouvert une session avec l'écran de login de gdm, sans utiliser par la suite la commande kinit. La commande klist donne :

chris@karmicvirt:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: chris@MAISON.MRS

Valid starting     Expires            Service principal
02/19/10 18:32:35  02/20/10 04:32:35  krbtgt/MAISON.MRS@MAISON.MRS
	renew until 02/20/10 18:32:32

Le TGT a bien été obtenu de façon transparente.

Juste pour le fun, voici un moyen d'ouvrir une session ssh en utilisant kerberos au travers de GSSAPI. Soit un utilisateur disposant de :

• la possibilité d'ouvrir une session ssh sur l'hôte distant ;
• un principal (kerberos) qui l'authentifie dans le royaume kerberos.

A la condition que l'hôte distant fasse partie du royaume et soit lui-même authentifié (clé partagée entre le KDC et l'hôte distant), alors cet utilisateur va pouvoir utiliser le SSO pour ouvrir sa session ssh sur l'hôte distant, sans saisie de mot de passe, et sans échange de clé publique.

Une démonstration rapide ?

Soit un serveur distant, qui va bientôt nous servir pour la cerise sur le gâteau. Il s'appèle squid3.eme.org, son nom prendra tout son sens plus tard. Cet hôte est mu par une Debian Squeeze, il est intégré à un domaine Microsoft (Windows 2008, Samba est notre alliée pour cette manœuvre), et dispose de :

• un serveur OpenSSH configuré pour accepter les authentifications GSSAPI ;
• une clé host/squid3.eme.org@EME.ORG partagée avec le KDC de Windows 2008.

Soit un utilisateur root qui dispose :

• d'un compte local sur squid3.eme.org ;
• d'un compte dans le domaine AD eme.org (pas forcément avec le même mot de passe d'ailleurs, ni même avec les mêmes privilèges d'administration) ;

Soit une station de travail (Ubuntu Karmic Koala nommée karmicvirt), disposant des outils kerberos krb5-user. Notre cobaye (chris) a ouvert une session sur ce poste de travail et souhaite accéder à proxy3.eme.org :

chris@karmicvirt:~$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000_f9ItDE)

Aucun principal ni aucun ticket ne sont présents dans le cache.

chris@karmikvirt:~$ ssh -v root@proxy3.eme.org
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to proxy3.eme.org [192.168.0.137] port 22.
debug1: Connection established.
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000_f9ItDE' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000_f9ItDE' not found

debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Next authentication method: publickey
debug1: Trying private key: /home/chris/.ssh/identity
debug1: Trying private key: /home/chris/.ssh/id_rsa
debug1: Trying private key: /home/chris/.ssh/id_dsa
debug1: Next authentication method: password
root@proxy3.eme.org's password: 

chris@karmikvirt:~$ kinit -V root@EME.ORG
Password for root@EME.ORG: 
Authenticated to Kerberos v5
chris@jauntyvirt:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_f9ItDE
Default principal: root@EME.ORG

Valid starting     Expires            Service principal
03/01/10 22:27:43  03/02/10 05:07:43  krbtgt/EME.ORG@EME.ORG

Maintenant, chris dispose d'un principal pour root

chris@karmicvirt:~$ ssh -v root@proxy3.eme.org
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to proxy3.eme.org [192.168.0.137] port 22.
debug1: Connection established.
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Authentication succeeded (gssapi-with-mic).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
Linux proxy3 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Mar  1 16:15:32 2010 from 192.168.0.68
proxy3:~# 

chris@karmicvirt:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_f9ItDE
Default principal: root@EME.ORG

Valid starting     Expires            Service principal
03/01/10 22:27:43  03/02/10 05:07:43  krbtgt/EME.ORG@EME.ORG
03/01/10 22:29:49  03/02/10 05:07:43  host/proxy3.eme.org@
03/01/10 22:29:49  03/02/10 05:07:43  host/proxy3.eme.org@EME.ORG

Sur le poste client, chris dispose maintenant des tickets nécessaires pour s'authentifier en tant que root sur le service host/proxy3.eme.org@EME.ORG

Le proxy Squid peut utiliser l'authentification kerberos. Squid est traité au chapitre Squid et SquidGuard, nous ne reviendrons pas sur les détails. Dans ce chapitre, nous avons utilisé NTLM pour permettre d'authentifier les utilisateurs à travers Active Directory. NTLM, c'est pas top. En plus, cette chose nécessite deux « access denied » avant de réagir. Consommation de bande passante et encombrement des logs inutiles.

Squid3, fourni avec Debian Squeeze, propose un « helper » : squid_kerb_auth pour kerberos qui se manipule un peu de la même manière que ntlm_auth pour NTLM.

Avantages :

• pas besoin d'utiliser samba, kerberos ne fait pas partie de CIFS ;
• l'authentification est immédiate, économie de bande passante et de volume de logs ;
• meilleure lisibilité des logs de Squid, par le fait.

Inconvénient(s) :

• si l'utilisateur ne dispose pas d'un TGT, le navigateur ne lui proposera pas une fenêtre de connexion ;
• la dernière version de la libkrb5-3, fournie dans Squeeze, semble incompatible avec le kerberos de Windows, même 2008 (vérifier pour 2008 r2).

Fonctionne parfaitement en revanche avec le KDC du MIT.

Voici rapidement comment faire.

D'abord, il faut réaliser un principal HTTP/<fqdn>@REALM comme on l'a fait pour apache, puis exporter la clé dans un fichier qui ne sera lisible que par proxy (nous sommes sur une Debian), également de la manière dont nous l'avons fait pour apache. Nous obtenons par exemple ceci :

/etc/squid3# ls -l
...
-r-------- 1 proxy proxy    322 févr. 18 12:28 krb5-proxy.keytab
...

Voici un squid.conf de base :

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d
auth_param negotiate children 10
auth_param negotiate keep_alive on
acl auth proxy_auth REQUIRED

acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl localnet src 192.168.0.0/24
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow localnet auth
http_access deny all
icp_access deny all
htcp_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern (cgi-bin|\?)	0	0%	0
refresh_pattern .		0	20%	4320
icp_port 3130
coredump_dir /var/spool/squid3

Squid doit être démarré avec à disposition une variable d'environnement indiquant le chemin d'accès à ce fichier de clés. Débian étant une distribution sérieuse, c'est assez facile à faire en créant un fichier /etc/default/squid3 contenant ceci :

KRB5_KTNAME=/etc/squid3/krb5-proxy.keytab
export KRB5_KTNAME

Ce fichier, s'il existe, est intégré à /etc/init.d/squid3. Il suffit alors de relancer squid.

Bien d'autres applications peuvent utiliser kerberos, grâce à GSSAPI. Postfix, Dovecot, samba etc. La fonction SSO étant probablement la plus intéressante, et Microsoft ne s'y est pas trompé, en intégrant kerberos à son système Active Directory. Ce que l'on peut regretter, c'est la façon opaque dont ça a été fait, mais c'est une marque de fabrique. Encore qu'un effort évident de documentation a été mené et que l'interopérabilité entre MS Windows et les systèmes libres Unix a quelques chances de progresser grâce à kerberos (et LDAP, mais ceci est une autre histoire).