Slave SASL Cannonicalize always returns root?

[johnh@primebuchholz.com]

Greetings, 

I've been working on this particular problem for a week now, and can't 
seem to find a resolution in the list archives/docs/faq, or through a 
great deal of testing and experimentation.

I have two openldap 2.2.13 servers.  For authentication, I'm using MIT 
Kerberos/Cyrus SASL GSSAPI.  All LDAP connections are TLS.

Binding to the master or slave works fine. 

The problem is that when slurpd tries to send changes to the slave, the 
slave always returns a referral.  Here's the relevant sections from my 
slapd.conf:

----------8<----------
Master:

replogfile      /var/lib/ldap/master-slapd.replog

replica host=my-ldap2.mydomain.com:389
        tls=yes
        binddn="cn=Replicator,dc=mydomain,dc=com"
        bindmethod=sasl
        saslmech=GSSAPI

# Set Kerberos Realm
sasl-realm      MYDOMAIN.COM

# Ensure GSSAPI is Used
sasl-secprops noanonymous,noplain,noactive

# Map SASL authentication DNs to LDAP DNs

sasl-regexp
        uid=Replicator,cn=mydomain.com,cn=gssapi,cn=auth
        cn=Replicator,dc=mydomain,dc=com
----------8<----------
Slave:

(same sals-regexp as above)

updatedn "cn=Replicator,dc=mydomain,dc=com"
updateref ldap://my-ldap1.mydomain.com/

----------8<----------

...And here is the section from the slave's debug output that I think 
shows the problem:

>>> dnPrettyNormal: <cn=Replicator,dc=mydomain,dc=com>
=> ldap_bv2dn(cn=Replicator,dc=mydomain,dc=com,0)
<= ldap_bv2dn(cn=Replicator,dc=mydomain,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=Replicator,dc=mydomain,dc=com,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=replicator,dc=mydomain,dc=com,272)=0
<<< dnPrettyNormal: <cn=Replicator,dc=mydomain,dc=com>, 
<cn=replicator,dc=mydomain,dc=com>
do_sasl_bind: dn (cn=Replicator,dc=mydomain,dc=com) mech GSSAPI
conn=0 op=3 BIND dn="cn=Replicator,dc=mydomain,dc=com" method=163
==> sasl_bind: dn="cn=Replicator,dc=mydomain,dc=com" mech=<continuing> 
datalen=65
SASL Canonicalize [conn=0]: authcid="root"
slap_sasl_getdn: id=root [len=4]
slap_sasl_getdn: u:id converted to uid=root,cn=GSSAPI,cn=auth
>>> dnNormalize: <uid=root,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=root,cn=GSSAPI,cn=auth,0)
<= ldap_bv2dn(uid=root,cn=GSSAPI,cn=auth,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=root,cn=gssapi,cn=auth,272)=0
<<< dnNormalize: <uid=root,cn=gssapi,cn=auth>
==>slap_sasl2dn: converting SASL name uid=root,cn=gssapi,cn=auth to a DN
slap_sasl_regexp: converting SASL name uid=root,cn=gssapi,cn=auth
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=0]: slapAuthcDN="uid=root,cn=gssapi,cn=auth"
SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such file 
or directory
SASL proxy authorize [conn=0]: authcid="root" authzid="root"
conn=0 op=3 BIND authcid="root"
SASL Authorize [conn=0]:  proxy authorization allowed
send_ldap_sasl: err=0 len=-1
send_ldap_response: msgid=4 tag=97 err=0
ber_flush: 14 bytes to sd 12
  0000:  30 0c 02 01 04 61 07 0a  01 00 04 00 04 00         0....a........
tls_write: want=90, written=90
  0000:  17 03 01 00 20 53 51 18  a7 77 27 f0 f5 86 04 2d   .... 
SQ..w'....-
  0010:  f4 4f aa 69 dd 5a 93 64  45 a2 7a ea 79 65 b3 9b .O.i.Z.dE.z.ye..
  0020:  1e 44 eb c9 22 17 03 01  00 30 a0 fc 25 10 6a f0 .D.."....0..%.j.
  0030:  fa 01 1d 21 c2 14 26 29  94 29 54 64 01 c4 01 93 ...!..&).)Td....
  0040:  8a 2d eb 0f 99 6d d2 e4  1b 19 81 36 f9 31 9d 00 .-...m.....6.1..
  0050:  91 53 d5 56 84 38 00 0b  7b f9                     .S.V.8..{.
ldap_write: want=14, written=14
  0000:  30 0c 02 01 04 61 07 0a  01 00 04 00 04 00         0....a........
<== slap_sasl_bind: rc=0
conn=0 op=3 BIND dn="uid=root,cn=gssapi,cn=auth" mech=GSSAPI ssf=56
do_bind: SASL/GSSAPI bind: dn="uid=root,cn=gssapi,cn=auth" ssf=56

...It then continues to try to bind as root, which obviously isn't my 
updatedn, and hence, a referral was returned.

I have tried setting authcId and authzId.  Setting authcId has no effect, 
debug logging still shows authcId is root.  Setting authzId has an 
interesting effect - the authzId string in the debug log has trailing 
garbage characters, and causes a sasl auth failure.

Any ideas?  Can I provide any more info?

Thanks for any help,

-John