Avoid strings in passwords with Azure AD

In this article you will learn how to avoid strings in passwords with Azure AD password protection. By default, the Windows operating system, via the password policies, offers to specify the minimum number of characters, as well as a predefined complexity of the password. 

This defined complexity (if enabled) requires:

• that a new password must contain at least one character from three defined sets (uppercase letters, lowercase letters, numbers and special characters),
• and that the content of the Active Directory attribute sAMAccountName and substrings of the attribute displayName (separated by comma, period, hyphen, underscore, space, hash or tab) lead to rejection.

For requirements going beyond this for the exclusion of strings, a separate password filter must be created and included.

Avoid strings in passwords with Azure AD password protection

In the Microsoft cloud, the Azure Active Directory (Azure AD) password policy does not offer any significant differences for strings, in contrary to Active Directory On-premise.

But there is an additional functionality called Azure AD Password Protection, whose avoid “weak” passwords. Azure AD Password Protection is based on two lists:

• Global Blacklist: This list is managed by Microsoft and updated via Azure AD telemetry data, with global password leaks or additional weak strings. This is an ongoing process to meet current conditions.
• Custom Blacklist: This list is managed under one’s own responsibility. One can exclude that e.g. the company name or product name may be used in passwords.

With the provided strings, the entered string is evaluated with a point system in case of a password change. If the value is at least 5, the string is considered valid. The process of scoring is as follows:

1. Normalization: in this step, uppercase letters are replaced by their lowercase counterpart and common character substitutions (e.g., “0” to “o”, “$” to “s”, or “1” to “l”) are reversed (example: “P@$$w0rd” becomes “password”).
2. Fuzzy match: the entries from the blacklists are searched completely or as a partial match in the normalized string. An edit distance of 1 is also applied, i.e. the entry from the blacklists differs with the (partial) string by an insert, delete or replace operation. (Example: “password” = “password” or “password” = “passort”).
3. Predefined strings: The respective strings greater than three characters consisting of first name, last name, and Azure client name will result in direct password rejection if a match is found
4. Scoring: Each fuzzy match found is scored with one point. All remaining characters are additionally calculated with one point.

The global Blacklist is available by default for each cloud-based user account. To use a custom blacklist, at least one Azure AD Premium P1 license is required.

Cloud password protection for local user accounts

Microsoft has extended the functionality to include a component for the Windows Server Active Directory. It means that the global and, if used, the customised blacklist will be applied when a password change is made to an Active Directory user account with the rating system described above. The functionality can be operated in one of two modes:

1. Monitoring mode: in this mode, a password change is allowed according to the locally applicable password policy, but compliance or rejection against the backlists is noted in the event log of the respective domain controller.
2. Enforcement mode: In this mode, the local password policy and the Azure AD password protection apply when a password change occurs. In addition, as in the monitoring mode, corresponding information is noted in the event log.

Independently, the blacklist lists are cached in the SYSVOL share. Every hour, each domain controller verifies the age of the blacklists. If they are older than one hour, an update is requested.

IDM-Portal Delegation

Delegate Azure AD Maintenance  

Reset passwords, update Name, Position, Authorizations leads to waiting time for end use and overload the IT-department. With IDM-Portal delegate your Active Directory and Azure AD routine tasks to non IT-users.

More about Azure AD Delegation

Azure AD Password Protection with Windows Server Active Directory

Microsoft has set up an architecture diagram for this functionality so that simple deployment without planning can be ruled out. But first, let’s look at the prerequisites:

• An Azure tenant
• All Azure user accounts that are synchronised from Windows Server Active Directory into Azure AD must have at least one Azure AD Premium P1 licence assigned (all non-synchronised users may also use Azure AD password protection).
• At least one member server that performs proxy functionality between the agents on the domain controllers and the Azure AD (must not include the Azure AD application proxy).
• Replication of the SYSVOL folder structure in the Windows Server Active Directory is performed using the DFS-R service (the file replication service is not supported).

If these prerequisites are fulfilled, the required services can be set up and the functionality for the Windows Server Active Directory can be activated. For this purpose, please refer to the architecture diagram already mentioned:

The setup starts with the Azure AD password protection proxy service, which is installed on a member server in the Active Directory forest to be deployed (e.g. on the Azure AD Connect system). For better failover protection of the service, it should be scheduled on another system. A Service Connection Point (SCP) is created in the Windows Server Active Directory for each instance of the proxy service via PowerShell cmdlet and the registration in Azure AD is carried out at the same time (Azure AD Global Admin and Organisation Admin are required for this).

If several Windows Server Active Directory forest structures in the corporate network are to use Azure AD password protection, then at least one instance of the Azure AD password protection proxy service is required for each forest. In addition, each Windows Server Active Directory forest must be made known once for Azure AD password protection in Azure AD.

After the proxy service is deployed in the on-premises infrastructure, the Azure AD Password Protection DC agents can be installed on domain controllers. During installation, an additional password filter DLL is registered on the domain controller, which communicates with the Azure AD Password Protection DC Agent to verify a password against the local copies of the two blacklists.

The password filter DLL is an addition to the already existing filters. For the Active Directory, a string is valid if all password filters agree to it. To obtain an update of the blacklists, the Azure AD Password Protection DC Agent communicates with the proxy service found via the registered SCP in the Active Directory. A newly received list is stored in the SYSVOL file structure (see picture) and thus replicated to all domain controllers of the domain, so that not every domain controller has to request the blacklists either.

The deployment of the agents to all domain controllers of a domain can be done in stages, so that in this case the Azure AD password protection is only active on the domain controllers on which the Azure AD password protection DC agent is also in operation. I.e. if a user changes his password on a domain controller on which the agent is not yet deployed, then the two predefined blacklists do not apply. This procedure can be used, for example, for initial tests of the functionality in the productive infrastructure.

The Azure AD password protection should first be used in monitoring mode in order to familiarise oneself as an administrator with the operation of the service. If necessary, the effects of the two blacklists can be assessed or users can be alerted to an unfavorable composition of the selected strings in their own password. In a second step, the mode can then be changed and the Azure AD password protection fully activated.

Conclusion

If the required Azure licences are available, then the quality of the user passwords in Azure AD and in the Windows Server Active Directory of a company can be increased with relatively simple means. The web interface in the Azure Portal offers the possibility to maintain the user-defined blacklist for Azure AD and Windows Server Active Directory uniformly. On the corporate network, the architecture of the service prevents domain controllers from maintaining a direct communication path with a cloud service. A local cache compensates for a temporary limitation in the accessibility of the cloud service.

For a user, the setup of strings in passwords is transparent. Whether via a password policy or Azure AD password protection, the user receives the identical cryptic indication that his or her chosen string violates a password requirement. An administrator, unless he has a centralised collection service for events, must find the corresponding domain controller on which the password change was made. He must then search for the log entry that provides information on why a string was rejected based on Azure AD password protection.