Sunday, 25 January 2015

FIM 2010: SSPR with one-way trust


This article describes and documents an SSPR setup between two AD forests with a one-way trust. FIM is deployed in the internal domain Users from the domain are being imported and managed by FIM. There is a one-way incoming trust on the domain. All prerequisites from the password reset deployment guide are already satisfied.

DMZ connector configuration

SSPR requires that the DMZ connector service account has local logon rights on the FIM synchronization server. If the service account is from the DMZ domain, a two-way trust is required to allow this setting. Since this is not a valid option in this scenario, a service account from the IS4U domain needs to be delegated the proper rights on the DMZ domain. This includes at least the following:
  1. Replicating directory access
  2. Reset password

WMI verification

The configuration as is was tested and worked, but after a week, following the same scenario resulted in the following error:
Following up on the error, the event viewer gave following info:
Password Reset Activity could not find Mv record for user

Finding the PDC

DsGetDCName failed with 1355
A bit of researching learned us that the SetPassword call of SSPR always calls DsGetDCName because SSPR needs to find and target the PDC (domain controller with the PDC emulator role). This call seems to fail. We tried getting more info by running this specific call via nltest nltest /dsgetdc:dmz /netbios, but failed with following message:
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
However, resolving the FQDN using nltest / /netbios succeeded. And, even more strange, retrying to resolve using the netbios name did work! Some googling pointed to caching of certain information, which explained why the netbios lookup works after the FQDN lookup and why the initial configuration worked and then broke a week later.




The solution involved changing the advanced IP configuration settings. By adding the and be suffixes the DsGetDCName call is enforced to always resolve the FQDN by searching for instead of dmz.


No comments: