Kerberos application reference architecture

To make things easier for employees, many organizations have developed applications to use Kerberos. This may also be referred to as SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism or Kerberos over HTTPS), Windows Integrated Authentication, or Windows Desktop Authentication or Windows SSO.

This allows an employee logged into their Windows desktop easy access to an application without being prompted for their Active Directory (AD) credentials. Many other third party applications from both Microsoft and other vendors have also adapted their solutions to use Kerberos for authentication. While this has worked well for many years, users are much more mobile in today’s works and use a variety of devices, and locations and are not always are logged into a Windows device connected to an AD domain. Access Gatewaycan be used to bridge the gap between the modern mobile workforce and these applications built around Windows authentication.
In this scenario, Okta first logs the user in, possibly using the users AD credentials, or a MFA token, and then the user proxies through the Access Gateway to the application that is designed for Windows Kerberos authentication. Access Gateway reaches out to a Windows Kerberos cluster and through an established trust, can have the Windows Kerberos cluster create a token for the user, and then insert that token into the HTTP headers which is passed to the application. The result is the application sees the token, and identifies who the user is, and the application does not need to be changed when adding it behind Okta.

Additionally users can now access that application using non domain joined devices including mobile browsers. If the Access Gateway is deployed in the DMZ, and is publicly accessible, these users do not need to VPN into the network in order to access the application.

Approach

To deploy Access Gateway to secure applications in an environment described above, it is best to begin deployment of a base architecture and then add specific features as needed. This methodology will allow an organization to begin moving forward in an agile fashion and not become overly bogged down in requirements analysis.

Key steps in determining an overall architecture include:

  • Identify how applications are to be integrated with Okta and Access Gateway. Typical integrations include:
  • Identify how many users will access the applications and how often. This will help determine how many instances of Access Gateway are required, what number of load balancers are necessary and generally how the architecture components will be distributed.
  • Identify which applications should be accessible through Access Gateway from the internet and which should require the user have access to the internal network. Typically this starts as a subset of applications, and expands over time.
  • Identify and work with the AD team to get the proper system accounts and trusts / keytabs.
  • Identify all AD infrastructure to determine the connections from Access Gateway to AD and the Windows Kerberos ticketing infrastructure.

 

Access Gateway Kerberos architectures

Access Gateway Kerberos installations can be deployed in any number of possible combinations. Common architecture are:

Single Access Gatewayinstance The simple kerberos instanceAccess Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway. This architecture represents a baseline for development and testing.
Simple Kerberos cluster The simple kerberos clusterAccess Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway.
This architecture extends the single Kerberos instance by addingAccess Gateway cluster.
Kerberos cluster The kerberos clusterAccess Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway and a redundant Kerberos cluster providing capacity and fault tolerance on the Kerberos side..
Multiple Kerberos domain The multiple kerberos domain Access Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway and multiple Kerberos trusted domains.

Architectures are broken down into the following functional areas:

External internet The external internet represents clients that access applications, as well as including your Okta Org.
DMZ The DMZ houses an Access Gateway cluster, and associated components, to allow access to applications from the external internet.
Internal The internal network houses the applications being protected by Access Gateway as well as other components required to make these applications widely available.

The simple Kerberos instance Access Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway.
This architecture represents a baseline or starting point for other architectures.

This architecture is designed to meet the following requirements:

  • Protect a Kerberos (Windows IIS) based service.
  • Provide a baseline for testing and development.

Benefits and drawbacks

Benefits Drawbacks
  • Simple installation
  • Baseline for testing, proof of concept etc.
  • Can be used to replace VPN
  • Not fault tolerant.
  • No load balancing or high availability.
  • Not intended for production.
  • Administration server access requires SSH port 22, and HTTPS ports 443, be open. See Prerequisites for deploying Access Gateway for details.
 

Architecture

Components

Location

Component Description

External internet

 

 

 

Web clients

Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.

comsumer-app1.example.com
URLs not shown

URL representing the application an external web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.

Okta org

Your Okta org, providing identity services.

Okta org Universal Directory

Okta universal directory, housed within an Okta org, containing users outside other LDAP/AD implementations. Typically these include other customer accounts, partner accounts and more.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.

DMZ

Access Gateway Access Gateway cluster, located in the DMZ is used to provide access to applications used by external internet clients.
Contains a Kerberos service and a keytab.
See Create keytab for details of creating a keytab.
See Add Kerberos service for details of defining a Access Gateway Kerberos service.
Typically hosted in a virtual environment such as Amazon Web Services, MS Azure, Oracle OCI or something similar. See Manage Access Gateway deployment.

Firewall

DMZ to internal firewall

Traditional firewall between DMZ and the internal network.

 

Internal network

 

 

Service/Protected application

 The set of protected web resources, in this case Microsoft Services, accessed using the comsumer-app1.internal-example.com URLs.

