| Avertissement |
|---|
Les pages ci-dessous montrent une expérience menée à l'IFSIC dans le but de montrer la faisabilité d'une architecture dont l'authentification serait complètement prise en charge par un serveur d'authentification Kerberos. Tous les tests menés ont conclu à la faisabilité, sauf le montage CIFS sur le filer NetApp du CRI, qui nécessite l'appui sur un Active Directory ; les auteurs ont réussi à configurer la relation d'approbation d'un serveur Active Directory vers le serveur Kerberos, mais pas le montage des volumes en CIFS lui-même (à leur grand désespoir...). Deux pistes sont désormais envisagées :
|
Machines mises en place (archive)
Une description de l'architecture mise en place et des acteurs du système.
Installation et configuration du serveur Kerberos (archive)
Comment installer un serveur d'authentification Kerberos.
Intégration d'un client Linux (archive)
Comment intégrer un client Linux dans un royaume Kerberos.
Passage de l'authentification Kerberos aux applications web (mod_auth_kerb)
Comment configurer Apache et mod_auth_kerb pour que l'authentification Kerberos passe du niveau système au niveau applicatif (web).
Installation et configuration du serveur CAS (archive)
Comment installer et configurer un serveur CAS pour qu'il authentifie les utilisateurs par Kerberos et LDAP.
Passage de l'authentification Kerberos à Samba (archive)
Comment mettre en place un serveur Samba et faire passer l'authentification Kerberos des clients lors du montage des volumes.
Passage de l'authentification Kerberos à NFS (v4)
Comment mettre en place un serveur NFS v4 et faire passer l'authentification Kerberos des clients lors du montage des volumes.
CASKERB:802.1X, radius et Kerberos802.1X, radius et Kerberos (archive)
Comment configurer un serveur freeRadius pour qu'il authentifie les usagers sur une base kerberos
Intégration d'un client Windows XP (archive)
Comment intégrer un client Windows XP dans un royaume Kerberos.
Intégration d'un client Windows 7 (archive)
Comment intégrer un client Windows 7 dans un royaume Kerberos.
...
Migration de l'authentification de LDAP à Kerberos (archive)
Comment envisager la migration de l'authentification des utilisateurs d'un annuaire LDAP à un serveur Kerberos.
Points restants à voir :
- CUPS et Kerberos
- NetApp et Kerberos
- AD et Kerberos
La configuration d'un client dans un royaume kerberos nécessite quelques paramètres clonables (nom du royaume, serveurs du royaume,...). Ces paramètres sont positionnés dans le fichier /etc/krb5.conf (Linux) ou par des commandes qui modifient des clefs de registre (ksetup sous Windows). Dans le cadre d'un système de déploiement, l'image à déployer peut avoir été configurée avec les valeurs adéquates.
Le problème principal est de mettre en place la confiance entre le serveur kerberos et les clients (fichier keytab sous Linux, clefs de registre sous Windows, ...). Un fichier keytab ou son équivalence Windows contient la clef attribuée au principal par le serveur kerberos. Cette clef est évidemment propre à chaque client (principal), comment éviter une intervention sur chaque poste à l'issue d'un déploiement ? Il faut aussi noter que la sécurité d'un environnement kerbérisé repose sur la confidentialité du contenu des keytab et qu'on se place ici forcément dans un compromis entre sécurité et faisabilité.
- Linux : les keytab de toutes les machine figurent dans l'image à déployer, la première phase de boot va éliminer les keytab inutiles et positionner le bon en fonction du nom du poste de travail. Pour créer tous les keytab on peut procéder de la manière suivante :
- sur le serveur kerberos on execute kadmin/addprinc (randkey) pour créer tous les principaux;
- on génère ensuite un keytab par poste de travail. Les fichiers keytab portent un nom explicite et sont placés dans un répertoire qui va être exporté sur le poste étalon.
- Windows : concernant la création des principaux, on ne peut pas ici utiliser l'option -randkey car l'installation de la clef sur le client est effectuée par une commande. On va donc sur le serveur kerberos créer tous les principaux Windows avec le même mot de passe. Il faut ensuite, une fois le déploiement effectué, avoir la possibilité (en tant qu'administrateur) d'exécuter la commande "ksetup /setcomputerpassword password". Nous envisageons d'utiliser un credential provider pour faire ça une seule fois lors du premier login sur la machine.