Blog Post

Microsoft Entra Blog
3 MIN READ

Dynamic automated access with Azure AD entitlement management

Joseph Dadzie's avatar
Joseph Dadzie
Icon for Microsoft rankMicrosoft
Aug 29, 2022

We continue to enhance Azure Active Directory (Azure AD) Identity Governance to help you meet security needs and preserve employee productivity at scale. Recent enhancements include the introduction of multi-stage access reviews and custom workflows in entitlement management using Azure Logic Apps 

 

Based on your feedback, we’ve made it even easier for you to automate your processes for access lifecycle management with a new preview of automatic assignment policies in entitlement management. In this preview, Azure AD adds and removes users’ access across groups, Teams, SharePoint sites, and apps as their attributes change (such as when someone joins, moves between departments, or goes on leave). The inclusion of this policy in an access package simplifies managing at scale; users don’t need to make requests, which not only ensures their access doesn’t remain longer than necessary, but also does so without the need for administrative interaction when someone moves teams. 

 

Assigning access based on attributes 

Building on the example in the previous blog post, suppose Contoso uses Salesforce and that the Sales team has an access package in Azure AD entitlement management. The package enables members of the Sales team and their colleagues to access relevant resources, including SharePoint sites, and provisions their access into Salesforce. 

 

Such an access package may include two policies for employees and guests to request access:  

  • Employees can request access and, if approved, have access, which is reviewed every 90 days. 
  • Non-employees, such as external sales reps, can also request access and, if approved, have access, which is reviewed every 60 days. 

Now they can add a third policy using the preview of auto-assignment policies.

  • Employees in the Sales department, based on users’ “department” attribute, have access automatically, so long as they’re in the department. 

 

 

 

In this policy, you specify a rule for how entitlement management will select the users who need assignments. The rule is based on the attributes of the user, such as department, that typically come from your organization’s HR system, where many people with the same value of the attribute need the same access.  

 

If you’ve used Azure AD dynamic groups before, this concept will be familiar. Soon after the policy is created, Azure AD will automatically begin creating resource assignments for those users who meet the rule. Based on the properties of new users provided by the HR system, employees moving into Sales will receive access automatically, without the need to request. 

 

 

 

In addition to what you can do with dynamic groups, you can also use entitlement management with automatic assignment policies for: 

  • Managing access across multiple resources, including applications, SharePoint Online sites, existing Azure AD groups and Teams, and groups that are provisioned to on-premises AD.
  • Managing access with a combination of policies to have both rules (e.g., everyone in a department) and exceptions (e.g., people in other departments who will need the same access) so that the exceptions can be regularly reviewed and removed, if no longer needed 
  • Further automating tasks across Microsoft and third-party applications through entitlement management’s custom extensions, which run workflows when users receive or lose assignments. 

 

These are just a couple scenarios for how you can now address even more use cases with entitlement management by automating some of the assignments. We encourage you to try it out by adding an automatic assignment policy to an access package and to let us know what you think. For more information on how to create an automatic assignment policy through the portal or Graph API, please view the documentation.   

 

We want to hear from you! Feel free to leave comments down below with ideas for the next topic or add other product suggestions at the feedback forum.   

 

 

Learn more about Microsoft identity: 

Updated Aug 26, 2022
Version 1.0
  • Some very cool stuff. A couple of questions if I may:

     

    How does this impact group write back in a multi AD forest to singe tenant scenario? If I have auto assignment policies for access packages where the members of the dynamic group are from different forests what happens when that group is written back on prem AD DS. I understand that these groups are written back as Universal Groups so you will you be able to use them across forest boundaries following the Kerberos forest trusts?  This is based on the idea that they can only be written back to one specific OU via AADConnect correct?

     

    And of course there is a massive dependency on the quality of your data.. 

  • Richard Adams's avatar
    Richard Adams
    Copper Contributor

    Would be interested to know when dynamic membership based on membership of an on-prem OU will be available and GA? I know there are workarounds you can implement  using extension attributes, but why isn't this already built in? Hybrid is going to be around for a very long time yet!

  • Richard Adams 

     

    The DN of the user is actually synched into Azure AD in the extensionproperty attribute which is a hashtable I think. It's the same attrbute that custom schame extension in AAD sit. 

     

    The last time I tried you unfortunately couldn't use it actually populate a dynamic group.. but the value is definitely there..