Image of an arrow

Comment aborder la gestion d’identité pour les grands parcs serveur?

Datacenter (photo)

Photo: Leonardo Rizzi (CC BY-SA)

Certains de nos clients ont des parcs de serveurs importants — 100, 400, voire 2000 et plus — et on ne gère pas 100 machines comme on en gère 10. Des outils de gestion de configuration existent depuis longtemps pour industrialiser la création et la gestion de ces parcs: CFEngine, Puppet, Chef, etc. Ces solutions fonctionnent bien pour les installations homogènes des systèmes d’exploitation et des applications, mais elles répondent moins bien à cette triple problématique :
1. Comment gérer et modifier rapidement
2. qui a le droit de faire quoi
3. et sur quelle machine?

Pour résoudre ce problème, on ne passe pas par des outils de gestion de configuration. On va plutôt unifier la gestion des identités autour d’un référentiel et y connecter les machines UNIX.

Active Directory

Souvent, la gestion des identités va être centralisée dans Active Directory, le service d’annuaire de Microsoft. Le monde Unix ne parlant pas nativement avec Windows, on va cependant utiliser des scripts et un outil de gestion de configuration pour pousser différentes informations de Active Directory vers le parc Unix :

  • les utilisateurs et mots de passe
  • leur différents groupes d’appartenance
  • les droits d’accès aux machines
  • les règles sudo

Malheureusement, cette procédure est longue. Elle prend parfois une semaine et implique des opérations manuelles, comme l’écriture d’un bout de code dans Puppet afin de permettre l’ajout d’un utilisateur dans un groupe. Souvent, la demande doit être faite à l’équipe Windows et à l’équipe Linux, les deux étant des entités séparées. Plusieurs outils peuvent nous aider dans cette tâche.

LDAP / Winbind

Jusqu’à récemment, on utilisait une connexion LDAP vers Active Directory; ou Winbind, sous Linux, qui offre l’avantage de joindre la machine au domaine Windows et de ne pas laisser traîner un mot de passe en clair sur les machines Linux:

winbind

Avantage :

  • Cette solution, qui existe depuis longtemps, est disponible sur toutes les distributions Linux.

Inconvénients :

  • Pas de caching, beaucoup de requêtes.
  • Nécessite de payer une licence d’accès client Windows pour chaque machine Linux.
  • Les règles sudo ne sont pas centralisées, il faut donc peupler le fichier sudoers par un autre mécanisme (par exemple, avec Puppet).
  • On ne peut pas automatiser complètement l’intégration d’une nouvelle machine dans le domaine; à un moment donné, il faut faire un net ads join et rentrer le mot de passe administrateur.

SSSD/Redhat IdM

Depuis quelques années, Redhat travaille sur deux projets : SSSD (System Security Services Daemon), et FreeIPA / Red Hat IdM.

SSSD

SSSD permet de remplacer Winbind avec une solution plus élégante et dédiée à la gestion d’identité (alors que Winbind est surtout un composant de Samba).

sssd-ad


Avantages :

  • Il y a plusieurs type de connecteurs: en mode natif pour Active Directory ou par LDAP pour FreeIPA/Red Hat IdM.
  • On peut cacher les informations afin de travailler en mode déconnecté, mais aussi pour réduire les latences et la charge sur le serveur d’identification.
  • SSSD est beaucoup plus simple à debugger que Winbind.

Inconvénients :

  • Cette solution existe depuis moins longtemps. L’intégration complète avec un Active Directory existe depuis SSSD 1.9 (fourni avec RHEL6.4+). On peut toutefois intégrer des clients RHEL5 et RHEL6.
  • Elle nécessite de payer une licence d’accès client Windows pour chaque machine Linux, si l’on opte pour une intégration native (c’est à dire pas LDAP).
  • Bien que cela soit possible, les règles sudo ne peuvent pas être centralisées facilement. Il faut donc souvent peupler le fichier sudoers par un autre mécanisme (notamment avec Puppet).
  • On ne peut pas automatiser complètement l’intégration d’une nouvelle machine dans le domaine (à un moment donné, il faut faire un net ads join  et rentrer le mot de passe administrateur).

Red Hat IdM

Le deuxième (FreeIPA / Red Hat IdM) permet de créer un domaine Linux (comme on crée un domaine Windows) et d’en gérer non seulement les identités, mais aussi les règles HBAC (Host Based Access Control) et les règles sudo. Enfin, on peut faire une relation d’approbation entre un domaine Red Hat IdM et un domaine Windows et, donc, centraliser les utilisateurs dans un domaine Active Directory tout en centralisant les règles sudo, HBAC et les groupes de ces utilisateurs dans un domaine Red Hat IdM.

sssd-adtrust

Avantages :

  • On peut cacher les informations, pour travailler en mode déconnecté, mais aussi pour réduire les latences et la charge sur le serveur d’identification
  • Il suffit de deux à trois serveurs IdM pour gérer un parc de 3 000 serveurs.
  • On peut faire une relation d’approbation entre un domaine IdM et un domaine Windows, et donc ne pas avoir à payer une licence d’accès client Windows pour chaque machine Linux
  • Les règles sudo et HBAC sont centralisées dans FreeIPA/Red Hat IdM
  • On peut automatiser l’intégration d’une nouvelle machine dans le domaine
  • SSSD et Red Hat IdM sont beaucoup plus simples à déboguer que Winbind

Inconvénient:

  • Cette solution existe depuis moins longtemps et l’intégration complète avec un Active Directory n’existe que depuis SSSD 1.9, fourni avec RHEL6.4+. On peut toutefois intégrer des clients RHEL 5 et 6

Installation typique

SSSD et Red Hat IdM, sont des outils simples et facile à mettre en place (voir l’exemple très simple ci-dessous). La question centrale est souvent : comment attribuer les UID/GID aux utilisateurs Windows? Pour cela, il y a plein d’options (qui sont en dehors du périmètre de ce billet).

Installation typique d’un serveur IdM

– Installer un RHEL7

vi /etc/hostname # pour le mettre fully qualified
vi /etc/hosts # pour mettre mon nom de machine
# yum upgrade -y
yum remove firewalld
yum install ipa-server ipa-server-trust-ad bind bind-dyndb-ldap -y
# vi /etc/sysconfig/network-scripts/ifcfg-eth0 # pour mettre l'adresse en statique et ONBOOT=yes
ipa-server-install --setup-dns
ipa-adtrust-install --enable-compat --netbios-name=DOMAINELINUX
ipa dnszone-add domainewindows.lan --name-server=dc.domainewindows.lan --admin-email='nicolas.zin@savoirfairelinux.com' --force --forwarder= --forward-policy=only --ip-address=

# sous windows:
# C:> dnscmd 127.0.0.1 /RecordAdd ad_domain serveur.DOMAINELINUX A
# C:> dnscmd 127.0.0.1 /RecordAdd ad_domain DOMAINELINUX NS serveur.DOMAINELINUX

ipa trust-add --type=ad domainewindows.lan --admin Administrator --password
# si SFU: --range-type=ipa-ad-trust

ipa trust-fetch-domains "domainewindows.lan"
ipa trustdomain-find "domainewindows.lan"

vi /etc/krb5.conf
# auth_to_local = RULE:[1:$1@$0]Installation typique d'un serveur IDM(^.*@DOMAINEWINDOWS.LAN$)s/@DOMAINEWINDOWS.LAN/@domainewindows.lan/
# auth_to_local = DEFAULT
service krb5kdc restart
service sssd restart

# configure sudo pour les RHEL5 (http://blog.delouw.ch/2013/07/25/centrally-manage-sudoers-rules-with-ipa-part-i-preparation/)
ldappasswd -x -S -W -h localhost -ZZ -D "cn=Administrator" uid=sudo,cn=sysaccounts,cn=etc,dc=domainelinux,dc=lan
echo sudoers: files sss >> /etc/nsswitch.conf
sed -i -e 's/services =.*/services = nss, pam, ssh, sudo/' /etc/sssd/sssd.conf
service sssd restart

Installation typique d’un client IdM RHEL6.4+

L’installation d’un client est TRÈS simple :

echo " 192.168.10.1 .domainelinux.lan" >> /etc/hosts
vi /etc/resolv.conf # pour mettre les serveurs Idm
yum install ipa-client
ipa-client-install --hostname=.domainelinux.lan --mkhomedir
sed -i -e 's/HOSTNAME=.*/HOSTNAME=/' /etc/sysconfig/network
hostname
# verifier que sudo est bon dans /etc/nsswitch.conf

