sorry for the high traffic. discussed with some collegues and it seems the following is applicable: "It's not a bug, it's a feauture!" the attribute passwordgraceusertime is not present in the iPlanet LDAP server or perhaps not enabled by default. https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Schema_Reference/Schema_Reference-Operational_Attributes_Special_Attributes_and_Special_Object_Classes.html#passwordGrace_UserTime . So instead of filing a bug, my question is: is it possible to somehow not have this attribute reset? I couldn't find anything under password policy. Googling did not help either. Any help is greatly appreciated! On Fri, May 24, 2013 at 3:38 PM, Vincent Gerris <vgerris@xxxxxxxxx> wrote: > I verified this behaviour is still present in Fedora 389 Directory Server 1.2.6. > > On Fri, May 24, 2013 at 3:21 PM, Vincent Gerris <vgerris@xxxxxxxxx> wrote: >> Hi all, >> >> I think I found it, it seems a bug to me. >> With audit logging enabled, I noticed a difference in output in the >> output log when changing for example a fax field or the password. >> I also noticed that this is also reproducible with the 389 admin GUI. >> What I see for example with changing a fax number is: >> >> >> time: 20130524143610 >> dn: uid=********,ou=********,o=********* >> changetype: modify >> replace: telephoneNumber >> telephoneNumber: 1234 >> - >> replace: modifiersname >> modifiersname: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot >> - >> replace: modifytimestamp >> modifytimestamp: 20130524123610Z >> - >> >> When ANY modification is made where the password field is modified, I >> see something like this: >> >> time: 20130524141847 >> dn: uid=********,ou=********,o=********* >> changetype: modify >> delete: preferredLanguage >> - >> replace: userPassword >> userPassword::somelongthingjhere********************************************************* >> = >> - >> replace: modifiersname >> modifiersname: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot >> - >> replace: modifytimestamp >> modifytimestamp: 20130524121847Z >> - >> >> time: 20130524141847 >> dn: uid=********,ou=********,o=********* >> changetype: modify >> replace: passwordgraceusertime >> passwordgraceusertime: 0 >> - >> >> Note the extra time: entry. >> Apparently, this extra time enty triggers the creation of the extra >> changelog entry. >> I looked on the old iPlanet server, when a password is changed there, >> there is no second time entry. >> >> Can anyone check this on a recent 389 or RH DS? >> >> kind regards, >> Vincent >> >> >> >> On Fri, May 24, 2013 at 2:04 PM, Vincent Gerris <vgerris@xxxxxxxxx> wrote: >>> Hi Ludwig and fellow readers, >>> >>> I will do that. >>> In the mean time I did some more investigating of the access log and >>> it seems like a bug to mee. >>> It may be true that sometime triggers te bug, but this is what I see >>> in the access log: >>> [24/May/2013:12:16:48 +0200] conn=20 op=1 MOD >>> dn="uid=********,ou=*******,o=*********" >>> >>> This single MOD log entry in the access log triggers 2 changelog >>> entries with the same time step, but one with a higher numer (+1). >>> I believe the proper behaviour of the Retro Changelog Plugin schould >>> be that only 1 entry is made in the cn-changelog tree. >>> >>> We are running 9.0.0 of the Red Hat Directory Server now, perhaps this >>> is a bug that is fixed in the mean time? >>> I am now off to enable Audit logging and perhaps after that look with >>> wireshark at what happens. >>> I hope in the mean time someone can confirm this bug and maybe a solution? >>> >>> Thank you. >>> >>> Kind regards, >>> Vincent >>> >>> On Thu, May 23, 2013 at 3:22 PM, Ludwig Krispenz <lkrispen@xxxxxxxxxx> wrote: >>>> >>>> On 05/23/2013 02:22 PM, Vincent Gerris wrote: >>>>> >>>>> Hi Ludwig, >>>>> >>>>> We see the same change with a different change number. >>>>> This does not happen while using the 389-console or a tool we use to >>>>> directly connect to the directory. >>>>> When other integration tools are used that do no trigger a duplicate >>>>> entry with iPlanet, they do show a duplicate entry. >>>>> I can attach a part of the slapd access log file that records this >>>>> activity. >>>> >>>> maybe you can also turn on audit logging and see if there is a difference in >>>> the ops from different clients >>>> >>>>> We are planning a migration from iPlanet 5 to RH DS 9 and this came up >>>>> yesterday. >>>>> >>>>> Kind regards, >>>>> Vincent >>>>> >>>>> On Thu, May 23, 2013 at 9:51 AM, Ludwig Krispenz <lkrispen@xxxxxxxxxx> >>>>> wrote: >>>>>> >>>>>> What do you mean by two entries - the same change duplicate with >>>>>> different >>>>>> change numbers or an additional change logged ? >>>>>> >>>>>> Ludwig >>>>>> >>>>>> >>>>>> On 05/23/2013 08:57 AM, Vincent Gerris wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We are using Red Hat Enterprise Directory Server (which is a stable >>>>>>> 389). >>>>>>> We have been using the retro changelog plugin from the old iPlanet >>>>>>> server for synchronisation to other systems. >>>>>>> Yesterday we noticed that for some reason, when an LDAP modification >>>>>>> is made, 2 entries turn up in de changelog LDAP tree. >>>>>>> It does not seem to happen when the 389-console client is used and a >>>>>>> change is made directly to an account with it, >>>>>>> but when an LDAP modify is done, while the slapd access logs shows 1 >>>>>>> modification, the changelog has two entries. >>>>>>> This seems to be a bug. >>>>>>> >>>>>>> Does anyone know how to solve this? >>>>>>> I have not found anybody having the issue and nothing in the >>>>>>> configuration either. >>>>>>> These duplicate entries might result in performance issues on the >>>>>>> scripting side. >>>>>>> Any help is greatly appreciated! >>>>>>> >>>>>>> Kind regards, >>>>>>> Vincent >>>>>>> -- >>>>>>> 389 users mailing list >>>>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> >>>>>> >>>>>> -- >>>>>> 389 users mailing list >>>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>> >>>>> -- >>>>> 389 users mailing list >>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>>> >>>> -- >>>> 389 users mailing list >>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
