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 is4u.be. Users from the domain dmz.be are being imported and managed by FIM. There is a one-way incoming trust on the dmz.be domain. All prerequisites from the password reset deployment guide are already satisfied.

DMZ connector configuration

SSPR requires the DMZ connector service account has local login 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 to the DMZ domain. This includes at least the following:
  1. Replicating directory access
  2. Reset password

WMI verification

The configuration 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 showed the 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 research led found 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 that failed with the following message:
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
However, resolving the FQDN using nltest /dsgetdc:dmz.be /netbios succeeded. And, even more strange, retrying using the NetBIOS name worked! 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 is4u.be and be suffixes the DsGetDCName call is enforced to always resolve the FQDN by searching for dmz.be instead of dmz.

IP settings