Mobilizing Kerberos: Getting Started

Introduction

The Mobilizing Kerberos: Getting Started guide provides a high-level overview of Kerberos and the challenges that enterprises face when mobilizing internal, Kerberos-secured websites. It also discusses how VMware Unified Access Gateway™ can solve these challenges.

Audience

This guide is for mobility administrators who want to mobilize internal, Kerberos-secured websites.

What Is Kerberos?

The Kerberos protocol has been in use since Windows 2000 and is still widely used in enterprises today. Kerberos is the original single sign-on (SSO) that has existed long before the SAML-based SSO that SaaS web apps commonly use today. An example of Kerberos authentication in use: when you log in to your laptop on the corporate network and are then automatically logged in when visiting your company’s intranet in a web browser.

To summarize a basic workflow:

  1. You log in to your laptop on the corporate network.
  2. The Key Distribution Center (KDC - usually running on the domain controller) provides you a ticket.
  3. The ticket grants you access to the Kerberos-secured websites you are entitled to.

These Kerberos-secured websites cause difficulty when the word mobility is mentioned. Kerberos was never designed to be a mobile protocol and has a couple of implementation details that do not work well in the mobile world.

  • Kerberos and UDPUDP is a lossy (connectionless) protocol, with the understanding that if a packet is lost, it is not fatal to the application using it. It is often used in real-time audio/video streaming. If TCP (a connection-based protocol) was used, the whole stream would stall every time a packet was missed, effectively not being real time. The cellular carrier networks that mobile devices use are not reliable. Therefore, UDP packets have a much higher chance of being lost than on a high-bandwidth corporate network where Kerberos is typically used. This is bad for an authentication flow.
     
  • Kerberos requires the client device to communicate directly to the KDC – This is not an issue for domain-joined laptops, as they are already on the corporate network. iOS and Android devices are connected to the Internet through any type of carrier or Wi-Fi network. These devices generally do not have access to the KDC.

So, how do you mobilize these internal, Kerberos-secured websites? Not only are they behind the corporate firewall but the client device requires direct access to the KDC to get a ticket to log in.

Perhaps you considered the following solution; recode the websites to use a modern SSO authentication flow such as SAML (rather than using Kerberos) and federate the logins to an identity provider (IdP), such as VMware Identity Manager™.

However, enterprises can be slow to change for the following reasons:

  • The websites work – why change it?
  • No-one at the company is familiar with Kerberos.
  • There are no resources available to implement a mobility project.
  • There is a substantial risk that changes might the break existing setup.

If you have been tasked with mobilizing these websites so that can they be securely accessed on a mobile device anywhere in the world, the solution usually has to work with the existing website as it is today.

Is Kerberos Support Available from Apple and Google?

This section reviews support from Apple and Google to implement Kerberos-secured websites.

Apple

In iOS 7, Apple introduced Enterprise Single Sign-On. This allowed for native apps (such as the Safari web browser) to leverage iOS to contact a KDC and exchange a user certificate for a Kerberos ticket to log in to a back-end web resource.

The initial login is performed during device enrollment into Mobile Device Management (MDM), as an LDAP Active Directory (AD) authentication check is done at that point. Subsequently, after the device is enrolled, a user certificate is securely provisioned through MDM, which is then used for authentication with AD from that point forward.

Although this approach does work, it has a couple of requirements that might not be ideal:

  • The iOS device must directly access the KDC and communicate to Kerberos. This poses a challenge for iOS devices that are anywhere in the world, connected to any network. If they are not connected to your corporate Wi-Fi and can directly access the infrastructure zone where the KDC is located, a VPN is required to access the same network as the KDC. The UDP requirement for Kerberos is also a potential issue, as allowing inbound UDP traffic through the corporate firewall might be problematic for your network security team—especially if load balancers are used.
     
  • The device must be secured through MDM (managed device) as the Kerberos authentication is handled directly by iOS. For bring-your-own-device (BYOD) programs, your users might only want a containerized app approach (unmanaged device) and not be willing to enroll their device into MDM.

Google

There is no Enterprise Single Sign-On or system-wide Kerberos integration in Android.

How Can You Enable Mobile Access to Kerberos-Secured Internal Websites?

