[2.7.0.19593] Self-Service : 403 WRONG_PASSWORD_USERNAME si le suffixe UPN diffère du domaine AD (régression 2.6 → 2.7)

[massimo]

Version : 2.7.0.19593-10b94c8e (serveur, agent et console)
Édition : Enterprise
Serveur : Debian 12
Postes : Windows 11, jointure hybride AD + Entra

Bonjour,

Depuis la mise à jour en 2.7.0.19593, le Self-Service refuse nos utilisateurs standard. Il fonctionnait en 2.6. Problème reproduit sur nos postes de test avec l'agent 2.7.

Contexte
- Domaine AD : domaine.local (NetBIOS DOMAINE)
- UPN des utilisateurs : @entreprise.fr (suffixe UPN alternatif, synchronisation Entra)
- UPN des comptes d'administration : @domaine.local
- service_auth_type par défaut (filetoken)

Symptôme

Code : Tout sélectionner

Client Error Forbidden (403): Restricted access. WRONG_PASSWORD_USERNAME
for url: https://127.0.0.1:8088/login

Dans waptservice.log :

Code : Tout sélectionner

WARNING local_login failed for user@domaine.local:
Forbidden, unable to find session or local profile for user user@domaine.local

Essais (tous KO pour un compte dont l'UPN est en @entreprise.fr)
- Session automatique (filetoken) : unable to find session or local profile for user user@domaine.local
- « Changer d'utilisateur » + user@domaine.local + mot de passe : même refus
- « Changer d'utilisateur » + DOMAINE\user + mot de passe : même refus (for user DOMAINE\user)
- « Changer d'utilisateur » + user@entreprise.fr + mot de passe : Invalid service response for GetLocalServiceToken, no token.
- service_auth_type = system : même résultat

Sur le même poste, le compte user_adm (UPN user_adm@domaine.local) se connecte sans problème.
Pas de compte local homonyme sur les postes.

Analyse
L'agent semble normaliser le nom en <sAMAccountName>@<domaine DNS AD> au lieu d'utiliser l'UPN réel (userPrincipalName) ou le SID de la session, ce qui échoue lorsque le suffixe UPN diffère du domaine. Probablement lié à la nouveauté 2.7 « users and groups are fully qualified names for authentication and self-service ACLs (no fallback on short name) ».
Le sujet « Selfservice WAPT : Erreur 666 » (viewtopic.php?t=4651) décrit peut-être le même cas (utilisateurs refusés, comptes admin OK).

Questions
1. Ce comportement est-il connu, et un correctif est-il prévu ?
2. Existe-t-il un paramètre de l'agent permettant d'utiliser l'UPN réel ou le SID de la session plutôt que sAMAccountName@domaine_DNS ?

Merci,

[dcardon]

Bonjour Maxime,

il y a en effet un bug à ce niveau là. La gestion des UPN est pas correctement prise en compte. On a un premier patch en interne, on revient vers vous très rapidement dès que c'est validé.

La partie gestion de droit selfservice a été améliorer pour intéroger la couche LSA locale plutôt que l'AD pour mieux gérer les cas où la connectivité réseau d'entreprise n'est que partielle ou complètement déconnecté (la couche LSA de Windows fait du cache et le fait plutôt bien, même si sa gestion des timeouts de connexion peut être un peu artistique parfois).

Désolé pour le désagrément, il faut que l'on rajoute des utilisateurs en UPN dans les tests internes...

Cordialement,

Denis

[massimo]

Bonjour Denis,

Merci pour ce retour rapide et la confirmation. Nous sommes disponibles pour tester le patch sur nos postes de test dès qu'il est prêt, si ça peut vous aider à le valider.

Cordialement,

[sfonteneau]

Bonjour

Je viens de publier la version 2.7.0.19597 qui devrais résoudre le problème, (tester chez un autre client)

Vous pouvez essayer a nouveau et revenir vers nous.

[massimo]

Bonjour,

Merci pour votre réactivité ! Après mise à jour du serveur et de l'agent, le Self-Service fonctionne à nouveau pour les utilisateurs dont l'UPN est en @entreprise.fr : connexion automatique OK et paquets correctement filtrés selon les groupes AD.

Merci à vous et à Denis pour le suivi

Cordialement,