Kerberos

是否可以通過 sssd 在 TLS 上使用 Kerberos?

  • January 3, 2016

背景

我正在嘗試以sssd我在 AWS Directory Services Simple AD 中創建的使用者身份登錄(通過 SSH,登錄到正在執行的 Amazon Linux EC2 實例)。我正在使用 Kerberos 進行身份驗證並使用 LDAP 辨識使用者(全部通過sssd.)。我通過多個代理伺服器上的 ELB 連接到 Simple AD。

問題

當我將 ELB 配置為對 Kerberos 埠使用 TLS 時,sssd無法連接到 Kerberos 伺服器並且登錄失敗。如果沒有 TLS,它就可以正常工作,一旦我在沒有 TLS 的情況下登錄,憑據就會被記憶體,當我重新打開 TLS 時,登錄會繼續工作。

RFC 6251解釋瞭如何通過 TLS 傳輸 Kerberos V5,所以假設這應該是可能的,對吧?我不確定我是否沒有正確執行此操作,或者是否sssd不支持 Kerberos over TLS。Google搜尋不會產生任何成果,並且手冊頁中沒有任何看似相關的內容。

請注意,我的 LDAPS 通過 ELB 完美執行,所以我至少知道我並沒有完全偏離軌道。

TL;DR 如何回答我的問題

要麼告訴我:

  • 通過 TLS 設置 Kerberos 時我做錯了什麼,或者
  • sssd不支持基於 TLS 的 Kerberos

錯誤資訊

這是來自 的輸出sssd。請注意,我編輯了 IP 地址。

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

建築學

以下是我圍繞 Simple AD 的架構:

架構圖

此設置使我能夠使用 LDAPS,即使 AWS 的 Simple AD 不支持它。我認為它也可以讓我在 TLS 上使用 Kerberos。

ELB 的 route53 記錄是directory.myteam.mycompany.com,但我用於 Simple AD 的域是myteam.mycompany.internal

ELB 配置

我使用 terraform 來創建架構。這裡只是 ELB 資源的定義,其餘的無關緊要:

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

請注意,我使用的證書來自受信任的 CA,它是為*.myteam.mycompany.com.

執行 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

除了這兩個文件之外,我還確保sshd_config在 pam 模組中啟用密碼身份驗證並啟用 sssd 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

軟體版本

  • 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
  • sssd1.12.2

您想通過 RFC 6251 實現的目標是 MIT Kerberos 無法實現的,因為沒有計劃實施此方案。但是,從 MIT Kerberos 1.13 開始,通過支持 Microsoft 的 Active Directory 所支持的相同協議 MS-KKDCP,支持通過 HTTPS 代理 Kerberos。MS-KKDCP 的客戶端也被反向移植到 RHEL 7 ( https://rhn.redhat.com/errata/RHSA-2015-0439.html )。

該功能取決於客戶端代理 Kerberos 流量的能力。在 RHEL 7/CentOS 7 上執行的 SSSD 應該能夠做到這一點。我認為,Amazon Linux 沒有此版本的 Kerberos 庫,因此您的方法行不通。

此外,Amazon 的 Simple AD 是使用 Heimdal kerberos 建構的 Samba AD。它也不支持 MS-KKDCP,因此不能用作 MS-KKDCP 代理。

引用自:https://serverfault.com/questions/746194