Background:

Its very common across many organizations that the DNS namespace across the Windows and UNIX/Linux environment is different than the AD (Active Directory) domain namespace.  For example, in my environment the DNS namespace is centrify.com but the AD domain is centrify.vms.

The Problem:

Note: I will use centrify.com as the DNS domain name and centrify.vms as the AD domain name throughout the article to explain the problem and the solution. 

Having a disjointed namespace creates problems for Kerberos Single-Singn-On (SSO).  Let me explain.  If the UNIX fqdn (fully qualified domain name) of a system is unix.centrify.com, when its joined to AD, it will have by default an AD name of unix.centrify.vms since the AD domain is centrify.vms.  When Kerberos applications on either Windows or UNIX/Linux try to obtain Kerberos service tickets for unix.centrify.com, AD will not know who that is since the machine in AD was joined with the name of unix.centrify.vms.

Further, how do Kerberos applications know that when requesting Kerberos tickets for systems with .centrify.com DNS names, they should query the AD domain centrify.vms?  By default Kerberos applications take the DNS name domain name as the AD domain to query.  Since centrify.com is not a valid AD domain, Kerberos ticket requests will fail.  

Luckily for organizations, Centrify has thought about this problem and provides several capabilities that make handling a disjointed DNS namespace a breeze.

The Solution:

The proper way to handle a disjointed DNS namespace consists of the following steps:

1. Join the UNIX/Linux system to AD with the fqdn of system as an alias.  This will assure that the UNIX fqdn is registered as part of the join process with the AD computer account
2. Configure the Hostname to realm mapping.  This will assure that the when Keberized applications on both Windows and UNIX/Linux system request Kerberos tickets systems with the DNS domain (i.e. centrify.com), they know which AD domain to contact.

Step 1 - Join the UNIX/Linux system to AD with the fqdn of the system as an alias

This is very straight forward to do.  I'll assume you're already familiar with the basics of the adjoin command.  If you're not, run "man adjoin".  To add an alias as part of the join process, the -a option can be used.  For example:

#/usr/sbin/adjoin -u dwirth -c "OU=UNIX-Servers,OU=UNIX" -z Global -a engcen7.centrify.com centrify.vms

In this example, the server's fqdn is engcen7.centrify.com and the AD domain or as known in the Kerberos world, a realm, is centrify.vms.  Using the command "adinfo -C" we can see all of the names which in the Kerberos world are called servicePrincipalNames (SPNs) that have been registered for the computer account as part of the join process.    

$ adinfo -C
Computer Account Diagnostics
  Joined as: engcen7.centrify.vms
  Trusted for Delegation: false
  Use DES Key Only: false
  Run adinfo as root to examine local key info
  Key Version: 7   (local key version unavailable)
  Service Principal Names: ftp/engcen7.centrify.com
                           nfs/engcen7.centrify.com
                           http/engcen7.centrify.com
                           cifs/engcen7.centrify.com
                           host/engcen7.centrify.com
                           nfs/engcen7.centrify.vms
                           http/engcen7.centrify.vms
                           host/engcen7.centrify.vms
                           ftp/engcen7.centrify.vms
                           cifs/engcen7.centrify.vms
                           nfs/engcen7
                           http/engcen7
                           host/engcen7
                           ftp/engcen7
                           cifs/engcen7

As can be noted, SPNs have been registered for the UNIX fqdn engcen7.centrify.com based on the alias provided as part of the join process.  

This is a great step in the right direction.  When Kerberized applications request a sevice ticket from AD for the UNIX fqdn (i.e. /engcen7.centrify.com), AD will be able to find the servicePrincipalName and generate the service ticket properly.

However, since by default, Kerberized applications will take the domain from the UNIX fqdn and assume that is the AD domain (realm) that should be queried to obtain Kerberos service tickets, Kerberos SSO will fail.  Let's solve this problem in step 2.

Step 2 - Configure the Hostname to realm mapping

To solve the problem where by default Kerberized applications take the AD domain name from the fqdn to query AD for service tickets, a domain name to realm or hostname to realm mapping needs to be configured.  This tells Kerberized applications, "hey, when looking for service tickets for , go to this to obtain Kerberos tickets".  

In my example, I need to create a hostname to realm mapping that tells my Windows and UNIX/Linux clients that when trying to obtain service tickets for systems or applications with a domain name of centrify.com to please do so by querying the AD domain centrify.vms.

To do this, we can use AD Group Policy.  GPO is a great way to do this as we simply need to do this once.  Microsoft provides a group policy under Computer Configuration --> Administrative Templates --> System --> Kerberos named "Define host name-to-Kerberos realm mappings".  The policy can of course apply to Windows system but will also apply to UNIX/Linux systems with Centrify since Centrify fully supports Microsoft's AD Group Policy.  In my environment I have this GPO applying to both Windows and UNIX/Linux systems.  Here's the GPO.

To configure the GPO, double click and set to enabled, then select the "Show" button to display the show contents window.

In the "Show Contents" window configure the host name to realm mapping.  The Value name column is for the AD domain or realm (i.e. centrify.vms).  The Value column is for the value or the DNS domain (i.e. centrify.com) as shown below below.

Click OK on the show contents Windows and OK on the Define host name-to-Kerberos realm mappings windows to save the changes.  

To confirm the changes have applied run "adgpupdate" on a UNIX/Linux system and "gpupdate" on a Windows system.  The changes would also take effect at the next GPO refresh which occurs by default every 90 to 120 minutes and a newly joined system would also pick up the GPO and apply it right away.  

In my environment, I can confirm the GPO is applying correctly by looking at the /etc/krb5.conf file of one my  UNIX/Linux systems and the registry domain_realm of one of my Windows systems.

Here's a snippet from the /etc/krb5.conf file on my engcen7 the GPO is being applied to.  

Here's the registry entry that is set on Windows systems when the GPO is applied:

After performing these two steps, Kerberos SSO will now work from both Windows to UNIX and UNIX to UNIX systems since 1) aliases that contain the DNS domain name have been registered for UNIX/Linux systems as part of the join process and 2) a hostname to realm mapping has been configured which tells Kerberized applications which AD domain to query when requesting service tickets for systems with the DNS domain name.  

Centrify has done great work in this area to make sure Kerberos SSO works in very complex environments, including those with a disjointed domain name namespace.

Happy Kerberos SSOing!

Felderi Santiago

Technical Director - NA East, LATAM