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 refr
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 wri
> 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"
>> co
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
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 initi
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
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