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, and 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 setup. If your 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 has sync enabled, users are able to use their Azure AD identity to connect to your services, and third part 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 who’s password has expired, or perhaps more worryingly, who’s 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 logon.
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 prevented, however this can take up to 3 hours.
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 that 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 fool proof. 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 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 withAAD 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 setup and manage, especially for small organisations.
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 which 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 password sync:
- Choose Pass Through Auth rather than password sync in the AD Connect setup
- Install a second Pass Through Auth client on another on premises machine for high availiblity.
Once you do this, your authentication requests are passed through and if a users password has expires they will be prevent from logging on. If you have enabled password write back in AD Sync then they will be able to reset their password at the cloud app. If you don’t allow it then the user needs to logon to an on premises resource to change it. Because the authentication process is still going through Azure AD you still retain all the benefits of this 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 hash syncing setting this would cause the user to not be able to logon, but now this setting works as expected as well.
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.
They 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.