Forum Discussion
Self Service Password Reset for trusted domain
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 s...
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.
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.
