Gestion des informations d'identification du serveur pour Linux et Windows

Nous sommes une boutique relativement petite (en ce qui concerne le nombre d'administrateurs système) avec un mélange de serveurs RHEL, Solaris, Windows 2003 et Windows 2008; environ 200 serveurs en tout.

Pour nos comptes d'administrateur ( rootsous Linux et admnistratorsous Windows), nous avons un schéma de mot de passe qui dépend de l'emplacement du centre de données et de quelques autres propriétés documentées du serveur.

Sous Linux, notre pratique actuelle consiste à créer un compte partagé non privilégié où nous pourrions le sufaire root. Sur les systèmes Windows, nous créons un compte supplémentaire avec des privilèges d'administrateur. Ces deux comptes partagent le même mot de passe.

Cela s'est révélé très inefficace. Lorsque quelqu'un quitte notre boutique, nous devons:

1. Modifier le schéma de mot de passe pour les comptes d'administrateur
2. Générez un nouveau mot de passe administrateur pour chaque serveur
3. Trouvez un nouveau mot de passe de compte non administrateur
4. Touchez chaque serveur et changez les mots de passe

Je voulais savoir si quelqu'un dans un environnement similaire pouvait suggérer une manière plus saine de gérer ces informations d'identification. Quelques informations pertinentes:

• Bien que la plupart de nos serveurs fassent partie de notre domaine AD, tous ne le sont pas.
• Nous gérons tous nos serveurs Linux avec Puppet (l'authentification par clé était une option à laquelle j'ai pensé, mais elle ne répondra qu'à la préoccupation n ° 3 ci-dessus).
• Nous fournissons des serveurs Linux avec Cobbler.
• Environ 10% de notre matériel est dédié à VMWare. Dans ces cas, nous utilisons des modèles VMWare pour les versions de serveur.

Toutes les idées ou suggestions seront grandement appréciées. C'est un problème qui persiste depuis un certain temps et je veux enfin le résoudre.

Voici quelques suggestions que j'aurais:

• Les serveurs connectés à Windows AD peuvent avoir leurs mots de passe d'administrateur local définis via la stratégie de groupe à l'aide des préférences de stratégie de groupe (GPP) ou d'un script de démarrage de l'ordinateur. Voir http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/b1e94909-bb0b-4e10-83a0-cd7812dfe073/

• Limitez la création de comptes locaux sur les serveurs Windows, sauf si requis. Utilisez des comptes AD lorsque cela est possible.

• Utilisez LDAP pour un ordinateur Linux pour authentifier les comptes d'administrateur auprès d'AD. Cela simplifie quelque peu la gestion des comptes. Et quand un administrateur a simplement désactivé en un seul endroit et sans accès, vous pouvez nettoyer le côté Linux à votre guise.

• Utilisez le fichier / etc / sudoers pour un compte administrateur spécifique sur linux, les administrateurs n'ont pas besoin du mot de passe root. Cela peut être bon dans votre cas, car ils auront rarement besoin du mot de passe root pour qu'il puisse être verrouillé. Mis à jour

• Conservez les mots de passe administrateur local et racine dans un mot de passe sûr et non de connaissances générales. Certains coffres-forts de mot de passe ont une délégation et une journalisation, vous n'aurez donc peut-être même pas besoin de réinitialiser un mot de passe si la personne n'y a jamais eu accès.

• Automatisez le processus de réinitialisation du mot de passe pour les comptes root et administrateur. Linux et Windows peuvent être scriptés pour cela, ce qui peut vous faire gagner du temps et ne pas en faire un fardeau.

J'espère que cela pourra aider.

Vous pouvez essayer de voir si FreeIPA fonctionne pour vous.

Vous pouvez gérer l'accès des utilisateurs aux hôtes à partir d'un emplacement central. Comme suggéré par d'autres, vous pouvez voir si sudo fonctionne pour vous pour un accès au niveau racine. Freeipa prend en charge les sudoers dans LDAP, vous n'avez donc pas à le maintenir sur chaque serveur ou via une marionnette, etc.

Freeipa prend en charge les clients Linux, Solaris et Windows. Vous pouvez perdre certaines fonctionnalités AD et je ne sais pas quelles autres limitations un client Windows aura.

Il a des fonctionnalités de réplication, vous pouvez donc éviter un SPOF. Le backend est LDAP, vous pouvez donc éventuellement réutiliser de nombreux outils que les gens utilisent pour LDAP, comme les scripts de sauvegarde.

Il prend en charge le contrôle d'accès basé sur l'hôte, vous pouvez donc dire "l'utilisateur X ne peut se connecter qu'aux serveurs Y".

Il offre également une synchronisation AD . Je ne suis pas une personne Windows, donc je n'ai aucune idée de ce que cela signifie.

N'utilisez pas le compte administrateur standard. Du côté de Windows, créez un compte utilisateur et un compte administrateur pour chaque utilisateur qui a besoin d'un accès administrateur. Vous pouvez utiliser n'importe quel outil pour synchroniser avec UNIX.

Si quelqu'un part, il vous suffit de supprimer ses comptes d'utilisateur et d'administrateur.

Pour sécuriser le compte administrateur standard, donnez-lui un mot de passe vraiment long et complexe, puis assurez-vous que chaque personne n'en a que la moitié. S'ils doivent utiliser l'intégralité du compte, ils doivent alors aller chercher quelqu'un qui a l'autre moitié.

C'est à peu près aussi sûr que je peux penser.