Herstellen einer Verbindung mit Azure DocumentDB mithilfe der rollenbasierten Zugriffssteuerung und der Microsoft Entra-ID

Öffnen Sie ein neues Terminal.

Melden Sie sich bei Azure CLI an.

Verwenden Sie az group show, um die Metadaten für Ihre aktuelle Ressourcengruppe abzurufen.

az group show \
    --name "<name-of-existing-resource-group>"

Sehen Sie sich die Ausgabe des vorherigen Befehls an. Notieren Sie den Wert der id Eigenschaft für diese Ressourcengruppe, da sie im nächsten Schritt verwendet werden muss.

{
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example",
  "location": "westus",
  "name": "msdocs-identity-example",
  "type": "Microsoft.Resources/resourceGroups"
}

Erstellen Sie eine neue JSON-Datei mit dem Namen role-definition.json. Erstellen Sie in der Datei diese Ressourcendefinition, die die hier aufgelisteten Werte angibt. Fügen Sie für die AssignableScopes Liste die id Eigenschaft der im vorherigen Schritt aufgezeichneten Ressourcengruppe hinzu.

{
  "Name": "Azure DocumentDB RBAC Owner",
  "IsCustom": true,
  "Description": "Can perform all Azure role-based access control actions for Azure DocumentDB clusters.",
  "Actions": [
    "Microsoft.DocumentDb/mongoClusters/*"
  ],
  "AssignableScopes": [
    "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example"
  ]
}

Erstellen Sie eine neue Rollendefinition mithilfe von az role definition create. Verwenden Sie die role-definition.json als Eingabe für das --role-definition-Argument.

az role definition create \
    --role-definition role-definition.json

Überprüfen Sie die Ausgabe des Befehls zum Erstellen von Definitionen. Die Ausgabe enthält den eindeutigen Bezeichner der Rollendefinition in der id-Eigenschaft. Notieren Sie diesen Wert, da er im Zuweisungsschritt weiter unten in diesem Leitfaden verwendet werden muss.

{
  "assignableScopes": [
    "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example"
  ],
  "description": "Can perform all Azure role-based access control actions for Azure DocumentDB clusters.",
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example/providers/Microsoft.Authorization/roleDefinitions/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
  "name": "e4e4e4e4-ffff-aaaa-bbbb-c5c5c5c5c5c5",
  "permissions": [
    {
      "actions": [
        "Microsoft.DocumentDb/*"
      ]
    }
  ],
  "roleName": "Azure DocumentDB RBAC Owner",
  "roleType": "CustomRole"
}

Öffnen Sie ein neues Terminal.

Melden Sie sich bei Azure CLI an.

Erstellen Sie eine neue Bicep-Datei, um Ihre Rollendefinition zu definieren. Nennen Sie die Datei "control-plane-role-definition.bicep". Fügen Sie diese actions der Definition hinzu:

metadata description = 'Create RBAC definition for Azure role-based access control access to Azure DocumentDB.'

@description('Name of the role definition.')
param roleDefinitionName string = 'Azure DocumentDB RBAC Owner'

@description('Description of the role definition.')
param roleDefinitionDescription string = 'Can perform all Azure role-based access control actions for Azure DocumentDB clusters.'

resource definition 'Microsoft.Authorization/roleDefinitions@2022-04-01' = {
  name: guid(subscription().id, resourceGroup().id, roleDefinitionName)
  scope: resourceGroup()
  properties: {
    roleName: roleDefinitionName
    description: roleDefinitionDescription
    type: 'CustomRole'
    permissions: [
      {
        actions: [
          'Microsoft.DocumentDb/mongoClusters/*'
        ]
      }
    ]
    assignableScopes: [
      resourceGroup().id
    ]
  }
}

output definitionId string = definition.id

Stellen Sie die Bicep-Vorlage mithilfe von az deployment group create. Geben Sie den Namen der Bicep-Vorlage und der Azure-Ressourcengruppe an.

az deployment group create \
    --resource-group "<name-of-existing-resource-group>" \
    --template-file control-plane-role-definition.bicep

Überprüfen Sie die Ausgabe der Bereitstellung. Die Ausgabe enthält den eindeutigen Bezeichner der Rollendefinition in der properties.outputs.definitionId.value-Eigenschaft. Notieren Sie diesen Wert, da er im Zuweisungsschritt weiter unten in diesem Leitfaden verwendet werden muss.

{
  "properties": {
    "outputs": {
      "definitionId": {
        "type": "String",
        "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example/providers/Microsoft.Authorization/roleDefinitions/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1"
      }
    }
  }
}

Erstellen Sie eine neue Bicep-Datei, um Ihre Rollenzuweisung zu definieren. Nennen Sie die Datei "control-plane-role-assignment.bicep".

metadata description = 'Assign RBAC role for Azure role-based access control access to Azure DocumentDB.'

@description('Id of the role definition to assign to the targeted principal in the context of the cluster.')
param roleDefinitionId string

@description('Id of the identity/principal to assign this role in the context of the cluster.')
param identityId string

resource assignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(subscription().id, resourceGroup().id, roleDefinitionId, identityId)
  scope: resourceGroup()
  properties: {
    roleDefinitionId: roleDefinitionId
    principalId: identityId
  }
}

Erstellen Sie eine neue Bicep-Parameterdatei namens control-plane-role-assignment.bicepparam. In dieser Parameterdatei, weisen Sie die zuvor aufgezeichneten Rollendefinitions-IDs dem Parameter roleDefinitionId zu und den eindeutigen Bezeichner für Ihre Identität dem Parameter identityId.

using './control-plane-role-assignment.bicep'

param roleDefinitionId = '<id-of-new-role-definition>'
param identityId = '<id-of-existing-identity>'

Stellen Sie diese Bicep-Vorlage mithilfe von az deployment group create.

az deployment group create \
    --resource-group "<name-of-existing-resource-group>" \
    --parameters control-plane-role-assignment.bicepparam \
    --template-file control-plane-role-assignment.bicep

Melden Sie sich beim Azure-Portal (https://portal.azure.com) an.

Geben Sie die Ressourcengruppe in der globalen Suchleiste ein.

Wählen Sie in DienstenRessourcengruppen aus.

Wählen Sie im Bereich "Ressourcengruppen " Ihre vorhandene Ressourcengruppe aus.

Wählen Sie im Bereich für die Ressourcengruppe im Dienstmenü die Zugriffssteuerung (IAM) aus.

Wählen Sie im Bereich Access Control (IAM)"Hinzufügen" aus. Wählen Sie dann " Benutzerdefinierte Rolle hinzufügen" aus.

Konfigurieren Sie im Bereich "Grundlagen " die folgenden Optionen, und wählen Sie dann "Weiter" aus:

Wählen Sie im Bereich "Berechtigungen" die Option "Berechtigungen hinzufügen" aus. Suchen Sie dann im Berechtigungsdialog nach DocumentDB. Wählen Sie schließlich die Option "Microsoft.DocumentDB/mongoClusters " aus.

Wählen Sie im Berechtigungsdialog alle Aktionen für Microsoft.DocumentDB/mongoClusters. Wählen Sie dann "Hinzufügen" aus, um zum Bereich "*Berechtigungen" zurückzukehren.

Im Bereich "Berechtigungen" sehen Sie sich die Liste der Berechtigungen an. Wählen Sie dann Überprüfen + erstellen aus.

Überprüfen Sie im Bereich "Überprüfen + Erstellen " die angegebenen Optionen für die neue Rollendefinition. Wählen Sie schließlich "Erstellen" aus.

Warten Sie, bis das Portal die Erstellung der Rollendefinition abgeschlossen hat.

Wählen Sie im Bereich Access Control (IAM)"Hinzufügen " und dann " Rollenzuweisung hinzufügen" aus.

Suchen Sie im Rollenbereich nach Azure DocumentDB der Azure DocumentDB RBAC-Besitzerrolle , die weiter oben in diesem Leitfaden erstellt wurde, und wählen Sie sie aus. Wählen Sie anschließend Weiter aus.

Wählen Sie im Bereich "Mitglieder " die Option " Mitglieder auswählen " aus. Wählen Sie im Dialogfeld "Mitglieder" die Identität aus, die Sie dieser Zugriffsebene für Ihre Azure DocumentDB-Cluster gewähren möchten, und verwenden Sie dann die Option "Auswählen ", um Ihre Auswahl zu bestätigen.

Überprüfen Sie im Bereich Mitglieder die ausgewählten Mitglieder und wählen Sie dann Überprüfen + Zuweisen aus.

Überprüfen Sie im Bereich "Überprüfen+ Zuweisen " die angegebenen Optionen für die neue Rollenzuweisung. Wählen Sie schließlich "Überprüfen+ Zuweisen" aus.

Warten Sie, bis das Portal die Erstellung der Rollenzuweisung abgeschlossen hat.

Öffnen Sie ein neues Terminal.

Melden Sie sich bei Azure CLI an.

Überprüfen Sie Ihr Azure-Zielabonnement.

az account show

Erstellen Sie eine neue Terraform-Datei, um Ihre Rollendefinition zu definieren. Benennen Sie die Datei control-plane-role-definition.tf. Fügen Sie diese actions der Definition hinzu:

variable "role_definition_name" {
  type        = string
  description = "Name of the role definition."
  default     = "Azure DocumentDB RBAC Owner"
}

variable "role_definition_description" {
  type        = string
  description = "Description of the role definition."
  default     = "Can perform all Azure role-based access control actions for Azure DocumentDB clusters."
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_client_config" "current" {}

data "azurerm_resource_group" "existing" {
  name = "<name-of-existing-resource-group>"
}

resource "azurerm_role_definition" "control_plane" {
  name               = var.role_definition_name
  scope              = data.azurerm_resource_group.existing.id
  description        = var.role_definition_description

  permissions {
    actions = [
      "Microsoft.DocumentDb/mongoClusters/*"
    ]
  }

  assignable_scopes = [
    data.azurerm_resource_group.existing.id
  ]
}

output "definition_id" {
  value = azurerm_role_definition.control_plane.id
}

Initialisieren Sie die Terraform-Bereitstellung.

terraform init --upgrade

Erstellen Sie einen Ausführungsplan für die Rollendefinition, und speichern Sie ihn in einer Datei namens role-definition.tfplan.

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --out "role-definition.tfplan"

Wenden Sie den Ausführungsplan an, um die Rollendefinition in Azure bereitzustellen.

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "role-definition.tfplan"

Überprüfen Sie die Ausgabe der Bereitstellung. Die Ausgabe enthält den eindeutigen Bezeichner der Rollendefinition in der definition_id-Eigenschaft. Notieren Sie diesen Wert, da er im Zuweisungsschritt weiter unten in diesem Leitfaden verwendet werden muss.

Erstellen Sie eine neue Terraform-Datei, um Ihre Rollenzuweisung zu definieren. Nennen Sie die Datei "control-plane-role-assignment."tf

variable "role_definition_id" {
  type        = string
  description = "Id of the role definition to assign to the targeted principal in the context of the cluster."
}

variable "identity_id" {
  type        = string
  description = "Id of the identity/principal to assign this role in the context of the cluster."
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "existing" {
  name = "<name-of-existing-resource-group>"
}

resource "azurerm_role_assignment" "control_plane" {
  scope              = data.azurerm_resource_group.existing.id
  role_definition_id = var.role_definition_id
  principal_id       = var.identity_id
}

Erstellen Sie eine neue Terraform-Variablendatei namens control-plane-role-assignment.tfvars. In dieser Variablendatei, weisen Sie der Variablen role_definition_id die zuvor aufgezeichneten Rollendefinitions-IDs zu und der Variablen identity_id den eindeutigen Bezeichner für Ihre Identität.

role_definition_id = "<id-of-new-role-definition>"
identity_id        = "<id-of-existing-identity>"

Initialisieren und anwenden Sie diese Terraform-Konfiguration.

terraform init --upgrade

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --var-file="control-plane-role-assignment.tfvars" --out "role-assignment.tfplan"

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "role-assignment.tfplan"

Rufen Sie die Details für das aktuell angemeldete Konto mithilfe von az ad signed-in-user ab.

az ad signed-in-user show

Der Befehl gibt eine JSON-Antwort mit verschiedenen Feldern aus.

{
  "@odata.context": "<https://graph.microsoft.com/v1.0/$metadata#users/$entity>",
  "businessPhones": [],
  "displayName": "Kai Carter",
  "givenName": "Kai",
  "id": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "jobTitle": "Senior Sales Representative",
  "mail": "<kai@adventure-works.com>",
  "mobilePhone": null,
  "officeLocation": "Redmond",
  "preferredLanguage": null,
  "surname": "Carter",
  "userPrincipalName": "<kai@adventure-works.com>"
}

Aktivieren Sie die Microsoft Entra ID-Authentifizierung auf dem Cluster, indem Sie die Clusterressource so aktualisieren, dass das MicrosoftEntraID in die authConfig.allowedModes-Array aufgenommen wird.

az resource patch \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --properties '{"authConfig":{"allowedModes":["MicrosoftEntraID","NativeAuth"]}}' \
    --latest-include-preview

Überprüfen Sie, ob die Änderung angewendet wurde, indem Sie die authConfig-Eigenschaft für den Cluster mithilfe von az resource show lesen.

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --query "properties.authConfig" \
    --latest-include-preview

(Optional) Rufen Sie den eindeutigen Bezeichner für den Microsoft Entra-Prinzipal ab, den Sie für den Cluster registrieren möchten. Sie können sie mit der Azure CLI mit einem der folgenden Befehle abrufen:

• Aktuelle angemeldete Identität

  az ad signed-in-user show      
  

• Eine andere menschliche Identität mit einem benutzerfreundlichen Namen

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Service Principal mithilfe des Anwendungsbezeichners

  az ad sp show \
    --id "<application-id>"
  

• Verwaltete Identität mithilfe der Ressourcengruppe und des Namens

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Erstellen Sie eine kleine Bicep-Vorlage, die den Cluster authConfig aktualisiert, um die Microsoft Entra-ID einzuschließen (speichern unter enable-entra-id.bicep):

param clusterName string
param location string = resourceGroup().location

resource cluster 'Microsoft.DocumentDB/mongoClusters@2025-09-01' = {
  name: clusterName
  location: location
  properties: {
    authConfig: {
      allowedModes: [
        'MicrosoftEntraID'
        'NativeAuth'
      ]
    }
  }
}

Stellen Sie die Vorlage bereit, um den Cluster zu aktualisieren:

az deployment group create \
    --resource-group "<resource-group>" \
    --template-file enable-entra-id.bicep \
    --parameters clusterName="<cluster-name>"

Überprüfen Sie die authConfig Eigenschaft auf dem Cluster mithilfe von az resource show.

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --query "properties.authConfig" \
    --latest-include-preview

Suchen Sie im Startbereich des Azure-Portals die Option "Microsoft Entra-ID ", und wählen Sie sie aus.

Wählen Sie im Bereich "Übersicht" für den Microsoft Entra ID-Mandanten die Option "Benutzer " im Abschnitt "Verwalten " des Dienstmenüs aus.

Wählen Sie in der Liste der Benutzer die Identität (Benutzer) aus, zu der Sie weitere Details erhalten möchten.

Beobachten Sie im Detailbereich für den bestimmten Benutzer den Wert der Objekt-ID-Eigenschaft .

Navigieren Sie zur vorhandenen Azure DocumentDB-Clusterressource.

Wählen Sie im Clustermenü unter "Einstellungen" die Option "Authentifizierung" aus.

Wählen Sie im Abschnitt "Authentifizierungsmethoden " die Option "Native DocumentDB" und "Microsoft Entra ID " aus, um die Microsoft Entra ID-Authentifizierung zusammen mit der systemeigenen Authentifizierung zu aktivieren.

Wählen Sie "Speichern" aus, um die Änderung beizubehalten.

Der Abschnitt " Authentifizierungsmethoden " sollte jetzt sowohl NativeAuth als auch MicrosoftEntraID als aktivierte Methoden auflisten.

(Optional) Rufen Sie den eindeutigen Bezeichner für den Microsoft Entra-Prinzipal ab, den Sie für den Cluster registrieren möchten. Sie können sie mit der Azure CLI mit einem der folgenden Befehle abrufen:

• Aktuelle angemeldete Identität

  az ad signed-in-user show      
  

• Eine andere menschliche Identität mit einem benutzerfreundlichen Namen

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Service Principal mithilfe des Anwendungsbezeichners

  az ad sp show \
    --id "<application-id>"
  

• Verwaltete Identität mithilfe der Ressourcengruppe und des Namens

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Erstellen Sie eine Terraform-Konfigurationsdatei, um die Microsoft Entra ID-Authentifizierung auf Ihrem vorhandenen Cluster zu aktivieren. Speichern Sie die Datei als enable-entra-id.tf:

variable "cluster_name" {
  type        = string
  description = "Name of the existing cluster"
}

variable "resource_group_name" {
  type        = string
  description = "Name of the existing resource group"
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "existing" {
  name = var.resource_group_name
}

data "azurerm_mongo_cluster" "existing" {
  name                = var.cluster_name
  resource_group_name = data.azurerm_resource_group.existing.name
}

resource "azurerm_mongo_cluster" "enable_entra" {
  name                   = data.azurerm_mongo_cluster.existing.name
  resource_group_name    = data.azurerm_resource_group.existing.name
  location               = data.azurerm_mongo_cluster.existing.location
  administrator_username = data.azurerm_mongo_cluster.existing.administrator_username
  administrator_password = data.azurerm_mongo_cluster.existing.administrator_password
  shard_count            = data.azurerm_mongo_cluster.existing.shard_count
  compute_tier           = data.azurerm_mongo_cluster.existing.compute_tier
  high_availability_mode = data.azurerm_mongo_cluster.existing.high_availability_mode
  storage_size_in_gb     = data.azurerm_mongo_cluster.existing.storage_size_in_gb
  version                = data.azurerm_mongo_cluster.existing.version

  # Enable both Microsoft Entra ID and Native authentication
  authentication_enabled = true
}

Erstellen Sie eine Variablendatei namens enable-entra-id.tfvars mit Ihren Clusterdetails:

cluster_name        = "<cluster-name>"
resource_group_name = "<resource-group>"

Initialisieren und Anwenden der Terraform-Konfiguration, um die Microsoft Entra ID-Authentifizierung zu aktivieren:

terraform init --upgrade

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --var-file="enable-entra-id.tfvars" --out "enable-entra.tfplan"

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "enable-entra.tfplan"

Überprüfen Sie die authConfig Eigenschaft auf dem Cluster mithilfe von az resource show.

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --query "properties.authConfig" \
    --latest-include-preview

Rufen Sie mit einem der folgenden Befehle den eindeutigen Bezeichner (Objekt-ID) des Microsoft Entra-Prinzipals ab, dem Sie Zugriff gewähren möchten:

• Aktuelle angemeldete Identität

  az ad signed-in-user show      
  

• Eine andere menschliche Identität mit einem benutzerfreundlichen Namen

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Service Principal mithilfe des Anwendungsbezeichners

  az ad sp show \
    --id "<application-id>"
  

• Verwaltete Identität mithilfe der Ressourcengruppe und des Namens

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Registrieren Sie den Prinzipal im Cluster, und ordnen Sie ihn den MongoDB-Datenbankrollen zu. Im folgenden Beispiel wird ein Principal als readWrite Benutzer auf der sales Datenbank registriert.

az resource create \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --location "<cluster-region>" \
    --properties '{"identityProvider":{"type":"MicrosoftEntraID","properties":{"principalType":"User"}},"roles":[{"db":"sales","role":"readWrite"}]}' \
    --latest-include-preview

• Ersetzen Sie principalType durch servicePrincipal für App-/Dienstprinzipale oder durch ManagedIdentity für verwaltete Identitäten.
• Um Administratorrechte zu gewähren, verwenden Sie {"db":"admin","role":"root"} im roles-Array.

Alle registrierten Principals und ihre zugeordneten Rollen auflisten (Cluster-Ebene-Ansicht):

az rest \
    --method "GET" \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01"

• Die Antwort enthält ein Array von Benutzerressourcen, die jeweils identityProvider Metadaten und ein roles Array mit zugeordneten Datenbankrollen enthalten.

Details zu einem bestimmten registrierten Hauptverantwortlichen abrufen (ersetzen <principal-id>):

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Entfernen Sie einen registrierten Prinzipal (Widerrufen des Datenebenenzugriffs):

az resource delete \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Erstellen Sie eine Bicep-Datei (z. B. register-principal.bicep), um den Prinzipal zu registrieren und Datenbankrollen zuzuordnen:

param clusterName string
param principalId string
param location string = resourceGroup().location
param principalType string = 'User'
param roles array = [
  {
    db: 'sales'
    role: 'readWrite'
  }
]

resource user 'Microsoft.DocumentDB/mongoClusters/users@2025-09-01' = {
  name: '${clusterName}/users/${principalId}'
  location: location
  properties: {
    identityProvider: {
      type: 'Microsoft.EntraID'
      properties: {
        principalType: principalType
      }
    }
    roles: roles
  }
}

Stellen Sie die Bicep-Vorlage bereit, um den Prinzipal zu registrieren.

az deployment group create \
    --resource-group "<resource-group>" \
    --template-file register-principal.bicep \
    --parameters clusterName="<cluster-name>" principalId="<principal-id>"

Listen Sie alle registrierten Prinzipale für den Cluster mithilfe der REST-API (nützlich nach der Bicep-Bereitstellung) auf:

az rest \
    --method GET \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01"

Rufen Sie Details zu einem bestimmten registrierten Prinzipal ab, der von Bicep erstellt wurde (ersetzen Sie <principal-id>):

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Entfernen Sie den Prinzipal, indem Sie die Ressource löschen (oder eine Vorlage ohne die Benutzerressource bereitstellen):

az resource delete \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Öffnen Sie den Azure DocumentDB-Zielcluster im Azure-Portal.

Wählen Sie unter Einstellungen die Option Authentifizierung aus.

Im Abschnitt "Microsoft Entra ID-Authentifizierung" listet das Portal die registrierten Microsoft Entra-Hauptkonten anhand der Objekt-ID auf. Verwenden Sie diese Ansicht, um:

• Scannen Sie die Liste nach erwarteten Objektbezeichnern.
• Überprüfen Sie die Details für einen einzelnen Prinzipal, indem Sie einen aufgelisteten Eintrag auswählen (oder die Suchfunktion des Portals verwenden).
• Verwenden Sie die Aktion Entfernen neben einem Eintrag, um den Datenebenenzugriff des Prinzipals sofort zu widerrufen.

Verwenden Sie die Seite "Benutzer" im Abschnitt "Microsoft Entra ID", um freundliche Namen für Objektbezeichner abzurufen, die in der Portalliste angezeigt werden. Suchen Sie dann anhand der Objekt-ID oder des Anzeigenamens.

Rufen Sie mit einem der folgenden Befehle den eindeutigen Bezeichner (Objekt-ID) des Microsoft Entra-Prinzipals ab, dem Sie Zugriff gewähren möchten:

• Aktuelle angemeldete Identität

  az ad signed-in-user show      
  

• Eine andere menschliche Identität mit einem benutzerfreundlichen Namen

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Service Principal mithilfe des Anwendungsbezeichners

  az ad sp show \
    --id "<application-id>"
  

• Verwaltete Identität mithilfe der Ressourcengruppe und des Namens

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Erstellen Sie eine Terraform-Datei (z. B. register-principal.tf), um den Prinzipal zu registrieren und Datenbankrollen mithilfe des AzAPI-Anbieters zuzuordnen:

variable "cluster_name" {
  type        = string
  description = "Name of the existing cluster"
}

variable "resource_group_name" {
  type        = string
  description = "Name of the existing resource group"
}

variable "principal_id" {
  type        = string
  description = "Object ID of the Microsoft Entra principal"
}

variable "principal_type" {
  type        = string
  description = "Type of principal: User, ServicePrincipal, or ManagedIdentity"
  default     = "User"
}

variable "roles" {
  type = list(object({
    db   = string
    role = string
  }))
  description = "Database roles to assign"
  default = [
    {
      db   = "sales"
      role = "readWrite"
    }
  ]
}

terraform {
  required_providers {
    azapi = {
      source  = "azure/azapi"
      version = "~> 2.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

provider "azapi" {}

data "azurerm_resource_group" "existing" {
  name = var.resource_group_name
}

data "azurerm_mongo_cluster" "existing" {
  name                = var.cluster_name
  resource_group_name = var.resource_group_name
}

resource "azapi_resource" "mongo_cluster_user" {
  type      = "Microsoft.DocumentDB/mongoClusters/users@2025-09-01"
  name      = var.principal_id
  parent_id = data.azurerm_mongo_cluster.existing.id
  location  = data.azurerm_resource_group.existing.location

  body = {
    properties = {
      identityProvider = {
        type = "MicrosoftEntraID"
        properties = {
          principalType = var.principal_type
        }
      }
      roles = var.roles
    }
  }
}

Erstellen Sie eine Variablendatei mit dem Namen register-principal.tfvars:

cluster_name        = "<cluster-name>"
resource_group_name = "<resource-group>"
principal_id        = "<principal-id>"
principal_type      = "User"
roles = [
  {
    db   = "sales"
    role = "readWrite"
  }
]

Initialisieren Sie die Terraform-Konfiguration, und wenden Sie sie an, um den Prinzipal zu registrieren:

terraform init --upgrade

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --var-file="register-principal.tfvars" --out "register-principal.tfplan"

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "register-principal.tfplan"

Alle registrierten Hauptentitäten für den Cluster mithilfe der REST-API auflisten (sinnvoll nach dem Terraform-Deployment):

az rest \
    --method GET \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01"

Details abrufen für einen bestimmten registrierten Principal, der von Terraform erstellt wurde (ersetzen <principal-id>):

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Entfernen Sie den Prinzipal, indem Sie die Terraform-Ressource zerstören:

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform destroy --var-file="register-principal.tfvars"

Navigieren Sie zum Azure DocumentDB-Cluster.

Wählen Sie die Navigationsoption "Verbindungszeichenfolgen " aus.

Kopieren oder zeichnen Sie den Wert aus dem Feld "Verbindungszeichenfolge" auf.