Le module utilisateurs réseau permet à Dynacase-platform d'utiliser un serveur LDAP déjà existant comme base d'authentification et comme référence pour les propriétés des utilisateurs (login, nom ,prénom, téléphone, mail ,…) et des groupes d'appartenances. Lorsque les utilisateurs et les groupes proviennent d'un serveur LDAP, on les nommera utilisateurs réseau et groupes réseau. Lors qu'ils sont déclarés localement, on les nommera utilisateurs locaux et groupes locaux.

À l'installation de Dynacase-platform, 2 utilisateurs et 2 groupes locaux sont crées :

• utilisateur admin (dynacase master) et guest (anonymous)
• groupes gadmin (groupe administration) et all (groupe défaut).

Ces utilisateurs et groupes ne doivent pas être supprimés. Ils servent de références lors de l'installation d'applications afin de définir les droits par défaut pour les utilisateurs et les administrateurs. L'utilisateur admin doit toujours être présent afin de débloquer des situations ou lorsque le serveur d'authentification distant est injoignable pour modifier par exemple des paramètres de connections.

Ce module est configuré pour être connecté à deux types de serveur LDAP : Active Directory et Posix. Dynacase-platform utilise une table de translation entre les schémas LDAP et les attributs des utilisateurs et groupes réseaux. Pour Active Directory, Dynacase-platform recherche les classes d'objets LDAP user et group. Pour Posix, Dynacase-platform recherche les classes d'objets LDAP posixAccount et posixGroup.

Deux politiques sont possibles dans le cadre de ce modules:

• Création à la volée : tout utilisateur référencé dans le LDAP peut se connecter à Dynacase-platform
• Création à la demande : l'administrateur doit créer l'utilisateur dans Dynacase-platform (choix parmis ceux référencés dans le LDAP)

L'installation du module créé deux nouvelles familles de documents : Utilisateur réseaux et Groupe réseaux. Ces documents vont recevoir les informations du LDAP choisi. Les informations provenant du LDAP ne peuvent pas être modifiés par Dynacase-platform. L'administrateur peut créer des utilisateurs réseaux. Cela consiste à rechercher un utilisateur dans le LDAP puis de le créer dans Dynacase-platform.

La création donne le document suivant. Les groupes d'appartenance à l'utilisateur sont créés automatiquement lorsqu'un utilisateur est créé ou mis à jour.

Afin de créer les comptes au LDAP équivalent dans Dynacase-platform, il est nécessaire de renseigner les paramètres suivants:

Ces paramètres doivent être les mêmes que ceux renseignés dans le fichier /etc/ldap.conf.

• NU_LDAP_MODE permet de spécifier le mode de connexion au serveur LDAP. Trois modes sont disponibles :
  • ”plain” (par défaut) effectue une connexion non-chiffrée
  • ”ssl” effectue une connexion sécurisée par SSL (généralement sur le port 636)
  • ”tls” effectue une connexion sécurisée par TLS (généralement sur le port standard 389)
  • Pour le paramétrage de ces modes, voir Paramétrage des modes sécurisés Network User.

• NU_LDAP_GROUP_BASE_DN et NU_LDAP_USER_DN permettent de spécifier un base DN de recherche distinct pour les groupes et les utilisateurs. Si vos groupes et vos utlisateurs sont dans la même sous-branche, il faudra alors renseigner le même base DN dans les deux paramètres.
• NU_LDAP_GROUP_FILTER et NU_LDAP_USER_FILTER permettent en plus de spécifier un filtre, au format LDAP, afin de restreindre la recherche des groupes et des utilisateurs a un sous-ensemble de ces éléments.

Exemple :

Note :

• Syntaxe des filtres LDAP : http://www.rfc-editor.org/rfc/rfc2254.txt, http://msdn.microsoft.com/en-us/library/aa746475(VS.85).aspx
• Pour récupérer les informations concernant l'AD utiliser la commande dos ldifde. Exemple pour dumper les utilisateurs du AD local dans un fichier :
  `ldifde -r ”(ObjectClass=User”) -s 127.0.0.1 -f utilisateurs.ldif'.

Pour utiliser `freedom-networkuser' comme fournisseur d'authentification à Dynacase-platform, il faut déclarer celui-ci dans la variable `$freedom_authprovider'.

Pour cela, il vous faut éditer le fichier `context/default/local-dbaccess.php' et ajouter `freedomNu' dans `$freedom_authprovider' :

<?php
$freedom_authprovider="freedom,freedomNu";
?>

Les paramètres du provider `freedomNu' sont :

$freedom_providers['freedomNu'] = array(
                       'allowAutoFreedomUserCreation' => 'no',
                       'fix_euro' => 'no',
                       'convert_to_utf8' => 'no',
                       'options' => array(
                                          LDAP_OPT_REFERRALS => 0
                       )
);

La commande wsh `nu_importldap' permet d'importer l'intégralité des utilisateurs et groupes d'un serveur LDAP Posix.

Utilisation

$ ./wsh.php --api=nu_importldap

Search group S-01-5-32-544...Create Group Administrateurs
Search group S-01-5-32-545...Create Group Utilisateurs
Search group S-01-5-32-546...Create Group Invités
Search group S-01-5-32-550...Create Group Opérateurs d'impression
Search group S-01-5-32-551...Create Group Opérateurs de sauvegarde
Search group S-01-5-32-552...Create Group Duplicateurs

Options

La commande wsh `nu_importldap_ad' permet d'importer l'intégralité des utilisateurs et groupes d'un serveur LDAP Active Directory.

Utilisation

$ ./wsh.php --api=nu_importldap_ad

Options

Deux commandes wsh permettent une mise à jour générale. Cela consiste à actualiser les informations des utilisateurs réseaux déjà créés à partir des informations présentes dans le LDAP.

• Pour les utilisateurs :

wsh --api=freedom_refresh --famid=LDAPUSER --method=refreshFromLDAP

• Pour les groupes :

wsh --api=freedom_refresh --famid=LDAPGROUP --method=refreshFromLDAP

Exemple :

# . /etc/freedom.conf
# wsh --api=freedom_refresh --famid=LDAPGROUP --method=refreshFromLDAP

7 documents to refresh
using refreshFromLDAP method
7)propriétaires créateurs de la stratégie de groupe (use refreshFromLDAP)Doc171923
6)administrateurs du schéma (use refreshFromLDAP)Doc171923
5)Admins du domaine (use refreshFromLDAP)Doc171923
4)Administrateurs de l'entreprise (use refreshFromLDAP)Doc171923
3)Administrateurs (use refreshFromLDAP)Doc171923
2)Utilisa. du domaine (use refreshFromLDAP)Doc171923
1)Utilisateurs (use refreshFromLDAP)Doc171923

Lors de la création d'un utilisateur réseau (ou du rafraîchissement de sa fiche), les attributs LDAP sont importés dans les attributs Dynacase-platform en suivant une table de correspondance qui est spécifiée dans le fichier `networkuser.ods', dans l'onglet LDAP.

On y définit des associations entre un attribut LDAP et son équivalent Dynacase-platform.

Par exemple, le numéro de téléphone (attribut Dynacase-platform US_PHONE) est pris à partir de l'attribut LDAP `telephoneNumber' pour les objets LDAP qui héritent du schéma `inetOrgPerson' :

LDAPMAP;LDAPUSER;telephoneNumber;US_PHONE;inetOrgPerson;1

Pour charger son propre « mapping », en complément de celui définit dans `networkuser.ods', on pourra créer un fichier CSV (ou ODS) et y définir ses règles de correspondance, et importer ce fichier comme on importe une définition de famille.

Pour modifier, ou supprimer une entrée, il faudra manipuler directemnt la table `docattrldap' en base de données (qui a la même structure que le fichier LDAPMAP décrit ci-dessus :

SELECT * FROM docattrldap;
UPDATE docattrldap SET ldap_attribute = 'someOtherPhoneNumber' WHERE freedom_attribute = 'US_PHONE';
etc.

Le paramètre NU_LDAP_MODE permet de spécifier la connexion en mode sécurisée (SSL ou TLS) avec le serveur LDAP/Active Directory.

La gestion de la demande et de la vérification du certificat du serveur par le client est paramétrable par le fichier de configuration standard de la librairie OpenLDAP :

• voir section “TLS OPTIONS” de la documentation de `''ldap.conf'''

Extrait :

TLS OPTIONS
       If OpenLDAP is built  with  Transport  Layer  Security  support,
       there  are more options you can specify.  These options are used
       when an ldaps:// URI is selected (by default  or  otherwise)  or
       when the application negotiates TLS by issuing the LDAP StartTLS
       operation.

       TLS_CACERT <filename>
              Specifies the file that contains certificates for all  of
              the Certificate Authorities the client will recognize.

       TLS_CACERTDIR <path>
              Specifies   the   path   of  a  directory  that  contains
              Certificate Authority certificates in separate individual
              files.    The    TLS_CACERT   is   always   used   before
              TLS_CACERTDIR.  This parameter is ignored with GNUtls.

       TLS_CERT <filename>
              Specifies the file that contains the client  certificate.
              This is a user-only option.

       TLS_KEY <filename>
              Specifies  the  file  that  contains the private key that
              matches the certificate  stored  in  the  TLS_CERT  file.
              Currently,  the  private key must not be protected with a
              password, so it is of critical importance  that  the  key
              file is protected carefully.  This is a user-only option.

       TLS_CIPHER_SUITE <cipher-suite-spec>
              Specifies acceptable cipher suite and  preference  order.
              <cipher-suite-spec>  should be a cipher specification for
              OpenSSL, e.g., HIGH:MEDIUM:+SSLv2.

              To check what ciphers a given spec selects, use:

                   openssl ciphers -v <cipher-suite-spec>

              To obtain the list of ciphers in GNUtls use:

                   gnutls-cli -l

       TLS_RANDFILE <filename>
              Specifies the  file  to  obtain  random  bits  from  when
              /dev/[u]random  is  not  available.  Generally set to the
              name of the EGD/PRNGD socket.  The  environment  variable
              RANDFILE  can also be used to specify the filename.  This
              parameter is ignored with GNUtls.

       TLS_REQCERT <level>
              Specifies what checks to perform on  server  certificates
              in a TLS session, if any. The <level> can be specified as
              one of the following keywords:

              never  The client will not request or  check  any  server
                     certificate.

              allow  The   server   certificate  is  requested.  If  no
                     certificate  is  provided,  the  session  proceeds
                     normally.  If  a  bad  certificate is provided, it
                     will be ignored and the session proceeds normally.

              try    The   server   certificate  is  requested.  If  no
                     certificate  is  provided,  the  session  proceeds
                     normally.  If  a  bad certificate is provided, the
                     session is immediately terminated.

              demand | hard
                     These  keywords   are   equivalent.   The   server
                     certificate  is  requested.  If  no certificate is
                     provided, or a bad certificate  is  provided,  the
                     session  is  immediately  terminated.  This is the
                     default setting.

       TLS_CRLCHECK <level>
              Specifies if the Certificate Revocation List (CRL) of the
              CA  should  be  used to verify if the server certificates
              have  not  been  revoked.  This  requires   TLS_CACERTDIR
              parameter  to  be  set.  This  parameter  is ignored with
              GNUtls.  <level> can be specified as one of the following
              keywords:

              none   No CRL checks are performed

              peer   Check the CRL of the peer certificate

              all    Check the CRL for a whole certificate chain

       TLS_CRLFILE <filename>
              Specifies  the  file  containing a Certificate Revocation
              List to be used to verify if the server certificates have
              not  been  revoked. This parameter is only supported with
              GNUtls.