Attribute-based application provisioning in Azure AD and scoping filters

Angel Castillo 31 Reputation points
2020-08-27T21:38:00.807+00:00

I'm using Azure AD provisioning for Dropbox and it works fine with the exception of those users that have multiple proxy addresses where the primary domain email address isn't being used. Instead they are using a secondary address as their primary from one of our alias domains that we manage.

An example would be a better way to explain this:

Username: jdoe
Primary domain is domain1.com
Alias domain is domain2.com

In Active Directory when creating a user our primary domain is used by default. We also have users using our alias domain as their primary SMTP email address in AD. When you look at their proxyAddresses attribute in AD you see:

SMTP:jdoe@domain2.com
smtp:jdoe@domain1.com

We've used Dropbox before, so username jdoe already has an account that uses jdoe@domain2.com but now that I'm using Azure AD for provisioning to Dropbox it imported their account as jdoe@domain1.com because it's going by what our primary default domain is.

I'm looking for a way where I can use scoping filters or editing existing mapping attributes to where an existing user like jdoe doesn't get a second account imported by provisioning when he's already in Dropbox as a member using our alias domain

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,442 questions
0 comments No comments
{count} votes

5 answers

Sort by: Most helpful
  1. Bhanot Ravi 31 Reputation points
    2020-08-27T22:22:06.367+00:00

    Hi AngelCastillo,

    You can use Scope Filters where in you can have a condition "Only provision Users which have UserPrincipalName ending with @domain1.com". I believe that would not provision users with UPN which ends with @domain2.com.

    21003-scope-filter.jpg

    Try in your development subscription, it may resolve your issue of duplicate account being provisioned.

    Do let us know if this have resolved your issue or not and don't forget to mark it as Answer to help others.

    Thanks,Ravi


  2. Bhanot Ravi 31 Reputation points
    2020-09-01T03:47:53.777+00:00

    Hi AngelCastillo ,

    Other way around to address your query is to use Active Directory Group based scoping. You can define a Security group or dynamic security group with all members for whom user ID provisioning is required and then provisioning scope is set to "Sync only assigned users and groups". With this, the Azure AD provisioning service will provision or de-provision users based on whether they're members of a group that's assigned to the application.

    User's who are already present in Dropbox application, you can exclude those from group membership and with that, no new User ID will be provisioned for those users and they will stay intact in the application. For all new ones, they will follow the path of group based assignement.

    Hope this will help.

    Thanks,
    Ravi

    0 comments No comments

  3. Bhanot Ravi 31 Reputation points
    2020-09-03T03:35:04.467+00:00

    Hi AngelCastillo ,

    Did you try the above solution, please post and if it has helped you in the solution, please do mark it as an answer.

    Thanks,
    Ravi


  4. Bhanot Ravi 31 Reputation points
    2020-09-03T14:11:06.463+00:00

    Thanks AngelCastillo, do inform whatever the outcome is as this will help the community.

    Thanks,
    Ravi

    0 comments No comments

  5. Angel Castillo 31 Reputation points
    2020-09-08T14:54:14.57+00:00

    I worked with Microsoft Azure support and using a custom mapping attribute helped with preventing the provisioning as I wanted but overall didn't stop the provisioning to happen after each cycle runs leaving pending invites for these existing accounts still being generated.

    But it was also determined by our department management team that to avoid complexity of this scenario all users would use our default domain for enterprise applications that are being provisioned and enabled for SSO via Azure AD.

    This prevents us having to come up with a custom solution to get around this, so we will move forward with this as our process moving forward.

    0 comments No comments