Verwenden von Dienstprinzipalen und verwalteten Identitäten in Azure DevOps

Azure DevOps Services

Dienstprinzipale und verwaltete Identitäten bieten sichere, skalierbare Authentifizierung für Azure DevOps Automatisierungsworkflows. Diese Microsoft Entra Identitätstypen bieten eine verbesserte Sicherheit gegenüber herkömmlichen persönlichen Zugriffstoken. Sie verwenden die automatische Verwaltung von Anmeldeinformationen, kürzere Tokenlebensdauern und Zugriffssteuerungen auf Unternehmensniveau.

Vorteile von Dienstprinzipalen und verwalteten Identitäten

Erhöhte Sicherheit

• Kurzlebige Tokens: Microsoft Entra-Tokens verfallen stündlich, wodurch das Expositionsrisiko im Vergleich zu PATs reduziert wird, die bis zu einem Jahr gültig sein können.
• Automatische Rotation: Verwaltete Identitäten handhaben die Anmeldeinformationenrotation automatisch.
• Keine gespeicherten geheimen Schlüssel: Die Notwendigkeit, langlebige Anmeldeinformationen im Code oder in der Konfiguration zu speichern, wird eliminiert.

Operative Exzellenz

• Centralized Management: Steuern des Zugriffs über Microsoft Entra ID Richtlinien und Azure DevOps Berechtigungen.
• Überwachungsfunktionen: Nachverfolgen von Authentifizierungs- und Zugriffsmustern durch umfassende Protokollierung.
• Effiziente Skalierung: Unterstützen Sie Unternehmensautomatisierungsszenarien ohne einzelne Benutzerabhängigkeiten.

Moderne Authentifizierung

• Standardsbasiert: Verwendet OAuth 2.0- und OpenID Connect-Protokolle.
• Unterstützung für die mehrstufige Authentifizierung: Erbt Sicherheitsrichtlinien der Organisation.
• Bedingter Zugriff: Wendet erweiterte Sicherheitsrichtlinien basierend auf dem Kontext an.

Grundlegendes zu Dienstprinzipalen und verwalteten Identitäten

Dienstprinzipale

Service-Prinzipale sind Microsoft Entra Objekte, die Anwendungen innerhalb eines Mandanten darstellen. Sie definieren, was eine Anwendung tun kann, welche Ressourcen darauf zugreifen können und wer sie verwenden kann. Dienstprinzipale werden automatisch erstellt, wenn Sie eine Anwendung in Microsoft Entra ID registrieren und eine sichere Möglichkeit für Anwendungen zum Authentifizieren und Zugreifen auf Ressourcen bereitstellen.

Hauptmerkmale

• Werden über die Anwendungsregistrierung in Microsoft Entra ID erstellt.
• Unterstützen von Szenarien mit mehreren Mandanten.
• Erforderlich ist die explizite Verwaltung von Anmeldeinformationen (Zertifikate oder Clientgeheimnisse).
• Ideal für Anwendungen, die sich in verschiedenen Umgebungen authentifizieren müssen.

Verwaltete Identitäten

Managed identities sind ein spezieller Typ von Dienstprinzipalen, die Azure automatisch verwaltet. Sie vermeiden die Notwendigkeit, dass Entwickler Anmeldeinformationen verwalten müssen, indem sie eine automatisch verwaltete Identität in Microsoft Entra ID für Azure Ressourcen bereitstellen.

Typen von verwalteten Identitäten

Vom System zugewiesene verwaltete Identität:

• Automatisch erstellt und an eine bestimmte Azure Ressource gebunden.
• Von Azure verwalteter Lebenszyklus (gelöscht, wenn die Ressource gelöscht wird).
• 1:1-Beziehung mit der Azure Ressource.
• Am besten geeignet für Anwendungen, die in einer einzelnen Azure Ressource bereitgestellt werden.

Vom Benutzer zugewiesene verwaltete Identität:

