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 cachedNous 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 
).
0 Response to “Validation de la couche SASL”