Azure Service Principal einrichten: Leitfaden für unbeaufsichtigten Zugriff

Wenn Sie Aufgaben in Azure mit Skripten und Tools automatisieren möchten, würden Sie Servicekonten oder Azure-Dienstprinzipale in Betracht ziehen? Es ist nicht ungewöhnlich, einfach ein neues Servicekonto zu erstellen, es mit allen gewünschten Administratorrollen auszustatten und es von der Mehr-Faktor-Authentifizierung auszuschließen.

I know what you’re thinking – “that is a horrible idea”. Of course, it is! And for sure, your IT Sec will give you a lot of grief if you did all that.

Aber was ist die Alternative? Wie können Sie ein privilegiertes Anmeldeinformationen mit begrenztem Umfang verwenden, das nicht von der Mehr-Faktor-Authentifizierung ausgeschlossen werden muss? Hier haben Sie Glück, denn das wird Ihnen dieser Artikel zeigen.

In diesem Artikel erfahren Sie, was ein Azure-Dienstprinzipal ist. Sie lernen, wie Sie Dienstprinzipale mit verschiedenen Arten von Anmeldeinformationen wie Passwörtern, geheimen Schlüsseln und Zertifikaten erstellen können.

Es gibt viele Tools zur Erstellung von Azure-Dienstprinzipalen. Dazu gehören die Verwendung des Azure-Portals, des Azure Active Directory Admin Center, von Azure AD PowerShell, Azure CLI und Azure PowerShell. Das Tool, auf das sich dieser Artikel konzentrieren wird, ist die Azure PowerShell.

Immer noch interessiert? Lesen Sie weiter und lassen Sie uns beginnen!

Anforderungen

Da es sich um einen Learning-by-Doing-Artikel handelt, hier sind einige Voraussetzungen, damit Sie Schritt halten können.

  • Zugang zu einem Azure-Abonnement. Es wäre am besten, wenn Sie an einem Test-Mandanten arbeiten. Wenn Sie keinen haben, können Sie sich für eine kostenlose Testversion registrieren.
  • Zugang zu einem Computer, der unter Windows 10 mit PowerShell 5.1 läuft.
  • Das Azure PowerShell-Modul muss installiert sein.

Azure Service Principal vs. Service Account

Automatisierungstools und Skripte benötigen oft Administrator- oder privilegierten Zugriff. Zum Beispiel das Einrichten von Speicherkonten oder das Starten und Stoppen von virtuellen Maschinen nach einem Zeitplan. Die meisten Administratoren verwenden wahrscheinlich ein vollständig privilegiertes Benutzerkonto (Service Account), um die Anforderungen an die Anmeldeinformationen für Skripte festzulegen.

A service account is essentially a privileged user account used to authenticate using a username and password. And, if used with automation, a service account is most likely excluded from any conditional access policies or multi-factor authentication.

Andererseits kann ein Azure Service Principal so eingerichtet werden, dass er zur Authentifizierung einen Benutzernamen und ein Zertifikat oder ein Passwort verwendet. Denken Sie an eine Benutzeridentität ohne Benutzer, sondern eher an eine Identität für eine Anwendung.

Ein Azure Service Principal kann nur Zugriff auf so wenig wie eine bestimmte Azure-Ressource haben. Zum Beispiel können Sie einen Azure Service Principal erstellen, der nur über rollenbasierten Zugriff auf ein gesamtes Abonnement oder nur eine einzelne Azure-Virtual Machine verfügt.

Primäre Überlegungen für die Erstellung von Azure-Dienstprinzipalen

Bevor Sie einen Azure-Dienstprinzipal erstellen, sollten Sie die grundlegenden Details kennen, für die Sie planen müssen. Diese Details mögen einfach erscheinen, aber sie machen die Erstellung eines Azure-Dienstprinzipals so effizient und einfach wie möglich.

Der Anzeigename. Alles beginnt mit einem Namen, und ein Azure-Dienstprinzipal muss einen Namen haben. Es gibt keine Regel hierfür, aber Ihre Organisation kann eine vorgeschriebene Namenskonvention haben.

  • Die Art des zu verwendenden Anmeldeinformationen. Sie können sich dafür entscheiden, einen Azure-Dienstprinzipal zu erstellen, der ein Passwort oder ein Zertifikat zur Authentifizierung verwendet. Das bedeutet nicht, dass Sie nur eine Option wählen können, Sie können beides verwenden.

Für Dienstprinzipale werden der Benutzername und das Passwort eher als Anwendungs-ID und geheimer Schlüssel bezeichnet.

  • Die Gültigkeitsdauer der Anmeldeinformation(en). Wenn Sie eine Passwort- oder Zertifikatanmeldeinformation zuweisen, müssen Sie einen Start- und Enddatum für ihre Gültigkeit festlegen. Wie lange Anmeldeinformationen gültig sind, hängt in der Regel davon ab, wie oft Sie Zertifikate und Passwörter rotieren/erneuern möchten.
  • Der Zugriffsbereich. Erstellen Sie einen Azure-Dienstprinzipal, der Zugriff auf ein Abonnement, eine Ressourcengruppe oder ausgewählte Ressourcen haben wird?
  • Die Rolle. Es gibt mehrere verfügbare Rollen, wie beispielsweise Mitwirkender, Leser und Eigentümer, um nur einige zu nennen. Sie müssen definieren, welche Rolle für den Dienstprinzipal „genau richtig“ ist.

Erstellen eines Azure-Dienstprincipals mit automatisch zugewiesenem geheimem Schlüssel

Der Kernpunkt bei der Erstellung eines neuen Dienstprincipals in Azure ist das Cmdlet New-AzAdServicePrincipal. In diesem Beispiel wird ein neuer Dienstprincipal mit den folgenden Werten erstellt:

Anzeigename: AzVM_Reader

Bereich: AzVM1 (Virtuelle Maschine)

Rolle: Reader

Passwort: <automatisch zugewiesen>

Gültigkeitsdauer der Anmeldeinformationen: 1 Jahr

Ermitteln der ID des Zielbereichs (Virtuelle Maschine)

Wie Sie sehen können, bezieht sich der Bereich dieses neuen Dienstprincipals nur auf die virtuelle Maschine mit dem Namen AzVM1. Der Parameter -Scope akzeptiert jedoch nicht nur den Namen, sondern die gesamte ID der Ressource. Um dies zu erreichen, verwenden Sie den folgenden Code.

Get-AzVM | Format-Table Name, ID

Wenn Sie den obigen Code in PowerShell ausführen, sollten Sie eine Liste mit VM-Namen und -IDs sehen, ähnlich dem untenstehenden Screenshot.

Get the list of VM names and IDs

Erstellen des Azure-Dienstprincipals mit geheimem Schlüssel

Jetzt, da Sie die ID des Zielbereichs haben, die ID der virtuellen Maschine AzVM1, können Sie den folgenden Befehl verwenden, um den neuen Dienstprincipal mit der Reader-Rolle zu erstellen. Die Eigenschaften des neuen Dienstprincipals werden in der Variablen $sp gespeichert.

$sp = New-AzAdServicePrincipal `
	-DisplayName AzVM_Reader `
	-Scope '/subscriptions/5e252811-b376-4136-b8ae-d3b8abe2c9c3/resourceGroups/ATA/providers/Microsoft.Compute/virtualMachines/AzVM1'
	-Role 'Reader'

Als Ergebnis des obigen Befehls wurde der Dienstprinzipal mit den folgenden Werten erstellt.

The properties of the new service principal

Entschlüsseln des geheimen Schlüssels

Jetzt haben Sie die Anwendungs-ID und das Geheimnis, was der Benutzername und das Passwort des Dienstprinzipals ist. Allerdings wird der Wert des Geheimnisses als System.Security.SecureString angezeigt. Sie möchten wissen, was das Geheimnis ist. Verwenden Sie dazu den folgenden Befehl, um das Geheimnis in Klartext umzuwandeln.

