Integrare l'identità AD FS con il data center dell'hub di Azure Stack

Articolo
10/30/2024

È possibile distribuire l'hub di Azure Stack usando Microsoft Entra ID o Active Directory Federation Services (AD FS) come provider di identità. La scelta deve essere effettuata prima di distribuire l'hub di Azure Stack. In uno scenario connesso è possibile scegliere Microsoft Entra ID o AD FS. Per uno scenario disconnesso è supportato solo Active Directory Federation Services. Questo articolo illustra come integrare Azure Stack Hub AD FS con il data center AD FS.

Importante

Non è possibile cambiare il provider di identità senza ridistribuire l'intera soluzione hub di Azure Stack.

Active Directory Federation Services e Graph

La distribuzione con AD FS consente alle identità in una foresta Active Directory esistente di eseguire l'autenticazione con le risorse nell'hub di Azure Stack. Questa foresta Active Directory esistente richiede una distribuzione di AD FS per consentire la creazione di un trust federativo AD FS.

L'autenticazione fa parte dell'identità. Per gestire il controllo degli accessi in base al ruolo nell'hub di Azure Stack, è necessario configurare il componente Graph. Quando l'accesso a una risorsa viene delegato, il componente Graph cerca l'account utente nella foresta Active Directory esistente usando il protocollo LDAP.

Architettura ad FS dell'hub di Azure Stack

L'istanza esistente di AD FS è il servizio token di sicurezza dell'account che invia attestazioni all'istanza di AD FS dell'hub di Azure Stack (la risorsa del servizio token di sicurezza). Nell'hub di Azure Stack l'automazione crea il trust del provider di attestazioni con l'endpoint dei metadati per l'istanza esistente di AD FS.

Nell'istanza esistente di AD FS è necessario configurare un trust della relying party. Questo passaggio non viene eseguito dall'automazione e deve essere configurato dall'operatore. L'endpoint dell'IP virtuale dell'hub di Azure Stack per AD FS può essere creato usando il modello https://adfs.<Region>.<ExternalFQDN>/.

La configurazione del trust della relying party richiede anche di configurare le regole di trasformazione attestazioni fornite da Microsoft.

Per la configurazione di Graph, è necessario fornire un account del servizio con l'autorizzazione "lettura" in Active Directory esistente. Questo account è necessario come input per l'automazione per abilitare gli scenari di controllo degli accessi in base al ruolo.

Per l'ultimo passaggio viene configurato un nuovo proprietario per la sottoscrizione del provider predefinita. Questo account ha accesso completo a tutte le risorse quando si accede al portale di amministrazione dell'hub di Azure Stack.

Requisiti:

Componente	Requisito
Grafico	Microsoft Active Directory 2012/2012 R2/2016 2019
AD FS	Windows Server 2012/2012 R2/2016 2019

Configurazione dell'integrazione di Graph

Graph supporta solo l'integrazione con una singola foresta di Active Directory. Se esistono più foreste, verrà usata solo quella specificata nella configurazione per recuperare utenti e gruppi.

Come input per i parametri di automazione sono necessarie le informazioni seguenti:

Parametro	Parametro del foglio di lavoro di distribuzione	Descrizione	Esempio
`CustomADGlobalCatalog`	Nome di dominio completo della foresta AD FS	FQDN della foresta di Active Directory di destinazione con cui si vuole eseguire l'integrazione	Contoso.com
`CustomADAdminCredentials`		Un utente con autorizzazione di lettura LDAP	graphservice

Configurare i siti di Active Directory

Per le distribuzioni di Active Directory con più siti, configurare il sito di Active Directory più vicino alla distribuzione dell'hub di Azure Stack. Questa operazione di configurazione consente di evitare che l'hub di Azure Stack Graph servizio risolva le query usando un server di catalogo globale di un sito remoto.

Aggiungere la subnet di rete VIP pubblica dell'hub di Azure Stack al sito di Active Directory più vicino all'hub di Azure Stack. Si supponga, ad esempio, che per Active Directory esistano due siti, ovvero Seattle e Redmond. Se l'hub di Azure Stack viene distribuito nel sito di Seattle, aggiungere la subnet di rete di IP virtuali pubblica dell'hub di Azure Stack al sito di Active Directory per Seattle.

Per altre informazioni sui siti di Active Directory, vedere Progettazione della topologia del sito.

Nota

Se Active Directory è costituito da un singolo sito, è possibile ignorare questo passaggio. Se è configurata una subnet catch-all, verificare che la subnet di rete VIP pubblica dell'hub di Azure Stack non faccia parte di essa.

Creare un account utente nell'istanza esistente di Active Directory (facoltativo)

Facoltativamente, è possibile creare un account per il servizio Graph nell'istanza esistente di Active Directory. Eseguire questo passaggio se non si ha già un account che si vuole usare.

Nell'istanza esistente di Active Directory creare l'account utente seguente (consiglio):
- Nome utente: graphservice
- Password: usare una password complessa e configurarla in modo che non scada mai.
Non sono necessarie autorizzazioni o appartenenze speciali.

Attivare l'automazione per configurare Graph

Per questa procedura usare un computer nella rete del data center in grado di comunicare con l'endpoint con privilegi nell'hub di Azure Stack.

Aprire una sessione di Windows PowerShell con privilegi elevati (eseguita come amministratore) e connettersi all'indirizzo IP dell'endpoint con privilegi. Usare le credenziali per l'autenticazione di CloudAdmin.
```
$creds = Get-Credential
$pep = New-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
```
Ora che si dispone di una sessione con l'endpoint con privilegi, eseguire il comando seguente:

Eseguire lo script seguente per l'hub di Azure Stack build 2008 e versioni successive
```
 $i = @(
        [pscustomobject]@{ 
                  CustomADGlobalCatalog="fabrikam.com"
                  CustomADAdminCredential= Get-Credential -Message "Do not include the domain name of the graphservice account in the username."
                  SkipRootDomainValidation = $false 
                  ValidateParameters = $true
                }) 

 Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -customCatalog $using:i} 
```
Eseguire lo script seguente per la compilazione dell'hub di Azure Stack prima del 2008
```
Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -CustomADGlobalCatalog contoso.com} 
```
Quando richiesto, specificare le credenziali per l'account utente che si vuole usare per il servizio Graph, ad esempio graphservice. Il valore di input per il cmdlet Register-DirectoryService deve essere il nome della foresta o il dominio radice nella foresta anziché qualsiasi altro dominio nella foresta.

Importante

