All versions of Centrify DirectControl running stock Open-SSH/Centrify OpenSSH.
Problem:
A user has a local Unix account name that matches their AD account name. This user is not zone-enabled but can ssh and SSO into a machine with their AD account.
Even if the local account is locked in /etc/passwd, login works.
What steps should be taken to prevent it?
Cause:
With SSO and GSSAPI authentication enabled, stock sshd is using the Kerberos ticket and principal to send over from ssh/putty and validate the user because the credentials are good. Centrify's sshd and Kerberos library have the same behavior as the open source implementations. Using Centrify's sshd will not help.
Resolution:
Option #1
On the server, add/change the line in /etc/centrifydc/centrifydc.conf
adclient.krb5.autoedit: false
This will stop adclient from deleting and changing /etc/krb5.conf when join or leave.
Then, edit /etc/krb5.conf, in the section [realm], add a subsection auth_to_local_names, something like this:
[realms]
DOMAIN.COM = {
kdc = domain.domain.com:88
master_kdc = domain.domain.com:88
kpasswd = domain.domain.com:464
kpasswd_server = domain.domain.com:464
kdc = domain.domain.com:88
master_kdc = domain.domain.com:88
kpasswd = domain.domain.com:464
kpasswd_server = domain.domain.com:464
auto_to_local_names = {
local_user = NOUSER
}
}
where local_user is the local_user that you want to stop SSO from the same AD user.
Centrify will fix our Kerberos library to honor .k5login first, but that is planned for the next maintenance release as any fix to low level MIT Kerberos library has its own implications.
Option #2
1. Download the following two files:
- krb5_conf.pl
- add_auth.sh
Place these files in the same directory.
2. backup /etc/krb5.conf
3. ./add_auth.sh > /tmp/krb5.conf
4. cp /tmp/krb5.conf /etc/krb5.conf
Update /etc/centrifydc/centrifydc.conf, add or edit the line to
adclient.krb5.autoedit: false