Self Service Password Reset for trusted domain

[PMC15]

Hi,

I manage a self-contained Forest/Domain in Geo1 which has a two way AD trust with our parent company in Geo2. The Geo1 domain sits in the Geo2 owned and maintained Azure/M365 tenant. SSPR is selectively enabled in Azure by way of Domain Local AD group into which all required AD groups from other business units within the organisation are nested and this works fine for users in Geo1 (all users in Geo1 are in domains which are in the same AD forest as the parent organisation).

A Domain Global AD group from Geo2 has also been nested in Geo1's Domain Local Group so, in theory, SSPR should be available to Geo2 users but it isn't working (we see a message on the SSPR page stating that SSPR 'isn't available for this user').

The Geo2 forest syncs to the Geo1 managed Azure AD via AAD connectors located in Geo1's data centres. I can see our users in the Azure Portal and have access to all permitted M365 apps such as Exchange Online, SharePoint et al. All users are have either E3 or E5 licenses.

Can anyone suggest a reason why SSPR isn't working for the Geo1 users or maybe point me to any documentation which might deal with this particular scenario?

Regards
Paul

[#2]

If anyone runs into the problem the cause of the issue and the solution was:

Cause
SSPR was configured to selective i.e. only members of an assigned security group (GEO1Domain\SSPR_Access) had permissions to use SSPR. This group was created in the on-prem AD in GEO1 and various groups were then nested into that group. A security group from the trusted domain in GEO2 was also nested into that group. GEO1Domain\SSPR_Access was synced up to Azure AD but we noticed that, while we could see the foreign domain from GEO2 in SSPR_Access when looking at it On-Prem, we could not see it in the synced version of that group in Azure AD.

Solution
We created a new group directly in Azure (SSPR_Access2) and nest all the required groups into that Azure native group, including the group from GEO2 which was itself synced to Azure. When we assigned this group the right to use SSPR it started to work for users in GEO2.

Lesson Learned
As the foreignsecuityprinciples container was not synced to Azure, the FSP representing the foreign group from GEO2 was not recognised as an FSP so when the on-prem security group with a nested group from an external domain synced to Azure, the synced group didn't have the FSP.