Tuesday 31 July 2018

Getting Azure AD Guest Users with the Azure AD Preview PowerShell module

Azure Guest access is a great concept primarily wrapped in the Microsoft Teams, SharePoint and Onedrive experience, however reporting and keeping a lid on Azure Guest access accounts can be a daunting task. Luckily there's a few ways to poll Azure Guest accounts, with PowerShell providing the best experience so far.

Accessing https://portal.azure.com and selecting Azure Active Directory | All Users | and then selecting 'Show: Guest Users Only'  will give you a list of the current Azure AD Guest Users in your directory. Unfortunately however, the UI is very limited in being able to get more information than what is presently shown.

Luckily the new Azure AD PowerShell Preview module can provide better insight to guest users for your Directory and we can utilise the shell to create a report for administrative purposes.

Let's take a look; once you have the module installed, utilise Connect-AzureAD, the module supports modern authentication by default so if you're looking to pre-enter credentials utilise the -credential parameter and $Credential = Get-Credential for scripting purposes.

We can simply list all users with Get-AzureADUser

We can get more information on a user by utilising -ObjectID and utilising the Azure AD User objects ObjectID GUID. For example Get-AzureADUser -ObjectID "object guid" |FL

What we see here is the parameter UserType - this is how we can differenciate a normal user to a Guest.

With a simple where statement we can specify all Guest users.

Get-AzureADUser |where {$_.UserType -eq 'Guest'}

The 'CreationType' attribute will also list if the account was created from an invitation from a user.

With a fairly simply PowerShell one liner we can retrieve all Azure Guest Users and format their most appropriate attributes easily.

Get-AzureADUser |where {$_.UserType -eq 'Guest'} |Select DisplayName, UserPrincipalName, AccountEnabled, mail |FT

We can utilise https://portal.azure.com  | Azure Active Directory | Users | Audit Logs to see who has invited the external users and also when an external user accepted the invite. Just filter on the activity and specify 'Invite external user' and 'Redeem esxtgernal user invite'.

Selecting the audit log will show you more information including the time and date of the activities.

If I check Azure Active Directory | Users | Sign-ins I can see audit logs for user sign-in. I can specify user search terms to get more detailed information on an Azure Guest User accessing my Office 365 tenant. Note I can get immediate access to Sign-in Info, Device Info and whether they had to have any 2nd factor authentication or conditional access rules apply.

And whilst both the Audit Log and Sign-ins allow me to download reports, Sign-ins provides richer integration with Power BI once you've configured it (which i'll detail in a future blog post).

So, getting back to creating a nice list of Azure Guest Users, we can utilise the Azure AD Preview PowerShell module to get this data and wrap it up in an email to send to us as and when needed. I've written a script and uploaded it to the TechNet Gallery here.

You can use it to get a list of Azure Guest users in the session window

Or use the -email switch where you'll be able to use it as a scheduled task - be aware the password needs to be in the script, however a standard user will work as all they need is read access which they have by default.

Have fun!

Thursday 26 July 2018

Configuring Azure Password Protection with Active Directory

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,

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


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!

My 4 days of Microsoft Inspire!

I recently got back from Las Vegas for my first Microsoft Inspire event. I took a wash-up video each day and posted them on Twitter. I've added them here as a nice single place to find them all.

I signed up to attend the pre-day on the Sunday - this was a great opt-in benefit I suggest you sign up for if you can in the future.

Day 1 - my day revolved around Skype to Teams roadmaps and Azure

Day 2 - I spent a lot of time on GDPR functionality enhancements in Office 365

Day 3 - A great final day, with a fantastic keynote. I doubled down on Azure incentives for SQL and Windows server migrations to Azure.

Have fun!