Dear Thierry, Thank you for your quick reply. We are in progress of getting the support contract arranged. It would be of great help if you can file a ticket in the mean time. If you can send the ticket number, then I will refer to that when support is in place. In the mean time, do you know any kind of work around? We currently have a connector looking in the changelog, filtering on the tree of change. We are unable to distinct between the two subsequent entries, so one dirty hack I was thinking of was removeing the attribute from the schema. That will probably give some other issues and is far from ideal. In the mean time I will look inside i f something can be done in terms of interpretation of the changes. Thank you very much for your help! Kind regards, Vincent On Mon, May 27, 2013 at 11:15 AM, thierry bordaz <tbordaz@xxxxxxxxxx> wrote: > On 05/24/2013 11:29 PM, Vincent Gerris wrote: > > Hi Thierry, > > Agreed that it might be handy, but we have no password policy enabled. > Thus, these actions should not be enabled imho. > Any way to disable it? Thanks, > > > Hi Vincent, > > Unfortunately there is no switch to prevent this internal modification. > I think that most of the time passwordgraceusertime is not set, so it would > be better to trigger that update (passwordgraceusertime=0) only if we > entered in the grace period (i.e. passwordgraceusertime!=0). > I would suggest that you fill a ticket for this issue or I will fill it for > you if you can not. > > best regards > thierry > > Kind regards, > Vincent > > On 24 May 2013 19:04, "thierry bordaz" <tbordaz@xxxxxxxxxx> wrote: >> >> On 05/24/2013 04:16 PM, Vincent Gerris wrote: >> >> 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! >> >> >> Hi Vincent, >> >> During a bind you may get notified that your password is about to expire >> or already expired. >> When you receive that notification you enter into the grace period time, >> where it is a good idea to change your password. >> Of course when you change your password, you expect that this grace period >> ends and that your password follow the life time of the password policy. >> To do this, when you reset your password, there is an additional internal >> modify to reset the grace time (and possibly others password policy >> attributes). Each time the password is reset (whatever the defined password >> policy) , this attribute is also reset and I do not know how to prevent >> this. >> >> best regards >> thierry >> >> 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 >> >> > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
