I) Introduction :
Dans le mécanisme traditonnel d’authentification, les utilisateurs prouvent leur identité au moyen d’un mot de passe. Ce système ne sait pas vérifier si l’utilisateur distant a volé le mot de passe ni même si le système distant est un système criminel masqué derrière une adresse dérobée.
Dans le système d’authentification Kerberos, lorsque un utilisateur tente de se connecter à un système, un hôte, le Key Distribution Center (centre de distribution des clés ou KDC) va vérifier les identités des deux parties avant de valider une authentification et en cas de succès, il va avertir chacune des deux parties que l’autre est bien celui qu’il prétend être.
Deux points important sont à noter pour finir cette courte introduction. Tout d’abord, l’utilisation de Kerberos nécessite que les services soient kerberisés. Les logiciels doivent être conçus pour exploiter Kerberos sinon point de sécurisation. L’exemple flagrant est celui des domaines MS Active Directory qui exploitent Kerberos V5 sur le papier mais même en 2004 la plupart des applications même Microsoft ne le sont pas et exploitent par conséquent le bien moins sécurisé NTLM. L’autre point important est que par son mode de fonctionnement, Kerberos implémente le SSO (Single Sign On) ce qui permet de n’avoir à s’authentifier qu’une fois puis après il suffit de présenter son ticket Kerberos. Mais encore une fois cela est valable si les applications sont Kerberisées.
II) Installation :
Sous Debian :
# apt-get install krb5-kdc krb5-admin-server krb5-user
L’installation vous demandera d’entrer la clé maitre (master key) du KDC.
Et si vous souhaitez faire une installation propre, ajoutez les les champs SRV suivants dans la zone correspondante de votre DNS :
_kerberos._udp IN SRV 01 00 88 kerberos.momonux.org. _kerberos._tcp IN SRV 01 00 88 kerberos.momonux.org. _kpasswd._udp IN SRV 01 00 464 kerberos.momonux.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.momonux.org. _kerberos IN TXT MOMONUX.ORG.
Rien de spécifique à connaître pour la configuration du KDC en lui même. Éditez le fichier /etc/krb5kdc/kdc.conf et adaptez le nom du Realm (zone kerberos) à votre Realm. Le Realm correspond au domaine DNS en majuscule. Sachez qu’un KDC peut être serveur de plusieurs Realms.
Adaptez ce fichier en remplaçant MOMONUX.ORG par votre Realm.
[kdcdefaults] kdc_ports = 750,88 [realms] MOMONUX.ORG = { database_name = /var/lib/krb5kdc/principal admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab al_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/stash kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3 default_principal_flags = +preauth }
Maintenant que le KDC est configuré, on va définir le comportement des clients Kerberos de ce KDC. On va notamment définir le realm par défaut et comment contacter ce realm. Cette manipulation s’effectue sur le KDC et sur les clients de ce même KDC. Pour celà, éditez le fichier /etc/krb5.conf.
[libdefaults] default_realm = MOMONUX.ORG kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] MOMONUX.ORG = { kdc = kerberos.momonux.org admin_server = kerberos.momonux.org default_domain = momonux.org } [domain_realm] momonux.org = MOMONUX.ORG momonux.org = MOMONUX.ORG
III) Initialisation du KDC :
Dans un premier temps, il faut initialiser la base de données du KDC fraîchement installé :
kdb5_util create -r MOMONUX.ORG -s
Il est temps de démarrer le KDC maintenant :
# krb5kdc
Ensuite, on va ajouter un utilisateur principal nommé foo:
kadmin.local: add_principal foo@MOMONIX.ORG WARNING: no policy specified for foo@MOMONIX.ORG; defaulting to no policy Enter password for principal "foo@MOMONIX.ORG": Re-enter password for principal "foo@MOMONIX.ORG": Principal "foo@MOMONIX.ORG" created.
Enfin, on va ajouter un hôte principal. Il faut ajouter chaque hôte du réseau à kerberiser sur le kdc.
kadmin.local: addprinc host/carl.momonux.org WARNING: no policy specified for host/carl.momonux.org@MOMONUX.ORG; defaulting to no policy Enter password for principal "host/carl.momonux.org@MOMONUX.ORG": Re-enter password for principal "host/carl.momonux.org@MOMONUX.ORG": Principal "host/carl.momonux.org@MOMONUX.ORG" created.
Testez votre KDC en faisant une demande de ticket à l’aide de la commande kinit :
# kinit julien@MOMONUX.ORG Password for julien@MOMONUX.ORG:
Affichons la liste des tickets Kerberos à l’aide de klist :
$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: julien@MOMONUX.ORG Valid starting Expires Service principal 10/21/04 18:20:51 10/22/04 04:20:51 krbtgt/MOMONUX.ORG@MOMONUX.ORG renew until 10/22/04 18:20:49
Notez que la commande kadmin permet d’effectuer cette commande sur une autre machine que le KDC
Pour finir sur la configuration du KDC, il se pourrait que vous auriez besoin d’avoir recours à un serveur esclave, particulièrement dans les environnements de production. L’implémentation Kerberos du MIT gère très bien celà au moyen de la commande kpropd -S.
IV) Mise en pratique : authentification de clients GNU/Linux :
Il vous faudra impérativement avoir configuré le client kerberos comme décrit plus haut. Si c’est le cas vous pouvez procéder à l’installation du module PAM approprié. Sous Debian le paquet porte le nom de libpam-krb5.
Configuration de PAM sous Debian :
Effectuez le remplaçement suivant dans le fichier /etc/pam.d/common-password :
password required pam_unix.so nullok obscure min=4 max=8 md5
Devient :
password sufficient pam_unix.so md5
password required pam_krb5.so try_first_pass
Configuration de PAM sous Gentoo/Mandrake/Fedora :
Effectuez le remplaçement suivant au fichier /etc/pam.d/system-auth :
auth required /lib/security/pam_env.so auth sufficient pam_ldap.so try_first_pass auth sufficient /lib/security/pam_unix.so likeauth nullok try_first_pass auth required /lib/security/pam_deny.so account optional /lib/security/pam_ldap.so try_first_pass account required /lib/security/pam_unix.so try_first_pass password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok md5 shadow try_authtok try_first_pass password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session sufficient /lib/security/pam_ldap.so try_first_pass session required /lib/security/pam_unix.so try_first_pass
Devient :
auth required /lib/security/pam_env.so auth required /lib/security/pam_unix.so likeauth nullok auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_krb5.so password required /lib/security/pam_unix.so nullok md5 shadow try_authtok try_first_pass password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so
Maintenant authentifiez vous depuis la machine sur cette machine et validez avec les journaux que l’authentification fonctionne.
V) Conclusion :
Kerberos est un mécanisme d’authentification très puissant. Couplé à LDAP (en plaçant l’attribut userPassword à la valeur {KERBEROS}user@realm), il peut fournir une solide plateforme d’authentification. Cette plateforme complétée par un serveur Samba vous permettra d’avoir un système d’authentification sûr et surtout opérationnel pour des clients UNIX comme des clients Windows.
Merci pour la clarté de ce ticket sur Kerberos, une question subsiste pour moi à propos de l’authentification d’un client windows, en effet j’ai monté mon serveur Kerberos qui tourne parfaitement, j’arrive à authentifier mon client linux, mais le client windows me pose problème. je procède de la façons suivante:
-J’ajoute un principalepour les ordinateurs windows
– je crée un principal pour un utilisateur windows
– je me connecter en admin sur le poste client wibdows
– j’installe le paquet suptools.msi ( il est dans D:/support/tools)
– j’ouvre une console sous windows en admin
ksetup /setdomain VMNET.RLA
ksetup /addkdc VMNET.RLA vm4.vmnet.rla
ksetup /setmachpassword kxpen
*** REBOOT ***
ksetup /mapuser * *
Merci pour la clarté de ce ticket sur Kerberos, une question subsiste pour moi à propos de l’authentification d’un client windows, en effet j’ai monté mon serveur Kerberos qui tourne parfaitement, j’arrive à authentifier mon client linux, mais le client windows me pose problème. je procède de la façons suivante:
-J’ajoute un principalepour les ordinateurs windows
– je crée un principal pour un utilisateur windows
– je me connecter en admin sur le poste client wibdows
– j’installe le paquet suptools.msi ( il est dans D:/support/tools)
– j’ouvre une console sous windows en admin
c:>ksetup /setdomain VMNET.RLA
c:>ksetup /addkdc VMNET.RLA vm4.vmnet.rla
c:>ksetup /setmachpassword kxpen
*** REBOOT ***
c:>ksetup /mapuser * *
– sous windows je crée un utilisateur du même nom que j’ai crée sous kerberos
Et voilà lorsque le prompt de login s’affiche et que je choisi de me connecter sur Kerberos realm
il m’affiche échec…
pitié quelqu’un aurait -il une idée, ça fait un semaine que je bloque dessus ?
cordialment.
Toujours via le support tools, vérifie que tu peux faire un kinit user@REALM. De la même façon Microsoft Windows utile beaucoup les requêtes DNS de type SRV, as-tu publié dans ton DNS les champs correspondants?
Bonjour, merci. J’ai réussi à mettre en place Kerberos.
Cependant, il y a quelque chose dont je ne suis pas sur. A la ligne addprinc host/carl.Momonux.org, tu dis qu’il faut créer un principal pour chaque hôte du réseau.
Ca veut dire que pour chaque utilisateur de mon domaine samba, je créé “nom du pc client/nom user@Domaine.Priv” ??
Merci d’avance.
Salut, il te faut un principal par hôte et un principal par utilisateur.
Bon courage,
Julien
Salut, en fait j’aurai une deuxième question.
Les SRV Records (ainsi que le TXT), tu les mets bien à la fin de ton fichier de zone de recherche directe de Bind9 ?
Car à priori, ils ne sont pas reconnus lorsque j’éxecute la commande de vérification du fichier DNS :
named-checkzone ADJB.PRIV /etc/bind/db.ADJB.PRIV
db.ADJB.PRIV:15: unknown RR type ’00’
db.ADJB.PRIV:16: unknown RR type ’00’
db.ADJB.PRIV:17: unknown RR type ’00’
db.ADJB.PRIV:18: unknown RR type ’00’
zone ADJB.PRIV/IN: loading from master file db.ADJB.PRIV failed: unknown class/type
Salut,
L’emplacement dans le fichier de zone directe n’a pas d’importance mais c’est bien là qu’ils doivent être présents. Peux-tu me montrer les enregistrements SRV de ta zone?
Voilà les enregistrements SRV de mon fichier de zone directe (la commande named-checkzone renvoie OK si les SRV sont commentés) :
_kerberos._udp 01 00 88 kerberos.ADJB.PRIV.
_kerberos._tcp 01 00 88 kerberos.ADJB.PRIV.
_kpasswd._udp 01 00 464 kerberos.ADJB.PRIV.
_kerberos-adm._tcp 01 00 749 kerberos.ADJB.PRIV.
_kerberos IN TXT ADJB.PRIV.
Merci de ton aide.
Effectivement tu ne ne précises pas le type d’enregistrement DNS, or le type SRV est tun type comme les autres (MX, NS, A, PTR…).
Ta première ligne devrait être :
_kerberos._udp IN SRV 01 00 88 kerberos.ADJB.PRIV.
Bon, pour les IN c’est un oubli de ma part sur mon post précédent, ils sont présents dans mon fichier.
Pour le ‘SRV’ j’aurai dû m’en apercevoir plus tôt, c’est d’une logique…
Par contre tu ne l’a pas précisé non plus dans ton tuto, est-ce normal ?
Merci.
C’est mis à jour. Sans doute une erreur de saisie, ça date de 2004 maintenant 🙂
Content que ça fonctionne pour toi.
bonjour
je suis un eleve ingenieur en info et telecom option cryptographie,la plate forme d’authentification de Kerberos m’interesse et je voulais bien travailler dessus,je voudrais donc obtenir d’explication et de conseils par rapport
Bonjour,
Quelles sont tes questions à ce sujet?