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.


Day 1

Day 2

Day 3

Have fun!

Wednesday, 27 June 2018

Test-OAuthConnectivity Error:Missing signing certificate.

Recently came across this issue where free/busy had stopped working from Exchange on-premises to Exchange Online in an Exchange 2013 Hybrid Environment. On-premises users could not see calendar free/busy information of a user in Exchange Online, but Exchange Online users could indeed see free/busy information for on-premises users and didn't have an issue.

First of all it's safe to say read this article, as free/busy issues can be a dark art to understand and resolve - however, in this instance there wasn't much information on this error so we had to work through it to find the resolution.

When running Test-OAuthConnectivity the following error presented itself:

Information:[OAuthCredentials:GetToken] start building a token for the user domain 'on-premisesdomain.com'
              Error:Missing signing certificate.
              Exchange Response Details:
              HTTP response message:
              System.Net.WebException: The request was aborted: The request was canceled. --->
              Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: Missing signing certificate.

Now Exchange utilises an authconfig certificate which is installed by default when you install Exchange and is used for OAuth services. The default expiry of this certificate is 5 years from the installation date.

You can view the certificate in question by running this command:

Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint |FL

What had happened in this instance, is that the certificate had expired 3 months into the Exchange Hybrid deployment.  So to resolve this issue we needed to generate a new cert firstly, and then apply this certificate as the new auth certificate which is performed with the following command:

Set-AuthConfig -NewCertificateThumbprint "Thumbprint of the new cert" -NewCertificateEffectiveDate XX/XX/XXXX


And then use Set-AuthConfig -PublishCertificate to make the change.

This command will push the certificate out to all CAS role servers so you don't have to push the cert out yourself.

Finally, re-run the Hybrid Wizard and once completed you will find on-premises users will be able to see the free/busy information for Exchange Online users once more.

Take care,

Thursday, 21 June 2018

Enabling Azure Password Protection Preview

Here's a quick video of how to enable Azure Password Protection which is currently in Preview. Previously you had a pretty painful experience to upload a custom banned password list to Office 365. This simplifies the process and adds additional services and features.

Check out part 2 next week where i'll enable advanced configuration when you have directory synchronisation from an on-premises Active Directory and have to install and configure the Azure Password Protection proxy service and deploy the APP agents to your Domain Controllers.

Take care!

Wednesday, 13 June 2018

The curious case of changing background colour for Office 365 Message Encryption

An interesting issue cropped up earlier this week when working with a customer to brand their OMEv2 experience to their corporate website and utilise the same colours and logo where appropriate. We had already branded Office 365 and we were to utilise an HTML colour code from their website into Office 365 Message Encryption.

Now Microsoft are usually very good with their documentation, but this did initially bring around some frustration as changing background colour simply didn't work.

The article explaining the Set-OMEConfiguration cmdlet is here, and states the following:

The BackgroundColor parameter specifies the background color. Valid values are:

  • An HTML hexadecimal (hex triplet) color code value (for example, #FFFFFF is white).
  • $null (blank). This is the default value.

However it doesn't work with an HTML colour code as you can see below.

Interestingly utilising Get-Help Set-OMEconfiguration -full didn't shed anymore information on the matter than what I was reading on docs.microsoft.com, even after using Update-Help

 Utilising Get-Command Set-OMEConfiguration -Args -backgroundcolor didn't really give me any insights and nor did expanding the parameter set using $a = Get-Command Set-OMEConfiguration 
$a.ParameterSet [0] | select -ExpandedProperty parameters

 However this did give me information on what values it was expecting, which could be anything.

In a moment of frustration I just typed a colour in. for example Black, and the change was honoured.

 Which frankly is hilarious. As my client wanted a certain blue whilst I was not able to give him the exact blue they wanted I found I could support light blue - although it had to be added as lightblue, 'light blue' was not accepted.

 This made me think how many blue options were available to me. It's safe to say you can't have navy blue but royal blue is fully supported.

I've raised this to Microsoft to hopefully get the cmdlet match what's on docs.microsoft.com and give us our HTML colour codes. I am pleased to confirm however $null does indeed work and remove any background colour change you have made :)

Update! 15/06/18 - 48 hours after raising this to Micosoft they have acknowledged the issue and created this article for the list of 140 available colours , as well as updating the original article.

Take care!

Wednesday, 30 May 2018

Convert an RMS template to an AIP label

So you can convert an Azure Rights Management template into a an Azure Information Protection label in less than 30 seconds, but delving a little deeper does it keep the settings? Let's take a look.

Select 'Protection'

Let's look at the settings of the label

The original test RMS template allowed me to share contact with an external user - something that had to be managed using a custom template in Azure Rights Management unless you used the Azure RMS Sharing App. Anyhow - looking at the configuration of the label you can see it's succesfully converted my RMS template and carried over the settings I originally configured. I would of course advise you to check every single RMS template you convert to an AIP label and of course it needs user education on the productivity change.

Have fun!


Thursday, 10 May 2018

An Introduction to Microsoft Teams

Just a heads up to join me on 11/05/2018 as I am hosting a webinar on Microsoft Teams: The New Way of Working.


See you there!


Friday, 4 May 2018

Secure your Twitter account with Multi Factor Authentication and the Microsoft Authenticator App

Yesterday, Twitter notified it's followers and the press that a bug had potentially allowed some 330 million user accounts to have their passwords stored without encryption. They have advised users to change their passwords even though they believe no compromises of this data has occured. You can read the whole story via Twitter here and the BBC News story here

I have indeed changed my Twitter password this morning - and I also went one step further, by securing my Twitter account with Multi Factor Authentication.

Now there's primarily two ways you could do this.

You could have the app integrated with Office 365 by assigning it to users through the Azure Marketplace, but assigning multi factor authentication to gallery applications this way requires Azure AD Premum P1 or better licensing whether it is deployed by Administrators or available for users via self service. Plus it would also utilise your Azure AD identity for authentication and verification to Twitter.

The other way is to natively integrate it directly through Twitter. Microsoft has made great gains in ensuring the Authenticator app in the relevant app stores can provide both corporate, personal and third party app support through a single application pane.

So, now that you've woken up and changed your Twitter password this morning, here's how you protect your account with Multi Factor Authentication and the Microsoft Authenticator app.

Login to Twitter and go to 'Settings and privacy'

Select 'Set up login verification'

You will go through a process to get a verification code to your registered mobile device

Once you have entered the verification code and completed this process you'll be able to review your login verification methods for Twitter

From here you'll be able to select a 'Mobile security app' to protect your Twitter account

Select it and start the process

Twitter will provide a QR code which you can use with the Microsoft Authenticator app to add your Twitter account

Open the Microsoft Authenticator account on your mobile device and select 'Add account'

Select 'Other account (Google, Facebook, etc.)

Once you have scanned the QR code in, Twitter will be added to your Microsoft Authenticator app

Back at Twitter, you can now add the code for Twitter from the Microsoft Authenticator app to complete the process

And that's it. You're all set up!

You can now use the Microsoft Authenticator app for your Azure Active Directory MFA requests, and your personal accounts and personal apps like Twitter.

Have fun!