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
Group teams
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.
Data
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.
Conclusion
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