Azure AD Connect: The Trouble With Expired Passwords

In an on premises world, with Active Directory, password expiry is easy. Set the required policy for your domain, make sure it’s applied, and forget about it — AD will take care of enforcing password changes and compliance with your password rules. Moving your identity to Azure complicates things, and that’s what we are going to talk about today — in particular, password expiry and related processes in the world of Azure AD Connect.

Azure AD password policies vary depending on how you have things set up. If you're lucky enough to be using cloud only identity (no synchronization at all), then this isn’t a headache you really need to deal with. Azure AD in cloud only mode has a set of password policies it follows, which includes password expiry by default of 90 days.

Where things get complicated is when you enable Azure AD Connect to synchronize your on premises users with Azure AD and you enable password hash sync to allow authentication in the cloud. With user and password hash sync enabled, users are able to use their Azure AD identity to connect to your services and third-party services such as Office 365. In this scenario, all your authentication happens in Azure AD. When you enable AD sync, your password complexity rules from on premises are used in place of any set in the cloud, however, your expiration policies are not. When password sync is enabled, the hash of the password in the cloud is set to never expire.

It doesn’t take much thought to see the concern here. In this scenario, users whose passwords have expired, or perhaps more worryingly whose account has expired, will still be able to login to services using their AAD account. Services like Office 365, Salesforce, Dropbox, etc., all of these can contain sensitive information that you probably don’t want expired users accessing. This limitation is documented, but it doesn’t jump out at you. I think most reasonable people would assume that if you are syncing an expired password, then the user would not be allowed to login.

Note that what we are talking about here is expired passwords and accounts, not disabled accounts. Disabling an account on premises will be synced up to Azure AD and access will be prevented, though this can take up to 3 hours.

Solutions

If you don’t make use of your synchronized Azure AD identity for accessing applications, then this may not be a concern. But for those who do, let’s look at what we can do to resolve this problem.

Change Cloud Password

One option would be to run a script on a regular basis to check your on premises AD for expired accounts and, when found, change the password in the cloud account. This would result in the user needing to reset their password before being able to login (as they don’t know this password) and this then being synced to AAD. Whilst being a fairly simple solution, it’s not particularly foolproof. You would need to run the script on a very regular basis to ensure you catch all expired accounts early, and it is going to be prone to issues and reliability concerns. If you need something simple and quick, it could work, but I wouldn’t recommend it.

AD Federation Services

Instead of using password hashes with AD Connect you could instead implement Azure ADFS. With ADFS, all login requests are authenticated against your on premises resource, and so all attributes of your on premises account are honored, including password and account expiry. This is a robust, time-tested solution to this issue. The problem is that ADFS is complicated to deploy and involves a number of extra resources and significant knowledge to set it up. If you are already using federation for other things (such as integration with other companies) then using this with Azure AD makes perfect sense. However, if you have never used ADFS, it can be pretty daunting and costly to set up and manage, especially for small organizations.

Azure AD Pass Through Authentication

Fortunately, there is a middle ground (now) between the two options above. Azure AD Pass Through Authentication is a new service currently in preview that allows you to still sync your users to Azure AD with AAD Connect, but to not sync their passwords to Azure AD. Instead, when a user authenticates, they are passed through to on premises AD using a client application to authenticate directly against your on premises infrastructure.

The primary use for this service is for companies that cannot or will not store their user passwords in the cloud, even in hashed form. But one of the other benefits is that, as with ADFS, all of your account policies, including expiry, will be honored. With this service, you get the same benefits of ADFS in terms of account expiry, but without having to install all of the infrastructure. In fact, there are really only two additional things to do when using this as opposed to password sync:

1. Choose Pass Through Auth rather than password sync in the AD Connect setup
2. Install a second Pass Through Auth client on another on premises machine for high availability.

Once you do this, your authentication requests are passed through, and if a user's password has expired, they will be prevented from logging on. If you have enabled password write back in AD Sync, then they will be able to reset their password via the cloud app. If you don’t allow it, then the user needs to log onto an on premises resource to change it. Because the authentication process is still going through Azure AD, you still retain all the benefits like MFA, Self Service Reset, Identity Protection, etc.

A further benefit for using Pass Through Auth is that setting the “user must change password at next logon” also now works. With the hash syncing setting, this would cause the user to not be able to log in, but now this setting works as expected as well.

Summary

Password expiry seems like a simple problem that was solved many years ago, and I suspect many people have moved to using Azure AD Connect Password Syncing and just assumed that their expiry policy carries over to this. They will be surprised to learn that users they thought had lost access to cloud resources through an expired password or account can actually still gain access to things. Up until recently, this was actually a fairly hard issue to solve. Fortunately, pass through auth is now available and makes it fairly simple to keep your passwords on premises and obey your expiry rules without needing to learn and implement ADFS.

The key thing here is to understand clearly what policies do and not apply to your cloud identities and make an informed decision about what concerns you and requires a change to be made.

Further Reading

• Integrate your on-premises directories with Azure Active Directory

• Deploying Active Directory Federation Services in Azure

• User sign-in with Azure Active Directory Pass-through Authentication