Richard,
I set the nsslapd-accesslog-logbuffering as you recomended and nothing was logged on the master ldap (ServerA). So I shutdown the master ldap machine and repeat the test. The result was the same behaviour: SAMBA writes on the userpassword attribute of the dedicated consumer (ServerB). Analyzing the access log output of ServerB, there is a line that show success in an extended operation:
- 01/Apr/2010:08:36:09 -0300] conn=553 op=18 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
- [01/Apr/2010:08:36:09 -0300] conn=553 op=18 RESULT err=0 tag=120 nentries=0 etime=0
I'm attaching a file (access.log) with all operations logged during password changing.
I've enabled the audit log on the serverB too. See the result:
time: 20100401083609
dn: uid=testuser,dc=lab,dc=com
changetype: modify
replace: userpassword
userpassword: {SSHA}D4paM4WUays6uAY1fpuSKnhoQhOJqyl9hT5IBA==
-
replace: modifiersname
modifiersname: cn=server,cn=plugins,cn=config
-
replace: modifytimestamp
modifytimestamp: 20100401113609Z
-
time: 20100401083609
dn: uid=testuser,dc=lab,dc=com
changetype: modify
replace: passwordgraceusertime
passwordgraceusertime: 0
-
replace: passwordExpirationTime
passwordExpirationTime: 20100630113609Z
-
replace: passwordExpWarned
passwordExpWarned: 0
Note that all operations above were made with the master ldap offline.
Thanks,
SIEDN - Diretorio Livre
Diretorio Livre wrote:
> Hello,
> We are using FDS 1.2.0 and we are making samba integration with LDAP.
> There are two FDS servers, one (serverA) is configured as single
> master and the other (serverB) as a dedicated consumer. We're using
> the option "ldap passwd sync=yes" and pointing the ldapsam to serverB.
> When we changed the password of a user (in a Windows machine), his
> "userpassword" ldap attribute has changed in serverB(the dedicated
> consumer) instead of return referral to serverA (the master). The most
> strange is that the access log doesn't show nothing, even the correct
> error code 10 (referral). We've checked the suffix configuration in
> the serverB and the "update on referral" was selected. It seems to us
> that SAMBA found a way to ignore the "update on referral" and made the
> modifications on the consumer. //Anybody has experiencied such behaviour?
Note that the access log is buffered, so operations may take a while
before they are flushed to disk. You can change this behavior by
setting nsslapd-accesslog-logbuffering: off in cn=config (but note that
this may impact performance in production environments).
Can you post relevant excerpts from the access log of the dedicated
consumer showing the sequence of operations for
the password change?
Have you checked the access log of the master?
>
> Steps to reproduce the behaviour
> - Configure two LDAP servers (one as single master and the other as
> dedicated consumer).
> - Configure replication between the two servers above.
> - Install SAMBA (we are using version 3.3.2 or 3.4.7).
> - Configure smb.conf with the following parameters:
> -- the ldapbackend pointing to the dedicated consumer server.
> -- ldap passwd sync=Only.
> -- ldap ssl = start tls (it's necessary).
>
>
> Thanks in advance,
> --
> SIEDN - Diretorio Livre
> "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilizaç
ão desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
>
> "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
>
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedor
aproject.org/mailman/listinfo/389-users