An LDAP directory can have numerous advantages over NIS. For example:
* Strong mutual authentication of client machines and LDAP servers * All network traffic and be encrypted (by mandate even) via SSL or TLS. * A rouge root on client machines cannot access user data, collect encrypted password strings for user accounts * Shadow password functionality including aging can be used
I would like to encourage Linux sysadmins to "properly" and securely setup LDAP directories as opposed to NIS.
What can be done to encourage this?
For starters, it would be nice to have a good generic LDAP directory browser/editor that was SSL/TLS enabled. RHL7.3 shipped with a decent one, GQ, but it was dropped.
The slick looking "directoryadministrator" can be used to administer an directory post-setup.
Any have other ideas?
I'll have a follow up as well.
Dax Kelson Guru Labs
On Wed, 2003-07-23 at 00:58, Dax Kelson wrote:
An LDAP directory can have numerous advantages over NIS. For example:
- Strong mutual authentication of client machines and LDAP servers
- All network traffic and be encrypted (by mandate even) via SSL or TLS.
- A rouge root on client machines cannot access user data, collect
encrypted password strings for user accounts
- Shadow password functionality including aging can be used
I would like to encourage Linux sysadmins to "properly" and securely setup LDAP directories as opposed to NIS.
What can be done to encourage this?
For starters, it would be nice to have a good generic LDAP directory browser/editor that was SSL/TLS enabled. RHL7.3 shipped with a decent one, GQ, but it was dropped.
The slick looking "directoryadministrator" can be used to administer an directory post-setup.
Any have other ideas?
could you make openldap not be incredibly slow under high load and/or large number of entries?
The problem I see with ldap-authentication backends are: 1. w/o kerberos or some other strong authenticator you'll still need an authentication system for your authentication system 2. the available ldap server for linux appears to not scale that well right now. 3. the layout of user information is not terribly obvious 4. the disaster recovery mechanism (what do you back up to make sure you can recover) isn't as well documented or as trivial to understand as NIS'
my 2c -sv
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
could you make openldap not be incredibly slow under high load and/or large number of entries?
The problem I see with ldap-authentication backends are:
- w/o kerberos or some other strong authenticator you'll still need an
authentication system for your authentication system 2. the available ldap server for linux appears to not scale that well right now. 3. the layout of user information is not terribly obvious 4. the disaster recovery mechanism (what do you back up to make sure you can recover) isn't as well documented or as trivial to understand as NIS'
my 2c -sv
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
We found that turning on nscd with openldap w/db4 had the speeds equivalent to NIS. However our ldap tables may just be lucky enough to be fast.
On Tue, 2003-07-22 at 23:15, seth vidal wrote:
On Wed, 2003-07-23 at 00:58, Dax Kelson wrote:
An LDAP directory can have numerous advantages over NIS. For example:
- Strong mutual authentication of client machines and LDAP servers
- All network traffic and be encrypted (by mandate even) via SSL or TLS.
- A rouge root on client machines cannot access user data, collect
encrypted password strings for user accounts
- Shadow password functionality including aging can be used
I would like to encourage Linux sysadmins to "properly" and securely setup LDAP directories as opposed to NIS.
What can be done to encourage this?
For starters, it would be nice to have a good generic LDAP directory browser/editor that was SSL/TLS enabled. RHL7.3 shipped with a decent one, GQ, but it was dropped.
The slick looking "directoryadministrator" can be used to administer an directory post-setup.
Any have other ideas?
could you make openldap not be incredibly slow under high load and/or large number of entries?
The problem I see with ldap-authentication backends are:
- w/o kerberos or some other strong authenticator you'll still need an
authentication system for your authentication system 2. the available ldap server for linux appears to not scale that well right now. 3. the layout of user information is not terribly obvious 4. the disaster recovery mechanism (what do you back up to make sure you can recover) isn't as well documented or as trivial to understand as NIS'
my 2c -sv
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
On Wed, 2003-07-23 at 12:15, Stephen Smoogen wrote:
We found that turning on nscd with openldap w/db4 had the speeds equivalent to NIS. However our ldap tables may just be lucky enough to be fast.
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
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:
On Wed, 2003-07-23 at 12:15, Stephen Smoogen wrote:
We found that turning on nscd with openldap w/db4 had the speeds equivalent to NIS. However our ldap tables may just be lucky enough to be fast.
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
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
On Wed, 2003-07-23 at 17:23, seth vidal wrote:
On Wed, 2003-07-23 at 12:15, Stephen Smoogen wrote:
We found that turning on nscd with openldap w/db4 had the speeds equivalent to NIS. However our ldap tables may just be lucky enough to be fast.
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.
OpenLDAP can perform massively different depending on how it tuned. Even to the order of 10x - 40x difference in performance.
OpenLDAP 2.1 uses Berkeley DB v4 backend by default. So alot of the performance tuning is really "Berkeley DB tuning", mostly in the realm of getting the DB cache size set appropriately.
Seriously, you can get very good performance out of OpenLDAP.
This tuning is NOT done inside of the OpenLDAP configuration, but at the Berkeley DB level.
You need to create a DB_CONFIG file inside of your database directory (/var/lib/ldap on RHL). If you crank up the size of the shared memory buffer pool you'll be happy. The default is 256KB!
Go read:
http://www.sleepycat.com/docs/ref/am_conf/cachesize.html http://www.sleepycat.com/docs/api_c/env_set_cachesize.html http://www.openldap.org/faq/data/cache/190.html
On Wed, Jul 23, 2003 at 06:05:58PM -0600, Dax Kelson wrote:
On Wed, 2003-07-23 at 17:23, seth vidal wrote:
On Wed, 2003-07-23 at 12:15, Stephen Smoogen wrote:
We found that turning on nscd with openldap w/db4 had the speeds equivalent to NIS. However our ldap tables may just be lucky enough to be fast.
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.
OpenLDAP can perform massively different depending on how it tuned. Even to the order of 10x - 40x difference in performance. [...] You need to create a DB_CONFIG file inside of your database directory (/var/lib/ldap on RHL). If you crank up the size of the shared memory buffer pool you'll be happy. The default is 256KB!
Go read:
http://www.sleepycat.com/docs/ref/am_conf/cachesize.html http://www.sleepycat.com/docs/api_c/env_set_cachesize.html http://www.openldap.org/faq/data/cache/190.html
Thanks a lot, this is very useful information!
I also think that ldap (user management at least) should become standard in RHL. It is possible to run all under ldap, but the ldap management tools are missing (that's easy to fix) and the standard RH user management tool should support ldap, too.
What is the status of RH tools with respect to that (redhat-config-users, useradd)? libuser was already build against ldap in RH9. Is there a chance to have more LDAP support in Cambridge?
On Thu, 2003-07-24 at 10:39, Axel Thimm wrote:
I also think that ldap (user management at least) should become standard in RHL. It is possible to run all under ldap, but the ldap management tools are missing (that's easy to fix) and the standard RH user management tool should support ldap, too.
What is the status of RH tools with respect to that (redhat-config-users, useradd)? libuser was already build against ldap in RH9. Is there a chance to have more LDAP support in Cambridge?
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.
On Thu, 2003-07-24 at 03:21, Felipe Alfaro Solana wrote:
On Thu, 2003-07-24 at 10:39, Axel Thimm wrote:
I also think that ldap (user management at least) should become standard in RHL. It is possible to run all under ldap, but the ldap management tools are missing (that's easy to fix) and the standard RH user management tool should support ldap, too.
What is the status of RH tools with respect to that (redhat-config-users, useradd)? libuser was already build against ldap in RH9. Is there a chance to have more LDAP support in Cambridge?
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.
Do you have libuser whipped into shape now?
It would great to have functioning luser* and lgroup* utilities.
Do they support startTLS?
Dax Kelson Guru Labs
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:
On Thu, 2003-07-24 at 03:21, Felipe Alfaro Solana wrote:
On Thu, 2003-07-24 at 10:39, Axel Thimm wrote:
I also think that ldap (user management at least) should become standard in RHL. It is possible to run all under ldap, but the ldap management tools are missing (that's easy to fix) and the standard RH user management tool should support ldap, too.
What is the status of RH tools with respect to that (redhat-config-users, useradd)? libuser was already build against ldap in RH9. Is there a chance to have more LDAP support in Cambridge?
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.
Do you have libuser whipped into shape now?
It would great to have functioning luser* and lgroup* utilities.
Do they support startTLS?
Dax Kelson Guru Labs
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
On Thu, 2003-08-07 at 00:05, Dax Kelson wrote:
Do you have libuser whipped into shape now?
I haven't stressed them too much, but I think they're useable.
It would great to have functioning luser* and lgroup* utilities. Do they support startTLS?
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.
Tommy McNeely wrote:
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?
No, they haven't. Edit /etc/pam.d/system-auth and change this line:
account required /lib/security/$ISA/pam_unix.so
It should read:
account sufficient /lib/security/$ISA/pam_unix.so
Simple fix, but a longstanding bug. It's bug 55193:
On Wed, Aug 06, 2003 at 06:11:23PM -0700, Gordon Messmer wrote:
No, they haven't. Edit /etc/pam.d/system-auth and change this line:
account required /lib/security/$ISA/pam_unix.so
It should read:
account sufficient /lib/security/$ISA/pam_unix.so
Hmm... I did something else (on RH8), which might not be the right way: I edited the "account [default=bad ...] ... pam_ldap.so line to the following:
account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore authinfo_unavail=ignore] /lib/security/pam_ldap.so
-
Axel Thimm -
Dax Kelson -
Felipe Alfaro Solana -
Gordon Messmer -
Jos Vos -
Lucas Albers -
seth vidal -
Stephen Smoogen -
Tommy McNeely