Pages

Thursday, April 9, 2020

Deploying Azure AD Password Protection for on-premise Active Directory

Improving the security of user authentication has always been a top priority for many organizations and one of the products I’ve been working with which has become very popular is Microsoft’s Azure AD Password Protection. For those who are not familiar with this Microsoft offering, this product essentially allows you to leverage the password protection Azure provides to cloud accounts to be extended to your on-premise Active Directory. The following are some highlights of the product:

  • Global banned passwords list > Microsoft has compiled and continue to maintain a list of passwords that their security team has deemed to be a security risk rom real-world security telemetry on actual password spray attacks. This list is not disclosed to the public because it would render it ineffective.
  • Custom banned password list > Organizations can use this feature to ban passwords they deem to be a security risk. These passwords are generally company and product names, location, and other words that can be easily guessed because it relates to the company in some way or another. Note that there is a 16 character limit.
  • Advanced password evaluation > Microsoft outlines the method they use to evaluate the strength of a password (https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad) that includes normalization and banned lists. A score is calculated based on the formula outlined in the document I provided and I would say that it is a great method.
  • Augments on-premise Active Directory password policy > Azure AD Password Protection (and its 8 character limit) does not replace the on-premise password policy but rather extends it. The on-premise password policy configuration will be enforced for users.
  • Reduced dependency on Azure > Azure AD password hash sync is not a requirement and the on-premise domain controllers do not need to constantly connect to Azure through the proxy service for password checks as the policy is downloaded locally every hour. In the event that registered proxy servers are not available, the Azure AD Password Protection DC agents continue to enforce their cached password policy.
  • Domain controllers does not need to maintain a persistent connection to Azure > The domain controllers rely on the Azure AD Password Protection Proxy Service to retrieve the password policy so there is no requirement to open additional outbound access.
  • Audit mode > You can’t actually turn Azure AD Password Protection for a subset of your on-premise Active Directory but you are provided with an audit mode that logs whether a password would have been accepted or rejected. I typically use this with a group of pilot users during the test phase.

There are an abundance of documentation provided from Microsoft that I found useful when I need refresh my memory so I will list them here:

Enforce Azure AD password protection for Windows Server Active Directory – How Azure AD Password Protection works
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/concept-password-ban-bad-on-premises

Plan and deploy on-premises Azure Active Directory Password Protection – Deployment guide
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy

Eliminate bad passwords in your organization – How passwords are evaluated and how global and custom banned password lists work
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad

Enable on-premises Azure Active Directory Password Protection – Enabling and disabling the password policy for testing and production
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/howto-password-ban-bad-on-premises-operations

Password Guidance – Some of the information is a bit dated as the publication was written in May 2016 but the concepts are still useful
https://www.microsoft.com/en-us/research/publication/password-guidance/

With all the information provided above, let’s proceed with the deployment.

Environment Prerequisites

  • The installers for the proxy and DC agent are available to be downloaded without a login and can be retrieved at the following URL: https://www.microsoft.com/en-us/download/details.aspx?id=57071
  • Azure AD Premium P1 license licenses are required for the organization
  • You can deploy both the Azure AD Password Protection Proxy Server and DC Agent directly on a domain controller for testing but this is not recommended, instead, have at least 1 x Azure AD Password Protection Proxy Server residing on a member server in the domain and the DC Agent installed on all the domain controllers
  • Multiple forests are supported but if each Azure AD Password Protection Proxy Server can only support one forest and its domain controller
  • Do not install the Azure AD Password Protection Proxy Server on a RODC as it is not supported
  • Load balancers are not necessary as the Azure AD Password Protection DC agent uses a simple round-robin-style algorithm when deciding which proxy server to call
  • All of the servers, including the domain controllers, need to have the Universal C Runtime installed
  • The Key Distribution Service must be enabled on all domain controllers in the domain that run Windows Server 2012. By default, this service is enabled via manual trigger start
  • Network connectivity over RPC endpoint mapper port 135 and the RPC server port must exist between at least one domain controller in each domain and at least one server that hosts the proxy service
  • All servers that have the Azure AD Password Protection Proxy service installed must have network access to the following endpoints:

Azure AD Password Protection DC agent Requirements

  • The install requires a server reboot
  • Operating system must be Windows Server 2012 or later
  • Domain and forest functional does not need to be Windows Server 2012
  • .NET 4.5 must be installed
  • The domain controllers should be using Distributed File System Replication (DFSR) for sysvol replication

Azure AD Password Protection proxy service Requirements

  • The install does not require a server reboot
  • Operating system must be Windows Server 2012 or later
  • .NET 4.5 must be installed
  • Must be configured to grant domain controllers the ability to log on to the proxy service (this ability is controlled via the "Access this computer from the network" privilege assignment)
  • Outbound TLS 1.2 HTTP traffic allowed
  • A Global Administrator account will be used to register the proxy service and forest with Azure AD
  • Network access must be enabled for the set of ports and URLs specified here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application#prepare-your-on-premises-environment
  • HTTP proxy is supported but additional configuration must be performed (this post will not demonstrate the configuration)

Microsoft Azure AD Connect Agent Updater prerequisites Requirements

The Microsoft Azure AD Connect Agent Updater service is installed along with the Azure AD Password Protection Proxy service. In the event where any of the following applies, further configuration would be required:

Configure Azure AD Password Protection

Enable the Azure AD Password Protection service by logging into https://portal.azure.com and navigating to Azure Active Directory > Security > Authentication Methods > Password Protection and configure the following:

Enable password protection on Windows Server Active Directory: Yes
Mode: Audit

image

Deploying the Azure AD Password Protection Proxy service

Begin by verifying that .NET 4.5 or later is installed by executing the following cmdlet:

Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" | Format-List

image

Compare the version number with the following table to verify that a supported version is installed:

image

Verify that the Windows Firewall service is running:

image

Proceed to install the Azure AD Password Protection Proxy service onto the proxy server:

image

image

image

image

Launch PowerShell and execute the following cmdlet to verify that the proxy service has been installed:

Import-Module AzureADPasswordProtection

Get-Service AzureADPasswordProtectionProxy | FL

image

Proceed to register the proxy service with the following cmdlet:

Register-AzureADPasswordProtectionProxy -AccountUPN '<yourGlobalAdministrator@onmicrosoft.com>'

**Note that I’ve had two deployments where an error thrown but the second try completes:

image

Proceed to register the on-premises Active Directory forest with the following cmdlet:

Register-AzureADPasswordProtectionForest -AccountUpn '<yourGlobalAdministrator@onmicrosoft.com>'

image

You can verify the registration by reviewing the Audit Logs entries in the Azure portal:

Target: AADPasswordProtectionProxy

image

**Note that if there is an HTTP proxy in the environment for machines to reach the internet then there are extra steps required to be performed. The environment in this example does not have a HTTP proxy so I will not be demonstrating the process.

Deploying the Azure AD Password Protection DC Agent

Begin by verifying that DFSR is used to replicate the sysvol folder by executing the following cmdlet:

Get-ItemProperty -Path "HKLM:SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols" | Format-List

image

The Local State value should be 3. The following is where the parameter and value is stored in the registry:

image

Verify that .NET 4.5 or later is installed by executing the following cmdlet:

Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" | Format-List

image

Compare the version number with the following table to verify that a supported version is installed:

image

Ensure that the Kerberos Key Distribution Center service is started:

image

Verify that the Windows Firewall service is running:

image

Proceed to install the Azure AD Password Protection DC Agent onto the Domain Controller server:

image

image

image

image

Proceed to restart the domain controller:

image

Once the domain controller has been successfully restarted, verify that the Azure AD Password Protection DC Agent service has started:

image

Proceed by launching the Event Viewer then navigate to Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin and verify that the following event ID is logged indicating that the agent is successfully enforcing the Azure password policy:

Source: DCAgent
Event ID: 30006
Level: Information
User: System

The service is now enforcing the following Azure password policy.

Enabled: 1
AuditOnly: 1
Global policy date: ‎2019‎-‎11‎-‎03T00:00:00.000000000Z
Tenant policy date: ‎2020‎-‎02‎-‎20T22:35:50.188026500Z
Enforce tenant policy: 1

image

Review the Operational log and verify that the following event is logged:

Source: DCAgent
Event ID: 10000
Level: Information
User: System

The password filter dll has successfully loaded and initialized.

image

You should also see the following event logged indicating the agent has starting:

Source: DCAgent
Event ID: 20000
Level: Information
User: System

The Azure AD Password Protection DC Agent service is starting.

image

The following event will verify that the agent has started:

The Azure AD Password Protection DC Agent service has successfully started.

image

The following event will also be logged indicating that the specified certificate is used to authenticate with Azure:

The following forest certificate credential is being used for authentication to Azure.

Forest certificate thumbprint: FC5E044348BB950D3B3B515F5B39830B532E1C1D
Forest certificate NotBefore: ‎2020‎-‎02‎-‎20T21:30:21.000000000Z
Forest certificate NotAfter: ‎2021‎-‎02‎-‎20T09:25:17.000000000Z
Forest certificate object DN: CN=1192827B-F3E2-4B12-95A7-2070859A5C23,CN=Forest Certs,CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=corp,DC=domain,DC=com

image

Test Azure AD Password Protection

Prepare a test plan with multiple passwords to test and verify that the expected outcome is achieved. The following is an event that would be logged if the password is not expected to be accepted but is allowed because audit mode is configured:

Source: DCAgent
Event ID: 30029
Level: Information
User: System

The reset password for the specified user would normally have been rejected because it matched multiple tokens in the combined Microsoft global and per-tenant banned password list of the current Azure password policy.

The current Azure password policy is configured for audit-only mode so the password was accepted.

UserName: testuser
FullName: Test User

image

The following is an event that would be logged if the password is accepted because it is compliant with the Azure password policy:

Source: DCAgent
Event ID: 10015
Level: Information
User: System

The reset password for the specified user was validated as compliant with the current Azure password policy.

UserName: testuser
FullName: Test User

image

The following is an event that would be logged if the user of a custom banned password is detected:

Source: DCAgent

Event ID: 30003

Level: Information
User: System

The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy.

UserName: username
FullName: username

image

Enforcing Azure AD Password Protection

When testing of the password policy with pilot users is complete, proceed and switch the Mode from Audit to Enforced:

image

----------------------------------------------------------------------------------------------------------------------------

Other notable items

It is important to note that you should leverage your on-premise password policies to enforce a minimum password length as Azure defaults to 8 characters. I always suggest to use the Password Settings Object (PSO) instead of the Default Domain Policy GPO because of the added flexibility and there have been environments where modifying the Default Domain Policy GPO did not enforce the configured minimum password length I wanted.

As mentioned earlier, there is a 16 character limit for banned passwords:

image

The following Azure AD Password Protection object will be created in the Configuration container after a successful deployment of Azure AD Password Protection:

image

Tuesday, April 7, 2020

Attempting to use a Chrome or Edge browser to access an Windows Server 2019 ADFS server with DUO MFA displays the message: "Request to the server has been blocked by an extension."

Problem

You’ve deployed a new Active Directory Federation Services (ADFS) farm on Windows Server 2019 and integrated DUO MFA with the portal so users logging onto Office 365 would be redirected to the ADFS portal protected by DUO 2FA but notice that using a Chrome or Edge browser fails to display the DUO authentication prompt and presents the following error:

Request to the server has been blocked by an extension.

image

Internet Explorer 11 does not exhibit this issue.

Performing a Google search for the error reveals that this is a known issue as described in the following DUO KB:

How do I resolve the error "Request to server has been blocked by extension" when logging in to Duo-protected AD FS on Server 2019?
https://help.duo.com/s/article/4832?language=en_US

image

In Windows Server 2019, Microsoft introduced a new security feature to allow for custom HTTP headers to be sent by AD FS. As a result there are more restrictive policies around displaying the Duo Prompt.

You proceed to implement the suggested additional configuration frame-src api-xxxxxx.duosecurity.com to the Content Security Policy (CSP) to the ADFS response headers as suggested but continue to receive the error.

Solution

--------------------------------------------------------------------------------------------------------------------------

Update: April 26, 2020

It appears the article:

How do I resolve the error "Request to server has been blocked by extension" when logging in to Duo-protected AD FS on Server 2019?
https://help.duo.com/s/article/4832?language=en_US

… was not clear that you are supposed to replace the hostname api-xxxxxx.duosecurity.com in both of the supplied options with the Duo hostname. To correct this issue, you can log onto the Duo administrator portal and retrieve the specific hostname for the application it is protection:

image

Or you can proceed to use a wildcard URL as I outlined below.

--------------------------------------------------------------------------------------------------------------------------

I’m not completely sure what date the article was written as I could not find any reference but I’ve come across a similar issue a while ago as outlined in the following post:

Configuring Content-Security-Policy HTTP Response Header on Citrix ADC for Citrix Apps and Desktops with DUO integration
http://terenceluk.blogspot.com/2020/02/configuring-content-security-policy.html

I had not seen the DUO knowledge base article during the troubleshooting in my blog post but the extra frame-src api-xxxxxx.duosecurity.com made sense as it explicitly specifies the URL to begin with api- followed by 5 characters and finally .duosecurity.com. However, as implementing the following cmdlet didn’t work:

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self'; frame-src api-xxxxxx.duosecurity.com "

I took another look at the second cmdlet that is suggested if the CSP has already been configured and noticed that the API hostname string had only 5 X, rather than 6 in the cmdlet above:

$apihostname = "api-XXXXX.duosecurity.com"

$CSP = ((Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders).'Content-Security-Policy')

$CSP = $CSP + "; frame-src " + $apihostname

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue $CSP

I tried modifying the CSP to include only 5 X but that did not correct the issue.

Troubleshooting at a deeper level with the developer tools revealed that frame was trying to load the following URL: https://api-8fe1dff4.duosecurity.com/

Refused to frame 'https://api-8fe1dff4.duosecurity.com/' because it violates the following Content Security Policy directive: "frame-src api-xxxxxx.duosecurity.com".

image

This did not match the allowed string so I followed the same configuration I used in my previous blog post and simply allowed all subdomains for duosecurity.com as such:

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self'; frame-src *.duosecurity.com "

image

**Note that the ResponseHeaders value gets truncated and will not display the full configuration unless you change the $FormatEnumerationLimit value to -1 by executing: $FormatEnumerationLimit=-1

The page began to load properly on Edge and Chrome once the above configuration was made.

image

I’m always open to corrections to my posts so please feel free to leave a comment if there is a better way of handling this.

Sunday, April 5, 2020

Creating an Office 365 Exchange Online transport rule to prepend a disclaimer for inbound external emails with a specific display name

I feel that every organization has at some point received phishing emails where the attacker impersonates a high level executive such as a CEO to email a CFO or someone in finance in the organization to try and have funds urgently transferred to an account. These phishing attempts can be very difficult to adequately protect because the attacker can easily create an email account from a legitimate service such as Gmail with the CEO’s name concatenated with perhaps a number at the end. The display name will only show the first and last name of the CEO and some users could potentially miss that the email address is not from within their organization. There are many products available that addresses this and one that I am familiar with is Office 365 Advanced Threat Protection which provides a feature named mailbox intelligence which has the following configurable actions:

image

Being able to purchase ATP would be dependent on the size of the organization and whether they’re able to afford the additional licenses but in the event that they are not able to, I would like to demonstrate a possible Exchange Online transport rule solution that can prepend a disclaimer for the incoming email. Note that this wouldn’t be very scalable as you would have to either configure separate rules for each user with a disclaimer identifying the user or have one rule configured for specific users but use a generic disclaimer.

Begin by navigating to mail flow > rules:

image

Create a new rule:

image

Provide a name for the rule and configure a condition specifying that The sender is located… with the setting Outside the organization:

image

Add another condition specifying A message header… with the setting matches these text patterns:

image

Add the full name of the user into the specify words or phrases window:

image

In the Do the following… field, you can select any of the actions you would like to execute when such a message with the matching display name but for this example we will use prepend a disclaimer:

image

You are free to use HTML to format the disclaimer and the following one I included is a yellow text box with the warning Caution: This is an external email from John Smith:

image

<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0

style='border-collapse:collapse;mso-yfti-tbllook:1184;mso-padding-alt:0in 0in 0in 0in'>

<tr style='mso-yfti-irow:0;mso-yfti-firstrow:yes;mso-yfti-lastrow:yes;

height:11.9pt'>

<td width=323 valign=top style='width:242.35pt;border:solid #2A3B48 1.0pt;

background:#F4DF11;padding:0in 5.4pt 0in 5.4pt;height:11.9pt'>

<p class=MsoNormal><b><span style='font-size:9.0pt;color:#993922'>CAUTION: </span></b><span

style='font-size:9.0pt'>This is an external email from John Smith <o:p></o:p></span></p>

</td>

</tr>

</table>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

Review and add any additional conditions such as The recipient is… with your own email to test the rule before adding it globally:

image

Proceed to test by sending an email from an external domain with the specified display name you created in the rule to verify that the emails are prepended with a disclaimer.

----------------------------------------------------------------------------------------------------------------------------

Other layers of protection you can add in addition to this are as follows:

Enabling Mail Tips for that warn users when they send an email with external recipients

This needs to be enabled at a global level so either everyone gets the mail tip or no one does so proper communication needs to be made to the organization.

Execute the following cmdlet to determine review the setting:

Get-OrganizationConfig | FL *mailtips*

Note that the screenshot below indicates it is currently set to False. To enable it, execute the cmdlet:

Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $true

image

Users will notice the following when they have an email with external recipients in the To field:

image

Prepending a disclaimer for all external emails

You can create a transport rule similar to the one described in this post but omit the condition for the header and tag all external emails entering the organization. If you choose to implement this then I would suggest changing the action for the rule that matches a display name so you don’t end up inserting two disclaimers.

Creating a new Exchange Online transport rule with the condition "has specific properties matching these text patterns" does not allow you to configure and add a user property

Problem

You would like to configure a new transport rule in Exchange Online with one of the following conditions:

  • has specific properties including any of these words
  • has specific properties matching these text patterns

You proceed by navigating to mail flow > rules:

image

Create a new rule:

image

Then add the condition The Sender > has specific properties matching these text patterns or has specific properties including any of these words:

image

… but you notice that the select user properties window is laid on top of the window where you are supposed to configure the User properties field:

image

You are unable to edit the User properties field unless you click on the Cancel button for the select user properties window:

image

Proceeding to configuring a user property and clicking OK will bring you back to the main configuration page for the rule without applying the changes you made:

image

Clicking on the Select properties and text patterns… link returns you to the previous issue where the select user properties window is presented:

image

… but clicking the + button will bring up the window User properties window behind it and seemingly stuck:

image

Using Chrome or Edge exhibits the same behavior and testing this on a on-premise Exchange Server 2016 (Version 15.1 Build 1591.10) yields the same result.

Solution

This issue threw me off for quite some time as I thought I was doing something wrong interactively so after not having any luck from searching through posts online, I opened a call with Office 365 support and the engineer eventually told me this was a bug and the solution was to use Internet Explorer. The Internet Explorer I had on my Windows 10 laptop is shown in the screenshot below and it indeed resolves the issue.

image

Saturday, April 4, 2020

Adding Email Address / ProxyAddress to an O365 mailbox for a user account that is synced with an on-premise Active Directory

I’ve recently been asked a few times about a common issue that many on-premise Exchange administrators encounter when transitioning to Office 365 so I thought I’d write a quick blog post outlining how to modify or add email addresses to an Office 365 mailbox for a user account that is synced with an on-premise Active Directory.

Problem

You attempt to use the Exchange Admin Center to add an additional email address or modify the primary email address of an Office 365 mailbox but receive the following error:

The operation on mailbox "<username>" failed because it's out of the current user's write scope. The action 'Set-Mailbox', 'EmailAddresses', can't be performed on the object '<username>' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

image

Attempting to use the Microsoft 365 admin center yields the same results:

image

image

The operation on mailbox "TestO365" failed because it's out of the current user's write scope. The action 'Set-Mailbox', 'EmailAddresses', can't be performed on the object 'TestO365' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

image

Solution

The way to add or modify email addresses for Office 365 mailboxes for user accounts that are synced with an on-premise Active Directory is to modify the proxyAddress attribute for the user account:

image

Prepending the email address with SMTP: capitalized will configure the primary email address for the account:

image

Additional email address aliases can be configured with smtp: in lower case.

Once the changes have been made to the account from the on-premise Active Directory, proceed to forcing a synchronization on the server with AD Connect to synchronize the changes to the account in Azure AD.

Start-ADSyncSyncCycle -PolicyType Delta

image