Integrieren der AD FS-Identität in Ihr Azure Stack Hub-Rechenzentrum

Artikel
03/29/2024

Sie können Azure Stack Hub mit Microsoft Entra ID oder Active Directory-Verbunddienste (AD FS) (AD FS) als Identitätsanbieter bereitstellen. Sie müssen diese Auswahl treffen, bevor Sie Azure Stack Hub bereitstellen. In einem verbundenen Szenario können Sie Microsoft Entra ID oder AD FS auswählen. In einem nicht verbundenen Szenario wird nur AD FS unterstützt. In diesem Artikel erfahren Sie, wie Sie Azure Stack Hub-AD FS in die AD FS des Rechenzentrums integrieren.

Wichtig

Sie können den Identitätsanbieter nicht wechseln, ohne die gesamte Azure Stack Hub-Lösung erneut bereitzustellen.

Active Directory-Verbunddienste (AD FS) und Graph

Die Bereitstellung mit AD FS gestattet Identitäten in einer vorhandenen Active Directory-Gesamtstruktur die Authentifizierung mit Ressourcen in Azure Stack Hub. Diese vorhandene Active Directory-Gesamtstruktur erfordert eine Bereitstellung von AD FS, um das Erstellen einer AD FS-Verbundvertrauensstellung zu ermöglichen.

Authentifizierung ist ein Teil der Identität. Damit die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) in Azure Stack Hub verwaltet werden kann, muss die Graph-Komponente konfiguriert werden. Wenn der Zugriff auf eine Ressource delegiert wird, sucht die Graph-Komponente das Benutzerkonto mithilfe des LDAP-Protokolls in der vorhandenen Active Directory-Gesamtstruktur.

AD FS-Architektur von Azure Stack Hub

Die vorhandenen AD FS sind der Konto-Sicherheitstokendienst (STS), der Ansprüche an Azure Stack Hub-AD FS (den Ressourcen-STS) sendet. In Azure Stack Hub wird mithilfe der Automatisierung die Anspruchsanbieter-Vertrauensstellung mit dem Metadatenendpunkt für die vorhandenen AD FS erstellt.

Für die vorhandenen AD FS muss eine Vertrauensstellung der vertrauenden Seite konfiguriert werden. Dieser Schritt erfolgt nicht durch die Automatisierung und muss vom Betreiber konfiguriert werden. Der Azure Stack Hub-VIP-Endpunkt für AD FS kann mithilfe des Musters https://adfs.<Region>.<ExternalFQDN>/ erstellt werden.

Die Vertrauensstellungskonfiguration der vertrauenden Seite erfordert außerdem, dass die Regeln für die Anspruchstransformation konfiguriert werden, die von Microsoft bereitgestellt werden.

Für die Graph-Konfiguration muss ein Dienstkonto bereitgestellt werden, das über „Leseberechtigung“ im vorhandenen Active Directory verfügt. Dieses Konto ist als Eingabe für die Automatisierung erforderlich, um RBAC-Szenarien zu ermöglichen.

Im letzten Schritt wird ein neuer Besitzer für das Anbieterstandardabonnement konfiguriert. Dieses Konto verfügt über Vollzugriff auf alle Ressourcen, wenn es am Azure Stack Hub-Administratorportal angemeldet ist.

Anforderungen:

Komponente	Anforderung
Graph	Microsoft Active Directory 2012/2012 R2/2016 2019
AD FS	Windows Server 2012/2012 R2/2016 2019

Einrichten der Graph-Integration

Graph unterstützt nur die Integration in eine einzelne Active Directory-Gesamtstruktur. Wenn mehrere Gesamtstrukturen vorhanden sind, wird nur die in der Konfiguration angegebene Gesamtstruktur verwendet, um Benutzer und Gruppen abzurufen.

Die folgenden Informationen sind als Eingabe für die Automatisierungsparameter erforderlich:

Parameter	Parameter für das Arbeitsblatt für die Bereitstellung	BESCHREIBUNG	Beispiel
`CustomADGlobalCatalog`	FQDN der AD FS-Gesamtstruktur	FQDN der Active Directory-Zielgesamtstruktur, mit der die Integration erfolgen soll	Contoso.com
`CustomADAdminCredentials`		Ein Benutzer mit LDAP-Leseberechtigung.	graphservice

Konfigurieren von Active Directory-Standorten

Bei Active Directory-Bereitstellungen mit mehreren Standorten sollten Sie den Active Directory-Standort konfigurieren, der Ihrer Azure Stack Hub-Bereitstellung am nächsten liegt. Durch die Konfiguration wird vermieden, dass der Azure Stack Hub-Graph-Dienst Abfragen über einen globalen Katalogserver von einem Remotestandort auflöst.

Fügen Sie das Azure Stack Hub-Subnetz mit öffentlicher VIP dem Active Directory-Standort hinzu, der Azure Stack Hub am nächsten liegt. Nehmen wir beispielsweise an, dass Ihr Active Directory zwei Standorte hat: Seattle und Redmond. Wenn Azure Stack Hub am Standort „Seattle“ bereitgestellt wurde, fügen Sie das Azure Stack Hub-Subnetz mit öffentlicher VIP dem Azure Active Directory-Standort für „Seattle“ hinzu.

Weitere Informationen zu Active Directory-Standorten finden Sie unter Entwerfen der Standorttopologie.

Hinweis

Wenn Ihr Active Directory aus einem einzigen Standort besteht, können Sie diesen Schritt überspringen. Wenn Sie ein Catch-All-Subnetz konfiguriert haben, vergewissern Sie sich, dass das Azure Stack Hub-Subnetz mit öffentlicher VIP-Adresse kein Teil davon ist.

Erstellen eines Benutzerkontos im vorhandenen Active Directory (optional)

Optional können Sie ein Konto für den Graph-Dienst im vorhandenen Active Directory erstellen. Führen Sie diesen Schritt aus, wenn Sie noch kein Konto haben, das Sie verwenden möchten.

Erstellen Sie im vorhandenen Active Directory das folgende Benutzerkonto (Empfehlung):
- Benutzername: graphservice
- Kennwort: Verwenden Sie ein sicheres Kennwort, und konfigurieren Sie es so, dass es nie abläuft.
Es sind keine speziellen Berechtigungen oder eine Mitgliedschaft erforderlich.

Auslösen der Automatisierung zum Konfigurieren von Graph

Verwenden Sie für diesen Vorgang einen Computer in Ihrem Rechenzentrumsnetzwerk, der mit dem privilegierten Endpunkt in Azure Stack Hub kommunizieren kann.

Öffnen Sie eine Windows PowerShell-Sitzung mit erhöhten Rechten (Als Administrator ausführen), und stellen Sie eine Verbindung zur IP-Adresse des privilegierten Endpunkts her. Verwenden Sie die Anmeldeinformationen für die CloudAdmin-Authentifizierung.
```
$creds = Get-Credential
$pep = New-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)
```
Nachdem Sie nun eine Sitzung mit dem privilegierten Endpunkt haben, führen Sie folgenden Befehl aus.

Führen Sie das folgende Skript für Azure Stack Hub Build 2008 und höher aus:
```
 $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} 
```
Führen Sie das folgende Skript für Versionen vor Azure Stack Hub Build 2008 aus:
```
Invoke-Command -Session $pep -ScriptBlock {Register-DirectoryService -CustomADGlobalCatalog contoso.com} 
```
Wenn Sie dazu aufgefordert werden, geben Sie die Anmeldeinformationen für das Benutzerkonto ein, das Sie für die Graph-Dienst verwenden möchten (z.B. „graphservice“). Die Eingabe für das Cmdlet Register-DirectoryService muss der Gesamtstrukturname / die Stammdomäne in der Gesamtstruktur sein statt einer anderen Domäne in der Gesamtstruktur.

Wichtig

Warten Sie, bis die Anmeldeinformationen angezeigt werden („Get-Credential“ wird im privilegierten Endpunkt nicht unterstützt), und geben Sie die Anmeldeinformationen des Graph-Dienstkontos ein.

Das Cmdlet Register-DirectoryService verfügt über optionale Parameter, die Sie in bestimmten Szenarien verwenden können, in denen die vorhandene Active Directory-Überprüfung einen Fehler ergibt. Bei Ausführung dieses Cmdlets wird überprüft, ob die angegebene Domäne die Stammdomäne ist, ein globaler Katalogserver erreichbar ist und für das angegebene Konto Lesezugriff gewährt wird.

Parameter	BESCHREIBUNG
`SkipRootDomainValidation`	Gibt an, dass anstelle der empfohlenen Stammdomäne eine untergeordnete Domäne verwendet werden muss.
`ValidateParameters`	Alle Überprüfungen werden umgangen.

Graph-Protokolle und -Ports

Der Graph-Dienst in Azure Stack Hub verwendet die folgenden Protokolle und Ports für die Kommunikation mit einem beschreibbaren globalen Katalog Server (Global Catalog Server, GC) und Schlüsselverteilungscenter (Key Distribution Center, KDC), die Anmeldeanforderungen in der gewünschten Active Directory-Gesamtstruktur verarbeiten können.

Der Graph-Dienst in Azure Stack Hub verwendet die folgenden Protokolle und Ports für die Kommunikation mit der Active Directory-Zielinstanz:

type	Port	Protocol
LDAP	389	TCP und UDP
LDAP SSL	636	TCP
LDAP GC	3268	TCP
LDAP GC SSL	3269	TCP

Einrichten der AD FS-Integration durch Herunterladen von Verbundmetadaten

Die folgenden Informationen sind als Eingabe für die Automatisierungsparameter erforderlich:

Parameter	Parameter für das Arbeitsblatt für die Bereitstellung	BESCHREIBUNG	Beispiel
CustomAdfsName	AD FS-Anbietername	Der Name der Anspruchsanbieter-Vertrauensstellung. Er wird wie hier angegeben auf der AD FS-Startseite angezeigt.	Contoso
CustomAD FSFederationMetadataEndpointUri	AD FS-Metadaten-URI	Verbundmetadatenlink.	https://ad01.contoso.com/federationmetadata/2007-06/federationmetadata.xml
SigningCertificateRevocationCheck	Nicht verfügbar	Optionaler Parameter, um die CRL-Überprüfung zu überspringen.	Keine

Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbietervertrauensstellung in Azure Stack Hub (durch Herunterladen von Verbundmetadaten)

Verwenden Sie für diesen Vorgang einen Computer, der mit dem privilegierten Endpunkt in Azure Stack Hub kommunizieren kann. Es wird erwartet, dass Azure Stack Hub dem vom Konto STS AD FS verwendeten Zertifikat vertraut.

Öffnen Sie eine Windows PowerShell-Sitzung mit erhöhten Rechten, und stellen Sie eine Verbindung mit dem privilegierten Endpunkt her.
```
$creds = Get-Credential
Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds
```

Da Sie nun mit dem privilegierten Endpunkt verbunden sind, führen Sie den folgenden Befehl mit den Parametern aus, die für Ihre Umgebung geeignet sind:

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

Führen Sie den folgenden Befehl aus, um den Besitzer des Anbieterstandardabonnements zu aktualisieren. Verwenden Sie dabei für Ihre Umgebung geeignete Parameter:
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
```

Einrichten der AD FS-Integration durch Bereitstellen einer Verbundmetadatendatei

Verwenden Sie ab Version 1807 diese Methode, wenn eine der folgenden Bedingungen erfüllt ist:

Die Zertifikatkette für AD FS unterscheidet sich im Vergleich zu allen anderen Endpunkten in Azure Stack Hub.
Es ist keine Netzwerkkonnektivität mit dem vorhandenen AD FS-Server aus der AD FS-Instanz von Azure Stack Hub gegeben.

Die folgenden Informationen sind als Eingabe für die Automatisierungsparameter erforderlich:

Parameter	BESCHREIBUNG	Beispiel
CustomAdfsName	Der Name der Anspruchsanbieter-Vertrauensstellung. Er wird wie hier angegeben auf der AD FS-Startseite angezeigt.	Contoso
CustomADFSFederationMetadataFileContent	Metadateninhalte.	$using:federationMetadataFileContent

Erstellen der Verbundmetadatendatei

Für das folgende Verfahren müssen Sie einen Computer verwenden, der über eine Netzwerkverbindung mit der vorhandenen AD FS-Bereitstellung verfügt, die zum Konto-STS wird. Die erforderlichen Zertifikate müssen ebenfalls installiert sein.

Öffnen Sie eine Windows PowerShell-Sitzung mit erhöhten Rechten, und führen Sie den folgenden Befehl mit den Parametern aus, die für Ihre Umgebung geeignet sind:

 $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

Kopieren Sie die Metadatendatei auf einen Computer, der mit dem privilegierten Endpunkt kommunizieren kann.

Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbietervertrauensstellung in Azure Stack Hub (mithilfe der Verbundmetadatendatei)

Verwenden Sie für diese Prozedur einen Computer, der mit dem privilegierten Endpunkt in Azure Stack Hub kommunizieren kann und Zugriff auf die Metadatendatei hat, die Sie zuvor erstellt haben.

Öffnen Sie eine Windows PowerShell-Sitzung mit erhöhten Rechten, und stellen Sie eine Verbindung mit dem privilegierten Endpunkt her.

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

Da Sie nun mit dem privilegierten Endpunkt verbunden sind, führen Sie den folgenden Befehl mit den Parametern aus, die für Ihre Umgebung geeignet sind:
```
Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataFileContent $using:federationMetadataFileContent
```
Führen Sie den folgenden Befehl aus, um den Besitzer des Anbieterstandardabonnements zu aktualisieren. Verwenden Sie dabei für Ihre Umgebung geeignete Parameter.
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "administrator@contoso.com"
```
Hinweis

Wenn Sie das Zertifikat auf dem vorhandenen AD FS (Konto-STS) rotieren, müssen Sie die AD FS-Integration erneut einrichten. Sie müssen die Integration auch dann einrichten, wenn der Metadatenendpunkt erreichbar ist oder durch Bereitstellen der Metadatendatei konfiguriert wurde.

Konfigurieren der vertrauenden Seite für eine vorhandene AD FS-Bereitstellung (Konto-STS)

Microsoft stellt ein Skript zur Verfügung, das die Vertrauensstellung der vertrauenden Seite (einschließlich der Anspruchstransformationsregeln) konfiguriert. Die Verwendung des Skripts ist optional, da Sie die Befehle auch manuell ausführen können.

Sie können das Hilfsskript unter Azure Stack Hub-Tools auf GitHub herunterladen.

Wenn Sie die Befehle manuell ausführen möchten, gehen Sie folgendermaßen vor:

Kopieren Sie den folgenden Inhalt in eine TXT-Datei (z. B. unter „C:\ClaimIssuanceRules.txt“ gespeichert) in der AD FS-Instanz oder dem Farmmitglied des Rechenzentrums:

@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);

Stellen Sie sicher, dass die Windows Forms-basierte Authentifizierung für Extranet und Intranet aktiviert ist. Sie können überprüfen, ob sie bereits aktiviert ist, indem Sie das folgende Cmdlet ausführen:
```
Get-AdfsAuthenticationProvider | where-object { $_.name -eq "FormsAuthentication" } | select Name, AllowedForPrimaryExtranet, AllowedForPrimaryIntranet
```
Hinweis

Die von der integrierten Windows-Authentifizierung (WIA) unterstützten Benutzer-Agent-Zeichenfolgen können für Ihre AD FS-Bereitstellung veraltet sein und müssen möglicherweise aktualisiert werden, um die neuesten Clients zu unterstützen. Weitere Informationen zum Aktualisieren der von WIA unterstützten Zeichenfolgen für den Benutzer-Agent finden Sie im Artikel Konfigurieren der formularbasierten Authentifizierung für Geräte im Intranet, die WIA nicht unterstützen.

Die Schritte zum Aktivieren der formularbasierten Authentifizierungsrichtlinie finden Sie unter Konfigurieren von Authentifizierungsrichtlinien.
Zum Hinzufügen der Vertrauensstellung der vertrauenden Seite führen Sie den folgenden Windows PowerShell-Befehl für Ihre AD FS-Instanz oder Ihr Farmmitglied aus. Aktualisieren Sie unbedingt den AD FS-Endpunkt, und verweisen Sie auf die Datei, die Sie in Schritt 1 erstellt haben.

Wichtig

Für Kunden, die Azure Stack Hub Version 2002 und höher ausführen, wird TLS 1.2 auf dem Azure Stack Hub ADFS-Endpunkt erzwungen. Daher muss TLS 1.2 auch auf den ADFS-Servern des Kunden aktiviert sein. Andernfalls tritt der folgende Fehler auf, wenn Add-ADFSRelyingPartyTrust auf dem ADFS-Host bzw. in der -Farm im Besitzt des Kunden ausgeführt wird:

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
```
Wichtig

Sie müssen das AD FS MMC-Snap-In verwenden, um die Ausstellungsautorisierungsregeln zu konfigurieren, wenn Windows Server 2012 oder 2012 R2 AD FS verwendet wird.
Wenn Sie als Browser Internet Explorer oder Microsoft Edge verwenden, um auf Azure Stack Hub zuzugreifen, müssen Sie Tokenbindungen ignorieren. Andernfalls tritt beim Anmeldeversuch ein Fehler auf. Führen Sie für Ihre AD FS-Instanz oder Ihr Farmmitglied den folgenden Befehl aus:

Hinweis

Dies gilt nicht, wenn Sie Windows Server 2012 oder 2012 R2 AD FS verwenden. In diesem Fall können Sie diesen Befehl problemlos überspringen und die Integration fortsetzen.
```
Set-AdfsProperties -IgnoreTokenBinding $true
```

SPN-Erstellung

Es gibt viele Szenarien, die die Verwendung eines Dienstprinzipalnamens (SPN) für die Authentifizierung erfordern. Hier einige Beispiele:

Verwendung der Azure CLI mit der AD FS-Bereitstellung von Azure Stack Hub
System Center Management Pack für Azure Stack Hub bei der Bereitstellung mit AD FS
Ressourcenanbieter in Azure Stack Hub bei der Bereitstellung mit AD FS
Verschiedene Apps
Sie benötigen eine nicht interaktive Anmeldung.

Wichtig

AD FS unterstützt nur interaktive Anmeldesitzungen. Wenn Sie eine nicht-interaktive Anmeldung für ein automatisiertes Szenario benötigen, müssen Sie einen SPN verwenden.

Weitere Informationen zum Erstellen eines SPN finden Sie unter Erstellen eines Dienstprinzipals für AD FS.

Problembehandlung

Konfigurationsrollback

Wenn ein Fehler auftritt, der die Umgebung in einem Zustand hinterlässt, in dem keine Authentifizierung mehr erfolgen kann, ist eine Rollbackoption verfügbar.

Öffnen Sie eine Windows PowerShell-Sitzung mit erhöhten Rechten, und führen Sie die folgenden Befehle aus:

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

Führen Sie dann das folgende Cmdlet aus:
```
Reset-DatacenterIntegrationConfiguration
```
Nachdem die Rollbackaktion ausgeführt wurde, wird für alle Änderungen an der Konfiguration ein Rollback ausgeführt. Authentifizierung ist nur mit dem integrierten CloudAdmin-Benutzer möglich.

Wichtig

Sie müssen den ursprünglichen Besitzer des Anbieterstandardabonnements konfigurieren.
```
Set-ServiceAdminOwner -ServiceAdminOwnerUpn "azurestackadmin@[Internal Domain]"
```

Erfassen zusätzlicher Protokolle

Wenn für eines der Cmdlets ein Fehler auftritt, können Sie zusätzliche Protokolle erfassen, indem Sie das Cmdlet Get-Azurestacklogs verwenden.

Öffnen Sie eine Windows PowerShell-Sitzung mit erhöhten Rechten, und führen Sie die folgenden Befehle aus:

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

Führen Sie dann das folgende Cmdlet aus:

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

Nächste Schritte

Integrieren einer externen Überwachungslösung in Azure Stack

Integrieren der AD FS-Identität in Ihr Azure Stack Hub-Rechenzentrum

Active Directory-Verbunddienste (AD FS) und Graph

Einrichten der Graph-Integration

Konfigurieren von Active Directory-Standorten

Erstellen eines Benutzerkontos im vorhandenen Active Directory (optional)

Auslösen der Automatisierung zum Konfigurieren von Graph

Graph-Protokolle und -Ports

Einrichten der AD FS-Integration durch Herunterladen von Verbundmetadaten

Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbietervertrauensstellung in Azure Stack Hub (durch Herunterladen von Verbundmetadaten)

Einrichten der AD FS-Integration durch Bereitstellen einer Verbundmetadatendatei

Erstellen der Verbundmetadatendatei

Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbietervertrauensstellung in Azure Stack Hub (mithilfe der Verbundmetadatendatei)

Konfigurieren der vertrauenden Seite für eine vorhandene AD FS-Bereitstellung (Konto-STS)

SPN-Erstellung

Problembehandlung

Konfigurationsrollback

Erfassen zusätzlicher Protokolle

Nächste Schritte

Feedback

Feedback

Zusätzliche Ressourcen