Problem:

After upgrading Centrify DirectControl from 5.1.1 or 5.0.x  to 5.1.2, if a .k5login exists in the AD user's home directory, SSO (Kerberos) is not possible with Centrify's OpenSSH. Is there any reason for this?

Cause:

This is by design to prevent a security hole. From windows the ticket is from samaccountname (which is not necessarily all lower case) if this does not match the ticket presented (case sensitivity), it is rejected. This is normal behavior for MIT Kerberos.

When we create user home directory, we create .k5login as part of the process. Now, if user had .k5login there, and it is not correct, the upgrade will expose the issue.

Resolution:

Delete or rename existing .k5login file. The contents should have the upn (user principal name) of the AD user account. This should fix SSO/Kerberos for that account.

Addendum:
10/9/2014

Centrify DirectControl does added one more check:

A) We try to locate the Unix profile of the AD user (zone enabled) of the presented credential (UPN).
If the found profile shows the same unix user name matching the login account, then it is allowed. 
This is by and larger for convenience of customer that has mixed case samaccountname. 

B) The precedence is that if .k5login is present, it wins (this is the part that we fixed). Centrify Direct Control hook is not invoked at all. 
Otherwise, CDC hook gets its say after all other Kerberos checks have failed. 

Note:
CDC used to take precedence over .k5login. This causes issues and so, it is fixed so that now .k5login takes precedence.