Bug 861398 - START TLS not work in sssd
START TLS not work in sssd
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
x86_64 Linux
unspecified Severity high
: rc
: 6.2
Assigned To: Stephen Gallagher
Kaushik Banerjee
Depends On:
  Show dependency treegraph
Reported: 2012-09-28 09:19 EDT by Tuan Nguyen
Modified: 2012-09-28 10:41 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-09-28 09:47:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tuan Nguyen 2012-09-28 09:19:29 EDT
Description of problem:
Our LDAP server is fedora LDAP (389-console), it works great with RH4, RH5, Sles10, Sles11 clients when using StartTLS on port 389 (ssl start_tls in ldap.conf)

But beginning of RH6, the old ldap (etc/ldap.conf) is replaced by /etc/sssd/sssd.conf. Unfortunately the StartTLS in sssd not work correctly, it ditn't failed when I play with the certificate or delete it. On RH5 all "id", "getent passwd", login stop to work when this happens.

Version-Release number of selected component (if applicable):

How reproducible:


enable client with "authconfig-tui" 

cat sssd.conf
config_file_version = 2
services = nss, pam

domains = default

debug_level = 5
debug_to_files = true

filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd

ldap_id_use_start_tls = True
ldap_tls_reqcert = demand
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
cache_credentials = True
ldap_search_base = dc=NN
ldap_uri = ldap://centaur,ldap://zpm
ldap_tls_cacertdir = /etc/openldap/cacerts

Steps to Reproduce:
1. setup a rh6 ldap client with the settings above, using certificate
2. test "id" to see if it works
3. remove the certificate (or just replace some characters in the cert)

Actual results:

The LOG shows correctly that StartTLS failed, but still the commando "id" stills work and I can still login on the server. It should not.

tail -f /var/log/sssd/sssd_default.log

(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [resolv_gethostbyname_dns_query] (4): Trying to resolve A record of 'centaur' in DNS
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [set_server_common_status] (4): Marking server 'centaur' as 'name resolved'
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [be_resolve_server_done] (4): Found address for server centaur: [] TTL 12848
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [sdap_sys_connect_done] (4): Executing START TLS
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [sdap_connect_done] (3): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL.
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [sdap_get_server_opts_from_rootdse] (5): No known USN scheme is supported by this server!
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [sdap_get_server_opts_from_rootdse] (5): Will use modification timestamp as usn!
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [simple_bind_send] (4): Executing simple bind as: (null)
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [simple_bind_done] (5): Server returned no controls.
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [simple_bind_done] (3): Bind result: Success(0), (null)
(Fri Sep 28 13:10:38 2012) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'centaur' as 'workin

*****Remove the certificate
rm -fr /etc/openldap/cacerts
tail -f /var/log/sssd/sssd_default.log

.NNhosting.com: [] TTL 14400
(Fri Sep 28 13:13:41 2012) [sssd[be[default]]] [sdap_sys_connect_done] (4): Executing START TLS
(Fri Sep 28 13:13:41 2012) [sssd[be[default]]] [sdap_connect_done] (3): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL.
(Fri Sep 28 13:13:41 2012) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend!
(Fri Sep 28 13:13:41 2012) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'zpm' as 'not working'
(Fri Sep 28 13:13:41 2012) [sssd[be[default]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Fri Sep 28 13:13:41 

Expected results:
When the certificate is "modified"/removed the command "id" (or "getent passwd" in RH5; "getent" not works for sssd) should not work, meaning no one (ldap user) can login to the server anymore.

Additional info:
Comment 2 Stephen Gallagher 2012-09-28 09:47:51 EDT
This is a feature, not a bug. When 'cache_credentials = True', SSSD maintains a local hash of the user password of users that have previously logged in so that if the LDAP server goes away for any reason (network issue, expired certificate, crashed daemon on the LDAP server, etc.) the machine running SSSD can continue to allow access while the network is unavailable.

So in this case, from SSSD's perspective, the LDAP server is unreachable (because the certificate doesn't match up), so it switches to offline mode. If this is not the behavior you want, you need to set 'cache_credentials = False' in sssd.conf, remove /var/lib/sss/db/cache_default.ldb (*) and restart SSSD with 'service sssd restart'. This will switch the behavior so that users cannot log in anymore if the LDAP server is unreachable. It will not change the 'id' or 'getent' results - those will still be answered from the identity cache - but it will not allow offline login.

Allowing the identity cache to remain is harmless, and in most cases beneficial (since it allows you to still see usern and group ownership for files with 'ls -l').
Comment 3 Tuan Nguyen 2012-09-28 10:41:36 EDT
Hello Stephen 

Thanks for your explanations, you are right it is a feature. Thanks for the trick with /var/lib/sss/db/cache_default.ldb .

Ok I will let it be, I will add "offline_credentials_expiration = 3" (days) in the sssd.conf . 


Note You need to log in before you can comment on or make changes to this bug.