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.
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 :
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.
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:
Avantage :
Inconvénients :
net ads join et rentrer le mot de passe administrateur.Depuis quelques années, Redhat travaille sur deux projets : SSSD (System Security Services Daemon), et FreeIPA / Red Hat IdM.
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).
Avantages :
Inconvénients :
net ads join et rentrer le mot de passe administrateur).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.
Avantages :
Inconvénient:
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).
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
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.
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 .
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 :
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.
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?
Pour aller plus loin techniquement, voici de très bons documents proposés par Red Hat:
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 […]
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 […]
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 […]
