Skapa och läsa ett användarkonto med hjälp av en anpassad princip för Azure Active Directory B2C

Artikel
01/11/2024

Azure Active Directory B2C (Azure AD B2C) bygger på Microsoft Entra-ID och använder därför Microsoft Entra ID-lagring för att lagra användarkonton. Azure AD B2C-kataloganvändarprofil levereras med en inbyggd uppsättning attribut, till exempel förnamn, efternamn, stad, postnummer och telefonnummer, men du kan utöka användarprofilen med dina egna anpassade attribut utan att kräva ett externt datalager.

Din anpassade princip kan ansluta till Microsoft Entra ID-lagring med hjälp av microsoft entra-ID:ts tekniska profil för att lagra, uppdatera eller ta bort användarinformation. I den här artikeln får du lära dig hur du konfigurerar en uppsättning tekniska Profiler för Microsoft Entra-ID för lagring och läsning av ett användarkonto innan en JWT-token returneras.

Scenarioöversikt

I artikeln Anropa ett REST-API med hjälp av azure Active Directory B2C-anpassad princip samlar vi in information från användaren, verifierar data, kallas rest-API och returnerar slutligen en JWT utan att lagra ett användarkonto. Vi måste lagra användarinformationen så att vi inte förlorar informationen när principen har slutfört körningen. Den här gången, när vi har samlat in användarinformationen och verifierat den, måste vi lagra användarinformationen i Azure AD B2C-lagringen och sedan läsa innan vi returnerar JWT-token. Hela processen visas i följande diagram.

A flowchart of creating a user account in Azure AD.

Förutsättningar

Om du inte redan har en skapar du en Azure AD B2C-klientorganisation som är länkad till din Azure-prenumeration.
Registrera ett webbprogram och aktivera implicit beviljande av ID-token. För omdirigerings-URI använder du https://jwt.ms.
Visual Studio Code (VS Code) måste vara installerat på datorn.
Slutför stegen i Anropa ett REST API med hjälp av en anpassad princip för Azure Active Directory B2C. Den här artikeln är en del av guideserien Skapa och kör egna anpassade principer.

Kommentar

Den här artikeln är en del av guideserien Skapa och köra egna anpassade principer i Azure Active Directory B2C. Vi rekommenderar att du startar den här serien från den första artikeln.

Steg 1 – Deklarera anspråk

Du måste deklarera ytterligare två anspråk, userPrincipalName, och passwordPolicies:

Leta upp elementet ContosoCustomPolicy.XML ClaimsSchema i filen och deklarera userPrincipalName och passwordPolicies anspråk med hjälp av följande kod:

    <ClaimType Id="userPrincipalName">
        <DisplayName>UserPrincipalName</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
    </ClaimType>
    <ClaimType Id="passwordPolicies">
        <DisplayName>Password Policies</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
    </ClaimType>

Läs mer om användning av userPrincipalName passwordPolicies och anspråk i artikeln Användarprofilattribut .

Steg 2 – Skapa tekniska profiler för Microsoft Entra-ID

Du måste konfigurera två tekniska Profiler för Microsoft Entra-ID. En teknisk profil skriver användarinformation till Microsoft Entra ID-lagring och den andra läser ett användarkonto från Microsoft Entra ID Storage.

Leta upp elementet ContosoCustomPolicy.XML ClaimsProviders i filen och lägg till en ny anspråksprovider med hjälp av koden nedan. Den här anspråksprovidern har tekniska profiler för Microsoft Entra-ID:

    <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            <!--You'll add you Azure AD Technical Profiles here-->
        </TechnicalProfiles>
    </ClaimsProvider>

I anspråksprovidern som du nyss skapade lägger du till en teknisk Profil för Microsoft Entra-ID med hjälp av följande kod:

    <TechnicalProfile Id="AAD-UserWrite">
        <DisplayName>Write user information to AAD</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Write</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
            <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
            <PersistedClaim ClaimTypeReferenceId="displayName" />
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
            <PersistedClaim ClaimTypeReferenceId="password"/>
            <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        </OutputClaims>
    </TechnicalProfile>

Vi har lagt till en ny teknisk profil för Microsoft Entra ID, AAD-UserWrite. Du måste notera följande viktiga delar av den tekniska profilen:

