Мне нужно настроить различные машины Ubuntu Trusty, используя sssd для сервера 389ds, который ожидает привязки к использованию binddn, выбранному автоматически через сопоставление сертификата клиента.

Я успешно настроил 389ds с помощью certmap следующим образом:

# 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

Кроме того, я отключил анонимные привязки и принудительно установил внешние привязки SASL следующим образом:

# 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

На стороне sssd у меня есть /etc/sssd/sssd.conf, который выглядит следующим образом:

[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

Когда я запускаю sssd, sssd пытается выполнить привязку к 389ds, сначала пытаясь выполнить анонимное связывание (что приводит к сбою), а затем с помощью механизма SASL EXTERNAL (который также не срабатывает):

(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: ]

Используя ssldump, кажется, что клиентская сторона отправила сертификат клиента, однако опция ssldump -A глючит, и она отказывается сообщить мне что-либо об этом сертификате:

1 3  0.0283 (0.0218)  C>SV3.3(7)  Handshake
      Certificate

У меня есть вопросы:

  • Почему попытка sssd связать анонимно не удалась? Теоретически «nsslapd-force-sasl-external: on» должен привести к тому, что все попытки связывания будут игнорироваться в пользу клиентского сертификата.

  • Почему ssd пытается выполнить привязку с использованием SASL/EXTERNAL?

  • Существуют ли какие-либо руководства или инструкции, описывающие sssd+ldap вместе с клиентскими сертификатами?

Во избежание сомнений, в этом случае простое связывание не вариант.

Обновить:

Когда я пытаюсь использовать openssl s_client для подключения к серверу 389ds с использованием правильного сертификата клиента, в журнале 389ds правильно отображается следующее сообщение о том, что сертификат клиента инициировал успешное связывание:

[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

В этом случае кажется, что sssd не пытается связать с предоставленным сертификатом и ключом. Кто-нибудь знает почему?

2 ответа2

0

Это должно ответить на ваш последний вопрос о том, что sssd не пытается использовать клиентский сертификат. Из sssd-ldap, версия 1.1.14 (https://jhrozek.fedorapeople.org/sssd/1.14.2/man/sssd-ldap.5.html):

ldap_default_authtok_type (строка)

The type of the authentication token of the default bind DN.

The two mechanisms currently supported are:

password

obfuscated_password

Default: password

ldap_sasl_mech (строка)

Specify the SASL mechanism to use. Currently only GSSAPI is tested and supported.

Default: not set

До меня дошли слухи, что эта функция должна быть включена в 1.1.13, но на странице руководства ничего нового в этом отношении не сказано.

0

Рекомендуемая настройка (для RedHat) для анонимного доступа - установить для nsslapd-allow-anonymous-access значение «rootdse», а не «off». Мне интересно, решит ли это проблему, которую вы видите. Этот параметр позволяет анонимным клиентам читать конфигурацию сервера, но не данные каталога, такие как пользователи. Это описано на стр. 412 Руководства по идентификации, аутентификации и политике доменов RedHat Enterprise Linux 7 Linux.

# force sasl external binds to use cert
dn: cn=config
changetype: modify
replace: nsslapd-force-sasl-external
nsslapd-force-sasl-external: rootdse

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .