Compléments

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.

Pam et kerberos

Cette autre usine qu'est PAM permet d'employer un module spécifique à kerberos. Sur Debian (et donc Ubuntu), la simple installation du paquet libpam-krb5 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

Dans common-password :

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

Dans common-session :

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

Dans common-session-noninterarctive :

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

Et dans common-account :

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

Il est nécessaire que l'utilisateur puisse ouvrir une session en s'appuyant sur un mot de passe local, faute de quoi, une indisponibilité du KDC lui empêcherait tout accès à son compte.

Cette configuration présente certaines imperfections qui peuvent amener des comportements désagréables !

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. Notons que ça ne fonctionne pas avec la connexion automatique à un compte par défaut. Comme cette pratique n'est pas recommandable dans un environnement « peu sûr » (c'est-à-dire dans tous les cas), nous ne pousserons pas plus avant les investigations.

Proxy Squid

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 ni winbind, 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 :

si l'utilisateur ne dispose pas d'un TGT, le navigateur ne lui proposera pas une fenêtre de connexion son accès sera interdit tout simplement.

Voici rapidement comment faire.

Le KDC

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
...

squid.conf

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

Environnement de Squid

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.

Et encore...

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).

Les chapitres

Table des matières