Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

Pascal Aubry et François Dagorn (Université IFSIC / université de Rennes 1)

Sommaire

1. La situation actuelle

1.1 Architecture

L'architecture informatique de l'université de Rennes 1 est aujourd'hui constituée de :

  • postes clients (Windows XP, Linux et Mac OS X). A ces postes viendront s'ajouter à la rentrée 2010/2011 des postes Windows 7.
  • serveurs de fichiers
    • Network Appliance (commun à toute l'Université) partagé en NFS pour les clients Unix et en CIFS pour les clients Windows
    • Serveurs de fichiers Unix partagés en NFS pour les clients Unix et/ou CIFS (Samba) pour les clients Windows
    • Serveurs de fichiers Windows partagés en CIFS pour les clients Windows
  • services applicatifs web
  • serveurs d'impression CUPS

1.2 Authentification

Le système d'authentification des usagers est architecturé autour de l'annuaire LDAP de l'établissement qui est dérivé journellement du système d'information. L'authentification LDAP est dans tous les cas réalisée par un fast bind sur l'annuaire du couple uid/password dont on veut valider l'authenticité, les mécanismes suivants sont mis en oeuvre :

...

Notons qu'il s'agit d'un usage détourné de l'annuaire LDAP, conçu initialement comme un service de pages blanches pour la recherche d'informations (utilisateurs, machines) et est aujourd'hui principalement utilisé pour l'authentification. Cet usage est néanmoins très largement adopté dans nos universités et répond fonctionnellement bien au besoin car il permet de contrôler l'accès à tous les types de services nécessaires sur un réseau informatique (ouverture de sessions, impressions, partage de fichiers, ...). Il est de plus disponible dans tous les environnements utilisés (Linux, Windows, MacOS, Solaris, ...).

2. Pourquoi évoluer ?

L'utilisation de LDAP décrite plus haut est aujourd'hui relativement générale dans les universités, plusieurs problèmes liés à la sécurité des réseaux se posent pourtant.

2.1 Pour plus de sécurité

Les mots de passe des usagers doivent impérativement être acheminés en clair depuis les postes de travail qui hébergent des services jusqu'aux serveurs LDAP chargés des opérations de contrôles. L'utilisation du protocole sécurisé LDAPS (LDAP sur TLS) permet de contourner ce problème puisqu'il impose une session TLS avant tout dialogue LDAP.  L'université de Rennes 1 n'utilise pas LDAPS et tous les postes de travail du réseau académique exposent les mots de passe des usagers aux yeux d'utilisateurs indélicats (l'empoisonnement ARP est facile à mettre en oeuvre). L'utilisation de services de fichiers mutualisés contrôlés par LDAP accentuent ce problème car les mots de passe doivent circuler en clair jusqu'aux services avant d'être acheminés ensuite (éventuellement en LDAPS) jusqu'aux serveurs LDAP. Dans ce cadre, les serveurs d'impressions (Samba, pam_ldap) ainsi que le serveur de fichiers communautaire de l'université de Rennes 1 sont aujourd'hui des maillons faibles de la sécurité du réseau de l'établissement.

2.2 A cause de l'apparition de Windows 7

En 2009, le nouveau système d'exploitaion Windows 7 est apparu, il ne s'intègre pas facilement dans un environnement contrôlé par LDAP.

...

L'IFSIC a développé un outil similaire à PGina (Regina), il est en place et fonctionne. La méthode utilisée par Regina et PGina pour intercepter et utiliser le mot de passe en clair n'est néanmoins pas compatible avec les impératifs de sécurité d'un réseau informatique. Plus généralement, c'est l'utilisation de LDAP pour authentifier des usagers qui pose de gros problèmes de sécurité.

2.3 Pour un SSO de bout en bout

La généralisation des ENT a permis la mise en oeuvre de systèmes d'authentification unique pour les environnements web, mais on reste pour l'instant d'en l'attente d'un système d'authentification allant de l'ouverture de session jusqu'aux applicatifs Web.

3. Les solutions

On distingue trois solutions possibles raisonnablement envisageables à la rentrée 2010/201.

3.1 Ne rien faire

Bien que non sécurisé, le réseau est aujourd'hui fonctionnel, il peut rester en l'état.

Si cette solution est la plus envisageable en terme de coût, elle oblige néanmoins à utiliser une « verrue » supplémentaire pour Windows 7 (Regina).

3.2 Utiliser Active Directory quand c'est possible

Les deux failles principales sont le serveur de fichiers et les services d'impressions. S'il est relativement simple de contrôler les accès CIFS au serveur de fichier communautaire (par l'intermédiaire d'un serveur Active Directory  utilisant une authentification NTLM nettement plus sûre que LDAP), cette solution ne règle pas complètement le problème car :

  • les postes Linux utilisent actuellement des montages NFS dans lesquels le serveur de fichiers fait confiance au client (sécurité zéro).  Quelle solution adopter alors ?
  • les services d'impressions continuent à utiliser Samba + pam_ldap, faut-il  les faire basculer aussi vers Active Directory ? Comment se passeraient alors les impressions depuis Linux ?

3.3 Changer de mécanisme d'authentification

Dans ce cadre, seule la solution Kerberos est envisageable.

...

Notre choix se porte donc clairement sur la première solution.

4. Kerberos

Kerberos fonctionne en environnement hétérogène, assurant la sécurité des échanges sur un réseau non sûr et permettant la mise en place d'un véritable service d'authentification unique.

...

Kerberos a été mis au point au MIT dans les années 1990, il est maintenant très largement déployé et est disponible dans tous les environnements aujourd'hui utilisés (Linux, Windows, MacOS, ...). Des universités françaises ont déjà migré leur systèmes d'authentification vers Kerberos, parmi celles-ci on peut citer les universités de Strasbourg et de Bordeaux 1.

5. Les tests effectués

Comme indiqué en 3.3,  la possibilité d'utiliser le serveur Kerberos enlisé dans un service Active Directory de MicroSoft a été volontairement écartée et les tests ont été effectués avec un serveur Kerberos hébergé sur un serveur Linux.
Les éléments ci-dessous ont été validés.

5.1 Le service Kerberos

Un serveur kerberos (MIT 1.6.1) maître est fonctionnel sur kerb1.univ-rennes1.fr. Il est redondé par un second serveur esclave (kerb2.univ-rennes1.fr), dont la synchronisation avec le serveur maître est assurée par une crontab via le protocole kprop.

...

Voir : Installation des serveurs Kerberos

5.2 Le service CAS

Un serveur CAS (3.3.5) est fonctionnel sur cas-kerb.univ-rennes1.fr.

...

Voir : Installation du serveur CAS

5.3 Les clients

L'authentification Kerberos s'intègre parfaitement (de manière native) dans les clients Linux, l'accès à tous les services a été validé : CAS, NFS v3 et v4 (sur serveurs linux et NetApp), Samba, CUPS.

...

5.4 Les services de fichiers

Le montage des volumes NetApp a été validé à la fois en NFS depuis les clients Unix et en CIFS depuis les clients Windows, en s'appuyant sur un Active Directory pour lequel une relation d'approbation mutuelle avec le royaume Kerberos a été mis en place.

...

5.5 Le service CUPS

Les clients Windows et Unix peuvent imprimer sur un serveur CUPS Kerbérisé de manière transparente.

Voir : Mise en place d'un serveur CUPS

5.6 Le service 802.1X

Un serveur FreeRadius a été configuré pour utiliser une base d'authentification Kerberos.
Le dispositif fonctionne mais ne peut pas être intégré dans le cadre de l'authentification unique.

Voir : 802-1x, Radius et Kerberos

6. Une stratégie de déploiement

Les tâches à réaliser pour mettre l'authentification Kerberos en production sont listées ci-dessous.

...

Le passage de toute l'université à l'authentification Kerberos nécessiterait au niveau de chaque cellule les mêmes tâches que celles à effectuer à l'IFSIC.

6.1 Tâches au niveau du CRI

Serveurs Kerberos

Recréer une infrastructure de production pour les serveurs Kerberos kerb1.univ-rennes1.fr et kerb2.univ-rennnes1.fr.

Voir : Installation des serveurs Kerberos

Serveur CAS

Modifier le serveur CAS pour qu'il permette :

...

Voir : Installation du serveur CAS

Application Sésame

Modifier l'application Sésame de l'université pour qu'elle permette :

...

Voir : Modification de l'application Sésame

NetApp

Ajouter les exports NFS v4 avec authentification Kerberos (et vérifier qu'ils sont compatibles avec les mêmes exports v3 sans authentification, sinon rester en v3/Trusted).

...

Voir : Mise en place d'un serveur NFS (v4-Kerberos)

6.2 Tâches au niveau de l'IFSIC

Clients

Modifier tous les clients pour l'authentification Kerberos.

...

Serveur de fichiers

Modifier l'authentification des serveurs Samba et NFS (passage à Kerberos).

...

Serveur d'impression

Remonter un serveur d'impression Kerberisé pour faciliter la transition.

Voir : Mise en place d'un serveur CUPS

7. Conclusion

Tout est techniquement prêt pour migrer d'une authentification basée sur LDAP à une authentification basée sur Kerberos.

...