[mdlug] LDAP Server Question

[Adam Tauno Williams]

On Wed, 2012-07-25 at 13:07 +0000, Wojtak, Greg (Superfly) wrote:
> I've gotten just about all the pieces working and have gotten
> Unix/Linux servers to be able to authenticate against Active
> Directory.  The challenge I'm facing is that the directory is laid out
> very poorly and all searches for users need to begin at the top-level
> directory component.

That is normal for AD.  AD laid out first-and-foremost for
administrative purposes, not what-will-actually-perform-best.

> This makes for very slow login times in most cases - anywhere from 10
> seconds to a minute.  nscd and sssd seem to help a bit, but even with
> them running, logins can sometimes still be very slow.

You should have nslcd running.  You get much better performance [this is
pam/nss_ldapd rather than pam/nss_ldap].  Few connections, no weird
issues with setuid binaries, much lower memory utilization [every binary
doesn't load the LDAP libraries], and working service discovery.

Note that how glibc/libc enumerates users and groups *SUCKS*.  It just
does, period, no way around it.  nslcd + nscd help, but nothing can make
something that just sucks not suck.  The UNIX/LINUX approach to users,
groups, and permissions is tragically retarded; a legacy of a long
bygone age of stand-alone machines and vertical use-cases.  You are
trying to lay that on top of something that is flexible and well
designed, some mismatch is inevitable.

Anyway, it really shouldn't be that slow.  Possibly something on the AD
side is just wrong?  AD is no speed deamon, but it certainly shouldn't
take 60 seconds.

> Is there a way to replicate certain objects (ie users and groups) from
> one directory server (ie AD) into another (ie, OpenLDAP) and instead
> of copying the structure of the directory, replicate them into a
> structure of my choosing? That would be ideal for me, but if anyone
> else has any ideas, I'd love to hear them.

Probably.

> I think for now I'm going to continue to pursue the OpenLDAP proxy
> cache solution to see if that adds anything. That solution loses its
> appeal to me however because at that point there are so many layers of
> caching going on that I'm sure we'll start to see issues (we see them
> today just with client caching).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mdlug.org/pipermail/mdlug/attachments/20120725/a1bfdbce/attachment-0001.sig>