Dela via


Integrera AD FS-identitet med ditt Azure Stack Hub-datacenter

Du kan distribuera Azure Stack Hub med hjälp av Microsoft Entra-ID eller Active Directory Federation Services (AD FS) (AD FS) som identitetsprovider. Du måste välja innan du distribuerar Azure Stack Hub. I ett anslutet scenario kan du välja Microsoft Entra ID eller AD FS. För ett frånkopplat scenario stöds endast AD FS. Den här artikeln visar hur du integrerar Azure Stack Hub AD FS med ditt datacenter AD FS.

Viktigt!

Du kan inte växla identitetsprovidern utan att distribuera om hela Azure Stack Hub-lösningen.

Active Directory Federation Services (AD FS) och Graph

Om du distribuerar med AD FS kan identiteter i en befintlig Active Directory-skog autentiseras med resurser i Azure Stack Hub. Den befintliga Active Directory-skogen kräver en distribution av AD FS för att skapa ett AD FS-federationsförtroende.

Autentisering är en del av identiteten. Om du vill hantera rollbaserad åtkomstkontroll (RBAC) i Azure Stack Hub måste Graph-komponenten konfigureras. När åtkomsten till en resurs delegeras letar Graph-komponenten upp användarkontot i den befintliga Active Directory-skogen med hjälp av LDAP-protokollet.

Azure Stack Hub AD FS-arkitektur

Den befintliga AD FS är kontosäkerhetstokentjänsten (STS) som skickar anspråk till Azure Stack Hub AD FS (resursen STS). I Azure Stack Hub skapar automation anspråksproviderns förtroende med metadataslutpunkten för den befintliga AD FS.

I den befintliga AD FS måste ett förlitande partförtroende konfigureras. Det här steget utförs inte av automatiseringen och måste konfigureras av operatorn. Azure Stack Hub VIP-slutpunkten för AD FS kan skapas med hjälp av mönstret https://adfs.<Region>.<ExternalFQDN>/.

Den förlitande partens förtroendekonfiguration kräver också att du konfigurerar de regler för anspråkstransformering som tillhandahålls av Microsoft.

För Graph-konfigurationen måste ett tjänstkonto anges som har läsbehörighet i den befintliga Active Directory. Det här kontot krävs som indata för automatiseringen för att aktivera RBAC-scenarier.

För det sista steget konfigureras en ny ägare för standardleverantörsprenumerationen. Det här kontot har fullständig åtkomst till alla resurser när det är loggat in på Azure Stack Hub-administratörsportalen.

Krav:

Komponent Krav
Diagram Microsoft Active Directory 2012/2012 R2/2016 2019
AD FS Windows Server 2012/2012 R2/2016 2019

Konfigurera Graph-integrering

Graph stöder endast integrering med en enda Active Directory-skog. Om det finns flera skogar används endast den skog som anges i konfigurationen för att hämta användare och grupper.

Följande information krävs som indata för automatiseringsparametrarna:

Parameter Parameter för distributionskalkylblad beskrivning Exempel
CustomADGlobalCatalog AD FS Forest FQDN FQDN för den Active Directory-målskog som du vill integrera med Contoso.com
CustomADAdminCredentials En användare med läsbehörighet för LDAP graphservice

Konfigurera Active Directory-platser

För Active Directory-distributioner som har flera platser konfigurerar du närmaste Active Directory-plats till din Azure Stack Hub-distribution. Konfigurationen undviker att Azure Stack Hub Graph-tjänsten löser frågor med hjälp av en global katalogserver från en fjärrplats.

Lägg till det offentliga VIP-nätverksundernätet i Azure Stack Hub till den Active Directory-plats som är närmast Azure Stack Hub. Anta till exempel att din Active Directory har två platser: Seattle och Redmond. Om Azure Stack Hub distribueras på Seattle-platsen lägger du till det offentliga VIP-nätverksundernätet för Azure Stack Hub till Active Directory-platsen för Seattle.

Mer information om Active Directory-webbplatser finns i Designa platstopologin.

Kommentar

Om din Active Directory består av en enda webbplats kan du hoppa över det här steget. Om du har konfigurerat ett catch-all-undernät kontrollerar du att det offentliga VIP-nätverket i Azure Stack Hub inte ingår i det.

Skapa användarkonto i den befintliga Active Directory (valfritt)

Du kan också skapa ett konto för Graph-tjänsten i den befintliga Active Directory. Gör det här steget om du inte redan har ett konto som du vill använda.

  1. I den befintliga Active Directory skapar du följande användarkonto (rekommendation):

    • Användarnamn: graphservice
    • Lösenord: Använd ett starkt lösenord och konfigurera lösenordet så att det aldrig upphör att gälla.

    Inga särskilda behörigheter eller medlemskap krävs.

Utlösa automatisering för att konfigurera graf

För den här proceduren använder du en dator i ditt datacenternätverk som kan kommunicera med den privilegierade slutpunkten i Azure Stack Hub.

  1. Öppna en upphöjd Windows PowerShell-session (kör som administratör) och anslut till IP-adressen för den privilegierade slutpunkten. Använd autentiseringsuppgifterna för CloudAdmin för att autentisera.

    $creds = Get-Credential
    $pep = New-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
    
  2. Nu när du har en session med den privilegierade slutpunkten kör du följande kommando:

    Kör skriptet nedan för Azure Stack Hub build 2008 och senare

     $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} 
    
    
    

    Kör skriptet nedan för Azure Stack Hub-versionen före 2008

    Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -CustomADGlobalCatalog contoso.com} 
    
    
    

    När du uppmanas till det anger du autentiseringsuppgifterna för det användarkonto som du vill använda för Graph-tjänsten (till exempel graphservice). Indata för cmdleten Register-DirectoryService måste vara skogens namn/rotdomän i skogen i stället för någon annan domän i skogen.

    Viktigt!

    Vänta på popup-fönstret autentiseringsuppgifter (Get-Credential stöds inte i den privilegierade slutpunkten) och ange autentiseringsuppgifterna för Graph Service-kontot.

  3. Cmdleten Register-DirectoryService har valfria parametrar som du kan använda i vissa scenarier där den befintliga Active Directory-verifieringen misslyckas. När den här cmdleten körs verifierar den att den angivna domänen är rotdomänen, att en global katalogserver kan nås och att det angivna kontot beviljas läsåtkomst.

    Parameter Description
    SkipRootDomainValidation Anger att en underordnad domän måste användas i stället för den rekommenderade rotdomänen.
    ValidateParameters Kringgår alla valideringskontroller.

Graph-protokoll och -portar

Graph-tjänsten i Azure Stack Hub använder följande protokoll och portar för att kommunicera med en skrivbar global katalogserver (GC) och Key Distribution Center (KDC) som kan bearbeta inloggningsbegäranden i Active Directory-målskogen.

Graph-tjänsten i Azure Stack Hub använder följande protokoll och portar för att kommunicera med active directory-målet:

Typ Port Protokoll
LDAP 389 TCP och UDP
LDAP SSL 636 TCP
LDAP GC 3268 TCP
LDAP GC SSL 3269 TCP

Konfigurera AD FS-integrering genom att ladda ned federationsmetadata

Följande information krävs som indata för automatiseringsparametrarna:

Parameter Parameter för distributionskalkylblad beskrivning Exempel
CustomAdfsName AD FS-providernamn Namn på anspråksprovidern.
Det visas så på AD FS-landningssidan.
Contoso
CustomAD
FSFederationMetadataEndpointUri
AD FS-metadata-URI Länk till federationsmetadata. https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml
SigningCertificateRevocationCheck NA Valfri parameter för att hoppa över CRL-kontroll. Ingen

Utlösa automatisering för att konfigurera anspråksproviderns förtroende i Azure Stack Hub (genom att ladda ned federationsmetadata)

För den här proceduren använder du en dator som kan kommunicera med den privilegierade slutpunkten i Azure Stack Hub. Det förväntas att certifikatet som används av kontot STS AD FS är betrott av Azure Stack Hub.

  1. Öppna en upphöjd Windows PowerShell-session och anslut till den privilegierade slutpunkten.

    $creds = Get-Credential
    Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
    
  2. Nu när du är ansluten till den privilegierade slutpunkten kör du följande kommando med hjälp av de parametrar som är lämpliga för din miljö:

    Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataEndpointUri "https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml"
    
  3. Kör följande kommando för att uppdatera ägaren till standardleverantörsprenumerationen med hjälp av de parametrar som är lämpliga för din miljö:

    Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
    

Konfigurera AD FS-integrering genom att tillhandahålla federationsmetadatafil

Från och med version 1807 använder du den här metoden om något av följande villkor är sant:

  • Certifikatkedjan skiljer sig för AD FS jämfört med alla andra slutpunkter i Azure Stack Hub.
  • Det finns ingen nätverksanslutning till den befintliga AD FS-servern från Ad FS-instansen i Azure Stack Hub.

Följande information krävs som indata för automatiseringsparametrarna:

Parameter Description Exempel
CustomAdfsName Namn på anspråksprovidern. Det visas så på AD FS-landningssidan. Contoso
CustomADFSFederationMetadataFileContent Metadatainnehåll. $using:federationMetadataFileContent

Skapa federationsmetadatafil

För följande procedur måste du använda en dator som har nätverksanslutning till den befintliga AD FS-distributionen, som blir kontot STS. De nödvändiga certifikaten måste också installeras.

  1. Öppna en upphöjd Windows PowerShell-session och kör följande kommando med hjälp av de parametrar som är lämpliga för din miljö:

     $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
    
  2. Kopiera metadatafilen till en dator som kan kommunicera med den privilegierade slutpunkten.

Utlösa automatisering för att konfigurera anspråksproviderns förtroende i Azure Stack Hub (med hjälp av federationsmetadatafil)

För den här proceduren använder du en dator som kan kommunicera med den privilegierade slutpunkten i Azure Stack Hub och har åtkomst till metadatafilen som du skapade i ett tidigare steg.

  1. Öppna en upphöjd Windows PowerShell-session och anslut till den privilegierade slutpunkten.

    $federationMetadataFileContent = get-content c:\metadata.xml
    $creds=Get-Credential
    Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
    
  2. Nu när du är ansluten till den privilegierade slutpunkten kör du följande kommando med hjälp av de parametrar som är lämpliga för din miljö:

    Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataFileContent $using:federationMetadataFileContent
    
  3. Kör följande kommando för att uppdatera ägaren till standardleverantörsprenumerationen. Använd de parametrar som är lämpliga för din miljö.

    Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
    

    Kommentar

    När du roterar certifikatet på den befintliga AD FS (konto-STS) måste du konfigurera AD FS-integreringen igen. Du måste konfigurera integreringen även om metadataslutpunkten kan nås eller om den har konfigurerats genom att tillhandahålla metadatafilen.

Konfigurera förlitande part för befintlig AD FS-distribution (konto-STS)

Microsoft tillhandahåller ett skript som konfigurerar det förlitande partförtroendet, inklusive reglerna för anspråkstransformering. Det är valfritt att använda skriptet eftersom du kan köra kommandona manuellt.

Du kan ladda ned hjälpskriptet från Azure Stack Hub Tools på GitHub.

Om du bestämmer dig för att köra kommandona manuellt följer du dessa steg:

  1. Kopiera följande innehåll till en .txt fil (till exempel sparad som c:\ClaimIssuanceRules.txt) på ditt datacenters AD FS-instans eller servergruppsmedlem:

    @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);
    
  2. Verifiera att Windows Forms-baserad autentisering för extranät och intranät är aktiverat. Du kan kontrollera om det redan är aktiverat genom att köra följande cmdlet:

    Get-AdfsAuthenticationProvider | where-object { $_.name -eq "FormsAuthentication" } | select Name, AllowedForPrimaryExtranet, AllowedForPrimaryIntranet
    

    Kommentar

    Windows-integrerad autentisering (WIA) som stöds av användaragentsträngar kan vara inaktuella för AD FS-distributionen och kan kräva en uppdatering för att stödja de senaste klienterna. Du kan läsa mer om att uppdatera wia-användaragentsträngar som stöds i artikeln Konfigurera formulärbaserad autentisering för intranät för enheter som inte stöder WIA.

    Anvisningar för att aktivera formulärbaserad autentiseringsprincip finns i Konfigurera autentiseringsprinciper.

  3. Om du vill lägga till det förlitande partförtroendet kör du följande Windows PowerShell-kommando på din AD FS-instans eller en servergruppsmedlem. Se till att uppdatera AD FS-slutpunkten och peka på filen som skapades i steg 1.

    Viktigt!

    För kunder som kör Azure Stack Hub-versionerna 2002 och senare tillämpas TLS 1.2 på Azure Stack Hub ADFS-slutpunkten. Därför måste TLS 1.2 också aktiveras på kundens ADFS-servrar. I annat fall uppstår följande fel när det körs Add-ADFSRelyingPartyTrust på den kundägda ADFS-värden/-servergruppen:

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

    För 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
    

    För 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
    

    Viktigt!

    Du måste använda snapin-modulen AD FS MMC för att konfigurera auktoriseringsregler för utfärdande när du använder Windows Server 2012 eller 2012 R2 AD FS.

  4. När du använder Internet Explorer eller Microsoft Edge-webbläsaren för att få åtkomst till Azure Stack Hub måste du ignorera tokenbindningar. Annars misslyckas inloggningsförsöken. Kör följande kommando på din AD FS-instans eller en servergruppsmedlem:

    Kommentar

    Det här steget gäller inte när du använder Windows Server 2012 eller 2012 R2 AD FS. I så fall är det säkert att hoppa över det här kommandot och fortsätta med integreringen.

    Set-AdfsProperties -IgnoreTokenBinding $true
    

Skapa SPN

Det finns många scenarier som kräver användning av ett tjänsthuvudnamn (SPN) för autentisering. Följande är några exempel:

  • Azure CLI-användning med AD FS-distribution av Azure Stack Hub.
  • System Center Management Pack för Azure Stack Hub när det distribueras med AD FS.
  • Resursprovidrar i Azure Stack Hub när de distribueras med AD FS.
  • Olika appar.
  • Du behöver en icke-interaktiv inloggning.

Viktigt!

AD FS stöder endast interaktiva inloggningssessioner. Om du behöver en icke-interaktiv inloggning för ett automatiserat scenario måste du använda ett SPN.

Mer information om hur du skapar ett SPN finns i Skapa tjänstens huvudnamn för AD FS.

Felsökning

Återställning av konfiguration

Om ett fel inträffar som lämnar miljön i ett tillstånd där du inte längre kan autentisera, är ett återställningsalternativ tillgängligt.

  1. Öppna en upphöjd Windows PowerShell-session och kör följande kommandon:

    $creds = Get-Credential
    Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
    
  2. Kör sedan följande cmdlet:

    Reset-DatacenterIntegrationConfiguration
    

    När återställningsåtgärden har körts återställs alla konfigurationsändringar. Endast autentisering med den inbyggda CloudAdmin-användaren är möjlig.

    Viktigt!

    Du måste konfigurera den ursprungliga ägaren av standardleverantörsprenumerationen.

    Set-ServiceAdminOwner -ServiceAdminOwnerUpn "azurestackadmin@[Internal Domain]"
    

Samla in ytterligare loggar

Om någon av cmdletarna misslyckas kan du samla in ytterligare loggar med hjälp av cmdleten Get-Azurestacklogs .

  1. Öppna en upphöjd Windows PowerShell-session och kör följande kommandon:

    $creds = Get-Credential
    Enter-pssession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
    
  2. Kör sedan följande cmdlet:

    Get-AzureStackLog -OutputPath \\myworkstation\AzureStackLogs -FilterByRole ECE
    

Nästa steg

Integrera externa övervakningslösningar