Azure active directory limit registration according to an email address pool or pre register account

Question 1

In azure active-directory B2C, is there a way to limit registration according to an email address pool? Or can i pre register account, then user would have to choose password or use google or facebook account?

Question 2

There is no built-in mechanism in Azure AD B2C to limit registration to a specific set of users / emails. You can request this via the Azure AD B2C feedback forum.

However, you can implement this yourself by:

Having a custom attribute to determine whether a user is "approved" or not. You would let users sign up by themselves and you would create an experience or flow that queries the Azure AD Graph for users that haven't been "approved" and then either approve them or delete them.
Building an invitation flow. When you invite a user, you'd create the user through the Azure AD Graph. You would then direct your users to the Password Reset policy as their "account verification" flow. This only works for local accounts as you can't pre-create users backed by social-accounts.

This is similar to Azure AD B2C - approval upon sign up?

Question 3

Following describes how you can save, load, and then issue the otherMails claim as emails from the sign-up/sign-in and password reset policies.

When writing a local account: You must create the otherMails claim from the email claim using the CreateOtherMailsFromEmail claims transformation and then persist the otherMails claim in the AAD-UserWriteUsingLogonEmail technical profile:

<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
  ...
  <IncludeInSso>false</IncludeInSso>
  <InputClaimsTransformations>
    <InputClaimsTransformation ReferenceId="CreateOtherMailsFromEmail" />
  </InputClaimsTransformations>
  <InputClaims>
    ...
  </InputClaims>
  <PersistedClaims>
    ...
    <PersistedClaim ClaimTypeReferenceId="otherMails" />
  </PersistedClaims>
  <OutputClaims>
    ...
    <OutputClaim ClaimTypeReferenceId="otherMails" />
  </OutputClaims>
  ...
</TechnicalProfile>

You must then pass the otherMails claim out from the LocalAccountSignUpWithLogonEmail technical profile that is invoked to register a local account:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
    ...
    <OutputClaims>
        ...
        <OutputClaim ClaimTypeReferenceId="otherMails" />
    </OutputClaims>
</TechnicalProfile>

When writing a social account: The otherMails claim is already created from the email claim and then persisted in the AAD-UserWriteUsingAlternativeSecurityId technical profile.

You must then pass the otherMails claim out from the SelfAsserted-Social technical profile that is invoked to register a social account:

<TechnicalProfile Id="SelfAsserted-Social">
    ...
    <OutputClaims>
        ...
        <OutputClaim ClaimTypeReferenceId="otherMails" />
    </OutputClaims>
</TechnicalProfile>

When reading a local or social account: The otherMails claim is already read in the AAD-UserReadUsingObjectId, AAD-UserReadUsingEmailAddress, and AAD-UserReadUsingAlternativeSecurityId technical profiles.

You must then pass the otherMails claim out from the LocalAccountDiscoveryUsingEmailAddress technical profile that is invoked to recover a local password:

<TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
    ...
    <OutputClaims>
        ...
        <OutputClaim ClaimTypeReferenceId="otherMails" />
    </OutputClaims>
</TechnicalProfile>

To issue the otherMails claim as emails from the sign-up/sign-in and password reset policies: You must add the otherMails claim as <OutputClaim /> to the relying party policies:

<RelyingParty>
    ...
    <TechnicalProfile Id="PolicyProfile">
        <OutputClaims>
            ...
            <OutputClaim ClaimTypeReferenceId="otherMails" PartnerClaimType="emails" />
        </OutputClaims>
    </TechnicalProfile>
</RelyingParty>

Question 4

You missed out configuring the policy for extension attribute support. https://docs.microsoft.com/en-us/azure/active-directory-b2c/user-flow-custom-attributes?pivots=b2c-custom-policy#azure-ad-b2c-extensions-app

This entire process can be automated with my tool: https://aka.ms/iefsetup before starting to use the samples.

Question 5

Prerequisites

Check if you have the proper permissions to get the object id from a Service Principal
Check if you have the proper permissions to add the Service Principal to the "Directory Readers" role in the Azure Active Directory tenant (-> Admin)

Steps

Install the Azure AD Module via Install-Module AzureAD [1]
Connect to the Azure Active Directory
- Connect-AzureAD
Get the Id of the "Directory Readers" role
- $roleId = (Get-AzureADDirectoryRole | where-object {$_.DisplayName -eq "Directory Readers"}).Objectid
Get the Service Principal Object ID
- $spObjectId = (Get-AzureADServicePrincipal -SearchString "spName").ObjectId
  - This of course only works if the result includes only one ObjectId
  - This is not the ObjectId of the application registered in the Azure Active Directory
Add service principal to the "Directory Readers" role
- Add-AzureADDirectoryRoleMember -ObjectId $roleId -RefObjectId $spObjectId
Check if SP is assigned to the Directory Readers role
- Get-AzureADDirectoryRoleMember -ObjectId $roleId | Where-Object {$_.ObjectId -eq $spObjectId}
If you want to remove the Service Principal from the role at a later stage
- Remove-AzureADDirectoryRoleMember -ObjectId $roleId -MemberId $spObjectId

Resources

[1] Install Azure AD Module

[2] Using a Service Principal to connect to a directory in PowerShell

Question 6

Sorry for the late response. The following code worked for me. Not sure if you need to use the IUserFetcher interface, but your LINQ query fails because you are comparing the objectID of the assignment, with the appRole Id. What you need to compare is the ID of the assignment.

var userFetcher = user as IUserFetcher;
IPagedCollection<IAppRoleAssignment> rawObjects = userFetcher.AppRoleAssignments.ExecuteAsync().Result;

IList<IAppRoleAssignment> assignments = rawObjects.CurrentPage.ToList();
IAppRoleAssignment a = null;
a = assignments.Where(ara => ara.Id.Equals(appRole.Id)).First();
if (a != null) {
    Console.WriteLine("Found assignment {0} for user {1}", appRole.Id, user.DisplayName);
}

Hope this helps...

Azure active directory limit registration according to an email address pool or pre register account

Answers

Prerequisites

Steps

Resources

azure-ad-b2c