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

Re: Overlay for applying business logic filters to LDAP modifies/deletes



Mark,

Bannister, Mark wrote:
> Do not allow more than 10% of entries underneath a given DIT to be modified
> in less than a 24 hour period

Throttling is tricky. Currently no idea besides implementing a custom overlay.

But throttling is a bad tool against real errors anyway:

1. No matter how you choose your static treshold a sync process going mad will
always cause a huge PITA.

2. Static throttling can easily hurt good sync behaviour and cause other
headaches, e.g. think of a mass deactivation needed because of a security
incident.

=> IMO it's better to raise the bar with additional constraints.

Also try to deactivate entries (invisible via ACL) instead of deleting them.
Then repairing accidently deactivated entries is less work. It's the approach
I take for almost everything in Æ-DIR [1].

[1] http://www.stroeder.com/publications.shtml#gpn15

If performance allows in your setup consider using slapo-accesslog - one of my
OpenLDAP feature favourites. Besides being mainly dedicated for delta-syncrepl
it's very useful for auditing and rolling back changes. My web2ldap shows
extra quick links when displaying a single entry and has some HTML templates
for nicer viewing.

> Entries underneath a given DIT must have a specified list of object classes
> and attributes defined

How about this approaches:

DIT content rules (most times overlooked schema feature):
http://www.openldap.org/faq/data/cache/1473.html

Andrew's poor man's DIT structure rules and nameforms with ACLs:
http://www.openldap.org/faq/data/cache/1474.html

> Do not permit modrdn under a given DIT

ACLs.

> Attribute values match a particular defined set of REs (I can do this with the constraint overlay)

Yupp, slapo-constraint is your friend. For DN references also slapo-refint
could help.

> Some critical entries cannot be modified or removed (I can do this with access control lists)

Yupp, ACLs.

> Some attributes not used in the DN must be unique (I can do this with the unique overlay)

Yupp, slapo-unique.

But be aware of slapo-unique issues:
http://www.openldap.org/its/index.cgi?findid=6825
http://www.openldap.org/its/index.cgi?findid=6916

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature