Problème ajout utilisateur Entra ID

[Manu]

Bonjour,
Je vous remercie d'avoir pris le temps de s'arrêter sur mon problème.

Je n'arrive plus à synchroniser mon Entra ID avec mes utilisateurs locaux.
Le bouton "lancer une simulation" fonctionne, mais lorsque je fais " Lancer la synchronisation" aucun changement ne se réalise.

Avant de commencer, voici mes informations serveur:
MariaDB : 10.11.4-MariaDB-1~deb12u1 (base : bsup 618.8Mo)
PHP : 8.2.14 (/etc/php/8.2/apache2/php.ini)
GestSup : 3.2.52 (6029 tickets / 787 utilisateurs / 0 équipements)

Lorsque j'active le mode "debug", voici le message d'erreur du "Lancer ka synchronisation":
Fatal error: Uncaught PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'user_id' cannot be null in /var/www/html/core/azure_ad.php:639 Stack trace: #0 /var/www/html/core/azure_ad.php(639): PDOStatement->execute() #1 /var/www/html/admin/user.php(178): include('...') #2 /var/www/html/admin.php(22): include('...') #3 /var/www/html/main.php(520): include('...') #4 /var/www/html/index.php(405): require('...') #5 {main} thrown in /var/www/html/core/azure_ad.php on line 639



Lorsque je cherche dans le dossier /var/www/html/core/azure_ad.php , voici le passage de la ligne 621 à 642 :
//Entra ID service already exist in GS DB
} else {
//check if exist an association with current GS user and service.
$qry=$db->prepare("SELECT `id`,`user_id` FROM `tusers_services` WHERE user_id IN (SELECT id FROM tusers WHERE azure_ad_id=:azure_ad_id) AND service_id=:service_id");
$qry->execute(array('azure_ad_id' => $AzureUser['id'],'service_id' => $service['id']));
$row=$qry->fetch();
$qry->closeCursor();
if(empty($row))//if no association found create it
{
$update=1;
echo '<i class="fa fa-sync text-warning"></i> <i class="fa fa-users text-warning"></i> '.T_('Mise à jour du service').' '.$AzureUser['service'].' pour '.$AzureUser['upn'].'<br />';
//delete old association
$qry=$db->prepare("DELETE FROM tusers_services WHERE user_id IN (SELECT id FROM tusers WHERE azure_ad_id=:azure_ad_id)");
$qry->execute(array('azure_ad_id' => $AzureUser['id']));
//create association
if($_GET['action']=='run')
{
$qry=$db->prepare("INSERT INTO tusers_services (user_id,service_id) VALUES ((SELECT MAX(id) FROM tusers WHERE azure_ad_id=:azure_ad_id),:service_id)");
$qry->execute(array('azure_ad_id' => $AzureUser['id'],'service_id' => $service['id']));
}
}


Pouvez-vous m'aider s'il vous plait ?

Bonne journée
Manu

[Flox]

Bonjour,

Pouvez-vous transmettre l'ensemble de la page affichée lors de la simulation de synchronisation avec le mode debug.

Et indiquer si le test du connecteur fonctionne ?

Cdt

[Manu]

Le test du connecteur fonctionne.
De plus il trouve bien les modifications a faire lors de la simulation.
Lors de la synchronisation il dit effectuer des changement mais c'est faux.

[historicsmile]

Il apprécie également les modifications à faire lors de la simulation. Lors de la synchronisation, il prétend apporter des changements, mais c'est incorrect.

[Parfaitup]

Salut ! Vu l’erreur, on dirait surtout que votre SELECT MAX(id) FROM tusers WHERE azure_ad_id=:azure_ad_id ne renvoie rien au moment de l’INSERT, donc derrière GestSup essaie d’insérer NULL dans tusers_services.user_id, ce qui colle pile avec le Column 'user_id' cannot be null ; en gros la simu passe parce qu’elle “voit” les écarts, mais en synchro réelle il y a au moins un user Entra ID dont l’azure_ad_id n’existe pas ou plus correctement côté tusers, souvent après un ancien compte local modifié/supprimé ou un doublon un peu tordu. Je regarderais direct en base si vous avez bien un enregistrement pour l’utilisateur qui plante avec un truc du genre SELECT id,login,azure_ad_id FROM tusers WHERE azure_ad_id='ID_ENTRA'; et aussi s’il n’y a pas des lignes orphelines dans tusers_services. Le plus parlant ce serait de tracer juste avant la ligne 639 la valeur de $AzureUser['id'], parce que j’ai deja vu ce genre de cas quand le mapping service part sur un user pas encore créé ou plus lié. A mon avis vous tenez un vrai bug sur la 3.2.52, donc la maj en 3.2.53 vaut le coup aussi, parce que là le code suppose qu’un user_id existe forcément alors que non visiblement.

[Alexgest]

Salut ! oui ça sent bien le cas où la simulation lit correctement les écarts mais qu’en exécution réelle ça casse au moment d’écrire l’association service, parce que le sous-select sur tusers ne retrouve aucun id pour le azure_ad_id traité, donc user_id = NULL et boum. Franchement je ferais comme au-dessus: vérifier en base les comptes Entra concernés avec un SELECT id, login, azure_ad_id FROM tusers WHERE azure_ad_id='...' et aussi repérer les users qui ont un azure_ad_id vide, en double ou pas cohérent après ancien renommage/suppression, parce que c’est souvent là que ça part de travers. Le code est un peu optimiste aussi, il suppose que le user existe forcément avant de créer le lien de service, donc sur une 3.2.52 ça me choque pas qu’il y ait un bug dans ce scénario.