• Als eigenständige Azure Ressource erstellt.
• Kann mehreren Azure Ressourcen zugewiesen werden.
• Lebenszyklus wird unabhängig von zugeordneten Ressourcen verwaltet.
• Am besten geeignet für Anwendungen, die auf mehreren Ressourcen ausgeführt werden oder eine gemeinsame Identität benötigen.

Wann jeder Typ verwendet werden soll:

• Serviceprinzipale: Cloudübergreifende Bereitstellungen, kontinuierliche Integration und kontinuierliche Übermittlung (CI/CD)-Pipelines, Anwendungen außerhalb Azure.
• System zugewiesene verwaltete Identitäten: Einzelne Azure-Ressourcenanwendungen (Azure Functions, Azure App Service).
• Vom Benutzer zugewiesene verwaltete Identitäten: Multiressourcenanwendungen, Szenarien für gemeinsame Identitäten.

Implementierungsleitfaden

Führen Sie die folgenden Schritte aus, um Dienstprinzipale oder verwaltete Identitäten für Azure DevOps Authentifizierung zu implementieren. Vollständige Codebeispiele finden Sie in unseren Beispielanwendungen.

Schritt 1: Erstellen Ihrer Identität

Wählen Sie den entsprechenden Identitätstyp basierend auf Ihrem Bereitstellungsszenario aus.

Option A: Erstellen eines Dienstprinzipals (Anwendungsregistrierung)

Dienstprinzipale funktionieren gut für CI/CD-Pipelines, cloudübergreifende Szenarien und Anwendungen, die flexible Bereitstellungsoptionen benötigen.

1. Registrieren Sie eine Anwendung im Microsoft Entra Admin Center.

2. Wechseln Sie zu App registrations>Neue Registrierung.

3. Konfigurieren Sie die Anwendung:

   • Name: Verwenden Sie einen beschreibenden Namen für Ihre Anwendung.
   • Kontotypen: Wählen Sie die entsprechende Mandantenunterstützung aus.
   • Umleitungs-URI: Für Dienst-zu-Dienst-Szenarien leer lassen.

4. Erstellen von Authentifizierungsanmeldeinformationen:

   • Empfohlen: Hochladen eines Zertifikats für erhöhte Sicherheit.
   • Alternative: Erstellen eines Client-Geheimnisses (erfordert regelmäßige Erneuerung).

Weitere Informationen finden Sie in den folgenden Artikeln:

• Application- und Dienstprinzipalobjekte in Microsoft Entra ID
• Erstellen eines Service Principal

Option B: Erstellen einer verwalteten Identität

Verwaltete Identitäten bieten die einfachste Authentifizierung für Azure gehostete Anwendungen.

Für vom System zugewiesene verwaltete Identität:

1. Wechseln Sie zu Ihrer Azure Ressource, z. B. App Service oder einer Azure Functions App.
2. Gehen Sie zu Identität>System zugewiesen.
3. Wechseln Sie den Status zu "Ein".
4. Wählen Sie "Speichern" aus, um die Konfiguration zu speichern.

Für vom Benutzer zugewiesene verwaltete Identität:

1. Erstellen Sie die verwaltete Identität im Azure-Portal.
2. Gehen Sie zu Ressource erstellen>Verwaltete Identität.
3. Konfigurieren Sie grundlegende Einstellungen, und erstellen Sie die Ressource.
4. Weisen Sie Ressourcen nach Bedarf zu.

Weitere Informationen finden Sie in den folgenden Artikeln:

• Übersicht über verwaltete Identitäten
• Verwalten von benutzerseitig zugewiesenen verwalteten Identitäten

Schritt 2: Hinzufügen der Identität zu Azure DevOps

Nachdem Sie Ihre Identität in Microsoft Entra ID erstellt haben, fügen Sie sie Ihrer Azure DevOps Organisation hinzu, um Zugriff auf Ressourcen zu gewähren.

