We have been playing with the new Local recovery feature and it does look very useful and something we would be looking to implement. The only draw back that we can see is when you have the feature enabled in an SSO environment. For example:
User has SSO enabled. PBA and Domain passwords are in synch.
User forgets password and resets their password at PBA via local recovery. User logs on at PBA with new password. Vista loads and the user is automatically logged into windows by MEEPC with the old password.
The effect of this is that the user will know the PBA password but will be oblivious to the fact that their domain password is different. The users PBA and Windows passwords will be out of synch until their Windows password expires and they are forced to change their password, at which point both MEE and Windows password will be back in synch.
Are there any issues with the two passwords being out of synch? I guess one such limitation is that users will not be able use the ctrl-alt-delete --> change password mechanism as this requires them to know their current Windows password.
I would be interested to know your thoughts on this scenario and if there is anything else that we can do to reduce user impact?
I have just been thinking about this some more. How feesible is it for a script to run daily on the server to produce a list of all user accounts that contain the event ID of a successful local recovery in the audit log. This list can then be used by another script which sets the attribute "user must change password at next login" on the AD?
There are likely to be around 18000 user accounts.
This is the event I would be targetting: 0400001c = "Local self recovery successful"
Strangely when I view the log in the console I can see the Description text ("Local self recovery successful"), but when I dump out the audit log the description is "Unknown"? It doesnt really make a difference as my script will be targeting the event ID rather than the description but I was curious why this was.
I am creating a VBScript to do the following: Run the DumpUserAudit command with the EventID parameter of 0400001c Open the audit dump text file. For each line in the text file which contains "0400001c" - Get the machine name. - Set the "User must change password at next logon" attribute in the AD
I guess we will need to run a regular scheduled task (probably weekly) to keep the size of Audit logs down and thus reduce the run time of the script. Am I missing anything else?