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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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. 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@redhat.com 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@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
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@redhat.com 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@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
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@redhat.com 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@redhat.com 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@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
-- 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
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@gmail.com 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@redhat.com 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@redhat.com 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@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
-- 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
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@gmail.com 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@gmail.com 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@redhat.com 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@redhat.com 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@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
-- 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
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/... .
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@gmail.com 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@gmail.com 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@gmail.com 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@redhat.com 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@redhat.com 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@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
-- 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
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/... .
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@gmail.com 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@gmail.com 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@gmail.com 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@redhat.com 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@redhat.com 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@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
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
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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,
Kind regards, Vincent On 24 May 2013 19:04, "thierry bordaz" tbordaz@redhat.com 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/... .
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@gmail.com vgerris@gmail.com 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@gmail.com vgerris@gmail.com 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@gmail.com vgerris@gmail.com 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@redhat.com lkrispen@redhat.com 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@redhat.com lkrispen@redhat.com 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 list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
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@redhat.com mailto:tbordaz@redhat.com> 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@gmail.com> <mailto:vgerris@gmail.com> 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@gmail.com> <mailto:vgerris@gmail.com> 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@gmail.com> <mailto:vgerris@gmail.com> 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@redhat.com> <mailto:lkrispen@redhat.com> 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 Krispenzlkrispen@redhat.com mailto:lkrispen@redhat.com > 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@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
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@redhat.com 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@redhat.com 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/... .
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@gmail.com 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@gmail.com 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@gmail.com 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@redhat.com 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@redhat.com 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@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
-- 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
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 05/27/2013 12:31 PM, Vincent Gerris wrote:
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.
Hi Vincent,
I created the following ticket to track it: https://fedorahosted.org/389/ticket/47371 Note that if a defined password policy create a "grace period" , DS may update this attribute (as well as others existing in pwd policy scope). This update will be registered in retroCL so the customer application should be able to handle these internal updates.
best regards thierry
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@redhat.com 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@redhat.com 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/... .
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@gmail.com 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@gmail.com 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@gmail.com 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@redhat.com 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@redhat.com 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@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
-- 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
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org