Forum GLPI-Project

N-Mi_N-Mi

Member

Registered: 2025-02-06

Posts: 4

Authentification x509

Bonjour,

Je cherche à faire marcher l'authentification x509 avec GLPI 10.0.16 sur Ubuntu 22.04, le tout communiquant avec un AD en LDAPS. Avant de faire les modifications pour activer l'authentification x509, l'authentification avec la méthode LDAPS seule fonctionne parfaitement.

En ce qui concerne la configuration d'Apache avec mod_ssl, jusqu'ici tout va bien, il reconnaît le certificat client, et le valide avec la CA adéquate, et j'ai loggué pour tester la variable SSL_CLIENT_VERIFY qui est bien à "SUCCESS".

Ma première difficulté a été que GLPI ne semblait pas reconnaître l'authentification x509, et affichait la mire de login. J'avais réglé le paramètre "Email attribute for X.509 authentication" au champs du certificat contenant l'adresse email de l'utilisateur (subjectAltName::otherName, qui est renseigné par mod_ssl dans la variable SSL_CLIENT_SAN_OTHER_msUPN_0), mais cela ne semblait pas fonctionner.
En lisant le code source de la page d 'authentification, j'ai compris que ce paramètre permettait d'indiquer le champs dans le DN qui contenait l'adresse email, et non dans le certificat, ce qui n'était peut-être pas assez explicite dans la doc ou sur la page de configuration.

J'ai donc refait un certificat (en attendant de trouver une autre solution) pour faire apparaître l'adresse email dans le DN, avec le format suivant (en indiquant "emailAddress" comme attribut à rechercher dans la conf GLPI) :
emailAddress=j-doe@secured.private,CN=j-doe,OU=Admins,OU=Administration,DC=secured,DC=private

Cette fois ci, la mire d'authentification n'est plus affichée, mais j'ai le message "Empty login or password".

Quel est le format attendu pour le certificat afin de se connecter avec la méthode x509 ?

N-Mi_N-Mi

Member

Registered: 2025-02-06

Posts: 4

Re: Authentification x509

Je me réponds à moi-même après avoir lu le code, je pense avoir compris :

$sslattribs = explode('/', $_SERVER['SSL_CLIENT_S_DN']);

Donc ce que GLPI attend ce n'est pas :

emailAddress=j-doe@secured.private,CN=j-doe,OU=Admins,OU=Administration,DC=secured,DC=private

Mais :

emailAddress=j-doe@secured.private/CN=j-doe/OU=Admins/OU=Administration/DC=secured/DC=private

Mes certificats utilisent la virgule comme séparateur (et sont déjà utilisés par plusieurs applications), et non un "/", qui d'après le commentaire dans le code est le séparateur utilisé dans les certificats de eGroupWare.

Si je ne souhaite pas patcher localement le code de GLPI (pour ne pas alourdir la maintenance), j'imagine qu'il va falloir que je trouve un moyen pour que Apache présente dans la variable SSL_CLIENT_S_DN un DN au format accepté par GLPI. Mais les premières recherches me laissent supposer que cette variable définie par mod_ssl n'est pas modifiable.

N-Mi_N-Mi

Member

Registered: 2025-02-06

Posts: 4

Re: Authentification x509

Bon, avec ce paramètre ça a l'air de passer :

SSLOptions +StdEnvVars +ExportCertData +LegacyDNStringFormat 

D'après la documentation de mod_ssl :

LegacyDNStringFormat

Cette option permet d'agir sur la manière dont les valeurs des variables SSL_{CLIENT,SERVER}_{I,S}_DN sont formatées. Depuis la version 2.3.11, Apache HTTPD utilise par défaut un format compatible avec la RFC 2253. Ce format utilise des virgules comme délimiteurs entre les attributs, permet l'utilisation de caractères non-ASCII (qui sont alors convertis en UTF8), échappe certains caractères spéciaux avec des slashes inversés, et trie les attributs en plaçant l'attribut "C" en dernière position.

Si l'option LegacyDNStringFormat est présente, c'est l'ancien format qui sera utilisé : les attributs sont triés avec l'attribut "C" en première position, les séparateurs sont des slashes non inversés, les caractères non-ASCII ne sont pas supportés et le support des caractères spéciaux n'est pas fiable.

N-Mi_N-Mi

Member

Registered: 2025-02-06

Posts: 4

Re: Authentification x509

Autre souci,

Maintenant que j'arrive à authentifier des utilisateurs par certificats x509, je souhaite leur assigner des groupes et des profils, de la même manière que pour l'authentification LDAP.

J'ai donc essayé de multiples manières de définir des règles de type memberOf sur les attributs, mais pas moyen de faire que la règle soit déclenchée.

J'ai même essayé des règles plus simple de type "Login > contains > joe" qui devrait forcément se déclencher pour le certificat "emailAddress=j-doe@secured.private/CN=j-doe/OU=Admins/OU=Administration/DC=secured/DC=private". Mais seul l'entité (il n'y en a qu'une de définie dans GLPI) est correcte : le profil est celui par défaut (au lieu de celui défini par la règle), et l'utilisateur n'est assigné à aucun groupe.

Comment faire ?

Last edited by N-Mi_N-Mi (2025-02-10 18:08:43)