1. Introduction
Before we understand the concept of choosing the correct REALM for your environment, it is important to understand what it is and why do we need it?
REALM (mentioned in upper case usually) is the domain over which the KDC (Key Distribution Center) has the ability or authority to authenticate the users. It is used to authenticate the users using Workspace ONE managed iOS devices and perform a Single Sign ON (SSO). This blog will help you understand how to choose and initialize built-in KDC in Workspace ONE Access.
The REALM name and Workspace external FQDN are two different services and should not be confused as one. However, you can always configure REALM the same as the Fully Qualified Domain Name (FQDN) of your appliance. If you are using a load balancer for a 3 node cluster deployment, you have to choose the FQDN of the load balancer as the REALM. Since your organization has to manage both the domains, you don’t need separate DNS entries for the REALM and the external FQDN of the appliance if you keep the names identical.
A. Understanding it with an example
If external FQDN and the load balancer address of my Access Cluster is “lb.navjyotchaney.com”, my REALM can also be “LB.NAVJYOTCHANEY.COM”. In this case, only one external DNS entry is required for the load balancer FQDN or VIP and that will cover the REALM discovery by the KDC client.
If external FQDN is “lb.navjyotchaney.com” and my REALM is “NAVJYOTCHANEY.COM”, I would need two different public DNS records. One for the external connections to reach my appliance load balancer VIP and the other for the Kerberos clients to find KDC after built in Kerberos is initialized .
The REALM name is used by a Kerberos client to generate DNS names. For LB.NAVJYOTCHANEY.COM, the Kerberos name to find KDC (TCP and UDP) is “_kerberos._tcp.LB.NAVJYOTCHANEY.COM” and “_kerberos._udp.LB.NAVJYOTCHANEY.COM”
For more details, visit the VMware Documentation page
2. Pre-Requirements
The Pre-Requirements for creating public DNS entries according to VMware Docs
3. Initializing the Built in KDC
A. First Node
Now, once the Access Node is up and running and you’ve decided the REALM, the next thing is to initialize it within the Node. Remember, if you have a 3 node cluster and the KDC is initialized after the cluster setup, you have to do a few more steps to initialize it on the other nodes. I would recommend taking snapshots of the server before doing this step.
- Log in to the 1st Access Node as root user
- Initialize the KDC using the command: /etc/init.d/vmware-kdc init – – realm LB.NAVJYOTCHANEY.COM – – subdomain lb.navjyotchaney.com
- Replace “LB.NAVJYOTCHANEY.COM” with your REALM and “lb.navjyotchaney.com” with subdomains (in lower case)
- Restart the appliance: service horizon-workspace restart
- Restart the Kerberos service: service vmware-kdc restart
- Clone the node
B. Initializing KDC after a cluster setup
- First, copy the KDC data from the first node using the command: service vmware-kdc dump <file>
- Change file permission: chown horizon <file>
- Move the data to the other node: service vmware-kdc load <file>
- Restart the appliance: service horizon-workspace restart
- Restart the Kerberos service: service vmware-kdc restart
I still prefer the first option. It’s easy and should be the preferred method. If you run into any issues with the initialization and notice iOS SSO failing, try to re-initialize the KDC with the –force parameter
/etc/init.d/vmware-kdc init – – realm LB.NAVJYOTCHANEY.COM – – subdomain lb.navjyotchaney.com – – force
4. Conclusion
For iOS SSO to work, you have to initialize the KDC and configure it correctly. Once this step is done, you can then initialize the Authentication adapter within Workspace ONE Access and enable Mobile SSO (iOS).
To keep yourself updated with the latest information, please refer VMware Documents.
Navjyot Chaney's Blog 