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

Re: Ang. RE: Bdb defaults - WAS: problem importing entries.

Hash: SHA1

Quanah Gibson-Mount wrote:
| --On Tuesday, June 15, 2004 4:21 PM +0200 Buchan Milne
| <bgmilne@obsidian.co.za> wrote:
|> # Protect passwords, using a regex so we can have generic accounts with
|> # write access
|> # Openldap will not authenticate against non-userPassword attributes
|> # but we would have to duplicate most rules ...
|> access to dn="(.+,)?,ou=.+,(dc=.+,?)+$$"
|> ~        by self write
|> ~        by dn="uid=root,ou=People,$2" write
|> ~        by group="cn=Domain Controllers,ou=Group,$2" write
|> ~        by anonymous auth
|> ~        by * none
| Several problems here:
| 1) It makes assumptions about where the ldap database is installed.

I don't see how you get there ...

| 2) It makes assumptions about the underlying schema's that are loaded.

My right, since the file that includes the ACLs includes the required
schemas (and we ship up-to-date schemas).

I had actually considered moving the ACLs and schema inclusions into
seperate include files (ie so including /etc/openldap/slapd-samba.conf
would have samba-relevant ACLs and include the samba schema).

| 3) It makes assumptions about the data loaded.

Sure, since the primary use of our OpenLDAP packages is for
nss_ldap/pam_ldap/samba use, and the provided tools will populate the
database as such (and if the user wants something else, they will need
to customise all affected scripts/configs anyway).

| For example, our database is in /db

I don't see how this has any bearing though .... since the whole point
of this post was to show that global ACLs seem useless - the "directory"
~ entry was shown to indicate that everything after it was in a database
definition. All configurations/scripts we include make no assumptions
about the location of the DBs (they just assume all "directory" and
"database" defintions are in the slapd.conf and not in included files).

| For example, we do not populate userPassword.  There is no reason to, as
| everything is done via SASL/GSSAPI with K5.

Sure, but any case where it is populated you most likely will want it
protected sanely by default.

At present, K5 is even more effort to get working ... and currently (due
to limited client-side support and a number of server-side package that
also lack feature complete implementations) of limited use to the
typical "target market" of Mandrake's openldap packages (we assume in
general that an installation as large as yours will be doing a lot of
customisation anyway, but we don't assume that for a 50-1000 user
installation which is where Unix is currently at a large disadvantage
compared to Win2k{,3}/AD).

| OpenLDAP is a massively flexible piece of software.  So are the
| underlying software components that plug in.  I think the premise that a
| person can just install and go is flawed, and I think the premise that
| people can just "set up" OpenLDAP while skipping on the documentation is
| flawed as well.

But, it seems that the time spent on reading the docs + time spent
implementing is much higher for openldap than many other projects.

| The quantity and quality of the documentation available
| in the FAQ, Admin guide, and man pages has increased substantially since
| I've been working with OpenLDAP, and I think it is more valuable to put
| energy into those areas than to try and come up with "defaults" that in
| the end are most likely to cause more confusion that in people had
| simply taken the time to read the documentation.  Of course, we live in
| a society that expects 30 second infomercials to tell them how to do
| everything, so I suppose this thread shouldn't be too surprising. ;)

Were you replying to my issue with global ACLs, or just using it as an
opportunity to criticise people who try to ship openldap packages that
work mostly out-the-box for limited supported (by me) configurations?


- --
Buchan Milne                      Senior Support Technician
Obsidian Systems                  http://www.obsidian.co.za
B.Eng                                RHCE (803004789010797)
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org