Creare e leggere un account utente usando criteri personalizzati di Azure Active Directory B2C
Azure Active Directory B2C (Azure AD B2C) è basato sull'ID Microsoft Entra e quindi usa l'archiviazione id Microsoft Entra per archiviare gli account utente. Il profilo utente della directory di Azure AD B2C include un set predefinito di attributi, ad esempio nome, cognome, città, codice postale e numero di telefono, ma è possibile estendere il profilo utente con attributi personalizzati senza richiedere un archivio dati esterno.
I criteri personalizzati possono connettersi all'archiviazione microsoft Entra ID usando il profilo tecnico Microsoft Entra ID per archiviare, aggiornare o eliminare le informazioni utente. Questo articolo illustra come configurare un set di profili tecnici di Microsoft Entra ID per archiviare e leggere un account utente prima che venga restituito un token JWT.
Panoramica dello scenario
In Chiamare un'API REST usando l'articolo criteri personalizzati di Azure Active Directory B2C vengono raccolte informazioni dall'utente, convalidati i dati, denominata API REST e infine restituito un token JWT senza archiviare un account utente. È necessario archiviare le informazioni utente in modo da non perdere le informazioni al termine dell'esecuzione del criterio. Questa volta, dopo aver raccolto le informazioni utente e convalidarlo, è necessario archiviare le informazioni utente nell'archiviazione di Azure AD B2C e quindi leggere prima di restituire il token JWT. Il processo completo è illustrato nel diagramma seguente.
Prerequisiti
In assenza di un tenant, creare un tenant di Azure AD B2C collegato alla sottoscrizione di Azure.
Registrare un'applicazione Web e abilitare la concessione implicita del token ID. Per l'URI di reindirizzamento, usare https://jwt.ms.
Nel computer deve essere installato Visual Studio Code (VS Code ).
Completare i passaggi descritti in Chiamare un'API REST usando i criteri personalizzati di Azure Active Directory B2C. Questo articolo fa parte della serie di procedure per creare ed eseguire criteri personalizzati.
Nota
Questo articolo fa parte della serie di procedure Creare ed eseguire criteri personalizzati in Azure Active Directory B2C. È consigliabile iniziare questa serie dal primo articolo.
Passaggio 1- Dichiarare attestazioni
È necessario dichiarare altre due attestazioni, userPrincipalName
e passwordPolicies
:
ContosoCustomPolicy.XML
Nel file individuare l'elemento ClaimsSchema e dichiarareuserPrincipalName
epasswordPolicies
le attestazioni usando il codice seguente:<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>
Altre informazioni sugli usi delle attestazioni e
passwordPolicies
nell'articolouserPrincipalName
Attributi del profilo utente.
Passaggio 2 - Creare profili tecnici di Microsoft Entra ID
È necessario configurare due profili tecnici microsoft Entra ID. Un profilo tecnico scrive i dettagli dell'utente nell'archiviazione di Microsoft Entra ID e l'altro legge un account utente dall'archiviazione microsoft Entra ID.
ContosoCustomPolicy.XML
Nel file individuare l'elemento ClaimsProviders e aggiungere un nuovo provider di attestazioni usando il codice seguente. Questo provider di attestazioni contiene i profili tecnici di Microsoft Entra ID:<ClaimsProvider> <DisplayName>Azure AD Technical Profiles</DisplayName> <TechnicalProfiles> <!--You'll add you Azure AD Technical Profiles here--> </TechnicalProfiles> </ClaimsProvider>
Nel provider di attestazioni appena creato aggiungere un profilo tecnico Microsoft Entra ID usando il codice seguente:
<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>
È stato aggiunto un nuovo profilo tecnico Microsoft Entra ID,
AAD-UserWrite
. È necessario prendere nota delle parti importanti seguenti del profilo tecnico:Operazione: l'operazione specifica l'azione da eseguire, in questo caso Write. Altre informazioni sulle altre operazioni in un provider tecnico Microsoft Entra ID.
Attestazioni persistenti: l'elemento PersistedClaims contiene tutti i valori che devono essere archiviati nell'archiviazione di Microsoft Entra ID.
InputClaims: l'elemento InputClaims contiene un'attestazione, che viene usata per cercare un account nella directory o crearne uno nuovo. Nella raccolta di attestazioni di input deve essere presente esattamente un elemento attestazione di input per tutti i profili tecnici di Microsoft Entra ID. Questo profilo tecnico usa l'attestazione di posta elettronica , come identificatore della chiave per l'account utente. Altre informazioni sugli altri identificatori di chiave che è possibile usare identificano in modo univoco un account utente.
ContosoCustomPolicy.XML
Nel file individuare ilAAD-UserWrite
profilo tecnico e quindi aggiungere un nuovo profilo tecnico dopo di esso usando il codice seguente:<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>
È stato aggiunto un nuovo profilo tecnico Microsoft Entra ID,
AAD-UserRead
. Questo profilo tecnico è stato configurato per eseguire un'operazione di lettura e per restituireobjectId
attestazioni ,userPrincipalName
,givenName
,surname
edisplayName
se viene trovato un account utente con nellaemail
InputClaim
sezione .
Passaggio 3 - Usare il profilo tecnico Microsoft Entra ID
Dopo aver raccolto i dettagli dell'utente usando il UserInformationCollector
profilo tecnico autocertizionato, è necessario scrivere un account utente nell'archiviazione di Microsoft Entra ID usando il AAD-UserWrite
profilo tecnico. A tale scopo, usare il AAD-UserWrite
profilo tecnico come profilo tecnico di convalida nel UserInformationCollector
profilo tecnico autocertificato.
ContosoCustomPolicy.XML
Nel file individuare il profilo tecnico e quindi aggiungere AAD-UserWrite
il UserInformationCollector
profilo tecnico come profilo tecnico di convalida nella ValidationTechnicalProfiles
raccolta. È necessario aggiungerlo dopo il profilo tecnico di CheckCompanyDomain
convalida.
Si userà il AAD-UserRead
profilo tecnico nei passaggi di orchestrazione del percorso utente per leggere i dettagli dell'utente prima di emettere un token JWT.
Passaggio 4- Aggiornare il profilo tecnico ClaimGenerator
Usiamo il ClaimGenerator
profilo tecnico per eseguire tre trasformazioni di attestazioni, GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation e CreateMessageTransformation.
ContosoCustomPolicy.XML
Nel file individuare ilClaimGenerator
profilo tecnico e sostituirlo con il codice seguente:<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>
Il profilo tecnico è stato suddiviso in due profili tecnici distinti. Il profilo tecnico UserInputMessageClaimGenerator genera il messaggio inviato come attestazione nel token JWT. Il profilo tecnico UserInputDisplayNameGenerator genera l'attestazione
displayName
. IldisplayName
valore dell'attestazione deve essere disponibile prima che ilAAD-UserWrite
profilo tecnico scriva il record utente nella risorsa di archiviazione microsoft Entra ID. Nel nuovo codice viene rimosso GenerateRandomObjectIdTransformation man manoobjectId
che viene creato e restituito dall'ID Di Microsoft Entra dopo la creazione di un account, quindi non è necessario generarlo all'interno dei criteri.ContosoCustomPolicy.XML
Nel file individuare ilUserInformationCollector
profilo tecnico autocertificato e quindi aggiungere ilUserInputDisplayNameGenerator
profilo tecnico come profilo tecnico di convalida. A questo scopo, laUserInformationCollector
raccolta delValidationTechnicalProfiles
profilo tecnico dovrebbe essere simile al codice seguente:<!--<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>-->
È necessario aggiungere il profilo tecnico di convalida prima
AAD-UserWrite
che ildisplayName
valore dell'attestazione sia disponibile prima che ilAAD-UserWrite
profilo tecnico scriva il record utente nell'archiviazione microsoft Entra ID.
Passaggio 5: Aggiornare i passaggi di orchestrazione del percorso utente
Individuare il HelloWorldJourney
percorso utente e sostituire tutti i passaggi di orchestrazione con il codice seguente:
<!--<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>-->
Nel passaggio 4
di orchestrazione viene eseguito il AAD-UserRead
profilo tecnico per leggere i dettagli utente (da includere nel token JWT) dall'account utente creato.
Poiché l'attestazione message
non viene archiviata, nel passaggio 5
di orchestrazione viene eseguito per UserInputMessageClaimGenerator
generare l'attestazione per l'inclusione message
nel token JWT.
Passaggio 6 - Caricare i criteri
Seguire la procedura descritta in Caricare un file di criteri personalizzato per caricare il file dei criteri. Se si carica un file con lo stesso nome di quello già presente nel portale, assicurarsi di selezionare Sovrascrivi il criterio personalizzato, se già esistente.
Passaggio 7 - Testare i criteri
Seguire la procedura descritta in Testare i criteri personalizzati per testare i criteri personalizzati.
Al termine dell'esecuzione del criterio e si riceve il token ID, verificare che il record utente sia stato creato:
Accedere al portale di Azure con autorizzazioni di Amministrazione istrator globale o ruolo con privilegi Amministrazione istrator.
Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant di Azure AD B2C dal menu Directory e sottoscrizioni.
In Servizi di Azure selezionare Azure AD B2C. In alternativa, usare la casella di ricerca per trovare e selezionare Azure AD B2C.
In Gestisci, seleziona Utenti.
Individuare l'account utente appena creato e selezionarlo. Il profilo dell'account è simile allo screenshot seguente:
AAD-UserWrite
Nel profilo tecnico Microsoft Entra ID viene specificato che, se l'utente esiste già, viene generato un messaggio di errore.
Testare di nuovo i criteri personalizzati usando lo stesso indirizzo di posta elettronica. Anziché i criteri eseguiti al completamento per rilasciare un token ID, verrà visualizzato un messaggio di errore simile allo screenshot seguente.
Nota
Il valore dell'attestazione della password è un'informazione molto importante, quindi prestare molta attenzione a come gestirlo nei criteri personalizzati. Per un motivo simile, Azure AD B2C considera il valore dell'attestazione della password come valore speciale. Quando si raccoglie il valore dell'attestazione password nel profilo tecnico autocertizionato, tale valore è disponibile solo all'interno dello stesso profilo tecnico o all'interno di profili tecnici di convalida a cui fa riferimento lo stesso profilo tecnico autocertificato. Una volta completata l'esecuzione del profilo tecnico autocertifiato e si passa a un altro profilo tecnico, il valore viene perso.
Verificare l'indirizzo di posta elettronica dell'utente
È consigliabile verificare l'indirizzo di posta elettronica di un utente prima di usarlo per creare un account utente. Quando si verificano gli indirizzi di posta elettronica, assicurarsi che gli account vengano creati da utenti reali. È anche possibile aiutare gli utenti a assicurarsi che usino gli indirizzi di posta elettronica corretti per creare un account.
I criteri personalizzati di Azure AD B2C consentono di verificare l'indirizzo di posta elettronica usando il controllo di visualizzazione della verifica. Si invia un codice di verifica al messaggio di posta elettronica. Dopo l'invio del codice, l'utente legge il messaggio, immette il codice di verifica nel controllo fornito dal controllo visualizzato e seleziona il pulsante Verifica codice .
Un controllo display è un elemento dell'interfaccia utente con funzionalità speciali e interagisce con il servizio back-end di Azure Active Directory B2C (Azure AD B2C). Consente all'utente di eseguire azioni nella pagina che richiamano un profilo tecnico di convalida al back-end. I controlli di visualizzazione vengono visualizzati nella pagina e fanno riferimento a un profilo tecnico autocertificato.
Per aggiungere la verifica tramite posta elettronica tramite un controllo di visualizzazione, seguire questa procedura:
Dichiarare l'attestazione
È necessario dichiarare un'attestazione da usare per contenere il codice di verifica.
Per dichiarare l'attestazione, nel ContosoCustomPolicy.XML
file individuare l'elemento e dichiarare verificationCode
l'attestazione ClaimsSchema
usando il codice seguente:
<!--<ClaimsSchema>-->
...
<ClaimType Id="verificationCode">
<DisplayName>Verification Code</DisplayName>
<DataType>string</DataType>
<UserHelpText>Enter your verification code</UserHelpText>
<UserInputType>TextBox</UserInputType>
</ClaimType>
<!--</ClaimsSchema>-->
Configurare un profilo tecnico di invio e verifica del codice
Azure AD B2C usa il profilo tecnico SSPR microsoft Entra ID per verificare un indirizzo di posta elettronica. Questo profilo tecnico può generare e inviare un codice a un indirizzo di posta elettronica o verifica il codice a seconda della modalità di configurazione.
ContosoCustomPolicy.XML
Nel file individuare l'elemento ClaimsProviders
e aggiungere il provider di attestazioni usando il codice seguente:
<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>
Sono stati configurati due profili AadSspr-SendCode
tecnici e AadSspr-VerifyCode
. AadSspr-SendCode
genera e invia un codice all'indirizzo di posta elettronica specificato nella InputClaims
sezione , mentre AadSspr-VerifyCode
verifica il codice. Specificare l'azione da eseguire nei metadati del profilo tecnico.
Configurare un controllo di visualizzazione
È necessario configurare un controllo di visualizzazione della verifica della posta elettronica per poter verificare l'indirizzo di posta elettronica degli utenti. Il controllo di visualizzazione della verifica della posta elettronica configurato sostituirà l'attestazione di visualizzazione del messaggio di posta elettronica usata per raccogliere un messaggio di posta elettronica dall'utente.
Per configurare un controllo di visualizzazione, seguire questa procedura:
ContosoCustomPolicy.XML
Nel file individuare laBuildingBlocks
sezione e quindi aggiungere un controllo di visualizzazione come elemento figlio usando il codice seguente:<!--<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>-->
È stato dichiarato un controllo di visualizzazione,
emailVerificationControl
. Prendere nota delle parti importanti seguenti:DisplayClaims : proprio come in un profilo tecnico autocertilato, questa sezione specifica una raccolta di attestazioni da raccogliere dall'utente all'interno del controllo di visualizzazione.
Azioni : specifica l'ordine delle azioni da eseguire dal controllo di visualizzazione. Ogni azione fa riferimento a un profilo tecnico responsabile dell'esecuzione delle azioni. Ad esempio, SendCode fa riferimento al
AadSspr-SendCode
profilo tecnico, che genera e invia un codice a un indirizzo di posta elettronica.
ContosoCustomPolicy.XML
Nel file individuare ilUserInformationCollector
profilo tecnico autocertificato e sostituire l'attestazione di visualizzazione del messaggio di posta elettronica peremailVerificationControl
visualizzare il controllo:Da:
<DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
Con:
<DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
Usare la procedura descritta nel passaggio 6 e nel passaggio 7 per caricare il file dei criteri e testarlo. Questa volta, è necessario verificare l'indirizzo di posta elettronica prima che venga creato un account utente.
Aggiornare l'account utente usando il profilo tecnico Microsoft Entra ID
È possibile configurare un profilo tecnico di Microsoft Entra ID per aggiornare un account utente anziché tentare di crearne uno nuovo. A tale scopo, impostare il profilo tecnico Microsoft Entra ID per generare un errore se l'account utente specificato non esiste già nella Metadata
raccolta usando il codice seguente. L'operazione deve essere impostata su Scrittura:
<Item Key="Operation">Write</Item>
<Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
Usare gli attributi personalizzati
In questo articolo si è appreso come archiviare i dettagli utente usando gli attributi predefiniti del profilo utente. Tuttavia, spesso è necessario creare attributi personalizzati per gestire lo scenario specifico. A tale scopo, seguire le istruzioni riportate nell'articolo Definire attributi personalizzati in Azure Active Directory B2C .
Passaggi successivi
Informazioni su come configurare un flusso di iscrizione e accesso per un account locale usando i criteri personalizzati di Azure Active Directory B2C.
Informazioni su come definire attributi personalizzati nei criteri personalizzati.
Informazioni su come aggiungere la scadenza della password ai criteri personalizzati.
Altre informazioni sul profilo tecnico microsoft Entra ID.