Azure Active Directory

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:

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.

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:

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!

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).

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’.

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

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.

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:

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.

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:

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!

I just wanted to write and tell you all about a fantastic new feature built into the AAD Connect tool. It’s name is ‘Staging Mode’ and it has a dual purpose; a) it allows you to have a server which is essentially on standby, and b) it can be used just as it’s name suggests, in a kind of test mode where you can see what is being imported before it all gets sent off to Azure AD.

In real life it would be utilised thus:

Customer A has a functional installation of AAD Sync / AAD Connect which is synchronising objects and attributes between Azure Active Directory and the On Premise Active Directory. They then build an AAD Connect server in their DR datacentre (or wherever they fancy), and during the initial configuration, enable ‘Staging Mode’. Apart from this setting, they configure it just like their existing, live AAD Sync / AAD Connect server. They even leave the scheduled task enabled and running. All of a sudden, DR strikes, and the live AAD Sync / AAD Connect server goes offline forevermore, cast into the computer graveyard in the sky. Rather than restore the server from backup, they simply log into their second AAD Connect server and disable ‘Staging Mode’. This server then starts synchronising with Azure Active Directory in earnest, without having to miss a beat.

What Staging Mode does is very simple. It acts just like a functional AAD Connect installation, except for the fact that it exports nothing to Azure Active Directory or your on premise Active Directory. It also does not perform any password sync or password write-back functions. The metaverse is fully populated and ready to start exporting data, giving you the easiest possible way to have a server on standby. Unfortunately there is no replication between your two synchronisation servers, so any configuration changes need to be replicated manually, but this is another step to making AAD Connect fully HA, which is becoming much more desirable as Azure Active Directory gains traction.