Configurare manualmente l'aggiunta ibrida a Microsoft Entra

Se si usa Microsoft Entra Connessione è un'opzione, vedere le indicazioni in Configurare l'aggiunta ibrida a Microsoft Entra. L'uso dell'automazione in Microsoft Entra Connessione semplifica notevolmente la configurazione del join ibrido di Microsoft Entra.

Questo articolo illustra la configurazione manuale dei requisiti per l'aggiunta ibrida di Microsoft Entra, inclusi i passaggi per i domini gestiti e federati.

Prerequisiti

  • Microsoft Entra Connect
    • 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 Microsoft Entra Connessione Sync. Per altre informazioni sugli attributi predefiniti del dispositivo sincronizzati con Microsoft Entra ID, vedere Attributi sincronizzati da Microsoft Entra Connessione.
    • Se gli oggetti computer dei dispositivi che vuoi essere aggiunto ibrido a Microsoft Entra appartengono a unità organizzative specifiche, configurare le unità organizzative corrette per la sincronizzazione in Microsoft Entra Connessione. Per altre informazioni su come sincronizzare gli oggetti computer tramite Microsoft Entra Connessione, vedere Filtro basato su unità organizzative.
  • Credenziali di amministratore dell'organizzazione per ognuna delle foreste Active Directory locale Domain Services.
  • (Per i domini federati) Windows Server con Active Directory Federation Services installato.
  • Gli utenti possono registrare i propri dispositivi con Microsoft Entra ID. Altre informazioni su questa impostazione sono disponibili nell'intestazione Configurare le impostazioni del dispositivo, nell'articolo Configurare le impostazioni del dispositivo.

Per l'aggiunta a Microsoft Entra ibrido i dispositivi devono avere accesso alle seguenti risorse Microsoft 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 dell'organizzazione (STS) (per i domini federati)

Avviso

Se l'organizzazione usa server proxy che intercettano il traffico SSL per scenari come la prevenzione della perdita dei dati o le restrizioni del tenant di Microsoft Entra, assicurarsi che il traffico verso questi URL venga escluso da tls break-and-inspect. L'impossibilità di escludere questi URL potrebbe 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 i computer Windows 10 o versioni successive per la registrazione dei dispositivi con Microsoft Entra ID. 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 Proxy WinHTTP Impostazioni distribuito 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 versioni successive possano eseguire correttamente l'autenticazione al proxy in uscita. Poiché i computer Windows 10 o versioni successive 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 di registrazione del dispositivo Connessione ivity.

Impostazione

È possibile configurare i dispositivi aggiunti all'ibrido Microsoft Entra per vari tipi di piattaforme di dispositivi Windows.

Al termine di queste configurazioni, seguire le indicazioni per verificare la registrazione.

Configurare un punto di connessione del servizio

I dispositivi usano un oggetto SCP (Service Connection Point) durante la registrazione per individuare le informazioni sul tenant di Microsoft Entra. Nell'istanza di Active Directory locale, l'oggetto SCP per i dispositivi aggiunti all'ibrido Microsoft Entra deve esistere nella partizione del contesto di denominazione della 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 Microsoft Entra.

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 della modalità di distribuzione di Microsoft Entra Connessione, l'oggetto SCP potrebbe essere già configurato. È possibile verificare l'esistenza dell'oggetto e recuperare i valori di individuazione usando lo script di 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;

$scp . L'output delle parole chiave mostra le informazioni sul tenant di Microsoft Entra. Ecco un esempio:

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

Configurare il rilascio delle attestazioni

In una configurazione federata di Microsoft Entra i dispositivi si basano su AD FS o su un servizio federativo locale da un partner Microsoft per l'autenticazione all'ID Microsoft Entra. I dispositivi eseguono l'autenticazione per ottenere un token di accesso da registrare nel servizio Registrazione dispositivi Microsoft Entra (Azure DRS).

I dispositivi windows correnti eseguono l'autenticazione usando autenticazione di Windows integrati a un endpoint 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 AD FS non è disponibile come servizio federativo locale, seguire le istruzioni del fornitore per assicurarsi che supportino gli endpoint WS-Trust 1.3 o 2005 e che vengano pubblicati tramite il file MEX (Metadata Exchange).

Per completare la registrazione dei dispositivi, nel token ricevuto dal servizio Registrazione dispositivo Azure devono essere presenti le attestazioni seguenti. Azure DRS crea un oggetto dispositivo in Microsoft Entra ID con alcune di queste informazioni. Microsoft Entra Connessione quindi usa queste informazioni per associare l'oggetto dispositivo appena creato all'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 rilasciare 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
);

Problema 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 quando più nomi di dominio verificati si trovano in Microsoft Entra ID

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 rilasciare 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 Microsoft Entra ID. Ad esempio, usare Value = "http://contoso.com/adfs/services/trust/".

Per altre informazioni sui nomi di dominio verificati, vedere Aggiungere un nome di dominio personalizzato all'ID Microsoft Entra.

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

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 verrebbe aggiunto due volte. Prima di eseguire di nuovo lo script, verificare che non esistano regole corrispondenti per le attestazioni (in condizioni corrispondenti).

  • Se sono presenti più nomi di dominio verificati, impostare il valore di $multipleVerifiedDomainNames nello script su $true. Assicurarsi inoltre di rimuovere qualsiasi attestazione issuerid esistente creata da Microsoft Entra Connessione o 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 è stata rilasciata un'attestazione ImmutableID per gli account utente, impostare il valore di $immutableIDAlreadyIssuedforUsers nello script su $true.

Risolvere i problemi di implementazione

Se si verificano problemi durante il completamento dell'aggiunta ibrida a Microsoft Entra per i dispositivi Windows aggiunti a un dominio, vedere: