The Fedora Marketing team built this interview as part of their work promoting the latest and greatest free and open source software technologies that Fedora brings with each new release. If you're interested in participating in Fedora, visit http://join.fedoraproject.org to get started.
Éclairage sur SSSD
Interview
Stephen, peux-tu te présenter, qui es-tu et que fais-tu ?
Je m'appelle Stephen Gallagher, et je milite pour le logiciel libre depuis un moment. J'utilise Red Hat Linux et ses dérivées depuis 1999, et depuis quelques années, j'ai décidé de m'offrir de faire ce que j'aime.
J'ai rejoins l'équipe de développement de FreeIPA v2 au sein de Red Hat depuis juin 2008. J'ai été embauché pour travailler sur le composant côté client de FreeIPA.
Je suis là pour parler avec toi de SSSD (System Security Services Daemon). Peux-tu me donner un bref descriptif de SSSD, qu'est-ce et que fait-il ?
SSSD a commencé en tant que composant du client FreeIPA. Le but initial était de fournir des fonctionnalités plus avancées que la recherche de nom d'utilisateurs et l'authentification centralisée.
Alors que nous le développions, nous avons réalisé que bon nombre de ces fonctionnalités pourraient être utilise y compris sans FreeIPA, alors nous l'avons séparé de celui-ci.
Le SSSD moderne n'est plus un simple service mais une collection de services proposant une interface commune pour l'identification et l'authentification.
SSSD fournit des informations utilisateurs à travers l'interface standard NSS (name-service switch) utilisé par les services d'identification classiques tels que nss_ldap et nss_nis. Nous fournissons également un module PAM (module d'authentification enfichable) pour gérer l'authentification.
Ok. Parlons de SSSD à partir de différents points de vue utilisateurs. Premièrement, supposons que je sois un utilisateur moyen. Comment SSSD peut m'être utile ? Comment interagir avec et s'intègre-t-il de façon transparente à mon environnement si je suis un nouvel utilisateur ?
L'utilisateur n'interagis pas vraiment avec SSSD directement. La fonctionnalité la plus visible pour l'utilisateur est à la disponibilité des autorisations mises en cache. Cela signifie que si ton compte utilisateur est géré par une autorité d'authentification centralisé (par exemple LDAP et Kerberos), tu n'as plus besoin d'avoir un compte local distinct sur ton portable quand tu n'es plus connecté au réseau central.
Dans un déploiement traditionnel, cela voudrait dire que pour se connecter en tant qu'utilisateur géré par LDAP et authentifié par Kerberos, tu devrais te connecter au réseau d'entreprise. Sinon, le système est incapable d'accéder aux serveurs LDAP et Kerberos pour t'identifier.
Avec SSSD, une fois que tu t'es connecté, les autorisations sont mises en cache (de manière sécurisée) dans SSSD, de façon à ce que tu puisses prendre ton portable de fonction, l'éteindre, monter dans le train puis te connecter.
Ça a l'air terrible, mais mon administrateur système ne connait pas SSSD. Quels sont les arguments lui donner pour lui démontrer l'utilité de SSSD pour moi et mes collègues ?
NSS est une fonctionnalité incluse dans les bibliothèques standards du système. Quand un programme demande des informations sur un utilisateur (comme relier un identifiant à un nom d'utilisateur, vérifier l'appartenance de celui à des groupes, le shell par défaut, le nom d'utilisateur complet, etc...), il formule une requête au système. En interne, l'appel système scrute la listes des greffons NSS accessibles. *Dans le contexte du processus original*, et ensuite, il se connecte au serveur d'identification pour résoudre l'information. Cela veut dire que sur chaque machine cliente, il peut y avoir des douzaines voire plus de processus formulant des requêtes au serveur d'identification. Or mettre en place une connexion au serveur d'identification est un processus très coûteux, surtout si le système utilise un chiffrement (comme il se doit !)
SSSD se comporte de manière légèrement différentes. Nous utilisons encore les greffons NSS au sein du processus, mais au lieu de communiquer directement avec le serveur d'identification distant, nous envoyons la requête à SSSD qui fait une série de choses.
Premièrement, il vérifie si il existe une entrée récente dans le cache pour l'utilisateur ou groupe demandé. Si cette entrée existe et n'est pas périmée (configurable), il renvoi immédiatement le résultat sans consulter le serveur. Cette mise en cache permet d'accélérer significativement les requêtes utilisateurs, du fait que les requêtes locales sont beaucoup plus rapides que de consulter un serveur distant. Si l'entrée du cache n'existe pas ou est périmée, SSSD utilise un connexion unique pour contacter le serveur distant. Ainsi, au lieu que chaque processus sur la machine cliente ouvre sa propre connexion sur le serveur distant, il n'y a plus qu'une seule et unique connexion par machine. Cela réduit la consommation des ressources sur le serveur d'identification.
En terme d'authentification, les administrateurs auront aussi la possibilité de configurer SSSD de façon à ce que les utilisateurs ne puissent se connecter à l'aide des autorisations mises en cache que pour une période donnée. L'idée derrière est de s'assurer que le portable doive se connecter régulièrement au réseau d'entreprise afin de continuer d'autoriser l'accès. Lors des connexions avec les autorisations mises en cache, l'utilisateur verra alors un message lui indiquant combien de jours il lui reste avant qu'il ne puisse plus se connecter hors du réseau d'entreprise.
Une autre fonctionnalité qui pourrait aider les administrateurs est la possibilité de configurer plusieurs domaines dans SSSD. Avec le traditionnel nss_ldap, il n'était possible de formuler une requête qu'à partir d'un unique domaine LDAP. Avec SSSD, on pourra configurer autant de domaines d'identifications que l'on veut, à condition que les étendues d'identifiants utilisateurs/groupes ne se recouvrent pas.
On prévoit prochainement d'autres fonctionnalités impliquant un contrôle centralisé plus avancé avec FreeIPA. L'une des plus attendues est la fonctionnalité HBAC (Contrôle d'Accès Basé sur l'Hôte), permettant à un administrateur d'un serveur FreeIPA v2 de configurer des groupes d'hôtes et contrôler les horaires d'accès pour des groupes d'utilisateurs. Par exemple, il sera possible à un administrateur dont la société ayant une politique horaire stricte, de restreindre l'accès au machines en dehors des horaires prévus à cet effet.
Bon, changeons de sujet pour un moment, et considèrons que je sois à la place de cet administrateur système. Quels sont les types d'authentification et serveurs d'identification pris en charge par SSSD ? Peux-tu m'en dire quelques mots ?
À l'heure où je te parle, SSSD prends en charge LDAP pour l'identification, et LDAP ou Kerberos pour l'authentification. Nous avons aussi une fonctionnalité moins bien supportée que nous appelons le dorsal 'proxy' qui permet à un administrateur d'enrober nos fonctionnalités de cache autour un greffon NSS existant (comme nss_nis).
Pour bénéficier de tout les avantages de SSSD, tu voudras certainement que ton réseau utilise LDAP pour l'identification, et Kerberos pour l'authentification et sso.
Dans SSSD 1.2, nous permettrons d'utiliser SSSD comme un client à part entière de FreeIPA v2, mais ce dernier est encore à un stade alpha. Cela prendra du temps, afin d'être déployable.
Par quel processus un administrateur système doit passer pour intégrer SSSD à son environnement ?
Sur Fedora, presque rien :) C'est un des points forts de Fedora, car c'est clairement le meilleur environnement pour travailler avec SSSD. Avec Fedora 13, authconfig 6.1.3 est capable de configurer SSSD grâce à une interface utilisateur rénovée et simplifiée par rapport aux versions précédentes.
La manière recommandée à ce jour pour les administrateurs est de prototyper leur configuration SSSD à l'aide d'authconfig puis de paramètrer plus finement la configuration si besoin est.
Un autre avantage majeur comparé à l'approche NSS et PAM traditionnelle est la disponibilité d'un unique fichier de configuration pour toute la configuration. Le fichier /etc/sssd/sssd.conf centralise tout ça.
Une fois que l'administrateur a un sssd.conf aux petits oignons, tout ce qu'ils ont à faire est de le distribuer aux clients, puis de lancer 'authconfig --enablesssd --enablesssdauth --update' et authconfig s'occupe du reste pour eux, configurant /etc/nssswitch.conf et /etc/pam/* files si nécessaire.
Sur Fedora, on ne peut pas faire plus simple. Nous avons fait de grands efforts pour rendre ceci le plus facile possible. J'aimerais publiquement remercier Tomas Mraz (authconfig) et Máirín Duffy (conception de l'expérience utilisateur) pour leur dur labeur afin de rendre la nouvelle interface utilisateur la plus ergonomique possible.
J'ai vu que SSSD a eu droit à une journée de tests en Mars. Peux-tu nous dire comment cela c'est passé ? Quels ont été les problèmes résolus à l'aide des efforts conjugués des nombreux testeurs de la communauté ?
Ça s'est très bien passé. Nous avons été surpris de voir que SSSD comportait très peu de bogues lui-même. La plupart des problèmes rencontrés provenaient de l'interface utilisateur d'authconfig (qui ont été corrigés depuis). Le vrai bénéfice de cette journée de tests a été de tester une grande variété de déploiements. Nous avons eu plaisir à voir que nous répondions aux besoins de la majorité des testeurs.
C'est ainsi que les bons logiciels sont écrits, il ne suffit pas d'avoir des développeurs malins, il faut avoir des personnes qui sont intéressées par ce que vous faites et vous aident à finir le dernier kilomètre.
Qui d'autre travaille sur SSSD ? Recevez vous des contributions d'autres personnes ?
Pour le moment, la majorité du code écrite pour SSSD provient de Sumit Bose, Simo Sorce, Jakub Hrozek et moi-même à Red Hat. Cependant nous avons reçu des patchs provenant de Fedora ARM, SuSE et Ubuntu (par ordre décroissant de contribution)
Peux-tu me dire où trouver des informations sur SSSD ? Avez-vous un wiki, une documentation, une liste de diffusion ou autre pour en savoir plus à propos de SSSD ?
Nous avons une page wiki et un bugtracker disponible sur https://fedorahosted.org/sssd . Le bugtracker est l'endroit où il est le plus facile de suivre nos développements. Nous créons de temps à autres une page wiki pour expliquer nos choix de conceptions et suivre les discussions annexes et conserver les références.
Notre liste de diffusion dédiée au développement est sssd-devel@lists.fedorahosted.org (https://fedorahosted.org/mailman/listinfo/sssd-devel). C'est une liste avec un trafic moyen. Si vous doutez un jour que nous ne travaillons pas d'arrache-pieds sur la prochaine version, venez passez deux jours en semaine sur cette liste. :)
On peut nous trouver la plupart du temps sur le canal #freeipa (réseau irc.freenode.net). C'est probablement le meilleur endroit pour discuter avec nous.