Autenticazione e accesso condizionale per ID esterno

Suggerimento

Questo articolo si applica alla collaborazione B2B e alla connessione diretta B2B. Se il tenant è configurato per la gestione delle identità e degli accessi dei clienti, vedere Sicurezza e governance in Microsoft Entra per ID esterno.

Quando un utente esterno accede alle risorse dell'organizzazione, il flusso di autenticazione viene determinato dal metodo di collaborazione (Collaborazione B2B o connessione diretta B2B), dal provider di identità dell'utente (un tenant esterno di Microsoft Entra, dal provider di identità social e così via), dai criteri di accesso condizionale e dalle impostazioni di accesso tra tenant configurate sia nel tenant principale dell'utente che nelle risorse di hosting del tenant.

Questo articolo descrive il flusso di autenticazione per gli utenti esterni che accedono alle risorse nell'organizzazione. Le organizzazioni possono applicare più criteri di accesso condizionale per i propri utenti esterni, che possono essere applicati a livello di tenant, app o utente singolo nello stesso modo in cui sono abilitati per dipendenti e membri a tempo pieno dell'organizzazione.

Flusso di autenticazione per gli utenti esterni di Microsoft Entra

Il diagramma seguente illustra il flusso di autenticazione quando un'organizzazione Microsoft Entra condivide le risorse con gli utenti di altre organizzazioni di Microsoft Entra. Questo diagramma illustra il funzionamento delle impostazioni di accesso tra tenant con i criteri di accesso condizionale, ad esempio l'autenticazione a più fattori, per determinare se l'utente può accedere alle risorse. Questo flusso si applica sia alla collaborazione B2B che alla connessione diretta B2B, ad eccezione di quanto indicato nel passaggio 6.

Diagramma che mostra il processo di autenticazione tra tenant.

Procedi Description
1 Un utente di Fabrikam (tenant principale dell'utente) avvia l'accesso a una risorsa in Contoso (tenant della risorsa).
2 Durante l'accesso, il servizio token di sicurezza Microsoft Entra valuta i criteri di accesso condizionale di Contoso. Controlla inoltre se l'utente Fabrikam è autorizzato ad accedere valutando le impostazioni di accesso tra tenant (le impostazioni in uscita di Fabrikam e le impostazioni in ingresso di Contoso).
3 Microsoft Entra ID controlla le impostazioni di attendibilità in ingresso di Contoso per verificare se Contoso considera attendibili le attestazioni MFA e dei dispositivi (conformità del dispositivo, stato aggiunto ibrido a Microsoft Entra) da Fabrikam. In caso contrario, andare al passaggio 6.
4 Se Contoso considera attendibili le attestazioni MFA e del dispositivo da Fabrikam, Microsoft Entra ID controlla la sessione di autenticazione dell'utente per indicare che l'utente ha completato l'autenticazione a più fattori. Se Contoso considera attendibili le informazioni sul dispositivo da Fabrikam, Microsoft Entra ID cerca un'attestazione nella sessione di autenticazione che indica lo stato del dispositivo (conforme o aggiunto ibrido a Microsoft Entra).
5 Se l'autenticazione a più fattori è necessaria ma non è stata completata o se non viene fornita un'attestazione del dispositivo, Microsoft Entra ID genera problemi di autenticazione a più fattori e dispositivi nel tenant principale dell'utente in base alle esigenze. Quando i requisiti di MFA e dispositivo sono soddisfatti in Fabrikam, l'utente può accedere alla risorsa in Contoso. Se i controlli non possono essere soddisfatti, l'accesso viene bloccato.
6 Quando non sono configurate impostazioni di attendibilità e l'autenticazione a più fattori è necessaria, agli utenti di Collaborazione B2B viene richiesta l'autenticazione a più fattori. Devono soddisfare l'autenticazione a più fattori nel tenant delle risorse. L'accesso viene bloccato per gli utenti con connessione diretta B2B. Se la conformità del dispositivo è necessaria ma non può essere valutata, l'accesso viene bloccato sia per gli utenti di Collaborazione B2B che per gli utenti con connessione diretta B2B.

Per altre informazioni, vedere la sezione Accesso condizionale per utenti esterni.

Flusso di autenticazione per utenti esterni non Azure AD

Quando un'organizzazione Di Microsoft Entra condivide le risorse con utenti esterni con un provider di identità diverso da Microsoft Entra ID, il flusso di autenticazione dipende dal fatto che l'utente stia autenticando con un provider di identità o con l'autenticazione con passcode monouso tramite posta elettronica. In entrambi i casi, il tenant della risorsa identifica il metodo di autenticazione da usare e quindi reindirizza l'utente al provider di identità o rilascia un passcode monouso.

Esempio 1: Flusso di autenticazione e token per un utente esterno non Azure AD

Il diagramma seguente illustra il flusso di autenticazione quando un utente esterno accede con un account da un provider di identità non Azure AD, ad esempio Google, Facebook o un provider di identità SAML/WS-Fed federato.

Diagramma che mostra il flusso di autenticazione per gli utenti guest B2B da una directory esterna.

Procedi Description
1 L'utente guest B2B richiede l'accesso a una risorsa. La risorsa reindirizza l'utente al tenant della risorsa, un IdP attendibile.
2 Il tenant della risorsa identifica l'utente come esterno e reindirizza l'utente al provider di identità dell'utente guest B2B. L'utente esegue l'autenticazione primaria nel provider di identità.
3 I criteri di autorizzazione vengono valutati nel provider di identità dell'utente guest B2B. Se l'utente soddisfa questi criteri, l'IDP dell'utente guest B2B rilascia un token all'utente. L'utente viene reindirizzato al tenant della risorsa con il token. Il tenant della risorsa convalida il token e quindi valuta l'utente rispetto ai criteri di accesso condizionale. Ad esempio, il tenant delle risorse potrebbe richiedere all'utente di eseguire l'autenticazione a più fattori Di Microsoft Entra.
4 Vengono valutate le impostazioni di accesso tra tenant in ingresso e i criteri di accesso condizionale. Se tutti i criteri sono soddisfatti, il tenant delle risorse rilascia il proprio token e reindirizza l'utente alla risorsa.

Esempio 2: Flusso di autenticazione e token per l'utente con passcode monouso

Il diagramma seguente illustra il flusso quando viene abilitata l'autenticazione con passcode monouso tramite posta elettronica e l'utente esterno non viene autenticato tramite altri mezzi, ad esempio Microsoft Entra ID, account Microsoft (MSA) o provider di identità di social networking.

Diagramma che mostra il flusso di autenticazione per gli utenti guest B2B con passcode monouso.

Procedi Description
1 L'utente richiede l'accesso a una risorsa in un altro tenant. La risorsa reindirizza l'utente al tenant della risorsa, un IdP attendibile.
2 Il tenant della risorsa identifica l'utente come utente OTP (Email One-Time Passcode) esterno e invia un messaggio di posta elettronica con OTP all'utente.
3 L'utente recupera l'OTP e invia il codice. Il tenant delle risorse valuta l'utente rispetto ai criteri di accesso condizionale.
4 Una volta soddisfatti tutti i criteri di accesso condizionale, il tenant della risorsa rilascia un token e reindirizza l'utente alla risorsa.

Accesso condizionale per utenti esterni

Le organizzazioni possono applicare i criteri di accesso condizionale per la collaborazione B2B esterna e gli utenti con connessione diretta B2B nello stesso modo in cui sono abilitati per dipendenti e membri dell'organizzazione a tempo pieno. Con l'introduzione delle impostazioni di accesso tra tenant, è anche possibile considerare attendibili le attestazioni di MFA e dispositivo da organizzazioni esterne di Microsoft Entra. Questa sezione descrive considerazioni importanti per l'applicazione dell'accesso condizionale agli utenti esterni all'organizzazione.

Nota

I controlli personalizzati con accesso condizionale non sono supportati per i trust tra tenant.

Assegnazione di criteri di accesso condizionale a tipi di utenti esterni

Quando si configura un criterio di accesso condizionale, si ha un controllo granulare sui tipi di utenti esterni a cui si vuole applicare il criterio. Gli utenti esterni vengono classificati in base alla modalità di autenticazione (interna o esterna) e alla relazione con l'organizzazione (guest o membro).

  • Utenti guest di Collaborazione B2B: la maggior parte degli utenti che sono comunemente considerati guest rientrano in questa categoria. Questo utente di Collaborazione B2B ha un account in un'organizzazione Microsoft Entra esterna o in un provider di identità esterno (ad esempio un'identità social) e dispone delle autorizzazioni a livello di guest nell'organizzazione. L'oggetto utente creato nella directory di Microsoft Entra ha un UserType di Guest. Questa categoria include gli utenti di Collaborazione B2B invitati e che hanno usato l'iscrizione self-service.
  • Utenti membri di Collaborazione B2B: questo utente di Collaborazione B2B ha un account in un'organizzazione Microsoft Entra esterna o in un provider di identità esterno (ad esempio un'identità social) e l'accesso a livello di membro alle risorse dell'organizzazione. Questo scenario è comune nelle organizzazioni costituite da più tenant, in cui gli utenti sono considerati parte dell'organizzazione più grande e necessitano dell'accesso a livello di membro alle risorse negli altri tenant dell'organizzazione. L'oggetto utente creato nella directory Microsoft Entra della risorsa ha un UserType di Member.
  • Utenti con connessione diretta B2B: utenti esterni che possono accedere alle risorse tramite connessione diretta B2B, ovvero una connessione bidirezionale reciproca con un'altra organizzazione di Microsoft Entra che consente l'accesso Single Sign-On a determinate applicazioni Microsoft (attualmente Microsoft Teams Connessione canali condivisi). Gli utenti con connessione diretta B2B non hanno una presenza nell'organizzazione Microsoft Entra, ma vengono invece gestiti dall'interno dell'applicazione (ad esempio, dal proprietario del canale condiviso di Teams).
  • Utenti guest locali: gli utenti guest locali dispongono di credenziali gestite nella directory. Prima che microsoft Entra B2B collaboration fosse disponibile, è stato comune collaborare con distributori, fornitori, fornitori e altri configurando le credenziali interne per loro e designandole come guest impostando l'oggetto utente UserType su Guest.
  • Utenti del provider di servizi: le organizzazioni che fungono da provider di servizi cloud per l'organizzazione (la proprietà isServiceProvider nella configurazione specifica del partner Microsoft Graph è vera).
  • Altri utenti esterni: si applica a tutti gli utenti che non rientrano in queste categorie, ma che non sono considerati membri interni dell'organizzazione, ovvero non eseguono l'autenticazione internamente tramite Microsoft Entra ID e l'oggetto utente creato nella directory Microsoft Entra della risorsa non ha un UserType di Member.

Nota

La selezione "Tutti gli utenti guest ed esterni" è stata ora sostituita con "Utenti guest ed esterni" e tutti i relativi sottotipi. Per i clienti che in precedenza avevano un criterio di accesso condizionale con l'opzione "Tutti gli utenti guest ed esterni" selezionati ora vedranno "Utenti guest ed esterni" insieme a tutti i sottotipi selezionati. Questa modifica nell'esperienza utente non ha alcun impatto funzionale sul modo in cui i criteri vengono valutati dal back-end dell'accesso condizionale. La nuova selezione offre ai clienti la granularità necessaria per scegliere tipi specifici di utenti guest ed esterni da includere/escludere dall'ambito utente durante la creazione dei criteri di accesso condizionale.

Altre informazioni sulle assegnazioni utente di accesso condizionale.

Confronto dei criteri di accesso condizionale con ID esterno

La tabella seguente fornisce un confronto dettagliato delle opzioni di conformità e dei criteri di sicurezza in Microsoft Entra per ID esterno. I criteri di sicurezza e la conformità vengono gestiti dall'organizzazione host/invito nei criteri di accesso condizionale.

Criteri Utenti di Collaborazione B2B Utenti con connessione diretta B2B
Concedere controlli: blocca l'accesso Supportata Supportata
Concedere controlli - Richiedere l'autenticazione a più fattori Supportata Supportato, richiede la configurazione delle impostazioni di attendibilità in ingresso per accettare attestazioni MFA dall'organizzazione esterna
Concedere controlli - Richiedere un dispositivo conforme Supportato, richiede la configurazione delle impostazioni di attendibilità in ingresso per accettare attestazioni di dispositivo conformi dall'organizzazione esterna. Supportato, richiede la configurazione delle impostazioni di attendibilità in ingresso per accettare attestazioni di dispositivo conformi dall'organizzazione esterna.
Concedi controlli - Richiedi un dispositivo aggiunto ibrido a Microsoft Entra Supportato, richiede la configurazione delle impostazioni di attendibilità in ingresso per accettare le attestazioni del dispositivo aggiunto ibrido a Microsoft Entra dall'organizzazione esterna Supportato, richiede la configurazione delle impostazioni di attendibilità in ingresso per accettare le attestazioni del dispositivo aggiunto ibrido a Microsoft Entra dall'organizzazione esterna
Concedere controlli - Richiedere l'app client approvata Non supportato Non supportato
Concedi controlli - Richiedi criteri di protezione delle app Non supportato Non supportato
Concedi controlli - Richiedi modifica della password Non supportato Non supportato
Concedere controlli - Condizioni per l'utilizzo Supportato Non supportato
Controlli sessione - Usare le restrizioni applicate dall'app Supportato Non supportato
Controlli sessione - Usare il controllo app per l'accesso condizionale Supportato Non supportato
Controlli sessione - Frequenza di accesso Supportato Non supportato
Controlli sessione - Sessione persistente del browser Supportato Non supportato

