Vous regardez une version antérieure (v. /wiki/pages/viewpage.action?pageId=83329041) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 55) afficher la version suivante »

Machines mises en place
Une description de l'architecture mise en place et des acteurs du système.

Installation et configuration du serveur Kerberos
Comment installer un serveur d'authentification Kerberos.

Intégration d'un client Linux
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
Comment installer et configurer un serveur CAS pour qu'il authentifie les utilisateurs par Kerberos et LDAP.

Intégration d'un client Windows XP
Comment intégrer un client Windows XP dans un royaume Kerberos.

Intégration d'un client Windows 7
Comment intégrer un client Windows 7 dans un royaume Kerberos.

Problèmes liés au clonage des postes

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).

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.
  • Aucune étiquette