7

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:

Architecture diagram

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
2rs2ts
  • 325
  • 3
  • 11
  • Can't help with your specific question but wanted to note: Thanks for your efforts to describe your problem and the environment! Thumbs up! Very well done! +1 – gxx Dec 31 '15 at 19:04
  • 1
    Does kinit as the user who'd log in work? What krb5_child is telling you is that the authentication takes too long and times out after the initial UDP request is sent. If that works, try increasing the krb5_auth_timeout. btw it might be a good idea to prepend KRB5_TRACE=/dev/stderr before kinit user@realm – jhrozek Jan 01 '16 at 05:03

1 Answers1

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.

abbra
  • 1,025
  • 5
  • 8
  • So if I pulled in the Kerberos library I needed from a different yum repo, and switching to Amazon's managed Microsoft AD, it'd be possible... hypothetically? – 2rs2ts Jan 05 '16 at 20:01
  • @2rs2ts you definitely can hack it around to produce something working but you need to know what are you doing, of course. Guiding you there is beyond what serverfault could do. – abbra Jan 05 '16 at 21:50