====== 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 [[:220squid:start]], 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/@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).