I’ve been working with a customer on designing a new Azure Multi Factor Authentication (MFA) service, replacing an existing 2FA (Two Factor Authentication) service based on RSA Authenticator version 7.
Now, typically Azure MFA service solutions in the past few years have been previously architected in the detail ie. a ‘bottom up’ approach to design – what apps are we enforcing MFA on? what token are we going to use? phone, SMS, smart phone app? Is it one way message, two way message? etc.
Typically a customer knew quite quickly which MFA ‘architecture’ was required – ie. the ‘cloud’ version of Azure MFA was really only capable of securing Azure Active Directory authenticated applications. The ‘on prem’ (local data centre or private cloud) version using Azure MFA Server (the server software Microsoft acquired in the PhoneFactor acquisition) was the version that was used to secure ‘on-prem’ directory integrated applications.
There wasn’t really a need to look at the ‘top down’ architecture. In aid of a ‘bottom up’ detailed approach – my colleague Lucian posted a very handy ‘cheat sheet’ last year, in comparing the various architectures and the features they support which you can find here.
New Azure MFA ‘Cloud Service’ Features
In the last few months however, Microsoft has been bulking up the Azure MFA ‘cloud’ option with new integration support for on-premise AD FS (provided with Windows Server 2016) and now on-premise Radius applications (with the recent announcement of the ‘public preview’ of the NPS Extension last month).
(On a side note: what is also interesting, and which potentially reveals wider trends on token ‘popularity’ selection choices, is that the Azure ‘Cloud’ option still does not support OATH (ie. third party tokens) or two-way SMS options (ie. reply with a ‘Y’ to authenticate). These new features have therefore forced the consideration of the primarily ‘cloud service’ architecture for both Radius and AD FS ‘on prem’ apps.
"It's all about the Apps"
Now, in my experience, many organizations share application architectures they like to secure with multi factor authentication options. They broadly fit into the following categories:
1. Network Gateway Applications that use Radius or SDI authentication protocols, such as network VPN clients and application presentation virtualisation technologies such as Citrix and Remote App
2. SaaS Applications that choose to use local directory credentials (such as Active Directory) using Federation technologies such as AD FS (which support SAML or WS-Federation protocols), and
3. SaaS applications that use remote (or ‘cloud’) directory credentials for authentication such as Azure Active Directory.
Applications that are traditionally accessed via only the corporate network are being phased out for ones that exist either purely in the Cloud (SaaS) or exist in a hybrid ‘on-prem’ / ‘cloud’ architecture.
These newer application architectures allow access methods from untrusted networks (read: the Internet) and therefore these access points also apply to trusted (read: corporate workstations or ‘Standard Operating Environment’) and untrusted (read: BYOD or ‘nefarious’) devices. In order to secure these newer points of access, 2FA or MFA solution architectures have had to adapt (or die).
What hasn’t changed however is that a customer when reviewing their 2FA or MFA choice of vendors will always want to choose a low number of MFA vendors (read: one), and expects that MFA provider to support all of their applications. This keeps user training cost low and operational costs low. Many are also fed up dealing with ‘point solutions’ ie. securing only one or two applications and requiring a different 2FA or MFA solution per application.
Customer Case Study
So in light of that background, this section now goes through the requirements in detail to really 'flush' out all the detail before making the right architectural decision.
Vendor Selection
This was taken place prior to my working with our customer, however it was agreed that Azure MFA and Microsoft were the ‘right’ vendor to replace RSA primarily based on:
- EMS (Enterprise Mobility + Security) licensing was in place, therefore the customer could take advantage of Azure Premium licensing for their user base. Azure Premium meant we would use the ‘Per User’ charge model for Azure MFA (and not the other choice of ‘Per Authentication’ charge model ie. being charged for each Azure MFA token delivered).
- Tight integration with existing Microsoft services including Office 365, local Active Directory and AD FS authentication services.
- Re-use of strong IT department skills in the use of Azure AD features.
Step 1: App Requirements Gathering
The customer I’ve been working with has two ‘types’ of applications:
1. Network Gateway Applications – Cisco VPN using an ASA appliance and SDI protocol, and Citrix NetScaler using Radius protocol.
2. SaaS Applications using local Directory (AD) credentials via the use of AD FS (on Server 2008 currently migrating to Server 2012 R2) using both SAML & WS-Federation protocols.
They wanted a service that could replace their RSA service that integrated with their VPN & Citrix services, but also ‘extend’ that solution to integrate with AD FS as well. The currently don’t use 2FA or MFA with their AD FS authenticated applications (which includes Office 365).
They did not want to extend 2FA services to Office 365 primarily as that would incur the use of static ‘app passwords’ for their Outlook 2010 desktop version.
Step 2: User Service Migration Requirements
The move from RSA to Azure MFA was going to involve the flowing changes as well to the way users used two factor services:
1. Retire the use of ‘physical’ RSA tokens but preserve a similar smart phone ‘soft token’ delivery capability
2. Support two ‘token’ options going forward: ‘soft token’ ie. use of a smart phone application or SMS received tokens
3. Modify some applications to use the local AD password instead of the RSA ‘PIN’ as a ‘what you know’ factor
4. Avoid the IT Service Desk for ‘soft token’ registration. RSA required the supply of a static number to the Service Desk who would then enable the service per that user. Azure MFA uses a ‘rotating number’ for ‘soft token’ registrations (using the Microsoft Authenticator application). This process can only be performed on the smart phone itself.
So mapping out these requirements, I then had to find the correct architecture that met their requirements (in light of the new ‘Cloud’ Azure MFA features):
Step 3: Choosing the right Azure MFA architecture
I therefore had a unique situation, whereby I had to present an architectural selection – whether to use the Azure MFA on premise Server solution, or Azure MFA Cloud services. Now, both services technically use the Azure MFA ‘Cloud’ to deliver the tokens, but the sake of simplicity, it boils down to two choices:
1. Keep the service “mostly” on premise (Solution #1), or
2. Keep the service “mostly” ‘in the cloud’ (Solution #2)
The next section goes through the ‘on-premise’ and ‘cloud’ requirements of both options, including specific requirements that came out of a solution workshop.
Solution Option #1 – Keep it ‘On Prem’
New on-premise server hardware and services required:
- One or two Azure MFA Servers on Windows Server integrating with local (or remote) NPS services, which performs Radius authentication for three customer applications
- On-premise database storing user token selection preferences and mobile phone number storage requiring backup and restoration procedures
- One or two Windows Server (IIS) hosted web servers hosting the Azure MFA User Portal and Mobile App web service
- Use of existing reverse proxy publishing capability of the user portal and mobile app web services to the Internet under an a custom web site FQDN. This published mobile app website is used for Microsoft Authenticator mobile app registrations and potential user self-selection of factor e.g. choosing between SMS & mobile app for example.
New Azure MFA Cloud services required:
- User using Azure MFA services must be in local Active Directory as well as Azure Active Directory
- Azure MFA Premium license assigned to user account stored in Azure Active Directory
Advantages:
- If future requirements dictate Office 365 services to use MFA, then ADFS version 3 (Windows Server 2012) directly integrates with on premise Server MFA. Only AD FS version 4 (Windows Server 2016) has capability in integrating directly with the cloud based Azure MFA.
- The ability to allow all MFA integrated authentications through in case Internet services (HTTPS) to Azure cloud are unavailable. This is configurable with the ‘Approve’ setting for the Azure MFA server setting: “when Internet is not accessible:”
Disadvantages:
- On-premise MFA Servers requiring uptime & maintenance (such as patching etc.)
- Have to host on-premise Azure website and publish to the Internet under existing customer capability for user self service (if required). This includes on-premise IIS web servers to host mobile app registration and user factor selection options (choosing between SMS and mobile app etc.)
- Disaster Recovery planning and implementation to protect the local Azure MFA Servers database for user token selection and mobile phone number storage (although mobile phone numbers can be retrieved from local Active Directory as an import, assuming they are present and accurate).
- SSL certificates used to secure the on-premise Azure self-service portal are required to be already supported by mobile devices such as Android and Apple. Android devices for example, do not support installing custom certificates and requires using an SSL certificate from an already trusted vendor (such as THAWTE)
Solution Option #2 – Go the ‘Cloud’!
New on-prem server hardware and services required:
- One or two Windows Servers hosting local NPS services which performs Radius authentication for three customer applications. These can be existing available Windows Servers not utilizing local NPS services for Radius authentication but hosting other software (assuming they also fit the requirements for security and network location)
- New Windows Server 2016 server farm operating ADFS version 4, replacing the existing ADFS v3 farm.
New Azure MFA Cloud services required:
- User using Azure MFA services must be in local Active Directory as well as Azure Active Directory
- User token selection preferences and mobile phone number storage stored in Azure Active Directory cloud directory
- Azure MFA Premium license assigned to user account stored in Azure Active Directory
- Use of Azure hosted website: ‘myapps.microsoft.com’ for Microsoft Authenticator mobile app registrations and potential user self selection of factor e.g. choosing between SMS & mobile app for example.
- Configuring Azure MFA policies to avoid enabling MFA for other Azure hosted services such as Office 365.
Advantages:
- All MFA services are public cloud based with little maintenance required from the customer’s IT department apart from uptime for on-premise NPS servers and AD FS servers (which they’re currently already doing)
- Potential to reuse existing Windows NPS server infrastructure (would have to review existing RSA Radius servers for compatibility with Azure MFA plug in, i.e. Windows Server versions, cutover plans)
- Azure MFA user self-service portal (for users to register their own Microsoft soft token) is hosted in cloud, requiring no on-premise web servers, certificates or reverse proxy infrastructure.
- No local disaster recovery planning and configuration required. NPS services are stateless apart from IP addressing configurations. User information token selections and mobile phone numbers stored in Azure Active Directory with inherent recovery options.
Disadvantages:
- Does not support AD FS version 3 (Windows Server 2012) for future MFA integration with AD FS SaaS enabled apps such as Office 365 or other third party applications (i.e. those that uses AD FS so users can use local AD authentication credentials). These applications require AD FS version 4 (Windows Server 2016) which supports the Azure MFA extension (similar to the NPS extension for Radius)
- The Radius NPS extension and the Windows AD FS 2016 Azure MFA integration do not currently support the ability to approve authentications should the Internet go offline to the Azure cloud i.e. cannot reach the Azure MFA service across HTTPS however this may be because….
- The Radius NPS extension is still in ‘public preview’. Support from Microsoft at this time is limited if there are any issues with it. It is expected that this NPS extension will go into general release shortly however.
Conclusion and Architecture Selection
After the workshop, it was generally agreed that Option #2 fit the customer’s on-going IT strategic direction of “Cloud First”.
It was agreed that the key was replacing the existing RSA service integrating with Radius protocol applications in the short term, with AD FS integration viewed as very much ‘optional’ at this stage in light of Office 365 not viewed as requiring two factor services (at this stage).
This meant that AD FS services were not going to be upgraded to Windows Server 2016 to allow integration with Option #2 services (particularly in light of the current upgrade to Windows Server 2012 wanting to be completed first).
The decision was to take Option #2 into the detailed design stage, and I’m sure to post future blog posts particularly into any production ‘gotchas’ in regards to the Radius NPS extension for Azure MFA.
During the workshop, the customer was still deciding whether to allow a user to select their own token ‘type’ but agreed that they wanted to limit it if they did to only three choices: one way SMS (code delivered via SMS), phone call (ie. push ‘pound to continue’) or the use of the Microsoft Authenticator app. Since these features are available in both architectures (albeit with different UX), this wasn’t a factor in the architecture choice.
The limitation for Option #2 currently around the lack of automatically approving authentications in case the Internet service ‘went down’ was disappointing to the customer, however at this stage it was going to be managed with an ‘outage process’ in case they lost their Internet service. The workaround to have a second NPS server without the Azure MFA extension was going to be considered as part of that process in the detailed design phase.