On Wed, 2003-07-23 at 12:15, Stephen Smoogen wrote: And to be fair - I found that it helps ldap too. but then you suffer nscd's problems of over-caching passwords with other uid information. unless you're using kerberos - and then if you are I'm not sure how much ldap saves you over nis. -sv

heh, so is that how to properly hijack a thread :) I question whether Red Hat (or linux in general) has fixed the problem that I have experienced from 7.x all the way through 9 so far where if the "ldap server" is unreachable, not even *local* users or root can login. The system hangs while looking up group information appearantly? I have seen little hacks in my bug reports, but have any of those been implemented into the mainstream yet? Dax Kelson wrote:

I've been working on replacing nis with openldap as my central authentication method. I've been working on implementing this for approximatelly 2 weeks. I was not aware that NIS was signifigantly faster then ldap. It is tricky implementing ldap, getting the server configured configured correctly, and importing the data takes effort... To reiterate setting up ldap is a pain in the ass. I go to work every day thinking, this sucks, and I hope I can get it implemented. I have been working on a ldap conversion of upwards of 30 hours, and expect finish in 50-100 hours total. Then I can test it for awhile, implement it, and then turn off NIS. As near as I understand you can configure ldap to authenticate for each connection. So a user can only get his password/username after he authenticates. Their are some trick configuration issues that if you overlook you render your ldap authentication completelly open. If users for example can change their UID then can become root. If you have it set to autocreate directories when accounts are created and you don't limit user logins to particular machines, they might be able to login to servers they shouldn't be on. Discussions on other mailing lists seem to indicate people are using ldap with millions of entries. Index it correctly, and have enough ram and you should have plenty of performance. The disaster recover seems straightforward, just slapcat the database and back up the resulting text file. I will be playing with disaster recover...so when my server dies in the distant future I will know what to do. I look forward to a number of items in ldap: Better security, users can't grab the whole password list as they currently can from NIS. SASL Encryption. Address Books for users and my MTA. redundancy, setup a backup caching server. --Luke

On Thu, 2003-08-07 at 00:05, Dax Kelson wrote: I haven't stressed them too much, but I think they're useable. I'm not sure. I just only patched some LDAP backend functions, but mainly, the LDAP module is the same as the original. I don't recall if the original LDAP module does support TLS.

On Thu, 2003-07-24 at 10:39, Axel Thimm wrote: I'm currently patching/modifying "libuser" to make it fully support LDAP. The latest version from RawHide works awfully: it tries to invoke ldap_modify_s to perform operations like adding a user or a group account, when in fact, it should use ldap_add_s. Right now, "luseradd" and "lgroupadd" are working perfectly for me. There are still some rough edges I need to fix. They need some testing also, I plan to release them for testing into rhl-beta-devel mailing list for approval.

We are using Kerberos/GSSAPI whenever possible. The places we are not.. we run into the over-caching of passwords. On Wed, 2003-07-23 at 17:23, seth vidal wrote: -- Stephen John Smoogen smoogen(a)lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka --