Wie konfiguriere ich sssd für die Authentifizierung bei LDAP mithilfe von Clientzertifikaten / SASL EXTERNAL?

Ich muss verschiedene Ubuntu Trusty-Computer mit sssd gegen einen 389ds-Server konfigurieren, der erwartet, dass ein binddn verwendet wird, der automatisch über ein Client-Zertifikat-Mapping ausgewählt wird.

Ich habe erfolgreich 389ds mit einer certmap wie folgt eingerichtet:

# 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 

Außerdem habe ich anonyme Bindungen deaktiviert und externe SASL-Bindungen wie folgt erzwungen:

# 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 

Auf der sssd-Seite habe ich /etc/sssd/sssd.conf, das wie folgt aussieht:

[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 

Wenn ich sssd starte, versucht sssd, sich an 389ds zu binden, indem zuerst versucht wird, anonym zu binden (was dann fehlschlägt) und dann den SASL EXTERNAL-Mechanismus zu verwenden (der ebenfalls fehlschlägt):

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

Mit ssldump wurde anscheinend von der Clientseite ein Clientzertifikat gesendet. Die Option ssldump -A ist jedoch fehlerhaft und weigert sich, etwas über dieses Zertifikat zu sagen:

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

Die Fragen, die ich habe, sind:

• Warum scheitert der Versuch von sssd, anonym zu binden? Theoretisch sollte das "nsslapd-force-sasl-external: on" dazu führen, dass alle Bindungsversuche zugunsten des Clientzertifikats ignoriert werden.

• Warum schlägt der Versuch von ssd, sich mit SASL / EXTERNAL zu verbinden, fehl?

• Gibt es eine Art Anleitung oder Howto, die sssd + ldap zusammen mit Client-Zertifikaten beschreibt?

Zur Vermeidung von Zweifeln sind in diesem Szenario einfache Bindungen keine Option.

Aktualisieren:

Wenn ich versuche, openssl s_client zu verwenden, um eine Verbindung zum 389ds-Server unter Verwendung des richtigen Clientzertifikats herzustellen, wird im 389ds-Protokoll Folgendes korrekt angezeigt, was darauf hinweist, dass das Clientzertifikat eine erfolgreiche Bindung ausgelöst hat:

[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 

In diesem Fall scheint es so, dass sssd nicht versucht, sich mit dem bereitgestellten Zertifikat und Schlüssel zu verbinden. Weiß jemand warum?