Applies to Dynamics 365 apps version 9.x and common Data Service
This is the first part of how Azure AD groups can be used to administer user access, originally written by Varun Katyal – HSD Dynamics 365 Technical Architect .
As the Office 365 world is expanding and more customers are moving their solutions into the cloud, there has been a greater need for administrators to be able to manage and provision users from a central location and as a group rather than individually.
The good news is that administrators can use their Azure Active Directory (Azure AD) groups to manage access rights for licensed Customer Engagement and Common Data Service users. The not so good news is that this has been around for a while yet we are only talking about this now.
Both Office as well as Security Azure AD groups can be used to provide access to users. The administrators can assign security roles to all members of the group instead of having to do it for each individual member.
Administrators can create Azure AD group teams in Dynamics and Common Data Service environments and assign relevant security roles to these teams. The members that are then added to the Azure AD group will automatically inherit access rights based on the group team’s security role when trying to access these environments.
Adding/Removing User access
Once the Azure AD group and the group team has been created, administrators only need to add the user to the Azure AD group and assign an appropriate Dynamics and Common Data Service licence. The user can then immediately log in to the environment which will provide access dynamically at run time.
When a user is either disabled/ deleted from Azure AD or removed from the Azure AD group, they lose the group membership and hence, their access rights to the environment.
Let us run through a step by step process to achieve this.
1 You can create a new Azure AD group by logging on to https://portal.azure.com, selecting the Active Directory for the CRM instance and navigating to ‘Groups’ from the left navigation
2 Select the group type as either Security or Microsoft 365 (we will choose the ‘Security’) and provide a Group name and description. Add members to this group (you can do this later as well)
3 Once the group is created, you can find the Object ID for this group as highlighted below. Take a note of this as it will be used to connect the Azure AD group to group team in Dynamics and Common Data Service environments.
4 Now let’s create the team in Dynamics by navigating to Settings -> Security -> Teams.
Create a new team and select the ‘Team Type’ as AAD Security Group and copy the Object ID from the previous step in the ‘Azure AD Object Id for a group’ field as below.
On save of the record, Dynamics will validate the Object ID and throw an error if it’s invalid. Members can only be added to this team through the Azure AD group. As you may notice Dynamics does not allow you to add members from the team record since there is no ‘add member’ or ‘+’ command.
5 After the team has been created, the next step is to assign a security role to this team. The team members will not yet be visible as they get access dynamically during runtime so when they try to login, they should have access and after that the Dynamics team record will show the member as well.
Now that members have been provided access through Azure AD group membership, they still don’t have a security role at a User level which means they can only own records as their Team but not as themselves which will then require administrators to assign individual security roles to the user.
In the next part of this blog, we will discuss how this issue can be resolved so that users can still own records when they are provided access through Azure AD groups.