Supported versions:

  • Microsoft IIS IWA -iIS 7 or later
  • Microsoft OWA IWA - IIS 7 or later

Microsoft domain service instance with Key Distribution Center

Domain service containing a Key Distribution Center (KDC) . Typically a KDC uses an Active Directory database as its credential backing store.
During run time operation, the KDC instance services requests for Kerberos tickets which are then used with Kerberos enabled services such as Microsoft IIS.

Other considerations

 

DNS is typically split externally vs internally. All external URLs, such as [appN|comsumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|comsumer-app1].internal-example.com, would be served by internal DNS.

Most architectures forward log events to an external syslog component. Okta strongly recommends that a logging server be configured for all Access Gateway environments.
See Configure log forwarders for more information on configuring log forwarding.


Additionally, Access Gateway itself is typically managed via internal access only. That is, administrators typically access Access Gateway itself from behind the firewall. This is shown in other architectures.

The simple Kerberos clusterAccess Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway.
This architecture extends the single Kerberos instance by addingAccess Gateway cluster.

This architecture is designed to meet the following requirements:

  • Protect a Kerberos (Windows IIS) based service.
  • Meet basic fault tolerance and high availability needs for Access Gateway.

Benefits and drawbacks

BenefitsDrawbacks
  • Relatively simple installation.
  • Can be used to replace VPN.
  • Provides basic fault tolerance and capacity support.
  • Can be expanded with additional workers as required to add capacity.
  • Load balanced.
  • Admin instance is accessed behind the firewall.
  • Single virtual environment.

  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions).

 

Architecture

Components

Location

ComponentDescription

External internet

 

 

 

Web clients

Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.

comsumer-app1.example.com
URLs not shown

URL representing the application an external web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.

Okta org

Your Okta org, providing identity services.

Okta org Universal Directory

Okta universal directory, housed within an Okta org, containing users outside other LDAP/AD implementations. Typically these include other customer accounts, partner accounts and more.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.

 







DMZ
Pre load balancer Balances load between clients and the cluster. Positioned between clients and the cluster.Pre load balancer Balances load between clients and the cluster. Positioned between clients and the cluster.
Access GatewayAccess Gateway cluster, located in the DMZ is used to provide access to applications used by external internet clients.
Contains a Kerberos service and a keytab.
See Create keytab for details of creating a keytab.
See Add Kerberos service for details of defining a Access Gateway Kerberos service.
Typically hosted in a virtual environment such as Amazon Web Services, MS Azure, Oracle OCI or something similar. See Manage Access Gateway deployment.

Firewall

DMZ to internal firewall

Traditional firewall between DMZ and the internal network.

 







Internal network

 

 

Service/Protected application

 The set of protected web resources, in this case Microsoft Services, accessed using the comsumer-app1.internal-example.com URLs.

Supported versions:

  • Microsoft IIS IWA -iIS 7 or later
  • Microsoft OWA IWA - IIS 7 or later

Pre internal Kerberos domain load balance

Load balancer for the Kerberos domain service cluster.

Microsoft domain service cluster with Key Distribution Center

Domain service cluster containing a Key Distribution Center (KDC) .
In this architecture the Domain service/KDC represents multiple instances acting as a cluster.

Other considerations

 

DNS is typically split externally vs internally. All external URLs, such as [appN|comsumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|comsumer-app1].internal-example.com, would be served by internal DNS.

Most architectures forward log events to an external syslog component. Okta strongly recommends that a logging server be configured for all Access Gateway environments.
See Configure log forwarders for more information on configuring log forwarding.


Additionally, Access Gateway itself is typically managed via internal access only. That is, administrators typically access Access Gateway itself from behind the firewall. This is shown in other architectures.

The Kerberos clusterAccess Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway and a redundant Kerberos cluster.
This architecture represents an environment providing fault tolerance for both Access Gateway and Kerberos.

This architecture is designed to meet the following requirements:

  • Protect a Kerberos (Windows IIS) based service.
  • Meets basic fault tolerance and high availability needs for Access Gateway
  • Meet basic fault tolerance and high availability for the Kerberos domain and Key Distribution Center (KDC).

Benefits and drawbacks

BenefitsDrawbacks
  • Can be used to replace VPN.
  • Provides basic fault tolerance and capacity support.
  • Can be expanded with additional workers as required to add capacity.
  • Load balanced.
  • Admin instance is accessed behind the firewall.
  • Kerberos domain and KDC are both fault tolerant and redundant.
  • Complex Access Gateway domain.
  • More complex Kerberos domain.
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions).
 

Architecture

Components

Location

ComponentDescription

External internet

 

 

 

Web clients

Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.

comsumer-app1.example.com
URLs not shown

URL representing the application an external web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.

Okta org

Your Okta org, providing identity services.

Okta org Universal Directory

Okta universal directory, housed within an Okta org, containing users outside other LDAP/AD implementations. Typically these include other customer accounts, partner accounts and more.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.

 







DMZ
Pre Access Gateway load balancer. Pre load balancer Balances load between clients and the cluster. Positioned between clients and the cluster.
Access GatewayAccess Gateway cluster, located in the DMZ is used to provide access to applications used by external internet clients.
Contains a Kerberos service and a keytab.
See Create keytab for details of creating a keytab.
See Add Kerberos service for details of defining a Access Gateway Kerberos service.
Typically hosted in a virtual environment such as Amazon Web Services, MS Azure, Oracle OCI or something similar. See Manage Access Gateway deployment.

Firewall

DMZ to internal firewall

Traditional firewall between DMZ and the internal network.

 







Internal network

 

 

Service/Protected application

 The set of protected web resources, in this case Microsoft Services, accessed using the comsumer-app1.internal-example.com URLs.

Supported versions:

  • Microsoft IIS IWA -iIS 7 or later
  • Microsoft OWA IWA - IIS 7 or later

Pre internal Kerberos domain load balance

Load balancer for the Kerberos domain service cluster.

Microsoft domain service cluster with Key Distribution Center

Domain service cluster containing a Key Distribution Center (KDC) .
In this architecture the Domain service/KDC represents multiple instances acting as a cluster.

Other considerations

 

DNS is typically split externally vs internally. All external URLs, such as [appN|comsumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|comsumer-app1].internal-example.com, would be served by internal DNS.

Most architectures forward log events to an external syslog component. Okta strongly recommends that a logging server be configured for all Access Gateway environments.
See Configure log forwarders for more information on configuring log forwarding.


Additionally, Access Gateway itself is typically managed via internal access only. That is, administrators typically access Access Gateway itself from behind the firewall. This is shown in other architectures.

The multiple Kerberos domain Access Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway and multiple Kerberos trusted domains.

This architecture is designed to meet the following requirements:

  • Protect a Kerberos (Windows IIS) based service.
  • Meets basic fault tolerance and high availability needs for Access Gateway
  • Meet basic fault tolerance and high availability for the Kerberos domain and Key Distribution Center (KDC).
  • Supports multiple Kerberos domains, sharing credentials and other information using trust relationships between domains.

Benefits and drawbacks

BenefitsDrawbacks
  • Can be used to replace VPN.
  • Provides fault tolerance and capacity support.
  • Can be expanded with additional workers as required to add capacity.
  • Load balanced.
  • Admin instance is accessed behind the firewall.
  • Single virtual environment.

  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions).

 

Architecture

Components

Location

ComponentDescription

External internet

 

 

 

Web clients

Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.

comsumer-app1.example.com
URLs not shown

URL representing the application an external web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.

Okta org

Your Okta org, providing identity services.

Okta org Universal Directory

Okta universal directory, housed within an Okta org, containing users outside other LDAP/AD implementations. Typically these include other customer accounts, partner accounts and more.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.

 







DMZ
Pre Access Gateway load balancer. Pre load balancer Balances load between clients and the cluster. Positioned between clients and the cluster.
Access GatewayAccess Gateway cluster, located in the DMZ is used to provide access to applications used by external internet clients.
Contains a Kerberos service and a keytab.
See Create keytab for details of creating a keytab.
See Add Kerberos service for details of defining a Access Gateway Kerberos service.
Typically hosted in a virtual environment such as Amazon Web Services, MS Azure, Oracle OCI or something similar. See Manage Access Gateway deployment.

Firewall

DMZ to internal firewall

Traditional firewall between DMZ and the internal network.

 







Internal network

 

 

Service/Protected application

 The set of protected web resources, in this case Microsoft Services, accessed using the comsumer-app1.internal-example.com URLs.

Supported versions:

  • Microsoft IIS IWA -iIS 7 or later
  • Microsoft OWA IWA - IIS 7 or later

Pre internal Kerberos domain load balance

Load balancer for the Kerberos domain service cluster. Load balancer typically only fronts Domain A.

Microsoft domain service cluster A with Key Distribution Center

Domain service cluster containing a Key Distribution Center (KDC).
In this architecture the Domain service/KDC represents multiple instances acting as a cluster.

Microsoft domain service cluster B with Key Distribution Center

Second Kerberos domain, trusted by service cluster A. Unknown credential requests are routed to this domain for handing.

Other considerations

 

DNS is typically split externally vs internally. All external URLs, such as [appN|comsumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|comsumer-app1].internal-example.com, would be served by internal DNS.

Most architectures forward log events to an external syslog component. Okta strongly recommends that a logging server be configured for all Access Gateway environments.
See Configure log forwarders for more information on configuring log forwarding.


Additionally, Access Gateway itself is typically managed via internal access only. That is, administrators typically access Access Gateway itself from behind the firewall. This is shown in other architectures.