Blog - AdaptivEdge

Azure AD Security and Password Protection

Written by aeadmin | Feb 13, 2019 7:00:00 PM

 

Microsoft continues to address vulnerabilities around user identity and has integrated a solution in Azure AD (currently in public preview) that enhances password policies to protect against common, weak passwords. Organizations can now configure their change/reset process to flow passwords through a sequence in which they are validated against banned passwords lists. If users attempt to use a banned password, they are notified that the password is vulnerable and will need to try a different password.

Azure AD Password Protection takes the new password provided during the reset process and converts the string to lowercase characters. The entry is then compared to the global and custom banned password lists using approximate string matching or “fuzzy matching.” In the example below, the word Ouredge has been added to the custom password list. If a user attempted to reset the password to our3dge2019 (note the 3) this password would be converted to ouredge2019 and rejected.

Microsoft manages the global banned password list, which comprises entries the AD Identity Protection team has identified as vulnerable and commonly used. Organizations have the option to enforce a custom list of banned passwords. While the approach for creating a custom list will vary, an organization should consider banning words and phrases commonly associated with users, including a mascot name or other company-specific products or terms.

Password Protection is currently available in preview for all SKUs including Azure AD Basic and Free. It can be extended to protect hybrid deployments with an on-premises Active Directory environment by using an Azure AD Premium subscription, and it works in conjunction with other features such as Self-Service Password Reset and Passthrough Authentication. The on-premises deployment requires the installation of two separate lightweight agents: “DC Agent Service” on all domain controllers (Windows Server 2012 or later) and “Proxy Service“ on dedicated member servers (Windows Server 2012 R2 or later). No network changes or Internet connectivity is required for the DCs and no changes are made to the schema. Please note this feature is not a real-time policy application engine and there may be delays between a password policy configuration change and replication across all domain controllers.

Prior to implementing any identity management features, it is important to understand the end-user experience and how they will be impacted. This can be accomplished in “Audit Mode” to conduct initial monitoring and identify any trends of weak passwords in the organization. Developing a solid deployment plan and properly communicating the initiative to the organization are keys for a successful deployment.

Technical References
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-faq

Written and composed by Raul Perez, Microsoft Systems Engineer