Eu tenho a necessidade de configurar várias máquinas Ubuntu Trusty usando sssd em um servidor 389ds que espera estar vinculado a usar um binddn selecionado automaticamente através de um mapeamento de certificado de cliente.
Configurei 389ds com êxito com um certmap da seguinte forma:
# By default, we trust any valid certificate that has an ou attribute that
# matches an entry (currently ou=Servers) in the DIT
certmap default default
default:DNComps
default:FilterComps ou
default:verifycert off
Além disso, desativei associações anônimas e forcei ligações externas SASL da seguinte forma:
# disable anonymous binds
dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: off
# force sasl external binds to use cert
dn: cn=config
changetype: modify
replace: nsslapd-force-sasl-external
nsslapd-force-sasl-external: on
No lado sssd, eu tenho o /etc/sssd/sssd.conf da seguinte forma:
[sssd]
config_file_version = 2
domains = LDAP
services = nss, pam
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
# A native LDAP domain
[domain/LDAP]
enumerate = true
cache_credentials = TRUE
debug_level = 9
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://ldap.example.com:636
ldap_user_search_base = dc=example,dc=com
tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/root-ca.crt
ldap_tls_cert = /etc/ssl/certs/my.crt
ldap_tls_key = /etc/ssl/private/my.key
ldap_sasl_mech = EXTERNAL
Quando eu inicio o sssd, o sssd tenta se ligar a 389ds, primeiro tentando se vincular anonimamente (o que falha) e, em seguida, usando o mecanismo SASL EXTERNAL (que também falha):
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0400): Search result: Inappropriate authentication(48), Anonymous access is not allowed.
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Inappropriate authentication(48), Anonymous access is not allowed.
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_server_opts_from_rootdse] (0x0200): No known USN scheme is supported by this server!
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1458231814
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: EXTERNAL, user: (null)
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-6)[Unknown authentication method]
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-4): no mechanism available: ]
Usando o ssldump, parece que o lado do cliente enviou um certificado de cliente, no entanto, a opção ssldump -A está com bugs e ele se recusa a me informar sobre esse certificado:
1 3 0.0283 (0.0218) C>SV3.3(7) Handshake
Certificate
As perguntas que tenho são:
-
Por que a tentativa do sssd de vincular-se anonimamente está falhando? Em teoria, o "nsslapd-force-sasl-external: on" deve fazer com que todas as tentativas de bind sejam ignoradas em favor do certificado do cliente.
-
Por que a tentativa do ssd de se ligar usando a falha SASL / EXTERNAL?
-
Existe algum tipo de guia ou como descrever o sssd + ldap junto com certificados de clientes?
Para evitar dúvidas, neste cenário, as ligações simples não são uma opção.
Atualização:
Quando eu tento usar o openssl s_client para conectar ao servidor 389ds usando o certificado de cliente correto, o seguinte aparece corretamente no log do 389ds indicando que o certificado do cliente acionou uma ligação bem-sucedida:
[17/Mar/2016:16:35:02 +0000] conn=130 SSL 128-bit AES-GCM; client CN=stuff,OU=Servers,O=Example,DC=example,DC=com; issuer CN=morestuff,OU=Example Signing CA,O=Example,DC=example,DC=com
[17/Mar/2016:16:35:02 +0000] conn=130 SSL client bound as ou=Servers,dc=example,dc=com
Aparece, neste caso, que o sssd não está tentando ligar-se ao certificado e à chave fornecidos. Alguém sabe por quê?