[RESOLVED] 2.7.0.19593 Self-Service: 403 WRONG_PASSWORD_USERNAME if UPN suffix differs from the AD domain (regression 2.6→2.7)

[massimo]

Version : 2.7.0.19593-10b94c8e (server, agent and console)
Edition: Enterprise
Server : Debian 12
Positions: Windows 11, hybrid AD + Enterprise join

Good morning,

Since the update to version 2.7.0.19593, the Self-Service feature is rejecting our standard users. It worked in version 2.6. This problem has been reproduced on our test machines with the 2.7 agent.

Context
- AD domain: domain.local (NetBIOS DOMAIN)
- User UPN: @entreprise.fr (alternative UPN suffix, Entra synchronization)
- UPN of administrative accounts: @domain.local
- default service_auth_type (filetoken)

Symptom

Code: Select all

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

In waptservice.log:

Code: Select all

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

Tests (all failed for an account whose UPN is @entreprise.fr)
- Automatic session (filetoken): unable to find session or local profile for user user@domain.local
- "Switch user" + user@domain.local + password: same refusal
- "Change user" + DOMAIN\user + password: same refusal (for user DOMAIN\user)
- "Switch user" + user@entreprise.fr + password: Invalid service response for GetLocalServiceToken, no token.
- service_auth_type = system: same result

On the same machine, the user_adm account (UPN user_adm@domain.local) connects without any problems.
No local accounts with the same name exist on the posts.

Analysis
The agent seems to be normalizing the name by<sAMAccountName> @<domaine DNS AD> instead of using the actual UPN (userPrincipalName) or the session SID, which fails when the UPN suffix differs from the domain. This is likely related to the new 2.7 feature "users and groups are fully qualified names for authentication and self-service ACLs (no fallback on short name)".
The topic “WAPT Selfservice: Error 666” (viewtopic.php?t=4651) perhaps describes the same case (users denied, admin accounts OK).

Questions
1. Is this behavior known, and is a fix planned?
2. Is there an agent setting that allows the actual UPN or SID of the session to be used instead of sAMAccountName@DNS_domain?

THANKS,

[dcardon]

Hi Maxime,

there is indeed a bug at this level. UPN management isn't working correctly. We have an initial patch internally, and we'll get back to you very soon as it's validated.

The self-service access management has been improved to query the local LSA layer rather than Active Directory to better handle cases where corporate network connectivity is only partial or completely disconnected (the Windows LSA layer does caching and does it quite well, even if its handling of connection timeouts can be a bit erratic at times).

Sorry for the inconvenience; we need to add more UPN users to our internal tests...

Best regards,

Denis

[massimo]

Hello Denis,

Thank you for your quick response and confirmation. We are available to test the patch on our test machines as soon as it is ready, if that would help you validate it.

Sincerely,

[sfonteneau]

Hello,

I have just released version 2.7.0.19597 which should resolve the issue (tested at another client's site).

You can try again and get back to us.

[massimo]

Hello,

Thank you for your quick response! After updating the server and agent, Self-Service is working again for users whose UPN is @entreprise.fr: automatic login is OK and packets are correctly filtered according to AD groups.

Thank you to you and Denis for the follow-up

. Best regards,