sssd-devel December 2011

sssd-devel@lists.fedorahosted.org

27 participants
59 discussions

Case insensitivity behaviour
by Jakub Hrozek 21 Dec '11

21 Dec '11

Hi, SSSD 1.7 will bring a new feature - the ability to mark a domain as "case insensitive". 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 "Foo:*:uid:gid:Foo:/home/Foo:/bin/bash". 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[1] - 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 case.

3 4

[PATCH] Save original memberof, not memberof
by Jakub Hrozek 21 Dec '11

21 Dec '11

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.

3 7

SSSD 1.7.0 release plans and branching information
by Stephen Gallagher 20 Dec '11

20 Dec '11

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.

1 0

[PATCH] PAM: make initgroups timeout work across multiple clients
by Stephen Gallagher 20 Dec '11

20 Dec '11

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). Fixes: https://fedorahosted.org/sssd/ticket/1063

2 2

[PATCH] Improve handling of DNS timeout
by Jakub Hrozek 20 Dec '11

20 Dec '11

Hi, 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 intentionally undocumented. https://fedorahosted.org/sssd/ticket/976

2 2

[PATCH] Error out if local domain is case insensitive
by Jakub Hrozek 20 Dec '11

20 Dec '11

https://fedorahosted.org/sssd/ticket/1104

2 2

[PATCH] MONITOR: use sigchld handler for monitoring SSSD services
by Stephen Gallagher 20 Dec '11

20 Dec '11

This patch depends on the SIGCHLD patches currently under review. This is the first consumer of those patches, and therefore can be used to test them. 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 here.

3 6

Re: [SSSD] Announcing SSSD 1.5.14
by GOLLSCHEWSKY, Tim 20 Dec '11

20 Dec '11

> > 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 real 0m48.47s user 0m0.15s sys 0m0.02s With ldap_rfc2307bis_initgroups_filter = (|(cn=xxxrd)(cn=xxxxp)(cn=xxxxd)) # time ssh myhost groups xxxxdm xxxxgmt xxxxd xxxxp xxxxd real 0m5.11s user 0m0.15s sys 0m0.03s 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. Best regards, Tim Gollschewsky. 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.

4 5

GSSAPI and Kerberos - understanding question
by Josh Geisser 20 Dec '11

20 Dec '11

Hi list 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. Cheers Josh -- ---- ASG at hnet

7 28

[www.transifex.net] New announcement created: SSSD
by admin＠transifex.net 19 Dec '11

19 Dec '11

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: http://www.transifex.net/projects/p/sssd/announcement/1423/ Always at your service. -- Transifex -- Open Translation Platform To change your notification settings, please visit your profile page at http://www.transifex.net/notices/.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel December 2011