Individuazione dell'area di autenticazione principale per un'applicazione

  • Articolo

Individuazione dell'area di autenticazione principale (HRD) è il processo che consente a Microsoft Entra ID di determinare il provider di identità (IDP) con cui un utente deve eseguire l'autenticazione al momento dell'accesso. Quando un utente accede a un tenant di Microsoft Entra per accedere a una risorsa o alla pagina di accesso comune di Microsoft Entra, digita un nome utente (UPN). Microsoft Entra ID usa tale id per individuare dove l'utente deve accedere.

L'utente viene portato a uno dei provider di identità seguenti per l'autenticazione:

  • Il tenant principale dell'utente (potrebbe essere lo stesso tenant della risorsa a cui l'utente sta cercando di effettuare l'accesso).

  • Account Microsoft. L'utente è un guest nel tenant di risorse che usa un account consumer per l'autenticazione.

  • Un provider di identità locale, ad esempio Active Directory Federation Services (AD FS).

  • Un altro provider di identità federato con il tenant di Microsoft Entra.

Accelerazione automatica

Alcune organizzazioni configurano i domini nel tenant di Microsoft Entra per la federazione con un altro IdP, ad esempio AD FS per l'autenticazione utente.

Quando un utente accede a un'applicazione, viene visualizzata per la prima volta una pagina di accesso a Microsoft Entra. Dopo aver digitato l'UPN, se si trova in un dominio federato, viene visualizzata la pagina di accesso del provider di identità che gestisce il dominio. In alcuni casi, è consigliabile per gli amministratori indirizzare gli utenti alla pagina di accesso quando accedono ad applicazioni specifiche.

Di conseguenza, gli utenti possono ignorare la pagina iniziale di Microsoft Entra ID. Questo processo viene definito "accelerazione automatica dell'accesso". Microsoft non consiglia più di configurare l'accelerazione automatica, in quanto può impedire l'uso di metodi di autenticazione più efficaci, ad esempio FIDO e impedisce la collaborazione. Per informazioni sui vantaggi della mancata configurazione dell'accelerazione automatica, vedere Abilitare l'accesso tramite chiave di sicurezza senza password. Per informazioni su come impedire l'accelerazione automatica dell'accesso, vedere Disabilitare l'accesso con accelerazione automatica.

Nei casi in cui il tenant è federato a un altro provider di identità per l'accesso, l'accelerazione automatica semplifica maggiormente l'accesso. È possibile configurare l'accelerazione automatica per singole applicazioni. Vedere Configurare l'accelerazione automatica per informazioni su come forzare l'accelerazione automatica usando HRD.

Nota

Se si configura un'applicazione per l'accelerazione automatica, gli utenti non possono usare credenziali gestite (ad esempio FIDO) e gli utenti guest non possono accedere. Se si accede direttamente a un IdP federato per l'autenticazione, non è possibile tornare alla pagina di accesso di Microsoft Entra. Gli utenti guest, che potrebbero dover essere indirizzati ad altri tenant o a un IdP esterno, ad esempio un account Microsoft, non possono accedere a tale applicazione perché ignorano il passaggio HRD.

Esistono tre modi per controllare l'accelerazione automatica in un IdP federato:

  • Usare un hint di dominio o richieste di autenticazione per un'applicazione.
  • Configurare un criterio HRD per forzare l'accelerazione automatica
  • Configurare un criterio HRD per ignorare gli hint di dominio da applicazioni specifiche o per determinati domini.

Finestra di dialogo di conferma del dominio

A partire da aprile 2023, le organizzazioni che usano l'accelerazione automatica o i collegamenti intelligenti potrebbero iniziare a visualizzare una nuova schermata aggiunta all'interfaccia utente di accesso. Questa schermata è la finestra di dialogo di conferma del dominio, fa parte dell'impegno generale di Microsoft per la protezione avanzata e richiede all'utente di confermare il dominio del tenant in cui accede. Annullare il flusso di autenticazione e contattare l'amministratore IT (se applicabile) se viene visualizzata la finestra di dialogo di conferma del dominio e non si riconosce il dominio tenant elencato. Di seguito è riportato un esempio dell'aspetto della finestra di dialogo di conferma del dominio:

Screenshot of the domain confirmation dialog listing the sign-in identifier '<kelly@contoso.com>' with a tenant domain of 'contoso.com'.

L'identificatore nella parte superiore della finestra di dialogo, kelly@contoso.com, rappresenta l'identificatore usato per l'accesso. Il dominio tenant elencato nell'intestazione e nel sottotitolo della finestra di dialogo mostra il dominio del tenant principale dell'account.

Anche se non è necessario visualizzare la finestra di dialogo di conferma del dominio per ogni istanza di accelerazione automatica o collegamenti intelligenti, la finestra di dialogo di conferma del dominio indica l'accelerazione automatica e i collegamenti intelligenti non possono più procedere senza problemi quando vengono visualizzati. Se l'organizzazione cancella i cookie a causa dei criteri del browser o in caso contrario, è possibile che si verifichi la finestra di dialogo di conferma del dominio più frequentemente. Infine, dato che Microsoft Entra ID gestisce il flusso di accesso end-to-end dell'accelerazione automatica, l'introduzione della finestra di dialogo di conferma del dominio non dovrebbe comportare interruzioni dell'applicazione.

Inoltre, è possibile eliminare la finestra di dialogo di conferma del dominio configurando un criterio restrizioni tenant v2 (TRv2). Un criterio TRv2 ottiene lo stesso comportamento di sicurezza della finestra di dialogo di conferma del dominio e pertanto, quando nella richiesta è presente un'intestazione dei criteri TRv2, la finestra di dialogo di conferma del dominio viene eliminata.

Hint di dominio

Gli hint di dominio sono direttive incluse nella richiesta di autenticazione da un'applicazione. Possono essere usate per accelerare l'indirizzamento dell'utente alla rispettiva pagina di accesso dell'IdP federato. Le applicazioni multi-tenant possono anche usarle per accelerare l'utente direttamente alla pagina di accesso di Microsoft Entra personalizzata per il tenant.

Ad esempio, l'applicazione "largeapp.com" potrebbe consentire ai clienti di accedere all'applicazione in un URL personalizzato "contoso.largeapp.com". L'app può includere anche un hint di dominio per contoso.com nella richiesta di autenticazione.

La sintassi degli hint di dominio varia a seconda del protocollo usato e viene in genere configurata nell'applicazione nei modi seguenti:

  • Per le applicazioni che usano il parametro WS-Federation: whr stringa di query. Ad esempio, whr=contoso.com.

  • Per le applicazioni che usano SAML: una richiesta di autenticazione SAML che contiene un hint di dominio o una stringa di query whr=contoso.com.

  • Per le applicazioni che usano il parametro OpenID Connessione: domain_hint stringa di query. Ad esempio, domain_hint=contoso.com.

Per impostazione predefinita, Microsoft Entra ID tenta di reindirizzare l'accesso al provider di identità configurato per un dominio se sono soddisfatte entrambe le condizioni seguenti:

  • Un hint di dominio è incluso nella richiesta di autenticazione dall'applicazione e
  • Il tenant è federato con tale dominio.

Se l'hint di dominio non fa riferimento a un dominio federato verificato, viene ignorato.

Nota

Se un hint di dominio viene incluso in una richiesta di autenticazione e deve essere rispettato, la presenza sostituisce l'accelerazione automatica impostata per l'applicazione nei criteri HRD.

Criteri HRD per l'accelerazione automatica

Alcune applicazioni non offrono un modo per configurare la richiesta di autenticazione che generano. In questi casi non è possibile usare hint di dominio per controllare l'accelerazione automatica. L'accelerazione automatica può essere configurata tramite i criteri di individuazione dell'area di autenticazione principale per ottenere lo stesso comportamento.

Criteri HRD per impedire l'accelerazione automatica

