12:53 p.m.
Looking at
http://www.openldap.org/lists/openldap-software/200701/msg00149.html
and
http://www.openldap.org/lists/openldap-software/200704/msg00050.html
it would seem as if it might be impossible/tricky to chain state related
ppolicy attribute (ex: pwdAccountLockedTime) updates of a consumer to the
master and then back down to the other consumers in OpenLDAP 2.3
Has anyone successfully done this with OpenLDAP 2.3 (2.3.39)?
Are these attributes exchanged in 2.4 in a multimaster configuration?
Looking at the debug, the update of these state attributes are updated
locally via bdb_modify_internal. I am guessing that these are not exposed to
the slapo-chain overlay as a result of that internal update.
Thanks
benji
---
Benji Spencer
System Administrator
Ph: 312-329-2288
6:24 p.m.
Ben Spencer skrev, on 27-12-2007 21:53:
Looking at
http://www.openldap.org/lists/openldap-software/200701/msg00149.html
and
http://www.openldap.org/lists/openldap-software/200704/msg00050.html
AFAICS msg00050 has nothing to do with ppolicy, msg00149 does.
it would seem as if it might be impossible/tricky to chain state
related
ppolicy attribute (ex: pwdAccountLockedTime) updates of a consumer to the
master and then back down to the other consumers in OpenLDAP 2.3
Has anyone successfully done this with OpenLDAP 2.3 (2.3.39)?
In as much as Pierangelo says that it was, as of Jan. 18th 2007, not
possible to chain these attributes, I have to take notice of that.
However, my site's been running ppolicy in production since the
beginning of Dec. with much tweaking and experimenting before that
(different utilities and mechanisms have to be able to support ppolicy
or a corresponding alternative).
pwdAccountLockedTime specific is an attribute that "disappears" as soon
as that time is over, so I can't check that, but mention was made of
pwdChangedTime and pwdHistory.
At my site one of the chaining (slave) machines is an OL 2.3.38 Samba
PDC; I've just changed the password of a "test rabbit" user with
smbpasswd and changed it back again. smbpasswd respects referrals,
doesn't chain. I see clearly (with GQ, a GUI) that pwdChangedTime and
pwdHistory have replicated back to the slave (and for that matter to 2
other slaves as well, that had nothing to do with the transaction). The
same happens when using the pam passwd libraries from a slave to update
the master. However, from the master's changelog I see that it wasn't
the master's accesslog that was responsible for replicating these
changes. I can only observe that these attributes are replicated, but in
as much as Pierangelo says that it's the implementor that's responsible,
let's leave it at that.
If your primary worry is that these attributes won't get replicated,
then you can put your mind at rest. For obvious reasons the whole
ppolicy thing would be pretty useless to my site if these attributes
were not replicated.
[...]
Best,
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
2:30 a.m.
In as much as Pierangelo says that it was, as of Jan. 18th 2007, not
possible to chain these attributes, I have to take notice of that.
However, my site's been running ppolicy in production since the
beginning of Dec. with much tweaking and experimenting before that
(different utilities and mechanisms have to be able to support ppolicy
or a corresponding alternative).
pwdAccountLockedTime specific is an attribute that "disappears" as soon
as that time is over, so I can't check that, but mention was made of
pwdChangedTime and pwdHistory.
pwdAccountLockedTime was only an example, though, really useful (required)
when having replicas.
At my site one of the chaining (slave) machines is an OL 2.3.38
Samba
PDC; I've just changed the password of a "test rabbit" user with
smbpasswd and changed it back again. smbpasswd respects referrals,
doesn't chain. I see clearly (with GQ, a GUI) that pwdChangedTime and
pwdHistory have replicated back to the slave (and for that matter to 2
other slaves as well, that had nothing to do with the transaction). The
same happens when using the pam passwd libraries from a slave to update
the master. However, from the master's changelog I see that it wasn't
the master's accesslog that was responsible for replicating these
changes. I can only observe that these attributes are replicated, but in
as much as Pierangelo says that it's the implementor that's responsible,
let's leave it at that.
My experience (which I am trying to validate here) is that with chaining,
the updates to the policy attributes do not get pushed up to the master.
They stay local to the instance on which the connection existed. (I have 1
master and 2 consumers -- it would be possible for all three to have
different values -- or no value at all). I wonder if what you are seeing is
more of a result of the referrals then the chaining? I could have something
messed up though also.
If your primary worry is that these attributes won't get
replicated,
then you can put your mind at rest. For obvious reasons the whole
ppolicy thing would be pretty useless to my site if these attributes
were not replicated.
The primary worry is that they do not get replicated (since I am not seeing
that). What version of OpenLDAP are you using?
Thanks
benji
9:29 a.m.
Tony Earnshaw wrote:
Ben Spencer skrev, on 27-12-2007 21:53:
> it would seem as if it might be impossible/tricky to chain state related
> ppolicy attribute (ex: pwdAccountLockedTime) updates of a consumer to the
> master and then back down to the other consumers in OpenLDAP 2.3
> Has anyone successfully done this with OpenLDAP 2.3 (2.3.39)?
In as much as Pierangelo says that it was, as of Jan. 18th 2007, not
possible to chain these attributes, I have to take notice of that.
[..]
pwdAccountLockedTime specific is an attribute that "disappears" as soon
as that time is over, so I can't check that, but mention was made of
pwdChangedTime and pwdHistory.
[..]
I see clearly (with GQ, a GUI) that pwdChangedTime and
pwdHistory have replicated back to the slave
But note that pwdChangedTime and pwdHistory are set by the DSA on the
same machine like where the password is (re)set - the master. So if you
chain the password change to the master you don't have to worry about.
But propagating pwdAccountLockedTime which might be triggered by bad
bind attempts to a slave is a different thing. I vaguely remembering
Kurt arguing against it. But don't exactly remember why (and when).
Ciao, Michael.
5815
days inactive
5816
days old
openldap-software@openldap.org
3 comments
3 participants
participants (3)
-
Ben Spencer -
Michael Ströder -
Tony Earnshaw