Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Customer experience | Sales, Customer Insights,... / We switched from tenan...
Customer experience | Sales, Customer Insights,...
Answered

We switched from tenant users to Security Groups access and now face a few issues

(0) ShareShare
ReportReport
Posted on by Bas Wijdenes 10

Hi all,

Hopefully someone here can help me out here.

We made a change in Dynamics where we don't add everyone from our tenant anymore, but use a Security Group for access to Dynamics 365.

This works fine, but I'm now facing a few issues I hope are resolvable without too much custom scripting.

Onboarding:

- New accounts (added to the Security Group) are not automatically provisioned in CRM. We need to log on once with the account before we'll see the user in CRM. I can solve this with a Custom login script to log in once in CRM at the account creation, but is there no other way?

Offboarding:

- When someone leaves the company the accounts is Disabled in AzureAD. This causes the account to dissapear in CRM as well. Although the account still has the license etc. Shouldn't the account be in CRM but disabled?

I guess I'm looking for some information regarding how others deal with their onboarding and offboarding process with CRM.

  • Bas Wijdenes Profile Picture
    Bas Wijdenes 10 on at
    RE: We switched from tenant users to Security Groups access and now face a few issues

    Hey Daniel,

    Thanks, this clarifies a lot!

  • PerezAguiar Profile Picture
    PerezAguiar Microsoft Employee on at
    RE: We switched from tenant users to Security Groups access and now face a few issues

    Hey Bas.

    a) unfortunately, yes. Nested AAD Groups are not supported when this is used to restrict access on PowerPlatform Admin center.

    b) However, from the description you're doing, you seem to be using approach A (users won't show on the instance until they login the first time, despite they have the licenses assigned).

    You can verify this by going to your settings on the instnace and verifying the "all AAD security security group teams"
    pastedimage1605536893800v1.png

    If you have some results there, means that besides the SecGroup configured on instance level, you're synchronizing team membership from AAD Groups (for example, to assign roles to all members of a team).  If this is the case, what you're experiencing (Users not showing on Dynamics until they login the first time), is the standard behavior (they're added on runtime).

    Hope it helps.

  • Bas Wijdenes Profile Picture
    Bas Wijdenes 10 on at
    RE: We switched from tenant users to Security Groups access and now face a few issues

    Hi Daniel,

    I think we do have option two. When I go to the url provided in the documentation I see that our Security Group is configured there.

    What do you mean exactly, that this group can't have Nested AAD groups?

    EDIT: I also believe the Dynamics Engineer configured the group on this setting in Dynamics 365:

    News.mscrm-addons.com Blog | Using Office 365 Security Groups to (mscrm-addons.com)

    So that means we probably have both and should start using 2 only in stead? 

    Thank you for your answer by the way! I was starting to feel desperate.

  • Suggested answer
    PerezAguiar Profile Picture
    PerezAguiar Microsoft Employee on at
    RE: We switched from tenant users to Security Groups access and now face a few issues

    Hey Bas!

    There are two ways to use Security groups in a Dynamics instance.

    a) AAD Security Groups.  This seems to be your current approach. Unfortunately, that first login is required for the user to show up (Initial user Synchronization), either with a custom login script or with user typing username/Pwd, as described on cloudblogs.microsoft.com/.../

    b) use one security group to control access to Dynamics instance.  This allows to use only one security group at instance level, but it doesn't require the LoginScript as the initial synchronization is triggered immediately..  You can read more on https://docs.microsoft.com/en-us/power-platform/admin/control-user-access 

    Unfortunately, the first approach has that "initial login" requirement that can't be done any other way.

    Regarding your second point:  When you disable a user on AD, the license remain (this is documented). What I've seen is that if the user is disabled/Deleted, then the username changes to something like GUID_username@domain.com but this is on standard behavior, and you have a "Disabled users" or "disabled users using license" available on Dynamics.   Also remember that despite you remove the "Dynamics" license, user might still have a Common Data Service app license (from O365 A1/13/15 or Microsoft365 Enterprise/Standard license) that still allow access to the CDS database.

    Best regards,

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Ramesh Kumar – Community Spotlight

We are honored to recognize Ramesh Kumar as our July 2025 Community…

Congratulations to the June Top 10 Community Leaders!

These are the community rock stars!

Announcing the Engage with the Community forum!

This forum is your space to connect, share, and grow!

Leaderboard > Customer experience | Sales, Customer Insights, CRM

#1
Holly Huffman Profile Picture

Holly Huffman 103

#2
Muhammad Shahzad Shafique Profile Picture

Muhammad Shahzad Sh... 96 Most Valuable Professional

#3
Gerardo Rentería García Profile Picture

Gerardo Rentería Ga... 51 Most Valuable Professional

Last month Overall leaderboard

Featured topics

Hide selecting Contact for potential customer when creating quote

Product updates

Dynamics 365 release plans