Forum GLPI-Project

gordibus

Member

Registered: 2024-12-31

Posts: 5

Problème de SSO après migration GLPI vers un nouveau serveur Debian 12

Bonjour à tous,

Je rencontre un problème avec la configuration du SSO après avoir migré notre application GLPI vers un nouveau serveur sous Debian12. Voici les détails de mon environnement et de ma problématique :

Environnement ancien serveur (SSO fonctionnel)
OS : DebianX
Serveur Web : Apache2
GLPI : 9.X
Authentification : Active Directory (SSO fonctionnel via Kerberos)
Configuration réseau : L'ancien serveur est intégré au domaine Active Directory avec un fichier krb5.keytab et une configuration SSO qui fonctionne correctement.

Environnement nouveau serveur
OS : Debian 12
Serveur Web : Apache2
GLPI : Dernière version disponible
Domaine Active Directory : Le nouveau serveur est bien joint au domaine, les utilisateurs peuvent se connecter manuellement en utilisant leur identifiant/mot de passe, mais la connexion automatique via SSO ne fonctionne pas.
Étapes réalisées lors de la migration
Installation de GLPI sur le nouveau serveur : Installation propre sous Debian 12 avec Apache2 et PHP.
Récupération des données : Importation de la base de données GLPI et copie des fichiers du dossier files depuis l'ancien serveur.
Intégration au domaine Active Directory : Le serveur est joint au domaine et peut interroger le contrôleur de domaine via LDAP.
Configuration SSO :
Modules Apache activés : authnz_ldap, auth_kerb, headers, rewrite.
Fichier /etc/krb5.conf configuré avec les mêmes paramètres que sur l'ancien serveur.
Fichier /etc/krb5.keytab récupéré depuis l'ancien serveur et mis à jour selon l'adresse correspondant.

Avez vous des pistes pour résoudre ce problème ?

Bien à vous.

Chico008

Member

Registered: 2022-12-14

Posts: 445

Re: Problème de SSO après migration GLPI vers un nouveau serveur Debian 12

Bonjour

peut tu nous indiquer la configuration glpi dans apache ?

coté Glpi, as tu bien activer egalement l'utilisation du domaine ldap ainsi que le champ de connexion automatique utilisé ?

gordibus

Member

Registered: 2024-12-31

Posts: 5

Re: Problème de SSO après migration GLPI vers un nouveau serveur Debian 12

Pour l'authentification SSO en GSSAPI j'ai ces fichier:
$cat /etc/apache2/sites-available/glpi-de-la-mort-qui-tue.fr.conf
```

<VirtualHost *:80>
    ServerName glpi-de-la-mort-qui-tue.fr.fr

    DocumentRoot /var/www/glpi/public

    # If you want to place GLPI in a subfolder of your site (e.g. your virtual host is serving multiple applications),
    # you can use an Alias directive. If you do this, the DocumentRoot directive MUST NOT target the GLPI directory itself.
    # Alias "/glpi" "/var/www/glpi/public"

    <Directory /var/www/glpi/public>
        Require all granted

        # Activer le module d'authentification GSSAPI pour l'authentification Kerberos
        AuthType GSSAPI
        AuthName "Active Directory Login"
        GssapiCredStore keytab:/etc/krb5.keytab
        Require valid-user

        RewriteEngine On

        # Redirect all requests to GLPI router, unless file exists.
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^(.*)$ index.php [QSA,L]
    </Directory>

    <FilesMatch \.php$>
                SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost/"
    </FilesMatch>

</VirtualHost>

```
Côté fichier .htaccess:
$cat /var/www/html/glpi/.htaccess
```

<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
deny from all
</IfModule>

```
Dans mon fichier /etc/samba/smb.conf

```

[global]
 workgroup = DLMQT
© StarXpert 2017 CR INSTALLATION GLPI 6 / 11
#*********
 realm = de-la-mort-qui-tue.LOCAL
 security = ADS
 encrypt passwords = yes
 password server = srv-dc01-vm.de-la-mort-qui-tue.local
 winbind enum groups = yes
 winbind enum users = yes
 winbind nested groups = yes
 winbind offline logon = yes
 winbind use default domain = no
 winbind nss info = sfu
 winbind cache time = 60
 winbind refresh tickets = yes
 idmap uid = 10000-20000
 idmap gid = 10000-20000

```

Enfin le fichier:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat winbind
group: compat winbind
shadow: compat winbind
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