Instead of focusing on the device requirement to communicate to Kerberos, you can delegate the Kerberos authentication to a middleware gateway component running on the corporate network. Using a gateway component addresses the following challenges:

  • Android devices do not support Kerberos.
  • Unmanaged iOS devices (that is, not under MDM) cannot use the Enterprise Single Sign-On feature to access Kerberos-secured websites.
  • Complex firewall and load balancer changes are required to allow Kerberos UDP traffic to flow.
  • The device must communicate directly to the KDC.

Here is an example: the intranet website is https://it.corp.local and your device is connected to your home Wi-Fi network.

  • Access – This website is not open to the Internet. If you try to connect, the website will not resolve in a web browser. The device must be on your internal corporate network to access it.
     
  • Authentication – This website is Kerberos-secured. The only way it will load is to send it a valid Kerberos ticket.

 

The next steps build out what must happen to enable mobile access to a Kerberos-secured website.

  1. A web browser on an iOS or Android device must load a Kerberos-secured website on your internal corporate network.

 

  1. Access: When the user navigates to https://it.corp.local in the web browser, the request must be sent to a gateway component (noted as GW in the diagrams) in your corporate network. The gateway component must be in your network’s DMZ, so it is reachable from the Internet.

    Your security team might mandate that traffic cannot go directly from the Internet through to the internal network. So, the gateway must verify that the device is secure before forwarding the request any further.

 

  1. Authentication: After verifying that the device is secure, the gateway must handle user authentication. If successfully authenticated, it must contact the internal KDC to request a Kerberos ticket (on behalf of the user).

 

  1. The gateway requests the internal, Kerberos-secured website, passing it the Kerberos ticket for authentication, and returns the website contents back to the web browser on the device.

 

The following table considers potential Access and Authentication workflows that would work for:

  • The native browser on a managed device
  • VMware Workspace ONE® Web (the VMware enterprise-grade web browser app for iOS and Android) on an unmanaged device

 

Native Browser (Managed Device)

Workspace ONE Web (Unmanaged Device)

Access

The gateway requires a public DNS record to route traffic to it and must be internet facing.

The native browser (for example, Safari) opens at the relevant URL to reach the gateway.

The gateway requires a public DNS record to route traffic to it and must be internet facing.

The Workspace ONE Web app includes the Workspace ONE SDK, which means that it supports proxying of traffic at the app level. The URL patterns for proxying can be enforced by Workspace ONE UEM administrator policy, allowing for split tunneling.

Authentication

The browser can be challenged for a SAML assertion by the gateway. It is assumed that the user has already signed in to an IdP as part of the enrollment process and so this existing session can be used for SSO (meaning no user interaction is required).

The Workspace ONE Web app can be challenged for a user certificate by the Gateway. As the app contains the Workspace ONE SDK, this can handle retrieving the user certificate and automatically presenting it for authentication (meaning no user interaction is required).

 

Introducing the VMware Unified Access Gateway

VMware has a secure gateway component that supports the use cases stated in the previous table; the Unified Access Gateway. A platform that provides secure edge services and access to defined resources that reside in the internal network. This allows authorized, external users to access internally located resources in a secure manner.  

 

Native Browser (Managed Device)

Workspace ONE Web (Unmanaged Device)

Unified Access Gateway with:

  • Web Reverse Proxy edge service enabled in Identify Bridging mode and configured to perform SAML -> Kerberos bridge.

Unified Access Gateway with:

  • VMware Tunnel edge service enabled, and Tunnel Proxy component configured.
  • Web Reverse Proxy edge service enabled in Identity Bridging and configured to perform User Certificate -> Kerberos bridge.

Managed Device Use Case Detailed Example

 

  1. An end user launches the native browser app (for example, Safari) on their managed mobile device from any network. They navigate to the public URL (https://uag.airwlab.com/it) of the internal site and this reaches the Unified Access Gateway Reverse Proxy edge service. A security check is performed (for example, to ensure the device is not jailbroken (iOS), or rooted (Android)) and unsecure devices are blocked. You do not want unsecure devices accessing your internal corporate network.
  2. The Identity Bridging feature part of the Unified Access Gateway Reverse Proxy edge service is configured to accept a SAML assertion to authenticate a user. To achieve this, the browser is redirected to VMware Identity Manager (a component of Workspace ONE) which handles the SSO, returning a SAML assertion upon successful authentication.
  3. The browser is then redirected back to the Unified Access Gateway, passing it the SAML assertion. The Unified Access Gateway validates that the SAML assertion is from a trusted IdP.
  4. The Unified Access Gateway extracts the username from the SAML assertion and contacts the KDC (running on corp.local) to retrieve a Kerberos ticket on behalf of the user to gain access to https://it.corp.local. This is called Kerberos Constrained Delegation (KCD - not to be confused with KDC).
  5. It then makes a request for the https://it.corp.local website, passing the Kerberos ticket for authentication.
  6. The web server successfully authenticates the user and returns the website contents.
  7. The Unified Access Gateway sends the website contents back to the native browser on the device.
  8. The end user has access to https://it.corp.local on their mobile device, without entering any credentials. You have now successfully mobilized this Kerberos-secured internal website on a managed device!

Unmanaged Device Use Case Detailed Example

 

 

  1. An end user installs the Workspace ONE Web app through the VMware Workspace ONE® Intelligent Hub app for iOS or Android. They launch it from any network; SSO occurs and Workspace ONE UEM issues it a unique user certificate.
  2. They navigate to the public URL (https://uag.airwlab.com/it) of the internal site. Another benefit of using Workspace ONE Web is that the Workspace ONE UEM administrator can configure this as a bookmark within the app, or even set it to be the home page (so user input is not required). This request reaches the Tunnel Proxy on Unified Access Gateway VMware Tunnel edge service which performs a security check. The Workspace ONE SDK also does a compromised check to ensure that the device is not jailbroken (iOS), or rooted (Android)). Unsecure devices are blocked. You do not want unsecure devices accessing your internal corporate network.
  3. The Unified Access Gateway is configured to request a valid certificate on any incoming request, to authenticate the user. To achieve this, the Workspace ONE SDK within Workspace ONE Web automatically sends the user certificate it was provisioned with. Assuming that the authentication check passes against AD, the Unified Access Gateway now knows who the user is.
  4. The Unified Access Gateway contacts the KDC (running on corp.local) to retrieve a Kerberos ticket on behalf of the user to gain access to https://it.corp.local. This is called Kerberos Constrained Delegation (KCD - not to be confused with KDC).
  5. It then makes a request for the https://it.corp.local website, passing the Kerberos ticket for authentication.
  6. The web server successfully authenticates the user and returns the website contents.
  7. The Unified Access Gateway sends the website contents back to the Workspace ONE Web app on the device.
  8. The end user has access to https://it.corp.local on their mobile device, without entering any credentials. You have now successfully mobilized this internal, Kerberos-secured website on an unmanaged device!

Conclusion

VMware Unified Access Gateway addresses all of the following challenges:

 

Challenge

Solution

Android devices do not support Kerberos.

The device is not required to communicate with Kerberos.

 

Unmanaged iOS devices (that is, not under MDM) cannot use the Enterprise Single Sign-On feature to access Kerberos-secured sites.

Unified Access Gateway provides access on unmanaged devices.

 

Complex firewall/load balancer changes are required to allow for Kerberos UDP traffic to flow.

The only inbound requirement is standard HTTPS/TCP on a configurable port to the required Unified Access Gateway DMZ component.

The device must communicate directly to the KDC.

Only the Unified Access Gateway in Identity Bridging mode and Reverse Proxy edge service are required to communicate to Kerberos.

 

Also, the Unified Access Gateway provides a consistent solution for both iOS and Android devices, in both managed and unmanaged modes. In addition, no changes are required for the internal website.

How to Get Started

Explore the following resources to learn more about Unified Access Gateway.

Mobilize your internal, Kerberos-secured websites today!

About the Authors

The Mobilizing Kerberos: Getting Started guide was written by:

  • James Murray, Staff Solution Engineer in End-User Computing, VMware
  • Andreano Lanusse, Staff Architect in End-User Computing, subject matter expert for Unified Access Gateway, VMware

 

Appreciation and acknowledgment for contributions from:

  • Adarsh Kesari, Staff Solutions Architect in End-User Computing, VMware