Voraussetzungen

• Rolle des Project-Sammlungsadministrators.
• Rolle "Projektadministrator" oder "Teamadministrator", wenn die Einladungsrichtlinie es Teamadministratoren ermöglicht, Benutzer hinzuzufügen.

Identität hinzufügen

So fügen Sie die Identität über das Azure DevOps Portal hinzu:

1. Wechseln Sie zu Organisationseinstellungen>Benutzer.

2. Wählen Sie "Benutzer hinzufügen" aus.

3. Geben Sie den Anzeigenamen Ihres Dienstprinzipals oder Ihrer verwalteten Identität ein.

4. Wählen Sie die entsprechende Zugriffsebene und den Projektzugriff aus.

5. Senden Sie die Einladung.

   

Programmgesteuertes Hinzufügen der Identität:

Verwenden Sie die ServicePrincipalEntitlements-REST-API , um den Prozess zu automatisieren.

Weitere Überlegungen:

• Finden Sie die richtige ID: Verwenden Sie die Objekt-ID des Dienstprinzipals im Enterprise-Anwendungen Bereich des Microsoft Entra Admin Center, nicht die Objekt-ID der Anwendungsregistrierung.
• Mieterbeschränkungen: Sie können nur Identitäten aus demselben Mandanten hinzufügen, mit dem Ihre Azure DevOps-Organisation verbunden ist. Informationen zu mandantenübergreifenden Szenarien finden Sie in der FAQ-Lösung.

Schritt 3: Konfigurieren von Berechtigungen

Konfigurieren Sie präzise Berechtigungen für Ihren Dienstprinzipal oder die verwaltete Identität innerhalb Azure DevOps. Im Gegensatz zu anderen Azure-Diensten verwendet Azure DevOps anstelle Microsoft Entra Anwendungsberechtigungen ein eigenes Berechtigungsmodell.

Berechtigungsoptionen:

• Direkte Zuweisung: Zuweisen von Berechtigungen direkt zur Identität.
• Groupmitgliedschaft: Zu den Azure DevOps- oder Microsoft Entra-Sicherheitsgruppen hinzufügen.
• Access levels: Weisen Sie die entsprechende Lizenzstufe zu (Basic, Basic, Basic + Test Plans oder Visual Studio Subscriber).

Bewährte Methoden:

• Anwenden der geringsten Berechtigungen: Erteilen Sie nur die erforderlichen Mindestberechtigungen.
• Verwenden Sie Gruppen: Verwalten von Berechtigungen über Gruppen zur einfacheren Wartung.
• Regelmäßige Überprüfungen: Überwachungsberechtigungen in regelmäßigen Abständen.

Berechtigungsverwaltungsoptionen:

• Azure DevOps portal: Wählen Sie Organization settings>Permissions aus.
• REST-APIs: Verwenden Sie Service Principal Graph-APIs für die programmgesteuerte Verwaltung.

Schritt 4: Abrufen von Microsoft Entra ID Tokens

Rufen Sie Zugriffstoken ab, um Ihre Anwendungen mit Azure DevOps APIs und Diensten zu authentifizieren.

Für Dienstprinzipale

Client-Anmeldeinformationsfluss nutzen.

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://app.vssps.visualstudio.com/.default
&client_secret={client-secret}
&grant_type=client_credentials

Zertifikatauthentifizierung verwenden (empfohlen):

using Microsoft.Identity.Client;

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithCertificate(certificate)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

var result = await app
    .AcquireTokenForClient(new[] { "https://app.vssps.visualstudio.com/.default" })
    .ExecuteAsync();

string accessToken = result.AccessToken;

Für verwaltete Identitäten

Aus Azure Ressourcen:

using Azure.Identity;
using Azure.Core;

