Verwenden von Dienstprinzipalen und verwalteten Identitäten

  • Artikel

Azure DevOps Services

Fügen Sie Ihren Azure DevOps-Organisationen Microsoft Entra-Dienstprinzipale und verwaltete Identitäten hinzu, um Zugriff auf Ihre Organisationsressourcen zu gewähren. Bei vielen Teams kann dieses Feature eine praktikable und bevorzugte Alternative zu persönlichen Zugriffstoken (PATs) sein, wenn Sie Anwendungen authentifizieren, die Automatisierungsworkflows in Ihrem Unternehmen nutzen.

Informationen zu Dienstprinzipalen und verwalteten Identitäten

Dienstprinzipale sind Sicherheitsobjekte innerhalb einer Microsoft Entra-Anwendung, die definieren, was eine Anwendung in einem bestimmten Mandanten tun kann. Sie werden während des Anwendungsregistrierungsprozesses im Azure-Portal eingerichtet und für den Zugriff auf Azure-Ressourcen wie Azure DevOps konfiguriert. Durch Hinzufügen von Dienstprinzipalen zu Ihrem organization und Einrichten von Berechtigungen darauf können wir ermitteln, ob ein Dienstprinzipal für den Zugriff auf Ihre Organisationsressourcen autorisiert ist und welche.

Verwaltete Identitäten sind ein weiteres Microsoft Entra-Feature, das ähnlich wie die Dienstprinzipale einer Anwendung fungiert. Diese Objekte stellen Identitäten für Azure-Ressourcen bereit und ermöglichen eine einfache Möglichkeit für Dienste, die die Microsoft Entra-Authentifizierung unterstützen, um Anmeldeinformationen zu teilen. Sie sind eine ansprechende Option, da die Microsoft Entra-ID die Verwaltung und Drehung von Anmeldeinformationen übernimmt. Während das Setup für eine verwaltete Identität in der Azure-Portal möglicherweise anders aussieht, behandelt Azure DevOps beide Sicherheitsobjekte genauso wie eine neue Identität in einer Organisation mit definierten Berechtigungen. Im weiteren Verlauf dieses Artikels werden verwaltete Identitäten und Dienstprinzipale austauschbar als Dienstprinzipal bezeichnet, sofern dies nicht angegeben ist.

Führen Sie die folgenden Schritte aus, um diese Identitäten bei Azure DevOps zu authentifizieren, damit sie Aktionen für sich selbst ausführen können.

Konfigurieren von verwalteten Identitäten und Dienstprinzipalen

Ihre Implementierung kann variieren, aber auf hoher Ebene helfen Ihnen die folgenden Schritte bei der Verwendung von Dienstprinzipalen in Ihrem Workflow. Sehen Sie sich eine unserer Beispiel-Apps an, die Sie zusammen mit einem eigenen Beispiel befolgen können.

1. Erstellen einer neuen verwalteten Identität oder eines Anwendungsdienstprinzipals

Erstellen Sie einen Anwendungsdienstprinzipal oder eine verwaltete Identität im Azure-Portal.

Erstellen eines Anwendungsdienstprinzipals

Wenn Sie eine neue Anwendungsregistrierung erstellen, wird ein Anwendungsobjekt in der Microsoft Entra-ID erstellt. Der Anwendungsdienstprinzipal ist eine Darstellung dieses Anwendungsobjekts für einen bestimmten Mandanten. Wenn Sie eine Anwendung als mehrinstanzenfähige Anwendung registrieren, gibt es ein eindeutiges Dienstprinzipalobjekt, das das Anwendungsobjekt für jeden Mandanten darstellt, dem die Anwendung hinzugefügt wird.

Weitere Informationen:

Erstellen einer verwalteten Identität

