RE: (ITS#7434) idassert-bind fails after restarting slapd

[blance3459@hotmail.com]

Okay, trying again with Thunderbird since Hotmail is determined only to send
in HTML format...

Quanah,

Trying to post a reply using my Hotmail account.  Sorry for the
unreadable output previously posted.  I'm almost embarrassed to say I've
been involved in IT for over 15 years and never used a mailing list before.

Anyhow, I did download the source packages and compiled them. However,
the semester was winding down and I was under a lot of pressure to have
something completed before the end of finals week so my professor could
assign me a grade for the work I had done.  I revered back to my
previous version to to get some stuff written. Not to mention, my
algorithms professor was kicking my butt too. Will I ever "really" need
an FFT in the real world?  lol

The more I looked at what I was trying to accomplish, I realized I was
attacking the problem all wrong.  What I was being asked to do was
something more like configuring my two slapd servers to act more like
Active Directory global catalog servers. GC's utilize MM instead of
single master replication so I scrapped the SM replication design in
favor of MM.  Once this was done, I no longer needed the chaining
overlay or proxy auth.  I now have MM replication of both cn=config and
my directory data (with delta) working and my Kerberos KDC's are happy.

One thing I did find was that configuring MM replication made me learn a
little more about how to "properly" name/configure an overlay with the
syncprov and accesslog modules by digging into the test scripts.   I had
some issues with sync state on the consumers , but I found a post you
made to someone else a few years back that solved my delta replication
issue by configuring an syncprov overlay on the accesslog db.  Not sure
I remember seeing that in the Admin Guide.

Looking back at the original post I noticed the chain overlay I had
configured was dn:
olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,
cn=config.  knowing what I know now, I'm not 100% sure that was
correct.  Shouldn't that overlay have been in either config database of
my directory  or ldap backend database for the chain rather than a
"frontend"?  Just a thought I've been kicking around in my head.

Either way, I have my ldap config working.  We can either close this
issue if you'd like or leave it open and I'll attempt to confirm my
theory on the overlay not being properly located when I get a chance.
Completely your choice.

But I do have a couple questions on my MM replication of cn=config if
you want to take them.  First, does it make sense or is it possible to
do delta replication on cn=config?  The data "on the wire" seems like it
would be much smaller and less frequent than directory data so perhaps
it's not as beneficial?   Secondly, I am using a simple bind with this
replication agreement (versus sasl/gssapi and tls for my directory
data).  When configuring limits and acl's for replication of my dit, I
created a groupofnames (cn=replicators, ou=groups, dc=example,dc=net)
that has each ldap server as a member.  My thought process was that this
made the solution a bit more scalable.  As ldap servers were added to
the topology, they could be added to the group of names and
automatically be given the correct permissions an limits.  Likewise, as
server are decommissioned, they could easily be removed by deleting them
from the group and directory.   Can I use this same group of names in
cn=config replication by creating a similar limit and acl using this
group of names?  Since I am handling the formatting of the gssapi uid in
cn=config (maybe a mistake if I ever wanted to be able to handle
multiple directories/domains), can I use the gssapi authentication of
hosts in dc=example,dc=net?  Seems I should be able to since it appears
that when the authorization occurs in the database, the bind id is
assumed to be already authenticated and accepted as presented with no
further authentication taking place.  I'm thinking that so long as that
uid is formatted into a db listed in an acl, the matching access is
applied?  Am I way off base in my thinking?  Now that I have a rough
workable solution I'm just trying to pretty it up a bit and make the
design more efficient and scalable.

Thanks

Barry