Diretorio Livre wrote:
> **
>
> 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.
>
Ok. Please file a bug at
https://bugzilla.redhat.com/enter_bug.cgi?product=389
it does not appear that the password modify extop sends back a referral
>
>
>
>
> 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
>
>
>
> "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.fedoraproject.org/mailman/listinfo/389-users
