Integrieren der AD FS-Identität in Ihr Azure Stack Hub-Rechenzentrum
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.
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