Tag Archive for 'gssapi'

Client Windows XP, KFW, KDC Unix et Mozilla

Un petit post pour mémoire sur le fonctionnement d’un client Windows XP avec KFW (Kerberos For Windows) et les outils Mozilla. Mon but est de proposer une authentification Kerberos aux utilisateurs itinérants : non raccordés à un domaine, compte local à la machine et authentification (au moment du login) non liée au KDC. KFW est un utilitaire distribué par le MIT qui permet d’intégrer une couche GSSAPI “traditionnelle” dans Windows. En effet, Windows utilise une variante fermée de la GSSAPI qui se nomme SSPI (Security Support Provider Interface). L’installation de KFW n’est pas compliquée (suivant, suivant et terminer). Une fois installée, on doit configurer le fichier krb5.ini (qui ressemble comme deux goutes d’eau au krb5.conf). Voici un exemple minimal :

[libdefaults]
	default_realm = MONDOMAINE.FR
 
[realms]
        MONDOMAINE.FR = {
                kdc = kdc.mondomaine.fr
        }
 
[domain_realm]
	.monrealm.fr = MONDOMAINE.FR
	mondomaine.fr = MONDOMAINE.FR

Ensuite, il suffit de cliquer pour obtenir les credentials (TGT). Ensuite, pour les applications Mozilla il faut faire un petit réglage. En effet, Firefox et Thunderbird utilisent par défaut la SSPI. On peut forcer l’utilisation de la GSSAPI en désactivant le SSPI. Pour ce faire, dans “Outils”, “Options” et “Editeur de configuration” placez le network.auth.use-sspi à false.

Postfix et Kerberos howto

Après moult jours de tripatouillage, je suis parvenu à faire fonctionner l’authentification Kerberos avec Postfix. En effet, on trouve dans les howtos un nombre impressionnant de façon d’y arriver (avec comme toujours certaines configurations dont on peut se demander comment elles fonctionnent). Installons d’abord les paquets :

$ apt-get install postfix
$ apt-get install libsasl2-modules-gssapi-mit

Le daemon saslauthd est inutile. Passons maintenant à l’enregistrement du service SMTP dans le KDC en créeant un ticket pour le service (smtp/fqdn).

$ kadmin.local
kadmin: addprinc -randkey smtp/mailtest.mondomaine
kadmin: ktadd -k /etc/smtp.keytab smtp/mailtest.mondomaine

Il faut ensuite recopier le /etc/smtp.keytab depuis le KDC vers le serveur de mail (mailtest). Sur mailtest ce fichier doit être installé dans le chroot de Postfix car par défaut le processus smtpd acceptant les connexions authentifiées pour l’envoi de messages est chrooté dans /var/spool/postfix. Tant que l’on est à parler du chroot, il faut aussi recopier le répertoire temporaire /var/tmp dans /var/spool/postfix/var car il est utilisé par le processus krb5.login. Il nous faut aussi le /etc/krb5.conf dans /var/spool/postfix/etc. Dernière note sur le chroot, on peut aller voir dans le script de démarrage (/etc/init.d/postfix) les fichiers copiés automatiquement dans le chroot au démarrage du service.

Une fois le chroot configuré, passons au master.cf pour activer un smtpd en SSL sur le port 465 :

smtps inet n - - - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

Occupons nous aussi du main.cf :

import_environment = KRB5_KTNAME=/etc/smtp.keytab
 
[...]
 
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
 
smtpd_recipient_restrictions = permit_sasl_authenticated,
                                permit_mynetworks,
                                reject_unauth_destination

Le import_environment est super important car il permet de positionner l’emplacement d fichier keytab utilisé par le service smtp kerberisé. On redémarre un coup Postfix et on test les méthodes d’authentification présentées aux clients avec la classqiue commande “ehlo” :

$ openssl s_client -connect mailtest.univ-orleans.fr:465

Nous renvoie la sortie suivante :

220 mailtest.mondomaine ESMTP Postfix (Debian/GNU)
ehlo mailtest.mondomaine
250-mailtest.mondomaine
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 NTLM CRAM-MD5 PLAIN LOGIN
250-AUTH=GSSAPI DIGEST-MD5 NTLM CRAM-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

La GSSAPI est bien notre mécanisme d’authentification par défaut. Testons maintenant avec un Thunderbird. Pour le configurer, allez dans les propriétés du compte puis “serveur sortant smtp”. Ajoutez en un avec comme nom de serveur mailtest.mondomaine, port 465, selectionnez “Utiliser un nom d’utilisateur et un mot de passe” et enfin choisissez “Utiliser un connexion sécurisée SSL”. Vous devriez maintenant pouvoir envoyer tous vos messages authentifié via Kerberos. Sus au spam interne !

Le debugging est assez complexe, surtout avec le chroot de Postfix. Pour vous aider, vous pouvez utiliser à mort strace en l’attachant au processus “master” de Postfix en suivant tout les types de fork (option -fF) et en sélectionnant certains appels systèmes (-e).

Validation de la couche SASL

Une petite procédure pour valider le fonctionnement de la SASL (Simple Athentication and Security layer) avec le mécanisme d’authentification GSSAPI (Kerberos). Nous supposons qu’un KDC est disponible (et surtout fonctionne). Si ce n’est pas le cas, un bon howto est fourni par le projet Ubuntu. Tout d’abord, installons ce qu’il faut :

apt-get install sasl2-bin
apt-get install libsasl2-2
apt-get install libsasl2-modules-gssapi-mit

Cyrus-SASL dispose d’outils pour valider le bon fonctionnement de la SASL sur votre machine. Ce sont les outils sasl-sample-[client|server]. C’est la première étape à réussir pour utiliser la SASL avec des application externes. Pour le test, on doit disposer de deux terminaux sur la machine (un pour le client, un autre pour le serveur) sur lesquelles nous sommes authentifiés. Les manipulations sont a effectuer sur les deux terminaux. Commençons par la liste des tickets en cours de validité :

klist

Nous renvoie :

klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
 
Kerberos 4 ticket cache: /tmp/tkt0

Demandons un ticket pour l’utilisateur toto :

kinit toto

Password for toto@REALM.FR:

Listons les tickets :

klist

Devrais renvoyer :

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: toto@REALM.FR
 
Valid starting     Expires            Service principal
09/10/09 11:16:57  09/10/09 21:16:57  krbtgt/REALM.FR@REALM.FR
        renew until 09/11/09 11:13:49
 
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Nous avons nos tickets, on peut tester la couche SASL. Sur le terminal dédié au serveur, nous allons utiliser le programme sasl-sample-server :

[root@term1]# sasl-sample-server -s host -p /usr/lib/sasl2 -m GSSAPI -d mybox.mydomain

Cette commande prend en argument un service (-s), l’emplacement des librairies des différents mécanismes supportés (-p), le mécanisme forcé (-m) et le FQDN de la machine (-d). Ici on utilise le service host (service de test), pour tester le mécanisme GSSAPI. Elle produit les résultats suivants :

Forcing use of mechanism GSSAPI
Sending list of 1 mechanism(s)
S: R1NTQVBJ
Waiting for client mechanism...

Sur la terminal dédié au client, on va lancer :

[root@term2]# sasl-sample-client -s host -p /usr/lib/sasl2 -m GSSAPI -n myhost.mydomain -u toto

Cette commande prend le nom d’utilisateur que l’on cherche à authentifier (-u). Ici il s’agit de “toto” qui est un principal de notre realm Kerberos. On doit avoir la sortie suivante :

service=host
Waiting for mechanism list from server...

Sur la sortie du serveur, on a la chaîne suivante : “S: R1NTQVBJ”. Il faut la passer au client dans la mesure où il n y a pas d’interaction réelle entre les deux programmes. Pour la passer, un simple copier coller suffit. Attention cependant, pour la valider il ne faut pas appuyer sur entrée mais faire [ctrl]+D (2 fois).Si on appuie sur entrée, cela concatène un retour charriot à la chaine non attendu par le programme. La réponse du client est :

S: R1NTQVBJrecieved 6 byte message
Forcing use of mechanism GSSAPI
Choosing best mechanism from: GSSAPI
returning OK: p10613
Using mechanism GSSAPI
Preparing initial.
Sending initial response...
C: R1NTQVBJAGCCAj8GCSqGSIb3EgECAgEAboICLjCCAiqgAwIBBaEDAgEOogcDBQAgAAAAo4IBPWGCATkwggE1oAMCAQWhERs
PVU5JVi1PUkxFQU5TLkZSoiwwKqADAgEDoSMwIRsEaG9zdBsZbWFpbHRlc3QxLnVuaXYtb3JsZWFucy5mcqOB7DCB6aADAgE
SoQMCAQOigdwEgdnWwLC9Ycz3AQxjwf/iNs9xldAuOErtfaNhCDqpq7tbV1FhzFjV+vv8HdbS9qD2eDwYvyglHSLgLJbsPZdl
wPvxllN/NuOVrJB
/8FosD1sWvt1FKIyXDwovOsIvKcFa8zibivG0HBRxEWQQULrC8Wlr1qFzvjWQMlAriZ2+uEKxWVqIGDbDk9bndAGhXmZdN
KfmqzzsBkqPEIAxAW4uTaIRNxHwonizG7MbngRZhuMBCki3L7+nAxxB6bWHhuZEvPA8VLBBa5lemkbr5+k1hRuiuxX1Q
muS3+TGpIHTMIHQoAMCARKigcgEgcU8+fSbMrZekojdtuhE+RPXgQHFRjufJpFZvI+F/csYU6cZE3hNFojp4yrTcYRptlLSTV
AcfBp50xjjoHicbm5Uzvwaq+6+aDdRomCfyiScuJ1ol+F36aNi2gdhjKuV6glWCXU1DM+HaV4DWwQBIRCIdHTwQC/czfz6
nWAz
o8x0cPkOkQwHmV
vWtBZwlaref8LGWfckQXK8QLNBVxBzwmeTuar4dZw+kA1sNjQeFUqvg5MixRAxTu1xjTdTyvlGK1PONAtnvw==
Waiting for server reply...

Copier coller de la réponse du client sur le serveur :

Sending response...
S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvb+47IUZ7sugVxWME3mMwey4jj
s/cvWXv6X1bgy1ETeaL8FChCtUnIvalmjHzUR9dplYmU68sKyFkc7xKHvKIbhkRk5F7PMy10iN+pspGDrFsCClm3ub
xMArsS9EfqBOzWonMRFZVhdPPAL7bgRGY
Waiting for client reply...

On colle ça dans le client :

C:
Waiting for server reply...

La réponse est un caractère blanc que l’on colle sur le serveur :

C: got ''
Sending response...
S: BQQF/wAMAAAAAAAAG76J+wcACACTtO/4HK+L2u98azg=
Waiting for client reply...

On transmet au client :

S: BQQF/wAMAAAAAAAAG76J+wcACACTtO/4HK+L2u98azg=recieved 32 byte message
Sending response...
C: BQQE/wAMAAAAAAAAD8CVGwQACABwMTA2MTMJcB2SqMJGtwEtfAk=
Negotiation complete
Username: toto
SSF: 56
Waiting for encoded message...

Hop, on colle dans le serveur :

C: BQQE/wAMAAAAAAAAD8CVGwQACABwMTA2MTMJcB2SqMJGtwEtfAk=got ' '
Negotiation complete
Username: p10613
Realm: (NULL)
SSF: 56
sending encrypted message 'srv message 1'
S: AAAASgUEB/8AAAAAAAAAABu+ifwxS1DHVyL8o4X8J2HeKsv8SaZsa36ZCAp0znoCUh6V
Fjf0+cxdGXX6c9Xie6+3bf+QJ8/N4H0cxS25
Waiting for encrypted message...

Dernier envoi sur le client :

S: AAAASgUEB/8AAAAAAAAAABu+ifwxS1DHVyL8o4X8J2HeKsv8SaZsa36ZCAp0znoCUh6V
Fjf0+cxdGXX6c9Xie6+3bf+QJ8/N4H0cxS25recieved 78 byte message
recieved decoded message 'srv message 1'
sending encrypted message 'client message 1'
C: AAAATQUEBv8AAAAAAAAAAA/AlRxbCjz0s/JxqbqHFHFHQNlOit4+ylbVbsmcaEJ5
PDTa8F8A7NhQ9sdciXNOhDe1oGYrCiF5Y23CaZdYUEbF

On clôt le côté serveur également :

C: AAAATQUEBv8AAAAAAAAAAA/AlRxbCjz0s/JxqbqHFHFHQNlOit4+ylbVbsmca
EJ5PDTa8F8A7NhQ9sdciXNOhDe1oGYrCiF5Y23CaZdYUEbFgot ''
recieved decoded message 'client message 1'

Le petit soucis du [ctrl]+D m’a fait perdre un sacré temps. En tout cas, si vous arrivez jusque la c’est que vous avez simulé une authentification via la GSSAPI (et surtout que ça marche ;-) ).