Das Erstellen von verwalteten Identitäten im Azure-Portal unterscheidet sich erheblich von der Einrichtung von Anwendungen mit Dienstprinzipalen. Bevor Sie mit dem Erstellungsprozess beginnen, müssen Sie zunächst überlegen, welche Art von verwalteter Identität Sie erstellen möchten:

  • Systemseitig zugewiesene verwaltete Identität: Bei einigen Azure-Diensten können Sie eine verwaltete Identität direkt in einem Dienst instance aktivieren. Wenn Sie eine systemseitig zugewiesene verwaltete Identität aktivieren, wird in Microsoft Entra ID eine Identität erstellt. Die Identität ist an den Lebenszyklus dieser Dienstinstanz gebunden. Azure löscht automatisch die Identität, wenn die Ressource gelöscht wird. Entwurfsbedingt kann nur diese Azure-Ressource diese Identität zum Anfordern von Token von Microsoft Entra ID verwenden.
  • Vom Benutzer zugewiesene verwaltete Identität Sie können auch eine verwaltete Identität als eigenständige Azure-Ressource erstellen, indem Sie eine vom Benutzer zugewiesene verwaltete Identität erstellen und sie einer oder mehreren Instanzen eines Azure-Diensts zuweisen. Bei benutzerseitig zugewiesenen verwalteten Identitäten wird die Identität getrennt von den Ressourcen verwaltet, für die sie verwendet wird.

Weitere Informationen finden Sie in den folgenden Artikeln und im Video:

2. Hinzufügen und Verwalten von Dienstprinzipalen in einer Azure DevOps-organization

Nachdem Sie die Dienstprinzipale im Microsoft Entra Admin Center konfiguriert haben, müssen Sie in Azure DevOps die gleichen Schritte ausführen, indem Sie die Dienstprinzipale zu Ihrer Organisation hinzufügen. Sie können sie über die Seite Benutzer oder mit den ServicePrincipalEntitlements-APIs hinzufügen. Da sie sich nicht interaktiv anmelden können, muss ein Benutzerkonto, das Benutzer zu einem organization, Projekt oder Team hinzufügen kann, diese hinzufügen. Solche Benutzer umfassen Projektsammlungsadministratoren (Project Collection Administrators , PCA) oder Projektadministratoren und Teamadministratoren , wenn die Richtlinie "Team- und Projektadministratoren erlauben, neue Benutzer einzuladen" aktiviert ist.

Tipp

Um dem organization einen Dienstprinzipal hinzuzufügen, geben Sie den Anzeigenamen der Anwendung oder verwalteten Identität ein. Wenn Sie einen Dienstprinzipal programmgesteuert über die ServicePrincipalEntitlements API hinzufügen möchten, müssen Sie die Objekt-ID des Dienstprinzipals und nicht die Objekt-ID der Anwendung übergeben.

Wenn Sie ein PCA sind, können Sie auch einem Dienstprinzipal Zugriff auf bestimmte Projekte gewähren und eine Lizenz zuweisen. Wenn Sie kein PCA sind, müssen Sie sich an das PCA wenden, um alle Projektmitgliedschaften oder Lizenzzugriffsebenen zu aktualisieren.

Screenshot of service principals and managed identities in the Users Hub.

Hinweis

Sie können nur eine verwaltete Identität oder einen Dienstprinzipal für den Mandanten hinzufügen, mit dem Ihre Organisation verbunden ist. Informationen zum Zugriff auf eine verwaltete Identität in einem anderen Mandanten finden Sie in der Problemumgehung in den häufig gestellten Fragen.

Nachdem Ihre Dienstprinzipale dem organization hinzugefügt wurden, können Sie sie ähnlich wie Standardbenutzerkonten behandeln. Sie können Berechtigungen direkt für einen Dienstprinzipal zuweisen, sie Sicherheitsgruppen und Teams hinzufügen, sie einer beliebigen Zugriffsebene zuweisen und sie aus dem organization entfernen. Sie können auch verwenden, Service Principal Graph APIs um CRUD-Vorgänge für Dienstprinzipale auszuführen.

Die Verwaltung von Dienstprinzipalen unterscheidet sich von Benutzerkonten in den folgenden wichtigen Weisen:

  • Dienstprinzipale verfügen nicht über E-Mails und können daher nicht per E-Mail zu einem organization eingeladen werden.
  • Gruppenregeln für die Lizenzierung gelten derzeit nicht für Dienstprinzipale. Wenn Sie einem Dienstprinzipal eine Zugriffsebene zuweisen möchten, empfiehlt es sich, dies direkt zu tun.
  • Während Dienstprinzipale zu Microsoft Entra-Gruppen (im Azure-Portal) hinzugefügt werden können, haben wir eine aktuelle technische Einschränkung, die uns daran hindert, sie in einer Liste der Microsoft Entra-Gruppenmitglieder anzuzeigen. Diese Einschränkung gilt nicht für Azure DevOps-Gruppen. Das heißt, ein Dienstprinzipal erbt weiterhin alle Gruppenberechtigungen, die auf einer Microsoft Entra-Gruppe festgelegt sind, zu der sie gehören.
  • Nicht alle Benutzer in einer Microsoft Entra-Gruppe sind sofort Teil einer Azure DevOps-Organisation, nur weil ein Administrator eine Gruppe erstellt und eine Microsoft Entra-Gruppe hinzufügt. Wir haben einen Prozess namens "Materialisierung", der geschieht, sobald sich ein Benutzer aus einer Microsoft Entra-Gruppe zum ersten Mal bei der Organisation anmeldet. Ein Benutzer, der sich bei einem organization anmeldet, ermöglicht es uns, zu bestimmen, welchen Benutzern eine Lizenz gewährt werden soll. Da die Anmeldung für Dienstprinzipale nicht möglich ist, muss ein Administrator sie explizit einer organization hinzufügen, wie zuvor beschrieben.
  • Sie können den Anzeigenamen oder Avatar eines Dienstprinzipals in Azure DevOps nicht ändern.
  • Ein Dienstprinzipal zählt als Lizenz für jede Organisation, zu der er hinzugefügt wird, auch wenn die Abrechnung mit mehreren Organisationen ausgewählt ist.

3. Zugreifen auf Azure DevOps-Ressourcen mit einem Microsoft Entra-ID-Token

Abrufen eines Microsoft Entra-ID-Tokens

Das Abrufen eines Zugriffstokens für eine verwaltete Identität kann mithilfe der Microsoft Entra ID-Dokumentation erfolgen. Weitere Informationen finden Sie in den Beispielen für Dienstprinzipale und verwaltete Identitäten.

Das zurückgegebene Zugriffstoken ist ein JWT mit den definierten Rollen, die für den Zugriff auf organization Ressourcen mithilfe des Tokens als Bearer verwendet werden kann.

Verwenden des Microsoft Entra-ID-Tokens zur Authentifizierung bei Azure DevOps-Ressourcen

Im folgenden Videobeispiel wechseln wir von der Authentifizierung mit einem PAT zur Verwendung eines Tokens aus einem Dienstprinzipal. Wir beginnen mit der Verwendung eines geheimen Clientschlüssels für die Authentifizierung und wechseln dann zu einem Clientzertifikat.

  • Während Dienstprinzipale zu Microsoft Entra-ID-Gruppen (im Azure-Portal) hinzugefügt werden können, haben wir eine aktuelle technische Einschränkung, die verhindert, dass wir sie in einer Liste der Microsoft Entra ID-Gruppenmitglieder anzeigen können. Diese Einschränkung gilt nicht für Azure DevOps-Gruppen. Das heißt, ein Dienstprinzipal erbt weiterhin alle Gruppenberechtigungen, die über einer Microsoft Entra-ID-Gruppe festgelegt sind, zu der sie gehören.
  • Nicht alle Benutzer in einer Microsoft Entra-ID-Gruppe sind sofort Teil einer Azure DevOps-Organisation, nur weil ein Administrator eine Gruppe erstellt und ihr eine Microsoft Entra-ID-Gruppe hinzufügt. Wir haben einen Prozess namens "Materialisierung", der geschieht, sobald sich ein Benutzer aus einer Microsoft Entra-ID-Gruppe zum ersten Mal bei der Organisation anmeldet. Ein Benutzer, der sich bei einem organization anmeldet, ermöglicht es uns, zu bestimmen, welchen Benutzern eine Lizenz gewährt werden soll. Da die Anmeldung für Dienstprinzipale nicht möglich ist, muss ein Administrator sie explizit einer organization hinzufügen, wie zuvor beschrieben.
  • Sie können den Anzeigenamen oder Avatar eines Dienstprinzipals in Azure DevOps nicht ändern.
  • Ein Dienstprinzipal zählt als Lizenz für jede Organisation, zu der er hinzugefügt wird, auch wenn die Abrechnung mit mehreren Organisationen ausgewählt ist.

Ein weiteres Beispiel zeigt, wie Sie eine Verbindung mit Azure DevOps mithilfe einer benutzerseitig zugewiesenen verwalteten Identität innerhalb einer Azure-Funktion herstellen.

Folgen Sie diesen Beispielen, indem Sie den App-Code in unserer Sammlung von Beispiel-Apps suchen.

Dienstprinzipale können verwendet werden, um Azure DevOps-REST-APIs aufzurufen und die meisten Aktionen auszuführen, aber es ist auf die folgenden Vorgänge beschränkt:

  • Dienstprinzipale können nicht Organisationsbesitzer oder Organisationen erstellen.
  • Dienstprinzipale können keine Token erstellen, z. B . persönliche Zugriffstoken (PATs) oder SSH-Schlüssel. Sie können ihre eigenen Microsoft Entra-ID-Token generieren, und diese Token können verwendet werden, um Azure DevOps REST-APIs aufzurufen.
  • Azure DevOps OAuth wird nicht für Dienstprinzipale unterstützt.

Hinweis

Sie können anwendungs-ID und nicht die Ressourcen-URIs verwenden, die Azure DevOps zum Generieren von Token zugeordnet sind.

Häufig gestellte Fragen

Allgemein

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

A: Viele unserer Kunden suchen nach einem Dienstprinzipal oder einer verwalteten Identität, um ein vorhandenes PAT (persönliches Zugriffstoken) zu ersetzen. Solche PATs gehören häufig zu einem Dienstkonto (shared team account), das sie zum Authentifizieren einer Anwendung mit Azure DevOps-Ressourcen verwendet. PATs müssen immer wieder mühsam rotiert werden (mindestens 180 Tage). Da PATs einfach Bearertoken sind, also Tokenzeichenfolgen, die den Benutzernamen und das Kennwort eines Benutzers darstellen, sind sie unglaublich riskant zu verwenden, da sie leicht in die Hände der falschen Person fallen können. Microsoft Entra-Token laufen jede Stunde ab und müssen mit einem Aktualisierungstoken neu generiert werden, um ein neues Zugriffstoken zu erhalten, das den allgemeinen Risikofaktor begrenzt, wenn es durchleckt wird.

Sie können keinen Dienstprinzipal verwenden, um ein persönliches Zugriffstoken zu erstellen.

F: Welche Ratenlimits gelten für Dienstprinzipale und verwaltete Identitäten?

A: Derzeit gelten für Dienstprinzipale und verwaltete Identitäten die gleichen Ratenlimits wie für Benutzer.

F: Kostet die Verwendung dieses Features mehr?

A: Dienstprinzipale und verwaltete Identitäten werden basierend auf der Zugriffsebene ähnlich berechnet wie Benutzer. Eine wichtige Änderung betrifft die Behandlung der "multi-organisationsübergreifenden Abrechnung" für Dienstprinzipale. Benutzer werden als nur eine Lizenz gezählt, unabhängig davon, in wie vielen Organisationen sie sich gerade befindet. Dienstprinzipale werden pro organization Benutzer als eine Lizenz gezählt. Dieses Szenario ähnelt der standardmäßigen "Benutzerzuweisungsbasierte Abrechnung".

F: Kann ich einen Dienstprinzipal oder eine verwaltete Identität mit der Azure CLI verwenden?

A: Ja! Überall, in dem paTs in der Azure CLI gefragt werden, können auch Microsoft Entra-ID-Zugriffstoken akzeptiert werden. In diesen Beispielen erfahren Sie, wie Sie ein Microsoft Entra-Token zur Authentifizierung mit CLI übergeben können.

# To authenticate with a command: After typing this command, the az devops login will prompt you to enter a token. You can add an Entra ID token too! Not just a PAT.
az devops login

# To authenticate a service principal with a password or cert:
az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>

# To authenticate a managed identity:
az login --identity

Jetzt rufen wir ein Microsoft Entra-Token ab (die UUID 499b84ac-1321-427f-aa17-267ca6975798der Azure DevOps-Ressource) und versuchen, eine Azure DevOps-API aufzurufen, indem sie sie in den Headern als Bearer Token übergeben:

Write-Host "Obtain access token for Service Connection identity..."
$accessToken = az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query "accessToken" --output tsv

Write-Host "Use access token with Azure DevOps REST API to list projects in the organization..."
$apiVersion = "7.1-preview.1"
$uri = "https://dev.azure.com/${yourOrgname}/_apis/projects?api-version=${apiVersion}"
$headers = @{
    Accept = "application/json"
    Authorization = "Bearer $accessToken"
}
Invoke-RestMethod -Uri $uri -Headers $headers -Method Get | Select-Object -ExpandProperty value ` | Select-Object id, name

Jetzt können Sie Befehle wie gewohnt verwenden az cli .

F: Kann ich meiner organization eine verwaltete Identität aus einem anderen Mandanten hinzufügen?

A: Sie können nur eine verwaltete Identität aus demselben Mandanten hinzufügen, mit dem Ihr organization verbunden ist. Wir haben jedoch eine Problemumgehung, mit der Sie eine verwaltete Identität im "Ressourcenmandanten" einrichten können, wobei alle Ihre Ressourcen vorhanden sind. Anschließend können Sie es aktivieren, um es von einem Dienstprinzipal im "Zielmandanten" zu verwenden, in dem Ihre Organisation verbunden ist. Führen Sie die folgenden Schritte als Problemumgehung aus:

  1. Erstellen Sie eine benutzerseitig zugewiesene verwaltete Identität in Azure-Portal für Ihren Ressourcenmandanten.
  2. Stellen Sie eine Verbindung mit einem virtuellen Computer her, und weisen Sie ihm diese verwaltete Identität zu.
  3. Erstellen Sie einen Schlüsseltresor , und generieren Sie ein Zertifikat (darf nicht vom Typ "PEM") sein. Wenn Sie dieses Zertifikat generieren, wird auch ein Geheimnis mit demselben Namen generiert, das wir später verwenden.
  4. Gewähren Sie Zugriff auf die verwaltete Identität, damit sie den privaten Schlüssel aus dem Schlüsseltresor lesen kann. Erstellen Sie eine Zugriffsrichtlinie im Schlüsseltresor mit den Berechtigungen "Abrufen/Liste" (unter "Geheime Berechtigungen" und suchen Sie unter "Prinzipal auswählen" nach der verwalteten Identität.
  5. Laden Sie das erstellte Zertifikat im CER-Format herunter, um sicherzustellen, dass es nicht den privaten Teil Ihres Zertifikats enthält.
  6. Erstellen Sie eine neue Anwendungsregistrierung im Zielmandanten.
  7. Laden Sie das heruntergeladene Zertifikat auf diese neue Anwendung auf der Registerkarte "Zertifikate und geheime Schlüssel" hoch.
  8. Fügen Sie den Dienstprinzipal dieser Anwendung der Azure DevOps-organization sie zugreifen soll, und denken Sie daran, den Dienstprinzipal mit allen erforderlichen Berechtigungen einzurichten.
  9. Informationen zum Abrufen eines Microsoft Entra-Zugriffstokens von diesem Dienstprinzipal, der das verwaltete Identitätszertifikat verwendet, finden Sie im folgenden Codebeispiel:

Hinweis

Sie müssen Zertifikate wie immer regelmäßig rotieren.

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

	var secret = keyVaultSecret.Value;
	return secret.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(string applicationClientID, string appTenantId)
{
	IConfidentialClientApplication app;

	byte[] privateKeyBytes = Convert.FromBase64String(GetSecret(keyVaultName, secretName));
	X509Certificate2 certificateWithPrivateKey = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

	app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
		.WithCertificate(certificateWithPrivateKey)
		.WithAuthority(new Uri(string.Format(CultureInfo.InvariantCulture, "https://login.microsoftonline.com/{0}", appTenantId)))
		.Build();
	app.AddInMemoryTokenCache();

	string AdoAppClientID = "499b84ac-1321-427f-aa17-267ca6975798/.default";
	string[] scopes = new string[] { AdoAppClientID };

	var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

	return result;
}

Artifacts

F: Kann ich einen Dienstprinzipal verwenden, um eine Verbindung mit Feeds herzustellen?

A: Ja, Sie können eine Verbindung mit jedem Azure Artifacts-Feed mit einem Dienstprinzipal herstellen. In den folgenden Beispielen wird gezeigt, wie Sie eine Verbindung mit einem Microsoft Entra-ID-Token für NuGet, npm und Maven herstellen, andere Feedtypen sollten aber auch funktionieren.

NuGet-Projektsetup mit Microsoft Entra-Token

  1. Fügen Sie Ihrem Projekt eine Nuget.config-Datei im selben Ordner wie die CSPROJ - oder .sln datei hinzu .

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="FeedName" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" />
  </packageSources>
</configuration>

  2. Rufen Sie ein Microsoft Entra-ID-Token für Ihren Dienstprinzipal ab .

  3. Führen Sie den folgenden Befehl aus, um sich mit Ihren Anmeldeinformationen zu authentifizieren, und fügen Sie dann Ihr Token mit dem Setapikey-Befehl hinzu. Mit diesem Befehl wird Ihre Feedquelle zu "nuget.config" hinzugefügt:

    nuget sources add -name <FEED_NAME> -source <SOURCE_URL> -username <USERNAME> -password <PASSWORD>

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

npm-Projektsetup mit Microsoft Entra-Token

Hinweis

Das vsts-npm-auth-Tool unterstützt keine Microsoft Entra-Zugriffstoken.

  1. .npmrc Fügen Sie Ihrem Projekt im selben Verzeichnis wie Ihr package.jsoneine hinzu.

    registry=https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/registry/ 
always-auth=true

  2. Rufen Sie ein Zugriffstoken für Ihren Dienstprinzipal oder Ihre verwaltete Identität ab.

  3. Fügen Sie diesen Code zu Ihrer ${user.home}/.npmrc hinzu, und ersetzen Sie den Platzhalter [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] durch das Zugriffstoken aus dem vorherigen Schritt.

    //pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/:_authToken=[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]

Maven-Projektsetup mit Microsoft Entra-Token

  1. Fügen Sie das Repository sowohl ihren Abschnitten als <repositories><distributionManagement> auch ihren pom.xmlAbschnitten hinzu.

    <repository>
  <id>Fabrikam</id>
  <url>https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/maven/v1</url>
  <releases>
    <enabled>true</enabled>
  </releases>
  <snapshots>
    <enabled>true</enabled>
  </snapshots>
</repository>

  2. Rufen Sie ein Zugriffstoken für Ihren Dienstprinzipal oder Ihre verwaltete Identität ab.

  3. Fügen Sie die settings.xml Datei in hinzu, oder bearbeiten Sie sie, ${user.home}/.m2 und ersetzen Sie den Platzhalter [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] durch das Zugriffstoken aus dem vorherigen Schritt.

    <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                              https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>Fabrikam</id>
      <username>Fabrikam</username>
      <password>[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]</password>
    </server>
  </servers>
</settings>

Marketplace

F: Kann ich einen Dienstprinzipal verwenden, um Erweiterungen im Visual Studio Marketplace zu veröffentlichen?

A: Ja. Führen Sie die folgenden Schritte aus:

  1. Fügen Sie einem Herausgeberkonto einen Dienstprinzipal als Mitglied hinzu. Sie können die ID des Dienstprinzipals aus seinem Profil abrufen, indem Sie Profile – Abrufen verwenden. Anschließend können Sie den Dienstprinzipal als Mitglied zum Herausgeber hinzufügen, indem Sie die ID aus dem vorherigen Schritt verwenden.

  2. Veröffentlichen einer Erweiterung über die TFX CLI mithilfe eines SP. Führen Sie den folgenden TFX CLI-Befehl aus, um ein SP-Zugriffstoken zu verwenden:

tfx extension publish --publisher my-publisher --vsix my-publisher.my-extension-1.0.0.vsix --auth-type pat -t <AAD_ACCESS_TOKEN>

Pipelines

F: Kann ich eine verwaltete Identität innerhalb einer Dienstverbindung verwenden? Wie kann ich geheime Schlüssel für den Dienstprinzipal in meiner Dienstverbindung einfacher drehen? Kann ich vermeiden, geheime Schlüssel in einer Dienstverbindung vollständig zu speichern?

Azure-Support s workload identity federation using the OpenID Verbinden protocol, which allows us to create secret-free service connections in Azure Pipelines backed by service principals or managed identity with federated credentials in Microsoft Entra ID. Als Teil der Ausführung kann eine Pipeline ihr eigenes internes Token mit einem Microsoft Entra-Token austauschen und so Zugriff auf Azure-Ressourcen erhalten. Nach der Implementierung wird dieser Mechanismus im Produkt über andere Arten von Azure-Dienstverbindungen empfohlen, die heute vorhanden sind. Dieser Mechanismus kann auch zum Einrichten geheimer Bereitstellungen mit jedem anderen OIDC-kompatiblen Dienstanbieter verwendet werden. Dieser Mechanismus befindet sich in der Vorschau.

Repos

F: Kann ich einen Dienstprinzipal verwenden, um Git-Vorgänge auszuführen, z. B. zum Klonen eines Repositorys?

A: Sehen Sie sich das folgende Beispiel an, wie wir ein Microsoft Entra ID-Token eines Dienstprinzipals anstelle eines PAT übergeben, um ein Repository in einem PowerShell-Skript zu klonen.

$ServicePrincipalAadAccessToken = 'Entra ID access token of a service principal'
git -c http.extraheader="AUTHORIZATION: bearer $ServicePrincipalAadAccessToken" clone https://dev.azure.com/{yourOrgName}/{yourProjectName}/_git/{yourRepoName}

Tipp

Um Ihr Token sicherer zu halten, verwenden Sie Anmeldeinformations-Manager, damit Sie ihre Anmeldeinformationen nicht jedes Mal eingeben müssen. Wir empfehlen git Credential Manager, die Microsoft Entra-Token (d. h. Microsoft Identity OAuth-Token) anstelle von PATs akzeptieren können, wenn eine Umgebungsvariable geändert wird.

Ein hilfreicher Tipp zum Abrufen des Zugriffstokens von der Azure CLI zum Aufrufen von Git Fetch:

  1. Öffnen Sie die Git-Konfiguration Ihres Repositorys:
git config -e
  1. Fügen Sie die folgenden Zeilen hinzu, wobei die UUID der Azure DevOps-Ressource lautet 499b84ac-1321-427f-aa17-267ca6975798:
[credential]
    helper = "!f() { test \"$1\" = get && echo \"password=$(az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query accessToken -o tsv)\"; }; f"
  1. Testen Sie, ob es funktioniert, indem Sie folgendes verwenden:
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Potenzielle Fehler

Fehler beim Erstellen eines Dienstprinzipals mit der Objekt-ID "{provided objectId}"

Es gibt keinen Dienstprinzipal mit dem provided objectId im Mandanten, der mit Ihrem organization verbunden ist. Ein häufiger Grund ist, dass Sie die Objekt-ID der App-Registrierung anstelle der Objekt-ID des Dienstprinzipals übergeben. Denken Sie daran, dass ein Dienstprinzipal ein Objekt ist, das die Anwendung für einen bestimmten Mandanten darstellt, nicht die Anwendung selbst. finden service principal object ID Sie auf der Seite "Unternehmensanwendungen" Ihres Mandanten. Suchen Sie nach dem Namen der Anwendung, und wählen Sie das zurückgegebene Ergebnis "Unternehmensanwendung" aus. Dieses Ergebnis ist die Seite der Dienstprinzipal-/Unternehmensanwendung, und Sie können die Objekt-ID auf dieser Seite verwenden, um einen Dienstprinzipal in Azure DevOps zu erstellen.

Zugriff verweigert: {ID of the caller identity} benötigt die folgenden Berechtigungen für die Ressource Benutzer, um diese Aktion auszuführen: Benutzer hinzufügen

Dieser Fehler kann auf einen der folgenden Gründe zurückzuführen sein:

  • Sie sind nicht der Besitzer des organization, Projektsammlungsadministrator oder Projekt- oder Teamadministrator.
  • Sie sind Projekt- oder Teamadministrator, aber die Richtlinie "Team- und Projektadministratoren das Einladen neuer Benutzer erlauben" ist deaktiviert.
  • Sie sind Projekt- oder Teamadministrator, der neue Benutzer einladen kann, aber Sie versuchen, eine Lizenz zuzuweisen, wenn Sie einen neuen Benutzer einladen. Projekt- oder Teamadministratoren dürfen neuen Benutzern keine Lizenz zuweisen. Jeder neue eingeladene Benutzer wird auf der Standardzugriffsebene für neue Benutzer hinzugefügt. Wenden Sie sich an eine PCA, um die Lizenzzugriffsebene zu ändern.

Die Azure DevOps Graph List-API gibt eine leere Liste zurück, obwohl wir wissen, dass im organization

Die Azure DevOps Graph-Listen-API gibt möglicherweise eine leere Liste zurück, auch wenn es noch mehr Seiten von Benutzern gibt, die zurückgegeben werden sollen. Verwenden Sie , continuationToken um die Listen zu durchlaufen, und Sie können schließlich eine Seite finden, auf der die Dienstprinzipale zurückgegeben werden. Wenn ein continuationToken zurückgegeben wird, bedeutet dies, dass mehr Ergebnisse über die API verfügbar sind. Obwohl wir planen, diese Logik zu verbessern, ist es derzeit möglich, dass die ersten X-Ergebnisse leer zurückgegeben werden.

TF401444: Melden Sie sich mindestens einmal als {tenantId'tenantId\servicePrincipalObjectId'} in einem Webbrowser an, um den Zugriff auf den Dienst zu ermöglichen.

Wenn der Dienstprinzipal nicht zur Organisation eingeladen wurde, tritt möglicherweise der folgende Fehler auf. Stellen Sie sicher, dass der Dienstprinzipal der entsprechenden Organisation hinzugefügt wird und über alle Berechtigungen verfügt, die für den Zugriff auf erforderliche Ressourcen erforderlich sind.