var credential = new ManagedIdentityCredential();
var tokenRequest = new TokenRequestContext(new[] { "https://app.vssps.visualstudio.com/.default" });
var token = await credential.GetTokenAsync(tokenRequest);

string accessToken = token.Token;

Verwenden Sie Azure Instanzmetadatendienst:

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-0801&resource=https://app.vssps.visualstudio.com/
Metadata: true

Azure CLI für Ad-hoc-Operationen

Verwenden Sie für einmalige Vorgänge oder Tests die Azure CLI:

# For service principal
az login --service-principal --username {client-id} --password {client-secret} --tenant {tenant-id}
az account get-access-token --scope https://app.vssps.visualstudio.com/.default

# For managed identity (from Azure resource)
az login --identity
az account get-access-token --scope https://app.vssps.visualstudio.com/.default

Weitere Informationen finden Sie unter Acquire Microsoft Entra Tokens.

Schritt 5: Verwenden von Token mit Azure DevOps

Verwenden Sie Ihre erworbenen Token, um REST-API-Aufrufe und andere Azure DevOps Vorgänge zu authentifizieren.

Führen Sie authentifizierte API-Aufrufe durch:

using System.Net.Http;
using System.Net.Http.Headers;

var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = 
    new AuthenticationHeaderValue("Bearer", accessToken);

var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.2");

Videobeispiele

Allgemeine Integrationsszenarien

• NuGet-Feeds: Verbinden Sie sich mit NuGet.exe oder dotnet CLI.
• Marketplace-Veröffentlichung: Veröffentlichen von Erweiterungen über die Befehlszeile.
• Azure Pipelines: Erstellen Sie Serviceverbindungen, gestützt auf verwaltete Identitäten.
• Git-Vorgänge: Klonen Sie Repositorys mit dem Git Credential Manager.

Vollständige Codebeispiele finden Sie in unseren Beispielanwendungen.

Überlegungen zur Verwaltung

Dienstprinzipale und verwaltete Identitäten weisen im Vergleich zu Benutzerkonten unterschiedliche Verwaltungsmerkmale auf.

Lizenzierung

• Jede Identität erfordert eine Lizenz in jeder Organisation, in die sie eintritt.
• Die Abrechnung mit mehreren Organisationen gilt nicht für Serviceprinzipale.
• Gruppenbasierte Lizenzierungsregeln gelten nicht automatisch. Sie müssen Lizenzen direkt zuweisen.

Identitätsverwaltung

• E-Mail-Adressen werden nicht verwendet, daher gibt es keine Einladungen per E-Mail.
• Anzeigenamen oder Avatare werden in Azure DevOps nicht geändert.
• Anzeigenamen werden von Microsoft Entra ID geerbt.

Gruppenmitgliedschaft

• Kann zu Microsoft Entra-Gruppen und Azure DevOps-Gruppen hinzugefügt werden.
• Weist eine technische Einschränkung auf, die die Anzeige in Microsoft Entra Gruppenmitgliedslisten verhindert (nur Benutzeroberflächeneinschränkung).
• Kann weiterhin Berechtigungen von Microsoft Entra Gruppen erben, zu denen sie gehören.

Materialisation

• Muss den Organisationen explizit hinzugefügt werden (keine automatische Erstellung wie bei Benutzern).
• Erforderlich, da sich Dienstprinzipale nicht interaktiv anmelden können.

Wichtige Unterschiede von Benutzerkonten

Dienstprinzipale und verwaltete Identitäten weisen im Vergleich zu normalen Benutzern spezifische Einschränkungen auf.

Fähigkeiten

• ✅ Generieren Microsoft Entra Token für den API-Zugriff.
• ✅ Zugriff auf Azure DevOps Ressourcen mit entsprechenden Berechtigungen.
• ✅ Treten Sie Sicherheitsgruppen und -teams bei.
• ❌ Erstellen Sie PATs oder Secure Shell-Schlüssel.
• ❌ Melden Sie sich interaktiv an oder greifen Sie über eine Web-UI zu.
• ❌ Organisationen erstellen oder besitzen.
• ❌ Unterstützung von Azure DevOps OAuth Flows.

