Today I was able to carve out some time to do a little testing of the Password Sync functionality within the new DirSync. What I wanted to test is what initiates a password sync to occur.

Password Sync

First I was logged into a computer with my Iceman account, I then changed the password for the account as any other user would do. Right when I did this, in my DirSync Server’s Application Event Log I noticed these two entries:

 

Sure enough, I was immediately able to login to the Office 365 using the changed password. This worked great and very seemless and transparent to both the end users and administrators.

The next scenario I tested is what happens when an admin resets a password for a user. I launch Active Directory Users and Computers (ADUC) and navigated to my Iceman user account and reset the password (I did remove the checkbox for ‘User must change password at next logon’

After doing this I check the Application Event Log on my DirSync server, surprise surprise there was NO corresponding entries like the ones above when the user changed their own password. Just to verify and see if maybe changing the password via ADUC did not result in event log entries I attempted to login with Iceman to the Office 365 Portal using the new password, no Bueno, could not login. Next thing I did, to try to see what happened is I logged into a domain joined computer using Iceman, I was able to login using the new password so the change obviously took. I then checked my DirSync Server’s event log and there were the event entries:

As you can see these entries correspond with the time that Iceman logged in:

So it appears that the password does not sync until the user logs into the domain. This could be problematic, say a user is away from the office and needs to check email but they forgot their password. They would probably call their HelpDesk and have it reset; but now the HelpDesk person is going to need to change it in Active Directory and in Office 365 to ensure that the user can access their mailbox. Another option would be forcing a full DirSync to run, but could be problematic as the HelpDesk tech might not have that level of access. Another problem with this is when you set a password online you are required to meet the Password policy Online, this could cause a problem if you do not have a strong password policy in you on-premises Active Directory.

That last sentence might have you wondering why can a lesser on-premises password policy be allowed to set passwords Online? My understanding is that because the password sync is not truly “Setting” the password online like a user or admin would do, but actually copying the password Hash File, the online password policy is never invoked.

New Event IDs

With the new DirSync tool there are new event ids that represent when the DirSync tool has ran. With the previous versions I also looked for Event ID 4 from source Directory Syncronization to know a sync occurred successfully. Now here are the two events generated with the new tool:

As you can see both are Event ID 902. Now you will need to look for any errors like below:

Well this is all for today, still working on the blog post as to when do you use Password Sync and when to use ADFS, stay tuned.