Condividi tramite

Individuazione dell'area di autenticazione principale per un'applicazione

  • Articolo

L'individuazione dell'area di autenticazione principale (HRD) è il processo che consente a Microsoft Entra ID di determinare, al momento dell'accesso, con quale provider di identità (IDP) deve eseguire l'autenticazione l'utente. Quando un utente effettua l'accesso a un tenant di Microsoft Entra per accedere a una risorsa, o nella pagina di accesso comune di Microsoft Entra, l'utente digita un nome utente (UPN). Microsoft Entra ID lo usa per individuare dove l'utente deve effettuare l'accesso.

L'utente viene indirizzato 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 di Microsoft Entra in modo da eseguire la federazione con un altro IdP, come AD FS, per l'autenticazione dell'utente.

Quando un utente accede a un'applicazione, viene innanzitutto visualizzata una pagina di accesso di Microsoft Entra. Dopo aver digitato il nome dell'entità utente, se ci si trova in un dominio federato verrà visualizzata la pagina di accesso del provider di identità del 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 è noto come "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 impedire la collaborazione. Vedere Abilitare l'accesso con chiave di sicurezza senza password per informazioni sui vantaggi della mancata configurazione dell'accelerazione automatica. 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 con 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 indirizza un utente direttamente a un IdP federato per l'autenticazione non potrà più tornare alla pagina di accesso di Microsoft Entra. Gli utenti guest, che potrebbero dover essere indirizzati ad altri tenant o a un provider di identità esterno, ad esempio un account Microsoft, non potranno effettuare l'accesso a tale applicazione poiché il passaggio HRD viene saltato.

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

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 della finestra di dialogo di conferma del dominio che elenca l'identificatore di accesso

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 per altri motivi, è possibile che venga mostrata più frequentemente la finestra di dialogo di conferma del dominio. 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 di restrizioni del tenant v2 (TRv2). Un criterio TRv2 ottiene la stessa postura 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 usarli per indirizzare l'utente direttamente alla pagina di accesso di Microsoft Entra personalizzata per il tenant.

Ad esempio, l'applicazione "largeapp.com" potrebbe consentire ai suoi utenti di accedere all'applicazione tramite un URL personalizzato "contoso.largeapp.com". L'applicazione potrebbe anche includere un hint di dominio a Contoso.com nella richiesta di autenticazione.

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

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

  • Per le applicazioni che usano Security Assertion Markup Language (SAML): una richiesta di autenticazione SAML che contiene un hint di dominio oppure una stringa di query whr=contoso.com.

  • Per le applicazioni che usano il parametro di stringa di query OpenID Connect: domain_hint. 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 entrambe le condizioni seguenti sono vere:

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

Se l'hint di dominio non fa riferimento a un dominio federato verificato, è possibile ignorarlo.

Nota

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

Criteri HRD per l'accelerazione automatica

Alcune applicazioni non forniscono un modo per configurare la richiesta di autenticazione che generano. In questi casi, non è possibile usare gli hint di dominio per controllare l'accelerazione automaticamente. L'accelerazione automatica può essere configurata tramite criterio Home Realm Discovery 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 accodato), cosa che può interrompere l'implementazione di credenziali gestite come FIDO. È possibile usare Criteri di individuazione dell'area di autenticazione principale per ignorare gli hint di dominio da determinate app o per determinati domini durante l'implementazione delle credenziali gestite.

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

Per le applicazioni, è consigliabile 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 quelle che usano le credenziali della password del proprietario della risorsa (ROPC), inviano nome utente e password direttamente a Microsoft Entra ID e non vengono scritte per comprendere la federazione. Queste non eseguono HRD e non interagiscono con il corretto endpoint federato 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, è necessario abilitare la Sincronizzazione hash password.

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 l'impostazione dei criteri HRD su un'applicazione per l'accelerazione automatica federata di accesso o altre applicazioni dirette basate su 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 diventano effettivi per una specifica applicazione solo quando sono connessi a un'entità servizio.

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

È possibile usare i cmdlet di PowerShell 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 criteri è "HomeRealmDiscoveryPolicy".

AccelerateToFederatedDomain è facoltativo. Se AccelerateToFederatedDomain è falso, i criteri non hanno alcun effetto sull'accelerazione automatica. Se AccelerateToFederatedDomain è vero ed esiste solo un dominio verificato e federato nel tenant, gli utenti verranno condotti direttamente al provider di identità federato per l'accesso. Se è vero ed è presente più di un dominio verificato del tenant, PreferredDomain deve essere specificato.

PreferredDomain è facoltativo. PreferredDomain deve indicare un dominio al quale accelerare. Può essere omesso se il tenant dispone di un solo dominio federato. Se è omesso ed esiste più di un dominio federato verificato, i criteri non hanno 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 è vero, l'applicazione può autenticare un utente federato presentando le credenziali di nome utente/password direttamente al token di autenticazione dell'endpoint di Microsoft Entra. Tale operazione viene eseguita solo se la sincronizzazione degli hash delle password è abilitata.

Inoltre, esistono due opzioni HRD a livello di tenant, non illustrate nella sezione precedente di questo articolo:

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 (rispetto ai molti applicati) hanno effetto:

  • Se nella richiesta di autenticazione è presente un hint di dominio, i criteri HRD per il tenant (quelli impostati come predefiniti 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.

  • Se i criteri sono assegnati in modo esplicito all'entità servizio, vengono applicati.

  • Se non è presente alcun hint di dominio e all'entità servizio non sono assegnati criteri in modo esplicito, vengono applicati i criteri assegnati in modo esplicito all'elemento organizzazione padre dell'entità servizio.

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

Passaggi successivi