2.4.6 ACLs and Extented Operations

2007-11-01 Thread Gavin Henry
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

Re: When to delete client content during RFC4533 synchronization?

2007-11-01 Thread Erik van Oosten
Thanks Howard, Your use of the words client and server seem inconsistent here. The above questions made no sense to me. Servers don't send polls. Sorry, my interpretation of RFC4533 terminology :) . What I read is that the client may select from 2 modes of operation (by providing an initial

Re: 2.4.6 ACLs and Extented Operations

2007-11-01 Thread Andreas Hasenack
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

Re: 2.4.6 ACLs and Extented Operations

2007-11-01 Thread Gavin Henry
quote who=Howard Chu 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

Re: setting up admin password on openldap

2007-11-01 Thread Naufal Sheikh
Hello, Well Finally I have got something. I have one last question though, regarding the concept, Below is the excerpt from my new slapd.conf: backend bdb database monitor databasebdb suffix o=trac rootdn cn=nsadmin,o=trac rootpw plain-text password. When I write

Re: When to delete client content during RFC4533 synchronization?

2007-11-01 Thread Howard Chu
Erik van Oosten wrote: Still, this interpretation can not be correct. When I run my sync client program against OpenLDAP (2.3.36), and then restart it after the refresh stage with the last received cookie (note: the DIT remains unchanged), the first message is exactly that SyncInfoMessage of