Firstly apologies that this is a few days later than I originaly planned but my trip to Microsoft Inspire really messed up my spare time to get this out there - having said that, welcome to the final part of my Azure Password Protection Preview review where we'll take a look at how to configure this with an on-premises Active Directory.
Pre-requisites require AADConnect and Windows Server 2012 R2 or above Domain Controllers, as well as the member server that will be running the Azure Password Protection Proxy.
You can download both the Proxy and Password Agent at this link. As previously stated Windows Server 2012 R2 is needed as the minimum supported operating system. The Proxy agent will flat out refuse to start on a Windows 2008 R2 server, but I did have success with the DC Agent. However this is not supported - ensure you are at Windows Server 2012 R2 or above.
Firstly we need to install the Proxy service. You can have up to two Proxy services installed per Active Directory Forest, with the DC Agent installed on every DC in the Forest/Domain. Run the install, although you can perform a silent install with
msiexec.exe /i AzureADPasswordProtectionProxy.msi /quiet /qn
However in this example I am using the UI. Deploy the agent
Simply accept the terms and select 'Install'
And that is it, the Proxy service is installed. However it is not configured with the service just yet. However you should be able to see it running in the Services snap-in.
What we now need to do is open a PowerShell session on the server, the install deploys a PowerShell Module called 'AzureADPasswordProtection' which we need to load.
Import-Module AzureADPasswordProtection, and then,
Register-AzureADPasswordProtectionProxy
You must ensure at this point that the account that is running this elevated PowerShell session is both a Domain Admin AND also a Global Administrator for your Office 365 tenant. This is very important. If you have ADFS then you will not get further unless you have password hash synchronisation in place - then it will work.
As long as the account confirms to both a Domain Admin and Global Administrator the service registers succesfully without much fuss.
From here on in, if you are in a single Forest scenario you are done. You are supported to install a second Proxy but you do not have to register the service, the above step is a once per Forest scenario. If you are running a multi Forest Active Directory, then you repeat the registration process once per Forest - and each Forest can have two Proxy agents.
We can check the service is still running and also the configuration of the service using these PowerShell commands:
Get-Service AzureADPasswordProtectionProxy |FL
Get-AzureADPasswordProtectionProxyConfiguration
For this above command you'll see that we can configure a static port if you require this in extremely restrictive outbound Firewall scenarios. Having the port set at 0 means it is dynamic, if you need to set it to a specific port simply use:
Set-AzureADPasswordProtectionProxyConfiguration -StaticPort 'port number'
Using the above command and setting the -StaticPort parameter back to 0 will make the service use a dynamic range once more.
So now we have our Proxy in a healthy state we can deploy our DC Agents, again the installer is a extermely simple affair, accept the terms and then we're completed - note that you'll have to restart your Domain Controllers. This is because it installs a password listening DLL to allow Azure Password Protection to work with your on-premises Active Directory. Deploy the Agent to each Domain Controller in the Forest. We can again quietly deploy should you so wish using
msiexec.exe /i AzureADPasswordProtectionDCAgent.msi /quiet /qn
Now we are in a position to enable password protection for Windows Server Active Directory. Go to the Azure Portal and in Password Protection enable it, ensure you select Save to keep your changes.
Microsoft recommends deploying in Audit mode only and that's what I have initally done. We'll enforce the policy later in this post.
I have found during testing this can take up to 60 minutes before it starts pushing the policy out and the on-premises agents reporting they are recieving a policy from Azure. Microsoft states it may sometimes take a lot longer than that, but we can check Event Viewer on the on-premises Domain Controllers to see when the policy has pushed down. More on that later.
We will now be in a scenario - even if the Azure Password Protection policy hasn't been pushed to on-premises that you'll be able to see a summary report of password changes. Use the PowerShell command Get-AzureADPasswordProtection SummaryReport -DomainController 'DC' (where DC is the Domain Controller you want to check)
If you check Event Viewer under | Application and Services Logs | Microsoft | AzureADPasswordProtection | you'll see either DCAgent, ProxyService, or both depending on how you have built your Proxy and Agent infrastructure. To confirm the Azure policy has pushed to your on-premises infrastructure check the DCAgent log and search for Event ID '30006', you'll get a nice notice telling you that your Azure Password Policy is now being enforced. All DC Agents should get this at roughly the same time as communication comes from the Proxy.
As we're in Audit mode we can now see Azure Password Protection working without explicitly denying users password changes. This is a great way to get an undersanding of the service, get a confidence it is working and perform testing of password changes whilst looking at the audit logs. Look for Event ID 10025 or utilise the previous Get-AzureADPasswordProtection SummaryReport - but the Event Logs will give you a richer report experience.
Once you are happy the Proxy and Agents are working as expected and your testing in Audit mode confirms the Azure Password Protection service is working as expected, we can take the service out of Audit mode and push for Enforcement. Go back into Azure and simply select 'Enforced'
I found I have to wait around an hour or so for the service to come out of Audit mode and Enforcement come into play. You can of course restart the DC Agents to immediately pick up policy change but if the Azure Password Policy hasn't been pushed to the Proxy yet from Azure it won't make a difference. You'll need to sit and wait and check for Event ID 30006. Once out of Audit mode, the event will show 'AuditOnly: 0' - interestingly 'Enforce tenant policy' is always at 1.
So what happens if we now change a password of the user? Well you'll not only going to get all of the auto-protection from Azure of their default password protection policies but your custom banned password policy is also invoked. If we now try to change a password we'll see the below:
And Event ID 10017 will show the Enforcement at work.
And of course back in PowerShell we can again use the summary reports. We'll now see numbers against password changes rejected or password sets rejected depending on the password change type.
I have to say I am impressed with the solution and look forward to it coming out of Preview. I do hope they'll add a few improvements to the service however.
Firstly from a user experience point of view when Azure Password Protection blocks your password change you are not informed, you just get the usual 'your password does not meet the complexity requirements' jargon. I've been informed that this is going to be improved so it can give a more granular informational alert experience.
Secondly pushing the audit log experience into Azure as well would also be great - akin to the Azure Self Service Password Experience with Password Writeback and AADConnect.
Lastly I think the registration experience can be improved, including visibility that both the Proxy and DC agents are online and working as expected. Pushing this visibility into the Azure Portal - something similar to Azure Pass-through Authenticaton when you can see your PTA agents being online and the FQDN of the DC/AADConnect box would be a welcome additition, along with notifications to administrators if an agent goes offline.
Have fun!
@OliverMoazzezi
No comments:
Post a Comment