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

Re: OpenLDAP - i seriously need advise

--On Wednesday, June 09, 2004 2:47 PM +0800 "Sivasakthi d/o Sivagnanam" <sakthi@digicert.com.my> wrote:

Hi Quanah,

Hi, please don't email me off of the list. If you can generate questions that are more specific like this, you'll get better responses on the list than you were getting.

OpenLDAP is it mostly implemented on UNIX environment or LINUX ?

UNIX (including Linux)

What about Windows ?

Some people do run OpenLDAP on Windows, I never have.

I thought of making the master in LINUX and the 2 slaves in win2k server.
What is the usual approach ?

I'm not sure there is a usual approach.

Stanford currently has all its OpenLDAP servers running under Solaris, and has done some experimentation with Linux. Other sites use their own mixtures.

Currently I'm doing a high level test to see if functionally its working
using a compiled version taken from Lucas website which has a windows
compiled openldap. I've managed to build the tree and did something on acl
before i read yr mail.
My current env they are using CriticalPath as the ldap server which is
expensive hence we're opting for OpenLDAP as its opensource license which
is free.
Hence if u trying accessing ldap.digicert.com.my, u may notice it has c=my
and 3 other subtree below it. The Bumi... is basically a private tree
whereby individual users can view their certs. I'm doing the same
structure for the new openldap...managed to do so far...this is my ACL
which i've configured in the slapd.conf:-
access to dn="" by * read

access to dn.subtree="o=DIGICERT SDN BHD,c=MY" by * read

access to dn.subtree="o=Digicert Sdn. Bhd.,c=MY" by * read

access to dn.base="o=Bumiputra Commerce Bank Berhad,c=MY" by * read

# access to dn.children="o=Bumiputra Commerce Bank Berhad,c=MY" by users
# read

access to dn.subtree="o=Bumiputra Commerce Bank Berhad,c=MY" by users read

is this correct ? How do I go about granting each user with a standard
password to access their entry ?

Note that ACL processing stops at the first applicable ACL. That doesn't look like it will affect you yet, but it is something to be aware of.

I don't see anything from your ACL's indicating how your users are defined in OpenLDAP, so it is fairly impossible to say what "their entry" is. If you use a SASL mechanism for authenticating the users, you can use a "sasl-regexp" to map the user's BIND to an entry that belongs to them.

For example, we use the SASL-GSSAPI method with Kerberos V. That means when I bind to OpenLDAP, my K5 principal "quanah@stanford.edu" is used to connect to the server.

A sasl-regexp line then maps "quanah@stanford.edu" to the OpenLDAP entry "uid=quanah,cn=accounts,dc=stanford,dc=edu". This does two things: (1) makes me a "user" so that ACL's like "by users read" apply, and it also makes me a have a "self" mapping, so if I say "by self write", I could write to my own entry.

generally, if you are using user/password auth (with or without a SASL mech), you need to add the password attribute to their entry, so that they can get mapped to that entry.

I'll note that:

access to dn.subtree="o=Bumiputra Commerce Bank Berhad,c=MY" by users read

means that any user who can bind can see every entry in this subtree, which is probably not what you want.


Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html