Comprendere e risolvere l'errore AADSTS50107 Requested Federation Realm Does Not Exist
By Mirko Peters ·
Se ti è mai capitato di vedere il temutissimo errore «AADSTS50107: Requested Federation Realm Does Not Exist» mentre provavi ad accedere a Microsoft 365, sai già…
Automatically translated with AI from the original post. Read the English original

Se ti è mai capitato di vedere il temutissimo errore «AADSTS50107: Requested Federation Realm Does Not Exist» mentre provavi ad accedere a Microsoft 365, sai già quanto l'accesso possa bloccarsi all'improvviso. Questo errore non è un semplice fallimento generico del login: indica nello specifico un errore di configurazione nell'autenticazione tra Microsoft 365 (o Entra ID/Azure AD) e il tuo identity provider, come ADFS o Okta.
In parole semplici, Microsoft 365 tenta di reindirizzare l'utente a un accesso federato per il suo dominio, ma non trova un "oggetto realm di federazione" corrispondente. Questo realm è un'impostazione fondamentale che collega il tuo dominio a un IdP: è il collante che rende possibile il single sign-on. Quando manca o è impostato in modo errato, né Microsoft 365 né Azure riescono ad autenticare gli accessi di quegli utenti, con conseguenti blocchi e richieste di supporto.
Questa guida ti permette di non dover correre ai ripari quando gli errori di federazione mettono a rischio la continuità operativa. Ti proponiamo gli approcci di risoluzione dei problemi, le correzioni e i metodi di prevenzione necessari per mantenere saldo il governo delle identità. Per le organizzazioni che lavorano nel cloud, mantenere in buono stato i realm di federazione è essenziale per un accesso sicuro e prevedibile. Cerchi strategie di governance più ampie? L'importanza di una governance del cloud applicata con rigore è illustrata in guide come Azure enterprise governance strategy, così come nell'analisi di casi reali di violazione in Microsoft 365 attack chain explained.
Cause principali e risoluzione dei problemi per gli errori di realm di federazione nell'accesso a Microsoft 365
Vediamo perché compare l'errore «Requested Federation Realm Does Not Exist». Nove volte su dieci ti trovi davanti a un dominio configurato come federato, ma il collegamento richiesto con l'identity provider manca o non funziona. Microsoft 365 vuole delegare l'autenticazione, ma dall'altra parte nessuno risponde: di solito la causa sono voci mancanti o digitate in modo errato nella configurazione di Azure AD o nell'IdP.
A volte basta un errore di ortografia nel valore del dominio o del realm. In altri casi un amministratore ha convertito un dominio dallo stato «gestito» a quello «federato» (o viceversa) senza ripulire tutti i riferimenti, e i server di accesso Microsoft non riescono quindi a stabilire quale IdP usare. Negli ambienti con più IdP o ibridi il problema può complicarsi, con conflitti di realm quando più provider reclamano lo stesso dominio.
Una causa spesso trascurata è una mancata corrispondenza dell'Issuer URI tra il tuo identity provider e quanto previsto da Azure AD. Se i valori non coincidono, l'autenticazione non si completa mai: un classico errore in SAML e nelle configurazioni ADFS. Le integrazioni complesse, soprattutto con provider di federazione di terze parti come Okta o PingFederate, possono introdurre problemi specifici se configurazioni o metadati non sono aggiornati.
Per ridurre i tempi di risoluzione, verifica sempre lo stato di federazione del dominio, la configurazione esatta dell'oggetto realm e il rispetto dello standard dell'Issuer URI. Una revisione proattiva della configurazione di federazione, soprattutto durante le migrazioni e dopo modifiche importanti ai criteri, può evitarti un sovraccarico di richieste al servizio di supporto. Per approfondire i rischi legati alla configurazione delle identità e le insidie dei criteri di accesso, trovi spunti utili in contenuti come Entra ID conditional access security e Microsoft 365 data access and ownership governance: entrambi spiegano in dettaglio come gli errori nella gestione degli accessi creino problemi in seguito.
Passaggi di risoluzione e soluzione per gli errori di realm di federazione AADSTS50107
Quindi i tuoi utenti sono bloccati con AADSTS50107. Da dove si comincia? Primo passo: verifica il metodo di autenticazione attuale del dominio usando PowerShell o l'interfaccia di amministrazione di Microsoft 365. Se il dominio è impostato come federato ma non ha un oggetto realm valido, la soluzione di solito consiste nel rieseguire la configurazione della federazione. Usa il cmdlet Set-MsolDomainAuthentication per registrare correttamente i parametri di federazione del dominio con i dati corretti dell'IdP.
Se usi un identity provider locale come ADFS, ricontrolla la configurazione della Relying Party Trust. È sorprendentemente facile trovare un Issuer URI configurato male o non aggiornato, e Azure AD è molto esigente: deve corrispondere esattamente. Se usi un IdP di terze parti (ad esempio Okta o PingFederate), assicurati che i metadati dell'IdP esterno, incluso il messaggio di risposta SAML, corrispondano a quanto Microsoft 365 si aspetta per il tuo dominio.
Negli ambienti ibridi o con più provider, verifica con attenzione tutte le impostazioni di federazione che si sovrappongono. Se più di un sistema ritiene di "possedere" il realm per un determinato dominio, il risultato è un caos di autenticazione. Dopo ogni modifica, convalida sempre lo stato di federazione del dominio usando i moduli PowerShell più recenti o il portale di Azure.
Mentre ricolleghi questi punti della federazione, documenta ogni modifica e comunica agli utenti quando sono previste interruzioni dell'accesso. Per gli amministratori più attenti alla sicurezza, è utile rivedere e rafforzare i controlli su consenso e OAuth per prevenire accessi laterali, come spiegato in dettaglio in Entra ID OAuth consent attack explained. In questo modo non chiudi una falla aprendone un'altra, più subdola.
Feedback, soluzioni e dove ottenere aiuto per i problemi con gli oggetti realm della federazione
Quando si tratta di grattacapi con il realm della federazione, la community tecnica Microsoft è una miniera d'oro. Molti amministratori hanno condiviso soluzioni alternative, come passare un dominio da "gestito" a "federato" e di nuovo indietro per forzare una configurazione pulita, oppure acquisire i token SAML con Fiddler per individuare i valori del realm che non coincidono tra i vari sistemi.
Non sottovalutare il valore di porre domande in sedi come i forum ufficiali Microsoft, i gruppi Slack della community o, se la situazione si complica, rivolgendoti a un consulente professionista. Errori persistenti o strani possono nascondere problemi invisibili, come metadati obsoleti, account guest non più utilizzati o criteri di accesso condizionale che entrano in conflitto con i confini di attendibilità della federazione. Per questo, il dialogo continuo con i canali di supporto e con altri professionisti IT può essere molto più efficace che combattere da soli.
Inoltre, tieni d'occhio le best practice in evoluzione per l'accesso condizionale e il contesto di autenticazione. Altri amministratori hanno segnalato più volte che eccezioni troppo ampie o inviti a utenti guest diventano rapidamente un incubo per accessi e sicurezza. Lo confermano guide come Conditional Access policy trust issues e the risks of M365 guest accounts.
Se sei indeciso o alle prese con un problema complicato che nessun altro sembra aver risolto, non esitare a portare il tuo scenario nella community. I riscontri reali, tra successi, fallimenti e persino quei tentativi del tipo "e se provassi questo?", sono ciò che mantiene la conoscenza aggiornata e le soluzioni concrete. Più voci partecipano alla conversazione, più rapidamente questi errori di realm della federazione perdono la loro capacità di interrompere la tua giornata.
Prevenire futuri errori AADSTS50107 con le best practice per la federazione
- Convalida la federazione del dominio prima della distribuzione: prima di andare in produzione, usa strumenti come PowerShell per verificare lo stato della federazione e assicurarti che ogni dominio federato sia associato a un identity provider attivo.
- Standardizza e allinea i formati dell'Issuer URI: verifica che l'Issuer URI in ogni IdP e in Microsoft Entra ID sia identico: anche una barra in più o un refuso può bloccare gli accessi.
- Mantieni aggiornati i metadati dell'IdP: aggiorna i metadati SAML per i provider di terze parti come ADFS, Okta o PingFederate. Le informazioni obsolete causano disallineamenti degli oggetti realm della federazione e fallimenti dell'autenticazione.
- Documenta e rivedi regolarmente tutte le impostazioni di federazione: pianifica audit periodici della configurazione, soprattutto dopo grandi aggiornamenti, fusioni o migrazioni. Piccoli errori possono diventare un problema serio se non vengono controllati.
- Mantieni controlli di governance rigorosi e cicli regolari di revisione degli accessi: non lasciare che le configurazioni di federazione o gli accessi degli ospiti proliferino senza controllo. Per le buone pratiche di governance puoi consultare risorse come Power Platform security governance oppure scoprire come ottenere una sicurezza solida di Microsoft 365 senza penalizzare gli utenti su unlock ironclad M365 security.
Seguire questi passaggi preventivi può aiutarti a evitare i problemi legati ad AADSTS50107 prima ancora che un utente debba chiedere assistenza.