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?
This is SSSD-VERSION 1.9.4 , Ubuntu Quantal 12.10
If homedir doesn't exist, user cannot login - homedir is not created locally on fly. Is it expected behavior?
fallback_homedir = /home/%u
override_homedir = /home/%u
Do I suppose to make change in pam to get it work?
Another problem - with group IDs:
After login to the terminal, I get the long list of warnings for all groups 1172xxxxx - it really delays login,
as the list is long. Do I miss some config options ?
su - testuser
groups: cannot find name for group ID XXXXXXX
id -G testuser
332400513 332411734 332411220 332411221 332405659 332410635 332403786 332403699 332407177 332408204 332408312 332406100 332408307 332413664 332402685 332402830 332411184
id -G -n testuser
domain users data-nat-nat-it-groupdrive rw nat-fnc-pri-setdiscription nat-pri-setcomputerdesc imada-terminal-users nat-it-outlook-admin nat-terminal-users terminal brugere dl-nat-it-staff nat-it-ansatte nat-it-ad-hoc nat-esignatur dl-nat-it nat-ctxusers common_users nat-lectures nat-booking
uid=332405654(testuser) gid=332400513(domain users) groups=332400513(domain users),1172612322,1172651920,1172657894,1172606592,1172607216,
........(a lot of groups)...
I have an LDAP server that is configured to serve up groups, and only
groups, using the rfc2307 schema. I have available to me a separate ldap
authentication server. I want sssd to get identity information from both
sources. It is not possible to just put the groups into the existing
server, as "they" will not grant me write access nor will they agree to
manage the groups.
sssd.conf is set up with two domains. The first (ldapr) is both auth and
id provider. The second (groupldap) is simply an id provider (with
The problem is that initgroups() only seems to be running for the first
In the first domain, gidNumber = uidNumber but there is no group with this
The groupldap DOES have a group with this gidNumber. It is successfully
obtained with the nss_cmd_getgrgid_search call before the initgroups call
finishes for USERNAME@ldapr.
The information flow is basically:
Issue initgroups for ALL
begin initgroups for ldapr
get missing information from groupldap
complete initgroups for ldapr
Here, it seems to me that it should continue with an initgroups for
groupldap. It does not.
There are other groups on groupldap that have memberUid=USERNAME. There is
never any search for groups with memberUid=USERNAME coming from the server
(in the logs on the ldap server, or in the sssd logs), and initgroups is
never called on the second domain (groupldap).
To make things more confusing, if I:
getent -s sss group SOMEGROUP
where SOMEGROUP is a posixGroup on groupldap.
So, it CAN get the group information from the groupldap domain, but it
Is this a bug, or the expected behavior? If this is expected, how do you
get it to search both?
Any help would be greatly appreciated.
We're running Debian systems with old sssd 1.2.1 shipped in Debian Squeeze.
This works most of the times with getent passwd and getent group together with
uncached sudo-ldap data. So the data is in place and can be correctly
retrieved by sssd via LDAP.
Since this old sssd version has some problems and does not have SUDO support
we're looking at upgrading to 1.9.4.
My colleague prepared back-ported Debian packages of 1.9.4 I'm testing with.
But I'm struggling that groups are not correctly retrieved - see my last
attempt of sssd.conf attached.
1. After login id does not show the user's groups although the OpenLDAP logs
show that group entries are searched and returned to sssd by OpenLDAP's slapd.
2. sudo -l -U username does not work although the OpenLDAP logs show that
sudoRole entries are searched and returned to sssd by OpenLDAP's slapd.
I wonder whether https://fedorahosted.org/sssd/ticket/1664 is relevant in my
case but playing with several values for filter_users_in_groups and enumerate
did not help.
sssd appears to bind successfully, but when it tries to fetch user information id balks. Here is a snippit from the log file immediately after the successful bind.
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): Bind result: Success(0), no errmsg set
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'mymachine' as 'working'
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status] (0x0100): Marking server 'mymachine' as 'working'
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done] (0x0100): sdap_get_generic_ext_recv failed : Input/output error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] (0x0040): dereference processing failed : Input/output error
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020): Nested group processing failed: [Input/output error]
(Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,Group lookup failed
(Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] (0x0040): Unable to get information from Data Provider
Error: 3, 5, Group lookup failed
Will try to return what we have in cache
ldpasearch works fine:
ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret "cn=somegroupname" -LL
and produces copious information about all the members of "somegroupname"
this is causing a major headache as a simple ls -l will hang the system.
I have just upgraded a few of my machines from Fedora 17 to Fedora 18
(sssd-1.9.4-3.fc18.x86_64) and on the F18 machines, users are now presented
with the "Your password will expire in 204 days..." message. All machines are
connected to an F17 FreeIPA server (freeipa-server-2.2.1-2.fc17.x86_64) which
has the "Password Expiration Notification (days)" set to 30.
I've been reading up on the "pam_pwd_expiration_warning (integer)" variable in
the sssd.conf man page, and the default is supposed to be "0", which I think
should allow the FreeIPA configuration to pass through.
Is there something I'm missing here? I'm pretty sure people don't need to see
the prompt at every login for the next 204 days, even though i bet some of
them will still not have changed their password ;)
Thanks in advance. -A
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
As a continuation of sssd evaluatin we plan migration from NIS to Active Directory+Kerberos.
Now again the question - what is the best approach and practice to migrate users ?
AD administrators enabled SFU, and we got extended schema with POSIX attributes.
I guess there might be some free or commercial tools for extracting data from NIS and loading into AD -ldap objects.
Our Linux users are dispersed in separated NIS domains, and all have AD account beside the entry in NIS.
Home directories are NFS-mounted with autofs from Linux storage server but some users access MSWin storage with smbclient.
Can you share experiences on assigning POSTFIX attributes in SSSD context, best practice etc..?
We would not like activate NIS services on AD server for migration.
=== SSSD 1.5.17 ===
The SSSD team is proud to announce the bugfix release of the System
Security Services Daemon version 1.5.17
As always, the source is available from https://fedorahosted.org/sssd
According to our current plan, this would be the last release done on
the 1.5 LTM branch upstream. When the next 1.9 release is out, it will
be proclamed LTM and the 1.5 branch would go completely EOL upstream,
with the exception of serious security issues or serious regressions
caused by this release.
== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
== Highlights ==
* A security bug assigned CVE-2013-0219 was fixed - TOCTOU race
conditions when creating or removing home directories for users in
* Monitoring and restarting child processes was made more robust
* The ipa_hbac_support_srchost option was backported, defaulting
* The limit of file descriptors a responder is allowed to open is
configurable using the fd_limit option
* Idle client connections are terminated in the responder
== Tickets fixed ==
== Detailed Changelog ==
Jakub Hrozek (8):
* Rename fo_get_server_name to fo_get_server_str_name
* fo_get_server_name() getter for a server name
* Only do one cycle when resolving a server
* Detect cycle in the fail over on subsequent resolve requests only
* Try all KDCs when getting TGT for LDAP
* HBAC: create empty groups with one NULL element
* Process all groups from a single nesting level
* TOOLS: Use openat/unlinkat when removing the homedir
Jan Zeleny (1):
* Add ipa_hbac_support_srchost option to IPA provider
Ondrej Kos (7):
* Add common SIGCHLD handling for providers
* Cancel ping-check if service goes away
* MONITOR: use sigchld handler for monitoring SSSD services
* Add new debug level macros
* UTIL: Add function for atomic I/O
* TOOLS: Use file descriptor to avoid races when creating a home directory
* TOOLS: Compile on old platforms such as RHEL5
Shantanu Goel (4):
* Set return errno to the value prior to calling close().
* Log message if close() fails in destructor.
* Do not send SIGPIPE on disconnection
* Add support for terminating idle connections
Stephen Gallagher (14):
* Bumping version to 1.5.17
* Fix potential resource leak in backup_file.c
* Log fixes for sdap_call_conn_cb
* LDAP: Copy URI instead of pointing at failover service record
* IPA: Detect nsupdate support for the realm directive
* DP: Reorganize memory hierarchy of requests
* Make the client idle timeout configurable
* LDAP: Make sdap_access_send/recv public
* IPA: Check nsAccountLock during PAM_ACCT_MGMT
* Also expire connections on the privileged pipe
* RESPONDERS: Allow increasing the file-descriptor limit
* RESPONDERS: Make the fd_limit setting configurable
* Converge accept_fd_handler and accept_priv_fd_handler
* SYSDB: Make sysdb_attrs_get_el_int() public