SSSD 1.7 will bring a new feature - the ability to mark a domain as "case
As implemented currently, if a domain is case-insensitive, SSSD would
store a lowercased alias in addition to the real name and lowercase all
queries for that domain so that they match on the alias. However, SSSD
would still return the original case sensitive name from the NSS
provider. For example, it is possible to look up a user "Foo" with
"getent passwd foo", but getent would still return
One of our users logged https://fedorahosted.org/sssd/ticket/1123 requesting
that we also lowercase the *result*. I'm not sure it's the right thing to
do, I implemented the case sensitivity feature the way I did on purpose,
thinking that we still want to return the *real* user name much like we
do for multiple CN attributes.
I would appreciate more opinions on this. One of the reasons for
implementing this feature in the first place was Windows SSO - I
admit I haven't tested this particular scenario, but I think what we
have now would suffice so that name lookups would work regardless of
The sdap_save_* refactoring brought one bug where instead of saving into
SYSDB_ORIG_MEMBEROF we would save into SYSDB_MEMBEROF. I rechecked all
other attribute names and this was the only one that was changed.
SSSD 1.7.0 is dev-complete to the best of our knowledge. We will be
releasing the 1.7.0 tarball on Thursday, to give translators a few more
days to provide updated strings, as well as a few more days of testing.
I have now created the sssd-1-7 branch and updated the version on the
master branch. All pushes that go to master are now targeted for SSSD
1.8.0. If an urgent fix is discovered that needs to go to 1.7.0 as well,
it will need to be merged to the sssd-1-7 branch.
Instead of timing out the initgroups lookup on a per-cctx basis,
we will maintain a hash table of recently-seen users and use this
instead. This will allow SSSD to handle user's logging into
multiple services simultaneously more graciously, as well as
playing nicer with SSH (which makes calls to PAM both before and
after a fork).
I'm not sure if it's still time to include this change in 1.7 since we
froze the strings yesterday, but if not, feel free to postpone to 1.8.
[PATCH 1/3] Resolver: Introduce a per-request timeout
In addition to passing a timeout to c-ares (which controls how long
would c-ares talk to an individual name server), also set up a tevent
timeout for the whole request.
The rationale is that the user of the async interface does not know or
case how many name servers there are and would like to just limit how
long the whole request could take. This should help in situations where
the DNS server is very slow or drops packets.
[PATCH 2/3] Do not touch resolve_service_state in fo_resolve_service_done
In the fail over code, we correctly used the "server->common" pointer as
memory context for the resolving but then passed a service resolving
state as a private context.
If the service resolving request was canceled before the resolving
request finished, fo_resolve_service_done would access freed memory.
This was a long-standing bug in the fail over code we never hit because
the service resolve request could end only when the resolve request
ended. I hit the bug when I introduced the timeouts in the later patch.
[PATCH 3/3] Failover: Introduce a per-service timeout
Changes the semantics of dns_resolver_timeout to be "how long a
service resolution can take" from "how long a name resolution can take".
I think it is better from the point of view of the fail over user.
Also introduces a new option dns_resolver_op_timeout which controls the
resolver timeout (which is what dns_resolver_timeout used to do). It is
This patch depends on the SIGCHLD patches currently under review. This
is the first consumer of those patches, and therefore can be used to
This changes the behavior of the monitor's child-monitoring code to use
the new sigchld handler. It also replaces some useless loop-checks that
we were doing to verify that the process was still up using waitpid().
It's less wasteful to simply rely on SIGCHLD.
I also revamped the restart logic so that now it will always restart
when the SIGCHLD handler is hit. To that end, I changed it so that the
ping timeout limit would kill the PID (thereby triggering the SIGCHLD
handler to take over).
Finally, I also added a 60s timer on monitor_kill_service() so that it
will send a SIGKILL to the process if it hasn't exited gracefully a
minute after receiving SIGTERM. This is probably the most controversial
piece of this patch. In theory, if we SIGKILL during an
ldb_transaction_commit(), we could end up with corrupted data in the LDB
cache. But I think that if we're still writing after 60s, we have bigger
issues to address. I'm certainly willing to entertain counter-arguments
> > I'm not sure if artificially trimming the group list is a good idea.
> > It wouldn't work for everyone and I would be wary of breaking access
> > control mechanisms.
> Noted. And yes I agree this (non-mandatory) config option wouldn't be useful for everyone, it's just something
> that fixes my particular problem (reduces ssh login times from 30 seconds to <5).
> I may have to write my own patch and apply it to the SRPM as each official version of SSSD is released. It won't be
> supported by Red Hat obviously but my users won't be complaining about slow login times anymore. So partial win. :)
Just thought I'd contribute my results in case this helps with your investigation of the larger problem. I assume there are other organisations with huge AD/LDAP directories that are having similar issues with ssh authentication times.
I've finished my local patch and added a config option called: ldap_rfc2307bis_initgroups_filter
If not specified, sssd just reverts to normal behaviour (cn=*) during the initgroups run.
With no ldap_rfc2307bis_initgroups_filter:
# time ssh myhost groups
xxxxdm xxxxdef xxxxgmt xxxx002 xxxx003 xxxxp xxxx001 xxxx002 xxxxt xxxxp xxxxange xxxxra xxxxb2 xxxxp xxxxd xxxxt xxxxp xxxxp xxxxp xxxxp xxxxd xxxxd xxxxp xxxxd xxxxd xxxxd xxxxp xxxxp xxxxd xxxxd xxxxp xxxxt xxxxd xxxxlemr xxxxp xxxxd xxxxp xxxxp xxxxd xxxxt xxxxd xxxxp xxxxd xxxxd xxxxt xxxxp xxxxt xxxxp xxxxd xxxxd xxxxt xxxxp xxxxd xxxxu xxxxp xxxxp xxxxp xxxxp xxxxd xxxxp xxxxp xxxxu xxxxp xxxxp xxxxt xxxxp xxxxd xxxxd xxxxt xxxxp xxxxd xxxxt xxxxt xxxxd xxxxt xxxxp xxxxp xxxxi xxxxd xxxxd xxxxp xxxxd xxxxp xxxxp xxxxd xxxxd xxxxp xxxxp xxxxd xxxxp xxxxd xxxxp xxxxd xxxxp xxxxp xxxxp xxxxp xxxxd xxxxd xxxxd xxxxd xxxxp xxxxp xxxxp xxxxd xxxxd xxxxd xxxxd xxxxd xxxxp xxxxp xxxxd xxxxd xxxxd xxxxd xxxxd xxxxd xxxxp xxxxp xxxxd xxxxp xxxxd xxxxd xxxxp xxxxd xxxxd xxxxd xxxxd xxxxd xxxxp xxxxd xxxxd xxxxd xxxxd xxxxd xxxxd xxxxd xxxxp xxxxd xxxxd xxxxp xxxxt xxxxp xxxxd xxxxd xxxxp xxxxd xxxxd xxxxd xxxxp xxxxd xxxxd
With ldap_rfc2307bis_initgroups_filter = (|(cn=xxxrd)(cn=xxxxp)(cn=xxxxd))
# time ssh myhost groups
xxxxdm xxxxgmt xxxxd xxxxp xxxxd
This hack will have to do until a better solution is found. I'm hoping the fixes coming in 1.7.0 will do the trick. :)
Thanks to everyone who helped me get to this point.
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
I'm sure I have gabs of understanding of how to use SSSD without using plain binding-user credentials in the configfile. I followed the guide for Win2008 allthough I only have 2003 SFU - would that work?
- I see it right that GSSAPI should enable looking up stuff in the LDAP using a machine-account instead of the binding-user/passwd?
- Kerberos (which has the machine-auth-ticket) comes into play for LDAP, but this exceeds the basic LDAP authentication (eg. Auth via Kerberos on the LDAP server)? Is this enough to feed nsswitch (e.g. getent) or is an additional valid user/pass still required?
The trouble I'm having here is the ktpasswd.exe generated-key is always dated at 01/01/70 01:00:00 which I guess is also the reason why ldapsearch -Y GSSAPI and kinit fail? 2003 behaviour?
The krb and ldap configuration works quite fine with bind-dn, just struggeling with SASL/GSSAPI.
ASG at hnet
Hello sssd, this is Transifex at https://www.transifex.net.
A new announcement has been just created for the project 'SSSD'.
You can check it out bellow:
String Freeze for SSSD 1.7.0
As of Dec 19, 2011, we are in string freeze for the SSSD 1.7.0 release.
If you'd like to see it at Transifex, please visit the following link:
Always at your service.
Transifex -- Open Translation Platform
To change your notification settings, please visit your profile page at http://www.transifex.net/notices/.