[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [Fwd: Re: Ang. RE: Bdb defaults - WAS: problem importing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pierangelo Masarati wrote:
|>Pierangelo Masarati wrote:
|>
|>| This is another issue. please use the ITS if you think there's a bug.
|>| Note that this part of ACLs has been the subject of a debate recently;
|>| global scope ACLs are supposed to behave as they used to be from all
|>| times; only, they are evaluated AFTER those database specific; so if you
|>| have something like
|>|
|>| <slapd.conf>
|>| # ...
|>| access to attrs=userpassword
|>| by * =x
|>|
|>| database xxx
|>| # ...
|>| access to *
|>| by * read
|>| </slapd.conf>
|>|
|>| then of course the global rule will never be used. I'm positive
|>| the behavior didn't change; if it did, then it's an error and deserves
|>| an ITS.
|>
|>Hmm, how about a configuration with a global ACL like:
|>
|># 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=.+,?)+$$"
|> attrs=lmPassword,ntPassword,sambaLMPassword,sambaNTPassword,userPassword
|>~ 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
|
|
| what if one doesn't load samba.schema? Moot point: your package will
| distribute samba.schema as well;
Yep. (you can see where I started off in authentication etc ...).
| but since it's not standard track
| (no RFC making it commonly accepted by ietf) openldap is not likely
| to distribute it.
Nor kerberosobject, nor dnszone, nor one for sudo, nor the one for
mod_cfg_ldap ...
| This is why your package is more user-friendly than
| openldap, no doubt.
|
Well, I prefer to compete with other distro's than the upstream software
(which I prefer to cooperate with ...).
| A more sophisticated solution would be:
|
| access to dn.regex="^(.+,)?ou=[^,]+,(dc=[^,]+)+$"
| attrs=userPassword@@SEP@@@@SAMBAPWD@@
| by self =xw
| by group.expand="cn=Domain Controllers,ou=Groups,$2" write
| by anonymous auth
| @@BYREPLICATOR@@
|
| and have it processed by a m4 (or even a sed) to expand @@SAMBAPWD@@ and
| @@REPLICATOR@@ respectively if samba has been selected and the file is
| destined to a replica... we did something like this for a customer who
| wanted to be able to reconfigure the system at a glance by simply
| answering a few questions; then the site administrators started makeing
| changes manually instead of changing the template and running the macro
| processor, but that's a completely different story...
|
Well, I'm trying to avoid a Kolab-style template-based setup where you
can't make minor changes the way the documentation tells you (and no, I
don't run sendmail anywhere ;-)).
But, the problem is that slapd.conf is a bit to complex to parse at
present (I don't see that something like perl-Libconf - will be able to
support it any time soon), so I might just look at having a "wizard"
which only does initial setup from a seperate template (and warn the
user to taht effect).
| note that by * none is implied (stupid defaults!)
It is now (wasn't on 2.0.x), which is probably a good thing, it may
actually force users to look at ACLs ...
| and the rootdn by
| definition doesn't even run thru ACL evaluation... answered tons of times,
| please test if you don't trust me!
|
|
|>Then, a database definition like:
|>directory /var/lib/ldap
|>
|>...
|>
|>access to *
|>~ by dn.exact="uid=root,ou=People,dc=example,dc=com" write
|>~ by group="cn=Replicator,ou=Group,dc=example,dc=com" write
|>~ by * read
|>
|>Now, if we have the final rule "by * read", then we aren't protecting
|>the password, and if we have "by * none", then we can't do anonymous
|>auth or let users change their passwords. Catch 22.
|>
|>Global ACLs should (IMHO) be global ... otherwise they are useless (at
|>least if you have a replica).
|
|
| seriously, I really don't understand this replica issue;
| what's the difference between a master and a replica?
The replica has to have an ACL allowing the replicadn configured on the
master to write to all entries in the DIT it will recieve mods for (at
least, in my experience/testing). I guess one could use a "break"
statement here though (which I will test when I can), which I hadn't
considered.
| I haven't ever seen such a different behavior in terms
| of ACL evaluation...
|
(without a break statement) It's impossible to have useful global ACLs
with a database-specific ACL that gives the replicadn write access
(unless I've made a mistake, and unfortuately I can't test now since my
master OpenLDAP server is at home ...).
|
|>If global ACLs are processed first, then they can be generic enough for
|>most purposes, and database-specific ACLs can tighten up the last bits.
|>But, if they are processed last, they are either used (with no
|>customisation available), or they aren't.
|>
|>Maybe there are counter-arguments?
|
|
| let's reverse your sentence: if global acls are processed first, either
| they're too global, and then they catch all, so database specific rules
| never get processed, or they are too specific, so they should really stay
| with the database. If you have just one database, it really does not make
| any difference (well, except for rootDSE), and I guess you don't have more
| than one, otherwise all this talking about defaults is really pointless,
| because 99% of the installations need just one.
But, do I want to have a template-based setup, or do I want to cater to
a newbie admin who just want to set his basedn,set his rootpw, and
migrate his accounts from passwd files?
IMHO, the second case is better than the first.
|
| If you look at HEAD code, there's something that will make you happy: ACLs
| are tested for scope, and those that are out of scope (e.g. "access to *"
| in a database) issue a warning, to inform admins that their ACL is likely
| to be inappropriate or to hide a more specific one (e.g. a global rule).
| This is simply a warning, because many times we want rules to be a bit
| broader, and because this would break the usual "access to *" final rule
| and the like in most of the installations (at least that minority that
| make use of ACLs, according to your experience).
;-).
| This is a completely
| different point, and I don't know if this test will ever make into
| release, because it really tricks people;
I'll see if I can give it a test and give you some feedback in that regard.
| I just added this note to show
| you that ACL issues and in general user friendliness is something we do
| consider and care about, we're not just "sitting arrogantly on our
| positions" ;) From our perspective (I guess the most of us) flexibility
| is the key issue, because openldap must be able to adapt to a wide variety
| of cases, and let me tell that in my limited experience as a consultant I
| really had to face a lot of unusual situations. The drawback is that the
| software doesn't appear to have safe defaults; I'm really sorry about
| that, and I hope that at some point ends will meet.
Hmm, yes, Mandrake prefers to default to relatively safe but generally
useable defaults (for example ssh set to reject password auth for root,
but allow root login with a key unless the "security level" has been
changed).
I've been trying to provide at least some safe defaults (while trying to
ensure that the user doesn't fill up filesystems with obsolete
transaction logs, and that even if they haven't read all the Berkeley DB
docs before some failure they might actually be able to use them to
recover etc. etc. etc.).
Regards,
Buchan
- --
Buchan Milne Senior Support Technician
Obsidian Systems http://www.obsidian.co.za
B.Eng RHCE (803004789010797)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAz17prJK6UGDSBKcRAhk9AKCuiNLTNepv767aprIXQPYmlkVkLQCfVI2I
7JhqxD0WxIBsW0JMqnidoiE=
=4ehP
-----END PGP SIGNATURE-----