Hi @mehdi dakhama - starting a new answer as I ran out of characters!
Ok to summarize, you want to restrict the users, that can read properties of groups that provide elevated permissions in your AD environment. The list of groups goes beyond the groups that are current protected by the SDProp process.
I do need to make the official Microsoft statement here: The standard operating model for AD is to allow authenticated users to read the attributes of other AD objects. Changing the operating model to restrict what attributes that can be read by authenticated users, is outside the scope of the normal operating model for Active Directory and could impacts the operation of Active Directory or services that use AD for authenticate or applications that use AD (i.e. Exchange). It could also impact future updates or patches that rely on this functionality. Changes to the standard operating model may also result in issues get support from Microsoft.
There are two approach to deliver the required restriction:
- Add an explicit deny permissions to prevent users from see the attributes of the selected groups
- Changing default permissions for existing and new user and group objects
The simplest approach is to use the explicit deny method on objects that you don't want users to read, and then assign this right to a group that contains users you want to block from reading the attributes of the group. However this approach will require on going maintenance to ensure new users are added to the deny group.
The more complicated approach, with the higher risk of breaking functionality is change the default permissions, however, this has the highest risk of breaking functionality and will be very hard to remove or reverse once implemented, I don't recommend this approach.
The recommendation is to use option 1 and assign an explicit deny permission.
If you do want to continue with changing the access permissions, I would suggest that you test it in a test environment, before implementing any changes in your production environment.
Deny Permissions Approach
If you assign an explicit deny permission to the groups, in this case the group is called test-group1, this will prevent the user from reading the group details. in this example the permission is applied to a specific user, but you would assign the permission to a group and then add the users you want to restrict.
With this permission in place the user is not able to see the attributes of the groups
And if the restricted user views the properties of a user that is a member of the group, their membership of the group is not displayed:
Where a user that is not restricted can see the group membership of the restricted group
This is simplest to implement for the specific groups but is also the simplest to remove if it's found to causes issues at a later date. You would need to add this permission to the AdminSDHolder container so the SDprop process will apply it the protected groups, and also directly to the groups that are not protected by the SDProp process. You just need to create a new group that will be used to assign the permission. I would not recommend using any the default groups like domain users or authenticated users as these groups include every user and will result in loss of access to all users.
You then just need to add an additional step to the user provisioning process to add new users to the deny group. I would also have some sort of schedule task to add missing users back into the restriction group.
Gary.