On 10/24/2012 3:13 PM, Dmitri Pal wrote: Honestly, I have zero interest in trying to replicate my entire LDAP directory on each and every server 8-/. It's kinda big ;). Most servers are probably only going to touch pieces of it, improving performance by caching those is good, but trying to replicate it entirely feels wrong. I'm not even sure it would work on our LDAP server, which resource restricts anonymous connections. I could try it out to see if it changes anything, but the only reason we run RHEL is for proprietary products that require it, and not running the stock supported rpm's kind of defeats that purpose :). If 1.9.2 is better I'd have to get them to back port whatever changes were relevant to the resolution, which would likely be more trouble than getting them to backport a single feature such as skipping group membership lookups. It's not intractable to handle our groups in a timely fashion, our Solaris 10 boxes do the same getent lookup in about 2/10 of a second. But considering we don't actually need the membership returned, just not including it seems a quicker solution. We would implement it ourselves, but I don't want to go to the trouble unless there's some reasonable chance upstream will accept it. RHEL6 includes nss-pam-ldapd rather than stock nss_ldap. While forked from nss_ldap, it does indeed not include the skipmembers feature. I already opened a case; the initial response was: ----- Could you please provide us the output of the strace command so that we can check where exactly the command is taking more time? You will have to execute below commands and provide us the resulting *.out files: # strace -o /tmp/getent_group_members.out getent group members ----- Level 1 support has never exactly impressed me 8-/. Disregarding the fact that strace on getent is only going to show a long delay between the connect to /var/lib/sss/pipes/nss and the response (it's not exactly a mystery what's taking so much time), they didn't even request the -t flag so the output won't even include timing information <sigh>. I find the most effective method to get something fixed through Red Hat support is to go fix it ourselves, get the fix accepted in the upstream project, hand it to them gift wrapped, and then have a lot of patience for the six months to a year it takes to show up in an officially supported RPM... I see you have an @redhat address :), please don't interpret my grumbling as derogatory to your company; you guys have some great engineers and do a lot of good stuff -- but your support absolutely drives me up the wall. Thanks much for your input... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson(a)csupomona.edu California State Polytechnic University | Pomona CA 91768

On 10/25/2012 9:41 AM, Dmitri Pal wrote: I assume you mean it supports connecting with authentication; considering I have provided it no credentials I would be surprised and disconcerted if it was doing anything other than an anonymous bind in my current deployment :). Ah, I did not realize that. I did try 1.9.2 and it does have drastically improved performance which should be sufficient for our deployment. I'll update our ticket and request early access to the 1.9.2 rpm for our prototyping and testing. For efficiency I'd still prefer just not processing the members, even if the delay to do so isn't unworkable. If no one else is working that RFE we might take a crack at it anyways... The case number is 00727783 if you wanted to take a look at it. Completely off-topic, but 00728171 is another example of why I bang my head against the wall when I open support tickets -- the mcelog shipped with RHEL6 is broken on amd family 15 CPU's. In the ticket, I clearly state I'm using a family 15 CPU, that it worked perfectly under RHEL5, and provide a link to an upstream patch to fix the problem. Support's response -- a link to a KB article explaining that amd family *16* CPU's are not supported by mcelog 8-/. Anyway, thanks for your help; much appreciated... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson(a)csupomona.edu California State Polytechnic University | Pomona CA 91768

On 10/25/2012 06:59 PM, Dmitri Pal wrote: I just wanted to clarify this, because I think Dmitri is confused about the situation. There is NO requirement for authentication or encryption to perform LDAP id_provider lookups. By default we will use an unencrypted simple bind, because that will work in most cases. We support using an authenticated connection (and indeed this is the default in the AD and IPA providers), but it is not required unless the LDAP server to which you are connecting has disabled or limited anonymous access. In this situation, you can use simple bind authentication to a known bind DN with a password or you can use a GSSAPI SASL bind to connect to the LDAP server. This is in contrast to when the SSSD is using LDAP as an *authentication* provider. In this situation, we mandate that the LDAP connection be protected by encryption (one of LDAPS, LDAP+TLS or LDAP+GSSAPI) before we will allow it to perform a simple-bind auth for a user. This is done because the LDAP protocol will transport the simple-bind password in plaintext over the network, thereby making it very easy to snoop passwords. pam_ldap allowed this behavior but SSSD has forbidden it and will simply refuse to even attempt the authentication if the communication channel is not encrypted. Obviously, if you are using Kerberos or another auth provider, the above is academic.

On Thu, Oct 25, 2012 at 05:43:12AM -0400, Stephen Gallagher wrote: There has also been many performance improvements done during the 1.9 development. I would suggest that you try the 1.9 packages to see if the performance is acceptable for you.

On Thu, Oct 25, 2012 at 03:21:26PM -0700, Paul B. Henson wrote: I assume you ran these with a cold cache? The other feature of the 1.9.x series is a new in-memory cache which should return results pretty much instantly.

On 10/25/2012 2:43 AM, Stephen Gallagher wrote: Cool. Is anybody actively working/planning to work on this? I notice it is currently owned by "somebody" :). We're fairly hands on, if nobody else is currently working on this we might take a look at it. initgroups() isn't a problem; there's no noticeable delay logging in. But I don't think I can reasonably prevent people from running 'id -a' (-G only provides less than informative gids), or even just 'ls -l' on an object owned by one of the large groups... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson(a)csupomona.edu California State Polytechnic University | Pomona CA 91768

On Thu, Oct 25, 2012 at 03:13:17PM -0700, Paul B. Henson wrote: Nobody is working on that as far as I know. We would certainly welcome patches, feel free to visit the #sssd channel on Freenode. Most of us hang around there -- some of the SSSD developers are in the EU timezones, some are in the US, so there would be a person to answer a question pretty much all the time. Don't hesitate to ask there on the sssd-devel mailing list! A good place to start would be the "Contribute" page: https://fedorahosted.org/sssd/wiki/Contribute There's also an assorted collection of developer-oriented tips: https://fedorahosted.org/sssd/wiki/DevRes