Hi Mark,
--On Thursday, June 06, 2019 1:12 PM +0100 Mark Cairney Mark.Cairney@ed.ac.uk wrote:
I.e., the only way you can ensure slapo-memberof will be "ok" in an replicated environment (syncrepl or delta-syncrepl) is if you can guarantee a REFRESH will never occur.
I think this was done in part to mitigate the behaviour in that ITS. If memberOf isn't compatible with syncrepl then does that mean you can't have replication and use the memberOf overlay? This would pose a problem for many medium-large installations surely? Looking back through the mailing list archive I do note a discussion of the whys and wherefores in September 2018.
Right, the primary issue is that if a server goes into REFRESH mode, the order in which the entries are sent back may not allow the slapo-memberOf overlay to rebuild the groups correctly.
The man page suggests using the dynlist overlay instead but given my limited understanding I don't see how that would work given the most common use case of the memberOf overlay is to get the group memberships when the user object is queried e.g. ldapsearch "uid=mcairney" "*" memberof
I gave some examples in https://www.openldap.org/its/index.cgi/?findid=8613. But none of it is pretty.
In general though it does seem like replication and attributes maintained locally via overlays (memberOf, ppolicy etc) are an absolute minefield!
Yes, it is. Unfortunately, Microsoft has never defined how memberOf should work in a replicated environment, and the RFC for ppolicy doesn't either. At least with ppolicy, one can configure back-ldap/slapo-chain to forward from the updates from a replica back to a provider so they get replicated out.
As I've noted a number of times on the list, overlay instantiation order is important for operation interception/processing. The syncprov overlay should be the first instantiated overlay, followed by accesslog, in a delta-syncrepl setup. In the above, this is clearly not the case.
I thought I'd seen this mentioned but wasn't 100% sure. I've now re-ordered my overlays as follows:
Great!
I would additionally note that the syncprov overlay is missing a sessionlog setting, where the default is likely much smaller than required for mitigating ITS#8125.
...and I've set olcSpSessionlog to be 500 (I'm not sure what the default is- 100?) Hopefully that's sufficient to avoid ITS#8125
It needs to be a value larger than the total number of entries in your database.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com