Skip to main content

Microsoft

Office 365 – DirSync Password Sync: Did You Know?

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”.

Password Expiration

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.

Account 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.

Account Disabled

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.
 
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Thoughts on “Office 365 – DirSync Password Sync: Did You Know?”

  1. Hi Joe,
    Thanks for the great blog post on this.
    Would you be able to clarify on how this process would work for this statement:
    “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.”
    Would the command line be as simple as:
    set-msoluserpassword -userprincipalaname (user) -forcechangepassword $true

  2. My thought there was that if you didn’t want users to be able to login with expired credentials, you could change the password in the cloud to an unknown value and the user could no longer use the expired password.
    So basically you would run your command but without the -forcepasswordchange switch. You’d also need logic to be able to identify expired passwords on-premises so you’d know who to reset in the cloud.
    This would force users to then change their on-premises password which would subsequently sync to the cloud and allow them to login.
    Thanks for the feedback!

  3. Joe,
    Are these limitation still in place today with the latest Azure AD Connect?
    Thx,
    Patrick

  4. Patrick-
    For the most part, the same limitations still apply today.
    I haven’t tested the issue with spaces but that’s a bit of an edge case. To force a sync of passwords, the process is a little different now: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-implement-password-synchronization/. Also, the (non-password) sync cycle is 30 minutes instead of 3 hours in the latest version of AAD Connect.
    Thanks!
    Joe

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Joe Palarchio

More from this Author

Categories
Follow Us