MFA per utenti esterni di Microsoft Entra

In uno scenario multi-tenant di Microsoft Entra, l'organizzazione delle risorse può creare criteri di accesso condizionale che richiedono MFA o conformità dei dispositivi per tutti gli utenti guest ed esterni. In genere, un utente di Collaborazione B2B che accede a una risorsa è quindi necessario per configurare l'autenticazione a più fattori Di Microsoft Entra con il tenant delle risorse. Tuttavia, Microsoft Entra ID offre ora la possibilità di considerare attendibili le attestazioni MFA da altri tenant di Microsoft Entra. L'abilitazione dell'attendibilità MFA con un altro tenant semplifica il processo di accesso per gli utenti di Collaborazione B2B e consente l'accesso per gli utenti con connessione diretta B2B.

Se sono state configurate le impostazioni di attendibilità in ingresso per accettare attestazioni MFA da un tenant principale di Collaborazione B2B o B2B direct connect dell'utente, Microsoft Entra ID controlla la sessione di autenticazione dell'utente. Se la sessione contiene un'attestazione che indica che i criteri di autenticazione a più fattori sono già stati soddisfatti nel tenant principale dell'utente, all'utente viene concesso l'accesso facile alla risorsa condivisa.

Se l'attendibilità MFA non è abilitata, l'esperienza utente è diversa per gli utenti di Collaborazione B2B e gli utenti con connessione diretta B2B:

  • Utenti di Collaborazione B2B: se l'organizzazione delle risorse non abilita l'attendibilità MFA con il tenant principale dell'utente, all'utente viene presentata una richiesta di autenticazione a più fattori dell'organizzazione delle risorse. (Il flusso è uguale aFlusso di autenticazione a più fattori per utenti esterni di Azure AD.

  • Utenti con connessione diretta B2B: se l'organizzazione delle risorse non abilita l'attendibilità MFA con il tenant principale dell'utente, l'utente non accede alle risorse. Se si vuole consentire la connessione diretta B2B con un'organizzazione esterna e i criteri di accesso condizionale richiedono l'autenticazione a più fattori, è necessario configurare le impostazioni di attendibilità in ingresso per accettare attestazioni MFA dall'organizzazione.

Altre informazioni su come configurare le impostazioni di attendibilità in ingresso per MFA.

MFA per utenti esterni non Di Azure AD

Per gli utenti esterni non di Azure AD, il tenant delle risorse è sempre responsabile dell'autenticazione a più fattori. L'esempio seguente illustra un tipico flusso MFA. Questo scenario funziona per qualsiasi identità, incluso un account Microsoft (MSA) o un ID social. Questo flusso si applica anche agli utenti esterni di Microsoft Entra quando non si configurano le impostazioni di attendibilità con la propria organizzazione Microsoft Entra.

  1. Un amministratore o un information worker in una società denominata Fabrikam invita un utente di un'altra società denominata Contoso a usare l'app di Fabrikam.

  2. L'app di Fabrikam è configurata per richiedere l'autenticazione a più fattori Di Microsoft Entra all'accesso.

  3. Quando l'utente di Collaborazione B2B di Contoso tenta di accedere all'app di Fabrikam, viene chiesto di completare la richiesta di autenticazione a più fattori di Microsoft Entra.

  4. L'utente guest può quindi configurare l'autenticazione a più fattori Di Microsoft Entra con Fabrikam e selezionare le opzioni.

Fabrikam deve disporre di licenze premium di Microsoft Entra ID sufficienti che supportano l'autenticazione a più fattori di Microsoft Entra. L'utente di Contoso usa quindi questa licenza da Fabrikam. Per informazioni sulle licenze B2B, vedere modello di fatturazione per Microsoft Entra per ID esterno.

Nota

L'autenticazione a più fattori viene completata nella tenancy delle risorse per garantire la prevedibilità. Quando l'utente guest accede, viene visualizzata la pagina di accesso del tenant della risorsa in background e la pagina di accesso del tenant principale e il logo aziendale in primo piano.

Reimpostazione dell'autenticazione a più fattori Microsoft Entra (correzione) per gli utenti di Collaborazione B2B

I cmdlet di PowerShell seguenti sono disponibili per la correzione o la richiesta di registrazione MFA dagli utenti di Collaborazione B2B.

Nota

I moduli di Azure AD e MSOnline PowerShell sono deprecati a partire dal 30 marzo 2024. Per altre informazioni, leggere l'aggiornamento deprecato. Dopo questa data, il supporto per questi moduli è limitato all'assistenza per la migrazione a Microsoft Graph PowerShell SDK e alle correzioni di sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile eseguire la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per domande comuni sulla migrazione, vedere Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero verificarsi interruzioni dopo il 30 giugno 2024.

  1. Connessione a Microsoft Entra ID:

    $cred = Get-Credential
    Connect-MsolService -Credential $cred
    
  2. Ottenere tutti gli utenti con metodi di correzione:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    

    Ad esempio:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    
  3. Reimpostare il metodo di autenticazione a più fattori Di Microsoft Entra per richiedere a un utente specifico di impostare nuovamente i metodi di correzione, ad esempio:

    Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
    

Criteri di attendibilità dell'autenticazione per utenti esterni

Il livello di attendibilità dell'autenticazione è un controllo di accesso condizionale che consente di definire una combinazione specifica di metodi di autenticazione a più fattori che un utente esterno deve completare l'accesso alle risorse. Questo controllo è particolarmente utile per limitare l'accesso esterno alle app sensibili nell'organizzazione perché è possibile applicare metodi di autenticazione specifici, ad esempio un metodo resistente al phishing, per gli utenti esterni.

È anche possibile applicare la forza di autenticazione ai diversi tipi di utenti guest o esterni con cui si collabora o con cui ci si connette. Ciò significa che è possibile applicare requisiti di attendibilità dell'autenticazione univoci per la collaborazione B2B, la connessione diretta B2B e altri scenari di accesso esterno.

