[MUSIC] Aakashi Kapoor: Welcome back to the final part of the video series on Azure AD Password Protection. So far in previous videos, we have covered an overview of password protection and smart lockout, how the password validation algorithms works. Now, let’s go ahead and dive into the details of how the on-prem solution works. You can enable Azure AD Password Protection for your on-prem environment from the unified admin experience on Azure Portal, as covered in the last video. When you enable this feature, we extend the same Azure service to your on-prem environment, so you are getting exact same algorithm, in fact, the exact same code that is running in Azure. The goal is to align with the password policy enforcement from Azure all the way down to Active Directory. This is done by installing an agent on the domain controllers and a proxy agent on either the DCs or another server if you have blocked internet connection to your DCs. The password policy is mastered in Azure AD and you cannot change it in AD. You will have to use Azure Portal to make the changes to the policy which will then be applied to both Azure and on-prem. For the on-prem architecture for password protection, we had two key principles that drove the design. First, we were never going to sync clear text passwords from DCs when validating the password. This meant the policy needed to be locally on the DC, so everything could be evaluated there. And second, customers don’t allow DCs to talk to the internet for security reasons. Keeping these in mind, we have to get into the validation happened locally but get the policies from Azure AD. This led to the creation of Azure AD Password Protection proxy service. It securely proxies calls from DCs to Azure AD. So, how does it all work together? There are three main components to the on-prem deployment. First, the proxy service; second, the DC agent; and third, the password filter DLL. When you deploy the capability, you deploy one or more proxy services in your forest. It’s primary purpose is to forward password policy download requests from domain controllers to Azure AD and it then returns the responses from Azure AD to the DCs. Each Azure AD password protection proxy service instance advertises itself to the domain controllers in the forest by creating a service connection point object in Active Directory. On your DC, you will have to deploy the agent service and the agent then deploys the password filter DLL. The DC agent checks early if it has the policy or whether the policy available is the latest and sync policies from Azure AD as needed. After the DC agent service receives a new password policy from Azure AD, the service persists this policy in domain sys vault folder share. Now, there is a benefit to doing that, as it replicates the policy across other domain controllers in the domain. So, as soon as one DC gets the policy, it can very quickly be enforced on all the other DCs in the domain. Now, user comes in and tries to change the password. The password filter DLL of the DC agent receives user password validation request from the operating system. Password DLL is very thin, and it runs inside a security critical process in Windows. It forwards them to the DC agent service that’s running locally on the DC and which then does the validation. Whenever an Azure AD Password Protection policy is downloaded, that policy is specific to a tenant. What I mean by that is that password policies are always a combination of the Microsoft Global Banned Password List and the pertinent Custom Banned Password List. One thing to note here is that Azure AD Password Protection acts as a supplement to the existing Active Directory password policies, not a replacement. This includes any of the third party password filter DLLS that may be installed in your environment. Active Directory always requires that all the password validation components agree before accepting a password. Now that we have understood how Azure AD Password Protection validates the passwords on-prem, let’s take a look into the steps to deploy the solution for your environment. First step is to download the DC agent and proxy agent installers from download center. Second step is to install and configure the proxy service. The proxy agent has to be installed on a member server. It can run on any domain join machine in the current Active Directory forest and it does not have to be a dedicated server. You could install it on a server that already has AAD Connect and it would work. Installing a proxy server does not need the proxy server to be rebooted. Since proxy is the one the one talking to Azure AD, we do need to register it with Azure AD. And finally, you would need to install DC agents on every DC and reboot the domain controllers after the installation. The ordering of which agents should be installed first does not matter. Additionally, you will also have to register the forest, since this is a per forest configuration. An important point to keep in mind is that the DC agent service always uses the most recent locally available password policy to evaluate a user’s password. If no password policy is available on the local DC, either due to a failure or as an older version of the DC agent has expired, then the password is automatically accepted. When that happens an event message is logged to warn the administrator. Once we have configured and enabled the feature for on- prem, the next step is to plan and execute your deployment. There are no specific steps in Azure for deploying password protection, as each time a user or administrator resets or changes Azure AD password, it validates it through the Global Bank Password List. You can further enable Custom Banned Password Lists from Azure Portal as needed. So, what should be the deployment strategy for on-prem? We recommend you start with audit mode. Rohini touched on this mode a little on the previous video. But this is a what-if mode, which is helpful to monitor the impact that the password policy will have on users and the environment when the policy’s enforced. In audit mode, passwords would continue to be set, but passwords that would be blocked are recorded in the event log. Our customers have found this mode really beneficial to have a data driven discussion with security teams on the need to improve existing operation of processes to use more secure passwords. After the feature has been running in audit mode for a reasonable period, we recommend that you switch the configuration from audit to enforce to require more secure passwords. Before enforcing, it is also advisable that you inform users about the upcoming change in security enforcement, possible impact on them, and how to choose more secure passwords. An important thing to consider here is that Azure AD Password Protection supports incremental deployment. But the DC agents can only validate passwords when it’s installed on a DC and only for password changes that are sent to that specific DC. It is not possible to control which domain controllers are chosen by Windows client machines for processing user password changes. In order to guarantee consistent behavior and universal password protection security enforcement, we recommend that the DC agent software must be installed on all DCs in a domain. After the deployment of Azure AD Password Protection, monitoring and reporting are essential tasks. Monitoring and reporting are done either by event log messages or by running PowerShell commandlets. The DC agent and proxy services both log event log messages. On each domain controller, the DC agent service writes the results of each individual password validation to the DC agent admin event log. The Get-AzureADPasswordProtectionSummaryReport commandlet may be used to produce a summary view of activity across forest, domain, or an individual domain controller scope. You can visit the link on the video for more details on how to monitor logs and generate reports for Azure AD Password Protection for your environment. Hope this video was helpful to understand how to deploy password protection for your on-prem environment. If you have any questions, please feel free to reach out to aadppfeedback@microsoft.com and we will be more than happy to help. Thanks a lot for watching the series. [MUSIC]
