Comment les administrateurs gèrent-ils les comptes d'utilisateurs sur des centaines de serveurs Linux?

Vous pouvez essayer avec Puppet pour gérer les utilisateurs :

Pourquoi utiliser Puppet pour gérer les comptes d'utilisateurs? (et non NIS, LDAP, etc)

Un des avantages de la gestion des comptes d'utilisateurs avec Puppet est le fait qu'elle soit décentralisée. Chaque compte utilisateur est simplement un compte utilisateur normal sur le serveur géré. Il n'y a rien de spécial concernant les comptes utilisateurs créés par Puppet, si ce n'est qu'ils ont été créés par Puppet et non par un administrateur humain. Ce qui est agréable à ce sujet, c'est que si l'hôte principal tombe en panne, nous ne perdons pas l'authentification. Cela signifie que notre serveur principal Puppetmaster (ou serveur NIS/LDAP) n'a pas besoin d'avoir des exigences de disponibilité spéciales. En cas d'urgence, nous pouvons nous concentrer sur la remise en service de nos serveurs de production, et nous focaliser sur la relève du Puppetmaster sur une base "au besoin". Le revers de la médaille est que Puppet n'est pas vraiment conçu pour gérer les comptes d'utilisateurs de connexion "normaux" (par opposition aux comptes système). La principale problématique est que, bien que vous puissiez définir le mot de passe dans Puppet, Puppet surveille continuellement les paramètres du système (bien) et s'il remarque que le mot de passe a été modifié, il le réinitialisera (mal). Je ne veux pas surveiller les mots de passe des utilisateurs sur notre réseau, donc il doit exister un moyen de définir un mot de passe et de faire en sorte que Puppet cesse de surveiller ce mot de passe. Heureusement, une fois que vous avez compris le truc, c'est en fait assez facile. Mais d'abord, clarifions quelques définitions.

http://docs.puppetlabs.com/pe/2.5/console_auth.html

Comme le mentionne SvenW, il y a 389DS et Kerberos. Depuis RHEL 6.2, Red Hat a inclus IPA dans la distribution (et donc elle est aussi dans CentOS). Il s'agit d'une suite complète de gestion des identités qui intègre 389DS et Kerberos, avec un contrôle basé sur des politiques pour l'authentification et l'autorisation, et éventuellement DNS. Il peut même être configuré pour une synchronisation à sens unique ou à double sens avec Active Directory.

IPA nécessite pratiquement SSSD sur les hôtes RHEL, mais elle fonctionne sans. J'ai même testé la connexion de Solaris 10 à IPA (ça fonctionne, mais c'est un peu compliqué). IPA est assez simple à configurer pour les hôtes RHEL.

Ceci est basé sur le projet FreeIPA.

Pour vos comptes d'utilisateur réseau, utilisez OpenLDAP comme SvW l'a mentionné.

Vous devriez aussi envisager des "Systèmes de Gestion de Configuration" pour gérer vos comptes locaux et tout le reste sur vos serveurs. Jetez un œil à CFEngine, Bcfg2, Puppet et Chef. Si vous utilisez AWS, ils ont une sorte de truc Chefy avec OpsWorks.

Si vous avez vraiment besoin de gérer plus de 100 serveurs, soit vous avez 10 administrateurs système ou vous utilisez un logiciel de gestion de configuration.

Cela peut sembler une réponse évidente, mais 'utilisez l'annuaire actif'. Vous devez modifier un peu notre schéma AD, pour inclure des champs spécifiques à Unix, mais une fois que vous le faites, vous avez un seul répertoire de tous vos comptes d'utilisateurs qui fonctionne sur plusieurs plateformes.

Peut-être moins utile si vous ne travaillez qu'avec Unix - mais je n'en ai en fait pas vu beaucoup. Mais AD est en fait une assez bonne combinaison des éléments clés de LDAP et Kerberos. Je trouve cela un peu ironique en fait.

Mais ce que vous obtiendrez 'gratuitement' ce sont des comptes multiplateformes, et une intégration Kerberos pour que vous puissiez faire des exportations NFSv4 en appliquant des ACL 'reconnus par CIFS', et des montages NFS krb5i/p, avec une authentication utilisateur forte(r).