Azure AD password protection preview for on premise Active Directory
In this article we will have a look at enabling Azure AD password protection policy in On Premise Active Directory Server.
By Default this feature is enabled for cloud only users with a basic filter of Azure AD password protection with global banned password list.However if we still require Azure AD password protection with custom banned password list for Cloud only users then we would need to have at-least Azure AD Basic License the default value is below.
https://exchangequery.files.wordpress.com/2018/12/Untitled.png?w=600
We have below options in password protection policies:
Lockout Threshold:
How many failed sign-ins are allowed on an account before its first lockout. If the first sign-in after a lockout also fails, the account locks out again.
Lockout Duration in Seconds:
The minimum length in seconds of each lockout. If an account locks repeatedly, this duration increases.
Enforce custom list:
When enabled, the words in the list below are used in the banned password system to prevent easy-to-guess passwords.
Custom banned password list:
A list of words, one per line, to prevent your users from using in their passwords. You should include words specific to your organization, such as your products, trademarks, industries, local cities and towns, and local sports teams. Your list can contain up to 1000 words. These are case insensitive, and common character substitutions (o for 0, etc) are automatically considered.
Enable Password protection on active directory:
If set to Yes, password protection is turned on for Active Directory domain controllers when the appropriate agent is installed.
Mode:
If set to Enforce, users will be prevented from setting banned passwords and the attempt will be logged. If set to Audit, the attempt will only be logged.
The Visual representation of how this process works is beautifully shown below from Microsoft technet Source
https://exchangequery.files.wordpress.com/2018/12/pp5.png?w=600
Below are the prerequisites for enabling the password protection on Active Directory:
- For enabling this service on On Premise Active Directory it requires an Azure AD premium license.
- A proxy service agent needs to be installed on a member server running windows server 2012 R2 or later.
- Domain controllers where the Azure AD password protection DC agent service will be installed must be running Windows Server 2012 or later.
- All servers running the azure AD components must be fully patched in-order to have Universal C runtime installed.
- Network connectivity must be present between the Azure AD proxy server and one domain controller running Azure agent Service.
- An Azure AD global administrator account is required to register and consume this service for On Premise AD in Azure AD.
- A local domain admin privilege account is required to register windows server AD with Azure AD.
- Domain running the DC agent service must use the DFSR replication type for SysVol Replication.
- Azure AD password protection proxy service server must have access to the below Microsoft Protection Endpoints.
https://login.microsoftonline.com – For Handling the Authentication Requests.
https://enterpriseregistration.windows.net – Azure AD password protection functionality
Download the 2 agents from link – https://www.microsoft.com/en-us/download/details.aspx?id=57071
https://exchangequery.files.wordpress.com/2018/12/Untitled-2.png?w=600
After download we will have 3 installers as below.
https://exchangequery.files.wordpress.com/2018/12/Untitled-3.png?w=600
Azure AD Password Protection Proxy Service – It acts as a proxy agent which will forward outgoing requests from domain controllers to Azure AD and incoming requests from Azure AD to the on premise domain controller.
https://exchangequery.files.wordpress.com/2018/12/Untitled-4.png?w=600
DC Agent password filter dll – Will receive all the password validation requests and forward them to the main component running in onpremise Domain Controller which is Azure AD password protection DC agent.
Azure AD password protection DC agent- Receives the password validation request from the filter agent and processes them with the currently present local password policy and returns the validation response Pass/Fail. This core services queries the Azure AD password protection proxy service to check and download the new versions of password policy.
https://exchangequery.files.wordpress.com/2018/12/Untitled-5.png?w=600
First step we need to install the proxy agent on a member server which in the same domain.
Once installation is completed Import the Module –
Import-Module AzureADPasswordProtection
Register the Proxy Agent –
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds
Enter the Domain Admin Credentials
https://exchangequery.files.wordpress.com/2018/12/Untitled-8.png?w=600
Later Enter the Azure Global Admin Credentials
https://exchangequery.files.wordpress.com/2018/12/Untitled-9.png?w=600
Later Register the Active Directory Forest –
Register-AzureADPasswordProtectionForest
On a successful registration we will be getting the below event log on the Azure AD password protection Proxy Server.
https://exchangequery.files.wordpress.com/2018/12/image-2-1.png?w=600
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds
Register the Proxy configuration on a static Port-
Below command can be run to make the proxy service communication and DC Agent Service to run on a static specific port. This option is preferred to keep a static single port communication from this proxy service server and the Domain Controller and not to have IP to IP communication between them.
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort 135
Install the DC agent on the Domain Controller. After the installation is complete only a restart is required and no further configuration is required at this stage.
After this login to Azure AD and enabled the password protection on Windows server Active Directory. Always strictly recommended to start only in Audit mode to understand the current password security and user compliance from the logs.
https://exchangequery.files.wordpress.com/2018/12/image-1.png?w=600
Once enforced in audit mode we get the below confirmation message in Azure Password protection DC Agent Event logs.
https://exchangequery.files.wordpress.com/2018/12/image-2.png?w=600
We can verify the password protection agent settings by below commands
Get-AzureAdPasswordProtectionDCAgent | FL
https://exchangequery.files.wordpress.com/2018/12/Untitled-10.png?w=600
Get-AzureADPasswordProtectionSummaryReport -DomainController DCHostName
https://exchangequery.files.wordpress.com/2018/12/Untitled-13.png?w=600
Its always better to start this operation by only keeping them in Audit mode since it will create a major impact in the environment without proper end user awareness about enforcing this password policy change.
Also we can monitor the logs in event viewer in below location
A user resetting the password with the compliant characters will get a successful log as below
https://exchangequery.files.wordpress.com/2018/12/Untitled-11-1.png?w=600
If there was a non-complaint password reset by a help-desk operator it would be logged in the audit mode and mention it did not meet the compliant standards.
https://exchangequery.files.wordpress.com/2018/12/Untitled-14.png?w=600
When the same password is provided to end user and when the end user resets them with non-compliant values then those entries also will be logged in the event viewer.
A Successful password policy update from Azure AD can be seen below from the Azure AD password protection proxy server.
https://exchangequery.files.wordpress.com/2018/12/image.png?w=600
We can also see that a separate Container is created in ADSI Edit and can see 2 certificates folder created with thumbprint name.
https://exchangequery.files.wordpress.com/2018/12/Untitled-15.png?w=600
Important Notes:
- As a best practice its not recommended to go with enforce mode initially since the end users will have tough time adopting the password policy immediately.
- Once the audit mode is enabled better to circulate email floaters about the upcoming password policy change which will create better awareness.
- The custom banned password policy is capable of having 1000 entries. We can gradually increase the value which will make this roll out in a smoother way.
- If we are updating the global banned password in the azure portal they are pushed down to the on premise agents in a polling interval of 1 hour time period.
- To Register-AzureADPasswordProtectionForest cmdlet to succeed at least one Windows Server 2012 or later domain controller must be available in the proxy server’s domain.