# Konvertieren Sie das verschlüsselte Passwort in Klartext
[System.Runtime.InteropServices.Marshal]::PtrToStringAuto(
    [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR(
        $sp.Secret
    )
)

Der oben genannte Befehl konvertiert den gesicherten String-Wert von $sp.Secret in Klartext. Siehe das Bild unten als Referenz.

Secure string password value converted to plain text

Überprüfung der Azure Service Principal Rollenzuweisung

Wie wissen Sie, dass dies funktioniert hat? Sie können die Zugriffssteuerungsliste des Ressourcen über das Azure-Portal überprüfen. Zum Beispiel können Sie im folgenden Bild sehen, dass der Dienstprinzipal AzVM_Reader nun Lesezugriff (Reader) auf die virtuelle Maschine AzVM1 hat.

Azure resource access control

Sie können auch den Befehl Get-AzRoleAssignment -ObjectID $sp.id verwenden, um die Rollenzuweisungen des Azure-Dienstprinzipals abzurufen. Siehe das folgende Bild als Beispiel.

Get the role assignment(s) of the service principal

Erstellen eines Azure Service Principal mit Passwort

Wenn Sie mehr Kontrolle darüber haben möchten, welches Passwort oder welcher Geheimschlüssel Ihrem Azure-Dienstprinzipal zugewiesen wird, verwenden Sie den Parameter -PasswordCredential während der Erstellung des Dienstprinzipals. Dies ist besonders nützlich, wenn das Passwort bestimmte Komplexitätsanforderungen erfüllen muss.

In diesem Beispiel wird der neue Azure-Dienstprinzipal mit folgenden Werten erstellt:

Anzeigename: ATA_RG_Contributor

Geltungsbereich: ATA (ResourceGroup)

Rolle: Mitwirkender

Passwort: 20 Zeichen lang mit 6 nicht alphanumerischen Zeichen

Gültigkeit der Anmeldeinformationen: 5 Jahre

ID des Zielbereichs (Ressourcengruppe) erhalten

Der Umfang dieses neuen Dienstprinzipals umfasst die gesamte Ressourcengruppe mit dem Namen ATA. Das erste, was Sie benötigen, ist die ID der ATA Ressourcengruppe. Verwenden Sie dazu den folgenden Code, stellen Sie jedoch sicher, dass Sie den Wert des Parameters -Name auf den Namen Ihrer Ressourcengruppe ändern.

# Holen Sie den ResourceId-Wert der Ressourcengruppe
$Scope = (Get-AzResourceGroup -Name ATA).ResourceId
$Scope

Dann sollten Sie die ResourceID der Ressourcengruppe sehen, die jetzt in der Variablen $Scope gespeichert ist.

Getting the Resource Group ID

Generierung des Passwort-Strings

Der nächste Schritt besteht darin, das Passwort zu generieren, das der Komplexität 20 Zeichen lang mit 6 nicht alphanumerischen Zeichen entspricht. Dazu können Sie die .NET-Statikmethode GeneratePassword() verwenden.

# Generieren Sie ein zufälliges Passwort mit der statischen Methode GeneratePassword()
Add-Type -AssemblyName 'System.Web'
$password = [System.Web.Security.Membership]::GeneratePassword(20, 6)
$password

In dem obigen Code GeneratePassword(20, 6) steht der erste Wert für die Länge des Passworts und der zweite Wert für die Anzahl der nicht alphanumerischen Zeichen, die enthalten sein sollen. Das Ergebnis wird im folgenden Screenshot angezeigt.

Randomly generated password using the .NET GeneratePassword() static method

Erstellen des Passwortanmeldeinformationen-Objekts

Jetzt, da Sie den Passwort-String haben, ist der nächste Schritt das Erstellen des Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential-Objekts. Dieses Objekt enthält den Passwort-String, der in der Variablen $password gespeichert ist, und die Gültigkeitsdauer von 5 Jahren. Kopieren Sie den folgenden Code und führen Sie ihn in Ihrer Azure PowerShell-Sitzung aus.

# Erstellen des Passwort-Credential-Objekts
[Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential]`
    $PasswordCredential = @{
    StartDate = Get-Date;
    EndDate   = (Get-Date).AddYears(5);
    Password  = $password
}
$PasswordCredential

Das Ausführen des obigen Codes in PowerShell speichert das Credential-Objekt in der Variable $PasswordCredential. Das erwartete Ergebnis wäre ähnlich wie das unten gezeigte.

Creating the new password credential object in Azure PowerShell

Erstellen des Service Principal mit Passwort

Sie haben nun die erforderlichen Parameterwerte, um den Azure Service Principal zu erstellen. Der folgende Code erstellt den Service Principal mit dem Anzeigenamen ATA_RG_Contributor und verwendet das in der Variable $PasswordCredential gespeicherte Passwort.

# Erstellen des Service Principal mit einem Passwort-Credential
$sp = New-AzAdServicePrincipal `
    -DisplayName 'ATA_RG_Contributor' `
    -PasswordCredential $PasswordCredential
$sp

Nach dem Ausführen des Codes sollte der neue Service Principal erstellt sein und die Eigenschaften werden in der Variable $sp gespeichert. Beachten Sie das untenstehende Beispielergebnis.

The new Azure service principal is created

Zuweisen der Rolle und des Geltungsbereichs

Der Azure Service Principal wurde im vorherigen Abschnitt erstellt, jedoch ohne Rolle und Geltungsbereich. Das liegt daran, dass die Parameter -Role und -Scope nicht zusammen mit dem Parameter -PasswordCredential verwendet werden können. Das bedeutet, dass ein zusätzlicher Schritt erforderlich ist, um die Rolle und den Geltungsbereich dem Service Principal zuzuweisen.

Der folgende Code verwendet das New-AzRoleAssignment-Cmdlet, um den Bereich und die Rolle des Azure-Dienstprinzipals zuzuweisen.

# Weisen Sie die Rolle dem Zielressourcen zu
New-AzRoleAssignment -$azSubscription = Get-AzSubscription -SubscriptionName VSE3
$Scope = "/subscriptions/$($azSubscription.ID)"
$TenantID = $azSubscription.TenantID$sp.ApplicationId `
    -Scope $Scope `
    -RoleDefinitionName 'Contributor'

Der folgende Screenshot zeigt das erwartete Ergebnis, nachdem die Rolle und der Bereich dem Azure-Dienstprinzipal zugewiesen wurden.

Assigning role and scope using Azure Powershell

Stellen Sie immer sicher, dass Sie das Kennwort des Dienstprinzipals speichern, da es keine Möglichkeit gibt, es wiederherzustellen, falls Sie es nicht gespeichert haben oder vergessen haben.

Verbindung zu Azure mit einem Dienstprinzipal Kennwort

Jetzt setzen wir den Dienstprinzipal ein. Anstatt sich bei Azure PowerShell mit einem Benutzerkonto anzumelden, verwendet der folgende Code stattdessen die Anmeldeinformationen des Dienstprinzipals.

# Holen Sie sich den Dienstprinzipal mit dem Anzeigenamen ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# Holen Sie sich die Mandanten-ID
$TenantID = (Get-AzContext).Tenant.ID

# Holen Sie sich den ersten Dienstprinzipalnamen
$user = $sp.ServicePrincipalNames[0]

# Konvertieren Sie das Passwort in eine sichere Zeichenfolge
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# Erstellen Sie das PSCredential-Objekt
$credential = [PSCredential]::New($user,$secPassword)

# Stellen Sie eine Verbindung zu Azure her
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID
# Holen Sie sich den Dienstprinzipal mit dem Anzeigenamen ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# Holen Sie sich die Mandanten-ID
$TenantID = (Get-AzContext).Tenant.ID

# Holen Sie sich den ersten Dienstprinzipalnamen
$user = $sp.ServicePrincipalNames[0]

# Konvertieren Sie das Passwort in eine sichere Zeichenfolge
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# Erstellen Sie das PSCredential-Objekt
$credential = [PSCredential]::New($user,$secPassword)

# Stellen Sie eine Verbindung zu Azure her
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID# Holen Sie sich den Dienstprinzipal mit dem Anzeigenamen ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# Holen Sie sich die Mandanten-ID
$TenantID = (Get-AzContext).Tenant.ID

# Holen Sie sich den ersten Dienstprinzipalnamen
$user = $sp.ServicePrincipalNames[0]

# Konvertieren Sie das Passwort in eine sichere Zeichenfolge
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# Erstellen Sie das PSCredential-Objekt
$credential = [PSCredential]::New($user,$secPassword)

# Stellen Sie eine Verbindung zu Azure her
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID

Nach Ausführung des obigen Codes sollten Sie bei Azure PowerShell mit dem Dienstprinzipal ATA_RG_Contributor und dem Passwort-Anmeldeinformationen angemeldet sein.

Connect to Azure using a Service Principal with Password Credential

Erstellen eines Azure-Dienstprinzipals mit Zertifikat

Ein Azure-Dienstprinzipal kann neben Passwort-Anmeldeinformationen auch über Anmeldeinformationen auf Basis eines Zertifikats verfügen. Das zugehörige Zertifikat kann von einer Zertifizierungsstelle ausgestellt oder selbstsigniert sein.

In diesem Beispiel wird der neue Azure-Dienstprinzipal mit folgenden Werten erstellt:

Anzeigename: VSE3_SUB_OWNER

Geltungsbereich: VSE3 (Abonnement)

Rolle: Owner

Zertifikatsgültigkeit: 2 Jahre

Abrufen der ID des Zielbereichs (Abonnement)

Der Geltungsbereich dieses neuen Dienstprinzipals umfasst das Azure-Abonnement mit dem Namen VSE3. Als Erstes müssen Sie die ID des VSE3-Abonnements abrufen. Verwenden Sie dazu den folgenden Code, und ändern Sie den Wert des Parameters -SubscriptionName auf den Namen Ihrer Ressourcengruppe.

# Abrufen der ID des Abonnement-Geltungsbereichs und der Mandanten-ID
$azSubscription = Get-AzSubscription -SubscriptionName VSE3
$Scope = "/subscriptions/$($azSubscription.ID)"
$TenantID = $azSubscription.TenantID

Geben Sie anschließend den Namen des neuen Azure-Dienstprinzipals und des selbstsignierten Zertifikats an, das erstellt werden soll.

# Der Name des neuen Azure-Dienstprinzipals und des selbstsignierten Zertifikats
$DisplayName = 'VSE3_SUB_OWNER'

Erstellen des selbstsignierten Zertifikats

Der unten stehende Code erstellt das selbstsignierte Passwort im persönlichen Zertifikatsspeicher mit dem Namen CN=VSE3_SUB_OWNER. Die Gültigkeit des Zertifikats wird auf zwei Jahre festgelegt. Die Eigenschaften des Zertifikats werden in der Variablen $cert gespeichert.

# Generiere ein selbstsigniertes Zertifikat
$cert = New-SelfSignedCertificate -CertStoreLocation "cert:\CurrentUser\My" `
    -Subject "CN=$($DisplayName)" `
    -KeySpec KeyExchange `
    -NotBefore ((Get-Date).AddDays(-1)) `
    -NotAfter ((Get-Date).AddYears(2))
$cert

Der Screenshot unten zeigt, dass das Zertifikat erstellt wurde.

The self-signed certificate is created in the personal certificate store

Wenn Sie das neue Zertifikat in einer vertrauteren Ansicht (GUI) anzeigen möchten, finden Sie es in der Zertifikatskonsole (certmgr.mmc). Beachten Sie das Bild unten, das das Zertifikat zeigt.

Viewing the self-signed certificate

Als nächstes wird der Base64-kodierte Wert des selbstsignierten Zertifikats abgerufen und in der Variable $keyValue gespeichert.

# Base64-Wert des selbstsignierten Zertifikats abrufen
$keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData())

Erstellen des Dienstprinzips mit Zertifikat

Jetzt, da das Zertifikat erstellt wurde, ist der nächste Schritt das Erstellen des neuen Azure-Dienstprinzips. Der folgende Code erstellt das Azure-Dienstprinzip, das das selbstsignierte Zertifikat als Anmeldeinformation verwendet. Die Gültigkeitsdauer der Anmeldeinformationen stimmt mit der Gültigkeitsdauer des Zertifikats überein.

$sp = New-AzADServicePrincipal -DisplayName $DisplayName `
    -CertValue $keyValue `
    -EndDate $cert.NotAfter `
    -StartDate $cert.NotBefore
$sp

Sie erhalten eine ähnliche Ausgabe, wie im Bild unten gezeigt.

The new Azure service principal with a certificate is created

Zuweisen der Rolle und des Geltungsbereichs

Das Azure-Dienstprinzip wurde erstellt, jedoch noch keine Rolle und kein Geltungsbereich zugewiesen. Dies bedeutet, dass ein zusätzlicher Schritt erforderlich ist, um die Rolle und den Geltungsbereich dem Dienstprinzip zuzuweisen.

Der folgende Code verwendet das New-AzRoleAssignment-Cmdlet, um die Besitzerrolle dem VSE3-Abonnement des Dienstprinzipals zuzuweisen.

# Rolle und Umfang zuweisen
New-AzRoleAssignment -ApplicationId $sp.ApplicationId `
    -Scope $Scope `
    -RoleDefinitionName 'Owner'

Wenn der Code ausgeführt wird, zeigt der folgende Screenshot die Bestätigung, dass die Rollenzuweisung abgeschlossen ist.

The service principal’s owner role is added to the subscription

Verbindung zu Azure mit einem Dienstprinzipalzertifikat

Nun haben Sie den Dienstprinzipal mit einer zertifikatsbasierten Anmeldeinformation erstellt. Das bedeutet, dass Sie sich ohne Verwendung eines Passworts mit Azure verbinden können. Stattdessen verwenden Sie das Zertifikat, das auf Ihrem Computer verfügbar ist, als Authentifizierungsmethode.

In diesem Beispiel lautet der Anzeigename des Dienstprinzipals VSE3_SUB_OWNER, und der Zertifikatsname lautet CN=VSE3_SUB_OWNER. Der folgende Code ruft den Fingerabdruck des Zertifikats aus dem persönlichen Zertifikatsspeicher ab und verwendet ihn als Anmeldeanmeldeinformation.

# Zertifikat mit dem Betreff CN=VSE3_SUB_OWNER abrufen
$cert = Get-ChildItem Cert:\CurrentUser\My\ | Where-Object { $_.Subject -eq 'CN=VSE3_SUB_OWNER' }

# Mit Azure verbinden
Connect-AzAccount -ServicePrincipal -CertificateThumbprint $cert.ThumbPrint -ApplicationID $sp.ApplicationID -Tenant $TenantID

Der folgende Screenshot zeigt, dass die Anmeldung bei Azure PowerShell erfolgreich war, indem nur die ApplicationID, Tenant und Zertifikat-Fingerabdruck verwendet wurden.

Connecting to Azure using a Service Principal and Certificate

Zusammenfassung

Azure Service Principals sind die Sicherheitsprinzipale, die bei der Erstellung von Anmeldeinformationen für Automatisierungsaufgaben und Tools, die auf Azure-Ressourcen zugreifen, berücksichtigt werden müssen. Der Umfang und die Rolle, die angewendet werden sollen, können ausgewählt werden, um „genau genug“ Zugriffsberechtigungen zu gewähren.

In diesem Artikel haben Sie gelernt, wie Sie Azure Service Principals mithilfe von PowerShell erstellen können. Azure Service Principals können über ein Passwort, einen geheimen Schlüssel oder Zertifikatsanmeldeinformationen verfügen. Jede dieser Arten von Anmeldeinformationen hat ihre Vorteile und anwendbaren Nutzungsszenarien.

Service Principals mit Passwort- oder geheimem Schlüssel- Anmeldeinformationen sind portabler, aber weniger sicher, da die Anmeldeinformationen im Klartext geteilt werden können. Auf der anderen Seite sind Zertifikatsanmeldeinformationen die sicherere Option, erfordern jedoch etwas mehr Aufwand zur Verwaltung.

Die in diesem Artikel erlernten Techniken decken nur die Grundlagen ab, um Ihnen den Einstieg in die Verwendung von Azure Service Principals in Ihrer Automatisierung zu ermöglichen. Es gibt viele weitere Möglichkeiten zur Konfiguration von Azure Service Principals, wie das Hinzufügen, Entfernen und Zurücksetzen von Anmeldeinformationen. Es liegt an Ihnen, sie bei Bedarf zu entdecken.

Vielen Dank für das Lesen!

Zusätzliche Lernressourcen

Hier sind einige Ressourcen, die Ihnen bei diesem Artikel behilflich sein könnten.

Source:
https://adamtheautomator.com/azure-service-principal/