I'm currently doing a review to see how OpenLDAP compares, *feature
wise* ATM, to other directory servers and specifically to the Sun DS -
i.e. to get a definitive list of features it's missing that Sun has and
what it has that Sun doesn't have, etc. For brevity, I haven't included
all the potentially useful features of OpenLDAP, but have just focused
on those associated with 1) RFC compliance (of which Sun may or may not
meet) and 2) features to match the Sun DS (which it would be replacing).
So far, here's what I have for OpenLDAP:
RFC 4510 (which includes 4511-4519). There was recent discussion on the
list around this, such that in some cases, not everything that changed
from 3377 (which includes 2251-2256, 2829, and 2830) to 4510 has been
updated in OpenLDAP, but I think those issues are fairly minor.
The following additional RFC's are supported in OpenLDAP:
- RFC 2247 and RFC 3088
- RFC 2696 simple paged results
- RFC 2849 ldif
- RFC 3062 password mod op
- RFC 3296 named referals, manageDSAit
- RFC 3673 All Op attrs + feature
- RFC 3687 Component matching rules
- RFC 3866 Languange tag and range
- RFC 3876 matched values control
- RFC 4370 proxy auth
- RFC 4522 binary encoding
- RFC 4523 x.509 cert schema
- RFC 4524 COSINE schema
- RFC 4525 Mod-increment
- RFC 4526 Absolute true/false filters
- RFC 4527 pre/post read control
- RFC 4528 assertion control
- RFC 4529 request attrs by objectclass
- RFC 4530 entryUUID
- RFC 4532 whoamI
- RFC 4533 Content Sync op (replication)
RFC's NOT supported are:
- RFC 2589 dds Seems with 2.4, this has gone from experimental to
- RFC 2891 server side sorting
- RFC 3671 collective attributes
- RFC 3928 LCUP mainly for updating cached addressbooks, etc - not
replication between servers
- RFC 3384 looks like just reqs for replication, not an actual
replication protocol - RFC 4533 is used instead
- RFC 3672 (subentries)
- RFC 3698 and 3727 (additional matching rules)
- RFC 3909 LDAP Cancel operation
- RFC 5020 entryDN operational attribute
(There are some other, often obscure, LDAP related RFC's that I didn't
include, but this seems to be the major/useful ones)
Other features not supported:
- VLV browse indexes (per
http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09). Not an
RFC, but supported by Sun and MS directories, and used by things like
Outlook and Solaris.
Other supported features:
- dyngroup/dynlist/memberof overlay (A much more useful feature than
Sun's groupOfURLs "dynamic" group and "roles" mechanism)
- ppolicy overlay (matches Sun DS 5.x reasonably close, but is account
lockout replicated to all servers? Sun DS 6.x claims to)
- refint overlay (similar to Sun's referential integrity plugin)
- unique overlay (similar to Sun's uniqueness plugin)
- audit and accesslog overlays, syslog logging - much more
useful/complete than Sun's access/audit/error logs.
- live acl changes via LDAP
- Per user resource limits (sizelimit, timelimit, idletimeout, etc). I
think Howard Chu said OpenLDAP has some of this, but I haven't seen any
reference to it or how to use it in the docs (does this functionality
exist, and if so, is there any documentation?)
- Tracking of last login (i.e. last successful ldap authentication)
Is this still fairly accurate?
The ones that are really problematic are the lack of:
- VLV Browse indexes
- RFC 2891 (server side sorting)
- per user/entry resources limits (if they don't exist)
Are there any unofficial updates/patches/overlays/plans for any of this
I'm doing a bit of playing with slapo-pcache and have it working
fairly well (particularly once I realised that an individual attr can
live in only one proxyattrset).
However, there's one bit that I can't get working - is there any way
to define a template that will match a search which doesn't provide an
i.e. I can see quite a few searches (presumably from amd) of the
following form (spacing and formatting changed by me to make it more
Jul 23 14:54:16 host1 slapd: conn=49 op=1
SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0
Jul 23 14:54:16 host1 slapd: query template of incoming query =
Jul 23 14:54:16 host1 slapd: QUERY NOT ANSWERABLE
Jul 23 14:54:16 host1 slapd: QUERY NOT CACHEABLE
Jul 23 14:54:16 host1 slapd: conn=49 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Note that there's no 'SRCH attr=' line.
I've tried proxyattrset of the following forms...
proxyattrset 1 *
(both of which crash slapd)
proxyattrset 1 <full list of attrs returned when none specified>
.... but this didn't work either.
Thanks in advance for any advice,
School of Informatics
University of Edinburgh
I have to handle account locking on our directory, so as to keep
accounts from people not working here anymore. On Buchan's suggestion, I
used ppolicy sofar, with pwdAccountLockedTime attribute set to
000001010000Z to lock unused account. This is really handy to handle
unix account and web applications account at once. However, they are
also some drawbacks:
- this is an operational account, thus a bit difficult to retrieve/edit
(additional search options needed)
- its locking value seems to be quite cryptic (but I maybe missed the
semantic description somewhere)
- it seems to be a binary field only (locked/unlocked), by opposition to
shadowMax which allows to set an expiration date in advance. Even a
purely cosmetic contract expiration date would be helpful here, but i
didn't found anything similar in standard schemas
- it doesn't handle easily use case where you just need to extract valid
account list (such as scan-to-emails features from copiers), excepted by
filtering on this attribute value, which isn't always possible (broken
copiers firmware, for instance)
Last issue could be workarounded by filtering on ldap side using dynamic
group I think.
So, does anyone have suggestion on how to handle this better ?
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Im using OpenLDAP 2.4.7 and using the mirrormode and syncrepl.
My setup has 2 LDAP nodes, one as master and other as slave through a VIP.
When the master goes down, the slave will become master and vice-versa.
At any point to keep both the LDAP in sync I'm using mirror mode and syncrepl.
When one node , say A is up (that is the active node) and the other node B is down, I delete some LDAP entry from node A. THen when i start node B, the slapd on node B crashes and i see a core file also.
I have attached the logs (node_A_ldap.out and node_B_ldap.out ) files.
Im using the following conf file.
index objectClass,entryCSN,entryUUID pres,eq
index mail,cn eq,sub
syncprov-checkpoint 100 10
PS: rid= 1 in both node A and node B.
provider points to the other peer node.
serverId= 1 on Node A and serverId= 2 on Node B
Is this is know bug in OpenLDAP2.4.7??
Thanks in advance for your help.
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
I haev a quick question which I haven't been able to find an answer to
in the docs:
I have a slapd master with a couple of slaves (syncrepl
refreshAndPersist). I can get updates to be diverted to the master with
the chain overlay, but as the FAQ says there'll be a small delay before
the changes are replicated back to the slaves.
Is there anyway to automatically direct subsequent reads of the changed
attributes to the master?
Else I guess I'll have to implement referral chasing logic in the client
so it doesn't try to read from the slave immediately after writing (and
getting a referral).
I have spent the last week off and on trying to figure out why my chain
overlay was not working correctly. I tried all combinations of it that
I could find and finally found out that the parser of the slapd.conf
file is picky about spacing. I was trying to make my config file look
nice by indenting the options under "overlay chain" only to find after
many frustrating hours that you cannot do that! I didn't find anywhere
that that was explicitly documented (even though all of the examples
were not formatted that way). I finally caught it when I upgraded to
2.4.7 wondering if there was a bug and slaptest gave a very unhelpful
error, but it did help me narrow it down. Hopefully this will save
someone my same frustrations.
bindmethod="simple" binddn="binduser" credentials="secret" mode="self"
chain-idassert-bind bindmethod="simple" binddn="binduser"
I have a set of 11 servers setup with syncrepl, all running openldap 2.4.6:
1 syncrepl provider, and 10 consumers.
The provider is having a hard time staying up for more than 18-24 hours at a
time - it will either stop responding, or just die. I'm working on getting
the debug log output right before it dies, but for now, about 60% of my
provider's log is filled with messages such as this:
Dec 28 15:04:15 ldapm01 slapd: slap_sl_malloc of 32 bytes failed,
Dec 28 15:04:15 ldapm01 slapd: slap_sl_malloc of 56 bytes failed,
Dec 28 15:04:15 ldapm01 slapd: slap_sl_malloc of 56 bytes failed,
The logs are quite copious, but I haven't seen anything else indicative of
an error. I've been researching for over a week, and attempting to tweak my
settings, but I can't find any data on this.
Does this have anything to do with the 'searchstack' setting? I looked in
the source code, and noticed that it didn't seem like a terrible error, but
this is the only output I have for the time being.
Any help would be greatly appreciated, as these are production machines.
If the information I provided doesn't help, please tell me what you would
need to understand the problem better.
index objectClass eq
index ou eq
index entryCSN,entryUUID eq
index uid,uidNumber,gidNumber eq
syncprov-checkpoint 100 10
checkpoint 512 5
index uid,uidNumber,gidNumber,member pres,eq
retry="10 100 30 +"
Thanks in advance!
Senior Systems Administrator
Endurance International Group
[ I posted this to the OpenLDAP tech list, and they suggested
re-posting here. It was suggested to upgrade to a newer version of
OpenLDAP, but for various reasons, upgrading to is problematic, and
I'm willing to endure an unreasonable amount of pain to try to get it
working with my ancient version. :) ]
Running OpenLDAP 2.2.19 on Darwin kernel v. 8.11.1, and when I issue:
/usr/sbin/slapcat -d 5 -v -l /Users/localadmin/Desktop/bkup.ldif
I get the following output:
slapcat shutdown: initiated
Anyone know how I can track down what's causing this segmentation fault?
it would seem as if it might be impossible/tricky to chain state related
ppolicy attribute (ex: pwdAccountLockedTime) updates of a consumer to the
master and then back down to the other consumers in OpenLDAP 2.3
Has anyone successfully done this with OpenLDAP 2.3 (2.3.39)?
Are these attributes exchanged in 2.4 in a multimaster configuration?
Looking at the debug, the update of these state attributes are updated
locally via bdb_modify_internal. I am guessing that these are not exposed to
the slapo-chain overlay as a result of that internal update.