Using a gMSA account with AADConnect

If you haven’t heard of a gMSA, you haven’t lived. That’s what my Mum tells me anyway.

A gMSA is also known as a Group Managed Service Account, and it really is the future of Service Accounts. It doesn’t allow interactive logons, it recycles it’s credentials automatically and can also be tied down so it can only be used on specific hosts. Most importantly it is recommended if you use Azure AD Connect with a dedicated SQL Server.

It does require Server 2012 or above on your domain controllers (for the schema extensions) and an Azure AD Connect server, but if you aren’t using this OS or newer yet, then I think you have other priorities you need to address 🙂

So the big question is; how do we use this magical feature? The guide below is for a new installation of AADConnect.

Firstly, if you haven’t done so already you need to enable the KDS Root Key 🔐 required for generating the passwords used by the service account. Run this PS Command from an AD Powershell prompt to enable the KDS Root Key 🔐. This can be done from a Domain Controller or from a server running RSAT ADDS tools.

Add-KdsRootKey –EffectiveImmediately

Funnily enough, even though we used -EffectiveImmediately, it is only available instantly on the DC you ran the command from. The other DC’s need to wait for replication to complete for the key to be available.

You then need to create the AAD Connect gMSA service account. Use this PS command to do this:

New-ADServiceAccount -Name AADC-gMSA -Description "AAD Connect Service Account" -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword MGMT01$,MGMT01$ -Passthru

Replace the sections in red with your own information. MGMT01 and MGMT02 are the names of our primary and staging AAD Connect servers in this instance, and the DNSHostName parameter essentially sets a DNS name of the service we are running.

Once this is done, you need to head over to your AAD Connect server and add the account using:

Install-ADServiceAccount AADC-gMSA

Lastly, during AADConnect installation, we need to select the service account. During initial installation, choose the ‘Customise’ option as shown below:

Screenshot 2019-05-21 at 16.55.44

And then select ‘Use an existing service account’ and enter the service account name using the domain\accountname$ format.

Screenshot 2019-05-21 at 16.57.43

This process will help you automate and secure your service accounts in the future, and is a great choice whenever a service account is required and gMSA is supported.




Use PowerShell to report on Azure AD Enterprise Application Permissions

Many Microsoft customers are now taking steps to try and modernise and centralise SaaS app identity by using Enterprise Applications within Azure AD to provide authentication, provisioning and reporting services.

This can be done by Administrators by adding applications into the AzureAD tenant and assigning users to them, or by Users (if you let them) who can self-service applications (think the Log in with Facebook / Google buttons). Applications which are added will have certain permissions assigned which will allow said application to be able to access AzureAD properties via the Microsoft Graph API.

These permissions can be as simple as allowing the application to read the users displayname, all the way to having full access to all files which the user can access in Office 365. You can see these permissions in the GUI by logging onto and navigating to Azure Active Directory>Enterprise Applications>Application Name>Permissions, as seen in the screenshot below. We can see that the Adobe Document Cloud application has had Admin consent to have full access to all files the user can access, and to sign in and read user profile. You can see the full range of available permissions in the Microsoft Graph, and what they all mean here.


This GUI feature is great for looking at individual applications, but if you are allowing users to provide consent themselves, or you are making full use of the Enterprise Applications feature, you are likely to have many applications listed here, and checking them one by one using the GUI is not efficient.

As always, PowerShell is able to come to the rescue. If we connect to the AzureAD v2 Powershell module by using Connect-AzureAD, we can export these permissions. Unfortunately, because of the way the data is presented, we need to do a little data massaging to make this possible.

Firstly, we need to get a list of all applications, and this can be done using:

Get-AzureADServicePrincipal | Select DisplayName,Homepage,ObjectID,AppDisplayName,PublisherName,
ServicePrincipalType | Export-Csv c:\reports\azureadsp.csv

This PS command will get a list of all the Service Principals (read: applications) you have configured, however it will not list the permissions. We need another cmdlet for that. The item we are most interested in for the Service Principal is the ObjectID, as this is the value we can use to map the Service Principal to the Permissions.

The next PS command we need is:

Get-AzureADOAuth2PermissionGrant | Select ClientID,Scope,ConsentType | Export-CSV :\oaauthperms.csv

This PS command will get a list of all the permissions granted in AzureAD. The important value here is the ClientID, which refers to the application, and the Scope, which refers to the permission level as described in the Graph Permissions article.

With this data we have two .csv files, and we need to compare the ObjectID from azureadsp.csv with the ClientID from oauthperms.csv. If we find a match, we need to copy the Now I’m no Excel expert, and there are probably better ways of doing this, but this was my method.

I copied the columns from azureadsp.csv into the oauthperms.csv. Let’s say the ObjectID value from azureadsp.csv ended up on row J. I would then create a new column called Application Name, at column A. I then used the INDEX, MATCH formula to look for identical ObjectID and ClientID values, and if a match was found, populate the Application Name.


The formula used looks like this:


Substituting the column names for logical names looks like this:


This gives us a value in Application Name which shows us the application which has been given rights to the Microsoft Graph and can enable us to easily see and filter which permissions have been given to which application. This can be used for management purposes, reporting and security auditing.

Hopefully this is useful for you, and if you think this could be improved upon please let me know in the comments!

ADFS Additional Authentication Rules – MFA Issue Type

ADFS Claim / Additional Authentication rules can appear very complex and confusing, and that’s because they are! One thing that tripped me up recently is related to the issue section of a claim rule whereby MFA is specified. During a project, I created a rule from a template I had used for another customer. Upon saving the rule I found that it didn’t apply MFA as I was expecting, and instead caused an error message in ADFS during logon attempts.

The rule I had used was issuing a claim for the Azure MFA Server rather than the Azure MFA Cloud Service. To clarify, the difference in the claim type is as follows:

Azure Cloud MFA

=> issue(Type = "", Value = "");

Azure MFA Server

=> issue(Type = "", Value = "");


This is an important distinction and needs to be considered when applying different types of authentication flows in ADFS.



Azure AD Powershell – Token Lifetime Configuration for MFA

The default token expiry in Azure AD for ADAL clients (using Modern Authentication) is 14 days for single factor and multi factor authentication users. This can stretch up to 90 days as long as the user does not change their password, and they do not go offline for longer than 14 days.

This means that clients using Outlook or Skype for Business can perform MFA once and then remain signed in using their access token for up to 90 days before being required to authenticate using MFA. As you can imagine, this is not an ideal situation for multi-factor authentication as a compromised account could be accessed through a rich client application with no MFA for up to 90 days.

Until recently, this could not be modified. However Microsoft released Configurable Token Lifetime as a Preview feature quite recently. This allows for various properties to be controlled, giving administrators more granular control over token refresh and enforcing a more secure MFA policy.

The Azure team have provided a solid guide here:

To do this, you need the Azure AD Preview PowerShell module. Install this by running the following from a PowerShell prompt:

Install-Module -Name AzureADPreview 

Here is a sample policy I’ve configured which will change the MFA token lifetime to 12 hours. I’ve combined this with ADFS Claim Rules which only enforce MFA if the user is on the extranet and using particular applications:

New-AzureADPolicy -Definition @("{`"TokenLifetimePolicy`":{`"Version`":1, `"MaxAgeMultiFactor`":`"12:00:00`",`"AccessTokenLifetime`":`"04:00:00`"}}") -DisplayName OrganizationDefaultPolicyScenario -IsOrganizationDefault $true -Type TokenLifetimePolicy

This is  a much needed feature from the point of view of security controls, although keep in mind it is still in Preview!



Azure RMS – File Classification Infrastructure Fail

I’ve been doing a bit of work recently with Azure RMS and FCI (using FSRM) to protect files located on traditional file servers.

One issue I came across whilst following various pieces of guidance which I found online was related to file classification. When attempting to run my File Management Task I was seeing no results.

I attempted to run the RMS protection script manually from PowerShell ISE (called RMS-Protect-FCI.ps1 in my case) and this returned an error as follows:

RMSProtection module not loaded

I had followed all the instructions I had seen so far, and luckily this error is quite descriptive. All I ended up having to do was to install the RMS Protection Tool, which can be found here:

It’s important to remember to install the pre-requisites for this too, as otherwise you will receive another error about failure to connect using bpostenantid. The key element I missed out was the RMS Client, found here:

Essentially I didn’t read the fine print and got lost in Powershell without installing the software I needed!

Some of the resources I used to configure this are listed below. All in all, FCI is a very powerful tool for protecting File Servers with RMS, but it has a lot of configuration steps and can appear (on the surface) very complex indeed!




AADSync / AADConnect default Domain Controller

I came across an odd situation recently whereby my AADConnect installation had decided to communicate with a Domain Controller which was in another site, across an Active Directory replication link with a 180 minute replication interval. This was no good for my customer as they made their AD changes on the site local to AADConnect, so I decided to remedy this by forcing AADConnect to communicate with a particular DC. This can be useful for many reasons, and you can actually set a list of ‘preferred Domain Controllers’ to allow for fault tolerance.

To do this, go into the Synchronisation Service, head on over to the Connectors tab and find your Active Directory Domain Services Connector. The below example is synchronising multiple AD Forests. Once you’ve selected your domain, you can see which Domain Controller is currently in use by checking the ‘Connection Status’ area (shown in the central area of the below screenshot).

Synchronisation Service

To change the Domain Controller in use, go to the Properties tab for your domain (on the right hand ‘Actions’ pane). Go into the ‘Configure Directory Partitions’ tab and you will see a handy tick box entitled ‘Only use preferred domain controllers’.

AADConnect - Directory Partitions

Place a checkmark in this box, and a window will appear, allowing you to enter your shortlist of Domain Controllers.

AADConnect - Preferred DCs

Once you’ve entered your preferred DCs, OK your way out of these windows and hey presto, you are done! It’s a nice and easy task to perform, but not one I’ve seen documented online before.

Thanks for reading!

Setting the ImmutableID to $null

Here’s a small Friday afternoon snippet of useful information for all you Office 365/Identity nerds out there.

If you have converted an AAD user from ‘Synced with Active Directory’ to ‘In Cloud’ and you want to sync a new user object with that user, you will need to clear the ImmutableID and then match it up with the new user object. I’m planning on creating a more extensive post on that very subject in the near future, but for now, I’ll give you this titbit of information:

Clearing the ImmutableID is done using the Powershell command:

Set-MSOLUser -UserPrincipalName -ImmutableID "$null"

You might think that those quote marks are a bit pointless, but you would be wrong! If you were to run the command as shown below, without the “” marks, it wouldn’t show you an error, but it also wouldn’t actually clear the ImmutableID.

Set-MSOLUser -UserPrincipalName -ImmutableID $null

As with all things PowerShell, syntax is everything!