Åtgärd: Åtgärden anger vilken åtgärd som ska utföras, i det här fallet Skriv. Läs mer om andra åtgärder i en teknisk Microsoft Entra ID-provider.
Beständiga anspråk: Elementet PersistedClaims innehåller alla värden som ska lagras i Microsoft Entra ID-lagring.
InputClaims: Elementet InputClaims innehåller ett anspråk som används för att leta upp ett konto i katalogen eller skapa ett nytt. Det måste finnas exakt ett indataanspråkelement i insamlingen av indataanspråk för alla tekniska Profiler för Microsoft Entra-ID. Den här tekniska profilen använder e-postanspråket som nyckelidentifierare för användarkontot. Läs mer om andra nyckelidentifierare som du kan använda för att unikt identifiera ett användarkonto.

ContosoCustomPolicy.XML Leta upp den AAD-UserWrite tekniska profilen i filen och lägg sedan till en ny teknisk profil efter den med hjälp av följande kod:

    <TechnicalProfile Id="AAD-UserRead">
        <DisplayName>Read user from Azure AD storage</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName"/>
            <OutputClaim ClaimTypeReferenceId="surname"/>
            <OutputClaim ClaimTypeReferenceId="displayName"/>
        </OutputClaims>
    </TechnicalProfile>

Vi har lagt till en ny teknisk profil för Microsoft Entra ID, AAD-UserRead. Vi har konfigurerat den här tekniska profilen för att utföra en läsåtgärd och för att returnera objectId, userPrincipalName, givenNamesurname och displayName anspråk om ett användarkonto med email i InputClaim avsnittet hittas.

Steg 3 – Använda den tekniska profilen för Microsoft Entra-ID

När vi har samlat in användarinformation med hjälp av den UserInformationCollector självsäkra tekniska profilen måste vi skriva ett användarkonto till Microsoft Entra ID-lagring med hjälp av den AAD-UserWrite tekniska profilen. Det gör du genom att använda den AAD-UserWrite tekniska profilen som en teknisk valideringsprofil i den UserInformationCollector självsäkra tekniska profilen.

ContosoCustomPolicy.XML Leta upp den UserInformationCollector tekniska profilen i filen och lägg sedan till AAD-UserWrite teknisk profil som en teknisk valideringsprofil i ValidationTechnicalProfiles samlingen. Du måste lägga till detta efter den tekniska verifieringsprofilen CheckCompanyDomain .

Vi använder den AAD-UserRead tekniska profilen i orkestreringsstegen för användarresan för att läsa användarinformationen innan vi utfärdar en JWT-token.

Steg 4 – Uppdatera den tekniska profilen ClaimGenerator

Vi använder den ClaimGenerator tekniska profilen för att köra tre anspråksomvandlingar, GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation och CreateMessageTransformation.

Leta upp den ContosoCustomPolicy.XML ClaimGenerator tekniska profilen i filen och ersätt den med följande kod:

    <TechnicalProfile Id="UserInputMessageClaimGenerator">
        <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="message" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    <TechnicalProfile Id="UserInputDisplayNameGenerator">
        <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

Vi har delat upp den tekniska profilen i två separata tekniska profiler. Den tekniska profilen UserInputMessageClaimGenerator genererar meddelandet som skickas som anspråk i JWT-token. Den tekniska profilen UserInputDisplayNameGenerator genererar anspråket displayName . Anspråksvärdet displayName måste vara tillgängligt innan den AAD-UserWrite tekniska profilen skriver användarposten till Microsoft Entra ID-lagring. I den nya koden tar vi bort GenerateRandomObjectIdTransformation eftersom den objectId skapas och returneras av Microsoft Entra-ID när ett konto har skapats, så vi behöver inte generera det själva i principen.

Leta upp den ContosoCustomPolicy.XML UserInformationCollector självsäkra tekniska profilen i filen och lägg sedan till den UserInputDisplayNameGenerator tekniska profilen som en teknisk valideringsprofil. När du gör det bör den UserInformationCollector tekniska profilens ValidationTechnicalProfiles samling se ut ungefär som följande kod:

    <!--<TechnicalProfile Id="UserInformationCollector">-->
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                        <Value>accountType</Value>
                        <Value>work</Value>
                        <Action>SkipThisValidationTechnicalProfile</Action>
                    </Precondition>
                </Preconditions>
            </ValidationTechnicalProfile>                        
            <ValidationTechnicalProfile ReferenceId="DisplayNameClaimGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

