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:
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.