If we talk security, we always need secrets and passwords. Though the challenge is, to use secure passwords, ideally not including public, or wide-used words. Such datasets of passwords are found in the Internet (example GitHub).

Future password-less authentication

The future is password-less. You shouldn't use and beyond that, don't even know your personal password. Microsoft offers these solutions and architectures:

password-less-methods

Authentication methods

  • Something you know (passwords)
  • Something you have (mobile phone)
  • Something you are (biometric)

Feel free to check out my Security page.

Why should you use this feature?

The conflict is, that users want a simple, retainable password. Security responsibles want the opposite, passwords should be complex (8+ digits, lower and upper case, numbers and special characters). And until everyone is password-less and uses MFA, the focus should be on reducing the attack surface. How are you doing that? Correct, with preventing the users from using such common passwords, that easy to guess, when knowing the organization.


Password protection

Azure AD Password Protection is an IAM feature, that restricts password policies. Configuration options are:

  • Lockout threshold - failed login attempts, until the accounts gets locked out
  • Lockout duration in seconds - lockout duration
  • Custom banned passwords - A list of words, that are blocked in a password set/change process (industry, location or common/known and weak words)
  • Password Protection for Windows Server Active Directory - enforce this policy in your on-premises environment
  • Mode - Audit mode is recommended to get an insight on the impact and Enforced activates this configuration

azure-ad-password-protection-2
(hint: always go for Audit mode first)

Hybrid - Password Protection for Windows Server Active Directory

So this feature is great, especially, because it offers an on-premises integration. Legacy-wise the default domain policy was in charge of password guidelines. AAD Password Protection is on top of the on-prem policy, providing even more security. Learn more about the archtitecture.

How to set up

You need:

  • Azure AD Password Protection DC Agent - the functional agent, that enforces the policy on-prem, establishes connection to the proxy service. All DC's must have installed this agent.
  • Azure AD Password Protection Proxy Service - a proxy service, installed on a domain-joined machine, that contacts to the DC Agent's. The consideration is, that the DC has no direct internet connection, in contrast to the server with the Proxy Service.
    Download link (official)

Install the Proxy Service

First, install the Proxy Agent on a server. The setup is just next-next and finish. Next open an elevated Powershell session and run this cmdlet:

Import-Module AzureADPasswordProtection

Register the Proxy interactively, please sign-in with a global administrator role.

Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'

Next, also register the forest with a global admin:

Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'

To guarantee the installation was successful, I would consider a look to the services:
proxy-services

And in the event viewer under Applications and Services Logs, Microsoft, Proxy Service, Operational reveals, that the proxy has started successfully.
proxy-eventvwr-1


Install the AD Agent

Now we're installing the AD Agent on each domain controller. The setup should also be straightforward. Here is the service:
adagent-services

And here is the event log, there you can see the configurations and that the Azure password policy is enforced locally.
adagent-eventvwr


Audit mode - impact report

It's important to understand if and how much the users are using weak words in their passwords. If set to Audit mode, you can run the following Powershell cmdlet, to see the statistics of password changes.

Get-AzureADPasswordProtectionSummaryReport

This yields this output. Important to see is PasswordChangeAuditOnlyFailures and PasswordSetAuditOnlyFailures, which count passwort set and changes, that would theoretically fail, if the policy was set to Enforced.

DomainController                : dc.domain.local
PasswordChangesValidated        : 20
PasswordSetsValidated           : 10
PasswordChangesRejected         : 0
PasswordSetsRejected            : 0
PasswordChangeAuditOnlyFailures : 2
PasswordSetAuditOnlyFailures    : 6
PasswordChangeErrors            : 0
PasswordSetErrors               : 0
You’ve successfully subscribed to Oceanleaf
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.