Abrechnung

• Wird in jeder Organisation als separate Lizenz gezählt. (Es gibt keinen Rabatt für mehrere Organisationen.)
• Muss die Zugriffsebene direkt zuweisen. (Gruppenregeln werden nicht automatisch angewendet.)

Häufig gestellte Fragen

Q. Warum sollte ich anstelle eines PAT einen Dienstprinzipal oder eine verwaltete Identität verwenden?

A. Dienstprinzipale und verwaltete Identitäten bieten gegenüber PATs erhebliche Sicherheitsvorteile.

Sicherheitsvorteile:

• Kürzere Lebensdauer: Microsoft Entra-Tokens verfallen stündlich, verglichen mit PATs, die bis zu einem Jahr gültig sein können.
• Automatische Rotation: Verwaltete Identitäten rotieren Anmeldeinformationen automatisch.
• Keine freigegebenen Geheimnisse: Das Risiko, langelebige Token zu speichern oder versehentlich freizugeben, wird eliminiert.
• Centralized control: Verwaltet über Microsoft Entra ID mit Unternehmenssicherheitsrichtlinien.

Betriebliche Vorteile:

• Überwachungspfad: Protokolliert Authentifizierungs- und Zugriffsmuster vollständig.
• Bedingter Zugriff: Wendet Richtlinien basierend auf Standort-, Geräte- und Risikofaktoren an.
• Keine Dienstkonten: Beseitigt abhängigkeiten von einzelnen Benutzerkonten für die Automatisierung.

Migrationsbeispiele finden Sie unter Replace PATs mit Microsoft Entra Token.

Q. Was sind die Ratenbeschränkungen für Dienstprinzipale und verwaltete Identitäten?

A. Dienstprinzipale und verwaltete Identitäten weisen die gleichen Geschwindigkeitsbeschränkungen wie Benutzer auf.

Q. Kostet die Verwendung dieses Features mehr?

A. Dienstprinzipale und verwaltete Identitäten werden wie Benutzer basierend auf Zugriffsebene gepreist. Die wichtigsten Unterschiede sind:

• Kein Abrechnungsrabatt für mehrere Organisationen: Jede Identität zählt in jeder Organisation als separate Lizenz.
• Lizenzzuweisung: Zugriffsstufen müssen direkt zugewiesen werden. (Gruppenregeln werden nicht automatisch angewendet.)
• Gleiche Preisstufen: Basic, Basic + Testpläne und Visual Studio Abonnementspreise sind anwendbar.

Q. Kann ich meiner Organisation eine verwaltete Identität aus einem anderen Mandanten hinzufügen?

A. Sie können Identitäten nur direkt über den verbundenen Mandanten Ihrer Organisation hinzufügen. Verwenden Sie diese Problemumgehung für mandantenübergreifende Szenarien.

So richten Sie eine mandantenübergreifende verwaltete Identität ein:

1. Erstellen Sie eine vom Benutzer zugewiesene verwaltete Identität im Ressourcenmandanten.
2. Weisen Sie sie einer Azure-Ressource zu, z. B. einem virtuellen Computer oder einer Funktionen-App).
3. Erstellen Sie einen Schlüsseltresor, und generieren Sie ein Zertifikat (kein PEM-Format).
4. Gewähren sie verwalteten Identitätszugriff auf den Schlüsseltresor mit den Berechtigungen " Get " und "List secret".
5. Laden Sie das Zertifikat im CER-Format herunter (nur öffentlicher Schlüssel).
6. Registrieren Sie die Anwendung im Zielmandanten.
7. Laden Sie das Zertifikat in die Anwendungsregistrierung hoch.
8. Fügen Sie den Service Principal zur Azure DevOps-Organisation hinzu.
9. Konfigurieren Sie die Authentifizierung mithilfe des Zertifikats aus dem Schlüsseltresor.

