...
Cette page discute de la migration d'une architecture où l'authentification des utilisateurs est confiée à un annuaire LDAP à une architecture où l'annuaire LDAP n'aurait en charge que son métier propre (le service d'annuaire) et où l'authentification des utilisateurs serait assurée par Kerberos.
Pourquoi ne pas basculer directement de LDAP à Kerberos ?
Parce que c'est impossible.
...
| Remarque | ||
|---|---|---|
| ||
Au terme de la phase de migration, c'est-à-dire quand tous les utilisateurs existants avant la mise en place de Kerberos seront présents dans le royaume, il sera possible (sous réserve de tests) de modifier l'authentification pour qu'un bind user/password soit validé en s'appuyant sur le serveur Kerberos et non les mots de passe contenus dans l'annuaire LDAP. Il est peut-être même possible de faire en sorte de configurer l'annuaire LDAP de telle manière que les binds user/password soient validés en s'appuyant sur les mots de passe de l'annuaire LDAp présents, et sur le serveur Kerberos sinon, grâce à un démon sals_authd utilisant la GSSAPI (à confirmer). |
Quand et comment migrer les utilisateurs ?
Il faut donc disposer d'un moyen de créer les utilisateurs dans le royaume Kerberos a la volée, à un moment où on dispose de leur mot de passe.
Les moments candidats sont les suivants :
- Lors de l'authentification sur un poste client. Cette solution, envisageable grâce au module PAM pam_krb5_migrate, est rejetée car elle nécessiterait un accès privilégié de création des comptes sur les postes clients, estimé comme un trop gros risque en matière de sécurité.
- Lors de l'authentification à un service, consulté par les utilisateurs de manière suffisamment régulière pour que la migration soit la plus rapide possible. Le seul service candidat suivant cette contrainte est le serveur de mail. Cette solution se heurte néanmoins au fait que dans de nombreux établissements, la consultation des mails se fait (au moins pour les étudiants) à travers un webmail CASifié, qui ne reçoit pas les mots de passe des utilisateurs (c'est dans ce cas le module pam_cas qui valide l'authentification des utilisateurs grâce à des ST ou PT émis par le serveur CAS).
- Lors de l'authentification sur le serveur CAS. C'est cette solution qui est retenue.
Comment faire ?
Pour rajouter au royaume Kerberos les utilisateurs qui n'y sont pas déjà
Il faut rajouter au serveur CAS le code nécessaire pour, à chaque fois qu'un utilisateur se connecte avec une authentification différente de Kerberos :
...
Voir plus loin pour le code ajouté au serveur CAS.
Pour créer les nouveaux utilisateurs à la fois dans le royaume Kerberos et l'annuaire LDAP
Il faut modifier la procédure de création des comptes des utilisateurs et y rajouter le code nécessaire pour créer les utilisateurs dans le royaume Kerberos.
Selon les procédures en vigueur dans l'établissement, il est également possible de créer le compte dans le royaume Kerberoslors de la première validation du compte à travers une interface web dédiée (comme cela est fait pour l'interface Sésame à l'université de Rennes 1).
Pour maintenir la cohérence des mots de passe LDAP et Kerberos
Il faut pendant la phase de migration s'assurer que les changements de mot de passe soient faits à la fois dans l'annuaire LDAP et le royaume Kerberos.
Pour cela, le changement de mot de passe ne doit pas être possible depuis les postes clients (car il ne serait répercuté dans l'annuaire LDAP) et doit se faire via une interface web centraliséequi répercute les changements à la fois dans le royaume Kerberos et l'annuaire LDAP.
Modifications du serveur CAS
Comme vu précédemment il faut, à chaque fois qu'un utilisateur se connecte avec une authentification différente de Kerberos :
...
L'alimentation du royaume Kerberosest faite par un wrapper de AuthenticationHandler ; de cette manière, elle peut être activée pour pour certains handlers seulement.
Modifications des sources
On crée tout d'abord un module supplémentaire nommé cas-server-integration-kerberosfeed en installant les sources du zip attaché .
...
Cela créee le war /cas-server-webapp/target/cas.war qui peut être déployé.
Configuration
Les beans ci-dessous sont dans le fichier /cas-server-webapp/src/main/webapp/WEB-INF/deployerConfigContext.xml.
...