Alcune applicazioni Microsoft e SaaS includono automaticamente domain_hints (ad esempio, https://outlook.com/contoso.com genera una richiesta di accesso con &domain_hint=contoso.com accodamento), che può interrompere l'implementazione di credenziali gestite come FIDO. È possibile usare i criteri di individuazione dell'area di autenticazione principale per ignorare gli hint di dominio di determinate app o per determinati domini durante l'implementazione delle credenziali gestite.

Abilitare l'autenticazione ROPC diretta degli utenti federati per le applicazioni legacy

La procedura consigliata consiste nell'usare le librerie di Microsoft Entra e l'accesso interattivo per autenticare gli utenti. Le librerie si occupano dei flussi dell'utente federato. A volte le applicazioni legacy, in particolare le applicazioni che usano le credenziali della password del proprietario della risorsa (ROPC), inviano nome utente e password direttamente all'ID Microsoft Entra e non vengono scritte per comprendere la federazione. Non eseguono HRD e non interagiscono con l'endpoint federato corretto per autenticare un utente. Se si sceglie di usare i criteri di individuazione dell'area di autenticazione principale per abilitare applicazioni legacy specifiche che inviano credenziali nome utente/password usando la concessione ROPC per eseguire l'autenticazione direttamente con Microsoft Entra ID, la sincronizzazione dell'hash delle password deve essere abilitata.

Importante

Abilitare l'autenticazione diretta solo se è stata attivata la sincronizzazione degli hash password e se è nota la possibilità di eseguire l'autenticazione di questa applicazione senza eventuali criteri implementati dal provider di identità in locale. Se si disattiva la sincronizzazione degli hash password o si disattiva la sincronizzazione della directory con Active Directory Connect per qualsiasi motivo, è necessario rimuovere questo criterio per impedire l'insorgere di autenticazione diretta usando un hash della password non aggiornata.

Impostare i criteri HRD

Esistono tre passaggi per impostare i criteri HRD in un'applicazione per l'accelerazione automatica dell'accesso federato o le applicazioni dirette basate sul cloud:

  1. Creazione di un criterio HRD.

  2. Individuazione dell'entità servizio a cui collegare i criteri.

  3. Collegamento del criterio all'entità servizio.

I criteri hanno effetto solo per un'applicazione specifica quando sono collegati a un'entità servizio.

Un solo criterio HRD può essere attivo in un'entità servizio in qualsiasi momento.

È possibile usare i cmdlet di PowerShell di Microsoft Graph per creare e gestire i criteri HRD.

L'oggetto json è una definizione di criteri HRD di esempio:

{  
  "HomeRealmDiscoveryPolicy":
  {  
    "AccelerateToFederatedDomain":true,
    "PreferredDomain":"federated.example.edu",
    "AllowCloudPasswordValidation":false
  }
}

Il tipo di criterio è "HomeRealmDiscoveryPolicy".

AccelerateToFederatedDomain è facoltativo. Se AccelerateToFederatedDomain è falso, i criteri non hanno alcun effetto sull'accelerazione automatica. Se AccelerateToFederatedDomain è true e nel tenant è presente un solo dominio verificato e federato, gli utenti vengono portati direttamente al provider di identità federato per l'accesso. Se è true e nel tenant sono presenti più domini verificati, è necessario specificare PreferredDomain .

PreferredDomain è facoltativo. PreferredDomain deve indicare un dominio al quale accelerare. Può essere omesso se il tenant dispone di un solo dominio federato. Se viene omesso e sono presenti più domini federati verificati, il criterio non ha alcun effetto.

Se PreferredDomain è specificato, deve corrispondere a un dominio federato verificato per il tenant. Tutti gli utenti dell'applicazione devono essere in grado di accedere a tale dominio. Gli utenti che non possono accedere al dominio federato vengono intrappolati e non riescono a completare l'accesso.

AllowCloudPasswordValidation è facoltativo. Se AllowCloudPasswordValidation è true, l'applicazione può autenticare un utente federato presentando le credenziali di nome utente/password direttamente all'endpoint del token Microsoft Entra. Tale operazione viene eseguita solo se la sincronizzazione degli hash delle password è abilitata.

Esistono anche due opzioni HRD a livello di tenant, non illustrate in precedenza:

Priorità e valutazione dei criteri HRD

È possibile creare criteri HRD e assegnarli a specifiche organizzazioni e entità servizio. Ciò significa che è possibile applicare più criteri a un'applicazione specifica, quindi Microsoft Entra ID deve decidere quale ha la precedenza. Un set di regole decide quali criteri HRD (di molti applicati) hanno effetto:

  • Se nella richiesta di autenticazione è presente un hint di dominio, i criteri HRD per il tenant (i criteri impostati come predefinito del tenant) vengono controllati per verificare se gli hint di dominio devono essere ignorati. Se sono consentiti hint di dominio, viene usato il comportamento specificato dall'hint di dominio.

  • In caso contrario, se un criterio viene assegnato in modo esplicito all'entità servizio, viene applicato.

  • Se non è presente alcun hint per il dominio e nessun criterio viene assegnato in modo esplicito all'entità servizio, viene applicato un criterio assegnato in modo esplicito all'organizzazione padre dell'entità servizio.

  • Se non è presente alcun hint per il dominio e nessun criterio è stato assegnato all'entità servizio o all'organizzazione, viene usato il comportamento predefinito hrd.

Passaggi successivi