```
Evidemment je ne vais pas fournir mes réels fichier néanmoins l'essentiel des informations sont là.

Malgré toute ces configurations faite, la connexion SSO ne se fait pas, les utilisateurs doivent se connecter manuellement.

Bonjour

peut tu nous indiquer la configuration glpi dans apache ?

coté Glpi, as tu bien activer egalement l'utilisation du domaine ldap ainsi que le champ de connexion automatique utilisé ?

Last edited by gordibus (2025-01-02 12:49:09)

Chico008

Member

Registered: 2022-12-14

Posts: 445

Re: Problème de SSO après migration GLPI vers un nouveau serveur Debian 12

ServerName glpi-de-la-mort-qui-tue.fr.fr

y'a pas un .fr en trop ?

le fichier .htaccess tu l'a modifier ?
de mon coté il est vide.
en principe, sauf besoin tres specifique, il ne faut pas le modifier, la conf devant se faire principalement avec le fichier de conf apache.
le .htaccess est pour palier si tu peut pas acceder a ta conf apache.

Si tu peut remet le par defaut pour refaire un test, et corriger ton apache de la mort qui tue pour retirer un .fr en trop
relance apache, vide le cache de ton navigateur, et refait un test.
Si le sso ne fonctionne toujours pas, regarde au niveau des logs apache ce qu'il raconte.

en shell, t'a tester avec les commandes kerberos (kinit et cie) voir si c'etait ok ?
apres cette partie c'est surtout pour gerer la connexion en shell via domaine, pas forcement necessaire pour le SSO apache.
pour cette partie de mon coté j'ai configurer que Kerberos, j'ai pas de samba sur mon serveur.

Last edited by Chico008 (2025-01-03 09:42:45)

gordibus

Member

Registered: 2024-12-31

Posts: 5

Re: Problème de SSO après migration GLPI vers un nouveau serveur Debian 12

Bonjour,

Le .fr à la fin est une erreur d'anonymisation. Le fichier se termine par

.fr.conf

.
Le fichier .htaccess est vide par défaut, mais malgré cela, l'erreur persiste.

J’ai réalisé des tests avec kinit en utilisant un utilisateur dédié. Ces tests fonctionnent néanmoins, mais le lien avec les groupes et utilisateurs ne se fait pas pour la connexion automatique.

Cependant, j’ai tout de même trouvé une piste :
Je me suis aperçu que je n’avais pas de fichier

/etc/krb5.keytab

.

Par ailleurs, je n’ai pas effectué de test avec cie, et je ne vois pas de quoi il s’agit.

Merci pour ton retour et tes suggestions !
Je vais me concentrer sur cette piste. Si mes tests aboutissent, je publierai les résultats ici. Dans le cas contraire, si vous avez des suggestions, n’hésitez pas à les partager.

ServerName glpi-de-la-mort-qui-tue.fr.fr

y'a pas un .fr en trop ?

le fichier .htaccess tu l'a modifier ?
de mon coté il est vide.
en principe, sauf besoin tres specifique, il ne faut pas le modifier, la conf devant se faire principalement avec le fichier de conf apache.
le .htaccess est pour palier si tu peut pas acceder a ta conf apache.

Si tu peut remet le par defaut pour refaire un test, et corriger ton apache de la mort qui tue pour retirer un .fr en trop
relance apache, vide le cache de ton navigateur, et refait un test.
Si le sso ne fonctionne toujours pas, regarde au niveau des logs apache ce qu'il raconte.

en shell, t'a tester avec les commandes kerberos (kinit et cie) voir si c'etait ok ?
apres cette partie c'est surtout pour gerer la connexion en shell via domaine, pas forcement necessaire pour le SSO apache.
pour cette partie de mon coté j'ai configurer que Kerberos, j'ai pas de samba sur mon serveur.

Chico008

Member

Registered: 2022-12-14

Posts: 445

Re: Problème de SSO après migration GLPI vers un nouveau serveur Debian 12

Pour le .fr en trop je parlais du servername dans le fichier de conf, pas dans le nom du fichier, mais je te fait confiance pour l'anonymisation

apres comme dis, en principe le SSO n'utilise que apache, le module apache gssapi (car c'est ce que tu utilises dans ton fichier de conf) et les keytab associé.

le reste de ta conf avec kerberos c'est surtout pour autoriser des utilisateur a se connecter en ssh via authentification Ad/ldap.
par contre il me semble que tu peut quand meme tester avec kinit la connexion a ton compte de service avec le keytab associé, voir si la connection fonctionne.
si elle fonctionne pas, tu saura pourquoi ton sso ne marche pas.

au nivau de la log apache t'a rien au moment de l'authentification justement ? pas d'erreur ?
car justement il devrait raler si y'a un soucis avec le  keytab ou le compte de service, ou autre.