As a part of Feature Management for BC22, Microsoft introduced the feature: Control Access to Business Central Using Security Groups.
The feature consists of two parts:
- Azure Active Directory Security Groups
- Deprecation of User Groups and introduction to Composable permission sets
Azure Active Directory Security Groups
For the Azure Active Directory Security Groups there are a number of sources that will clarify how this is set up:
But basically, the new Security Groups can be linked to an Azure Security Group. Then a number of permission sets can be assigned to the Security Groups. The overview can look like this:
The cloud always supports Azure Active Directory but also in on-premise service tiers set up with Azure Active Directory, the security groups can be linked to any Azure Active Directory Security Group as described in above link: Control Access to Business Central Using Security Groups.
Then each user is assigned one or more BC Security Groups and the permissions can be adjusted individually.
This all makes sense and everybody understands that the primary directions BC is taking is towards the cloud.
Composable Permission Sets
However, it came as a surprise to me that the user groups no longer exist when enabling the feature in Feature Management (And it is enabled by default in new BC22 installations).
I thought that the new security groups should replace the old user groups, but so much wiser I became😊
A long and (at times heated) correspondence with Jesper Schultz-Wedde from Microsoft made the penny drop and here is how I understand it:
My old setup is constructed with:
- A number of User Groups
- Each User Group has attached a number of permission sets
- Each user has assigned one or more User Groups
- The permission sets from the user group will be defaulted to the user
- Lastly, it was possible to add or subtract permission sets to the individual user
Windows Active Directory Security Groups have always been available, but was created as a user of the type Windows Group and then assigned permission sets. The user would then be added to the Security Group in Active Directory but would also be created as a full user (or limited user) in BC in order to control which companies the user should be able to access. In this section we will ignore the Windows Group users.
The new setup
Converting the old User Groups with the wizard in Feature Management offers two options:
- Assign permissions to members
- Convert to a permission set
The Assign permissions to members will add the permission sets to each individual user. This is a major setback because it brings us back to the time before user groups and will create a maintenance nightmare. Watch out – this is the default value.
The Convert to a permission set will create a Composable Permission Set that includes all the permission sets that were included in the User Group. This basically makes the Composable Permission set a User Group.
The conversion resulted in this:
Finance has had all permission sets added to the individual users and must be maintained separately.
Clicking the permissions action on Paul Hansson (Finance) does not make much sense:
Sales and Purchase have a Composable Permission Set added to the user with the permission sets.
But with Sales with the composable permission set, it makes much more sense:
And notice that it is now possible to exclude access to individual objects from Composable Permission Sets.
All in all, I am happy with the new functionality, but there are a couple of things that I would change:
- There is almost no documentation on the last part of the feature and communication has been sparse
- The feature is enabled by default in BC22. A feature with this amount of structural changes should be optional so you can investigate nice and easy and then activate when ready
- There are no FactBoxes showing Permission Sets from Composable Permission Sets on the User Card, this would be a nice feature.
Don’t forget to check out my store
