Self service password reset is not working multiple forest AD hybrid identity environment

Question

We are having a problem with office365 SSPR in our environment that is users cannot reset their own password using office365 portal, my assumption is password writeback is not working as expected.

Description of our environment
We have three AD on-premises forests connected together using 3-way domain trust. The Trust is working properly.
We have a single azure AD tenant.
In each forest we have installed AD connect tool.
Two of the AD connect tools are configured to sync a blank OU, while one AD connect is configured to sync user and device OUs from the three AD forests to o365. Password sync from AD on-prem to office365 is syncing properly regardless of the forest where the user is hosted in this state of configuration.
All users are assigned Microsoft 365 E5 license plan, which has Azure AD premium 2, sspr requires at least AD premium 1.

What we have tried and getting problems
When we try to configure just a single AD connect to sync from the three forests (and remove the other two AD connects), the issue of password sync occurs (users cannot sign to o365 using their on-premises credentials)

When we try to configure each three AD connect to sync users from its respective forest to azure AD, the issue of user objects deletion occurs, hence we have to and restore the deleted users.

What do we need to do to make sure SSPR is working properly for our environment.

The error i get once i reset password using SSPR service in office365

Answer 1

@Benard Mwanza

I'm glad that support team was able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "[The question author cannot accept their own answer. They can only accept answers by others] (https://learn.microsoft.com/en-us/answers/support/accepted-answers#why-only-one-accepted-answer)", I'll repost your solution in case you'd like to "[Accept] (https://learn.microsoft.com/en-us/answers/support/accepted-answers#accepted-answer-in-a-question-thread)" the answer.

Answered by @Benard Mwanza

Below is the summary of few things he did to fix.
Configured a single AD connect server to synchronize objects from the three forests. Uninstalled the other two connect servers.
The AD connect server was not using TLS 1.2, so we enabled that first (required a reboot).
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-tls-enforcement
Added MFA exception for the Azure AD connector account, this was done via conditional access policy as there was existing conditional access policies in place that requires all users to verify MFA before connecting to M365.
Reset the Azure AD connector account password, he pulled the link below.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-azureadaccount
Reset the password for Microsoft azure AD sync service logon account (NT SERVICE\ADSync) inside the AD connect
server (simply remove the existing password>choose to apply>Ok & then start the service).

I got to learn that synced GL administrator accounts cannot reset password using SSPR with password writeback. It's not supported
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#unsupported-writeback-operations

Normal synced users are able to reset their passwords using sspr service with password writeback. This worked fine at the end.

Answer 2

@Benard Mwanza

I have read through your description. Configuring multiple AD connect severs, connecting to single Azure AD tenant is not recommended.

You will have to create 2-way trust between all 3 forests and then install AD connect in only one forest.

Many organizations have environments with multiple on-premises Active Directory forests. There are various reasons for having more than one on-premises Active Directory forest. Typical examples are designs with account-resource forests and the result of a merger or acquisition.

When you have multiple forests, all forests must be reachable by a single Azure AD Connect sync server. The server must be joined to a domain. If necessary to reach all forests, you can place the server in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).

The Azure AD Connect installation wizard offers several options to consolidate users who are represented in multiple forests. The goal is that a user is represented only once in Azure AD. There are some common topologies that you can configure in the custom installation path in the installation wizard. On the Uniquely identifying your users page, select the corresponding option that represents your topology. The consolidation is configured only for users. Duplicated groups are not consolidated with the default configuration.

Common topologies are discussed in the sections about separate topologies, full mesh, and the account-resource topology.

The default configuration in Azure AD Connect sync assumes:

Each user has only one enabled account, and the forest where this account is located is used to authenticate the user. This assumption is for password hash sync, pass-through authentication and federation. UserPrincipalName and sourceAnchor/immutableID come from this forest.
Each user has only one mailbox.
The forest that hosts the mailbox for a user has the best data quality for attributes visible in the Exchange Global Address List (GAL). If there's no mailbox for the user, any forest can be used to contribute these attribute values.
If you have a linked mailbox, there's also an account in a different forest used for sign-in.
If your environment does not match these assumptions, the following things happen:

If you have more than one active account or more than one mailbox, the sync engine picks one and ignores the other.
A linked mailbox with no other active account is not exported to Azure AD. The user account is not represented as a member in any group. A linked mailbox in DirSync is always represented as a normal mailbox. This change is intentionally a different behavior to better support multiple-forest scenarios.

Once you have this set up in place then you can configure SSPR. While writing the password back to on-premises, AD connect AD connector account will make the password changes in corresponding forest to which user belongs to.

You can also refer below article to know more about recommended AD connect topologies.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies

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

Answer 3

Hi @Sandeep G-MSFT I opened a ticket with Microsoft and got an engineer assigned from identity team. He managed to resolve the issue.

Below is the summary of few things he did to fix.
Configured a single AD connect server to synchronize objects from the three forests. Uninstalled the other two connect servers.
The AD connect server was not using TLS 1.2, so we enabled that first (required a reboot).
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-tls-enforcement
Added MFA exception for the Azure AD connector account, this was done via conditional access policy as there was existing conditional access policies in place that requires all users to verify MFA before connecting to M365.
Reset the Azure AD connector account password, he pulled the link below.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-azureadaccount
Reset the password for Microsoft azure AD sync service logon account (NT SERVICE\ADSync) inside the AD connect
server (simply remove the existing password>choose to apply>Ok & then start the service).

I got to learn that synced GL administrator accounts cannot reset password using SSPR with password writeback. It's not supported
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#unsupported-writeback-operations

Normal synced users are able to reset their passwords using sspr service with password writeback. This worked fine at the end.