Originally posted at: FIM2010: SSPR with one-way trust @ IS4U Blog
Intro
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 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:
- Replicating directory access
- 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 /dsgetdc:dmz.be /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.
WINS
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.
Solution
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.
