Dear All,
It this a bad ACL?:
access to dn="ou=Users,dc=suretecsystems,dc=com" by self write by users read by anonymous auth
This was working fine on 2.3.39, but after an upgrade last night "getent passwd" stopped working with error 50.
I can supply the full ACL and some sample data when I get a change.
But with loglevel 128, it looked like with was seeing "by auth" and not "by anonymous auth"
Now, when we browse our Samba PDC that worked fine on 2.3.39, we are seeing:
conn=63 fd=32 ACCEPT from IP=X.X.X.X:39211 (IP=0.0.0.0:389) conn=63 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=63 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" conn=63 op=0 RESULT tag=120 err=2 text=unsupported extended operation
and it goes very slowly.
Any ideas?
I'll obvoiusly doc this up in our migration section later.
Thanks.
Gavin Henry wrote:
Now, when we browse our Samba PDC that worked fine on 2.3.39, we are seeing:
conn=63 fd=32 ACCEPT from IP=X.X.X.X:39211 (IP=0.0.0.0:389) conn=63 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=63 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" conn=63 op=0 RESULT tag=120 err=2 text=unsupported extended operation
and it goes very slowly.
Any ideas?
That's a StartTLS request. slapd will reject that request if you didn't configure TLS certificates. Check your client config to see why it's requesting it, or your server config...
Gavin Henry escreveu:
Dear All,
It this a bad ACL?:
access to dn="ou=Users,dc=suretecsystems,dc=com" by self write by users read by anonymous auth
If a .subtree match is implied, this could be bad from a security point of view, perhaps. It allows an authenticated user to change any aspect of his/her own entry. Depending on what you have there, an user could make him/herself root for example.
Perhaps previously an unqualified "to dn" would be equal to "to dn.sub", while now it is equal to "to dn.exact"?
openldap-software@openldap.org