Hi --
sounds like you have long had the licensing feature turned on to allow the Entra AD groups, and that you normally expect that the first time the user logs in, it will match via a group and they will have access, inheriting the group's role. You indicate it is happening to all/any new user in all/any group.
i have a few questions:
1. In Entra, looking at the user, and at the sign-in log, do you see any indication of the attempt? If yes, then is there a failure or any useful info? If no, can you look at the whole sign-in log to see if there are attempts by a different user from who is expected?
2. In F&O can you add a new user using the Users > import users option...which would confirm/test that there are no issues querying the AD users or bringing them in manually.
3. If you try from a tier 2 or tier 1 environment, is it the same?
4. Does the Telemetry ID part look correct?
We used to rely on this, but we eventually moved away from it because of inconsistencies and limitations, usually related to the length of the group names or the resulting UserIDs, the impact of name changes, as well as the number of legal entities we have.
Instead, we still lean on the EntraAD groups for the users and roles, but we built a PowerAutomate to orchestrate the creation of new users, the association with the correct legal entity, and the assignment of roles. Well, we use 2 PowerAutomate Flows...one for users, one for roles. In the PowerAutomate (a LogicApp would also work), we do the following:
Users:
1. use the graph api to get the group - we have 1 group for "access" similar to the CE/power platform side, and then azure ad connector to get the members
2. use the f&o connector to list the existing enabled users
3. parse and compare
3.a. Some need to be created, we use the f&o connector to create a record in SystemUsers -- note, the f&o record limits the userid to 20 characters
3.b. Some need to be disabled, we use the f&o connector to disable
Roles:
Similar, but this time we have an EntraAD group per role
1. user the graph api to get the groups and the users in the groups
2. use the f&o connector to get the roles and the users with the role
3. parse and compare
3.a. add users to roles
3.b. drop users from roles
you can also use this concept to manage the native F&O group membership (which you can then use for credit pools or approval groups, etc), maintaining an EntraAD security group that maps to an F&O group and keeping them in sync with the Flow.
