Applies to: All versions of Centrify DirectControl on *specific platforms
Consider the following scenario:
b) Both servers are running Centrify's OpenSSH. The sshd_config was not changed.
c) On the client side, Centrify Putty is used with Kerberos settings in place.
d) A new TGT is received from the Windows client machine (klist shows it is current)
e) Forward and reverse lookup of both Centrify servers are fine from Windows.
f) In /etc/centrifydc/centrifydc.conf, krb5.forwardable.user.tickets is set to true
g) In /etc/centrifydc/centrifydc.conf, krb5.unique.cache.files is set to false
After the first hop with SSO, the command /usr/share/centrifydc/kerberos/bin/klist -f reports no credentials cache found.
As a result, the second hop fails.
Is there any reason for this?
This is a known issue in our code and not SSHD itself. There is no workaround.
This will be fixed in Centrify DirectControl 5.1.
Excludes Centos 6.3, Debian 6, Fedora 17, Oracle Lunux EL 6u2