FIM 2010: SSPR with one-way trust

Originally posted at: FIM2010: SSPR with one-way trust @ IS4U Blog


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:

An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)

Following up on the error, the event viewer gave following info:

Password Reset Activity could not find Mv record for user

This is a very clear error message indicating a problem with the WMI permissions. Checking up on this resulted in the conclusion that the permissions were set correctly. Lookups for accounts in the IS4U domain worked, but lookups for accounts in the DMZ domain failed.

Finding the PDC

Going back to the event viewer, we were given another clue:

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.


NetBIOS recognizes domain controllers by the [1C] service record registration, but we could not find the correct WINS configuration, maybe because of the one-way trust.


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.



Leave a Reply

Your email address will not be published. Required fields are marked *