Debian et LDAP pour sudo

Le sudo moderne a la capacité d'utiliser ldap. À mon avis, cette méthode est maladroite et susceptible d'échouer, mais il ne s'agit que de mon expérience. http://www.gratisoft.us/sudo/readme_ldap.html

Je préfère nettement utiliser netgroups pour étendre les configurations sudo locales plutôt que de m'appuyer complètement sur ldap. Ma règle de base est la suivante : si c'est nécessaire pour faire fonctionner le serveur, cela doit être local. Seuls les comptes d'utilisateurs non vitaux, etc. vont dans ldap/nis/quelque chose.

Je ne pense pas que ce soit un risque d'échec puisque vous pouvez avoir un fichier sudoers de sauvegarde local, donc même si votre serveur LDAP est en panne, vous pouvez toujours utiliser SUDO sur celui-ci pour le maintenir et pour que les administrateurs puissent restaurer la connexion au serveur LDAP.

C'est très simple à faire, et vous préférerez avoir un fichier sudoers centralisé plutôt que de nombreux sudoers locaux lorsque vous aurez quelque chose comme plus de 100 serveurs à gérer.

En outre, regardez ceci, extrait du site web sudo :

L'utilisation de LDAP pour les sudoers présente plusieurs avantages :

• Sudo n'a plus besoin de lire sudoers dans son intégralité. Lorsque LDAP est utilisé, il n'y a que deux ou trois requêtes LDAP par invocation. Cela le rend particulièrement rapide et particulièrement utilisable dans les environnements LDAP.

• Sudo ne se termine plus s'il y a une faute de frappe dans sudoers. Il n'est pas possible de charger dans le serveur des données LDAP qui ne sont pas conformes au schéma sudoers, de sorte que la syntaxe correcte est garantie. Il est toujours possible d'avoir des fautes de frappe dans un nom d'utilisateur ou d'hôte, mais cela n'empêchera pas l'exécution de sudo.

• Il est possible de spécifier des options par entrée qui remplacent les options globales par défaut. Le fichier /etc/sudoers ne prend en charge que les options par défaut et les options limitées associées à user/host/commands/aliases. La syntaxe est compliquée et peut être difficile à comprendre pour les utilisateurs. Placer les options directement dans l'entrée est plus naturel.

• Le programme visudo n'est plus nécessaire. visudo assure le verrouillage et le contrôle syntaxique du fichier /etc/sudoers. Comme les mises à jour LDAP sont atomiques, le verrouillage n'est plus nécessaire. Comme la syntaxe est vérifiée lors de l'insertion des données dans LDAP, il n'est pas nécessaire d'utiliser un outil spécialisé pour vérifier la syntaxe.

J'ai pu compiler sudo avec l'option --with-ldap qui lui permet d'utiliser un répertoire LDAP. sudo source est livré avec un schéma qui peut être chargé dans LDAP et lui permettre d'utiliser le répertoire au lieu de /etc/sudoers

Je suppose que vous voulez dire que sudo devrait utiliser ldap ;)

La façon la plus simple de procéder est d'accorder sudo à un groupe via /etc/sudoers, puis de contrôler les membres de ce groupe via ldap.

Nous avons essayé de mettre les sudoers dans ldap, mais nous avons trouvé que le moyen le plus simple de gérer les sudo (et les contrôles d'accès) était de combiner l'appartenance à un groupe ldap avec un outil de gestion de configuration centralisé qui pourrait pousser les fichiers acl et sudoers vers un serveur ou des groupes de serveurs.

Nous utilisons pam_access pour contrôler l'accès aux serveurs, et Puppet pour distribuer les fichiers et appliquer les acls, mais il existe d'autres outils de gestion de la configuration comme cfengine qui pourraient également fonctionner.