If the uidNumber attribute does not have a uniqueness constraint, the directory will accept it and write it in.
LDAP does not have the concept of 'primary keys' as such. Each entry in LDAP is 'keyed' by it's distinguished name, which is made up of the distinguished name of its parent container, and its own naming attribute (often cn). So within container "ou=container,o=company" the cn must be unique (assuming cn is the naming attribute), but in "ou=container1,o=company" you can duplicate a cn that is already used in ou=container. Unless you define a constraint against an attribute, the only thing that must be unique is the distinguished name (dn).
By default, iPlanet used to (and possibly still does - I work on a heavily customised iPlanet environment) have a uniqueness constraint on the uid attribute across the whole directory tree. If thats the case with the OP's directory environment on uidNumber, then attempting to write a uidNumber attribute that's already been used will result in a constraint violation. I would not recommend catching that error and incrementing until the error doesn't occur as an approach BTW, because LDAP is optimised for reads, not writes.
strat's approach or a SSS (see my post below) would be the most LDAP'ish. Of the two strat's is the better method.
Update:
Hmm. I'm actually not familiar w/the internals of LDAP -- i just assumed that uidNumber was a LDAP primary key (thus unique and auto-incrementing)
As per above, LDAP doesn't have the concept of primary keys, and most databases don't create numeric auto incrementing primary keys unless you tell them to. They generally have a ROWID or similar which is numeric and auto incrementing, but thats not the same thing as a primary key.
--------------------------------------------------------------
g0n, backpropagated monk
In reply to Re^2: Looking for highest uidNumber in ldap
by g0n
in thread Looking for highest uidNumber in ldap
by rlb3
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |