Azure AD Authentication

ADFS is dead! Long Live Azure AD!

So, you might have read the High Level Design Notes and spotted that I would deploy Active Directory Federated Services (ADFS) as part of what would by my gold standard deployment. However since starting this blog, things have changed. If you watch (or were lucky to attend) Ignite videos from this year, the message is clear. Microsoft want you to move away from using ADFS. They are actively challenging you to provide them with reasons why you MUST use ADFS and then challenging that. In this blog post we will take a look at authentication with Azure AD.

Password Hash Sync

First of all, regardless of which authentication method you go with, you should enable Password Hash Sync. This allows you to get reports on people using known compromised passwords. As the name suggests, your passwords aren’t actually synchronized to Azure AD, rather the hash of those passwords is. On top of this, the hash is then encrypted, salted and hashed again using SHA-256 before being synchronized to Azure. More information on this can be found at Implement password hash synchronization with Azure AD Connect sync

As with removing ADFS, Microsoft are actively challenging people on why they cannot enable this feature. Adding PHS also has the benefit of providing you with a backup authentication in the event your ADFS service fails. AAD can be set to perform authentication on a temporary basis, whilst you recover your ADFS service.

Why use Azure AD?

Azure AD supports many protocols for authentication with 3rd party applications. These include SAML and OAuth 2.0. With the growth in use of Cloud services, including Software as a Service, identity management has been a challenge. When using multiple SaaS products, you have to configure users in each of these products which can be a huge task. But what about when someone leaves the organization, either voluntarily or forcibly? You have to go through and kill access in all those services. Wouldn’t it be nice if you could kill one account and all subsequent access is stopped? That’s the beauty of using ADFS or even Azure AD.

When you’re hosting your own ADFS service, you have to go through the process of deploying it, maintaining it, upgrading it, and most importantly of all, securing it. Wouldn’t it be nice if someone else would handle it all? Well, use Azure AD and they will! Microsoft are processing billions of logins via Azure AD. They can handle it. Granted you still have to do some management in setting up the new applications, and enabling the Conditional Access Policies to secure it but beyond this, you’re good to go.

Using Azure AD has the added advantage of using SCIM (System for Cross-domain Identity Management). SCIM is very useful for provisioning, deprovisioning and updating users and groups. Automating the user provisioning process is a huge win for any environment. With the Azure AD Provisioning in place, you can flow users from your HR system such as Workday, in to Active Directory or Azure Active Directory, from within AD you then flow it out to AAD via AAD Connect, you can use either static groups or dynamic groups to then flow your users out to SaaS products such as Slack (why aren’t you using teams?), Workplace by Facebook, Google and many others. The key feature to this, is it reduces a monotonous task that is performed by your Helpdesk/IAM team, reduces errors but also, ensures that accounts are deprovisioned when someone leaves. You can find a list of apps that support SCIM provisioning at

As well as all this goodness, using Azure AD, it can intelligently block access to attackers whilst allowing the user to carry on. ADFS has a smart lockout feature but Azure AD can take things further by providing MFA challenges in the event of a suspect breach.

In public preview is the Azure AD Identity Governance. This is something I am getting really excited for, and looking forward to going GA. IG is a fantastic way to ensure that the right person has the right access at the right time. You build up access packages which can contain groups, AAD applications and their roles and SharePoint sites. You specify policies to control who can get access to the packages, who reviews and approves the requests. This all works across both internal users and guests. With the ability to review the access and automatically revoke access for example when a contract ends. IG will be a real enabler for truly collaborative environments, no longer are you going to need to create inhouse accounts for external parties to use, you can now track and use guest accounts and grant the level off access required.

Granted Azure AD can’t complete everything that Windows Server AD can, but if you’re starting out a new business, currently using AAD as part of Office 365, or just looking at improving your postures and processes, why not look at embracing AAD fully? It’s being developed at a rate of knots. The more you dive in to Azure AD as an identity provider, the more you realise what it can do and how it can help you.


Leave a Reply

Your email address will not be published. Required fields are marked *