[Authentification] Serveurs LINUX

Serveurs LINUX [Authentification] - Sécurité - Systèmes & Réseaux Pro

Marsh Posté le 08-01-2015 à 11:03:36    

Bonjour à tous (et bonne année).
 
Je rencontre un besoin très simple, sans doute déjà rencontré par beaucoup d'entre vous qui maîtrise/utilise ce type d'environnement.
 
J'ai une batterie de serveur LINUX pour lesquels je n'ai aucun compte nominatif (pour les administrateurs, il n'y a pas d'utilisateurs sur ces plateformes).
Je voudrais donc créer pour chacun des administrateurs et techniciens des comptes nominatifs en les forçant à utiliser des clés privées (avec mot de passe).
 
La ou je bloque c'est concernant le déploiement en masse, dans un environnement Windows j'utiliserais l'AD sans hésiter.
Est ce que pour un environnement LINUX, il faut aussi déployer un annuaire LDAP, se connecter sur un annuaire AD existant, répliquer simplement les comptes sur chaque machine ?
 
Je n'ai pas suffisamment d’expérience sur les environnements LINUX, je vous sollicite donc pour que nous puissions débattre des solutions et bonnes pratiques de chacun.
 
Merci par avance  :jap:  
 
Bonne journée :hello:


---------------
Mon topic : http://forum.hardware.fr/forum2.ph [...] =0&nojs=0]
Reply

Marsh Posté le 08-01-2015 à 11:03:36   

Reply

Marsh Posté le 08-01-2015 à 11:27:05    

Justement si tu as un compte distant, tu pourrais imaginer faire une copie par SSH de tes clés publiques de tes utilisateurs, si tu pars sur un système clé privée/clé publique [:spamatounet]  
Cela serait en outre moins lourd à mettre en place qu'une connection à l'AD en LDAP (AD étant un LDAP ;) ) et de gérer les droits après. Dans ton AD tu as tes utilisateurs et les administrateurs, et tous les administrateurs n'ont pas forcément besoin de se connecter à tous les serveurs.
 
Regardes par ici en exemple, sachant qu'à la suite tu pourras scripter l'envoie dans le langage de ton choix tant que ça gère du SSH.


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Reply

Marsh Posté le 08-01-2015 à 12:06:23    

Bonjour bardial et merci pour ton retour.
 
Je vais effectivement partir sur des clé privée/publique c'est une certitude.
 
En revanche, j'ai toujours créer des jeux de clé par rapport à des utilisateurs systèmes existant (dans /~/.ssh), avec cette solution il faudrait donc que je script la création des comptes puis l'ajout des clé SSH dans leur répertoire personnel.
 
Sans cela je n'aurais toujours pas de compte nominatif et donc de traçabilité clairement lisible sur les actions effectuées sur les systèmes.
 
Il y a t'il moyen par ailleurs de forcer le changement de mot de passe de l'authentification des clés privées tous les trois mois par exemple ?
 
 
 


---------------
Mon topic : http://forum.hardware.fr/forum2.ph [...] =0&nojs=0]
Reply

Marsh Posté le 08-01-2015 à 13:54:04    

Ben niveau création d'utilisateurs tu seras bien obligé de le faire, l'ajout de l'authentification par un système clé publique/clé privée n'est qu'une couche supplémentaire de sécurité.
Sachant que tu peux très bien aussi utiliser si ça t'enchante (ou si le besoin se faisait sentir) un système OTP (par ici côté serveur, sachant que le client peut être aussi FreeOTP pour un smartphone/tablette Android ou iOS).
 
Après tu as tant de monde que cela qui doit se connecter sur tes serveurs ?
Tous les admins et tous les techs doivent pouvoir se connecter sur tous les serveurs ?
 
Après tu pourrais utiliser un système comme Puppet pour s'occuper des utilisateurs par exemple :

Citation :

# Add "admin" account
user { 'admin':
    home       => '/home/admin',   # home directory is /home/admin
    managehome => true,            # manage the home directory by Puppet
    groups     => ['wheel'],       # the user belongs to wheel group
    password   => 'PASSWORD_HASH', # hashed password text
}


Là, toujours pareil, par du script tu fais une copie de la clé publique de tes utilisateurs. S'ils doivent tous aller sur tous les serveurs, Puppet pourra se charger de copier le fichier contenant les clés publiques.
 
Pour le coup des 3 mois, sauf à faire du script qui va reset ton fichier qui contient les clés publiques, appelé par cron, je ne vois pas trop comment faire car à ma connaissance ça n'a pas de "durée de vie" à ce niveau [:spamatounet]


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Reply

Marsh Posté le 08-01-2015 à 15:22:53    

à une époque j'avais mis ça en place (authentification centralisée), j'avais utilisé nss-mysql et le module radius de PAM, ça marchait bien et sans avoir à créer chaque user un par un sur chaque serveur.  
Je vois qu'il existe de façon analogue nss_ldap et pam_ldap, tu dois pouvoir t'en sortir avec ça.


---------------
Que va-t-il se passer cette gelgamar ? vous le découvrirez janamont à 20h
Reply

Marsh Posté le 08-01-2015 à 15:44:00    

+1, créer des utilisateurs locaux sur chaque serveur c'est un non sens

Reply

Marsh Posté le 08-01-2015 à 17:55:03    

Je@nb a écrit :

+1, créer des utilisateurs locaux sur chaque serveur c'est un non sens


