NSX-T LBaaS with Workspace ONE Access

Opening

A few homelab versions back, I exclusively ran NSX-v LBaaS for all things “edge”. I’ve since had the opportunity to shift over to F5 BIG-IP, and now Avi Networks (welcome to the VMware family!), but still asked on numerous occasions to provide guidance on how to load balance Workspace ONE Access with NSX. Let me just say, the world is moving to NSX-T; it’s time you do the same. So without further ado, let’s dig into the recipe for how to load balance Workspace ONE Access with NSX-T.

Pre-Requisites

Only a handful of things to account for here:

  1. Functional NSX-T 2.4 Environment – For the below, I am using a highly available NSX-T 2.4.0 Manager cluster, with dual ‘large’ sized virtual Edge Nodes
  2. Functional Workspace ONE Access Node – I’m using an on-premises 1903 cluster below. Keep in mind, to implement a functional cluster, you will need to change the FQDN which won’t be possible without the below implemented. For now, start with one node, then follow the instructions for establishing a 3 node cluster. Here’s a great document on pre-requisites and deployment instructions for Workspace ONE Access
  3. If you choose to implement Kerberos AuthN for domain joined workstations, you will need a pair of functioning vIDM Connectors
  4. As documented here and here, you will need a VIP for services, forward and reverse DNS and SRV records to support iOS Mobile SSO. This is out of scope for below, but required to load balance these services successfully
  5. A public SSL certificate which is trusted by all clients, and uploaded to NSX Manager. There are many caveats to SSL design for this product, so let’s assume SSL re-encryption for all things layer 7, and passthrough for all things layer 4. Let’s also assume that the node namespace is disjointed from our public namespace, i.e. dmz.virtualprivateer.com v. virtualprivateer.com.

Configuration

There are five Workspace ONE Access services in scope for load balancing:

  1. Horizon Service (HTTPS 443) – This is the primary service powering the catalog and all things ‘Access’
  2. CertProxy (TCP 5262) – Android SSO using TLS mutual authn
  3. KDC (TCP/UDP 88) – iOS SSO using Kerberos pk-init authn
  4. CertAuth Service (TCP 7443) – Pure TLS mutual authn
  5. Integrated Windows Auth (HTTPS 443) – Domain joined Kerberos authn

In the next few sections, I’ll identify the key configuration elements that must be defined. For other data points, either accept the default value or use the provided screenshot for examples.

Profiles

It’s a bit counter-intuitive from the UI, but we need to start with creating our profiles for reference in pools, monitors and virtual servers:

Application
  • Name: prof-app-tcp-30min
  • Type: Fast TCP
  • Timeout: 1800 (seconds)
  • Name: prof-app-udp-30min
  • Type: Fast UDP
  • Timeout: 1800 (seconds)
  • Name: prof-app-http-60min
  • Type: HTTP
  • Timeout: 3600 (seconds)
  • X-Forwarded-For: Insert
Persistence
  • Name: prof-persist-sourceip
  • Type: Source IP
  • Timeout: 3600
  • Name: prof-persist-cookie-jsessionid
  • Type: Cookie
  • Cookie Mode: Rewrite
  • Cookie Name: JSESSIONID
SSL
  • Name: prof-ssl-server-balanced
  • Type: Server SSL Profile
  • SSL Suite: Balanced (recommended)
  • Name: prof-ssl-client-highsecurity
  • Type: Client SSL Profile
  • SSL Suite: High Security or Custom
  • Supported SSL Ciphers/Protocols: Various/TLS_V1_2

Monitors

With profiles in order, we can move on to creating health checks in the Monitors (Active) tab. These are well defined for Workspace ONE Access here. Keep in mind that if your T1 logical router housing the load balancer is uplinked to a T0, the source IP of the health check is the inter-router uplink address.

Horizon
  • Name: mon-access-https
  • Protocol: HTTPS
  • Monitoring Port: 443
  • Monitoring Internal/Timeout: 5/10 seconds
  • HTTP Request: GET /SAAS/API/1.0/REST/system/health/heartbeat
  • HTTP Response: Code 200
  • SSL Configuration: Enabled, use ‘prof-ssl-server-balanced’
CertProxy
  • Name: mon-access-certproxy
  • Protocol: HTTPS
  • Monitoring Port: 5262
  • Monitoring Interval/Timeout: 10/10
  • HTTP Request: GET /system/health
  • HTTP Response: Code 200
  • SSL Configuration: Enabled, use ‘prof-ssl-server-balanced’
KDC
  • Name: mon-access-kdc
  • Protocol: TCP
  • Monitoring Port: 88
  • Monitoring Interval/Timeout: 10/10
CertAuth
  • Name: mon-access-cas
  • Protocol: HTTPS
  • Monitoring Port: 7443
  • Monitoring Interval/Timeout: 10/10
  • HTTP Request: GET /SAAS/API/1.0/REST/system/health/heartbeat
  • HTTP Response: Code 200
  • SSL Configuration: Enabled, use ‘prof-ssl-server-balanced’
Connector
  • Name: mon-access-iwa
  • Protocol: HTTPS
  • Monitoring Port: 443
  • Monitoring Interval/Timeout: 5/10
  • HTTP Request: GET /hc/API/1.0/REST/system/health/allOk
  • HTTP Response: Code 200
  • SSL Configuration: Enabled, use ‘prof-ssl-server-balanced’

Server Pools

One of the benefits of leveraging NSX LBaaS is that the ability to reuse configuration from other areas of the product, such as micro-segmentation. You’ll notice that pool members are dynamically selected based on security group membership, which is a nice marriage of the security policy with the load balancing availability.

Horizon
  • Name: pool-access-horizon
  • Algorithm: Least Connection
  • Active Monitor: ‘mon-access-https’
  • SNAT Translation Mode: Automap, depending on your environment
  • Members: Static or Dynamic via security group
CertProxy
  • Name: pool-access-certproxy
  • Algorithm: Least Connection
  • Active Monitor: ‘mon-access-certproxy’
  • SNAT Translation Mode: Automap, depending on your environment
  • Members: Static or Dynamic via security group
KDC
  • Name: pool-access-kdc
  • Algorithm: Least Connection
  • Active Monitor: ‘mon-access-kdc’
  • SNAT Translation Mode: Automap, depending on your environment
  • Members: Static or Dynamic via security group
CertAuth
  • Name: pool-access-cas
  • Algorithm: Least Connection
  • Active Monitor: ‘mon-access-cas’
  • SNAT Translation Mode: Automap, depending on your environment
  • Members: Static or Dynamic via security group
Connector
  • Name: pool-access-iwa
  • Algorithm: Least Connection
  • Active Monitor: ‘mon-access-iwa’
  • SNAT Translation Mode: Automap, depending on your environment
  • Members: Static or Dynamic via security group

Virtual Servers

Time to bring it all together. Before you configure the virtual servers, you’ll want to make sure you’ve uploaded all of the appropriate certificates, allocated a VIP to WS1 Access, and configured forward/reverse DNS for said VIP. Take note: there are some specifics called out below around load balancing IWA for the connectors.

Horizon
  • Name: vs-access-horizon
  • IP Address: {Your Access VIP}
  • Port: 443
  • Type: L7 HTTP
  • Server Pool: ‘pool-access-horizon’
  • Application Profile: ‘prof-app-http-60min’
  • Persistence: Cookie
  • Cookie: ‘prof-persist-cookie-jsessionid’
  • SSL Configuration:
    • Client SSL: Enable
    • Default Certificate: {Your Public Certificate}
    • Client SSL Profile: ‘prof-ssl-client-highsecurity’
    • Server SSL: Enable
    • Server SSL Profile: ‘prof-ssl-server-balanced’
  • Request Rewrite Phase: Add New Rule
    • Match Conditions: Blank/Delete all conditions
    • Match Strategy: ALL
    • Action: HTTP Request Header Rewrite
    • Header Name: RemotePort
    • Header Value: $_remote_port
CertProxy
  • Name: vs-access-certproxy
  • IP Address: {Your Access VIP}
  • Port: 5262
  • Type: L4 TCP
  • Server Pool: ‘pool-access-certproxy’
  • Application Profile: ‘prof-app-tcp-30min’
  • Persistence: Source IP
  • Source IP: ‘prof-persist-sourceip’
