Hi,
I'm using luma to modify users passwords, until 389-ds-base 1.2.6 everything worked ok. but with 1.2.8.2 the updated password isn't propagating to the slaves.
However, with 389-console, passwd or even ldapmodify it works ok.
auditing the process, I found that luma deletes the userpasswd attibute and adds it again. 389-console and passwd only modifies the attribute.
I have 4 ldap servers (1 master, 3 slaves) and 1 AD server.
Is this behavior expected in 1.2.8.2?
I'm attaching audit logs for luma and passwd, for the master and one slave.
thanks
On 04/26/2011 02:30 PM, Yonathan Dossow wrote:
Hi,
I'm using luma to modify users passwords, until 389-ds-base 1.2.6 everything worked ok. but with 1.2.8.2 the updated password isn't propagating to the slaves.
However, with 389-console, passwd or even ldapmodify it works ok.
auditing the process, I found that luma deletes the userpasswd attibute and adds it again. 389-console and passwd only modifies the attribute.
I have 4 ldap servers (1 master, 3 slaves) and 1 AD server.
Is this behavior expected in 1.2.8.2?
Sounds like a dup of https://bugzilla.redhat.com/show_bug.cgi?id=695779
I'm attaching audit logs for luma and passwd, for the master and one slave.
thanks
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On Tue, 2011-04-26 at 14:31 -0600, Rich Megginson wrote:
On 04/26/2011 02:30 PM, Yonathan Dossow wrote:
Hi,
I'm using luma to modify users passwords, until 389-ds-base 1.2.6 everything worked ok. but with 1.2.8.2 the updated password isn't propagating to the slaves.
However, with 389-console, passwd or even ldapmodify it works ok.
auditing the process, I found that luma deletes the userpasswd attibute and adds it again. 389-console and passwd only modifies the attribute.
I have 4 ldap servers (1 master, 3 slaves) and 1 AD server.
Is this behavior expected in 1.2.8.2?
Sounds like a dup of https://bugzilla.redhat.com/show_bug.cgi?id=695779
thanks for the fast reply, however the problem here looks different, because in the slave we are not seeing any change. looks like the master is not sending updates when luma deletes and adds again the attribute.
Also, I tested if the password is synced to AD, and works ok when I change it with luma. The problem appears only between 389-ds servers.
greetings
On 04/26/2011 02:48 PM, Yonathan Dossow wrote:
On Tue, 2011-04-26 at 14:31 -0600, Rich Megginson wrote:
On 04/26/2011 02:30 PM, Yonathan Dossow wrote:
Hi,
I'm using luma to modify users passwords, until 389-ds-base 1.2.6 everything worked ok. but with 1.2.8.2 the updated password isn't propagating to the slaves.
However, with 389-console, passwd or even ldapmodify it works ok.
auditing the process, I found that luma deletes the userpasswd attibute and adds it again. 389-console and passwd only modifies the attribute.
I have 4 ldap servers (1 master, 3 slaves) and 1 AD server.
Is this behavior expected in 1.2.8.2?
Sounds like a dup of https://bugzilla.redhat.com/show_bug.cgi?id=695779
thanks for the fast reply, however the problem here looks different, because in the slave we are not seeing any change. looks like the master is not sending updates when luma deletes and adds again the attribute.
Also, I tested if the password is synced to AD, and works ok when I change it with luma. The problem appears only between 389-ds servers.
Does this only happen with the userPassword attribute?
greetings
On Tue, 2011-04-26 at 19:08 -0600, Rich Megginson wrote:
On 04/26/2011 02:48 PM, Yonathan Dossow wrote:
On Tue, 2011-04-26 at 14:31 -0600, Rich Megginson wrote:
On 04/26/2011 02:30 PM, Yonathan Dossow wrote:
Hi,
I'm using luma to modify users passwords, until 389-ds-base 1.2.6 everything worked ok. but with 1.2.8.2 the updated password isn't propagating to the slaves.
However, with 389-console, passwd or even ldapmodify it works ok.
auditing the process, I found that luma deletes the userpasswd attibute and adds it again. 389-console and passwd only modifies the attribute.
I have 4 ldap servers (1 master, 3 slaves) and 1 AD server.
Is this behavior expected in 1.2.8.2?
Sounds like a dup of https://bugzilla.redhat.com/show_bug.cgi?id=695779
thanks for the fast reply, however the problem here looks different, because in the slave we are not seeing any change. looks like the master is not sending updates when luma deletes and adds again the attribute.
Also, I tested if the password is synced to AD, and works ok when I change it with luma. The problem appears only between 389-ds servers.
Does this only happen with the userPassword attribute?
I tested other attributes, like cn, sn, and some attributes from a schema created by us, and they are all working. so it appears to be only userPassword with the problem.
greetings
On 04/26/2011 07:57 PM, Yonathan Dossow wrote:
On Tue, 2011-04-26 at 19:08 -0600, Rich Megginson wrote:
On 04/26/2011 02:48 PM, Yonathan Dossow wrote:
On Tue, 2011-04-26 at 14:31 -0600, Rich Megginson wrote:
On 04/26/2011 02:30 PM, Yonathan Dossow wrote:
Hi,
I'm using luma to modify users passwords, until 389-ds-base 1.2.6 everything worked ok. but with 1.2.8.2 the updated password isn't propagating to the slaves.
However, with 389-console, passwd or even ldapmodify it works ok.
auditing the process, I found that luma deletes the userpasswd attibute and adds it again. 389-console and passwd only modifies the attribute.
I have 4 ldap servers (1 master, 3 slaves) and 1 AD server.
Is this behavior expected in 1.2.8.2?
Sounds like a dup of https://bugzilla.redhat.com/show_bug.cgi?id=695779
thanks for the fast reply, however the problem here looks different, because in the slave we are not seeing any change. looks like the master is not sending updates when luma deletes and adds again the attribute.
Also, I tested if the password is synced to AD, and works ok when I change it with luma. The problem appears only between 389-ds servers.
Does this only happen with the userPassword attribute?
I tested other attributes, like cn, sn, and some attributes from a schema created by us, and they are all working. so it appears to be only userPassword with the problem.
Thanks. Can you please open a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=389
greetings
389-users@lists.fedoraproject.org