[RISOLTO] 2.7.0.19593 Self-Service: 403 WRONG_PASSWORD_USERNAME se il suffisso UPN è diverso dal dominio AD (regressione 2.6→2.7)

[massimo]

Versione: 2.7.0.19593-10b94c8e (server, agente e console)
Edizione: Impresa
Server: Debian 12
Posizioni: Windows 11, join ibrido AD + Enterprise

Buongiorno,

Dopo l'aggiornamento alla versione 2.7.0.19593, la funzionalità Self-Service non consente più l'accesso ai nostri utenti standard. Nella versione 2.6 funzionava correttamente. Il problema è stato riprodotto anche sulle nostre macchine di test con l'agente 2.7.

Contesto
- Dominio AD: domain.local (dominio NetBIOS)
- UPN utente: @entreprise.fr (suffisso UPN alternativo, sincronizzazione Entra)
- UPN degli account amministrativi: @dominio.local
- tipo di autenticazione del servizio predefinito (filetoken)

Sintomo

Codice: Seleziona tutto

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

Nel file waptservice.log:

Codice: Seleziona tutto

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

Test (tutti falliti per un account il cui UPN è @entreprise.fr)
- Sessione automatica (filetoken): impossibile trovare la sessione o il profilo locale per l'utente utente@dominio.local
- "Cambia utente" + utente@dominio.local + password: stesso rifiuto
- "Cambia utente" + DOMINIO\utente + password: stesso rifiuto (per l'utente DOMINIO\utente)
- "Cambia utente" + user@entreprise.fr + password: Risposta del servizio non valida per GetLocalServiceToken, nessun token.
- service_auth_type = system: stesso risultato

Sulla stessa macchina, l'account user_adm (UPN) utente_amministratore@dominio.local) si connette senza problemi.
Nei post non risultano account locali con lo stesso nome.

Analisi
L'agente sembra normalizzare il nome<sAMAccountName> @<domaine DNS AD> Invece di utilizzare l'UPN (userPrincipalName) effettivo o il SID di sessione, che fallisce quando il suffisso UPN è diverso dal dominio. Questo è probabilmente correlato alla nuova funzionalità 2.7 "utenti e gruppi sono nomi completi per l'autenticazione e gli ACL self-service (nessun fallback sul nome breve)".
L'argomento "Selfservice WAPT: errore 666" (viewtopic.php?t=4651) forse descrive lo stesso caso (utenti negati, account amministratore OK).

Domande
1. Questo comportamento è noto ed è prevista una soluzione?
2. Esiste un'impostazione dell'agente che consenta di utilizzare l'UPN o il SID effettivo della sessione anziché sAMAccountName@DNS_domain?

GRAZIE,

[dcardon]

Ciao Maxime,

effettivamente c'è un bug a questo livello. La gestione UPN non funziona correttamente. Abbiamo una patch iniziale interna e ti ricontatteremo al più presto non appena sarà validata.

La gestione degli accessi self-service è stata migliorata per interrogare il livello LSA locale anziché Active Directory, in modo da gestire meglio i casi in cui la connettività alla rete aziendale è solo parziale o completamente interrotta (il livello LSA di Windows esegue la cache e lo fa piuttosto bene, anche se la sua gestione dei timeout di connessione può essere a volte un po' irregolare).

Ci scusiamo per l'inconveniente; dobbiamo aggiungere altri utenti UPN ai nostri test interni...

Cordiali saluti,

Denis

[massimo]

Ciao Denis,

grazie per la rapida risposta e conferma. Siamo disponibili a testare la patch sulle nostre macchine di prova non appena sarà pronta, se questo ti può essere d'aiuto per convalidarla.

Cordiali saluti,

[sfontenau]

Ciao,

ho appena rilasciato la versione 2.7.0.19597 che dovrebbe risolvere il problema (testata presso un altro cliente).

Puoi riprovare e farci sapere.

[massimo]

Salve,

grazie per la rapida risposta! Dopo l'aggiornamento del server e dell'agente, il Self-Service funziona di nuovo per gli utenti il ​​cui UPN è @entreprise.fr: l'accesso automatico è OK e i pacchetti vengono filtrati correttamente in base ai gruppi AD.

Grazie a lei e a Denis per il follow-up

. Cordiali saluti,