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 portal.azure.com 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.

perms

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.

indexmatch

The formula used looks like this:

=INDEX($H$2:$H$101,MATCH($B2,$J$2:$J$101,0))

Substituting the column names for logical names looks like this:

=INDEX($DisplayName$2:$DisplayName$101,MATCH($ClientID2,$ObjectID$2:$ObjectID$101,0))

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!

Advertisements

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 = "http://schemas.microsoft.com/claims/authnmethodsreferences", Value = "http://schemas.microsoft.com/claims/multipleauthn");

Azure MFA Server

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

 

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: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes

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: https://www.microsoft.com/en-us/download/details.aspx?id=47256

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: https://www.microsoft.com/en-us/download/details.aspx?id=38396

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!

https://docs.microsoft.com/en-us/information-protection/rms-client/configure-fci
https://technet.microsoft.com/library/hh847874.aspx
https://msdn.microsoft.com/library/mt433202.aspx
http://simon-may.com/setup-azure-rms-file-protection-encryption-file-classification-infrastructure-fci-prem-file-servers/
https://docs.microsoft.com/en-us/information-protection/deploy-use/configure-servers-rms-connector#configuring-a-file-server-for-file-classification-infrastructure-to-use-the-connector

 

 

 

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 emily@misstech.co.uk -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 emily@misstech.co.uk -ImmutableID $null

As with all things PowerShell, syntax is everything!

Azure App Cloud Discovery & PAC Files

Azure App Cloud Discovery is a seriously cool piece of technology. Being able to scan your entire computer estate for cloud SaaS applications in either a targeted, or catch-all manner can really help discover the ‘Shadow IT’ going on in your environment. Nowadays, users not having local admin rights won’t necessarily stop them from using cloud SaaS apps in any way which is going to increase their productivity. Users don’t generally think about the impact of using such applications, and the potential for data leakage.

But, as with lots of Microsoft’s other cloud technologies which are being launched left, right and centre at the moment, the Enterprise isn’t catered for as it might hope. Most Enterprise IT departments leverage some kind of web filtering, or proxying. This may be using transparent proxying, in which case you can count your blessings as Cloud App Discovery will work just fine. If you are explicitly defining a proxy in your internet settings, then you can get around that by adding particular registry keys. However if you are using a PAC file to control access to the internet, then unfortunately Cloud App Discovery will not work for you. This is a shame as it is, in my opinion, the best way to approach web proxying in an Enterprise, but that’s another story. From what I have heard, a feature is in the works which will allow you to configure Cloud App Discovery agents to log their findings to an internal data collector. This data collector can sit on a local server and then upload data to Azure on your behalf, which is a much more elegant solution to the problem of data collection from multiple machines. However as far as I know, this feature is not available yet. I’ll be keeping my ear to the ground and will let you know if this changes.

In the meantime, if you are desperate to get your data collection up and running in the meantime, you could change to explicitly defined proxying, and configure registry settings for your clients as per the following MS article:

https://azure.microsoft.com/en-gb/documentation/articles/active-directory-cloudappdiscovery-registry-settings-for-proxy-services/

Cloud App Discovery is a feature of Azure Active Directory Premium, a toolkit designed to take your Azure Active Directory to new, cloudier heights. Azure AD Premium can be bought standalone, or comes bundled with the Enterprise Mobility Suite. I would highly recommend it to Office 365 customers as it can give you and your users some great new features which can help make your Azure AD the best it can be!

Edit: It looks like PAC file support has been added rather surreptitiously. No announcement was made, and the KB articles haven’t been updated. I happened to check the Change Log today and Release 1.0.10.1 includes an option to tweak your PAC file to support Cloud App Discovery. https://social.technet.microsoft.com/wiki/contents/articles/24616.cloud-app-discovery-agent-changelog.aspx

Alternatively, if you use a PAC file (Proxy Auto Configuration) to manage proxy configuration, please tweak your file to add https://policykeyservice.dc.ad.msft.net/ as an exception URL.

I’m yet to test this myself but it looks promising!