[389][Active Directory] Replication issue

[Moisés Barba Pérez]

Hello,

   Unfortunately in our organization we have a replication agreement
between 389 DS and an Active Directory.

   For some reason, some Active Directory admin has run a script which has
change the "givenname" and "sn" attrs (now they are in base64) and
that
change have been replicated to the 389 DS (1).

   The issue is: This changes coming from replication aren't shown in the
server logs with the AD agreement, I saw them in the access file and audit
file but from another 389 DS (2) server with multimaster replication
agreement not in the server with the AD agreement ¿Is this normal? We are
using 1.2.5 version.

 AD <=====> 389 DS (1)  <=====> 389 DS (2)

Regards,
Moses.

[Rich Megginson]

On 04/14/2014 02:49 AM, Moisés Barba Pérez wrote:
>  Hello,
>
>     Unfortunately in our organization we have a replication agreement 
>  between 389 DS and an Active Directory.
>
>     For some reason, some Active Directory admin has run a script which 
>  has change the "givenname" and "sn" attrs (now they are in base64)
> and 
>  that change have been replicated to the 389 DS (1).
>
>     The issue is: This changes coming from replication aren't shown in 
>  the server logs with the AD agreement, I saw them in the access file 
>  and audit file but from another 389 DS (2) server with multimaster 
>  replication agreement not in the server with the AD agreement ¿Is this 
>  normal? We are using 1.2.5 version. 
I don't understand what the problem is.  Can you be more specific?

>   AD <=====> 389 DS (1)  <=====> 389 DS (2)
>
>  Regards,
>  Moses.
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[Steven Crothers]

The problem is that the sn and givenName attributes contain the same
data, but the data is now in base64, so it's not human readable.

I'm not sure how to get around that myself.
Steven Crothers
steven.crothers(a)gmail.com


On Mon, Apr 14, 2014 at 9:58 AM, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
>  On 04/14/2014 02:49 AM, Moisés Barba Pérez wrote:
>
>  Hello,
>
>     Unfortunately in our organization we have a replication agreement between
>  389 DS and an Active Directory.
>
>     For some reason, some Active Directory admin has run a script which has
>  change the "givenname" and "sn" attrs (now they are in base64) and
> that
>  change have been replicated to the 389 DS (1).
>
>     The issue is: This changes coming from replication aren't shown in the
>  server logs with the AD agreement, I saw them in the access file and audit
>  file but from another 389 DS (2) server with multimaster replication
>  agreement not in the server with the AD agreement ¿Is this normal? We are
>  using 1.2.5 version.
>
>
>  I don't understand what the problem is.  Can you be more specific?
>
>
>   AD <=====> 389 DS (1)  <=====> 389 DS (2)
>
>  Regards,
>  Moses.
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[Rich Megginson]

On 04/14/2014 09:35 AM, Steven Crothers wrote:
>  The problem is that the sn and givenName attributes contain the same
>  data, but the data is now in base64, so it's not human readable. 
Is it base64 encoded in AD, or only in 389?
Have you base64 decoded one of the values to see what it is?
Is it base64 encoded as seen by ldapsearch, or is it actually base64 
encoded in the db?  Note that in LDAP (but not necessarily in AD, which 
violates several LDAP standards), if there is trailing whitespace in an 
attribute value, ldapsearch will base64 encode the value when it 
displays it, since the trailing whitespace is not "visible".

>  I'm not sure how to get around that myself.
>  Steven Crothers
>  steven.crothers(a)gmail.com
>
>
>  On Mon, Apr 14, 2014 at 9:58 AM, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
> > On 04/14/2014 02:49 AM, Moisés Barba Pérez wrote:
> >
> > Hello,
> >
> >     Unfortunately in our organization we have a replication agreement between
> > 389 DS and an Active Directory.
> >
> >     For some reason, some Active Directory admin has run a script which has
> > change the "givenname" and "sn" attrs (now they are in base64)
> and that
> > change have been replicated to the 389 DS (1).
> >
> >     The issue is: This changes coming from replication aren't shown in the
> > server logs with the AD agreement, I saw them in the access file and audit
> > file but from another 389 DS (2) server with multimaster replication
> > agreement not in the server with the AD agreement ¿Is this normal? We are
> > using 1.2.5 version.
> >
> >
> > I don't understand what the problem is.  Can you be more specific?
> >
> >
> >   AD <=====> 389 DS (1)  <=====> 389 DS (2)
> >
> > Regards,
> > Moses.
> >
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[Moisés Barba Pérez]

I think there have been a misunderstood. The problem isn't the codification.

If we change the givenname (for example) in AD then the replication
agreement between 389DS and AD writes that change in LDAP (It doesn't
matter what type of change, base64 or not), but the 389DS logs doesn't show
that "update" in the attribute.

Eventually, I look for that change in another server with multimaster
replication and I saw the change. ¿Is that normal? I mean:

AD <==========> 389 DS (1)  <==========> 389 DS (2)
make a                    Recive the change               Recive the change
from 389DS(1)
change                    but doesn't show it                and show the
change in the logs.
and sends                in his logs
it to 389DS(1)           ¿why doesn't it show
                                the change?

Regards,
Moses


2014-04-14 18:07 GMT+02:00 Rich Megginson <rmeggins(a)redhat.com&gt;:

>  On 04/14/2014 09:35 AM, Steven Crothers wrote:
>
> > The problem is that the sn and givenName attributes contain the same
> > data, but the data is now in base64, so it's not human readable.
> >
>
>  Is it base64 encoded in AD, or only in 389?
>  Have you base64 decoded one of the values to see what it is?
>  Is it base64 encoded as seen by ldapsearch, or is it actually base64
>  encoded in the db?  Note that in LDAP (but not necessarily in AD, which
>  violates several LDAP standards), if there is trailing whitespace in an
>  attribute value, ldapsearch will base64 encode the value when it displays
>  it, since the trailing whitespace is not "visible".
>
>
>
> > I'm not sure how to get around that myself.
> > Steven Crothers
> > steven.crothers(a)gmail.com
> >
> >
> > On Mon, Apr 14, 2014 at 9:58 AM, Rich Megginson <rmeggins(a)redhat.com&gt;
> > wrote:
> >
> >> On 04/14/2014 02:49 AM, Moisés Barba Pérez wrote:
> >>
> >> Hello,
> >>
> >>     Unfortunately in our organization we have a replication agreement
> >> between
> >> 389 DS and an Active Directory.
> >>
> >>     For some reason, some Active Directory admin has run a script which
> >> has
> >> change the "givenname" and "sn" attrs (now they are in
> base64) and that
> >> change have been replicated to the 389 DS (1).
> >>
> >>     The issue is: This changes coming from replication aren't shown in
> >> the
> >> server logs with the AD agreement, I saw them in the access file and
> >> audit
> >> file but from another 389 DS (2) server with multimaster replication
> >> agreement not in the server with the AD agreement ¿Is this normal? We are
> >> using 1.2.5 version.
> >>
> >>
> >> I don't understand what the problem is.  Can you be more specific?
> >>
> >>
> >>   AD <=====> 389 DS (1)  <=====> 389 DS (2)
> >>
> >> Regards,
> >> Moses.
> >>
> >>
> >> --
> >> 389 users mailing list
> >> 389-users(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >>
> >>
> >> --
> >> 389 users mailing list
> >> 389-users(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users
>

[Rich Megginson]

On 04/15/2014 03:23 AM, Moisés Barba Pérez wrote:
>  I think there have been a misunderstood. The problem isn't the 
>  codification.
>
>  If we change the givenname (for example) in AD then the replication 
>  agreement between 389DS and AD writes that change in LDAP (It doesn't 
>  matter what type of change, base64 or not), but the 389DS logs doesn't 
>  show that "update" in the attribute. 
Right.  The winsync operations are _internal_ operations.  You'll have 
to enable access logging of internal operations to see these in the 
access log.

>  Eventually, I look for that change in another server with multimaster 
>  replication and I saw the change. ¿Is that normal? I mean:
>
>  AD <==========> 389 DS (1)  <==========> 389 DS (2)
>  make a                    Recive the change               Recive the 
>  change from 389DS(1)
>  change                    but doesn't show it                and show 
>  the change in the logs.
>  and sends                in his logs
>  it to 389DS(1)           ¿why doesn't it show
>                                  the change?
>
>  Regards,
>  Moses
>
>
>  2014-04-14 18:07 GMT+02:00 Rich Megginson <rmeggins(a)redhat.com 
>  <mailto:[e-mail]>>:
>
>      On 04/14/2014 09:35 AM, Steven Crothers wrote:
>
>          The problem is that the sn and givenName attributes contain
>          the same
>          data, but the data is now in base64, so it's not human readable.
>
>
>      Is it base64 encoded in AD, or only in 389?
>      Have you base64 decoded one of the values to see what it is?
>      Is it base64 encoded as seen by ldapsearch, or is it actually
>      base64 encoded in the db?  Note that in LDAP (but not necessarily
>      in AD, which violates several LDAP standards), if there is
>      trailing whitespace in an attribute value, ldapsearch will base64
>      encode the value when it displays it, since the trailing
>      whitespace is not "visible".
>
>
>
>          I'm not sure how to get around that myself.
>          Steven Crothers
>          steven.crothers(a)gmail.com <mailto:[e-mail]>
>
>
>          On Mon, Apr 14, 2014 at 9:58 AM, Rich Megginson
>          <rmeggins(a)redhat.com <mailto:[e-mail]>> wrote:
>
>              On 04/14/2014 02:49 AM, Moisés Barba Pérez wrote:
>
>              Hello,
>
>                  Unfortunately in our organization we have a
>              replication agreement between
>              389 DS and an Active Directory.
>
>                  For some reason, some Active Directory admin has run a
>              script which has
>              change the "givenname" and "sn" attrs (now they are in
>              base64) and that
>              change have been replicated to the 389 DS (1).
>
>                  The issue is: This changes coming from replication
>              aren't shown in the
>              server logs with the AD agreement, I saw them in the
>              access file and audit
>              file but from another 389 DS (2) server with multimaster
>              replication
>              agreement not in the server with the AD agreement ¿Is this
>              normal? We are
>              using 1.2.5 version.
>
>
>              I don't understand what the problem is.  Can you be more
>              specific?
>
>
>                AD <=====> 389 DS (1)  <=====> 389 DS (2)
>
>              Regards,
>              Moses.
>
>
>              --
>              389 users mailing list
>              389-users(a)lists.fedoraproject.org
>              <mailto:[e-mail]>
>              https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>              --
>              389 users mailing list
>              389-users(a)lists.fedoraproject.org
>              <mailto:[e-mail]>
>              https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>          --
>          389 users mailing list
>          389-users(a)lists.fedoraproject.org
>          <mailto:[e-mail]>
>          https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>      --
>      389 users mailing list
>      389-users(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[Moisés Barba Pérez]

Ok. I have no problem with that, but... Shouldn't it be better behaviour to
show this changes in 389DS? At least in the audit log. Because if you are
looking for an change date or modifiers DN and you have no logs, how can
you get where the change comes from?

In my case, I am not the AD admin and I would like to probe that some
changes had been made in AD and replicated to 389DS.

Regards,
Moses.


2014-04-15 15:44 GMT+02:00 Rich Megginson <rmeggins(a)redhat.com&gt;:

>   On 04/15/2014 03:23 AM, Moisés Barba Pérez wrote:
>
>      I think there have been a misunderstood. The problem isn't the
>  codification.
>
>   If we change the givenname (for example) in AD then the replication
>  agreement between 389DS and AD writes that change in LDAP (It doesn't
>  matter what type of change, base64 or not), but the 389DS logs doesn't show
>  that "update" in the attribute.
>
>
>  Right.  The winsync operations are _internal_ operations.  You'll have to
>  enable access logging of internal operations to see these in the access log.
>
>
>
>   Eventually, I look for that change in another server with multimaster
>  replication and I saw the change. ¿Is that normal? I mean:
>
>  AD <==========> 389 DS (1)  <==========> 389 DS (2)
>   make a                    Recive the change               Recive the
>  change from 389DS(1)
>   change                    but doesn't show it                and show the
>  change in the logs.
>   and sends                in his logs
>   it to 389DS(1)           ¿why doesn't it show
>                                   the change?
>
>   Regards,
>  Moses
>
>
>  2014-04-14 18:07 GMT+02:00 Rich Megginson <rmeggins(a)redhat.com&gt;:
>
> > On 04/14/2014 09:35 AM, Steven Crothers wrote:
> >
> >> The problem is that the sn and givenName attributes contain the same
> >> data, but the data is now in base64, so it's not human readable.
> >>
> >
> >  Is it base64 encoded in AD, or only in 389?
> > Have you base64 decoded one of the values to see what it is?
> > Is it base64 encoded as seen by ldapsearch, or is it actually base64
> > encoded in the db?  Note that in LDAP (but not necessarily in AD, which
> > violates several LDAP standards), if there is trailing whitespace in an
> > attribute value, ldapsearch will base64 encode the value when it displays
> > it, since the trailing whitespace is not "visible".
> >
> >
> >
> >> I'm not sure how to get around that myself.
> >> Steven Crothers
> >> steven.crothers(a)gmail.com
> >>
> >>
> >> On Mon, Apr 14, 2014 at 9:58 AM, Rich Megginson <rmeggins(a)redhat.com&gt;
> >> wrote:
> >>
> >>> On 04/14/2014 02:49 AM, Moisés Barba Pérez wrote:
> >>>
> >>> Hello,
> >>>
> >>>     Unfortunately in our organization we have a replication agreement
> >>> between
> >>> 389 DS and an Active Directory.
> >>>
> >>>     For some reason, some Active Directory admin has run a script which
> >>> has
> >>> change the "givenname" and "sn" attrs (now they are in
> base64) and that
> >>> change have been replicated to the 389 DS (1).
> >>>
> >>>     The issue is: This changes coming from replication aren't shown in
> >>> the
> >>> server logs with the AD agreement, I saw them in the access file and
> >>> audit
> >>> file but from another 389 DS (2) server with multimaster replication
> >>> agreement not in the server with the AD agreement ¿Is this normal? We
> >>> are
> >>> using 1.2.5 version.
> >>>
> >>>
> >>> I don't understand what the problem is.  Can you be more specific?
> >>>
> >>>
> >>>   AD <=====> 389 DS (1)  <=====> 389 DS (2)
> >>>
> >>> Regards,
> >>> Moses.
> >>>
> >>>
> >>> --
> >>> 389 users mailing list
> >>> 389-users(a)lists.fedoraproject.org
> >>> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>
> >>>
> >>>
> >>> --
> >>> 389 users mailing list
> >>> 389-users(a)lists.fedoraproject.org
> >>> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>
> >> --
> >> 389 users mailing list
> >> 389-users(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
>
>
>
>  --
>  389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users
>

[Rich Megginson]

On 04/16/2014 01:21 AM, Moisés Barba Pérez wrote:
>  Ok. I have no problem with that, but... Shouldn't it be better 
>  behaviour to show this changes in 389DS? At least in the audit log. 
These changes are not showing up in the audit log?  That sounds like a 
bug, which may have been fixed after version 1.2.5

>  Because if you are looking for an change date or modifiers DN and you
>
>  have no logs, how can you get where the change comes from? 
The access log by default logs operations from _external_ clients. The 
way winsync works is that it polls AD for changes and writes them using 
_internal_ operations.  So if having winsync operations in the access 
log is critically important to you, and you can tolerate the noise of 
all of the additional internal operations, then you can enable access 
logging of internal operations.  The reason why we do not enable access 
logging of internal operations by default is that it adds a _lot_ of 
information to the access log, something that most admins do not want to 
have to sift through.

Also, if you are looking for something specific (e.g. debugging), you 
can enable the Replication error log level 
http://port389.org/wiki/FAQ#Troubleshooting

>  In my case, I am not the AD admin and I would like to probe that some 
>  changes had been made in AD and replicated to 389DS. 
See above.
>  Regards,
>  Moses.
>
>
>  2014-04-15 15:44 GMT+02:00 Rich Megginson <rmeggins(a)redhat.com 
>  <mailto:[e-mail]>>:
>
>      On 04/15/2014 03:23 AM, Moisés Barba Pérez wrote:
> >     I think there have been a misunderstood. The problem isn't the
> >     codification.
> >
> >     If we change the givenname (for example) in AD then the
> >     replication agreement between 389DS and AD writes that change in
> >     LDAP (It doesn't matter what type of change, base64 or not), but
> >     the 389DS logs doesn't show that "update" in the attribute.
>
>      Right.  The winsync operations are _internal_ operations. You'll
>      have to enable access logging of internal operations to see these
>      in the access log.
>
>
> >
> >     Eventually, I look for that change in another server with
> >     multimaster replication and I saw the change. ¿Is that normal? I
> >     mean:
> >
> >     AD <==========> 389 DS (1) <==========> 389 DS (2)
> >     make a                    Recive the change               Recive
> >     the change from 389DS(1)
> >     change                    but doesn't show it                and
> >     show the change in the logs.
> >     and sends                in his logs
> >     it to 389DS(1)           ¿why doesn't it show
> >                                     the change?
> >
> >     Regards,
> >     Moses
> >
> >
> >     2014-04-14 18:07 GMT+02:00 Rich Megginson <rmeggins(a)redhat.com
> >     <mailto:[e-mail]>>:
> >
> >         On 04/14/2014 09:35 AM, Steven Crothers wrote:
> >
> >             The problem is that the sn and givenName attributes
> >             contain the same
> >             data, but the data is now in base64, so it's not human
> >             readable.
> >
> >
> >         Is it base64 encoded in AD, or only in 389?
> >         Have you base64 decoded one of the values to see what it is?
> >         Is it base64 encoded as seen by ldapsearch, or is it actually
> >         base64 encoded in the db?  Note that in LDAP (but not
> >         necessarily in AD, which violates several LDAP standards), if
> >         there is trailing whitespace in an attribute value,
> >         ldapsearch will base64 encode the value when it displays it,
> >         since the trailing whitespace is not "visible".
> >
> >
> >
> >             I'm not sure how to get around that myself.
> >             Steven Crothers
> >             steven.crothers(a)gmail.com <mailto:[e-mail]>
> >
> >
> >             On Mon, Apr 14, 2014 at 9:58 AM, Rich Megginson
> >             <rmeggins(a)redhat.com <mailto:[e-mail]>> wrote:
> >
> >                 On 04/14/2014 02:49 AM, Moisés Barba Pérez wrote:
> >
> >                 Hello,
> >
> >                     Unfortunately in our organization we have a
> >                 replication agreement between
> >                 389 DS and an Active Directory.
> >
> >                     For some reason, some Active Directory admin has
> >                 run a script which has
> >                 change the "givenname" and "sn" attrs (now they
> are
> >                 in base64) and that
> >                 change have been replicated to the 389 DS (1).
> >
> >                     The issue is: This changes coming from
> >                 replication aren't shown in the
> >                 server logs with the AD agreement, I saw them in the
> >                 access file and audit
> >                 file but from another 389 DS (2) server with
> >                 multimaster replication
> >                 agreement not in the server with the AD agreement ¿Is
> >                 this normal? We are
> >                 using 1.2.5 version.
> >
> >
> >                 I don't understand what the problem is.  Can you be
> >                 more specific?
> >
> >
> >                   AD <=====> 389 DS (1)  <=====> 389 DS (2)
> >
> >                 Regards,
> >                 Moses.
> >
> >
> >                 --
> >                 389 users mailing list
> >                 389-users(a)lists.fedoraproject.org
> >                 <mailto:[e-mail]>
> >                 https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >                 --
> >                 389 users mailing list
> >                 389-users(a)lists.fedoraproject.org
> >                 <mailto:[e-mail]>
> >                 https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >             --
> >             389 users mailing list
> >             389-users(a)lists.fedoraproject.org
> >             <mailto:[e-mail]>
> >             https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >         --
> >         389 users mailing list
> >         389-users(a)lists.fedoraproject.org
> >         <mailto:[e-mail]>
> >         https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
> >     --
> >     389 users mailing list
> >     389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>      --
>      389 users mailing list
>      389-users(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users