[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]