Step-By-Step: Implementing Azure AD Password Protection On-Premises
Published May 23 2019 12:00 AM 85.3K Views

I travel a lot in Italy, and many times I see multiple customers that are asking for the same requests. One request is the possibility to block some specific passwords in Active Directory. Unfortunately too many users have BAD habits and use the company name in the password field for example. In those cases, the Security team wants to block some easy and well known passwords.

 

In Active Directory you can Enable some GPO that can help you to implement strong password, like:

  1.  Minimum Password Length
  2.  Minimum Password Age
  3.  Maximum password Age
  4.  Password must meet complexity requirements
  5.  Enforce Password History

 

However, with a minimum password length of 8 chars and these GPOs, we unfortunately can't avoid the use of some well known Passwords like:
 

"P@$$w0rd" or "Pippo01!"

 

Azure AD Password Protection is finally what we need to enhance the password policies in your organization. With this feature, you can use the same checks for passwords in AzureAD on your on-premises Active Directory implementation. You can enforce both the Microsoft Global Banned Passwords and Custom banned-passwords list stored in Azure AD tenant.

 

What are the Design Principles?
 

Azure AD Password Protection is based on multiple design principles available here, but I would like to emphasize some of the most important ones:

  1. Your DCs never talk directly with Azure.
    (you need to install the Azure AD Password Protection Proxy Service)
  2. Your DCs will be never be exposed on the internet.
  3. There are no ports listening on the Domain Controllers for the Azure AD Password Protection DC Agent.
  4. All the services of the Azure AD Password Protection (Proxy Service and DC Agent) do not require any specific user to work, they use the  LOCAL SYSTEM account, but you will need a Global Admin of your tenant and a Domain Admins to register the Proxy Services and the Forest, but only one time.
  5. Do not require any schema update or specific DFL/FFL.
  6. The deployment of this solution supports the incremental deployments.

 

How does it work?

 

  1. A user requests a password change to a Domain Controller.
  2. The DC Agent Password Filter dll, receive from the OS, the password validation requests, and forward them to the  Azure AD Password Protection DC Agent, installed on the DC. This Agent then validate if the password is compliance with the locally stored Azure password policy.
  3. The Agent on the DC every 1h locate via the SCP (Service Connection Point) in the forest the Azure AD Password Protection Proxy Service to download a fresh copy of the Azure password policy.
  4. The Agent on the DC receives the new version of the Azure password policy from the proxy service and stores it in the Sysvol enabling this new policy to be replicated to all other DCs in the same domain.

The Azure Password policies are stored in Sysvol as shown here:

Sysvol_AADPP.png
It is not necessary that all the DCs are able to comunicate with the Azure AD Password Protection Proxy Server, if you have a very complex Active Directory environments, you can configure a minimum of one DC per domain to be able to connect to the AAD Password Protection Proxy Servers, and the other DCs will take the new policy from the Sysvol replication. However, on these DCs you will see some warning of this type:

Log Name:      Microsoft-AzureADPasswordProtection-DCAgent/Admin
Source:        Microsoft-AzureADPasswordProtection-DCAgent
Date:          15/05/2019 23:37:39
Event ID:      30018
Task Category: None
Level:         Warning
Keywords:     
User:          SYSTEM
Computer:      ITDC01.IT.CONTOSO.COM
Description:
One or more Azure AD Password Protection Proxy servers were found in the forest but this machine was unable to establish network connectivity to any of them.
 This operation will be run periodically and may succeed in future attempts
 This may be an expected and benign condition depending on how the network environment is configured.
 This domain controller may be able to obtain updated password policies via sysvol replication if other domain controllers do have proxy connectivity.

 

How can I deploy the Azure AD Password Protection?

The following is a an example of a simple scenario to understand how-to deploy this feature:

AADPP_schema.png

 

  1. Since your DCs never talk directly with Azure you need at least 2 Azure AD Password Protection Proxy Server per Forest for high availability and should be placed in the Root Domain. The Azure AD Password Protection Proxy Servers must be Windows Server 2012R2 or above.

  2. Download the Azure AD Password Protection software (Proxy and DC Agent):


    AADPP_software.png

     
  3.  Be sure to have installed .NET Framework 4.7 at minimum on these Proxy Servers.

  4. All the server DCs and Proxy Services require the Universal C runtime for Windows.
     
  5. Install the Proxy Service (AzureADPasswordProtectionProxySetup.exe) on the two Servers, joined to the root domain:
    Install_Proxy_1.pngInstall_Proxy_1.png
    Install_Proxy_2.png
    Install_Proxy_3.png
    You can also complete this via Silent installation from the command line

    With the installation of the Proxy Service completed, you can open PowerShell and can see a new module, AzureADPasswordProtection, installed.
     
    PS C:\> Get-Command -Module AzureADPasswordProtection
    
    CommandType     Name                                               ModuleName
    -----------     ----                                               ----------
    Function        Get-AzureADPasswordProtectionSummaryReport         AzureADPasswordProtection
    Cmdlet          Get-AzureADPasswordProtectionDCAgent               AzureADPasswordProtection
    Cmdlet          Get-AzureADPasswordProtectionProxy                 AzureADPasswordProtection
    Cmdlet          Get-AzureADPasswordProtectionProxyConfiguration    AzureADPasswordProtection
    Cmdlet          Register-AzureADPasswordProtectionForest           AzureADPasswordProtection
    Cmdlet          Register-AzureADPasswordProtectionProxy            AzureADPasswordProtection
    Cmdlet          Set-AzureADPasswordProtectionProxyConfiguration    AzureADPasswordProtection
     
    You can also open the event log and can see new Event logs for the installed Service:
     
    AADPPP_EventLogs.png

  6. All the DCs must be at least Windows Server 2012 or above. You now need to install the package "AzureADPasswordProtectionDCAgentSetup.msi":
    Install_Agent_1.png
    Install_Agent_2.png
    Install_Agent_3_Restart.png

    As you can see the DC Agents installation require the reboot of the DC and also in this case if you want you can use the Silent installation with the command line. But please remember to put the /norestart parameter to avoid the immediate restart of the DC.

    After the installation, on the DC you will see a new Eventlog for the agent:
    AADPPDCA_Eventlog.png

  7. By default the Azure AD Password Protection DC Agent use the TCP port 135 and the dynamic ports range to connect to the Azure AD Password Protection Proxy Servers, so this ports must be open at the network level, but if you prefer, you can configure the proxy Service to Listen on a specific ports.
    Set-AzureADPasswordProtectionProxyConfiguration –StaticPort <portnumber>
    This command must be executed on each proxy Server, and require the restart of the Proxy Service.

  8. You need to register on your Azure AD Tenant the two Proxy Server with a simple PowerShell cmdlet on each proxy:
    Register-AzureADPasswordProtectionProxy -AccountUpn 'admin@<yourtenant>.onmicrosoft.com'
    This registration of the Proxy Service is necessary only one time, for the first authentication on the tenant.

  9. You need to register the Forest on Azure AD so this command must be lunched from only one of the Proxy Servers:
    # IF YOU ARE CONNECTED TO THE PROXY SERVER WITH ADMIN CREDENTIAL
    # OF THE ROOT DOMAIN, THEN YOU CAN USE THIS COMMAND: 
    Register-AzureADPasswordProtectionForest -AccountUpn 'admin@<yourtenant>.onmicrosoft.com' 
    
    # OTHERWISE YOU CAN SPECIFY THE ROOT DOMAIN CREDENTIALS: 
    Register-AzureADPasswordProtectionForest -AccountUpn 'admin@<yourtenant>.onmicrosoft.com' -ForestCredential $(Get-Credential)
    This command require the a Global Admin of the tenant and a Domain Admins of the Root Domain.

  10. You can now connect to the https://portal.azure.com and configure the Azure AD Password Protection:
    Azure_AD_PP_Portal_Config.png

NOTE: keep in mind that when you write in the custom banned password the word "fabrikam", you are adding more than that, also the "f@br1k@m" is banned! So we made also common char substitution. The Custom password field, can contain up to 1000 words case-insensitive.

 

