I am working on a solution to integrate only the FIM syncronization services (no Portal) into our current account management processes. Due to CAL costs for FIM we cannot use Portal for our users or self Service. When playing with FIM I am looking to allow for the passwords to be synced with FIM and PCNS in our environment. I am trying to find out what the best way is to allow for the force password change on next login setting to apply to both AD DS and AD LDS.
Today when flagging an account in LDS to force change on first login I setup the account with the PWDLastSet attribute to be 0. Hoewever, when syncing passwords with FIM, if i set a users password in AD to require change on next login, the password change gets successfully replicated, but also updates the PWDLastSet attribute for the account which cleasr the force change on next login option we are setting in LDS. This would allow a helpdesk user to reset an AD account to require a password change on next login, but would also clear the force change on next login flag (PWDLastSet attibute) and the password would be immidiately usable in ADLDS.
Is there a different configuration i need in the PCNS or FIM MA? I understand that when the user logs into their workstation and sets their password it will correctly update LDS with the new password, but if the user goes into our LDS based applications they will be able to use the account without having to change it making it somewhat less secure.
Any help is appreciated.
- Changed type Markus VilcinskasMicrosoft employee, Owner Thursday, March 14, 2013 6:51 AM
While I'm thinking about your problem, is there a reason why you couldn't just use userProxyFull objects in ADLDS, joined on objectSid via the FIM sync server, and therefore avoid using PCNS altogether?
Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine
what Bob suggested would be a lot easier. But if you need this to work like you described, it will be tricky, there is no "require PW change on next logon" per say option in AD LDS ... I mean how would that even work? Dependent on your detailed use case there are few options ... if for example you specifically don't want users to use their AD LDS accounts before the change the AD password you can try just disabling or expiring the AD LDS account until the AD password is in the "normal" state.
Thanks for the replys. Currently I have written a Self Service Portal that allows people to register and Activate their LDS accounts as well as change passwords. This application handles the various LDAP return codes based on the disposition of the account. For example when a password is reset by the helpdesk we require the user to go the the Self Service Portal to change their password. The code in the portal traps the "Require Password Change on Next Login" exception during the BIND required (Eror 52e from the .Net LDAP Provider) and displays a standard Change your password dialog box. This occurs for new accounts that are created and when the user call ths Help Desk and they reset their password. the Interfaces always set the PWDLastSet attribute to 0 to trigger this behavior.
We cannot use Proxy Objects as we have a requirement for offline utilization. We have 2 LDS instances in our home office and another 300 + LDS instances that need to function in remote sites (Retail Stores) as a backup in the case the WAN link is down. There are no domain controllers present in these remote locations.
The other issue is not all users have an AD DS account, but all users do have an LDS account. I am going to update our custom portal to perform the Password Reset and Force Change on next login in AD where applicable, but if the user only has an LDS account is will only update there. This way if the user has an AD DS account it will change the password there, flag it as force change on next login and replicate via PCNS to the LDS via FIM. While the password replicates fine, the force change on next login does not. If all the actions were take from the portal, I could contro this, but there are times where this action will be taken via the DSA.msc or other mechanism that does not flow via PCNS and FIM as I thought it would (or hoped).