Configurare manualmente l'aggiunta ad Azure Active Directory ibrido

Se si usa Azure AD Connect è un'opzione, vedere le indicazioni in Configurare l'aggiunta ad Azure AD ibrido. L'uso dell'automazione in Azure AD Connect semplifica notevolmente la configurazione dell'aggiunta ad Azure AD ibrido.

Questo articolo illustra la configurazione manuale dei requisiti per l'aggiunta ad Azure AD ibrido, inclusi i passaggi per i domini gestiti e federati.

Prerequisiti

  • Azure AD Connect versione 1.1.819.0 o successiva.
    • Per ottenere il completamento dell'aggiunta alla sincronizzazione della registrazione del dispositivo, come parte della configurazione di registrazione del dispositivo, non escludere gli attributi predefiniti del dispositivo dalla configurazione di sincronizzazione di Azure AD Connect. Per altre informazioni sugli attributi di dispositivo predefiniti sincronizzati con Azure AD, vedere Attributi sincronizzati da Azure AD Connect.
    • Se gli oggetti computer dei dispositivi da aggiungere ad Azure AD ibrido appartengono a unità organizzative specifiche, configurare le unità organizzative corrette da sincronizzare in Azure AD Connect. Per altre informazioni su come sincronizzare oggetti computer con Azure AD Connect, vedere Filtro basato su unità organizzative.
  • Credenziali di amministratore globale per il tenant di Azure AD.
  • Credenziali di amministratore dell'organizzazione per ognuna delle foreste Active Directory locale Domain Services.
  • (Per i domini federati) Windows Server 2012 R2 con Active Directory Federation Services installato.
  • Gli utenti possono registrare i propri dispositivi con Azure AD. Per altre informazioni su questa impostazione, vedere l'intestazione Configurare le impostazioni del dispositivo nell'articolo Configurare le impostazioni del dispositivo.

Per l'aggiunta ad Azure AD ibrido i dispositivi devono avere accesso alle risorse Microsoft seguenti dalla rete dell'organizzazione:

  • https://enterpriseregistration.windows.net
  • https://login.microsoftonline.com
  • https://device.login.microsoftonline.com
  • https://autologon.microsoftazuread-sso.com (se si usa o si prevede di usare Seamless SSO)
  • Servizio token di sicurezza (STS) dell'organizzazione (per i domini federati)

Avviso

Se l'organizzazione usa server proxy che intercettano il traffico SSL per scenari come la prevenzione della perdita di dati o le restrizioni del tenant di Azure AD, assicurarsi che il traffico verso questi URL venga escluso dall'interruzione e dall'ispezione TLS. L'impossibilità di escludere questi URL può causare interferenze con l'autenticazione del certificato client, causare problemi con la registrazione del dispositivo e l'accesso condizionale basato su dispositivo.

Se l'organizzazione richiede l'accesso a Internet tramite un proxy in uscita, è possibile usare Web Proxy Auto-Discovery (WPAD) per abilitare Windows 10 o computer più recenti per la registrazione dei dispositivi con Azure AD. Per risolvere i problemi durante la configurazione e la gestione di WPAD, vedere Risoluzione dei problemi relativi al rilevamento automatico.

Se non si usa WPAD, è possibile configurare le impostazioni proxy WinHTTP nel computer in uso a partire da Windows 10 1709. Per altre informazioni, vedere Impostazioni del proxy WinHTTP distribuite dall'oggetto Criteri di gruppo.

Nota

Se si configurano le impostazioni proxy nel computer usando le impostazioni WinHTTP, i computer che non possono connettersi al proxy configurato non riusciranno a connettersi a Internet.

Se l'organizzazione richiede l'accesso a Internet tramite un proxy in uscita autenticato, assicurarsi che i computer Windows 10 o più recenti possano eseguire correttamente l'autenticazione al proxy in uscita. Poiché Windows 10 o più recenti computer eseguono la registrazione del dispositivo usando il contesto del computer, configurare l'autenticazione proxy in uscita usando il contesto del computer. Per i requisiti di configurazione, contattare il provider del proxy in uscita.

Verificare che i dispositivi possano accedere alle risorse Microsoft necessarie nell'account di sistema usando lo script Test Device Registration Connectivity (Test Device Registration Connectivity ).

Configurazione

È possibile configurare dispositivi aggiunti all'identità ibrida di Azure AD per diversi tipi di piattaforme di dispositivi Windows.

Al termine di queste configurazioni, seguire le indicazioni per verificare la registrazione e abilitare i sistemi operativi di livello inferiore , se necessario.

Configurare un punto di connessione del servizio

I dispositivi usano un oggetto punto di connessione del servizio durante la registrazione per individuare le informazioni del tenant di Azure AD. Nell'istanza locale di Active Directory l'oggetto punto di connessione del servizio per i dispositivi aggiunti ad Azure AD ibrido deve essere incluso nella partizione del contesto dei nomi di configurazione della foresta del computer. Esiste un solo contesto di denominazione della configurazione per ogni foresta. In una configurazione di Active Directory a più foreste, il punto di connessione del servizio deve essere presente in tutte le foreste contenenti computer aggiunti al dominio.

L'oggetto SCP contiene due valori di parole chiave: azureADid:<TenantID> e azureADName:<verified domain>. Il <verified domain> valore nella azureADName parola chiave determina il tipo del flusso di registrazione del dispositivo (federato o gestito) che il dispositivo seguirà dopo aver letto il valore SCP dall'istanza di Active Directory locale. Altre informazioni sui flussi gestiti e federati sono disponibili nell'articolo Funzionamento della registrazione dei dispositivi di Azure AD.

Per recuperare il contesto dei nomi di configurazione della foresta è possibile usare il cmdlet Get-ADRootDSE.

Per una foresta con nome di dominio di Active Directory fabrikam.com, il contesto dei nomi di configurazione è il seguente:

CN=Configuration,DC=fabrikam,DC=com

Nella foresta, l'oggetto SCP per la registrazione automatica dei dispositivi aggiunti a un dominio si trova in:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Your Configuration Naming Context]

A seconda di come è stato distribuito Azure AD Connect, l'oggetto punto di connessione del servizio potrebbe essere già stato configurato. È possibile verificare l'esistenza dell'oggetto e recuperare i valori per l'individuazione con lo script di Windows PowerShell seguente:

$scp = New-Object System.DirectoryServices.DirectoryEntry;

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";

$scp.Keywords;

L'output di $scp.Keywords mostra le informazioni sul tenant di Azure AD, Ad esempio:

azureADName:microsoft.com
azureADId:72f988bf-86f1-41af-91ab-2d7cd011db47

Se il punto di connessione del servizio non esiste, è possibile crearlo eseguendo il cmdlet nel Initialize-ADSyncDomainJoinedComputerSync server Azure AD Connect. Per eseguire questo cmdlet sono necessarie le credenziali di amministratore dell'organizzazione.

Il Initialize-ADSyncDomainJoinedComputerSync cmdlet esegue queste operazioni:

  • Crea il punto di connessione del servizio nella foresta di Active Directory a cui è connesso Azure AD Connect.
  • Richiede che si specifichi il parametro AdConnectorAccount, che è l'account configurato come account connettore di Active Directory in Azure AD Connect.

Lo script seguente mostra un esempio dell'uso del cmdlet. In questo script, $aadAdminCred = Get-Credential richiede la digitazione di un nome utente. Specificare il nome utente nel formato UPN (User Principal Name) (user@example.com).

Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";

$aadAdminCred = Get-Credential;

Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;

Il Initialize-ADSyncDomainJoinedComputerSync cmdlet esegue queste operazioni:

  • Usa il modulo PowerShell di Active Directory e gli strumenti Active Directory Domain Services (AD DS). Questi strumenti si basano sull'esecuzione di Servizi Web Active Directory in un controller di dominio. Il servizio Servizi Web Active Directory è supportato nei controller di dominio che eseguono Windows Server 2008 R2 e versioni successive.
  • È supportato solo per il modulo MSOnline PowerShell versione 1.1.166.0. Per scaricare questo modulo, seguire questo collegamento.
  • Se gli strumenti di Active Directory Domain Services non sono installati, Initialize-ADSyncDomainJoinedComputerSync avrà esito negativo. È possibile installare questi strumenti tramite Server Manager in Funzionalità>Strumenti di amministrazione remota del server>Strumenti di amministrazione ruoli.

Configurare il rilascio delle attestazioni

In una configurazione federata di Azure AD, i dispositivi si basano su AD FS o su un servizio federativo locale di un partner Microsoft per l'autenticazione in Azure AD. I dispositivi eseguono l'autenticazione per ottenere un token di accesso per la registrazione nel servizio Registrazione dispositivo Azure Active Directory.

I dispositivi correnti Di Windows eseguono l'autenticazione tramite autenticazione di Windows integrata a un endpoint di WS-Trust attivo (versione 1.3 o 2005) ospitato dal servizio federativo locale.

Quando si usa AD FS, è necessario abilitare gli endpoint WS-Trust seguenti:

  • /adfs/services/trust/2005/windowstransport
  • /adfs/services/trust/13/windowstransport
  • /adfs/services/trust/2005/usernamemixed
  • /adfs/services/trust/13/usernamemixed
  • /adfs/services/trust/2005/certificatemixed
  • /adfs/services/trust/13/certificatemixed

Avviso

Sia adfs/services/trust/2005/windowstransport che adfs/services/trust/13/windowstransport devono essere abilitati solo come endpoint per Intranet e NON devono essere esposti come endpoint per Extranet tramite Proxy applicazione Web. Per altre informazioni su come disabilitare gli endpoint Windows WS-Trust, vedere Disabilitare gli endpoint Windows WS-Trust sul proxy. È possibile verificare gli endpoint abilitati nella console di gestione di AD FS, in Servizio>Endpoint.

Nota

Se non si usa AD FS come servizio federativo locale, seguire le istruzioni del fornitore per verificare che siano supportati endpoint WS-Trust 1.3 o 2005 e che questi vengano pubblicati tramite file Metadata Exchange (MEX).

Per completare la registrazione dei dispositivi, nel token ricevuto dal servizio Registrazione dispositivo Azure devono essere presenti le attestazioni seguenti. Il servizio Registrazione dispositivo Azure creerà un oggetto dispositivo in Azure AD con alcune di queste informazioni. Azure AD Connect usa quindi le informazioni per associare l'oggetto dispositivo appena creato con l'account computer locale.

  • http://schemas.microsoft.com/ws/2012/01/accounttype
  • http://schemas.microsoft.com/identity/claims/onpremobjectguid
  • http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid

Se sono necessari più nomi di dominio verificati, è necessario specificare l'attestazione seguente per i computer:

  • http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid

Se viene già rilasciata un'attestazione ImmutableID (ad esempio usando mS-DS-ConsistencyGuid o un altro attributo come valore di origine per ImmutableID), è necessario specificare un'attestazione corrispondente per i computer:

  • http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID

Nelle sezioni seguenti sono disponibili informazioni su:

  • I valori necessari in ogni attestazione.
  • Come si presenta una definizione in AD FS.

La definizione consente di verificare se i valori sono presenti o devono essere creati.

Nota

Se non si usa AD FS per il server federativo locale, seguire le istruzioni del fornitore per creare la configurazione appropriata per il rilascio di queste attestazioni.

Rilasciare l'attestazione del tipo di account

L'attestazione http://schemas.microsoft.com/ws/2012/01/accounttype deve contenere un valore DJ che identifica il dispositivo come computer aggiunto a un dominio. In AD FS, è possibile aggiungere una regola di trasformazione rilascio simile alla seguente:

@RuleName = "Issue account type for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "DJ"
);

Rilasciare l'attestazione objectGUID dell'account computer locale

L'attestazione http://schemas.microsoft.com/identity/claims/onpremobjectguid deve contenere il valore objectGUID dell'account computer locale. In AD FS, è possibile aggiungere una regola di trasformazione rilascio simile alla seguente:

@RuleName = "Issue object GUID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$", 
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
   query = ";objectguid;{0}",
   param = c2.Value
);

Rilasciare l'attestazione objectSID dell'account computer locale

L'attestazione http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid deve contenere il valore objectSid dell'account computer locale. In AD FS, è possibile aggiungere una regola di trasformazione rilascio simile alla seguente:

@RuleName = "Issue objectSID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);

Rilasciare issuerID per il computer se in Azure AD sono presenti più nomi di dominio verificati

L'attestazione http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid deve contenere l'URI (Uniform Resource Identifier) di tutti i nomi di dominio verificati che si connettono al servizio federativo locale (AD FS o del partner) che rilascia il token. In AD FS è possibile aggiungere regole di trasformazione rilascio simili alle seguenti, nell'ordine specificato, dopo quelle riportate sopra. È necessaria una regola per emettere in modo esplicito la regola per gli utenti. Nelle regole seguenti viene aggiunta una prima regola che identifica l'autenticazione dell'utente rispetto a un computer.

@RuleName = "Issue account type with the value User when its not a computer"
NOT EXISTS(
[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "DJ"
]
)
=> add(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
   Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "User"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = regexreplace(
   c1.Value,
   ".+@(?<domain>.+)",
   "http://${domain}/adfs/services/trust/"
   )
);

@RuleName = "Issue issuerID for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = "http://<verified-domain-name>/adfs/services/trust/"
);

Nell'attestazione precedente <verified-domain-name> è un segnaposto. Sostituirlo con uno dei nomi di dominio verificati in Azure AD. Ad esempio, usare Value = "http://contoso.com/adfs/services/trust/".

Per altre informazioni sui nomi dominio verificati, vedere Aggiungere un nome di dominio personalizzato ad Azure Active Directory.

Per ottenere un elenco dei domini aziendali verificati, è possibile usare il cmdlet Get-MsolDomain.

Elenco di domini aziendali

Rilasciare ImmutableID per il computer quando ne esiste uno per gli utenti (ad esempio usando mS-DS-ConsistencyGuid come origine per ImmutableID)

L'attestazione http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID deve contenere un valore valido per i computer. In AD FS, è possibile creare una regola di trasformazione rilascio come segue:

@RuleName = "Issue ImmutableID for computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
   query = ";objectguid;{0}",
   param = c2.Value
);

Script helper per creare le regole di trasformazione rilascio di AD FS

Lo script seguente semplifica la creazione delle regole di trasformazione rilascio descritte sopra.

$multipleVerifiedDomainNames = $false
$immutableIDAlreadyIssuedforUsers = $false
$oneOfVerifiedDomainNames = 'example.com'   # Replace example.com with one of your verified domains

$rule1 = '@RuleName = "Issue account type for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "DJ"
);'

$rule2 = '@RuleName = "Issue object GUID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
   query = ";objectguid;{0}",
   param = c2.Value
);'

$rule3 = '@RuleName = "Issue objectSID for domain-joined computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);'

$rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "DJ"
]
)
=> add(
   Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
   Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
   Value == "User"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = regexreplace(
   c1.Value,
   ".+@(?<domain>.+)",
   "http://${domain}/adfs/services/trust/"
   )
);

@RuleName = "Issue issuerID for domain-joined computers"
c:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
   Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);'
}

$rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers"
c1:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "-515$",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
   Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
   store = "Active Directory",
   types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
   query = ";objectguid;{0}",
   param = c2.Value
);'
}

$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules 

$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5

$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules

Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString

Osservazioni

  • Questo script aggiunge le regole a quelle esistenti. Non eseguire lo script due volte, perché il set di regole verrà aggiunto due volte. Prima di eseguire di nuovo lo script, verificare che non esistano regole corrispondenti per le attestazioni (in condizioni corrispondenti).

  • Se si hanno più nomi di dominio verificati (visualizzati nel portale di Azure AD o tramite il cmdlet Get-MsolDomains), impostare il valore di $multipleVerifiedDomainNames nello script su $true. Assicurarsi anche di rimuovere qualsiasi attestazione issuerid esistente che potrebbe essere stata creata da Azure AD Connect o con altri mezzi. Ecco un esempio di questa regola:

    c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
    => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)",  "http://${domain}/adfs/services/trust/")); 
    

Se è già stata emessa un'attestazione ImmutableID per gli account utente, impostare il valore di $immutableIDAlreadyIssuedforUsers nello script su $true.

Configurare il servizio federativo per i dispositivi di livello inferiore

I dispositivi downlevel richiedono al servizio federativo locale di rilasciare attestazioni per supportare l'autenticazione di Windows integrata (IWA) per la registrazione del dispositivo.

Il servizio federativo locale deve supportare il rilascio delle attestazioni authenticationmehod e wiaormultiauthn alla ricezione di una richiesta di autenticazione per la relying party di Azure AD contenente un parametro resouce_params con il valore codificato seguente:

eyJQcm9wZXJ0aWVzIjpbeyJLZXkiOiJhY3IiLCJWYWx1ZSI6IndpYW9ybXVsdGlhdXRobiJ9XX0

which decoded is {"Properties":[{"Key":"acr","Value":"wiaormultiauthn"}]}

Quando si verifica una richiesta di questo tipo, il servizio federativo locale deve autenticare l'utente usando autenticazione di Windows integrato. Se l'autenticazione riesce, il servizio federativo deve rilasciare le due attestazioni seguenti:

http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows http://schemas.microsoft.com/claims/wiaormultiauthn

In AD FS, è necessario avere una regola di trasformazione rilascio che trasmetta il metodo di autenticazione. Per aggiungere questa regola:

  1. Nella console di gestione di AD FS, passare adAD FS>Relazioni di attendibilità>Attendibilità componente.

  2. Fare clic con il pulsante destro del mouse sull'oggetto trust della relying party della Piattaforma delle identità di Microsoft Office 365 e quindi scegliere Modifica regole attestazione.

  3. Nella scheda Regole di trasformazione rilascio selezionare Aggiungi regola.

  4. Nell'elenco dei modelli delle regole di attestazione selezionare Inviare attestazioni mediante una regola personalizzata.

  5. Selezionare Avanti.

  6. Nella casella di testo Nome regola attestazione digitare Regola attestazione metodo di autenticazione.

  7. Nella casella Claim rule (Regola attestazioni) immettere la regola seguente:

    c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);

  8. Nel server federativo immettere il comando di PowerShell seguente. Sostituire <RPObjectName> con il nome dell'oggetto relying party per l'oggetto trust della relying party di Azure AD. Tale oggetto è solitamente denominato Piattaforma delle identità di Microsoft Office 365.

    Set-AdfsRelyingPartyTrust -TargetName <RPObjectName> -AllowedAuthenticationClassReferences wiaormultiauthn

Risolvere i problemi di implementazione

Se si verificano problemi durante il completamento dell'aggiunta ad Azure AD ibrido per dispositivi Windows aggiunti al dominio, vedere:

Passaggi successivi