• Guide, Sicurezza, Sistemi Operativi
• 11 Settembre 2025

È stato osservato che su Windows 11 24H2 e Windows Server 2025 un utente può autenticarsi anche se inserisce come nome utente un UPN con suffisso errato o non definito in Active Directory. In pratica, quando il suffisso del UPN non corrisponde ad alcun dominio noto o configurato, il sistema tenta comunque di autenticare l’utente usando la parte prima della @ come sAMAccountName nel dominio locale joinato.

In altre parole, Windows segue una procedura di autenticazione multi-step: prima prova con l’UPN fornito (Kerberos), e se questo fallisce o il dominio del UPN non viene trovato, effettua automaticamente un fallback al formato legacy DOMINIO\nomeutente (utilizzando il sAMAccountName nel dominio del computer). Questo spiega perché un logon con UPN “sbagliato” può comunque andare a buon fine utilizzando l’account corrispondente nel dominio AD locale.

Documentazione ufficiale sul cambiamento

Questo comportamento non è attualmente documentato da Microsoft come funzionalità ufficiale: potrebbe trattarsi di un bug o regressione introdotta con le nuove build. Non esiste oggi un metodo supportato per disabilitarlo, se non mitigazioni indirette (es. restrizioni NTLM, allineamento UPN).

Microsoft ha documentato il comportamento generale di risoluzione del nome utente in Active Directory, anche se non esiste al momento una nota esplicita nelle release notes di Windows 11/Server 2025 che annunci questa modifica. Tuttavia, le dinamiche di risoluzione UPN vs sAMAccountName sono descritte in fonti ufficiali e articoli tecnici:

• KB929272 (Windows Server 2003) – Questo articolo spiega i “stili di logon interattivo” e come il Kerberos Distribution Center (KDC) risolve l’UPN. In esso si chiarisce che un utente può accedere con un UPN esplicito (quello definito nell’attributo userPrincipalName) oppure con un UPN implicito composto da sAMAccountName@NomeDominioAD. Il KDC effettua il lookup in quest’ordine: prima cerca un UPN esplicito corrispondente; se il suffisso UPN coincide con il nome DNS o NETBIOS del dominio locale, interpreta il nome come UPN implicito e prova quindi a risolvere la parte utente come sAMAccountName nel dominio. Solo se questi tentativi falliscono, passa a referral Kerberos verso altri domini/foreste o alla Global Catalog. In passato, dunque, un UPN con suffisso non corrispondente ad alcun dominio/alternate UPN noto avrebbe causato il fallimento del logon dopo i tentativi di referral e GC.
  
• Conflitti tra UPN impliciti/espliciti – Un thread ufficiale sul forum Microsoft Technet (riportato su Server Fault) conferma indirettamente la logica di fallback: se due utenti condividono lo stesso “nome” prima della @, uno come sAMAccountName e un altro come UPN esplicito, il sistema dà precedenza all’UPN esplicito. Ad esempio, se il dominio è example.com, l’utente1 ha sAMAccountName “user1” e l’utente2 ha un UPN esplicito identico ([email protected]), un logon inserendo [email protected] autenticherà utente2. Se però l’UPN esplicito di utente2 viene cambiato (rendendo “[email protected]” inesistente come UPN), allora inserendo [email protected] al logon si accederà come utente1 tramite il suo sAMAccountName. Questo comportamento, documentato da Microsoft, dimostra che in assenza di un UPN esplicito valido il sistema “ricade” sull’account con sAMAccountName corrispondente nel dominio di default.
  

Queste informazioni confermano che il meccanismo di fallback esiste ed è parte del design di Active Directory (non necessariamente una novità assoluta), ma le versioni recenti di Windows sembrano applicarlo anche a scenari prima non consentiti. In Windows 11/Server 2025 si è notato che il fallback al dominio joinato avviene anche quando il suffisso dopo la @ non coincide con alcun dominio della foresta o di trust configurato. Microsoft non ha pubblicato articoli specifici di “Known Issue” o modifiche esplicite su questo nei documenti di Windows 11/Server 2025 finora, ma il comportamento è consistente con la logica Kerberos/NTLM sottostante: dopo il fallimento della ricerca Kerberos per UPN inesistente, Windows può tentare un’autenticazione NTLM utilizzando il dominio locale oppure, in alternativa, ripetere direttamente una nuova richiesta Kerberos sul sAMAccountName. Entrambe le modalità realizzano il fallback.

Cosa significa

Immaginiamo Beth, utente del dominio aziendale adatum.com.
Il suo UPN corretto è:

[email protected]

Tutto funziona come previsto.

Ma cosa succede se Beth, distratta, sbaglia a digitare e scrive:

[email protected]

Un suffisso inesistente, non configurato in Active Directory.
Eppure il logon va a buon fine.