Du måste lägga till den tekniska valideringsprofilen innan AAD-UserWrite anspråksvärdet displayName måste vara tillgängligt innan den AAD-UserWrite tekniska profilen skriver användarposten till Microsoft Entra ID-lagring.

Steg 5 – Uppdatera orkestreringsstegen för användarresan

Leta upp din HelloWorldJourney användarresa och ersätt alla orkestreringssteg med följande kod:

    <!--<OrchestrationSteps>-->
        <OrchestrationStep Order="1" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
            </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

I orkestreringssteget 4kör vi den AAD-UserRead tekniska profilen för att läsa användarinformationen (som ska ingå i JWT-token) från det skapade användarkontot.

Eftersom vi inte lagrar anspråket message kör vi i orkestreringssteget 5UserInputMessageClaimGenerator för att generera anspråket message för inkludering på JWT-token.

Steg 6 – Ladda upp princip

Följ stegen i Ladda upp en anpassad principfil för att ladda upp principfilen. Om du laddar upp en fil med samma namn som den som redan finns i portalen kontrollerar du att du väljer Skriv över den anpassade principen om den redan finns.

Steg 7 – Testprincip

Följ stegen i Testa den anpassade principen för att testa din anpassade princip.

När principen har slutfört körningen och du får din ID-token kontrollerar du att användarposten har skapats:

Logga in på Azure-portalen med behörigheter som global administratör eller privilegierad rolladministratör.
Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Azure AD B2C-klient från menyn Kataloger + prenumerationer.
Under Azure-tjänster väljer du Azure AD B2C. Eller använd sökrutan för att hitta och välja Azure AD B2C.
Under Hantera väljer du Användare.
Leta upp det användarkonto som du nyss skapade och välj det. Kontoprofilen ser ut ungefär som skärmbilden nedan:

I vår AAD-UserWrite tekniska Profil för Microsoft Entra-ID anger vi att om användaren redan finns skapar vi ett felmeddelande.

Testa din anpassade princip igen med samma e-postadress. I stället för att principen körs till slutförande för att utfärda en ID-token bör du se ett felmeddelande som liknar skärmbilden nedan.

A screenshot of error as account already exists.

Kommentar

Värdet för lösenordsanspråk är en mycket viktig information, så var mycket försiktig med hur du hanterar det i din anpassade princip. Av liknande skäl behandlar Azure AD B2C värdet för lösenordsanspråk som ett särskilt värde. När du samlar in värdet för lösenordsanspråk i den självsäkra tekniska profilen är det värdet endast tillgängligt inom samma tekniska profil eller inom en teknisk valideringsprofil som refereras av samma självsäkra tekniska profil. När körningen av den självsäkra tekniska profilen har slutförts och flyttas till en annan teknisk profil går värdet förlorat.

Verifiera användarens e-postadress

Vi rekommenderar att du verifierar en användares e-post innan du använder den för att skapa ett användarkonto. När du verifierar e-postadresser kontrollerar du att kontona har skapats av riktiga användare. Du kan också hjälpa användarna att se till att de använder rätt e-postadresser för att skapa ett konto.

Azure AD B2C:s anpassade princip är ett sätt att verifiera e-postadressen med hjälp av verifieringsvisningskontroll. Du skickar en verifieringskod till e-postmeddelandet. När koden har skickats läser användaren meddelandet, anger verifieringskoden i kontrollen som tillhandahålls av visningskontrollen och väljer knappen Verifiera kod .

En visningskontroll är ett användargränssnittselement som har särskilda funktioner och interagerar med Azure Active Directory B2C-serverdelstjänsten (Azure AD B2C). Det gör att användaren kan utföra åtgärder på sidan som anropar en teknisk valideringsprofil i serverdelen. Visningskontroller visas på sidan och refereras av en självkontrollerad teknisk profil.

Använd följande steg för att lägga till e-postverifiering med hjälp av en visningskontroll:

Deklarera anspråk

Du måste deklarera ett anspråk som ska användas för att lagra verifieringskoden.

