Microsoft added the “Password Sync” option to DirSync in June 2013 and in the past year it has become a viable alternative to AD FS due to its fewer on-premises infrastructure dependencies. The differences between Password Sync and AD FS are well documented elsewhere, the article “Choosing a sign-in model for Office 365” is a good start in comparing the two models.
I always discuss with my clients the importance of “understanding what you have” when you engage in a service-based offering and never assume that a feature will function exactly the same as it does on-premises. With Password Sync, there are a few password and account related scenarios that aren’t well documented by Microsoft. These scenarios may not apply to your organization or you may have a way to easily workaround them. They don’t necessarily make Password Sync any less viable of a sign-in model but it’s important to “understand what you have”.
When Password Sync is enabled, the cloud password for a synchronized user is set to “never expires”. This means that the password synchronized to the cloud is still valid after the on-premises password expires.
Remote employees that don’t sign into the on-premises Active Directory often will probably like this “feature”, your security team may have a different reaction if they aren’t advised of this configuration in advance. As a possible workaround to this, you could develop a script running as a scheduled task that modifies the cloud password via Remote PowerShell based on the on-premises password expiration.
Separate from Password Expiration is the “Account Expires” attribute on an on-premises Active Directory account. Some organizations rely heavily on this attribute for temporary accounts used by contractors or consultants like myself. A consultant friend of mine recently ran across this “feature” with his own account where he could login to his client’s Office 365 tenant fine but could not login to the client’s VPN which was using the on-premises Active Directory.
As it turns out, the “accountExpires” attribute is not synchronized by DirSync so it only makes sense that Windows Azure Active Directory (Office 365) has no awareness of this expiration value. Again, something that could possibly leverage a script as a workaround but would require some development and testing.
When an account is disabled in the on-premises Active Directory, DirSync sends this status to Windows Azure Active Directory and the account there has “BlockCredential” set to “true” which stops a user from logging into Office 365. This synchronization is subject to the DirSync cycle which by default has a 3-hour delay between syncs. If the need came up to remove access immediately, a manual sync could be run or the password on the user could be changed before disabling.
Passwords with Spaces
My colleague, Paul Bellacera, recently uncovered this gem while working with a client using Password Sync. After migrating a user from on-premises Exchange to Exchange Online, the user could no longer access his mailbox via Outlook whereas access via Outlook Web App and Exchange ActiveSync both appeared to work fine. While working with the user, it was revealed that the user had a space as the first character of his password.
Troubleshooting revealed that Outlook strips leading or trailing spaces out of the password and thus was failing to authenticate; other functions such as ActiveSync and Outlook Web App had no problem with the space. You can reproduce this yourself with a Password Sync account by connecting to Exchange Online with Outlook and just adding a couple spaces to the end of your password. Assuming your actual password doesn’t have the spaces, Outlook will still authenticate successfully as it has stripped out the spaces; the same condition does not seem to occur when authenticating via AD FS. Admittedly this is a bit of an edge case but interesting and something to be aware of.
Password Sync Interval / Manual Sync
The Password Sync process runs outside of the normal DirSync sync intervals. So instead of the usual 3 hour delay in DirSync changes, Password Sync operations will generally occur within minutes of the password being changed. Forcing a “Full Sync” of DirSync does not synchronize passwords, there is a separate process documented for that at: DirSync/Windows Azure AD Password Sync Frequently Asked Questions.