Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with
StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet)
and I'd like to let the sssd instances on all the systems authenticate to the
LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid
having to set/configure passwords for each system's sssd.
When I arrived into the office this morning our Nagios server was displaying a lot of alarms.
The "sssd_pam" process was consuming 100% CPU, and I was unable to log on to the box as anything
else than root.
2310 root 20 0 219m 44m 2176 R 99.6 0.3 2883:27 sssd_pam
In the var/log/sssd/sssd_pam.log file, the following error message was repeated:
[sssd[pam]] [accept_fd_handler] (0x0020): Accept failed [Too many open files]
This being our Nagios server the maximum amount of concurrent open files has been increased from
the default 1024 to 4096 for all users.
This is RHEL 6.3 with sssd-1.8.0-32.
What can I do to prevent this from happening in the future?
we do see some timeouts when sssd tries to bind to the LDAP
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [be_resolve_server_done]
(4): Found address for server xxx1.domain.de: [10.11.12.13] TTL 21600
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [fo_set_port_status] (4):
Marking port 636 of server 'xxx1.domain.de' as 'working'
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [set_server_common_status]
(4): Marking server 'xxx1.domain.de' as 'working'
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [simple_bind_send] (4):
Executing simple bind as: uid=abcdefg,ou=People,o=ldap,o=root
(Mon Aug 27 10:35:59 2012) [sssd[be[LDAP]]] [be_run_offline_cb] (3):
Going offline. Running callbacks.
(Mon Aug 27 10:35:59 2012) [sssd[be[LDAP]]] [be_pam_handler_callback]
(4): Backend returned: (1, 9, <NULL>) [Provider is Offline
(Authentication service cannot retrieve authentication info)]
In this case sssd seems to not ask the second ldap server?
We ser the "ldap_search_timeout" option to 120 seconds (default
is 6 seconds), but this does change the behaviour.
We are running sssd 1.5.1 (as distributed with CentOS 5.X).
Looking at all the different ldap timeout values, I guess that
"ldap_network_timeout" is not the right thing (because network
connect does work), could "ldap_opt_timeout" provide some solution
(as I do not really understand what it does)?
Olaf Gellert email gellert(a)dkrz.de
Deutsches Klimarechenzentrum GmbH phone +49 (0)40 460094 214
Bundesstrasse 45a fax +49 (0)40 460094 270
D-20146 Hamburg, Germany www http://www.dkrz.de
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Prof. Dr. Thomas Ludwig
Registergericht: Amtsgericht Hamburg, HRB 39784
OS: Fedora 17
Using the compiled source from the git repo, I'm having trouble getting
users to authenticate via PAM with the pam_sss.so module.
I can do ID lookups, enumerate user information, and "pam_test_client"
returns successful for all cases, but when logging in via SSH or through
the TTY, I get authentication failure. As an already-authenticated local
user, su commands/password auth work.
This problem persists despite pam_sss.so's order in the stack or its
control. Examining the logs, I don't see any error messages from pam_sss.
When installed from the repos, SSSD performs as expected.
I'd like to contribute to the project but thought it'd be a good idea to
get a system up and running with the unaltered source, first. Thanks.
I will be doing a short presentation in our company about IPA & sssd & Active Directory. The aim is to motivate headquarters to replace our
existing commercial (Centrify) solution with SSSD.
The presentation is available at:
should you like to see it.
Comments are welcome :-)
I'm having trouble getting a cluster of Fedora 16 installs (sssd-client-1.8.4-13.fc16.x86_64) to see secondary groups from my Open Directory server (rfc2307). I have a RHEL6 box (sssd-client-1.8.0-32.el6.x86_64) with an identical sssd.conf that does work. Is this a known issue or is there something wonky with my Fedora setup?
[fedora]# id ldapuser
uid=9000(ldapuser) gid=5079(ps) groups=5079(ps)
[rhel63]# id ldapuser
uid=9000(ldapuser) gid=5079(ps) groups=5079(ps),1000(cmcd),2004(sch-guest),1031(bc),1027(web)
[fedora]# ldapsearch -LLL -x -b cn=groups,dc=ldap,dc=in,dc=hwlab cn=sch-guest | grep ldapuser
my domain config in sssd.conf:
ldap_id_use_start_tls = False
cache_credentials = True
ldap_search_base = dc=ldap,dc=in,dc=hwlab
krb5_realm = LDAP.IN.HWLAB
krb5_server = ldap.in.hwlab,quasimoto.in.hwlab
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldap://ldap.in.hwlab/,ldap://quasimoto.in.hwlab/
krb5_kpasswd = ldap.in.hwlab
ldap_tls_cacertdir = /etc/openldap/cacerts
Thanks for any insight,
================= A security bug in 1.9.0 beta6 ===============
= Subject: HBAC rules ignored if SELinux processing
= is enabled
= CVE ID#: CVE-2012-3462
= Summary: A flaw in the SSSD's access-provider
= logic causes the result of the HBAC
= rule processing to be ignored in the
= event that the access-provider is
= also handling the setup of the user's
= SELinux user context.
= Impact: moderate
= Affects default
= configuration: yes (IPA provider only)
= Introduced with: 1.9.0 beta6
==== DESCRIPTION ====
The latest development release of the SSSD is vulnerable to a security bug.
When the SSSD is configured as an IPA client and the access provider is
also handling the evaluation of user's SELinux user context, the result
of Host Based Access Control rules is ignored.
We decided not to release a full release, for two reasons:
* the number of users running the beta is very small. Furthermore,
the beta releases are not fully tested and suitable for production
* the next release - 1.9.0 RC1 is coming very soon. It is tentatively
scheduled for 2012-08-23
==== WORKAROUND ====
If you don't rely on the evaluation of user's SELinux user context, you
can turn off their processing by setting:
selinux_provider = none
in the sssd.conf config file. That would cause the correct access control
code to be returned to the PAM service.
==== PATCH AVAILABILITY ====
The patch is available at:
I can configure sssd to use ldap as an id provider, and AD (krb5) as
auth provider, but I guess this poses problems for some web
because some of these don't know anything about krb and will look for
Just some question:
Why is ipHost host mapping not supported in SSSD - and deferred,
because this is strange when ipServicePort is supported?
Not a 100% necessary feature for our environment, but could be useful
for an IP mapping to important administration servers (monitoring,
I have a problem with pam_sss:
Aug 2 16:59:14 draco sshd: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
Aug 2 16:59:14 draco sshd: pam_sss(sshd:auth): received for user ondrejv: 22 (Authentication token lock busy)
Note that if I replace pam_sss with pam_krb5, it works like a charm.
Anyone knows what the message above means?