// Example: Acquire token using managed identity certificate
public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
    var keyVaultUri = new Uri($"https://{keyVaultName}.vault.azure.net");
    var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
    var keyVaultSecret = await client.GetSecretAsync(secretName);
    return keyVaultSecret.Value.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(
    string applicationClientID, string appTenantId)
{
    byte[] privateKeyBytes = Convert.FromBase64String(await GetSecret(keyVaultName, secretName));
    var certificate = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

    var app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
        .WithCertificate(certificate)
        .WithAuthority(new Uri($"https://login.microsoftonline.com/{appTenantId}"))
        .Build();

    var result = await app.AcquireTokenForClient(
        new[] { "499b84ac-1321-427f-aa17-267ca6975798/.default" })
        .ExecuteAsync();

    return result;
}

Häufige Fehler und Lösungen

Das Git-Repository mit dem Namen oder der Kennung ist nicht vorhanden, oder Sie verfügen nicht über die erforderlichen Berechtigungen.

Lösung: Stellen Sie sicher, dass der Dienstprinzipal mindestens über eine Standardlizenz verfügt. Projektbeteiligtenlizenzen bieten keinen Repositoryzugriff.

Erstellung eines Dienstprinzipals mit Objekt-ID fehlgeschlagen

Lösung: Stellen Sie sicher, dass Sie die Objekt-ID des Dienstprinzipals aus dem Bereich Unternehmensanwendungen und nicht die Objekt-ID der Anwendungsregistrierung verwenden.

So suchen Sie die richtige ID:

1. Wechseln Sie zu Microsoft Entra Admin Center>Enterprise-Anwendungen.
2. Suchen Sie nach Ihrem Anwendungsnamen.
3. Verwenden Sie die Objekt-ID im Bereich "Enterprise-Anwendungen ".

Zugriff verweigert: Benötigt Berechtigungen zum Hinzufügen von Benutzern

Mögliche Ursachen und Lösungen:

• Unzureichende Rolle: Muss ein Projektsammlungsadministrator (PCA) oder ein Projekt- oder Teamadministrator mit aktivierten Einladungsberechtigungen sein.
• Richtlinieneinschränkung: Überprüfen Sie, ob die Richtlinie Team- und Projektadministratoren das Einladen neuer Benutzer erlauben aktiviert ist.
• Lizenzzuweisung: Project-Administratoren können während der Einladung keine Lizenzen zuweisen. Wenden Sie sich an die PCA für Lizenzänderungen.

Azure DevOps Graphs List API gibt eine leere Liste zurück.

Lösung: Verwenden Sie continuationToken, um alle Seiten zu durchlaufen. Dienstprinzipale können auf späteren Seiten aufgrund des API-Paginierungsverhaltens angezeigt werden.

TF401444: Anmeldeanforderung Fehler

Lösung: Stellen Sie sicher, dass der Dienstprinzipal der Organisation mit den erforderlichen Berechtigungen ordnungsgemäß hinzugefügt wird. Dieser Fehler gibt an, dass die Identität in der Organisation nicht erkannt wird.

Verwenden von KI für die Einrichtung von Dienstprinzipal- und verwalteten Identitäten

Wenn Sie den Azure DevOps MCP Server mit Ihrem KI-Agent im Agentmodus verbunden haben, können Sie Anweisungen in natürlicher Sprache verwenden, um Dienstprinzipal- und verwaltete Identitätsauthentifizierung einzurichten und zu behandeln.

Verwandte Inhalte

• Beispielanwendungen und Codebeispiele
• API-Referenz zur Dienstprinzipalberechtigungen
• Service Principal Graph API Referenz
• Microsoft Entra Authentifizierungsoptionen
• Authentication-Leitfaden für Azure DevOps