Justement voir déjà si tous les tech et tous les admins doivent pouvoir aller sur tous les serveurs... ainsi seuls ceux qui ont un compte dessus pourront y accéder, et pas les autres.
Et ça m'étonnerait qu'il bosse avec 300 admins et techs, qui doivent pouvoir tous bosser sur 1500 serveurs :lol:


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Reply

Marsh Posté le 08-01-2015 à 18:09:49    

bardiel a écrit :


Justement voir déjà si tous les tech et tous les admins doivent pouvoir aller sur tous les serveurs... ainsi seuls ceux qui ont un compte dessus pourront y accéder, et pas les autres.


 
c'est une problématique à gérer par des groupes de sécurité, pas par des comptes locaux créés au petit bonheur la chance.


---------------
Que va-t-il se passer cette gelgamar ? vous le découvrirez janamont à 20h
Reply

Marsh Posté le 08-01-2015 à 19:01:58    

J'ai une soixante de serveurs et ça évolue qui doivent être accessible par une équipe de 15 personnes, donc je pense qu'un annuaire correspond mieux au besoin.
 
D'autant plus que nous avons déjà un annuaire LDAP (type AD).
 
Je vais fouiller du coté de NSS et PAM, j'ai l'impression que ce n'est pas sorcier, après je n'ai pas suffisamment de recul ni d’expérience pour dire que ça collera au besoin (avec prise en compte des clés privée/publique et de l'expiration du mot de passe) et qu'il n'y aura pas d'incompatibilité à prévoir rapidement (évolution de l'environnement LINUX + évolution de l'environnement MS).


---------------
Mon topic : http://forum.hardware.fr/forum2.ph [...] =0&nojs=0]
Reply

Marsh Posté le 08-01-2015 à 19:04:00    

Misssardonik a écrit :

c'est une problématique à gérer par des groupes de sécurité, pas par des comptes locaux créés au petit bonheur la chance.


Voui voui voui [:housesmile]  
Si tu passes par un structure gérée par un Puppet pour standardiser l'installation des comptes, ce n'est pas au petit bonheur la chance.
Si tu fais un script qui te créer pour tel serveur tel, tel et tel utilisateur dessus (avec bien évidemment un fichier disponible pour tout le monde pour savoir qui peut aller où), ce n'est pas au petit bonheur la chance.
 
Après niveau connexion comme tu le proposes, avec gestion par les groupes de sécurités, j'ai toujours eu de la mauvaise expérience dedans avec du Kerberos qui foirait quand on avait une perte de liaison entre l'AD et le serveur Linux (merci réseau national avec du bon lag [:dr house] ). Mais je l'accorde, c'est théoriquement ce qu'il faudrait faire pour que ça soit propre.


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Reply

Marsh Posté le 08-01-2015 à 19:04:00   

Reply

Marsh Posté le 08-01-2015 à 19:07:32    

bardiel a écrit :


Si tu passes par un structure gérée par un Puppet pour standardiser l'installation.


 
En tout cas en ce qui me concerne ça m'a permis de comprendre l’intérêt d'une solution Puppet et franchement ça donne envie de le déployer rapidement compte tenu du nombre de serveur et des opérations qu'on fait à la "main" sur chaque serveur..
 
Donc merci  :jap:


---------------
Mon topic : http://forum.hardware.fr/forum2.ph [...] =0&nojs=0]
Reply

Marsh Posté le 08-01-2015 à 19:39:48    

Misssardonik a écrit :


 
c'est une problématique à gérer par des groupes de sécurité, pas par des comptes locaux créés au petit bonheur la chance.


 
+10000, les groupes ça sert à ça.
 
Puppet, oui pour la conf des serveurs (limite pour pousser la conf PAM/NSS s'il veut) mais pas pour gérer qui a le droit de se connecter sur 60 serveurs parmis 15 personnes.

Reply

Marsh Posté le 11-01-2015 à 23:42:52    

bbr241 a écrit :

Bonjour à tous (et bonne année).
 
Je rencontre un besoin très simple, sans doute déjà rencontré par beaucoup d'entre vous qui maîtrise/utilise ce type d'environnement.
 
J'ai une batterie de serveur LINUX pour lesquels je n'ai aucun compte nominatif (pour les administrateurs, il n'y a pas d'utilisateurs sur ces plateformes).
Je voudrais donc créer pour chacun des administrateurs et techniciens des comptes nominatifs en les forçant à utiliser des clés privées (avec mot de passe).
 
La ou je bloque c'est concernant le déploiement en masse, dans un environnement Windows j'utiliserais l'AD sans hésiter.
Est ce que pour un environnement LINUX, il faut aussi déployer un annuaire LDAP, se connecter sur un annuaire AD existant, répliquer simplement les comptes sur chaque machine ?
 
Je n'ai pas suffisamment d’expérience sur les environnements LINUX, je vous sollicite donc pour que nous puissions débattre des solutions et bonnes pratiques de chacun.
 
Merci par avance  :jap:  
 
Bonne journée :hello:


 
Est ce que les netgroup dans un domaine nis ça ne ferait pas l'affaire?

Reply

Marsh Posté le 23-01-2015 à 14:29:38    

Ou un puppet... qui permettrait de déployer les clefs a l'installation de nouvelles machines de façon automatique (avec fai), créé tes utilisateurs et d'harmonisé toutes les configurations de tes serveurs.

Reply

Marsh Posté le 23-01-2015 à 16:18:51    

La vrai réponse, windows compliant est https://wiki.debian.org/LDAP/PAM
De rien.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed