Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.
Hinweis
In Azure Active Directory B2C sind benutzerdefinierte Richtlinien in erster Linie für komplexe Szenarien konzipiert. Für die meisten Szenarien empfehlen wir die Verwendung von integrierten Benutzerflows. Informieren Sie sich, sofern noch nicht geschehen, unter Tutorial: Erstellen von Benutzerflows und benutzerdefinierten Richtlinien in Azure Active Directory B2C über das Starter Pack für benutzerdefinierte Richtlinien.
Azure Active Directory B2C (Azure AD B2C) bietet Unterstützung für die Microsoft Entra Benutzerverwaltung. In diesem Artikel werden die Einzelheiten eines technischen Profils für die Interaktion mit einem Anspruchsanbieter thematisiert, der dieses standardisierte Protokoll unterstützt.
Protokoll
Das Name-Attribut des Protocol-Elements muss auf Proprietary festgelegt werden. Das handler-Attribut muss den vollqualifizierten Namen der Protokollhandler-Assembly Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=nullenthalten.
Zu den folgenden technischen Microsoft Entra-Profilen für benutzerdefinierte Richtlinien gehört das technische Profil AAD-Common. Die technischen Profile von Microsoft Entra geben das Protokoll nicht an, da das Protokoll im technischen Profil AAD-Common konfiguriert ist:
- AAD-UserReadUsingAlternativeSecurityId und AAD-UserReadUsingAlternativeSecurityId-NoError : Suchen Sie im Verzeichnis nach einem Konto für soziale Netzwerke.
- AAD-UserWriteUsingAlternativeSecurityId: Erstellen Sie ein neues Konto für soziale Netzwerke.
- AAD-UserReadUsingEmailAddress : Suchen Sie nach einem lokalen Konto im Verzeichnis.
- AAD-UserWriteUsingLogonEmail: Erstellen Sie ein neues lokales Konto.
- AAD-UserWritePasswordUsingObjectId : Aktualisieren Sie das Kennwort eines lokalen Kontos.
- AAD-UserWriteProfileUsingObjectId : Aktualisieren eines Benutzerprofils eines lokalen oder sozialen Kontos.
- AAD-UserReadUsingObjectId: Lesen eines Benutzerprofils eines lokalen oder sozialen Kontos.
- AAD-UserWritePhoneNumberUsingObjectId - Schreiben Sie die MFA-Telefonnummer eines lokalen oder sozialen Kontos
Das folgende Beispiel zeigt das technische Profil AAD-Common:
<TechnicalProfile Id="AAD-Common">
<DisplayName>Azure Active Directory</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<!-- We need this here to suppress the SelfAsserted provider from invoking SSO on validation profiles. -->
<IncludeInSso>false</IncludeInSso>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
Eingabe-Ansprüche
Das InputClaims-Element enthält einen Anspruch, der verwendet wird, um ein Konto im Verzeichnis nachzuschlagen oder ein neues Konto zu erstellen. Es muss genau ein InputClaim-Element in der Eingabeanspruchssammlung für alle technischen Microsoft Entra-Profile vorhanden sein. Möglicherweise müssen Sie den Namen des in Ihrer Richtlinie definierten Anspruchs dem Namen zuordnen, der in Microsoft Entra ID definiert ist.
Zum Lesen, Aktualisieren oder Löschen eines vorhandenen Benutzerkontos ist der Eingabeanspruch ein Schlüssel, der das Konto im Microsoft Entra Verzeichnis eindeutig identifiziert. Beispiel: objectId, userPrincipalName, signInNames.emailAddress, signInNames.userName oder alternativeSecurityId.
Um ein neues Benutzerkonto zu erstellen, ist der Eingabeanspruch ein Schlüssel, der ein lokales Konto oder ein Verbundkonto eindeutig identifiziert. Beispiel: lokales Konto: signInNames.emailAddress oder signInNames.userName. Für ein Verbundkonto: die alternativeSecurityId.
Das InputClaimsTransformations-Element kann eine Auflistung von Transformationselementen für Eingabeansprüche enthalten, die zum Ändern des Eingabeanspruchs oder zum Generieren eines neuen Anspruchs verwendet werden.
OutputClaims
Das OutputClaims-Element enthält eine Liste der Ansprüche, die vom technischen Microsoft Entra-Profil zurückgegeben werden. Möglicherweise müssen Sie den Namen des in Ihrer Richtlinie definierten Anspruchs dem Namen zuordnen, der in Microsoft Entra ID definiert ist. Sie können auch Ansprüche einschließen, die nicht von der Microsoft Entra ID zurückgegeben werden, solange Sie das DefaultValue Attribut festlegen.
Das OutputClaimsTransformations-Element kann eine Auflistung von OutputClaimsTransformation-Elementen enthalten, die verwendet werden, um die Ausgabeansprüche zu ändern oder neue zu generieren.
Das technische Profil AAD-UserWriteUsingLogonEmail erstellt z. B. ein lokales Konto und gibt die folgenden Ansprüche zurück:
- objectId, die Kennung des neuen Kontos
- newUser, der angibt, ob der Benutzer neu ist
-
authenticationSource, wodurch die Authentifizierung auf
localAccountAuthentication - userPrincipalName, bei dem es sich um den Benutzerprinzipalnamen des neuen Kontos handelt
- signInNames.emailAddress, bei dem es sich um den Anmeldenamen des Kontos handelt, ähnlich dem E-Mail-Eingabeanspruch
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
</OutputClaims>
PersistedClaims
Das PersistedClaims-Element enthält alle Werte, die von der Microsoft Entra ID beibehalten werden sollen, mit möglichen Zuordnungsinformationen zwischen einem Anspruchstyp, der bereits im Abschnitt ClaimsSchema in der Richtlinie definiert ist, und dem Namen des Microsoft Entra Attributs.
Das technische Profil AAD-UserWriteUsingLogonEmail , mit dem ein neues lokales Konto erstellt wird, behält die folgenden Ansprüche bei:
<PersistedClaims>
<!-- Required claims -->
<PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
<PersistedClaim ClaimTypeReferenceId="newPassword" PartnerClaimType="password"/>
<PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />
<PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration" />
<!-- Optional claims. -->
<PersistedClaim ClaimTypeReferenceId="givenName" />
<PersistedClaim ClaimTypeReferenceId="surname" />
</PersistedClaims>
Der Name des Anspruchs ist der Name des Microsoft Entra Attributs, es sei denn, es wird das PartnerClaimType-Attribut angegeben, das den Namen des Microsoft Entra Attributs enthält.
Anforderungen an einen Arbeitsgang
- Es muss genau ein InputClaim-Element im Anspruchsbehälter für alle technischen Microsoft Entra Profile vorhanden sein.
- Im Artikel Benutzerprofilattribute werden die unterstützten Azure AD B2C-Benutzerprofilattribute beschrieben, die Sie in den Eingabeansprüchen, Ausgabeansprüchen und persistenten Ansprüchen verwenden können.
- Wenn der Vorgang or
WriteistDeleteClaims, muss er auch in einem PersistedClaims-Element angezeigt werden. - Der Wert des userPrincipalName-Anspruchs muss das Format
user@tenant.onmicrosoft.com. - Der displayName-Anspruch ist erforderlich und darf keine leere Zeichenfolge sein.
Vorgänge des technischen Microsoft Entra Profils
Lesen Sie
Der Lesevorgang liest Daten zu einem einzelnen Benutzerkonto. Das folgende technische Profil liest Daten über ein Benutzerkonto anhand der objectId des Benutzers aus:
<TechnicalProfile Id="AAD-UserReadUsingObjectId">
<Metadata>
<Item Key="Operation">Read</Item>
<Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="objectId" Required="true" />
</InputClaims>
<OutputClaims>
<!-- Required claims -->
<OutputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" />
<!-- Optional claims -->
<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="otherMails" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
</OutputClaims>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
Schreiben
Mit dem Schreibvorgang wird ein einzelnes Benutzerkonto erstellt oder aktualisiert. Das folgende technische Profil erstellt ein neues soziales Konto:
<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
<Metadata>
<Item Key="Operation">Write</Item>
<Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
<Item Key="UserMessageIfClaimsPrincipalAlreadyExists">You are already registered, please press the back button and sign in instead.</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="CreateOtherMailsFromEmail" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="AlternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />
</InputClaims>
<PersistedClaims>
<!-- Required claims -->
<PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
<PersistedClaim ClaimTypeReferenceId="userPrincipalName" />
<PersistedClaim ClaimTypeReferenceId="mailNickName" DefaultValue="unknown" />
<PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />
<!-- Optional claims -->
<PersistedClaim ClaimTypeReferenceId="otherMails" />
<PersistedClaim ClaimTypeReferenceId="givenName" />
<PersistedClaim ClaimTypeReferenceId="surname" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
<OutputClaim ClaimTypeReferenceId="otherMails" />
</OutputClaims>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
<UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
DeleteClaims (Löschen)
Der DeleteClaims-Vorgang löscht die Informationen aus einer bereitgestellten Liste von Ansprüchen. Das folgende technische Profil löscht Ansprüche:
<TechnicalProfile Id="AAD-DeleteClaimsUsingObjectId">
<Metadata>
<Item Key="Operation">DeleteClaims</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="objectId" Required="true" />
</InputClaims>
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="objectId" />
<PersistedClaim ClaimTypeReferenceId="Verified.strongAuthenticationPhoneNumber" PartnerClaimType="strongAuthenticationPhoneNumber" />
</PersistedClaims>
<OutputClaims />
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
DeleteClaimsPrincipal
Der DeleteClaimsPrincipal-Vorgang löscht ein einzelnes Benutzerkonto aus dem Verzeichnis. Das folgende technische Profil löscht ein Benutzerkonto aus dem Verzeichnis unter Verwendung des Benutzerprinzipalnamens:
<TechnicalProfile Id="AAD-DeleteUserUsingObjectId">
<Metadata>
<Item Key="Operation">DeleteClaimsPrincipal</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="objectId" Required="true" />
</InputClaims>
<OutputClaims/>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
Das folgende technische Profil löscht ein Benutzerkonto für soziale Netzwerke mit alternativeSecurityId:
<TechnicalProfile Id="AAD-DeleteUserUsingAlternativeSecurityId">
<Metadata>
<Item Key="Operation">DeleteClaimsPrincipal</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="alternativeSecurityId" Required="true" />
</InputClaims>
<OutputClaims/>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
Metadaten
| Merkmal | Erforderlich | BESCHREIBUNG |
|---|---|---|
| Vorgang | Ja | Der auszuführende Vorgang. Mögliche Werte: Read, Write, DeleteClaims oder DeleteClaimsPrincipal. |
| RaiseErrorIfClaimsPrincipalDoesNotExist | Nein | Löst einen Fehler aus, wenn das Benutzerobjekt nicht im Verzeichnis vorhanden ist. Mögliche Werte: true oder false. |
| RaiseErrorIfClaimsPrincipalAlreadyExists | Nein | Lösen Sie einen Fehler aus, wenn das Benutzerobjekt bereits vorhanden ist. Mögliche Werte: true oder false. Diese Metadaten gelten nur für den Schreibvorgang. |
| ApplicationObjectId | Nein | Der Anwendungsobjektbezeichner für Erweiterungsattribute. Wert: ObjectId einer Anwendung. Weitere Informationen finden Sie unter Verwenden von benutzerdefinierten Attributen. |
| ClientId | Nein | Die Client-ID für den Zugriff auf den Mandanten als Drittanbieter. Weitere Informationen finden Sie unter Verwenden von benutzerdefinierten Attributen in einer Richtlinie zum Bearbeiten von benutzerdefinierten Profilen |
| IncludeClaimResolvingInClaimsHandling | Nein | Gibt für Eingabe- und Ausgabeansprüche an, ob die Forderungsauflösung im technischen Profil enthalten ist. Mögliche Werte sind true oder false (Standardwert). Wenn Sie einen Anspruchslöser im technischen Profil verwenden möchten, legen Sie dies auf true. |
Benutzeroberflächenelemente
Die folgenden Einstellungen können verwendet werden, um die Fehlermeldung zu konfigurieren, die bei einem Fehler angezeigt wird. Die Metadaten sollten im selbst bestätigten technischen Profil konfiguriert werden. Die Fehlermeldungen können lokalisiert werden.
| Merkmal | Erforderlich | BESCHREIBUNG |
|---|---|---|
| UserMessageIfClaimsPrincipalAlreadyExists | Nein | Wenn ein Fehler ausgelöst werden soll (siehe Beschreibung des RaiseErrorIfClaimsPrincipalAlreadyExists-Attributs), geben Sie die Meldung an, die dem Benutzer angezeigt werden soll, wenn das Benutzerobjekt bereits vorhanden ist. |
| UserMessageIfClaimsPrincipalDoesNotExist | Nein | Wenn ein Fehler ausgelöst werden soll (siehe Beschreibung des RaiseErrorIfClaimsPrincipalDoesNotExist-Attributs), geben Sie die Meldung an, die dem Benutzer angezeigt werden soll, wenn das Benutzerobjekt nicht vorhanden ist. |
Nächste Schritte
Weitere Informationen finden Sie im folgenden Artikel, z. B. zur Verwendung des technischen Profils von Microsoft Entra: