Actually, maybe I wasn't totally wrong. There MAY be a bug at work, = just not the one I initially thought ....

1.) Implemented your exact working example on my dev server. Worked. 2.) Implemented same example on my QA server. Worked. 3.) Implemented on a production server. Failed.

I then realized the dynlist-attrset was listed as follows:

syncrepl params accesslog params dynlist-attrset params

I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl = lines (below my indexes for this DB).

Example then worked in production.

Is THAT a bug? That its behavior changes depending on where it is placed = inside of a given 'database' section?

Thanks, sorry to keep bugging you with this ....

GUESSING what you meant above is something like this (as you keep writing things like "accesslog parameters" instead of the real thing)

<slapd.conf excerpt> database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret #null#bind on directory testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub

overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid

overlay syncprov

overlay accesslog logdb cn=log logops writes reads logold (objectclass=person)

dynlist-attrset posixGroup memberURL memberUid:uid </slapd.conf excerpt>

or any permutation of the dynlist-attrset statement, like both before overlay syncprov, or both at the end, or anywhere between "overlay syncrepl" and the last "log*" statement, I get the expected result.

So now the only way to keep this ITS open is to see your ENTIRE slapd.conf (except passwords, of course). An even better alternative would be to receive a sanitized slapd.conf, a LDIF and a search operation based on ldapsearch that clearly illustrates the issue, like what I posted a couple of postings ago.

p.