Microsoft Entra ID offre tre punti di forza di autenticazione predefiniti:

  • Livello di autenticazione a più fattori
  • Livello di autenticazione a più fattori senza password
  • Resistenza all'autenticazione a più fattori resistente al phishing

È possibile usare uno di questi punti di forza predefiniti o creare criteri di attendibilità dell'autenticazione personalizzati in base ai metodi di autenticazione necessari.

Nota

Attualmente, è possibile applicare criteri di attendibilità dell'autenticazione solo agli utenti esterni che eseguono l'autenticazione con Microsoft Entra ID. Per i passcode monouso tramite posta elettronica, saml/WS-Fed e gli utenti federati di Google, usare il controllo delle concessioni MFA per richiedere l'autenticazione a più fattori.

Quando si applicano criteri di attendibilità dell'autenticazione agli utenti esterni di Microsoft Entra, i criteri interagiscono con le impostazioni di attendibilità MFA nelle impostazioni di accesso tra tenant per determinare dove e come l'utente esterno deve eseguire l'autenticazione a più fattori. Un utente di Microsoft Entra esegue prima l'autenticazione usando il proprio account nel tenant Microsoft Entra di casa. Quindi, quando l'utente tenta di accedere alla risorsa, Microsoft Entra ID applica i criteri di accesso condizionale di livello di autenticazione e verifica se è stata abilitata l'attendibilità MFA.

Negli scenari utente esterni, i metodi di autenticazione accettabili per soddisfare il livello di autenticazione variano a seconda che l'utente stia completando l'autenticazione a più fattori nel tenant principale o nel tenant della risorsa. La tabella seguente indica i metodi accettabili in ogni tenant. Se un tenant di risorse sceglie di considerare attendibili le attestazioni provenienti da organizzazioni esterne di Microsoft Entra, solo le attestazioni elencate nella colonna "Tenant principale" vengono accettate dal tenant della risorsa per l'evasione dell'autenticazione a più fattori. Se il tenant delle risorse ha disabilitato l'attendibilità MFA, l'utente esterno deve completare l'autenticazione a più fattori nel tenant delle risorse usando uno dei metodi elencati nella colonna "Tenant delle risorse".

Tabella 1. Metodi MFA di livello di autenticazione per utenti esterni
Authentication method Tenant principale Tenant delle risorse
SMS come secondo fattore
Chiamata vocale
Notifica push di Microsoft Authenticator
Accesso tramite telefono Microsoft Authenticator
Token software OATH
Token hardware OATH
Chiave di sicurezza FIDO2
Windows Hello for Business (Configurare Windows Hello for Business)

Per configurare un criterio di accesso condizionale che applica i requisiti di attendibilità dell'autenticazione a utenti o guest esterni, vedere Accesso condizionale: Richiedere un livello di autenticazione per gli utenti esterni.

Esperienza utente per utenti esterni di Microsoft Entra

I criteri di attendibilità dell'autenticazione interagiscono con le impostazioni di attendibilità MFA nelle impostazioni di accesso tra tenant per determinare dove e come l'utente esterno deve eseguire l'autenticazione a più fattori.

In primo luogo, un utente di Microsoft Entra esegue l'autenticazione con il proprio account nel tenant principale. Quando quindi l'utente tenta di accedere alla risorsa, Microsoft Entra ID applica i criteri di accesso condizionale di livello di autenticazione e verifica se è stata abilitata l'attendibilità MFA.

  • Se l'attendibilità MFA è abilitata, Microsoft Entra ID controlla la sessione di autenticazione dell'utente per un'attestazione che indica che l'autenticazione a più fattori è stata soddisfatta nel tenant principale dell'utente. (Vedere Tabella 1 per i metodi di autenticazione accettabili per l'evasione dell'autenticazione a più fattori al termine del tenant principale di un utente esterno. Se la sessione contiene un'attestazione che indica che i criteri MFA sono già stati soddisfatti nel tenant principale dell'utente e i metodi soddisfano i requisiti di attendibilità dell'autenticazione, l'utente è autorizzato ad accedere. In caso contrario, Microsoft Entra ID presenta all'utente una sfida per completare l'autenticazione a più fattori nel tenant principale usando un metodo di autenticazione accettabile. Il metodo MFA deve essere abilitato nel tenant principale e l'utente deve essere in grado di eseguirne la registrazione.
  • Se l'attendibilità MFA è disabilitata, Microsoft Entra ID presenta all'utente una richiesta di verifica per completare l'autenticazione a più fattori nel tenant delle risorse usando un metodo di autenticazione accettabile. (Vedere Tabella 1 per i metodi di autenticazione accettabili per l'evasione dell'autenticazione a più fattori da un utente esterno.

Se l'utente non è in grado di completare l'autenticazione a più fattori o se un criterio di accesso condizionale (ad esempio un criterio del dispositivo conforme) impedisce la registrazione, l'accesso viene bloccato.

Conformità dei dispositivi e criteri dei dispositivi aggiunti a Microsoft Entra ibrido

Le organizzazioni possono usare i criteri di accesso condizionale per richiedere che i dispositivi degli utenti siano gestiti da Microsoft Intune. Questi criteri possono bloccare l'accesso degli utenti esterni, perché un utente esterno non può registrare il dispositivo non gestito con l'organizzazione delle risorse. I dispositivi possono essere gestiti solo dal tenant principale di un utente.

Tuttavia, è possibile usare le impostazioni di attendibilità dei dispositivi per sbloccare gli utenti esterni, pur richiedendo dispositivi gestiti. Nelle impostazioni di accesso tra tenant, è possibile scegliere di considerare attendibili le attestazioni del tenant principale di un utente esterno sul fatto che il dispositivo dell'utente soddisfi i criteri di conformità del dispositivo o sia aggiunto a Microsoft Entra ibrido. È possibile impostare le impostazioni di attendibilità dei dispositivi per tutte le organizzazioni Microsoft Entra o le singole organizzazioni.

Quando le impostazioni di attendibilità del dispositivo sono abilitate, Microsoft Entra ID controlla la sessione di autenticazione di un utente per un'attestazione del dispositivo. Se la sessione contiene un'attestazione del dispositivo che indica che i criteri sono già stati soddisfatti nel tenant principale dell'utente, all'utente esterno viene concesso l'accesso facile alla risorsa condivisa.

Importante

  • A meno che non si sia disposti a considerare attendibili le attestazioni relative alla conformità del dispositivo o allo stato aggiunto ibrido di Microsoft Entra da un tenant principale di un utente esterno, non è consigliabile applicare criteri di accesso condizionale che richiedono agli utenti esterni di usare dispositivi gestiti.

Filtri del dispositivo

Quando si creano criteri di accesso condizionale per gli utenti esterni, è possibile valutare un criterio in base agli attributi del dispositivo registrato in Microsoft Entra ID. Usando il filtro per la condizione dei dispositivi , è possibile scegliere come destinazione dispositivi specifici usando gli operatori e le proprietà supportati e le altre condizioni di assegnazione disponibili nei criteri di accesso condizionale.

I filtri dei dispositivi possono essere usati insieme alle impostazioni di accesso tra tenant per basare i criteri sui dispositivi gestiti in altre organizzazioni. Si supponga, ad esempio, di voler bloccare i dispositivi da un tenant Microsoft Entra esterno in base a un attributo di dispositivo specifico. Per configurare un criterio basato su attributi del dispositivo, è possibile seguire questa procedura:

  • Configurare le impostazioni di accesso tra tenant per considerare attendibili le attestazioni dei dispositivi da tale organizzazione.
  • Assegnare l'attributo del dispositivo da usare per filtrare uno degli attributi di estensione del dispositivo supportati.
  • Creare criteri di accesso condizionale con un filtro del dispositivo che blocca l'accesso ai dispositivi contenenti tale attributo.

