Forum Linux.général [LDAP] Conception annuaire d'entreprise

Posté par  (site web personnel) .
Étiquettes : aucune
0
15
juil.
2009
Bonjour,

Je suis actuellement dans une entreprise d'une vingtaine de personne et nous souhaitons créer un annuaire LDAP pour gérer l'authentification de nos employés sur les divers services que nous utilisons (SSH, FTP, Trac, ERP...).

Voici ce à quoi j'avais pensé :

dc=com
|
dc=societe
|
-----------------------------------------------------------
| | |  |
ou=groups ou=clients ou=employees ou=admin

Je pensais donc regrouper nos employés dans employees... Seulement, je suis perdu dès que je veux créer des groupes. Par exemple, il n'y a que certains employés qui peuvent accéder au serveur ssh1. Je voulais donc créer un groupe serveur ssh1 et insérer les employés dedans... Mais je suis perdu car certain de ces employés peuvent aussi accéder au serveur ssh2 !!

De plus, je voudrais que quand mes employés se connectent, ils n'aient pas de /home/employees de créé... C'est possible ?


Merci de me sortir de ce brouillard :)
  • # pourquoi pas

    Posté par  . Évalué à 2.

    les utilisateurs seront tous dans employees (si tu les mets là)
    un utilisateur (UID) peut ensuite appartenir à plusieurs groupes

    au moment de gerer l'identification (probablement avec pam_ldap) il suffit de dire que du prend les logins dans

    dc=com,dc=societe,ou=employees

    cela va creer le /home/utilisateur1
    au moment ou celui-ci va se connecter (pour la premiere fois)
    • [^] # Re: pourquoi pas

      Posté par  (site web personnel) . Évalué à 1.

      Mais justement, je ne veux pas que mes users aient leur propre /home/user ...
      En fait, j'aimerais juste que je puisse vérifier qui se connecte, mais qu'il n'aient pas de /home et qu'après, ils puissent se connecter en root si besoin est !

      Mais du coup, je me dis que ca va être compliqué ....

      Par contre, il serait possible d'avoir un compte "invité" sur chaque serveur et que quand un employé se connecte, il soit sur ce compte ... ?
      • [^] # Re: pourquoi pas

        Posté par  . Évalué à 2.

        il me semble que si tu ajoutes le schema posix_group dans ton ldap
        tu peux preciser le /home/xyz de ton utilisateur

        par contre je ne sais pas si tu peux avoir le meme /home pour differents utilisateurs (il pourrait y avoir des problemes de droits)
  • # Limiter l'accès à certains serveurs

    Posté par  . Évalué à 1.

    Pour limiter l'accès au serveur ssh1 à certains users de l'annuaire, tu as plusieurs façon de le faire.

    La première, c'est les netgroup, un héritage de NIS qui a la particularité de fonctionner avec tous les unices (aix solaris etc..).

    Hop, une petite URL qui va bien :

    http://directory.fedoraproject.org/wiki/Howto:Netgroups

    Il y a à ma connaissance une autre façon de procéder, mais cette fois c'est spécifique à PAM, j'ai la flemme de chercher mais je suis sûr que tu trouvera :-)
  • # allowGroup/sshd

    Posté par  (site web personnel) . Évalué à 2.

    directive AllowGroup dans config sshd

    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

    • [^] # Re: allowGroup/sshd

      Posté par  (site web personnel) . Évalué à 1.

      Oui, c'est bien ce que je comptais utiliser ... :-)

      Mais j'étais plus embêté quand à l'implémentation de ces groupes dans ldap...
      Une piste peut être ? ;-)
      • [^] # Re: allowGroup/sshd

        Posté par  (site web personnel) . Évalué à 2.

        Comme l'a indiqué Neox l'un des attributs du schéma posixGroup permet cela.

        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

      • [^] # Re: allowGroup/sshd

        Posté par  . Évalué à 3.

        dc=com,dc=societe,ou=group

        et dedans tu mets tes groupes
        ssh1
        ssh2
        serveurA
        serveurB
        ...

        un utilisateur qui doit acceder uniquement à ssh1 sera dans le groupe ssh1
        un utilisateur qui peut acceder aux deux serveurs sera dans les 2 groupes

        et ainsi de suite
        • [^] # Re: allowGroup/sshd

          Posté par  (site web personnel) . Évalué à 1.

          ok...

          Mais comment cela se modélisera t'il pour attacher un utilisateur à un groupe ? (je sais pas si je me fais bien comprendre >_< )
          • [^] # Re: allowGroup/sshd

            Posté par  . Évalué à 2.

            ben avec ton outil de gestion ldap
            quand tu crees un utilisateur, il a un groupe "primaire" (par exemple DRH/COMPTA...)

            puis tu lui ajoutes des groupes "secondaires" (ssh1,serveurA...)

            un utilisateur peut donc etre dans plusieurs groupes
            • [^] # Re: allowGroup/sshd

              Posté par  (site web personnel) . Évalué à 1.

              À priori pas dans posix_group ...
              Il faut que j'ajoute des attributs ?


              (pour info, j'utilise phpldapadmin)
              • [^] # Re: allowGroup/sshd

                Posté par  . Évalué à 2.

                posix_group ca ajoute surtout (de memoire)
                les champs shell, home...

                sinon perso j'utilisais LUMA (client local pour serveur ldap) comme logiciel pour gerer mon ldap mais il faut alors pouvoir se connecter au serveur depuis ta machine locale
                • [^] # Re: allowGroup/sshd

                  Posté par  (site web personnel) . Évalué à 1.

                  LUMA ne fonctionne qu'à moitié ici ... Quand je créé un groupe, je ne le retrouve pas dans ma liste de groupe ! (et impossible de créer des Organizational Unit...)

                  Par contre, avec phpldapadmin ca marche pas trop mal... Le seul problème, c'est qu'avec un posixGroup, je peux spécifier un UID... Est ce indispensable dans mon cas, si je n'en spécifie pas, j'ai peur que ça créé un peu le bazar non ?
                  • [^] # Re: allowGroup/sshd

                    Posté par  (site web personnel) . Évalué à 2.

                    verifier la présence de schema-check on dans le fichier de conf de slapd
                    Si défini, les attributs obligatoires sont vérifiés lors de l'ajout de nouveaux objects dans
                    l'annuaire, ce qui *evite* les bétises et garantit l'intégrité de celui-ci.

                    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

                    • [^] # Re: allowGroup/sshd

                      Posté par  (site web personnel) . Évalué à 1.

                      Ca vérifie que tout les attributs sont remplis, mais ca me dit pas si les uid sont uniques ... Mais l'uid est il vraiment indispensable ??
                      • [^] # Re: allowGroup/sshd

                        Posté par  (site web personnel) . Évalué à 2.

                        Regarde dans le schéma correspondant, tu as toutes les infos.

                        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

                        • [^] # Re: allowGroup/sshd

                          Posté par  (site web personnel) . Évalué à 1.

                          Hum, en fait pour l'uid, c'est moi qui perdais la boule ...

                          Je mélangeais avec le GID ! Est il indispensable ? Si oui, je pense que je peux tout le temps mettre 50 non ? Vu que c'est le groupe d'users par défaut ?
                          • [^] # Re: allowGroup/sshd

                            Posté par  (site web personnel) . Évalué à 2.

                            Pour un groupe donné, le gidNumber est unique.

                            Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

                          • [^] # Re: allowGroup/sshd

                            Posté par  . Évalué à 2.

                            si le groupe avec GID=50 te conviens alors oui, tu peux par exemple mettre tous tes utilisateurs sous ce GID

                            attention toutefois, car ce GID peut se retrouver sur tes serveurs comme etant lié a un autre utilisateur/groupe

                            je me souviens que j'avais du mettre un min UID et min GID dans mon ldap
                            afin de ne pas risquer de confusion

                            genre minUID=10000, minGID=10000

                            car sur les machines suivant la distrib,
                            les users commencent à 100 ou 1000
                            les groups non system aussi.

                            donc pour bien faire la difference entre un utilisateur local et un du LDAP, je mettais des ID > 10000
                            • [^] # Re: allowGroup/sshd

                              Posté par  (site web personnel) . Évalué à 1.

                              C'est une très bonne idée, je vais faire comme ça aussi ...
                              Donc je peux mettre tout mes users ldap dans un seul GID, c'est aussi bien ?
                              Par contre, pour les UID, je sais pas comment en avoir un différent à chaque fois .. J'ai pas envie de devoir aller chercher le dernier UID rentré pour savoir lequel je dois mettre ...

                              Un UID est forcément un int ?
                              (voir le lien : http://www.nabble.com/LDAP-membership-represented-by-memberU(...) )
                              • [^] # Re: allowGroup/sshd

                                Posté par  . Évalué à 2.

                                l'UID ldap est souvent le login (donc autre chose qu'un INT)


                                uniqueMember: uid=janeth,ou=People,dc=example,dc=com
                                uniqueMember: uid=michael,ou=People,dc=example,dc=com
                                uniqueMember: uid=john,ou=People,dc=example,dc=com
                      • [^] # Re: allowGroup/sshd

                        Posté par  (site web personnel) . Évalué à 2.

                        Si!

                        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

          • [^] # Re: allowGroup/sshd

            Posté par  (site web personnel) . Évalué à 2.

            http://www.nabble.com/LDAP-membership-represented-by-memberU(...)

            Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.