How Azure AD and a Load Balancer Can Simplify App Delivery

This post was sponsored by Kemp

Microsoft’s offering in the single sign-on space for several years has been Azure Active Directory, which serves as the underlying directory service for Microsoft 365. This service is also widely used as the SSO and provisioning service compatible with most third-party SaaS applications such as ServiceNow, Salesforce, Atlassian, and many more.

In a surprising turnaround from a few years ago, Microsoft has been making significant inroads into the SSO marketplace, mostly driven by a combination of sales of Microsoft 365 E3 licensing to enterprises, a practically complete set of features such as Conditional Access, a reasonably large catalog of straightforward SSO, and provisioning integrations and integration into bundles services such as Intune. What this means is that it is difficult for a company deploying Microsoft 365 not to leverage Azure AD advanced functionality. While Okta was seen as a default go-to, or AD FS was deployed on-premises for additional control, this is no longer the case.

A common complaint through I hear on a regular basis is from customers that don’t have the full suite – and have bought and adopted Office 365 but haven’t got some of the security add-ins. While technically they have been ready to utilize SSO services into other applications, the bundled Azure AD Free version only recently expanded its support for SSO integrations. A second common gripe with the Azure AD version Microsoft bundled remains the lack of Conditional Access functionality – which Microsoft has gone a reasonable way to address by introducing Security Defaults. Security Defaults allow an IT administrator to gradually enable Multi-Factor Authentication (MFA) for users with limited effort, disallow unsafe legacy authentication methods and enforce additional sign-in security for administrators.

These changes mean that it’s easier for IT departments to run a secure Office 365 deployment on even the most basic Office 365 plans, and Azure AD can be used by customers as a more complete SSO solution, with integral MFA for other applications at no cost.

Understanding Azure AD as an SSO solution

A basic implementation of Azure AD Connect, Microsoft’s directory synchronization tool, mirrors local Active Directory accounts to Azure AD and includes built-in functionality that enables SSO by several methods.

In a modern deployment, organizations either directly join Windows 10 PCs, or enroll mobile devices and Macs to Azure AD and Intune for full management, which enables SSO to any service–connected to Azure AD by default. Organizations running traditional on-premises AD environments also have this capability either by using the most common method, Hybrid Azure AD join or Seamless SSO.

Hybrid Azure AD Join (HAADJ) works by the administrator configuring a Group Policy to auto-enroll domain-joined Windows PCs to Azure AD, so the user is always signing into Azure AD at the point of PC login. Seamless SSO works differently and enables Windows Integrated Authentication to be used for Azure AD Join via a local computer object that assists the Kerberos aspects of the sign-in process, on behalf of Azure AD.

This makes it extremely easy to utilize Azure AD as a single-sign-on solution both for domain-joined PCs, cloud–managed PCs, mobile devices, and once signed-in via a browser or rich application, for personal devices in a BYOD scenario.

Just like Office 365, any SAML application registered to Azure AD can be signed-in using the same credentials and session, and when used, Multi-Factor Authentication can be triggered. In the case of Azure AD Premium Plan 1 and higher, Conditional Access Policies can be used to only allow login from domain-joined PCs, Intune compliant devices, particular IP ranges or add additional protections, such as MFA, risk-based sign-in or using session-based controls to prevent actions such as downloads or copy-and-paste via Microsoft Cloud App Security.

Protecting Enterprise applications without VPN or building Azure-based services protected by Azure AD

A recent change in the move to mass remote working is the challenge of maintaining access to enterprise applications that traditionally require a VPN for access.

This brings additional challenges as VPN access usually impedes access to cloud-based services and without split-tunneling, this introduces additional latency when using services like Teams. When coupled with a substantial increase in remote operations, this can add a significant load to existing on-premises infrastructure too. For organizations building out applications to Azure, it adds additional latency by routing users through on-premises infrastructure when application access could be via ISP peering directly with Microsoft.

If you have Azure AD Premium Plan 1 or higher for all users who need to access these applications (or Microsoft 365 E3 and similar) then one option is Azure AD Application Proxy.

This is a solution that does not require a load balancer or application server to be externally published as it relies upon Azure services acting as an HTTPS endpoint for application access. This endpoint connects to one or more on-premises agents that make outbound connections to wait for requests. This is a good solution for publishing simple applications, although configurations can be complex and in most circumstances still require a traditional load balancer.

A more flexible solution is to utilize a dedicated load balancer that includes the required load balancing functionality, web application firewall functionality, and security technologies to perform both the load balancing and integrate that with the SSO services.

In addition, because using the load balancer for SSO does not require Azure AD Premium licenses, all customers with Office 365 licenses, or using an Azure AD Free subscription, can securely publish applications externally utilizing SSO and MFA.

This allows the following scenarios to be configured easily:

Add internal or line-of–business applications to a common application library alongside Microsoft 365 apps.

Publish an existing traditional web application for remote access quickly.
Publish complex multi-geo web applications for remote access without redesigning the way application access works or introducing per-geo URLs to meet Azure AD Application Proxy requirements.
Publish Azure–based cloud applications using cloud-native load balancer technologies.
Easily integrate line-of-business applications into Teams tabs by leveraging Azure AD SSO.
Use as a foundation to support building Teams applications that contain web application content.

For Azure AD Premium or Microsoft 36 customers, provide conditional access to web applications in the same way Microsoft 365 or SaaS applications support.
For Azure AD Free or Office 365 customers, provide SSO and MFA to web applications at no extra cost.

Integrating Kemp Loadmaster with Azure AD for SSO

In the following example, we will publish an existing line of business application that runs on-premises to our Enterprise applications library in Azure AD. This will use Kemp’s Azure AD integration that provides automatic SAML-based sign-in.

The full guide for Kemp integration is available on Microsoft Docs, therefore we won’t cover every step throughout this process. Instead, we will cover the basics to demonstrate the straightforward integration process and you can also find a video of the process here – Integrating Kemp Loadmaster with Azure AD for SSO.

We will start with the finished product. Once published, our application, named Corp App will show in Microsoft 365 All Apps page and users will be able to pin this to their menu (or “waffle”) in the top-left corner:

Naturally, users will also be able to bookmark and visit the application directly using its existing URL (in our case https://corpapp.allabout365.com), follow links from our SharePoint Intranet, or add the web application URL as a channel tab into Teams for quick access.

To begin though, we will need to visit the Azure AD admin center and navigate to Enterprise Applications and choose New Application:

From the gallery, we will search from Kemp and choose Kemp LoadMaster Azure AD integration. This will serve as the application we will publish, therefore we will name it after the application – in our example Corp App:

Next, we will navigate to Single Sign-On and enable SAML sign-on. We will edit the Basic SAML Configuration and enter the URL that corresponds to the published VIP on the Kemp Loadmaster:

Next in Azure AD, we will download both the Certificate (Base 64) and Federation Metadata XML files:

To complete the basic configuration in Azure AD, we will then configure options on the Properties tab including whether user assignment is required, an application icon and whether the application is enabled and visible:

After configuration in Azure AD, we will then configure the respective options on the Kemp Loadmaster. We will first need to import the certificate downloaded from Azure AD.

To do this, login into the LoadMaster and navigate to Certificates & Security>Intermediate Certs, then import the Certificate (Base 64) providing an easy to distinguish name:

We will then need to add the first of two SSO configurations. First, the client-side configuration supports redirection to Azure AD for SSO. The second, server-side configuration, supports passing the success authentication back to the web application using Kerberos constrained delegation.

Choose an appropriate name for the client-side configuration, then choose Add:

On the new client-side configuration page, we will choose the authentication protocol SAML, then choose MetaData File from the IDP Provisioning option, as shown below. We will then select the Federation Metadata XML file we downloaded from the Azure AD portal.

To enable the SSO configuration and allow it to be tested, we will then need to select the VIP from Virtual Services>View/Modify Services. Under ESP Options, we must then set the first part of the configuration necessary to support Azure AD sign–in.

Choose Enable ESP, configuring Client Authentication Mode to SAML, SSO Domain to the Client-Side Configuration profile configured above, and then set the Allowed Virtual Hosts and Allowed Virtual Directories to appropriate values.

In the example below, we have used the corpapp.allabout365.com FQDN and allowed all virtual directories (/*) to use this configuration:

At this point in the configuration, attempting access to the load–balanced application will redirect to Azure AD login pages, and you can test the sign-in process.

If this application is an internal web page that does not require authentication, this may be the only configuration you require.

If the website must use authentication then you must configure this to use Windows Authenticated Authentication, with Negotiate configured in IIS to support Kerberos-based SSO.

You will also need to create an AD user account, and configure it to be used for Kerberos constrained delegation for your website FQDN and respective application servers. This (more complex) process is detailed in the Microsoft Docs guidance for Kemp Loadmaster and may be familiar to you if you’ve published a load–balanced application in the past that uses Kerberos authentication.

Once this account is configured, our final step is to configure this as a new server–side configuration in the Manage SSO page on the LoadMaster. In our example, we specify Authentication Protocol as Kerberos Constrained Delegation, and add our Realm, one or more domain controllers hosting the KDC and the delegated account username and password:

Finally, to enable the server-side configuration for the VIP, we will return to the ESP Options page and select Server Authentication Mode as KDC and select our new server-side configuration:

After completing this configuration, we can now test the Azure AD application and validate authenticated, load–balanced web pages can be accessed via this method.

Reference:https://petri.com/how-azure-ad-and-a-load-balancer-can-simplify-app-delivery