In this series I am going to step through how to help secure your internal infrastructure through the use of modern tools both running both within Azure AD and on your internal AD infrastructure. These tools should be considered to provide a good security baseline for your user accounts as part of your overall approach to securing your infrastructure and ultimately your data.

  1. Implementing Modern Security Tools – Part 1 – Azure AD Password Protection
  2. Implementing Modern Security Tools – Part 2 – Microsoft LAPS
  3. Implementing Modern Security Tools – Part 3 – Conditional Access

The Password Issue

End users have traditionally been one of the weakest parts of your security infrastructure due to the use of weak passwords, however a single entry-point to your network has often provided sufficient protection (or at least you have believed it did). With the modernisation of IT services and the adoption of cloud based services, the traditional single point of entry to your network or data has changed significantly.

Today potential for compromised security accounts providing access to multiple systems without having to cross the threshold of your corporate network brings new challenges, thankfully Microsoft are making big steps to address this issue including tools such as MFA and FIDO2 authentication methods.

Released earlier this month, Azure AD Password Protection is the newest addition to the list of tools you should familiarise yourself with in this case.

Azure AD Password Protection

Azure AD Password Protection is a new tool which is currently available in preview and provides you with the ability to have a filter for password changes, providing you with a checking mechanism to mitigate against commonly used and provide custom password criteria.

This type of process will be somewhat familiar to you if you have used security tools like SpecOps Password Policy in the past, and although in its current incarnation it is not as feature rich as some of the third party tools, it is a great step in the right direction.

So lets run through the highlights of the new Azure AD security feature;

  • Provides protection against 500 of the most commonly used weak passwords along with over 1 million character substitutions. Lets face it P@ssw0rd1 is something we have all seen at some point used in order to satisfy password complexity requirements
  • Provides protection not only for Azure AD housed accounts, but also for your on-premise active directory accounts through the use of a proxy service
  • Provides intelligent account lock out
  • Provides custom password matching
How Does It Work?

The process is straight forward, in this example lets step through a password change process on an network with multiple domain controllers within a single AD forest and a single Azure AD Password Protection Proxy.

  1. The end user initiates a password change against their local domain controller
  2. The password is checked against the domain password complexity settings
  3. Once the password satisfies the internal complexity settings it is passed through to the Azure Password Protection Proxy
  4. The Azure Password Protection Proxy service communicates with the Azure AD tenant used to set up the service
  5. The password is compared against the configured password policy
  6. If the password complexity is sufficient the password change is committed to the Sysvol store, otherwise the end user is informed that their password does not meet the complexity requirements
How To Implement Azure AD Password Protection

Implementation is extremely straight forward and simple, it requires a domain member server to house the proxy service (although for testing purposes in my own lab I have used one of my lab DC’s without an issue, it is a test environment.. don’t do this in production). Typically this member server can be multi functional, for the majority of customers I deal with the on-premise AD connect or MFA server will serve this purpose well.

So lets look over the pre-requisites over first:

  • All domain controllers and member servers used to host the proxy service must be running at least Windows Server 2012
  • All domain controllers must be using DFSR for sysvol replication (Visit this link if you need to step through this process – https://blogs.technet.microsoft.com/filecab/2014/06/25/streamlined-migration-of-frs-to-dfsr-sysvol/)
  • Global administrator (Azure AD) and domain administrator accounts are required
  • Internet access is required from the member server housing the proxy role

With the pre-requisites out of the way you will need to download both the proxy and DC agents from the following URL – https://www.microsoft.com/en-us/download/details.aspx?id=57071. Once downloaded the proxy service can be installed on the member server allocated for the proxy role.

The Password Protection Proxy

Run the downlaoded AzureADPasswordProtectionProxy.msi installation using your favorite method, be it manual or via PowerShell for example:

Start-Process .\AzureADPasswordProtectionProxy.msi -Argumentlist "/quiet /qn"

With the proxy agent installed we now must register the computer with Azure AD for the purpose of housing this role, to do so you will need to open a new PowerShell window and import the Azure AD cmdlets by running the following command:

Import-Module AzureADPasswordProtection

Once imported you should now have the following list of commands available to you;

Now we can register the proxy with Azure AD from the PowerShell console using the following;

$AdminCredentials = Get-Credential 
Register-AzureADPasswordProtectionProxy -AzureCredential $AdminCredentials

Now we need to register the AD forest that is going to be protected, to do so go back to the PowerShell console and type the following;

$AdminCredentials = Get-Credential 
Register-AzureADPasswordProtectionForest -AzureCredential $AdminCredentials
Domain Controller Agents

With the proxy now in place we can move onto the next step, installing the DC agents. The agents must be installed on all writable domain controllers, read-only domain controllers are not required as they only relay the password changes. To install the agent you to deploy the AzureADPasswordProtectionDCAgent.msi installer either via GPO, ConfigMgr or manually such as in the following example:

Start-Process .\AzureADPasswordProtectionDCAgent.msi -Argumentlist "/quiet /qn"
High Availability

High availability of this system will be a consideration when implementing, as you would not like to get into a scenario where password policies can be circumvented due to a server being down for maintenance. Thankfully this is catered for, at the time of writing the preview supports a maximum of two proxies per forest for HA purposes. The proxies are accessed in a round-robin fashion from the domain controllers and in the event of a loss of both proxies, the cached password policy will be used to enforce compliance.

Password Policies

To configure the service you will need to sign in to your Azure tenant. Once logged on go to the Azure Active Directory blade (1), click on Authentication Methods (2) and the options will be displayed on the right hand side.

It is recommended that you first of all implement the service in audit mode prior to enabling the feature as this will provide you with feedback that the service is working without causing any unexpected issues.

To enforce the policy just click on the “Enforced” mode as per the screenshot below;

How Do I Check It Is Working?

To verify if the service is working simply open the console and use the following command to display the running statistics;

Get-AzureADPasswordProtectionSummaryReport

To test if the password policies are being applied there are a number of things you can do. First of all let’s review the sysvol to ensure that the policy is present, simply browse to the following location and you should see contents similar to the folder pictured below;

\\YOURLOCALDOMAIN\Sysvol\YOURLOCALDOMAIN\Policies\{4A9AB66B-4365-4C2A-996C-58ED9927332D}\AzureADPasswordProtection

Now you can simply attempt to change the password for a user, or create a new user in Active Directory and you should see screens similar to the ones below:

This slideshow requires JavaScript.

You can also view the event logs on your writable domain controllers to ensure everything is working. In the below example you will see that the password was rejected as it was non compliant;

So that concludes part 1 of this series, in part 2 I will revisit using Microsoft LAPS to secure local administrator accounts across your internal environment. For further documentation and FAQ’s on Azure AD Password Protection please visit the following documentation links;

https://cloudblogs.microsoft.com/enterprisemobility/2018/06/19/azure-ad-password-protection-and-smart-lockout-are-now-in-public-preview/
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises

Thanks for reading!

(2688)

Maurice Daly

Maurice has been working in the IT industry for the past 18 years and currently working in the role of Principal Consultant with TrueSec. With a focus on OS deployment through SCCM/MDT, group policies, active directory, virtualisation and office 365, Maurice has been a Windows Server MCSE since 2008 and was awarded Enterprise Mobility MVP in March 2017.

There are no comments.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.