KDC
  • Name: vs-access-kdc
  • IP Address: {Your Access VIP}
  • Port: 88
  • Type: L4 TCP
  • Server Pool: ‘pool-access-kdc’
  • Application Profile: ‘prof-app-tcp-30min’
  • Persistence: Source IP
  • Source IP: ‘prof-persist-sourceip’
  • Name: vs-access-kdc
  • IP Address: {Your Access VIP}
  • Port: 88
  • Type: L4 UDP
  • Server Pool: ‘pool-access-kdc’
  • Application Profile: ‘prof-app-udp-30min’
  • Persistence: Source IP
  • Source IP: ‘prof-persist-sourceip’
CertAuth
  • Name: vs-access-cas
  • IP Address: {Your Access VIP}
  • Port: 7443
  • Type: L4 TCP
  • Server Pool: ‘pool-access-cas’
  • Application Profile: ‘prof-app-tcp-30min’
  • Persistence: Source IP
  • Source IP: ‘prof-persist-sourceip’
Connector
  • Name: vs-access-iwa
  • IP Address: {Your Connector VIP}
  • Port: 443
  • Type: L7 HTTP
  • Server Pool: ‘pool-access-iwa’
  • Application Profile: ‘prof-app-http-60min’
  • Persistence: None
  • SSL Configuration:
    • Client SSL: Enable
    • Default Certificate: {Your Public or Internal Certificate}
    • Client SSL Profile: ‘prof-ssl-client-highsecurity’
    • Server SSL: Enable
    • Server SSL Profile: ‘prof-ssl-server-balanced’

Load Balancers

Now we create a load balancer to attach the virtual servers to. after creating the object, you will need to revisit each virtual server that you want to attach and select the LB in the ‘Load Balancer’ field. This action will activate the VIP and start the health checks.

Connector IWA Configuration

Enabling Kerberos authentication for domain joined workstations in Workspace ONE Access is performed in three distinct phases. In order to introduce high availability for this auth adapter via the load balancer, we need to configure each phase to link the redirects in sequence:

Phase 1: AuthN Request to Workspace ONE Access Service

Workspace ONE Access will make the determination that a client should attempt authentication with Integrated Windows Authentication using a series of definable conditions. Upon this determination, WS1 Access will redirect the client to a provided FQDN; in our case, the VIP FQDN of ‘vs-access-iwa’. Take note: this VIP is not the same as the WS1 Access VIP.

Phase 2: Redirect to Connector VIP FQDN

Open the Workspace ONE Access admin console and navigate to ‘Identity & Access Management -> Identity Providers -> WorkspaceIDP__**’, where ** equals the IdP where the pair of connectors are configured:

In the ‘IdP Hostname’ field, enter the VIP FQDN of the ‘vs-access-iwa’ virtual server and press ‘Save’:

Phase 3: Redirect to Connector Pool Member FQDN

Remember that ‘vs-access-iwa’ had persistence set to ‘None’? This is because in most deployments, the connector itself is what performs Kerberos authentication with the client through ‘Negotiate’, which requires an auxiliary redirect. Kerberos doesn’t play nice with man-in-the-middle, so we need to redirect the client to the connector individually. This is why load balancing persistence isn’t necessary.

Back in the Workspace ONE Access admin console, navigate to ‘Identity & Access Management -> Setup -> Connectors’:

Select one the ‘Worker’ links, then navigate to ‘Auth Adapter -> KerberosIdPAdapter’:

I am assuming you’ve already completed the pre-reqs and activated this adapter, so enter the connector FQDN in the ‘Redirect Host Name’ field. Note: This is not the VIP FQDN, but rather than FQDN of the node itself in order for Kerberos AuthN to be performed:

The client will subsequently redirect to this FQDN over HTTPS, so you’ll need to make sure there is a trusted certificate uploaded to the Connector service via the Configurator. Best practice is to use an internal web certificate issued from a CA that is trusted by your domain, since the request would never be performed from an internet sourced client.

Outcomes

At this point, you’ve got a rock solid LBaaS solution in place for all things Workspace ONE Access. Next steps would be to extend these services to an HA pair of Edge Nodes if you haven’t already done so.

The recipe above will be maintained in ongoing fashion with any errors or product changes as they surface. Happy load balancing!

Tags: , , , , , ,