[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Optimizing OpenLDAP pam authentication (it's very slow)



I'm posting this back to the list in the hopes that it will help
someone else with this problem in the future:

Thanks to Gary, I have an ldap that allows fast pam_ldap logins.

Here is what I had to do:
- The LDAP is loaded with the stock PADL migration scripts
- I had to add a dummy group entry that contained
  groupOfUniqueNames/uniqueMember attributes.  Without this,  
  the uniqueMember indices would not generate.
- I had to edit the core.schema to allow uniqueMember to have an
  equality index by changing this:
    attributetype ( 2.5.4.50 NAME 'uniqueMember'
		EQUALITY uniqueMemberMatch
		SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

  to this:
    attributetype ( 2.5.4.50 NAME 'uniqueMember' SUP distinguishedName )

Hopefully someone that has a deeper understanding of how nsswitch,
pam_ldap, openldap fit together can make this processes a bit more
seamless.


Thanks again to all that helped!




On Fri, Jun 01, 2001 at 09:43:55AM -0400, Gary Williams wrote:
> I would have thought so.  It may be worth trying to create
> a group that has a uniqueMember just to see if it gets
> created.  When you run the query from ldapsearch, how long
> does it take?  Can you run the server in debug mode with
> logging turned on and see where it's taking the time?  I
> really hate to ask you to debug the server, but with
> everything indexed, I don't know what would be taking so
> much time.
> 
> From: Matthew Gregg [mailto:greggmc@musc.edu]
> Sent: Friday, June 01, 2001 9:40 AM
> To: Gary Williams
> Subject: Re: Optimizing OpenLDAP pam authentication (it's very slow)
> 
> 
> My indices now look like this:
> index uid,cn,uidNumber,gidNumber,objectClass,uniqueMember,memberUid eq
> 
> I rebuilt the indices with this configuration and continue to have 
> slow logins.
> 
> Since memberUid doesn't exist in the data, should a 
> memberUid.dbb(index file) have been created in my ldap "db" directory?
> 
> Thanks again for the help.
>  
> On Fri, Jun 01, 2001 at 07:25:34AM -0400, Gary Williams wrote:
> > Why is memberUid now only a presence index?  Since the
> > filter is doing equality tests on objectClass, memberUid,
> > and uniqueMember, they all need to have equality indexes.
> > I'm not sure how smart the filter checking is, but it may
> > still be doing an exhaustive check for the memberUid now
> > since it doesn't have an equality index.  I don't know why
> > the filter checks for both, but if both are indexed
> > correctly, it shouldn't take a long time.
> > 
> > From: Matthew Gregg [mailto:greggmc@musc.edu]
> > Sent: Thursday, May 31, 2001 4:05 PM
> > To: Gary Williams
> > Subject: Re: Optimizing OpenLDAP pam authentication (it's very slow)
> > 
> > 
> > I'm starting to pull my hair out now.
> > Since I had reloaded the ldap using "memberUid's", I had to reload yet
> > again to put the "uniqueMember" attributes back, so that I could try
> > this.
> > 
> > I made the change you suggested, and guess what.. still slow.
> > I was able to create the uniqueMember equality index, tho.
> > 
> > My indices now look like:
> > index uid,cn,uidNumber,gidNumber,objectClass eq
> > index memberUid pres
> > index uniqueMember pres,eq
> > 
> > Do you think the filter nsswitch/pam_ldap is using is just plain
> > wrong:
> > (&(objectClass=posixGroup)(|(memberUid=greggmc)
> > (uniqueMember=uid=greggmc,ou=People,dc=musc,dc=edu))
> > 
> > Why both memberUid and uniqueMember?
> > 
> > 
> > On Thu, May 31, 2001 at 03:00:18PM -0400, Gary Williams wrote:
> > > Matthew,
> > > 
> > > This is cheating, but hopefully it will get you working, and that's
> > > the important thing.  I think the problem is that, even though you
> > > don't have any uniqueMember attributes on your groups, since the
> > > filter has it in there, and you don't have an equality index, the
> > > server has to do an exhaustive search.  I think if you look in
> > > core.schema and change the attribute definition for uniqueMember
> > > from:
> > > 
> > > attributetype ( 2.5.4.50 NAME 'uniqueMember'
> > > 	EQUALITY uniqueMemberMatch
> > > 	SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
> > > 
> > > to:
> > > 
> > > attributetype ( 2.5.4.50 NAME 'uniqueMember' SUP distinguishedName )
> > > 
> > > you will be able to create the equality index.  I'm only guessing
> > > as to the cause of the slow response, but if it is the index on
> > > uniqueMember, this should take care of it.  If you don't feel like
> > > trying this solely on my hunch, I understand.  Good Luck.
> > > 
> > > 
> > > Gary Williams
> > > 
> > > 
> > > From: Matthew Gregg [mailto:greggmc@musc.edu]
> > > Sent: Thursday, May 31, 2001 2:45 PM
> > > To: Michael L Torrie
> > > Cc: openldap-software@OpenLDAP.org
> > > Subject: Re: Optimizing OpenLDAP pam authentication (it's very slow)
> > > 
> > > 
> > > This is getting very frustrating.
> > > 
> > > I shut down slapd, deleted all files from the ldap db directory.
> > > Re-migrated passwd and groups using the stock PADL scripts. then used
> > > ldapadd to re-populate the ldap from the passwd and group ldifs.
> > > Tried to login from a box using the ldap and it was still SLOW.
> > > So I stopped slapd re-ran slapindex(fingers crossed), started slapd.
> > > Again tried to login still SLOW.
> > > 
> > > Base LDAP entries look like this:
> > > dn: dc=musc,dc=edu
> > > objectClass: dcObject
> > > objectClass: organization
> > > o: Medical University of South Carolina
> > > dc: musc
> > > 
> > > dn: cn=Manager,dc=musc,dc=edu
> > > objectClass: organizationalRole
> > > cn: Manager
> > > 
> > > dn: ou=People, dc=musc, dc=edu
> > > ou: People
> > > objectClass: top
> > > objectClass: organizationalUnit
> > > 
> > > dn: ou=Groups, dc=musc, dc=edu
> > > ou: Groups
> > > objectClass: top
> > > objectClass: organizationalUnit
> > > 
> > > 
> > > Passwd entries look like this:
> > > dn: uid=greggmc,ou=People,dc=musc,dc=edu
> > > uid: greggmc
> > > cn: Matthew C Gregg
> > > objectClass: account
> > > objectClass: posixAccount
> > > objectClass: top
> > > userPassword: <removed>
> > > loginShell: /bin/csh
> > > uidNumber: 4675
> > > gidNumber: 4675
> > > homeDirectory: /home/greggmc
> > > gecos: Matthew C Gregg
> > > 
> > > Group entries look like this now:
> > > dn: cn=itlab,ou=Groups,dc=musc,dc=edu
> > > objectClass: posixGroup
> > > objectClass: top
> > > cn: itlab
> > > userPassword: {crypt}*
> > > gidNumber: 1389
> > > memberUid: binzafar
> > > memberUid: jonesje
> > > memberUid: sprovero
> > > memberUid: starmerf
> > > memberUid: starmerj
> > > 
> > > My indices look like this:
> > > index uid,cn,uidNumber,gidNumber,memberUid eq
> > > index uniqueMember pres
> > > index objectClass pres,eq
> > > 
> > > What gives folks?  It still seems like the group lookup is running
> > > un-indexed.
> > > 
> > > Is anyone else on the list using OpenLDAP for pam authentication AND
> > > has a large number of user and groups entries(10K+)?
> > > 
> > > 
> > > 
> > > 
> > > On Thu, May 31, 2001 at 10:32:49AM -0600, Michael L Torrie wrote:
> > > > Okay, my ldap server is running very quickly now.  I'm using the following
> > > > indexes (I have not modified how the groups are stored from the migrate
> > > > script):
> > > > 
> > > > index uid,cn,gidNumber,uidNumber,memberUid eq
> > > > index objectClass pres,eq
> > > > 
> > > > I then ran slapindex and restart ldap.  Now when I ls -l all the user
> > > > directories, they show up right away.  Logging in via samba on a windows
> > > > machine barely touches ldap at all right now.  su'ing to a user is almost
> > > > instant.  I'm also running nscd.  Those who are playing around with index
> > > > settings, did you remember to run slapindex to generate the indexes?  Once
> > > > I did that, things are full speed now.
> > > > 
> > > > Does this help Matthew?
> > > > 
> > > > Michael
> > > > 
> > > > On Thu, 31 May 2001, Matthew Gregg wrote:
> > > > 
> > > > > I've seen that and tried that.  What that does is "and" your filter
> > > > > with the default filter.  How to change/override the default filter would be
> > > > > the trick. Right?
> > > > >
> > > > > On Thu, May 31, 2001 at 05:24:41PM +0200, GOMBAS Gabor wrote:
> > > > > > On Thu, May 31, 2001 at 11:12:38AM -0400, Matthew Gregg wrote:
> > > > > >
> > > > > > > Also, the filter that is being run is coming from nsswitch/pam_ldap.
> > > > > > > It's not something that I can configure, without some code changes.
> > > > > >
> > > > > > Yes you can. Look at the sample ldap.conf in the nss_ldap distribution
> > > > > > (the nss_base_* parameters).
> > > > > >
> > > > > > Gabor
> > > > > >
> > > > >
> > > > >
> > > > 
> > > 
> > 
> 

-- 
brought to you by, Matthew Gregg...
one of the friendly folks in the IT Lab.
--------------------------------------\
The IT Lab (http://www.itlab.musc.edu) \____________________
Probably the world's premier software development center.
Serving: Programming, Tools, Ice Cream, Seminars