Avec des centaines de serveurs RHEL, comment pouvons-nous maintenir des comptes root locaux et des comptes d'utilisateurs réseau? Existe-t-il une solution de type Active Directory qui les gère depuis un emplacement central?
Avec des centaines de serveurs RHEL, comment pouvons-nous maintenir des comptes root locaux et des comptes d'utilisateurs réseau? Existe-t-il une solution de type Active Directory qui les gère depuis un emplacement central?
Réponses:
LDAP est un composant central d’Active Directory, disponible sous Linux sous la forme OpenLDAP et 389DS (et quelques autres). En outre, l’autre composant principal Kerberos est disponible sous la forme de MIT Kerberos et Heimdal . Enfin, vous pouvez même connecter vos machines à AD.
sudoersappliquer des règles (ou les deux).
Vous pouvez essayer avec puppet pour gérer un utilisateur:
Pourquoi utiliser Puppet pour gérer les comptes d'utilisateurs? (et non NIS, LDAP, etc.)
L'un des avantages de la gestion des comptes d'utilisateurs dans puppet est le fait qu'il est décentralisé. Chaque compte d'utilisateur est simplement un compte d'utilisateur normal sur le serveur géré. Les comptes d'utilisateurs que marionnette crée n'ont rien de spécial en dehors du fait qu'ils ont été créés par marionnette et non par un administrateur humain. La bonne chose à propos de cela est que si l'hôte principal meurt, nous ne perdons pas l'authentification. Ce qui signifie que notre serveur puppetmaster (ou serveur NIS / LDAP) n’a pas besoin de conditions de disponibilité particulières. En cas d'urgence, nous pouvons nous concentrer sur la mise en route de nos serveurs de production et sur la mise en place du maître de marionnettes au besoin. L’inconvénient est que marionnette n’est pas nécessairement conçue pour gérer des comptes d’utilisateur «normaux» (par opposition à des comptes système). La plus grande façon dont cela se présente est que, bien que vous puissiez définir le mot de passe dans puppet, celui-ci surveille en permanence les paramètres système (bon) et le réinitialisera s'il constate que le mot de passe a changé. (mauvais) Je ne souhaite pas contrôler les mots de passe des utilisateurs sur notre réseau. Il doit donc 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 vraiment très facile. Mais d’abord, voyons quelques définitions.
Comme SvenW le mentionne, il existe 389DS et Kerberos. Depuis RHEL 6.2, Red Hat a inclus IPA dans la distribution (et donc dans CentOS également). Il s'agit d'une suite complète de gestion des identités intégrant 389DS et Kerberos, avec un contrôle basé sur des stratégies d'authentification et d'autorisation, et éventuellement DNS. Il peut même être configuré pour une synchronisation unidirectionnelle ou bidirectionnelle avec Active Directory.
IPA nécessite à peu près SSSD sur les hôtes RHEL, mais cela fonctionne sans. J'ai même testé la connexion de Solaris 10 à IPA (fonctionne, mais un peu délicat). IPA est assez simple à configurer pour les hôtes RHEL.
Ceci est basé sur le projet FreeIPA .
Pour les comptes utilisateur de votre réseau, OpenLDAP comme SvW est mentionné.
Vous devez également consulter "Systèmes de gestion de la configuration" pour gérer vos comptes locaux et tout le reste sur vos serveurs. Jetez un coup d'œil à CFEngine, Bcfg2, Puppet et Chef. Si vous utilisez AWS, ils ont un problème avec Chefy avec OpsWorks.
Si vous avez vraiment besoin de gérer plus de 100 serveurs, vous avez soit 10 administrateurs système, soit vous utilisez le logiciel Configuration Management.
Cela peut être une réponse évidente, mais utilisez "annuaire actif". Vous devez modifier un peu notre schéma AD afin d'inclure des champs spécifiques à Unix, mais une fois que vous le faites, vous disposez d'un répertoire unique de tous vos comptes d'utilisateur qui fonctionne sur plusieurs plates-formes.
Peut-être moins utile si vous êtes un magasin Unix uniquement - mais je n'en ai pas vu beaucoup. Mais AD constitue en réalité un assez bon maillage des éléments clés de LDAP et de Kerberos. Je trouve ce bit ironique en fait.
Mais ce que vous obtiendrez «gratuitement», ce sont des comptes multiplateformes et une intégration Kerberos afin que vous puissiez exporter NFSv4 en appliquant des ACL "reconnues CIFS" et des montages NFS krb5i / p, avec une authentification forte des utilisateurs.