Client apps are not scoped to do subtree searches from the root of the directory where the autoincrement objects live, nor do the ACLs permit it, but you knew that already.
Duplicate a race condition using the above code and you shouldn't be using LDAP in the first place.
On Tue, Nov 14, 2017 at 10:26 PM, Michael Ströder michael@stroeder.com wrote:
MJ J wrote:
You don't need a special object class or schema, you can use this: dn: cn=user,ou=increment,dc=foo,dc=bar objectClass: top objectClass: account objectClass: posixAccount
Ouch! Depending on the config of your LDAP server and client systems this is a visible user account with username 'user' and *changing* and *conflicting* uidNumber. This is bad design. No wonder if you're running into problems with nss-pam-ldapd (nslcd) or sssd later.
You have been warned.
And here is a python method to do the job for you:
def increment_uidnumber(l, base): """ Perform LDAP modify-increment operation on uidNumber tracking object """ modlist = [(ldap.MOD_INCREMENT, "uidNumber", "1")] l.modify_s("cn=user,{0}".format(base), modlist) r = l.search_s(base, ldap.SCOPE_SUBTREE, "(objectClass=posixAccount)", ['uidNumber']) next_number = r[0][1]['uidNumber'][0]
return next_numberUsing MOD_INCREMENT is good but the above read-after-write is prone to race conditions. Since you're using Python you can look at file Demo/pyasn1/readentrycontrol.py to learn how to use the PreReadControl or PostReadControl class (see also RFC 4527) for incrementing *and* reading the new ID within a single atomic modify operation.
Also note that you should only do this on a single provider or "primary" MMR-enabled provider (ITS#8757 would be nice for that).
BTW: That's how it's done in Æ-DIR but with a special object class:
https://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2Flda...
One of the unsolved problems is that IDs consumed from the pool might not really be used by the client application possibly resulting in gaps in your ID space.
Ciao, Michael.