是否可以通過 sssd 在 TLS 上使用 Kerberos?
背景
我正在嘗試以
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 模組中啟用密碼身份驗證並啟用 sssdsudo 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
sssd
1.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 代理。