Hello,
When setting up Azure SSPR for on-premise users, we need to enable password writeback using Entra ID connect. Will this cause any disruption to users or require any downtime?
So, you’re wondering if enabling Azure Entra ID Connect password write-back will cause any disruptions or require some downtime? Well, let me give you the lowdown.
First, the good news: Enabling password write-back via Entra ID Connect shouldn’t cause a significant disruption to your users. This service is designed to work in real time, which means your users will get zero-delay feedback if their password doesn’t meet the on-premises AD DS policy. It also supports various scenarios like user-initiated and admin-initiated password resets, ensuring a seamless experience.
Now, for some necessary fine-tuning:
-
AD Connect Permissions: Ensure that the on-premises service account handling password write-back has the necessary permissions. Specifically, ensure that the MSOL_xxxxx account has all the rights to reset passwords on user objects, and that inheritance is enabled.
-
SSPR Configuration: Double-check that you have properly set up SSPR and password write-back in both the Azure AD Connect configuration and the Azure AD Portal.
-
Azure AD Licenses: Verify that your users have the required Azure AD Premium Licenses for this feature.
-
AD DS Configuration: If you’re using a protected group, be aware that the on-premises service account can’t change passwords for users belonging to those groups. Also, note that users can’t use password write-back to reset their forgotten passwords if they’re part of these groups.
Finally, remember to update Azure AD Connect to the latest version if you haven’t already done so. This will ensure that you have the latest features and any existing issues are resolved.
In summary, enabling password write-back should be relatively smooth, but make sure to double-check these key configurations to avoid any potential bumps. Happy troubleshooting