Nice to Know

 

  1. The Proxy Service of Azure AD Password Protection can work with HTTPS proxy servers in your environment, but actually the Azure AD Password Protection proxy service doesn't support the use of specific credentials for connecting to an HTTPS proxy.

  2. By default the Azure AD Password Protection is set to "Audit Mode" on the Tenant so, if you deploy a proxy service and install one agent on a DC (only for testing purpose), if the password match the Microsoft Global Banned Password list, the DC Agent will generate only events like this one:

    Log Name:      Microsoft-AzureADPasswordProtection-DCAgent/Admin
    Source:        Microsoft-AzureADPasswordProtection-DCAgent
    Event ID:      30009
    Task Category: None
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      ITDC01.IT.CONTOSO.COM
    Description:
    The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global 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: ITOPSTALK
     FullName: ITOPSTALK
    Or like this, if the password match your custom password lists on the tenant:

    Log Name:      Microsoft-AzureADPasswordProtection-DCAgent/Admin
    Source:        Microsoft-AzureADPasswordProtection-DCAgent
    Event ID:      30007
    Task Category: None
    Level:         Information
    Keywords:     
    User:          SYSTEM
    Computer:      ITDC01.IT.CONTOSO.COM
    Description:
    The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the 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: ITOPSTALK
     FullName: ITOPSTALK
    No Password will be blocked until you will change the configuration on the Tenant from "Audit Mode" to "Enforce".

  3. If your DCs are all 2012 or above but you are using FRS for replicating the SYSVOL, upgrade first to DFSR to use Azure AD Password Protection, because FRS is deprecated.

  4. Have you already two AD connect servers in your Environment? Yes? So you can install the proxy Service on this 2 Servers if you want, but start always from the one in staging mode ;). 

  5. Azure AD Password Protection for Active Directory require the Azure AD Premium licences P1 or P2.

  6. Azure AD Password Protection is not a real-time policy application engine, you can have a delay in the application of the new Azure Password Policy in your on-premises AD environment.

  7. If you want to force a DC to download a fresh copy of the Azure Password Policy from the Proxy Service, you can restart the DC Agent.

 

Scenarios

Some Customers think that because Azure AD Password protection On-Premises, work with DC Agents they can deploy Agents only on a single AD Site to protect for example a Branch Office, but this is a partial deployment and it is not recommended. In this scenario a customer want to deploy DC Agents only on the NY-SITE, graphics always help to understand better:

scenario1.png

As you can see one DC in the IT.CONTOSO.DOMAIN don't have the DC Agent, because the change password can happens on any DC, this configuration is not secure and not recommended.

 

If you want to implement a more secure scenario, you need to install the DC Agent on each DCs of the forest, like in this example:

scenario2.png

 

As you can see here, we have secured all the entire forest by installing the DC agent on each DC in every domains.


If you want to apply the Azure AD Password Protection only to one domain in your forest, you need in any case to deploy the Proxy Services for the Forest and then deploy the DC Agent only on all the DCs in that domain to secure it, in this example HR.CONTOSO.COM. (You should not think to deploy the DC agent only on the PDC, for example):

scenario3.png


Last but not least, rem
ember to alert your users about the Policy password change before switch the configuration in the Tenant from "Audit mode" to "Enforce".

I hope that all this info, will help you to deploy this great feature in your Environments. 

 

Reference

The official reference:

Enforce Azure AD password protection for Windows Server Active Directory

Azure AD Password Protection troubleshooting

Azure AD Password Protection monitoring and logging

 

 

45 Comments
Copper Contributor

Thanks for the write-up, this looks great. One question though, is there a reason this is not bundled into the Azure AD Connect software that most of us already have?

Hi @DKord,

many thanks for your question! In my honest opinion I would like to say......why not? :)
But I need to be honest, actually this two services (Azure AD Password Protection Proxy and AD Connect) are in two different software packages, so we will see in the future if something will change. Thanks again.

Brass Contributor

How does this DC agent behaves, in conjunction with the Microsoft Password Change Notification tool?
I'm guessing there is no issues, as it basically uses the same methodology as the Azure AD connect sync, to syncronize hashes to the cloud?

 

 

Hi @Micki Wulffeld,

the Microsoft Password change Notification Service use a Password filter (Pcnsflt.dll), the password filter is used to obtain passwords from Active Directory. The password notification filter runs simultaneously with other filters that are running on the domain controller (this means that can work with the Azure AD Password Protection DC Agent Password Filter).

Reference: https://docs.microsoft.com/en-us/microsoft-identity-manager/infrastructure/mim2016-password-manageme...

 

Also i have found this:
========================================================

Question: Is it supported to install Azure AD Password Protection side by side with other password-filter-based products?

Yes. Support for multiple registered password filter dlls is a core Windows feature and not specific to Azure AD Password Protection. All registered password filter dlls must agree before a password is accepted.

========================================================

Reference: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...

 

So at the end, there are no reasons why they should not work together, but if you will find an issue, we are here to solve it.

Copper Contributor

Great article. One question. We have an empty root domain, you mention the proxy needs to be a member of the root domain? Can it not be a member of the child domain?

Hi @AndyWallace12030,

correct, in my scenarios I placed the Proxy in the root domain , but if you already have, for example, the Azure AD Connect Servers in a child domain like IT.CONTOSO.COM, you can install the Azure AD Password Protection proxy service on this servers and it works, because the other DCs in the forest are able to locate them via the SCP (Service Connection Point) published in AD, even if the proxy are in the Child domain.

Both scenarios (Proxy in the root or proxy in the child domain) are supported.

Many thanks for your question! :)

Copper Contributor

nice post Dado

 

Copper Contributor

You mention that "You can configure a minimum of one DC per domain and the other DCs will take the new policy from the Sysvol replication" but then state "As you can see one DC in the IT.CONTOSO.DOMAIN don't have the DC Agent, because the change password can happens on any DC, this configuration is not secure and not recommended.".   This seems conflicting?   Is the one DC option for testing only?

 

Thanks!

Hi @3dinfo,

what I mean in this part:

================================

"It is not necessary that all the DCs are able to comunicate with the Azure AD Password Protection Proxy Server if you have a very complex Active Directory environments. You can configure a minimum of one DC per domain and the other DCs will take the new policy from the Sysvol replication. "

================================

Is that at least one DC per domain need to be able to comunicate with the Azure AD Password Protection Proxy Service to take the new Password policy, but for sure you need to install the DC Agent on all DC in the domain if you want to secure the domain.

 

I have change a little the article based on your question :)

==================================

It is not necessary that all the DCs are able to comunicate with the Azure AD Password Protection Proxy Server, if you have a very complex Active Directory environments, you can configure a minimum of one DC per domain to be able to connect to the AAD Password Protection Proxy Servers, and the other DCs will take the new policy from the Sysvol replication.

==================================

 

Many thanks for the question 3DInfo ;)

 

Copper Contributor

appreciate the write up. I was wondering if you could help understand an error i'm receiving... I have a single proxy service in a hybrid environment and installed the dc agent on a single dc... I got confused on the writing of the proxy.exe.config file... we don't have a http proxy in our environment..so I'm guessing that should be the proxy service server name.  i've restarted the proxy config service and dc agent service.. still seeing this error:

 

"One or more Azure AD Password Protection Proxy servers were found in the forest but this machine was unable to establish network connectivity to any of them..."

 

i see the inbound firewall rule for port 135...and i'm able to telnet to the port on proxy service server from dc agent server... is there some other communication that i'm not seeing?

 

appreciate the time and effort. thanks. 

 

 

Hi @gqcars

 

So if I understand well you don't have an HTTP proxy Server in your environment , so you don't need to change anything inside of the AzureADPasswordProtectionProxy.exe.config file, you need to modify this file only if you want that your Azure Ad Password Protection Proxy Service is able to go to the internet and reach Azure via an HTTP Proxy Server ;).

 

This event that you receive, came from the DC Agent:
============================================

One or more Azure AD Password Protection Proxy servers were found in the forest but this machine was unable to establish network connectivity to any of them.

============================================

This is due to a network connectivity issue from the DC Agent to the Azure AD Password Protection Proxy Service.

On your Proxy server you should be able to view this to inbound Windows Firewall rules:Firewall_roules_AADPPPS.jpg:

This rules are automatically created by the installation of the Proxy Service, one is for the Endpoint Mapper on port 135 TCP, and the other is for the Dynamic Port Range by default from 49152 to 65535 TCP. If this two rules are enabled on the Windows Firewall you need to check if there is something else that act as a firewall (Example: firewall appliance on the network, or may be the Antivirus on the DC or on the Proxy).

 

I hope to help you ;)

Ciao :)

Microsoft

Hi @Daniele De Angelis,

 

I would like a clarification regarding the number 7 bullet point in the Nice to Know section regarding the: "If you want to force a DC to download a fresh copy of the Azure Password Policy from the Proxy Service, you can restart the DC Agent."

 

Is there a fixed amount of time that the Azure AD Password Protection DC agent periodically tries to download a new copy of the Azure Password Policy? (e.g. every 15 minutes or 30 minutes) 

 

Thank you,

George

 

Hi @George Smyrlis,

 

Yes, every 1h, you can find this info in the official docs also:
===============================================

The DC Agent service always requests a new policy at service startup. After the DC Agent service is started, it checks the age of the current locally available policy hourly. If the policy is older than one hour, the DC Agent requests a new policy from Azure AD via the proxy service, as described previously. If the current policy isn't older than one hour, the DC Agent continues to use that policy.
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-on-p...
===============================================

Ciao ;)

Brass Contributor

good question George Smyrlis. 
I have an other question @Daniele De Angelis   :)

Microsoft recommends 2 Proxy servers for uptime concerns, but does the DC ever looses it's cache of the policy from the proxy server?
for exsample if the DC restarts?
Does it ever become a problem to reset a password, if the proxy service is unavailable for days maybe?
 

Or is the only concern if we want the latest banlist from Microsoft Global banlist.

Hi @Micki Wulffeld,

I'll try to respond to your questions :

1) The DC don't loose the local copy of the Microsoft Global and Custom banned password list if you reboot it for example.

2) If you have two proxy service and they are offline for days, the DC Agent on the DC will continue to use the old version of Global and Custom banned password list (even if you reboot it in this time for example for patching), but for sure if you add new custom password in the Azure portal this will not be applied on-premises until your proxy services will be back online.
3) Event if the proxy services are offline, the DC will continue to reset password using the local copy of Global and Custom banned password lists.

 

Many thanks for asking ;)

Ciao

 

Copper Contributor

Hi @Daniele De Angelis 

 

I know I'm late in getting to this article. It would be really useful in some small office deployments I have seen. I have two questions.

 

1. Does the proxy need to be on a separate machine or could it be installed on the DC.

 

2. In another environment, they have a single Azure AD Connect machine (and two DC's). Will this work if I were to install the proxy on the one AADC computer (understanding that there is no resiliency in such a configuration).

 

Many thanks.

Hi @A-XR219,

 

it's a pleasure to answer questions ;) :

 

1) You can run the Azure AD Password Protection proxy service on a domain controller for testing, but that domain controller then requires internet connectivity. This connectivity can be a security concern. We recommend this configuration for testing only, so not in Production Environment.

Referencehttps://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...

2) Yes It works, even if you have only one Azure AD Password Protection Proxy, and if this proxy become unavailable the DC agent continue to use the local cached copy, but fore sure you are not able to receive the most recent updated Password Policy:
================================================
The design of the Azure AD Password Protection DC agent software mitigates the usual problems that are associated with high availability. The Azure AD Password Protection DC agent maintains a local cache of the most recently downloaded password policy. Even if all registered proxy servers become unavailable, the Azure AD Password Protection DC agents continue to enforce their cached password policy.
================================================

 Reference: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...

 

Thank you for your questions @A-XR219  ;)

Daniele

Copper Contributor

Thanks @Daniele De Angelis 

 

Sorry... another question. I can see how and where the events are logged on the DC's, and there is good documentation for feeding these logs back into something like Azure Log Analytics. Is there a way to feed the logs from AAD which relate to AAD Password Protection? For clarity, if Someone tries to use a bad password while resetting their password directly in AAD, is that logged somewhere that I can push into Log Analytics (or, as is likely, have I misunderstood.)? 

 

Thanks again.

 

Ben

hi @A-XR219 ,

nice to hear you again :), 

as you probably know the official documentation for the AAD Password Protection On-premise events logs is here:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...
this logs are local to the DCs and Proxy so are NOT automatically forwarded to Azure Logs Analytics, maybe you need to use Azure Monitoring Agents, but to be honest I don't  have experience on this and I'm sorry for that ;).

Thanks

Daniele 

Copper Contributor

@Daniele De Angelis

 

I have question around the installation of AAD Protection Proxy Service agent and I cannot seem to find an answer. Can this agent be installed on the same server as Azure AD Connect V2 or is it best practice to have those roles separated?? For example, I have a primary Azure AD Connect Server and a staging Azure AD Connect Server..I was wondering if I could install it on both, maybe its not even supported, idk. Thank you so much.

Hi @Marc Rodieck ,

my apologize for the delay, here you can find the answer to your question ;):
=========================================================================================
Question: Is it okay to deploy the Azure AD Password Protection Proxy service side by side with other services such as Azure AD Connect?

Answer: Yes. The Azure AD Password Protection Proxy service and Azure AD Connect should never conflict directly with each other.

 

Unfortunately, an incompatibility has been found between the version of the Microsoft Azure AD Connect Agent Updater service that is installed by the Azure AD Password Protection Proxy software and the version of the service that is installed by the Azure Active Directory Application Proxy software. This incompatibility may result in the Agent Updater service being unable to contact Azure for software updates. It is not recommended to install Azure AD Password Protection Proxy and Azure Active Directory Application Proxy on the same machine.
Reference: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...
=========================================================================================
Be aware of the incompatibility between "Azure AD Password Protection Proxy" and "Azure Active Directory Application Proxy", in this case is better to have different servers.

Many thanks for your question.

Daniele De Angelis

Copper Contributor

Hi.

 

So if we have 1000 users in our AD on premise (not Azure), but we only want to use Azure Active Directory Password Protection, then do we have to pay 1000 users in Azure AD premium (6 usd x user) ?

Hi @juangonzalez,
here the link related to the licensing of Azure AD Password Protection:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad
Please pay attention to the note:

==================================

On-premises AD DS users that aren't synchronized to Azure AD also benefit from Azure AD Password Protection based on existing licensing for synchronized users.
==================================
So let me translate this in your case, if you have 1000 users, 100 are synchronized with Azure and 900 are only local AD Users, you should have 100 licenses AD Premium P1 or P2 to provide AAD Password protection with Custom password list to this 100 users on the cloud side but also the 1000 users on-premises can benefit of the Azure AD Password Protection.
Remember in this 100 user you should have a Global Admin or buy 101 licenses.
Many thanks for your question ;)

Daniele De Angelis
 

Iron Contributor

Hi @Daniele De Angelis 

Thank you for writing this blog it is very useful for the community.

Based on my research and understanding I have come to the conclusion that a default installation of AAD Password Protection on-prem supplements any existing on-prem password policy. That is, when a password change/set is processed it is first evaluated against existing complexity, length and history rules, that are set in AD; if it passes that stage it is then assessed against the additional functionality introduced by AAD PP.  For that reason when introducing the AAD PP service it is recommended to review existing password policies (both your written policy and policy applied by GPO).

Is my logic correct?

Reference:
“Azure AD Password Protection acts as a supplement to the existing AD DS password policies, not a replacement.” - https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-on-p...
"To enforce both the default Windows password filter and the custom password filter, ensure that the Passwords must meet complexity requirements policy setting is enabled. Otherwise, disable the Passwords must meet complexity requirements policy setting.” - https://docs.microsoft.com/en-us/windows/win32/secmgmt/installing-and-registering-a-password-filter-... 

Hi @Paul Bendall,
many thanks for your feedback! ♥ :)
Yes Your logic is correct! :)

Remember that by Default the AAD PP is in Audit Mode, so nothing will be blocked by default by AAD PP, so in Audit Mode you can see the events on the domain controller under the DC Agent Admin Event Log.
Reference: Monitor on-premises Azure AD Password Protection | Microsoft Docs

My suggestion is to look this events to see what could be the impact of enabling the Enforce Mode in your environment.
Many Thanks for your question ;)
Daniele De Angelis



Copper Contributor

Hi @Daniele De Angelis,

Thanks for this great blog and the guided instructions.

 

I noticed at many points in this you mentioned the "Microsoft Global Banned Password List", but after reading more on this page, I'm interested to learn if you know whether or not this List uses, contains, or is integrated with the (probably) much larger Have I Been Pwned Password list managed by Troy Hunt, that can be queried and tested online here.

 

I'm comparing this Azure AD Password Protection tool against https://safepass.me, and apparnetly we can run both at the same time, but the main difference is that safepass(dot)me uses the HIBP Pwned Passwords Database.

Thanks!

Hi @tobyraistrickinseego ,
your feedback is really appreciated! ♥ :).

The only thing that I know about the Microsoft Global Banned Password list is listed here:
=============================================
The contents of the global banned password list aren't based on any external data source, but on the results of Azure AD security telemetry and analysis.
=============================================
So is not public available, and is not based on external data sources.


I don't know Safepass, but if this software act as a password filter on the DC probably can work with AAD PP:
=============================================
Is it supported to install Azure AD Password Protection side by side with other password-filter-based products?

Yes. Support for multiple registered password filter dlls is a core Windows feature and not specific to Azure AD Password Protection.
All registered password filter dlls must agree before a password is accepted.
Reference: On-premises Azure AD Password Protection FAQ | Microsoft Docs

=============================================
IMHO is always better to make tests on a pre-production Environment even if the documentation tell us "Yes should work" ;). 
Many Thanks for your question ;)
Daniele De Angelis

Brass Contributor

@Daniele De Angelis Do you know if the incompatibility between the version of the Microsoft Azure AD Connect Agent Updater service that is installed by the Azure AD Password Protection Proxy software and the version of the service that is installed by the Azure Active Directory Application Proxy has been addressed?

 

We have servers with both AD Connect and the Application proxy installs combined, it would be great to be able to add Protection Proxy on top of this without needing new servers.

 

It is my understanding that the incompatibility only affects the Password Protection Agent Updater, can we install Protection Proxy without the Agent Updater and stack it with AD Connect and Application Porxy together? There haven't been updates to Protection Proxy for well over 2 years (with the exception of the last 2 releases) and I am OK handling the updates manually, while keeping Connect Agent and Application Proxy automatically updated.

Hi @Mirza Dedic,

 

from what I know the incompatibility unfortunately is still in place, so because the scenario you propose was never been tested from our support, my recommendation is to use two different servers. 

 

Many thanks for your question.

Daniele De Angelis

Copper Contributor

I realize this blog is showing some age, but the comments, conversation and details are very helpful. I am going out on a limb to see if anyone has encountered a possible solution to the following:

 

I understand where the logs are written on the DC(s) and that as a Domain Administrator one can connect to the DC and review the logs. Has anyone found a good solution for allowing others to view the logs to support end users as we enable this feature?

 

1) Essentially a central logging solution for the various Event IDs mentioned here. 

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...

If all these events are collected into a central logging source, those assisting users in password changes could review the logs, identify the userID in question and inform them of the event (they chose a password on the global list).

 

2) I also see where you can export the Trace log to a file.

Can you export the Admin log to a file? The current format of the Admin log is un readable by certain logging solutions so this might provide a simple solution to export to a central location in text format. I realize it would output SAMID format but it could be locked down and cleared every few days.

 

3) Has anyone built a custom solution or does Azure AD/Azure PaaS/SaaS provide a solution where these logs can be fed back into Azure AD and appear on AAD audit logs for review to determine if an AD user tried to set a password on a banned list.

 

I am just trying to make those employees who are supporting users live's a bit easier and provide them with ways to identify why a user is unable to set a password as they might not have read the announcements.

Copper Contributor

Knowing that when implementing the proxy agent on a domain controller, an internet connection is required and with it could have possible security problems. My query is: would deploying both agents on a domain controller and open only the exit urls, https://login.microsoftonline.com and https://enterpriseregistration.windows.net with this setup would it work in a production environment? What do you recommend. Thanks in advance.

Hi @ebellido170,
I need to be clear, don't do it in a production environment! :)
If your environment is in sync with AAD you can deploy de proxy on the AD Connect (that already have an internet connection) like indicated in the following reference:
=========================================================================================
Reference: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...
Question:
 Is it okay to deploy the Azure AD Password Protection Proxy service side by side with other services such as Azure AD Connect?

Answer: Yes. The Azure AD Password Protection Proxy service and Azure AD Connect should never conflict directly with each other.

 

Unfortunately, an incompatibility has been found between the version of the Microsoft Azure AD Connect Agent Updater service that is installed by the Azure AD Password Protection Proxy software and the version of the service that is installed by the Azure Active Directory Application Proxy software. This incompatibility may result in the Agent Updater service being unable to contact Azure for software updates. It is not recommended to install Azure AD Password Protection Proxy and Azure Active Directory Application Proxy on the same machine.
=========================================================================================
Many thanks for you question  ;)
Daniele De Angelis

Copper Contributor

Is it possible for Admins to set lower security passwords?.  Say for instance,  and app only recognises 8 character passwords?.  If not,  is there the possibility to have exceptions for certain accounts?.

Copper Contributor

I can't find a way to retire one of the proxy servers from the environment and re-deploy on a new site.

 

Removing the application from programme and files does not help, it still shows up when I run Get-AzureADPasswordProtectionProxy

 

Thanks!

AK

Copper Contributor

Hello @Daniele De Angelis ,

 

I deployed Azure AD password protection about 2-3 years ago.

 

My Global policy date currently shows as "2020‎-‎10‎-‎30T00:00:00.000000000Z". Is this normal or is something broken?

 

 

Below is what I have when for Event 30006;

Enabled: 1
AuditOnly: 0
Global policy date: ‎2020‎-‎10‎-‎30T00:00:00.000000000Z
Tenant policy date: ‎2022‎-‎05‎-‎12T14:42:03.741042900Z
Enforce tenant policy: 1

 

Looking forward to your response.

 

Thank you.

Copper Contributor

I am trying to install Azure Password Protect,  but am unable to force the Proxy server to use our environments HTTP Proxy.  We have a very strict (unavoidable) policy, that servers must exit the network, via the proxy.  I have set the system proxy using netsh winhttp, and that is fine,  I have the AzureADPasswordProtectionProxy.exe.config created, using the correct proxy server details.  Yet when I restart the DC Service,  I get the error that it (The azure Password Protect Proxy server)  is unable to resolve Login.microsoftonline.com...   Wireshark, shows that traffic is trying to use the Azure Password Proxy box to resolve the address,  and no traffic ever hits the Environment HTTP Proxy...

I even added the system proxy as a secondary DNS server in the NIC config.. same result.

All the registration is complete (forest and proxy) and comms between the DC and Proxy are fine.  Just comms out to azure is failing.

 

Any ideas?.

TIA

Ian.

Copper Contributor

my guess would be *.microsoftonline.com is what needs to be allowed to reach from the proxy

Copper Contributor

All,

 

We have an Tiered AD environment and implementing the “Azure AD Password Protection for Active Directory Domain Services”. For this to work we need to install the “Azure AD Password Protection Proxy service”. The Microsoft documentation stated”:

 

All the services of the Azure AD Password Protection (Proxy Service and DC Agent) do not require any specific user to work, they use the  LOCAL SYSTEM account, but you will need a Global Admin of your tenant and a Domain Admins to register the Proxy Services and the Forest, but only one time.

So the question is:

Do we really need the domain administrator permissions to get the proxy services to work or is there a possibility to get this server configured with delegated permissions so we can position this proxy server in Tier 1?

 

Thanks in advanced,

Eric

Copper Contributor

I have the same question as @akgupta88.  We need to retire one of the proxy servers from the environment and migrate to a new server (OS upgrade).  Does anyone know if there is a cmdlet to unregister/remove an AAD PP proxy? 

 

TIA

Shawn

Copper Contributor

Thanks for these insights.

Our company runs individual on-prem ADs in different regions. Those individual domains trust each other. There is one Sync-Server for all domains to sync AD Users etc into one Office365 Tenant.

Is it possible to install on-prem Azure Ad Password protection in different AD Domains which are synced into one AzureAD Tenant? If yes, is it possible to configure operation mode "audit/enforce" differently for the different on-prem ADs?

 

TIA, Thomas

 

Hi @ThomasU1915
for the first question, the answer is YES, if the various DCs located around the world in different domain, are able to reach via network the Servers that are hosting the Azure AD Password Protection Proxy Service, and  this Servers (with proxy agent) must be in the same forest.

For the second question, actually is not possible from the interface on the Azure portal, as you can see here:

DanieleDeAngelis_2-1661501256167.png

 

So if you enable the enforce mode, you will enable it for all the forest, actually there is no option to enable it for a single domain.

 

Many thanks for your question

Ciao

Daniele

 

Copper Contributor

Hi @Daniele De Angelis  Thanks for this article really appreciate the step by step. We have PTA servers in addition to AADC servers in the environment, is it supported design to install the Password Proxy agent service onto Win16 servers that are already running the PTA agent services? 

 

Thanks in advance. 

Chris 

Copper Contributor

Hi @Daniele De Angelis ,

 

I know that this is an old thread. There is anyway to compile an consolidated  report of banned password usage . When it is in Audit Mode the password protection settings.

many thanks

Copper Contributor

Amazing write-up! Does anyone know if this is supported in GCC High?

Copper Contributor

Why is this separate software instead of being a part of AD Connect? We are already using AD Connect to sync with Azure. Why does Microsoft continually release more applications instead of adding functionality to existing applications that we already have?

 

Version history
Last update:
‎Jun 07 2019 01:59 AM
Updated by: