How to configure UNAB to use the native Kerberos Client to enable SSO with other applications

Document ID : KB000010382
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

UNAB may be configured to use the native kerberos client for performing authentication of AD users to log into an endpoint. This is configured via uxauth.ini, and the authentication mechanism implies following the standard kerberos mechanism and generating a Kerberos ticket.

Unless otherwise specified UNAB Kerberos authentication will be limited to the scope of the UNAB application itself, so other kerberos enabled applications will not be able use it.

This document explains these concepts and indicates how Kerberos tickets may be shared with other applications using Kerberos authentication

Instructions:

At user logon, UNAB always creates a user ticket  in a file with the standard naming convention for a Kerberos credentials cache, namely /tmp/krb5cc_%uid.  

Here is an example taken after an actual logon of user aduser1 to a recent version of UNAB:

/home/aduser1> id


uid=20301(aduser1) gid=2001(unix_users) groups=2001(unix_users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
/home/aduser1> ls -l /tmp/*cc*


-rw-------. 1 aduser1 unix_users 1257 Jul 21 11:06 /tmp/krb5cc_20301

Even though parameters in the Kerberos section in uxauth.ini are consumed and acted upon by Kerberos itself,  the default_ccache_name token there has no effect  (UNAB overrides it and follows the convention described above)

The pam_delete_user_ccache token in uxauth.ini set to "yes",  means that UNAB will delete the ticket it creates as soon as the user completes logon, i.e.,  you should not normally even see them. The default value for the pam_delete_user_ccache  token was recently changed to "yes", since most customers are not interested in a ticket and preferred it deleted.  Bear in mind however that there are many things that lead s to creation of a Kerberos ticket: kinit, uxconsole -krb -init, kerberized logon, etc.

If the goal is to integrate UNAB with other Kerberos-based software in the endpoint, it is necessary to register it with the  -sso option in the command line. Doing so one will get the so-called "standard" configuration, where the Kerberos keytab and configuration are in standard locations so that they can be shared. Kerberos configuration and keytabs will be put in their standard location for it (e.g., /etc/krb5.conf), so that they can be used by both: UNAB and whatever Kerberos-based applications is used.  Before doing this, it is recommended to make sure there is no garbage in the current Kerberos configuration (typically that is /etc/krb5.conf)

Otherwise, if the UNAB endpoint is not registered with -sso, it will work in UNAB's internal configuration, which is in /etc/uxauth.ini, so native Kerberos does not know about it

Be also aware that when working with Kerberos, errors may come directly from the Kerberos API, so troubleshooting may need to be done at the AD level. For instance errors in the password registration area are 100 percent dependent on the Kerbersos service in AD.

Additional Information:

also see

https://support.ca.com/us/knowledge-base-articles.TEC1877714.html

https://docops.ca.com/ca-privileged-identity-manager/14-0/en/implementing/install-unab-endpoint/installing-and-customizing-a-unab-host/kerberos-and-sso-considerations