chkconfig sssd on
service sssd start

À partir de là, la machine fait partie du domaine Linux et peut être jointe par des utilisateurs Windows.

Connexion des utilisateurs Windows

Lors de la configuration du serveur IdM, on a créé une relation d’approbation entre notre domaine IdM et notre Active Directory. Du coup, les utilisateurs Active Directory peuvent se connecter à nos machines Linux en utilisant leur nom complet :

ssh <machine> -l <utilisateur>@domainewindows.lan

Note: Afin d’éviter que les utilisateurs rentrent à chaque fois leur nom complet, il y a moyen de dire à IdM que le domaine par défaut est domainewindows.lan .

Interface web de gestion

Une fois le domaine installé, il y a moyen de gérer les utilisateurs, les groupes et les règles sudo et HBAC par une interface web :

free-ipa.web

On peut également (et surtout!) effectuer ces opérations en ligne de commande, avec la commande ipa. Tout ce que l’on trouve dans l’interface est scriptable et aussi disponible sous forme de web service. Malheureusement, la documentation à ce sujet est très lacunaire.

Conclusion

L’installation d’un parc complet est toujours un peu plus longue et détaillée que ce qui est présenté ici, mais ce billet en donne un bon aperçu. Bien entendu, chaque cas est unique. Certains préfèrent avoir des machines Linux connectées à un Active Directory, d’autres optent pour la mise en place d’un domaine, avec une relation d’approbation évitant que les utilisateurs doivent entrer à chaque fois leur nom complet. On devra alors se poser la question de la mise en correspondance (« mapping ») des UID/GID des utilisateurs Windows dans le monde Linux ; il y a plusieurs options pour ça, surtout si l’on veut mettre en place des serveurs Samba.

Bref, il y a moyen aujourd’hui de centraliser la gestion des identités — ainsi que les règles sudo et HBAC — de façon à réduire le temps entre une demande de changement et son application sur un parc hétérogène, d’une semaine à quelques heures, ce qui est non négligeable. Une bonne planification est nécessaire et il faut pour cela disposer aussi d’un parc de serveurs relativement homogène.
Comment aborder la gestion d’identité pour les grands parcs serveur?


Articles similaires

Image of an arrow

La LDAPCon est une conférence internationale autour de la technologie LDAP et des enjeux de gestion des identités, d’authentification et d’habilitation. L’événement qui se déroulera cette année à Bruxelles du 19 au 20 octobre, se tient tous les deux ans dans un pays différent : 2007 à Cologne en Allemagne 2009 à Portland aux États-Unis […]

Savez-vous comment automatiser l’installation ainsi que la configuration de Nexus Repository Manager version 3.x avec Ansible ? Pas encore ? On vous donne un coup de pouce ici ! Pour rappel, Ansible est un outil de déploiement qui permet à des playbooks d’automatiser les déploiements d’applications et d’infrastructure. L’avantage clé d’Ansible est sa flexibilité puisqu’il […]

         Nous sommes heureux de vous annoncer la sortie d’une vidéo promotionnelle produite par Microsoft eux-même ! Fruit d’une collaboration autour de la plateforme Azure, cette vidéo souligne la pertinence et l’essor des technologies open source dans l’environnement infonuagique Azure de Microsoft ainsi que notre capacité d’innovation en combinant technologies open source […]

Thumbnail image

L’authentification unique (en anglais Single Sign On ou SSO) est aujourd’hui bien implantée dans les systèmes d’information, grâce à une large offre de produits et surtout de nombreux standards comme CAS, SAML ou OpenID Connect, pour ne citer que les plus importants. Cependant, ce domaine reste difficile d’accès car chaque nouvelle norme demande un temps […]

Thumbnail image

La Ville de Villeurbanne mise sur l’Open Source et choisit LemonLDAP::NG pour contrôler les droits d’accès de ses utilisateurs. La Ville de Villeurbanne possédait plusieurs applications Web dont l’authentification était déjà déléguée à un serveur central CAS (Central Authentification Services), modifié pour les besoins de Villeurbanne pour donner accès à la fois aux utilisateurs internes […]