Figura 1: UPN di Beth

Figura 2: Login con UPN errato

Figura 3: L’utente accede al dominio con l’UPN errato

Quello che potrebbe sembrare un bug è in realtà un comportamento by design:

• Windows prova a trattare ciò che l’utente ha scritto come un UPN esplicito (userPrincipalName).
  
  • Se il suffisso dopo la @ è definito nella foresta, tutto ok.
    
  • Se non lo è, il lookup fallisce.
    
• A questo punto entra in gioco il fallback:
  
  • La parte prima della @ (beth) viene interpretata come sAMAccountName.
    
  • La parte dopo la @ (aadtm.com), non trovando corrispondenza, viene ignorata.
    
  • Windows autentica Beth come se avesse digitato:
    
  • ADATUM\beth
    
• Se la password è corretta, l’utente entra comunque.
  

Risultato: anche scrivendo un UPN sbagliato, Beth ottiene accesso grazie al mapping sul sAMAccountName nel dominio joinato.

Prima e dopo: cosa cambia

• Fino a Windows Server 2019 / 2022: un UPN con suffisso errato portava a un secco logon failure.
  
• Con Windows 11 / Server 2025: il sistema “aiuta” l’utente, permettendo l’accesso tramite fallback automatico.
  

Possibilità di disabilitare il fallback

Attualmente non risultano policy di sicurezza o chiavi di registro dedicate per disabilitare selettivamente questo fallback dell’UPN a livello di sistema. Il comportamento è intrinseco al processo di logon di Windows. Tuttavia, esistono misure indirette che si possono adottare per impedirne l’efficacia:

• Restrizione dell’autenticazione NTLM: come accennato, il fallback al sAMAccountName avviene tipicamente mediante NTLM se il percorso Kerberos con l’UPN fallisce. Impedendo l’uso di NTLM, il logon non riuscirebbe in caso di UPN non risolto. Si può valutare l’uso delle policy “Network Security: Restrict NTLM” sul dominio (o sulle workstation) per vietare l’NTLM dove non necessario. Ad esempio, negando l’NTLM outgoing dalle workstation o incoming sui DC, Windows sarà costretto ad usare solo Kerberos (o fallire) e quindi un UPN con suffisso sconosciuto non permetterà l’accesso. Questa è una contromisura drastica che va testata con cautela, ma elimina il “fallback” automatico su canali meno sicuri. In alternativa, è possibile configurare il dominio in modo da rifiutare login che non usino Kerberos o da richiedere l’autenticazione al DC anche per gli unlock (evitando cache credenziali), impostazioni che però impattano scenari più ampi.
  
• Allineare UPN ed email/alias: come best practice amministrativa, assicurarsi che l’UPN degli utenti corrisponda al loro indirizzo email aziendale o comunque a ciò che gli utenti inseriscono normalmente. In questo modo si riduce la probabilità di errori di digitazione del suffisso. Microsoft consiglia di usare UPN “di default” (impliciti, basati sul DNS AD) a meno di specifiche necessità, proprio perché UPN alternativi possono introdurre confusione o conflitti. Garantire che i suffissi UPN alternativi siano configurati correttamente in Active Directory Domains and Trusts ed evitare suffix non univoci previene anomalie di risoluzione. Anche se non disabilita il fallback, questa pratica riduce i casi in cui un utente potrebbe autenticarsi con un suffisso errato.
  

Al momento non esiste una GPO “ufficiale” per forzare il rifiuto di credenziali UPN con suffisso non riconosciuto. L’assenza di documentazione su una policy specifica suggerisce che Microsoft non ha (ancora) previsto un toggle di configurazione per questo comportamento, probabilmente perché considerato un meccanismo di compatibilità.

Chiarezza sul rischio

Il fallback dell’UPN verso il sAMAccountName non è solo una curiosità tecnica: può introdurre rischi reali in contesti enterprise.

• Phishing interno: immaginiamo un attaccante che suggerisce agli utenti di loggarsi con [email protected]. L’utente scrive quell’UPN convinto che sia legittimo, il sistema lo accetta comunque e Beth entra. L’esperienza di “successo” rafforza l’idea che l’identificativo fosse corretto, creando terreno fertile per campagne di phishing o social engineering.
  
• Audit e forensic: nei log di sicurezza del DC, il tentativo appare come [email protected] (UPN errato), ma l’accesso effettivo registrato è ADATUM\beth. Un analista che indaga su un incidente può trovarsi davanti a eventi incoerenti: input diverso dall’account realmente autenticato, con il rischio di sottovalutare o interpretare male l’attacco.
  

Questo comportamento, quindi, complica sia la security awareness degli utenti sia le attività di monitoraggio e investigazione degli amministratori.

Rilevamento e mitigazione del rischio

Per individuare quando avvengono logon di questo tipo o mitigarne gli effetti, si possono adottare i seguenti approcci:

• Audit degli eventi di autenticazione: Abilitare la registrazione dettagliata degli eventi di logon (Account Logon/Logon Events) sui Domain Controller e sulle workstation. In particolare, un tentativo di accesso con UPN errato genererà inizialmente un evento di Kerberos Logon failure (4768 o 4771).
  
  • In alcuni casi il fallback produce un evento 4624 con Authentication Package = NTLM (sequenza 4771 → 4624).
    
  • In altri casi, invece, il fallback avviene direttamente in Kerberos: 4768 fail → 4768 success → 4624 Kerberos.
    Entrambi gli scenari indicano che il suffisso errato è stato ignorato e l’utente autenticato tramite il sAMAccountName.
    
  • Questo può essere un indicatore che l’UPN iniziale non è stato risolto e si è ripiegato su NTLM. Monitorare nei log sicurezza quante autenticazioni NTLM avvengono per account che potrebbero usare Kerberos (UPN corretto) aiuta a identificare questi casi.
    
• Analisi dei pattern nei log: Se si sospetta che gli utenti stiano inserendo suffissi UPN sbagliati, è utile confrontare il nome utente riportato nei diversi eventi di autenticazione. Ad esempio, nel nostro scenario:
  
  • Beth dovrebbe autenticarsi con [email protected].
    
  • Ma se digita [email protected], nei log di sicurezza può comparire prima un tentativo con quell’UPN inesistente.
    
  • In un ambiente on-prem puro, il suffisso errato (aadtm.com) può comparire in eventi di errore Kerberos (ad esempio 4771 – Kerberos pre-authentication failed con codice KDC_ERR_S_PRINCIPAL_UNKNOWN) o nei log di sicurezza lato client.
    
  • Subito dopo, se avviene il fallback, il Domain Controller registrerà un logon riuscito (4624 – Logon success) dove l’account effettivo autenticato sarà ADATUM\beth.
    
  • Questi dettagli non sono immediatamente evidenti nei soli log di successo, perché lì vediamo solo l’account risolto. È quindi fondamentale auditare anche i fallimenti e incrociare le informazioni per far emergere i tentativi con UPN non standard come [email protected].
    
• Strumenti e script: Non risultano tool Microsoft dedicati esclusivamente a questo controllo. Tuttavia, è possibile usare script PowerShell per confrontare gli attributi mail, userPrincipalName e sAMAccountName degli utenti in AD, identificando discrepanze. Un utente che tende a inserire l’email al posto dell’UPN, ad esempio, potrebbe avere UPN diverso dalla mail. Uniformare questi valori mitiga all’origine il problema. In aggiunta, soluzioni di log management/SIEM possono essere configurate con alert che segnalino autenticazioni NTLM interattive anomale o eventi Kerberos con KDC_ERR_S_PRINCIPAL_UNKNOWN (principal sconosciuto) seguiti da successo dello stesso utente via NTLM.
  

In pratica: un 4771 con UPN errato seguito da un 4624 con NTLM è l’indicatore più chiaro che si è verificato un fallback da UPN a sAMAccountName.

Come verificarlo

Si può riprodurre facilmente il comportamento in lab:

• Creare un utente beth con UPN [email protected].
  
• Provare il logon con [email protected].
  
• Osservare i log eventi sul DC:
  

prima uno o più tentativi Kerberos fallito (KDC_ERR_S_PRINCIPAL_UNKNOWN).

• Se il client usa NTLM come fallback, subito dopo compare un 4624 NTLM riuscito con ADATUM\beth.
  
• Se invece il fallback rimane in Kerberos, vedremo un 4768 di successo seguito da un 4624 Kerberos con ADATUM\beth.
  

Figura 4: Eventi di login dell’utente Beth

Figura 5: Evento 4768 – Emissione del ticket kerberos fallita per l’UPN errato

Figura 6: Evento 4768 – Emissione del ticket kerberos per il sAMAccountName

Figura 7: Evento 4624 – Login effettuato da parte di Beth

Mitigazioni possibili

• Allineare UPN ed email aziendale: riduce errori e ambiguità.
  
• Limitare i suffissi UPN configurati nella foresta: meno possibilità di confusione.
  
• Monitorare i logon NTLM e gli errori Kerberos 4771 seguiti da successi NTLM.
  
• Valutare la restrizione NTLM tramite policy di dominio: drastico, ma impedisce il fallback.
  

In sintesi, Microsoft non ha (finora) pubblicato una documentazione ufficiale che annunci esplicitamente questa modifica di comportamento per Windows 11/Windows Server 2025. Il fenomeno è però spiegabile alla luce delle regole di risoluzione UPN già presenti in Active Directory da tempo. Il fallback automatico al sAMAccountName nel dominio locale può risultare sorprendente, ma è coerente con la necessità di mantenere compatibilità con formati legacy e con l’uso di NTLM come ripiego. Per disabilitarlo occorrono misure indirette (es. bloccare NTLM), mentre per rilevarlo è necessario monitorare accuratamente i log di autenticazione. Di seguito sono riportate le fonti ufficiali e i riferimenti tecnici che confermano questi comportamenti e suggeriscono le best practice correlate:

• KB Microsoft 929272 – “Interactive logon styles and KDC account lookup”
  
• Forum Technet/ServerFault – discussione su UPN impliciti vs espliciti e conflitti di accesso
  
• Approfondimento tecnico (ServerDevWorker) su processo di autenticazione UPN vs SAM. (Non ufficiale, ma utile per comprendere il meccanismo di fallback)
  
• Documentazione Microsoft sulla restrizione di NTLM e considerazioni sulla sicurezza dell’autenticazione (per valutare mitigazioni).
  

ICTPower PowerShell AD Tools

Nel repository GitHub nicferr/powershell-ad-tools troverete due script PowerShell: Find-UpnFallback4768.ps1 e Get-ADUserLoginForms.ps1.

Per poter utilizzare i due scripts è necessario abilitare l’audit avanzato di Active Directory. Per farlo è possibile utilizzare il seguente comando:

In alternativa potete utilizzare una Group Policy da distribuire ai Domain Controller che abiliti l’auditing policy “Audit Kerberos Authentication Service” da Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Logon → Audit Kerberos Authentication Service e l’auditing policy “Audit Logon”

Figura 8: Abilitazione dell’auditing policy “Audit Kerberos Authentication Service”

Figura 9: Abilitazione dell’auditing policy “Audit Logon”

NB: nei grandi ambienti questi log sono normalmente abilitati. Qualora non lo fossero, tenere in considerazione:

• Dimensione Security log: alza il max size (es. 1–2 GB) e retention su “Overwrite events as needed”, o rischi di perdere gli eventi.
  
• Time sync: assicurati che DC e client siano allineati (NTP). La correlazione 4771→4624 si basa sui timestamp.
  
• NTLM nel 4624: nello script cerchiamo 4624 con AuthenticationPackageName = NTLM. Se lo hai bloccato, è “expected” non trovarlo (e il fallback… non avviene).
  

Find-UpnFallback4768.ps1 permette di cercare nei log la sequenza “sospetta” di EventID nei log (4771 -> 4626). Per eseguirlo è sufficiente eseguire i comandi:

Per cercare sequenze sospette in tutto il dominio:

Come leggere l’output:

• FirstSeen_4771_User: l’UPN tentato (es. [email protected]) che il DC non ha trovato.
  
• Then_4624_User: l’account effettivamente autenticato subito dopo (es. ADATUM\beth) con Auth = NTLM.
  
• CorrelationSeconds: distanza temporale tra i due eventi (tipicamente pochi secondi).
  
• Se vedete questa coppia 4771 (principal unknown) → 4624 (NTLM) per lo stesso IP e lo stesso “prefisso” utente, hai un forte indicatore di fallback UPN→sAM.
  

Figura 10: Output dello script Find-UpnFallback4768 .ps1

Il secondo script, invece, enumera tutte le forme di logon plausibili per un utente AD (UPN, DOMINIO\sam, sam@DNS, sam@NETBIOS, suffissi UPN di foresta) e, con -TestCredentials, le prova davvero contro il dominio per dirti quali funzionano.

Come leggere l’output:

• La prima riga “header” mostra UPN, sAMAccountName, dominio DNS/NetBIOS e i suffissi UPN configurati.
  
• La tabella elenca le stringhe di logon generate:
  
  • LoginForm = cosa l’utente potrebbe digitare.
    
  • Kind = tipo (UPN registrato, DOM\sam, ecc.).
    
  • IsUPN = se è (o sarebbe) un UPN vero.
    
  • Validated = con -TestCredentials, True/False indica se quella forma autentica davvero.
    
• Se vedi che [email protected] risulta Validated=True, significa che il sistema ha fatto fallback e in realtà ha autenticato ADATUM\beth.
  

(Tradotto: se qualcosa “sembra UPN ma non lo è”, qui lo si vede a “colpo d’occhio”.)

Figura 11: Output dello script Get-ADUserLoginForms .ps1

Conclusioni

Quello che per l’utente sembra un “colpo di fortuna” è in realtà un cambiamento di design introdotto con Windows 11 / Windows Server 2025.
Il messaggio per gli amministratori AD è chiaro:

• Non date per scontato che un login con UPN inesistente fallisca.
  
• Mettete in conto questo fallback nei vostri piani di auditing e hardening.