É possível usar o Kerberos através do TLS através do sssd?

6

Antecedentes

Estou tentando efetuar login (via SSH, em uma instância do Amazon Linux EC2 executando sssd ) como usuários que criei no AD simples do AWS Directory Services. Estou autenticando com o Kerberos e identificando o usuário com o LDAP (através de sssd .) Conecto-me ao Simple AD através de um ELB em vários servidores proxy.

Problema

Quando eu configuro o ELB para usar TLS para a porta Kerberos, sssd não pode se conectar ao servidor Kerberos e o login falha. Sem o TLS, ele funciona muito bem e, depois que eu efetuo login sem o TLS, as credenciais são armazenadas em cache e o login continua a funcionar quando eu ligo o TLS novamente.

RFC 6251 apresenta uma explicação de como o Kerberos V5 pode ser transportado através de TLS, então, hipoteticamente, isso deve ser possível, certo? Não tenho certeza se não estou fazendo isso corretamente ou se sssd não suporta Kerberos por TLS. Pesquisando não produz nada frutífero e as páginas de manual não têm nada aparentemente relevante nelas.

Note que eu tenho LDAPS funcionando perfeitamente através do ELB, então eu sei, no mínimo, que eu não estou completamente fora do caminho.

TL; DR como responder minha pergunta

Diga-me também:

  • O que estou fazendo de errado ao configurar o Kerberos em TLS ou
  • sssd não suporta Kerberos por TLS

Mensagem de erro

Isso é da saída de sssd . Note que eu editei os endereços 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!

Arquitetura

Veja como minha arquitetura em torno do Simple AD se parece:

EssaconfiguraçãopermitequeeuuseLDAPS,emboraoSimpleADdaAWSnãoofereçasuporte.EupresumiquetambémmedeixariausaroKerberosporTLS.

Oregistroroute53paraoELBédirectory.myteam.mycompany.com,masodomínioqueeuuseiparaoSimpleADémyteam.mycompany.internal.

ConfiguraçãodoELB

Euuseiterraformparacriaraarquitetura.AquiestáapenasadefiniçãodorecursoELB,jáqueorestoéirrelevante:

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

Observe que o certificado que estou usando é de uma CA confiável e é especificado para *.myteam.mycompany.com .

Configuração na máquina executando o 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

Além desses dois arquivos, certifiquei-me de ativar a autenticação por senha em sshd_config e ativar o sssd nos módulos pam com 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

Versões de software

  • 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
por 2rs2ts 31.12.2015 / 19:55

1 resposta

2

O que você deseja alcançar com o RFC 6251 não é possível com o MIT Kerberos, pois não há planos para implementar esse esquema. No entanto, desde o MIT Kerberos 1.13, há suporte para o proxy do Kerberos via HTTPS, suportando o mesmo protocolo que o Active Directory da Microsoft suporta, o MS-KKDCP. O lado do cliente para o MS-KKDCP também foi retornado para o RHEL 7 ( link ).

A funcionalidade depende da capacidade de proxy do tráfego Kerberos pelos clientes. O SSSD em execução no RHEL 7 / CentOS 7 deve ser capaz de fazê-lo. O Amazon Linux não tem essa versão da biblioteca do Kerberos, portanto, sua abordagem não funcionaria.

Além disso, o Simple AD da Amazon é o Samba AD criado com o Heimdal kerberos. Ele também não suporta o MS-KKDCP, portanto, não pode ser usado como um proxy MS-KKDCP.

    
por 03.01.2016 / 23:31