Multiple Kerberos domain application reference architecture

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

Benefits Drawbacks
  • 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

Component Description
External internet Web clients

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

consumer-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 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

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.

Related topics

Common Access Gateway flows

About Access Gateway DNS use

About Access Gateway high availability

About Access Gateway prerequisites