Frage Ist es möglich, Kerberos über TLS über sssd zu verwenden?


Hintergrund

Ich versuche mich einzuloggen (über SSH, zu einer laufenden Amazon Linux EC2 Instanz) sssd) als Benutzer, die ich in meinem AWS Directory Services Simple AD erstellt habe. Ich authentifiziere mich mit Kerberos und identifiziere den Benutzer mit LDAP (alles durch sssd.) Ich verbinde mich über eine ELB über mehrere Proxy-Server mit dem Simple AD.

Problem

Wenn ich den ELB für die Verwendung von TLS für den Kerberos-Port konfiguriere, sssd kann keine Verbindung zum Kerberos-Server herstellen und die Anmeldung schlägt fehl. Ohne TLS funktioniert es einwandfrei, und sobald ich mich ohne TLS anmelde, werden die Zugangsdaten zwischengespeichert und die Anmeldung funktioniert weiter, wenn ich TLS wieder einschalte.

RFC 6251 stellt eine Erklärung dar, wie Kerberos V5 über TLS transportiert werden kann, also sollte dies hypothetisch möglich sein, oder? Ich bin mir nicht sicher, ob ich das nicht richtig mache oder ob sssd unterstützt Kerberos nicht über TLS. Googeln bringt nichts Fruchtbares und die Manpages haben nichts scheinbar Relevantes an sich.

Beachten Sie, dass LDAPS perfekt durch die ELB funktioniert, so dass ich zumindest weiß, dass ich nicht komplett abwesend bin.

TL, DR, wie ich meine Frage beantworte

Sag mir entweder:

  • Was mache ich falsch beim Einrichten von Kerberos über TLS, oder?
  • sssd unterstützt Kerberos nicht über TLS

Fehlermeldung

Dies ist von der Ausgabe von sssd. Beachten Sie, dass ich die IP-Adressen redigiert habe.

(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!

Die Architektur

So sieht meine Architektur um die Simple AD aus:

Architecture diagram

Dieses Setup ermöglicht es mir, LDAPS zu verwenden, obwohl AWS Simple AD dies nicht unterstützt. Ich nahm an, dass ich Kerberos über TLS verwenden würde.

Der route53-Datensatz für den ELB ist directory.myteam.mycompany.com, aber die Domäne, die ich für die einfache AD verwendet habe, ist myteam.mycompany.internal.

ELB-Konfiguration

Ich habe Terraform verwendet, um die Architektur zu erstellen. Hier ist nur die Definition der ELB-Ressource, da der Rest irrelevant ist:

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"
  }
}

Beachten Sie, dass das von mir verwendete Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle stammt, für die es angegeben ist *.myteam.mycompany.com.

Konfiguration auf dem Rechner mit 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

Zusätzlich zu diesen beiden Dateien habe ich sichergestellt, dass die Passwortauthentifizierung aktiviert wird sshd_config und aktiviert sssd in den Pam-Modulen mit 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

Softwareversionen

  • 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

6
2017-12-31 18:55


Ursprung


Kann Ihnen bei Ihrer konkreten Frage nicht helfen, wollte aber folgendes beachten: Danke für Ihre Bemühungen, Ihr Problem und die Umwelt zu beschreiben! Daumen hoch! Sehr gut gemacht! +1 - gf_
Funktioniert kinit als Benutzer, der sich anmeldet? Was krb5_child Ihnen sagt, ist, dass die Authentifizierung zu lange dauert und nach dem Senden der ursprünglichen UDP-Anfrage abläuft. Wenn das funktioniert, versuchen Sie krb5_auth_timeout zu erhöhen. Übrigens könnte es eine gute Idee sein, KRB5_TRACE = / dev / stderr vor kinit user @ realm voranzustellen - jhrozek


Antworten:


Was Sie mit RFC 6251 erreichen möchten, ist mit MIT Kerberos nicht möglich, da dieses Schema nicht implementiert werden soll. Seit MIT Kerberos 1.13 gibt es jedoch Unterstützung für das Proxys von Kerberos über HTTPS, indem dasselbe Protokoll unterstützt wird, das Microsoft Active Directory unterstützt, MS-KKDCP. Die Client-Seite für MS-KKDCP wurde ebenfalls auf RHEL 7 zurückportiert (https://rhn.redhat.com/errata/RHSA-2015-0439.html).

Die Funktionalität hängt von der Fähigkeit ab, Kerberos-Datenverkehr von den Clients zu übernehmen. SSSD unter RHEL 7 / CentOS 7 sollte dies ermöglichen. Amazon Linux hat diese Version der Kerberos-Bibliothek nicht, denke ich, also würde Ihr Ansatz nicht funktionieren.

Darüber hinaus ist Amazon Simple AD Samba AD mit Heimdal Kerberos gebaut. Es unterstützt auch MS-KKDCP nicht und kann daher nicht als MS-KKDCP-Proxy verwendet werden.


2
2018-01-03 22:31



Also, wenn ich die Kerberos-Bibliothek, die ich von einem anderen yum-Repo benötigte, und die Umstellung auf die von Amazon verwaltete Microsoft AD einhole, wäre es möglich ... hypothetisch? - 2rs2ts
@ 2rs2ts du kannst es auf jeden Fall hacken, um etwas zu produzieren, aber du musst natürlich wissen, was du machst. Sie dort zu führen, ist jenseits dessen, was Serverfault tun könnte. - abbra