Question Contrôle d'accès à des centaines de boîtes LAMP via LDAP


C'est le cauchemar de tous les projets de SysAdmin. En gros, nous voulons contrôler qui a accès à quels hôtes. Aussi simple que cela puisse paraître, le problème est de trouver une solution évolutive et nécessitant peu d’entretien (coûts de gestion). Nous utilisons bcfg2 pour Config Mgmt un peu comme Cfengine & puppet.

Quelques façons:

  1. Netgroups est très évolutif mais vient avec un énorme surcoût de gestion. La maintenance des hôtes, des groupes d’hôtes et des groupes de réseaux d’utilisateurs (distincts des groupes ldpa) semble être un très gros fardeau, mais elle est réalisable.

  2. ldap.conf (rendez-vous à jmozdzen le 1er juillet) et contrôle d’accès basé sur LDAp. Nous pourrions modéliser le fichier ldap.conf pour chaque hôte et créer un groupe avec nom d’hôte et membres en tant qu’utilisateurs. Mais l'inconvénient est que vous ne pouvez pas spécifier un groupe d'accès (groupe d'utilisateurs), mais uniquement individuellement.

  3. restriction sshd_config. Mais cela ne fonctionne pas si les utilisateurs se connectent de manière native.

  4. Vérification d'attribut d'hôte. En supprimant les commentaires sur pam_check_host_attr dans ldap.conf et en ajoutant le nom d’hôte à chaque utilisateur, cela fonctionne bien, mais l’automatisation n’est pas simple.

Quelqu'un a une approche différente de ce problème et cela évolue bien et automatisé?


5
2017-07-13 17:27


origine




Réponses:


J'utilise quelque chose de similaire à votre "Option 2" - une configuration LDAP (pam_ldap / nss_ldap) où chaque classe de serveur a un groupe dans LDAP (db, web, etc.), et les membres de ce groupe sont autorisés à se connecter. à cette classe de serveur. C’est à peu près la même chose que les netgroups, mais cela fonctionne bien car nos listes d’utilisateurs sont relativement statiques (vous avez accès à une liste de machines, et cet accès est pratiquement permanent).

Nous n'autorisons pas les connexions à la console pour les utilisateurs LDAP (seuls les comptes de service d'urgence et racine peuvent se connecter localement, et ces mots de passe sont soigneusement gardés). Par conséquent, les restrictions spécifiques à LDAP ne doivent être appliquées à sshd dans notre cas.


3
2017-07-13 17:52



+1: Vous pouvez utiliser LDAP + PAM pour contrôler l'accès. OpenSSH peut également utiliser PAM. - Stefan Lasiewski
Merci, pouvez-vous publier le schéma pour hostclass dans LDAP et quel attribut utilisez-vous pour membre du groupe? (J'ai uniquememeber). - Prashanth Sundaram
Il n'y a pas de schéma pour "classe d'hôte" - c'est une construction logique / administrative. Notre structure LDAP définit une unité d'organisation appelée LoginACL, avec une sous-unité d'organisation pour chaque site et des entités groupOfUniqueNames dans chaque site pour chaque "classe de serveur". Le contrôle d'accès est imposé par pam_ldap pam_groupdn directive (nous utilisons uniquemember en tant qu'attribut d'appartenance) Les utilisateurs et les groupes sont globaux dans mon cas: ce n'est pas parce que vous ne pouvez pas vous connecter que vous ne devez pas exister (vous pouvez posséder des fichiers à cause d'un montage NFS) - voretaq7
Nous avons également des classes de serveurs et leur utilisation réduirait considérablement le nombre de groupes à gérer. La logique est simple: les utilisateurs accédant à tous les hôtes de base de données sont identiques, à quelques exceptions près. Merci pour les commentaires. - Prashanth Sundaram
Les exceptions sont le seul véritable meurtrier ici: pour autant que je sache, il n’ya aucun moyen de créer un utilisateur unique comme dans NIS (je peux me tromper cependant, je n’ai pas trop cherché depuis que nous avons interdit les logiciels uniques. en tant que facteur de politique d'entreprise, je n'ai donc pas à supporter ce cas d'utilisation;) - voretaq7


Une autre approche intéressante est suggérée dans le module nssov d'OpenLDAP. Voir le LISEZMOI pour plus de détails.


0
2017-07-18 17:11



Est-ce que OpenLDAP / slapd est spécifique? J'utilise 389 Directory. D'après la [page d'accueil] [1], il s'agit d'une manière LDAP de rechercher des fichiers plats comme / etc / aliases, hôtes, etc. Regarder README ressemble à un Dn comme ceci 'cn = <service> + uid = <utilisateur> , cn = <nomhôte>, cn = pam, cn = auth 'et une correspondance d'expression régulière est recherchée. J'aime cette approche, mais on dirait qu'il s'agit d'un hamburger au bœuf double, savoureux mais difficile à digérer. L'implémentation de la recherche de fichiers à plat est beaucoup plus simple sans nslcd.conf. Utilisez simplement les outils de migration PADL et remplacez nsswitch.conf par ldap. Tout autre commentaire est le bienvenu. [1]: arthurdejong.org/nss-pam-ldapd - Prashanth Sundaram