Hybrid Azure AD environments and third-party password tools
Can we leverage third-party password tools like Specops Password Policy in hybrid Azure AD environments? The answer is yes, and this blog will explain how.
Azure AD Hybrid
Let’s start with some background.
The best way to think about Azure Active Directory is that it is primarily intended to be an identity solution. A way to leverage a managed identity for say SaaS solutions via Single Sign on, O365, or providing federation.
This is not the same as standing up Domain Controllers on virtual machines in Azure. Azure AD is a service.
One of the challenges for companies that have an existing on-premises Active Directory Domain Services environment is how to deal with users potentially having two identities that have different passwords and are separate entities? That can become burdensome to users, and create overhead for support.
This is where using Azure AD Connect comes in. It’s Microsoft’s solution to this issue, and allows a synching of identities from your on-premises domain controllers, and Azure AD. In essence, it allows you to extend your on-premises identities.
AD Connect is the Microsoft solution to dealing with the issue of multiple identities. It allows you to use the same account your users are familiar with, and passwords to be used by Azure AD, for authentication.
AD Connect features:
- Included with your Azure subscription at no additional cost.
- When Password Writeback is enabled, password changes via Self Service Password Reset can adhere to on-premises password policies, including Specops Password Policy.
- Can be configured to synchronize changes to your Active Directory identities to Azure AD on a configurable interval.
- Password Changes sync near instantly to Azure AD.
- Can be used to used to sync custom attributes to 3rd party solutions via Azure AD Enterprise Applications and Mapping.
Azure AD Connect and Password Writeback
One of the features of Azure AD Connect and Azure AD is to enable password writeback. This setting dictates whether password changes done in Azure AD SSPR are then synchronized back to your on-premises Active Directory environment. Let’s review Microsoft’s sample architecture for Password Writeback.
This architecture shows the flow when a user changes their password via SSPR in the cloud. Azure AD will leverage Azure AD Connect (assuming Password Writeback is enabled) to sync the password change back to your on-premises Active Directory environment.
Since AD Connect by default syncs passwords from your on-premises Active Directory environment to Azure AD, you’ve now created a two-way sync for passwords.
Azure AD Connect – Installation considerations
If you want more information about getting Azure AD Connect up and running you can see documentation here.
Some of the items that you may want to consider if you are thinking about implementing Azure AD Connect:
- Review permission requirements for the AD Connect service account, and the required access the person setting up Azure AD Connect will need. You can see details here.
- Look at the requirements and supported configurations – in particular supported topologies here. From experience, it might save you some headaches down the line.
- Treat this server like you would treat a Domain Controller. When in production, it will have important identity information and become pretty critical infrastructure. Consider how you will secure access to this server.
- Considering setting up at least two Azure AD Connect Servers. One in production, and one in Staging mode. They should have identical configurations in case of a critical failure. This way in the case of an issue, or if one server requires maintenance, you can switch the staging into production, and vice versa. You can see more information here.
I have Azure AD Connect installed, how do I enable Password Writeback?
There are two pieces that are required to be configured for this:
- Azure AD Connect Password Writeback feature needs to be enabled.
- Enable Password Writeback for SSPR via Azure AD.
Let’s quickly go over Microsoft’s documentation on how to do this.
Once you’ve done those two items, you have enabled Password Writeback.
How does Specops Password Policy fit in?
Now that Azure AD SSPR is configured to use Password Writeback, user password changes done via SSPR do the equivalent of an Admin Reset and SSPR will check your on-premises Active Directory for any password policies including Specops Password Policy, and the password has to meet all of them.
If the user chooses a password that meets your Default Domain Policy, as well as your Specops Password Policy, the password will be changed in Azure, and then sync down to your on-prem Active Directory domain. Please keep in mind that there might be a delay in the password syncing down to your on-prem Active Directory.
What happens when a user chooses a password that is rejected?
The password will not be changed in Azure, nor the on-prem Active Directory Domain.
On the user side, they will receive a message similar to this:
While it does tell them it is rejected, the user still doesn’t quite know what in particular they need to fix for their password change to be accepted. This can cause the user time and they may contact your Service Desk needing assistance.
Whether the password is accepted or rejected, Specops Password Policy is still enforced.
Changing a password in Specops uReset vs Azure AD
As we saw previously, we can change the password in Azure AD SSPR, but the user experience leaves a lot to be desired.
For comparison, I want to walk through the password change experience in Specops uReset to compare.
When a user goes to change their password, they get a screen that shows them all of the requirements the user must meet:
As you can see the user is presented with requirements that they must meet to change their password. This is based on the policy set in Specops Password Policy. The policy requirements can be customized as you need.
As the user starts typing a password, the requirements will turn green as they are fulfilled:
Note: At the bottom we are leveraging the variable length aging custom setting in Specops Password Policy that allows a password maximum age to be set based on the length of the user’s selected password.
Once the user has completed all of the requirements in red, you will see them turn green and the OK button becomes available.
Once the user hits OK and the password change is accepted, they will be given a Success screen:
This password will be changed on your on-prem Active Directory, as well as updating the user’s local cached credentials, without the workstation needing direct connectivity to a Domain Controller.
The user has a much more streamlined experience. Users will be able to change their passwords without service desk intervention, password policy compliance will be easier to maintain, and passwords will still be synced back to your on-prem Active Directory domain.
Additional uReset features:
- Multi-Factor Authentication for password changes and resets including 15+ Identity Providers including Okta, PingID, Duo, Symantec VIP, and others including traditional methods like Mobile Code, Google Authenticator, and Email.
- Accessible from any web browser, the Windows logon screen, the mobile app.
- When a user changes their password, their cached credentials is also updated, even if not connected to a Domain Controller.
- Enrollment enforcement and auto-enrollment options.
- Enrollment notifications via system tray, email, or unclosable full screen browser.
- Helpdesk interface for verifying users, unlocking user accounts and setting temporary passwords.
Please Contact us to get more information, or to have a chat about how Specops can help you meet your password security needs.
(Last updated on April 29, 2022)