Protected Groups - SSPR Best Practices

@Motty ,

Thank you for providing detailed information.

For security reasons a Windows AD account that belongs to on-premises AD protected group(s) cannot use SSPR+Password Writeback to reset his/her on-premises password using the flow "Forgot my password" rather administrators can change their password in the cloud but can't reset a forgotten password.

Therefore, workaround would be assign required permissions to AdminSDHolder container for Azure AD connector account either manually or by using AAD connect PowerShell module but assign required permissions to AdminSDHolder container is not recommended, so if you wish to leverage SSPR+Password Writeback to reset password of user then best way would be removing user account from protected groups.

To know more about How does self-service password reset writeback work in Azure Active Directory, refer.

However, "Domain Users" group is not a Protected Group in Active Directory by default, and here is a list of protected accounts and groups by operating system, therefore I'm curious whether "Domain Users" members were specifically added to member-of any protected groups such as Domain Admins, Server Operators, Account operators or Enterprise admins etc.., ? if so then you may see AdminCount attribute set to 1.

In order to determine if a user is or was member of a protected group you can check the if the on-premises AD user object has the AdminCount attribute set:

Hope this helps.

Hello @Motty ,

Thanks for reaching out.

Important points to be aware of when synchronizing groups (such as the Domain Users group) from Active Directory to Azure AD:

• Azure AD Connect excludes built-in security groups from directory synchronization.
• Azure AD Connect does not support synchronizing Primary Group memberships to Azure AD. To learn more about, refer understanding about AAD groups from here

Therefore, to resolve the issue in the scenario that some built-in groups (such as the Domain Users group) aren't synced, create a new group that contains all the applicable members and appropriate permissions of the built-in group. Then, add that group as a member to the built-in group that's not synced. Use the new group instead of the built-in group to manage members. By using this method, you still manage only one group.

You don't want to change the attributes of the built-in group or change the scoping rules of the identity sync appliance to allow critical system objects to be synced. It may trigger other unexpected behavior.

Reference: https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/objects-dont-sync-ad-sync-tool#create-a-new-group-and-add-it-to-the-built-in-group-thats-not-being-synced

Hope this helps.

------
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.