on-Premises Azure Active Directory Password Protection

Last year I wrote a blogpost on password in Azure Active Directory (Choose a password that’s harder for people to guess – https://jaapwesselius.com/2018/10/15/choose-a-password-thats-harder-for-people-to-guess/) in which I mentioned the banned password lists and the Azure AD Password Protect feature. Back then this was only for Azure AD, but right now it is also available for on-premises Domain Controller as well (for some time already). It is possible for on-premises Domain Controllers to use the password protect functionality in Azure AD and thus block the possibility to use weak passwords in your on-premises environment. Let’s see how it works.

The password protection feature on-premises uses a Password Protection Agent that’s running on the on-premises Domain Controllers. When a user initiates a password change, the new password is validated by the Azure AD Password Protection agent, which request a password policy from the Azure AD Password Protection proxy service. This Password Protection service requests a password policy from Azure AD. The new password is never sent to Azure AD. This is shown in the following picture (borrowed from the Microsoft website):

azure-ad-password-protection

After receiving the password policy, the agent returns pass or fail for the new password. In case of fail the user must try it again.

Installation of the password protect consists of two steps:

  • The Azure AD Password Protection Proxy service using the AzureADPasswordProtectionProxySetup.exe software installer. This is installed on a domain joined computer that has access to the Internet and proxies the password policy request to Azure Active Directory.
  • The DC Agent service for password protection by using the AzureADPasswordProtectionDCAgentSetup.msi package. This runs on the Domain Controllers and send the password policy requests to the server running the proxy service.

Both can be downloaded from the Microsoft download center on https://www.microsoft.com/en-us/download/details.aspx?id=57071

Password Protection Proxy Installation

The first step is to install the password protection service. This server should be able to access Azure AD and since the Domain Controller does not have an internet connection this should be installed on a separate server. In my lab environment I have installed the password protection service on the Azure AD Connect server.

Installation of the password protection proxy is straightforward; you can use the GUI or the command line setup with the /quit switch for unattended install (and Server Core). After installation use PowerShell to register the proxy in Azure AD by using the following commands:

[PS] C:\> Import-Module AzureADPasswordProtection
[PS] C:\> Register-AzureADPasswordProtectionProxy -AccountUpn 'administrator@tenant.onmicrosoft.com'

This command can work when you have MFA enabled for admin accounts, if you don’t require MFA on your admin accounts (which is a bad practice IMHO) you can use the following command:

[PS] C:\> $globalAdminCredentials = Get-Credential
[PS] C:\> Register-AzureADPasswordProtectionProxy -AzureCredential $globalAdminCredentials

The last step is to register the forest in Azure Active Directory. This is very similar to the registration process of the proxy service. You can use the following PowerShell commands to register the forest:

Register-AzureADPasswordProtectionForest

[PS] C:\> Register-AzureADPasswordProtectionForest -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’

Again, when MFA is not enabled you can use the following command to register your forest in Azure AD:

[PS] C:\> $globalAdminCredentials = Get-Credential 'yourglobaladmin@yourtenant.onmicrosoft.com'
[PS] C:\> Register-AzureADPasswordProtectionForest -AzureCredential $globalAdminCredentials

Note. A multi-forest scenario is supported for the Password Protection service, you can install multiple forest using these commands. Multiple domains against one tenant is supported, one domain against multiple tenants is a not-supported scenario.

Some remarks:

  • The server where the password proxy agent server is installed should have .NET Framework 4.7 or higher installed.
  • For high availability it is recommended to install the password protection agents on multiple servers
  • The password protection proxy supports an in-place upgrade, so a newer version can be installed without uninstalling the previous version.

So how does this work, and how does the password protection service find the proxy server (or servers)?

When the Password Protection Proxy is installed it is registered in Active Directory with a well-know GUID. The Password Protection Agent checks Active Directory for this well-know GUID and finds the server where the Password Protection Agent is installed.

You can use the following PowerShell commands to find the Password Protection Proxy:

$SCP = "serviceConnectionPoint"
$Keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter {objectClass -eq $SCP -and keywords -like $Keywords }

It returns the server, and you can use ADSIEdit to inspect the computer:

Azure AD Password Protection Proxy SCP

This is much like how domain-joined Outlook clients find the Autodiscover SCP in Active Directory.

Installing the DC agent service

When the proxy service is installed and registered the Domain Controller agent service can be installed. It is just an MSI package that can be installed (using the GUI, accept license agreement and click install) or you can install it on the command line using the following command (use elevated privileges):

C:\> msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn

Note. Installation of the DC agent requires a restart, but you can use the /norestart switch to reboot at a more convenient time.

After rebooting the Domain Controller the password protection service is ready for use.

Some remarks:

  • Azure AD Password protection service requires an Azure AD Premium P1 or P2 license.
  • Domain Controllers should be Windows 2012 or higher.
  • Domain Controllers should have .NET Framework 4.5 or higher installed.
  • You never know which Domain Controller is going to process a password change. Therefore, the Password Protection service need to be installed on all Domain Controllers. For a straightforward environment this should not be a problem, but for large enterprises with lots of DC’s it can be an issue (I deliberately do not that about security officers at this point :-))
  • Both the proxy service and the DC agent support an in-place upgrade, so a newer version can be installed without uninstalling the old version.

Testing the Azure AD Password Protection service

So, after installing the Password Protection Proxy and the DC agent it’s time to test which is relatively simple. Logon to a domain-joined workstation, use CTRL-ALT-DELETE to change the password. When using a simple password like “Summer2019” or something it fails with the following error message.

Unable to update the password

From this moment on it is no longer possible to use weak passwords, locally enforced by Azure Active Directory and again a step closer to a safer environment.

Exchange 2016 CU15 and Exchange 2019 CU4 released

On December 17, 2019 Microsoft has released its quarterly updates for Exchange Server:

  • Exchange 2016 CU15.
  • Exchange 2019 CU4 (only available via Volume License).

There are a couple of things that are worth noting:

  1. Both Exchange server versions need the .NET Framework 4.8. If you are running an older version of Exchange (much older) consult Michel de Rooij’s blogpost Upgrade Paths for CU’s and .NET.
  2. If you are running an Exchange Hybrid version there’s the n-1 policy. This means your on-premises versions of Exchange should be Exchange 2016 CU14 or Exchange 2019 CU3 at minimum.
  3. There’s an update on the Exchange calculator which is now version 10.3.
  4. There are no schema changes compared to the previous version so there’s no need to run Setup.exe /PrepareSchema. I always recommend running Setup.exe /PrepareAD to make sure any additional features or changes like (for example) RBAC are applied correctly.

So now real new features which is in line with Microsoft’s strategy. If you need the latest and greatest then Exchange Online is the way to go. If you need a stable on-premises environment you’re good with Exchange 2016 or Exchange 2019.

More information

Released: December 2019 Quarterly Exchange Updates
Exchange 2016 CU15 Download: https://www.microsoft.com/en-us/download/details.aspx?id=100780
Exchange 2016 CU15 UM Pack: https://www.microsoft.com/en-us/download/details.aspx?id=100781

 

Outlook 2010 stays offline with Exchange Online

One of my clients is running Exchange 2010 in hybrid mode, and they have Outlook 2010 and Outlook 365 ProPlus client. For testing purposes, I have two VMs, one with Windows 7 and Office 2010 and one with Windows 10 and Office 365 ProPlus. And every Monday morning I run the Windows 7 VM for an hour or so to see if everything is working fine 😊

This morning my Outlook 2010 was working offline, and it didn’t want to go online (OWA and Outlook 365 ProPlus were working fine). Remove the Outlook profile but creating a new Outlook profile didn’t work. After a minute the dreaded an encrypted connection to your mail server is not available error message appeared:

An encrypted connection to your mail server is not available

Mostly this is caused by Autodiscover that goes wrong somewhere, the Remote Connectivity Analyzer shows that Autodiscover to the on-premises Exchange 2010 goes well, but that the redirect to Exchange Online goes wrong and it generates the following error message:

An HTTP 456 Unauthorized response was received from the remote Unknown server. This indicates that the user may not have logged on for the first time, or the account may be locked. To logon, go to http://portal.microsoftonline.com.

And further down more details are revealed:

X-AutoDiscovery-Error: LiveIdBasicAuth:AppPasswordRequired:<RequestId=8a51c25b-9213-4873-aff8-ebc1da40544f>;

An HTTP 456 Unauthorized response was received from the remote Unknown server

The AppPasswordRequired explains more. Last week I changed the MFA settings (see previous authenticator app for Office 365 blogpost). This works fine for OWA and Office 365 ProPlus, but not for Outlook 2010. Since Outlook 2010 does not work with Office 365 MFA, especially not in a hybrid environment (not even with an App Password).

The only workaround here was to temporarily disable MFA for my user account, create a new Outlook profile (which worked fine without MFA) and re-enable MFA. Again, Outlook 2010 does not recognize the MFA and still works with Exchange Online using basic authentication, but all other Office 365 services work fine with Office 365 MFA (both SMS and Authenticator authentication).

Authenticator app for Office 365

I have been running MFA for Office 365 user accounts up-and-running for quite some time now and very satisfied with it. But as you may have seen in the blogpost, I have been running SMS only, and with a 30 days renewal that works fine. But I was also interested in the Authenticator app, especially when running multiple clients on mobile devices.

Changing the authentication can be done on a per-user basis. Logon to the Microsoft portal (portal.office.com) using your regular work account. Select My Account (under your thumbnail profile picture) and select Security and Privacy and click Additional security verification as shown in the following screenshot:

Select Update your phone numbers used for account security, check the Authenticator app or token checkbox and click Setup authenticator app button.

Scan the QR code on your mobile device in the authenticator app, confirm the registration, click Save and you’re all set. The next time you logon to Office 365 you’ll see the following Approve Sign in Request window:

But instead of entering a verification code received via SMS you must approve the sign in on the Authenticator app.