Attendere il popup delle credenziali (Get-Credential non è supportato nell'endpoint con privilegi) e immettere le credenziali dell'account del servizio Graph.

Il cmdlet Register-DirectoryService include parametri facoltativi che è possibile usare in determinati scenari in cui la convalida dell'istanza esistente di Active Directory non riesce. Quando questo cmdlet viene eseguito, verifica che il dominio fornito sia il dominio radice, sia possibile raggiungere un server di catalogo globale e che all'account fornito venga concesso l'accesso in lettura.

Parametro	Descrizione
`SkipRootDomainValidation`	Specifica che è necessario usare un dominio figlio anziché il dominio radice consigliato.
`ValidateParameters`	Ignora tutti i controlli di convalida.

Protocolli e porte di Graph

Il servizio Graph nell'hub di Azure Stack usa i protocolli e le porte seguenti per comunicare con un server di catalogo globale (GC) scrivibile e il Centro distribuzione chiavi (KDC) in grado di elaborare le richieste di accesso nella foresta di Active Directory di destinazione.

Il servizio Graph nell'hub di Azure Stack usa i protocolli e le porte seguenti per comunicare con l'istanza di Active Directory di destinazione:

Tipo	Porta	Protocollo
LDAP	389	TCP & UDP
LDAP SSL	636	TCP
GC LDAP	3268	TCP
SSL per GC LDAP	3269	TCP

Configurazione dell'integrazione di AD FS scaricando i metadati della federazione

Le informazioni seguenti sono necessarie come input per i parametri di automazione:

Parametro	Parametro del foglio di lavoro di distribuzione	Descrizione	Esempio
CustomAdfsName	Nome provider AD FS	Nome del provider di attestazioni. Viene visualizzato in questo modo nella pagina di destinazione di AD FS.	Contoso
CustomAD FSFederationMetadataEndpointUri	URI dei metadati di AD FS	Collegamento ai metadati della federazione.	https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml
SigningCertificateRevocationCheck	ND	Parametro facoltativo per ignorare il controllo CRL.	Nessuno

Attivare l'automazione per configurare l'attendibilità del provider di attestazioni nell'hub di Azure Stack (scaricando i metadati della federazione)

Per questa procedura, usare un computer in grado di comunicare con l'endpoint con privilegi nell'hub di Azure Stack. È previsto che il certificato usato dall'account STS AD FS sia considerato attendibile dall'hub di Azure Stack.

Aprire una sessione di Windows PowerShell con privilegi elevati e connettersi all'endpoint con privilegi.

$creds = Get-Credential
Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Ora che si è connessi all'endpoint con privilegi, eseguire il comando seguente usando i parametri appropriati per l'ambiente:

Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataEndpointUri "https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml"

Eseguire il comando seguente per aggiornare il proprietario della sottoscrizione del provider predefinita usando i parametri appropriati per l'ambiente:
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
```

Configurazione dell'integrazione di AD FS fornendo il file di metadati federativo

A partire dalla versione 1807, usare questo metodo se una delle condizioni seguenti è vera:

La catena di certificati è diversa per AD FS rispetto a tutti gli altri endpoint nell'hub di Azure Stack.
Non esiste connettività di rete al server AD FS esistente dall'istanza di AD FS dell'hub di Azure Stack.

Le informazioni seguenti sono necessarie come input per i parametri di automazione:

Parametro	Descrizione	Esempio
CustomAdfsName	Nome del provider di attestazioni. Viene visualizzato in questo modo nella pagina di destinazione di AD FS.	Contoso
CustomADFSFederationMetadataFileContent	Contenuto dei metadati.	$using:federationMetadataFileContent

Creare il file di metadati della federazione

Per la procedura seguente, è necessario utilizzare un computer con connettività di rete alla distribuzione AD FS esistente, che diventa il servizio token di sicurezza dell'account. È necessario installare anche i certificati necessari.

Aprire una sessione di Windows PowerShell con privilegi elevati ed eseguire il comando seguente usando i parametri appropriati per l'ambiente:

 $url = "https://win-SQOOJN70SGL.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml"
 $webclient = New-Object System.Net.WebClient
 $webclient.Encoding = [System.Text.Encoding]::UTF8
 $metadataAsString = $webclient.DownloadString($url)
 Set-Content -Path c:\metadata.xml -Encoding UTF8 -Value $metadataAsString

Copiare il file di metadati in un computer in grado di comunicare con l'endpoint con privilegi.

Attivare l'automazione per configurare l'attendibilità del provider di attestazioni nell'hub di Azure Stack (usando il file di metadati federativo)

Per questa procedura, usare un computer in grado di comunicare con l'endpoint con privilegi nell'hub di Azure Stack e di accedere al file di metadati creato in un passaggio precedente.

Aprire una sessione di Windows PowerShell con privilegi elevati e connettersi all'endpoint con privilegi.

$federationMetadataFileContent = get-content c:\metadata.xml
$creds=Get-Credential
Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Ora che si è connessi all'endpoint con privilegi, eseguire il comando seguente usando i parametri appropriati per l'ambiente:
```
Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataFileContent $using:federationMetadataFileContent
```
Eseguire il comando seguente per aggiornare il proprietario della sottoscrizione del provider predefinita. Usare i parametri appropriati per l'ambiente.
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
```
Nota

Quando si ruota il certificato nell'istanza di AD FS (account STS) esistente, è necessario configurare di nuovo l'integrazione di AD FS. È necessario configurare l'integrazione anche se l'endpoint dei metadati è raggiungibile o è stato configurato fornendo il file di metadati.

Configurare la relying party sulla distribuzione di AD FS esistente (servizio token di sicurezza dell'account)

Microsoft fornisce uno script che configura l'attendibilità della relying party, incluse le regole di trasformazione delle attestazioni. L'uso dello script è facoltativo perché è possibile eseguire manualmente i comandi.

È possibile scaricare lo script helper da Strumenti dell'hub di Azure Stack in GitHub.

Se si decide di eseguire manualmente i comandi, seguire questa procedura:

Copiare il contenuto seguente in un file di .txt (ad esempio, salvato come c:\ClaimIssuanceRules.txt) nell'istanza o nel membro della farm AD FS del data center:

@RuleTemplate = "LdapClaims"
@RuleName = "Name claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"), query = ";userPrincipalName;{0}", param = c.Value);

@RuleTemplate = "LdapClaims"
@RuleName = "UPN claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);

@RuleTemplate = "LdapClaims"
@RuleName = "ObjectID claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
=> issue(Type = "http://schemas.microsoft.com/identity/claims/objectidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Family Name and Given claim"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"), query = ";sn,givenName;{0}", param = c.Value);

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Group SID claims"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all windows account name claims"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(claim = c);

Verificare che l'autenticazione basata su Windows Forms per Extranet e Intranet sia abilitata. È possibile verificare se la funzionalità è già abilitata eseguendo il cmdlet seguente:
```
Get-AdfsAuthenticationProvider | where-object { $_.name -eq "FormsAuthentication" } | select Name, AllowedForPrimaryExtranet, AllowedForPrimaryIntranet
```
Nota

Le stringhe dell'agente utente supportate da Windows Integrated Authentication (WIA) potrebbero essere obsolete per la distribuzione di AD FS e potrebbero richiedere un aggiornamento per supportare i client più recenti. Per altre informazioni sull'aggiornamento delle stringhe dell'agente utente supportate da WiA, vedere l'articolo Configurazione dell'autenticazione basata su moduli Intranet per i dispositivi che non supportano WiA.

Per i passaggi per abilitare i criteri di autenticazione basati su form, vedere Configurare i criteri di autenticazione.
Per aggiungere l'attendibilità della relying party, eseguire il comando Windows PowerShell seguente nell'istanza di AD FS o in un membro della farm. Assicurarsi di aggiornare l'endpoint AD FS e puntare al file creato nel passaggio 1.

Importante

Per i clienti che eseguono l'hub di Azure Stack versione 2002 e successive, TLS 1.2 viene applicato all'endpoint ADFS dell'hub di Azure Stack. Di conseguenza, TLS 1.2 deve essere abilitato anche nei server ADFS del cliente. In caso contrario, si verificherà l'errore seguente durante l'esecuzione Add-ADFSRelyingPartyTrust nell'host/farm ADFS di proprietà del cliente:

Add-ADFSRelyingPartyTrust : The underlying connection was closed: An unexpected error occurred on a send.

Per AD FS 2016/2019
```
Add-ADFSRelyingPartyTrust -Name AzureStack -MetadataUrl "https://YourAzureStackADFSEndpoint/FederationMetadata/2007-06/FederationMetadata.xml" -IssuanceTransformRulesFile "C:\ClaimIssuanceRules.txt" -AutoUpdateEnabled:$true -MonitoringEnabled:$true -enabled:$true -AccessControlPolicyName "Permit everyone" -TokenLifeTime 1440
```
Per AD FS 2012/2012 R2
```
Add-ADFSRelyingPartyTrust -Name AzureStack -MetadataUrl "https://YourAzureStackADFSEndpoint/FederationMetadata/2007-06/FederationMetadata.xml" -IssuanceTransformRulesFile "C:\ClaimIssuanceRules.txt" -AutoUpdateEnabled:$true -MonitoringEnabled:$true -enabled:$true -TokenLifeTime 1440
```
Importante

È necessario utilizzare lo snap-in MMC DI AD FS per configurare le regole di autorizzazione di rilascio quando si utilizza Windows Server 2012 o 2012 R2 AD FS.
Quando si usa Internet Explorer o il browser Microsoft Edge per accedere all'hub di Azure Stack, è necessario ignorare le associazioni di token. In caso contrario, i tentativi di accesso hanno esito negativo. Nell'istanza di AD FS o in un membro della farm eseguire il comando seguente:

Nota

Questo passaggio non è applicabile quando si usa AD FS Windows Server 2012 o 2012 R2. In questo caso, è possibile ignorare questo comando e continuare con l'integrazione.
```
Set-AdfsProperties -IgnoreTokenBinding $true
```

Creazione di un nome dell'entità servizio

Esistono molti scenari che richiedono l'uso di un nome dell'entità servizio (SPN) per l'autenticazione. Di seguito vengono riportati alcuni esempi.

Utilizzo dell'interfaccia della riga di comando di Azure con la distribuzione ad FS dell'hub di Azure Stack.
Management Pack di System Center per l'hub di Azure Stack quando viene distribuito con AD FS.
Provider di risorse nell'hub di Azure Stack quando vengono distribuiti con AD FS.
Varie app.
È necessario un accesso non interattivo.

Importante

AD FS supporta solo sessioni di accesso interattive. Se è necessario un accesso non interattivo per uno scenario automatizzato, è necessario usare un nome SPN.

Per altre informazioni sulla creazione di un nome SPN, vedere Creare un'entità servizio per AD FS.

Risoluzione dei problemi

Rollback della configurazione

Se si verifica un errore che lascia l'ambiente in uno stato in cui non è più possibile eseguire l'autenticazione, è disponibile un'opzione di rollback.

Aprire una sessione di Windows PowerShell con privilegi elevati ed eseguire i comandi seguenti:

$creds = Get-Credential
Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Eseguire quindi il cmdlet seguente:
```
Reset-DatacenterIntegrationConfiguration
```
Dopo aver eseguito l'azione di rollback, viene eseguito il rollback di tutte le modifiche di configurazione. È possibile solo l'autenticazione con l'utente CloudAdmin predefinito.

Importante

È necessario configurare il proprietario originale della sottoscrizione del provider predefinita.
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "azurestackadmin@[Internal Domain]"
```

Raccolta di log aggiuntivi

Se uno dei cmdlet ha esito negativo, è possibile raccogliere log aggiuntivi usando il Get-Azurestacklogs cmdlet .