Background
I am trying to log in (via SSH, to an Amazon Linux EC2 instance running sssd
) as users that I've created in my AWS Directory Services Simple AD. I am authenticating with Kerberos and identifying the user with LDAP (all through sssd
.) I connect to the Simple AD through an ELB over several proxy servers.
Problem
When I configure the ELB to use TLS for the Kerberos port, sssd
cannot connect to the Kerberos server and the login fails. Without TLS it works just fine, and once I log in without TLS the credentials get cached and login continues to work when I turn TLS back on.
RFC 6251 presents an explanation of how Kerberos V5 can be transported over TLS, so hypothetically, this should be possible, right? I am unsure whether I am not doing this correctly or if sssd
doesn't support Kerberos over TLS. Googling does not produce anything fruitful and the man pages don't have anything seemingly relevant in them.
Note that I have LDAPS working perfectly through the ELB, so I know at the very least that I'm not completely off-track.
TL;DR how to answer my question
Tell me either:
- What I'm doing wrong when setting up Kerberos over TLS, or
sssd
does not support Kerberos over TLS
Error message
This is from the output of sssd
. Note that I redacted the IP addresses.
(Thu Dec 31 18:36:43 2015) [[sssd[krb5_child[2780]]]] [sss_child_krb5_trace_cb] (0x4000): [2780] 1451587003.307171: Sending request (218 bytes) to MYTEAM.MYCOMPANY.INTERNAL
(Thu Dec 31 18:36:43 2015) [[sssd[krb5_child[2780]]]] [sss_child_krb5_trace_cb] (0x4000): [2780] 1451587003.307390: Initiating TCP connection to stream 1.2.3.4:88
(Thu Dec 31 18:36:43 2015) [[sssd[krb5_child[2780]]]] [sss_child_krb5_trace_cb] (0x4000): [2780] 1451587003.309053: Sending TCP request to stream 1.2.3.4:88
(Thu Dec 31 18:36:43 2015) [[sssd[krb5_child[2780]]]] [sss_child_krb5_trace_cb] (0x4000): [2780] 1451587003.310487: TCP error receiving from stream 1.2.3.4:88: 104/Connection reset by peer
(Thu Dec 31 18:36:43 2015) [[sssd[krb5_child[2780]]]] [sss_child_krb5_trace_cb] (0x4000): [2780] 1451587003.310609: Terminating TCP connection to stream 1.2.3.4:88
(Thu Dec 31 18:36:43 2015) [[sssd[krb5_child[2780]]]] [sss_child_krb5_trace_cb] (0x4000): [2780] 1451587003.310729: Sending initial UDP request to dgram 1.2.3.4:88
# Lots of other output...
(Thu Dec 31 18:36:58 2015) [sssd[be[myteam]]] [krb5_child_timeout] (0x0040): Timeout for child [2780] reached. In case KDC is distant or network is slow you may consider increasing value of krb5_auth_timeout.
(Thu Dec 31 18:36:58 2015) [sssd[be[myteam]]] [krb5_auth_done] (0x0020): child timed out!
Architecture
Here's what my architecture around the Simple AD looks like:
This setup enables me to use LDAPS even though AWS' Simple AD does not support it. I assumed it would also let me use Kerberos over TLS.
The route53 record for the ELB is directory.myteam.mycompany.com
, but the domain I used for the Simple AD is myteam.mycompany.internal
.
ELB configuration
I used terraform to create the architecture. Here's just the definition of the ELB resource, since the rest is irrelevant:
resource "aws_elb" "proxy" {
name = "directory-proxy-pub"
subnets = ["${split(",", module.vpc.public_subnet_ids_dsv)}}"]
cross_zone_load_balancing = true
security_groups = [ "${aws_security_group.elb-proxy.id}" ]
listener {
lb_port = 636
lb_protocol = "ssl"
instance_port = 389
instance_protocol = "tcp"
ssl_certificate_id = "${var.my_cert}"
}
listener {
lb_port = 88
lb_protocol = "ssl"
instance_port = 88
instance_protocol = "tcp"
ssl_certificate_id = "${var.my_cert}"
}
health_check {
interval = 15
timeout = 5
unhealthy_threshold = 2
healthy_threshold = 3
target = "TCP:389"
}
tags {
Name = "directory-proxy"
}
}
Note that the certificate I'm using is from a trusted CA and it's specified for *.myteam.mycompany.com
.
Configuration on the machine running sssd
/etc/sssd/sssd.conf
:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = myteam
[nss]
default_shell = /bin/bash
fallback_homedir = /home/%u
ldap_user_home_directory = unixHomeDirectory
[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
[domain/myteam]
enumerate = true
cache_credentials = TRUE
id_provider = ldap
ldap_uri = ldaps://directory.myteam.mycompany.com
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_default_bind_dn = CN=test-user,CN=users,DC=myteam,DC=mycompany,DC=internal
ldap_default_authtok = REDACTED_PASSWORD
ldap_id_use_start_tls = true
ldap_schema = AD
ldap_force_upper_case_realm = true
ldap_id_mapping = true
ldap_search_base = CN=users,DC=myteam,DC=mycompany,DC=internal
ldap_user_uuid = none
ldap_group_uuid = none
chpass_provider = krb5
auth_provider = krb5
krb5_server = directory.myteam.mycompany.com
krb5_realm = MYTEAM.MYCOMPANY.INTERNAL
krb5_changepw_principal = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15
krb5_canonicalize = True
/etc/sysconfig/authconfig
:
IPADOMAINJOINED=no
USEMKHOMEDIR=yes
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=yes
USESHADOW=yes
USEWINBIND=no
PASSWDALGORITHM=sha512
FORCELEGACY=yes
USEFPRINTD=no
FORCESMARTCARD=no
USEDB=no
USELDAPAUTH=no
USEPASSWDQC=no
IPAV2NONTP=no
WINBINDKRB5=no
USELOCAUTHORIZE=yes
USEECRYPTFS=no
USECRACKLIB=yes
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELDAP=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=yes
USEPWQUALITY=yes
USEHESIOD=no
In addition to these two files, I made sure to enable password authentication in sshd_config
and enabled sssd in the pam modules with sudo authconfig --updateall --enablesssd --enablesssdauth
.
/etc/pam.d/system-auth
:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet_success
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
Software versions
uname -a
:Linux ip-172-31-31-2 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
sssd
1.12.2
What you want to achieve with RFC 6251 is not possible with MIT Kerberos as there are no plans to implement this scheme. However, since MIT Kerberos 1.13 there is support for proxying Kerberos over HTTPS by supporting the same protocol that Microsoft's Active Directory does support, MS-KKDCP. The client side for MS-KKDCP was backported to RHEL 7 as well (https://rhn.redhat.com/errata/RHSA-2015-0439.html).
The functionality depends on ability to proxy Kerberos traffic by the clients. SSSD running on RHEL 7/CentOS 7 should be able to do so. Amazon Linux does not have this version of Kerberos library, I think, so your approach would not work.
In addition, Amazon's Simple AD is Samba AD built with Heimdal kerberos. It is also not supporting MS-KKDCP, so cannot be used as a MS-KKDCP proxy.