Altre informazioni sul filtro per i dispositivi con accesso condizionale.

Criteri di gestione delle applicazioni mobili

Non è consigliabile richiedere criteri di protezione delle app per gli utenti esterni. I controlli di concessione dell'accesso condizionale, ad esempio Richiedi app client approvate e Richiedi criteri di protezione delle app richiedono la registrazione del dispositivo nel tenant delle risorse. Questi controlli possono essere applicati solo ai dispositivi iOS e Android. Poiché il dispositivo di un utente può essere gestito solo dal tenant principale, questi controlli non possono essere applicati agli utenti guest esterni.

Accesso condizionale basato sulla posizione

I criteri basati sulla posizione in base agli intervalli IP possono essere applicati se l'organizzazione che invita può creare un intervallo di indirizzi IP attendibile che definisce le organizzazioni partner.

I criteri possono essere applicati anche in base alle posizioni geografiche.

Accesso condizionale basato sul rischio

I criteri di rischio di accesso vengono applicati se l'utente guest esterno soddisfa il controllo di concessione. Ad esempio, un'organizzazione potrebbe richiedere l'autenticazione a più fattori Di Microsoft Entra per rischi di accesso medio o elevato. Tuttavia, se un utente non è stato registrato in precedenza per l'autenticazione a più fattori Di Microsoft Entra nel tenant della risorsa, l'utente viene bloccato. Questa operazione viene eseguita per impedire agli utenti malintenzionati di registrare le proprie credenziali di autenticazione a più fattori Di Microsoft Entra nel caso in cui compromettano la password di un utente legittimo.

I criteri di rischio utente, tuttavia, non possono essere risolti nel tenant delle risorse. Ad esempio, se è necessaria una modifica della password per gli utenti guest esterni ad alto rischio, questi vengono bloccati a causa dell'impossibilità di reimpostare le password nella directory delle risorse.

Condizione delle app client di accesso condizionale

Le condizioni delle app client si comportano come per gli utenti guest B2B come per qualsiasi altro tipo di utente. Ad esempio, è possibile impedire agli utenti guest di usare protocolli di autenticazione legacy.

Controlli sessione di accesso condizionale

I controlli sessione si comportano allo stesso modo per gli utenti guest B2B come per qualsiasi altro tipo di utente.

Criteri di protezione delle identità e rischio utente

Identity Protection rileva le credenziali compromesse per gli utenti di Microsoft Entra e contrassegna gli account utente che potrebbero essere compromessi come "a rischio". Come tenant delle risorse, è possibile applicare criteri di rischio utente agli utenti esterni per bloccare gli accessi a rischio. Per un utente esterno, il rischio utente viene valutato nella home directory. Il rischio di accesso in tempo reale per questi utenti viene valutato nella directory delle risorse quando tenta di accedere alla risorsa. Tuttavia, poiché l'identità di un utente esterno esiste nella home directory, sono previste le limitazioni seguenti:

  • Se un utente esterno attiva i criteri di rischio utente di Identity Protection per forzare la reimpostazione della password, viene bloccato perché non può reimpostare la password nell'organizzazione delle risorse.
  • Il report utenti rischiosi dell'organizzazione delle risorse non riflette gli utenti esterni perché la valutazione dei rischi si verifica nella home directory dell'utente esterno.
  • Amministrazione nell'organizzazione delle risorse non possono ignorare o correggere un utente esterno rischioso perché non hanno accesso alla home directory dell'utente B2B.

È possibile evitare che i criteri basati sui rischi influiscano sugli utenti esterni creando un gruppo nell'ID Microsoft Entra che contiene tutti gli utenti esterni dell'organizzazione. Aggiungere quindi questo gruppo come esclusione per i criteri di rischio utente e di rischio di accesso predefiniti di Identity Protection e i criteri di accesso condizionale che usano il rischio di accesso come condizione.

Per altre informazioni, vedere Identity Protection e utenti B2B.

Passaggi successivi

Per altre informazioni, vedere gli articoli seguenti: