[389-users] Strange behaviour - SAMBA is writing on a Dedicated Consumer Server
Rich Megginson
rmeggins at redhat.com
Thu Apr 1 13:20:10 UTC 2010
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 at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
More information about the 389-users
mailing list