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.
many new features rely on library APIs and features that are only available
in recent versions of SSSD dependencies. As a result, the code often needs
#ifdefs and special branches in order to at least compile or run on RHEL5.
So far we've been doing nightly builds also for RHEL5 and fixing issues
as we were finding them. But recently we are considering dropping support
for RHEL5 -- it is causing some engineering effort and at the same time
the audience is probably very limited. If you are running super-stable
enterprise distribution, chances are you are not all that interested in
the latest and possibly very unstable SSSD version.
The proposal would be to keep building and supporting the 1.9.x branch
for RHEL5 and switch to using RHEL6 as the oldest supported release
starting from the 1.10 upstream version. Of course we would still accept
patches from any potential contributors.
Any objections against the plan?
I see sudo package comes with a nice way how to extend the AD schema to support sudo attributes:
Hence my question:
Anyone tried something like:
sudo_provider = ad?
=== SSSD 1.9.5 ===
The SSSD team is proud to announce the release of version 1.9.5 of
the System Security Services Daemon.
As always, the source is available from https://fedorahosted.org/sssd
This is mostly a bugfix release with minor feature enhancements -- see
the changelog below for details. In addition to fixing functionality,
this release also includes one security patch.
Our focus is now on developing new features for the upcoming 1.10
release. That said, fixes for important bugs will be added to the 1.9.6
bucket and released when appropriate. The 1.9.6 release has no due date yet,
although we would release it to be aligned with RHEL-6.5 at the latest.
RPM packages will be made available for Fedora shortly, initially for
F-18 and later also backported to F-17, which has moved to the 1.9 series
== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
== Highlights ==
* This release focused mainly on fixing regressions compared to the 1.8
series and bugfixes for features introduced in the 1.9 release cycle. The
release also includes one security fix
* Includes a fix for CVE-2013-0287: A simple access provider flaw prevents
intended ACL use when SSSD is configured as an Active Directory client
* Fixed spurious password expiration warning that was printed on login
with the Kerberos back end
* A new option ldap_rfc2307_fallback_to_local_users was added. If this
option is set to true, SSSD is be able to resolve local group members of
* Fixed an indexing bug that prevented the contents of autofs maps from
being returned to the automounter deamon in case the map contained a large
number of entries
* Several fixes for safer handling of Kerberos credential caches for cases
where the ccache is set to be stored in a DIR: type
== Tickets Fixed ==
SSSD does not list local user's group membership defined in LDAP
[sssd[krb5_child[PID]]]: Credential cache directory /run/user/UID/ccdir does not exist
Misleading example in the man page
sssd is not serving large automount maps reliably
Saving dereferenced groups fails if a nested group member is outside nesting limit
Unchecked return value in files.c
names of domain_realm mapping files in SSSD contain dots
sssd_be crashes sometimes
pwd_expiration_warning has wrong default for Kerberos
sssd pam write_selinux_login_file creating the temp file for SELinux data failed
LDAP provider doesn't save binary attributes correctly
krbcc dir creation issue with MIT krb5 1.11
sssd etas 99% CPU and runs out of file descriptors when clearing cache
document what does access_provider=ad do
sssd fails with readonly /etc/selinux/targeted/logins
pam responder segfaults if the client disconnects before the operation finishes
Simple access control always denies uppercased users in case insensitive domain
== Detailed Changelog ==
Jakub Hrozek (16):
* Bump the version to 1.9.5, reset release in RPMs to 0
* Don't use srcdir with tests
* Fix the krb5 password expiration warning
* Remove enumerate=true from man sssd-ldap
* Don't treat 0 as default for pam_pwd_expiration warning
* Provide a be_get_account_info_send function
* Add unit tests for simple access test by groups
* Do not compile main() in DP if UNIT_TESTING is defined
* Resolve GIDs in the simple access provider
* Document what does access_provider=ad do
* Allocate PAM DP request data on responder context
* krb5: include backwards compatible declaration of krb5_trace_info
* Fix simple access group control in case-insensitive domains
* LDAP: do not invalidate pointer with realloc while processing ghost users
* tests: Link the simple access tests with -ldl
* Updating the translations for the 1.9.5 release
Jan Engelhardt (1):
* sysdb: try dealing with binary-content attributes
Kamil Dudka (1):
* sssd-1.8.0: work around a bug in cov-build from Coverity
Lukas Slebodnik (1):
* Fix krbcc dir creation issue with MIT krb5 1.11
Michal Zidek (4):
* Unchecked return value in files.c
* File descriptor leak in nss responder.
* Debug message in sss_mc_create_file.
* sssd fails with readonly SELinux login files
Pavel Březina (6):
* krb: recreate ccache if it was deleted
* subdomains: replace invalid characters with underscore in krb5 mapping file name
* sdap_fill_memberships: continue if a member is not foud in sysdb
* autofs: fix invalid header 'number of entries' in packet
* if selinux is disabled, ignore that selogin dir is missing
* krb5-utils-tests: remove invalid condition
Simo Sorce (1):
* ldap: Fallback option for rfc2307 schema
Stephen Gallagher (2):
* Fix minor grammar error in log
* NSS: Add original homedir to home directory template options
SSSD 1.9.2 on CentOS 6.
I am attempting to configure SSSD to authenticate against AD via LDAP.
When starting the daemon though, the logs get filled with failure
messages about being unable to convert the SID properly for every user.
The extra strange part is the SID it says it cannot convert is the same
for every user. Example:
(Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_user] (0x1000):
Mapping user [REDACTED] objectSID to unix ID
(Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_idmap_sid_to_unix]
(0x0080): Could not convert objectSID
[S-1-5-21-3220130920-4012199101-135577023-1153286127] to a UNIX ID
(Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_user] (0x0040):
Failed to save user [REDACTED]
(Mon Apr 15 15:52:47 2013) [sssd[be[LDAP]]] [sdap_save_users] (0x0040):
Failed to store user 988. Ignoring.
Where can I get more information on why it's failing? The following is
domains = LDAP
services = nss, pam
config_file_version = 2
;debug_level = 0x1310
filter_groups = root
filter_users = root
ldap_id_use_start_tls = True
id_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://REDACTED
ldap_search_base = REDACTED
auth_provider = ldap
cache_credentials = true
ldap_schema = ad
enumerate = True
ldap_id_mapping = True
ldap_user_objectsid = objectSid
ldap_idmap_range_min = 100000
ldap_idmap_range_max = 1000000
ldap_default_bind_dn = REDACTED
ldap_default_authtok_type = password
ldap_default_authtok = REDACTED
ldap_tls_cacertdir = /etc/sssd/cacerts
debug_level = 9
ldap_force_upper_case_realm = True
Also, here's what ObjectSID looks like from LDAP (via ldapsearch) for
one of the users it's complaining about:
When comparing this to the other user's not being mapped, the objectSid
coming from LDAP, at initial glance, is not the same.
I found a bug in sssd stable 1.9.2 and 1.9.4. I found no place to report this so maybe somene here is able to help with this.
The sudoers ldap lookups fail with a timeout message (see below) when using ldap_uri = _srv_ (which works with anything else i.e. ldap_users, ldap_groups, ...).
This is how it looks with ldap_uri set to _srv_:
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [dc=mydomain,dc=org]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=sudoRole)][dc=mydomain,dc=org].
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter]
(Thu Apr 18 20:51:03 2013) [sssd[be[MYDOMAIN]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder]
(Thu Apr 18 20:52:03 2013) [sssd[be[MYDOMAIN]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [dc=mydomain,dc=org]
(Thu Apr 18 20:52:03 2013) [sssd[be[MYDOMAIN]]] [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full refresh of sudo rules failed : Connection timed out)
For debugging I turned of ldap_sudo_use_host_filter just in case someone is wondering about the short ldap filter.
With an ldap_uri set to a FQHN anything works as expected.
Is there anyone who can help creating a patch for this? I have very little knowledge about the sssd source.
Since getting sssd logins to work correctly, I'm noticing that logging
in with my 'old' local user account takes orders of magnitude longer to
complete than before. (root logins continue to happen without any
noticeable delay.) Why is that, and is there a configuration parameter I
can change to restore normal login times for local non-root users? I can
work around the problem by opening a separate text console as root and
stopping the sssd daemon until the login completes, then restarting the
Ultimately, of course, I think the logical solution is to create a local
sssd user (with an associated LOCAL domain), but I've grown fond of my
local account user name and I'm not certain yet that I can use
sss_useradd to create a local database entry with the same account name
without some unintended (and perhaps negative) consequences.
Global Solutions Support Engineering (GSSE)
GSD Customer Solution Center
Technology Services, Enterprise Group
by Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)
The following entry into an ldap.conf file on a RHEL V5 system provides for the ability to limit users
based in their GID values:
nss_base_passwd OU=ldap,DC=mydomain,DC=net?one?|(gidNumber=11001) (gidNumber=11003)
Only those users with GID's of 11001 or 11003 can login. All others are prohibited.
I've tried the same filter in sssd.conf on a v6 RHEL system but can't seem to get it to work.
It doesn't cause any syntax errors but it is ignored.
I've also tried placing an "=" sign after the nss_base_passwd string and quoting everything after
the "=" sign....to no avail.
Can anyone explain the sssd syntax for accomplishing this task ?
Thanks in advance.
hi errbody, i may have an easy question, but i haven't found anything in
the documentation which describes my use-case exactly. i hope you can help.
my environment is kerberos for authentication and kerberos using
host-keytab for ldap binds. sssd is working fine for this setup. the
wrinkle is that i am trying to get this to work on a (Rocks) hpc cluster
where i have kerberos running on headnode but not the compute nodes.
i am hoping that i can use the sssd config with kerberos authentication on
the head node and have a simpler setup for the compute nodes. since ssh
public keys are used for authentication on compute nodes, i really only
need user and group enumeration working there. is there a simple way to
get user list from sssd on head node for use on compute nodes?