RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 861398 - START TLS not work in sssd
Summary: START TLS not work in sssd
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: 6.2
Assignee: Stephen Gallagher
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-28 13:19 UTC by Tuan Nguyen
Modified: 2012-09-28 14:41 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-28 13:47:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Tuan Nguyen 2012-09-28 13:19:29 UTC 
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):
sssd-1.5.1-66.el6.x86_64

How reproducible:

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ldap-domain-example.html

enable client with "authconfig-tui" 

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

domains = default

debug_level = 5
debug_to_files = true

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

[domain/default]
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: [217.16.102.9] 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
g'

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

.NNhosting.com: [217.16.102.93] 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 13:47:51 UTC 
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 14:41:36 UTC 
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 . 

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