Dynamics 365 has some security features which integrate Dynamics 365 with AD Groups. AD Groups can be used to grant and restrict access to a Dynamics 365 environment and with AAD security teams you can automatically add users to teams.
I hate doing manual tasks (Dynamics 365 — The cost of manual deployments activities) and if it can be automated it should, so AAD security teams offer a great way to automate adding users and giving them security roles.
This blog post will discuss both security groups and AAD security teams.
Microsoft Documentation — Control user access to environments: security groups and licenses
AD security group
The first AD security group I recommend to setup is a group which grants people access to an environment. Microsoft cover it here
You create an AD group and then you go to Power Platform Admin and navigate to environments where you will see all environments you have access to.
If you add AD group in the security group setting, this allows users to access or see the Dynamics 365 environment if they are added to that group. This is an easy way to control which users can access different environments.
It acts as a layer before security roles and stops accidently giving access to users. For projects its common for developers and consultants to have access to most of the Dynamics 365 environments accept Preproduction and Production.
Microsoft documentation — Control user access to environments: security groups and licenses
Dynamics 365 lets you create a few different types of team
- Owner teams
- Access Teams
- Group teams
Owner teams are the classic team in Dynamics and works like a user, they can own records and have security roles.
Access teams allow record access and give people access to a particular record, e.g. sales people working on an opportunity
Groups teams are different because they link an AD Group to a team in Dynamics 365 AAD team. AD groups can be of type office or security. The office AD group can be created with users with less privileges and as a way to create groups of users.
An AD security group will need an IT person to create them.
Both Azure AD groups will have an Azure AD Object Id for the group and we link that to a team in Dynamics by putting that guid in azureactivedirectoryobjectidazureactivedirectoryobjectid field
You can create these in Dynamics by creating a new team and selecting the AAD Security type or AAD Group type.
A few things to note
- You have to put Azure AD object ID on creation of the team
- It will validate the it’s a valid guid
- You cannot change this guid after creation
This page describes how group teams and owner teams work in Dynamics
The picture below shows how AD Groups work
The security gives access to the environment
The team AD group automatically adds a user. In the example above, you add a user into the Sales Manager AD team and it will automatically add that user to the Sales Manager team in Dynamics (as long as you have created the team and put in the correct Azure AD Object ID)
If you assign the team a security role then you don’t have to do any manual setup of the users for security roles or field level security.
The diagram below show it without AD groups linked with teams.
Each AD group can only work with an Dynamics team in one Dynamics instance.
You can keep the guids the same but you need to change the AzureID field
Why aren’t people in the Dynamics groups?
I setup up my teams, put in the correct Azure AD Object Id for a group. The user was added to the correct group and then………nothing.
Where was the user? why wasn’t the user appearing in my team?
In the Microsoft documentation
The list of team members listed in each group team only displays the user members who have accessed the environment. This list doesn’t show all the group members of the Azure AD group. The team member’s privileges are derived dynamically at run-time when the team member accesses the application. The security role of the team is not assigned directly to the team member. Since team member’s privileges are derived dynamically at run-time, the team member’s Azure AD group memberships are cached upon the team member’s log-in. This means that any Azure AD group membership maintenance done on the team member in Azure AD will not be reflected until the next time the team member logs in or when the system refreshes the cache (after 8 hours of continuous log-in).
The members show in the team in Dynamics 365 only when users have accessed Dynamics 365 (logged in). If the user in the AD Group hasn’t logged in then they won’t show in the team members in Dynamics.
Other potential gotcha’s from Microsoft documentation
You can only create one group team for each Azure AD group per environment, and the Azure AD ObjectId of the group team cannot be edited once the group team is created.
Team members are maintained in each group team at run-time and the operation is done at the database level; therefore, the update to group team event is not available for plugin.
If you have a release pipeline, you can keep the GUIDs of the AAD security group team the same but you have change the Azure AD Object ID to the AD group.
It’s worth doing because you will have the teams with the same guids in each environment.
AD groups can be an effective way to add security and simplify adding users to a Dynamics 365 environment.
I think all Dynamics 365 environment should have a security group, it stops accidently enabling users to environments.
AAD security groups are good if you have distinct security roles with no cross over. If you can do it, it will save time adding users and is worth looking into to.
picture from here