Om du vill deklarera anspråket ContosoCustomPolicy.XML letar du upp elementet ClaimsSchema i filen och deklarerar verificationCode anspråket med hjälp av följande kod:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

Konfigurera en teknisk profil för att skicka och verifiera kod

Azure AD B2C använder teknisk profil för Microsoft Entra Entra ID SSPR för att verifiera en e-postadress. Den här tekniska profilen kan generera och skicka en kod till en e-postadress eller verifiera koden beroende på hur du konfigurerar den.

Leta upp elementet ContosoCustomPolicy.XML ClaimsProviders i filen och lägg till anspråksprovidern med hjälp av följande kod:

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

Vi har konfigurerat två tekniska profiler AadSspr-SendCode och AadSspr-VerifyCode. AadSspr-SendCode genererar och skickar en kod till den e-postadress som anges i InputClaims avsnittet medan AadSspr-VerifyCode verifierar koden. Du anger vilken åtgärd du vill utföra i den tekniska profilens metadata.

Konfigurera en visningskontroll

Du måste konfigurera en visningskontroll för e-postverifiering för att kunna verifiera användarnas e-post. Visningskontrollen för e-postverifiering som du konfigurerar ersätter det e-postvisningsanspråk som du använder för att samla in ett e-postmeddelande från användaren.

Använd följande steg för att konfigurera en visningskontroll:

ContosoCustomPolicy.XML Leta upp BuildingBlocks avsnittet i filen och lägg sedan till en visningskontroll som ett underordnat element med hjälp av följande kod:

    <!--<BuildingBlocks>-->
        ....
        <DisplayControls>
            <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
              <DisplayClaims>
                <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
              </DisplayClaims>
              <OutputClaims></OutputClaims>
              <Actions>
                <Action Id="SendCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                  </ValidationClaimsExchange>
                </Action>
                <Action Id="VerifyCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                  </ValidationClaimsExchange>
                </Action>
              </Actions>
            </DisplayControl>
        </DisplayControls> 
    <!--</BuildingBlocks>-->

Vi har deklarerat en visningskontroll, emailVerificationControl. Notera följande viktiga delar:

DisplayClaims – Precis som i en självkontrollerad teknisk profil anger det här avsnittet en samling anspråk som ska samlas in från användaren i visningskontrollen.
Åtgärder – Anger ordningen på åtgärder som ska utföras av visningskontrollen. Varje åtgärd refererar till en teknisk profil som ansvarar för att utföra åtgärderna. Till exempel refererar SendCode till den AadSspr-SendCode tekniska profilen, som genererar och skickar en kod till en e-postadress.

Leta upp den ContosoCustomPolicy.XML UserInformationCollector självsäkra tekniska profilen i filen och ersätt e-postvisningsanspråket för att emailVerificationControl visa kontrollen:

Från:
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
Till:
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
Använd proceduren i steg 6 och steg 7 för att ladda upp principfilen och testa den. Den här gången måste du verifiera din e-postadress innan ett användarkonto skapas.

Uppdatera användarkontot med hjälp av teknisk profil för Microsoft Entra-ID

Du kan konfigurera en teknisk Profil för Microsoft Entra-ID för att uppdatera ett användarkonto i stället för att försöka skapa ett nytt. Om du vill göra det anger du den tekniska profilen för Microsoft Entra-ID så att det utlöser ett fel om det angivna användarkontot inte redan finns i Metadata samlingen med hjälp av följande kod. Åtgärden måste anges till Skriv:

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>

Använd anpassade attribut

I den här artikeln har du lärt dig hur du lagrar användarinformation med hjälp av inbyggda attribut för användarprofiler. Du behöver dock ofta skapa egna anpassade attribut för att hantera ditt specifika scenario. Det gör du genom att följa anvisningarna i artikeln Definiera anpassade attribut i Azure Active Directory B2C .

Nästa steg

Lär dig hur du konfigurerar ett registrerings- och inloggningsflöde för ett lokalt konto med hjälp av en anpassad princip för Azure Active Directory B2C.
Lär dig hur du definierar anpassade attribut i din anpassade princip.
Lär dig hur du lägger till förfallodatum för lösenord till en anpassad princip.
Läs mer om teknisk profil för Microsoft Entra ID.

Dela via