I've got a little challenge...
there is an attribute in AD call msDS-KeyVersionNumber. In AD this operational attribute increments each time the unicodePwd attribute is updated. It is typically a small integer, being the number of times that the password has ever been changed.
In Samba4, we maintain this by looking into our replication metadata (replPropertyMetaData), and returning a counter that is maintained there.
I could maintain this manually from Samba's side (this is what we did in the past), but I wanted to first check if there was something already stored that I could convert.
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
I've got a little challenge...
there is an attribute in AD call msDS-KeyVersionNumber. In AD this operational attribute increments each time the unicodePwd attribute is updated. It is typically a small integer, being the number of times that the password has ever been changed.
In Samba4, we maintain this by looking into our replication metadata (replPropertyMetaData), and returning a counter that is maintained there.
I could maintain this manually from Samba's side (this is what we did in the past), but I wanted to first check if there was something already stored that I could convert.
We don't keep a counter on the LDAP side. However, the Heimdal KDC maintains the keyVersionNumber, and it seems to me that you'd have that integrated here as well.
I've got a little challenge...
there is an attribute in AD call msDS-KeyVersionNumber. In AD this operational attribute increments each time the unicodePwd attribute is updated. It is typically a small integer, being the number of times that the password has ever been changed.
In Samba4, we maintain this by looking into our replication metadata (replPropertyMetaData), and returning a counter that is maintained there.
I could maintain this manually from Samba's side (this is what we did in the past), but I wanted to first check if there was something already stored that I could convert.
If I understand correctly what you're asking for, modifications of the unicodePwd attribute should be accompanied by modify:increment of a counter. Something like:
dn: cn=someone changetype: modify replace: unicodePwd unicodePwd:: <some value> -
should be transformed into
dn: cn=someone changetype: modify replace: unicodePwd unicodePwd:: <some value> - increment: msDS-KeyVersionNumber msDS-KeyVersionNumber: 1 -
This way, the modification is atomic. As usual, this could be accomplished by stacking an overlay that intercepts modifications to specified attributes, like unicodePwd.
Can you formalize this a little bit more?
p.
On Tue, 2010-05-25 at 05:11 +0200, masarati@aero.polimi.it wrote:
I've got a little challenge...
there is an attribute in AD call msDS-KeyVersionNumber. In AD this operational attribute increments each time the unicodePwd attribute is updated. It is typically a small integer, being the number of times that the password has ever been changed.
In Samba4, we maintain this by looking into our replication metadata (replPropertyMetaData), and returning a counter that is maintained there.
I could maintain this manually from Samba's side (this is what we did in the past), but I wanted to first check if there was something already stored that I could convert.
If I understand correctly what you're asking for, modifications of the unicodePwd attribute should be accompanied by modify:increment of a counter. Something like:
dn: cn=someone changetype: modify replace: unicodePwd unicodePwd:: <some value>
should be transformed into
dn: cn=someone changetype: modify replace: unicodePwd unicodePwd:: <some value>
increment: msDS-KeyVersionNumber msDS-KeyVersionNumber: 1
This way, the modification is atomic. As usual, this could be accomplished by stacking an overlay that intercepts modifications to specified attributes, like unicodePwd.
Can you formalize this a little bit more?
That's pretty much what I was looking for. The exact semantics don't matter too much, but this I need: - a 'small' monotonically increasing increasing integer - only increases for unicodePwd, not other updates. - always strictly related to the unicodePwd value it was incremented for (as it will be used as an abstract idenifier, along with the DN/samaccountname/etc to identify the secret unicodePwd value).
Thanks,
Andrew Bartlett
On Tue, 2010-05-25 at 05:11 +0200, masarati@aero.polimi.it wrote:
I've got a little challenge...
there is an attribute in AD call msDS-KeyVersionNumber. In AD this operational attribute increments each time the unicodePwd attribute is updated. It is typically a small integer, being the number of times that the password has ever been changed.
In Samba4, we maintain this by looking into our replication metadata (replPropertyMetaData), and returning a counter that is maintained there.
I could maintain this manually from Samba's side (this is what we did
in
the past), but I wanted to first check if there was something already stored that I could convert.
If I understand correctly what you're asking for, modifications of the unicodePwd attribute should be accompanied by modify:increment of a counter. Something like:
dn: cn=someone changetype: modify replace: unicodePwd unicodePwd:: <some value>
should be transformed into
dn: cn=someone changetype: modify replace: unicodePwd unicodePwd:: <some value>
increment: msDS-KeyVersionNumber msDS-KeyVersionNumber: 1
This way, the modification is atomic. As usual, this could be accomplished by stacking an overlay that intercepts modifications to specified attributes, like unicodePwd.
Can you formalize this a little bit more?
That's pretty much what I was looking for. The exact semantics don't matter too much, but this I need:
- a 'small' monotonically increasing increasing integer
- only increases for unicodePwd, not other updates.
- always strictly related to the unicodePwd value it was incremented
for (as it will be used as an abstract idenifier, along with the DN/samaccountname/etc to identify the secret unicodePwd value).
In contrib/slapd-modules/samba4/ there's now a vernum overlay (vernum.c, *very* experimental) that:
- defines the attribute msDS-KeyVersionNumber (with some changes) as
( 1.2.840.113556.1.4.1782 NAME 'msDS-KeyVersionNumber' DESC 'in the original specification the syntax is 2.5.5.9' SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' EQUALITY integerMatch SINGLE-VALUE USAGE dSAOperation NO-USER-MODIFICATION )
I plan to define our own; name suggestions are welcome.
- expects 'unicodePwd' to be defined
- increments msDS-KeyVersionNumber any time unicodePwd is modified, or creates it with value '0' if an entry is added with unicodePwd
- "sanitizes" the database at startup, by creating msDS-KeyVersionNumber in existing entries that contain unicodePwd
I realize right now that it doesn't handle the case of a modify that actually adds the unicodePwd attribute; I'll deal with this shortly.
I plan to make both attrs configurable, so it may be useful in other cases. Right now all you need to do is instantiate the overlay
overlay vernum
and it'll use the default attrs.
p.
--On Tuesday, May 25, 2010 5:11 AM +0200 masarati@aero.polimi.it wrote:
This way, the modification is atomic. As usual, this could be accomplished by stacking an overlay that intercepts modifications to specified attributes, like unicodePwd.
Can you formalize this a little bit more?
Imagine the possibilities if you could generalize this for uidNumber's too...
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, May 25, 2010 5:11 AM +0200 masarati@aero.polimi.it wrote:
This way, the modification is atomic. As usual, this could be accomplished by stacking an overlay that intercepts modifications to specified attributes, like unicodePwd.
Can you formalize this a little bit more?
Imagine the possibilities if you could generalize this for uidNumber's too...
Maybe I misunderstood the posting but IMHO that's a different use-case: The msDS-KeyVersionNumber is per user entry and AFAICS does not have to be unique across the whole directory. IMO it's not possible to implement a directory-wide whatever-unique-ID generator without a central UID pool entry.
Ciao, Michael.
Quanah Gibson-Mount wrote:
--On Tuesday, May 25, 2010 5:11 AM +0200 masarati@aero.polimi.it wrote:
This way, the modification is atomic. As usual, this could be accomplished by stacking an overlay that intercepts modifications to specified attributes, like unicodePwd.
Can you formalize this a little bit more?
Imagine the possibilities if you could generalize this for uidNumber's too...
Maybe I misunderstood the posting but IMHO that's a different use-case: The msDS-KeyVersionNumber is per user entry and AFAICS does not have to be unique across the whole directory. IMO it's not possible to implement a directory-wide whatever-unique-ID generator without a central UID pool entry.
Yes, if I understand Quanah's point correctly, what he wants to have is already provided by rfc4525 + rfc4527: increment with pre- or post-read, to atomically increment and read a (central) counter.
p.
--On Tuesday, May 25, 2010 7:58 PM +0200 masarati@aero.polimi.it wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, May 25, 2010 5:11 AM +0200 masarati@aero.polimi.it wrote:
This way, the modification is atomic. As usual, this could be accomplished by stacking an overlay that intercepts modifications to specified attributes, like unicodePwd.
Can you formalize this a little bit more?
Imagine the possibilities if you could generalize this for uidNumber's too...
Maybe I misunderstood the posting but IMHO that's a different use-case: The msDS-KeyVersionNumber is per user entry and AFAICS does not have to be unique across the whole directory. IMO it's not possible to implement a directory-wide whatever-unique-ID generator without a central UID pool entry.
Yes, if I understand Quanah's point correctly, what he wants to have is already provided by rfc4525 + rfc4527: increment with pre- or post-read, to atomically increment and read a (central) counter.
Correct. Just something we've never implemented, but I've often seen requested. ;)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Andrew Bartlett -
Howard Chu -
masarati＠aero.polimi.it -
Michael Ströder -
Quanah Gibson-Mount