Remove your dn{} line.
Sorry, which dn line do you mean?
This?
authzTo: {0}dn:*
Yeah.
No difference.
What were you hoping it would do?
On 29 Jul 2012, at 11:08, "elekktretterr@exemail.com.au" elekktretterr@exemail.com.au wrote:
No difference.
What were you hoping it would do?
Sorry, I replied in a rush!
Gavin.
I also tried to upgrade syncrepl to TLS and while replication works fine over TLS, chaining still says Strong(er) authentication is needed.
And i get
50150d47 do_bind: dn () SASL mech EXTERNAL 50150d47 ==>slap_sasl2dn: converting SASL name cn=cn\3Dreplicator,o=webgate,st=some-state,c=au to a DN 50150d47 ==> rewrite_context_apply [depth=1] string='cn=cn\3Dreplicator,o=webgate,st=some-state,c=au' 50150d47 ==> rewrite_rule_apply rule='cn=replicator' string='cn=cn\3Dreplicator,o=webgate,st=some-state,c=au' [1 pass(es)] 50150d47 ==> rewrite_context_apply [depth=1] res={0,'cn=cn\3Dreplicator,o=webgate,st=some-state,c=au'} 50150d47 slap_parseURI: parsing cn=cn\3Dreplicator,o=webgate,st=some-state,c=au ldap_url_parse_ext(cn=cn\3Dreplicator,o=webgate,st=some-state,c=au) 50150d47 >>> dnNormalize: <cn=cn\3Dreplicator,o=webgate,st=some-state,c=au> 50150d47 <<< dnNormalize: <cn=cn\3Dreplicator,o=webgate,st=some-state,c=au> 50150d47 <==slap_sasl2dn: Converted SASL name to cn=cn\3Dreplicator,o=webgate,st=some-state,c=au 50150d47 slap_sasl_getdn: dn:id converted to cn=cn\3Dreplicator,o=webgate,st=some-state,c=au 50150d47 SASL Authorize [conn=1017]: proxy authorization allowed authzDN="" 50150d47 send_ldap_sasl: err=0 len=-1 50150d47 do_bind: SASL/EXTERNAL bind: dn="cn=cn\3Dreplicator,o=webgate,st=some-state,c=au" sasl_ssf=0
ive got this on the master:
authz-policy to authz-regexp cn=replicator "cn=replicator,ou=daemons,dc=webgate,dc=net,dc=au"
"cn=replicator" is the CommonName set in the private key
I just discovered something odd.
I ran slapd -d 256 on the provider, then started the replicator, and then did ldapmodify and look what i found:
50152ae5 conn=1020 op=0 BIND dn="" method=128 50152ae5 conn=1020 op=0 RESULT tag=97 err=0 text= 50152ae5 conn=1020 op=1 MOD dn="uid=nofilter@punchyouremployer.net,ou=emails,dc=webgate,dc=net,dc=au" 50152ae5 conn=1020 op=1 MOD attr=cn 50152ae5 conn=1020 op=1 RESULT tag=103 err=8 text=modifications require authentication 50152ae5 conn=1020 op=2 UNBIND
BIND dn="" on the first line
It's using anonymous! How is this possible?
Well looks like I figured it out. In the bottom of slapo-chain man page, it says
"All URIs not listed in the configuration are chained anonymously. "
my chain-uri was "ldap://ldap.provider.net:389/"
but my updateref was ldap://ldap.provider.net
After changing chain-uri to the same as updateref, chaining with the correct binddn started to work.
This really _has_ to go into OpenLDAP FAQ
It cost 2 days of my life.
On 29 Jul 2012, at 13:42, "elekktretterr@exemail.com.au" elekktretterr@exemail.com.au wrote:
Well looks like I figured it out. In the bottom of slapo-chain man page, it says
"All URIs not listed in the configuration are chained anonymously. "
my chain-uri was "ldap://ldap.provider.net:389/"
but my updateref was ldap://ldap.provider.net
After changing chain-uri to the same as updateref, chaining with the correct binddn started to work.
This really _has_ to go into OpenLDAP FAQ
It cost 2 days of my life.
Glad you sorted it. It's in the man page what more is there to do?
The FAQ is publicly available to edit and two days isn't a lot. Look what you've learned and are now certain of!
Gavin.
openldap-technical@openldap.org
-
elekktretterr＠exemail.com.au -
Gavin Henry -
Gavin Henry