Hi all

1) The context My team is working on a corporate directory using Open LDAP 2.4.38, managing about 200,000 employees.

Each employee is constructed using a specific object class named ftperson, based on parent object class inetOrgPerson All the ftperson objects are are stored in an branch named ou=people .

We use the standard uid attribute for he RDN 's ftperson object to identify an employee.

So far, the full DN of an employee is something like : uid=CUID,ou=people,dc=intrannuaire,dc=orange,dc=com with CUID representing an alphanumeric string

Precision : the CUID value is precalculated and provisioned by another corporate identity management system that checks and ensures the CUID value is unique.

We have a new requirement consisting of adding an additionnal "uid" like attribute named xuid

The value of xuid will also precalculated et provisioned by the corporate identity management system that will check and ensure the xuid value is unique.

At first, we have choosen to simply add a new attribute to the ftperson object structrure using the following attribute definition : olcAttributeTypes: {76}( ORANGE-AT:77 NAME 'xuid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

2) My question We'd like to harden the xuid management policy on our Open LDAP server by adding an unicity constraint rule for the xuid attribute equivalent to a RDMS unique key index.

I've found and read several LDAP documentations including : => uid attribute définition https://ldapwiki.com/wiki/0.9.2342.19200300.100.1.1 => extented flags https://ldapwiki.com/wiki/Extended%20Flags

I've tried several configurations such as : - define xuid attribute using uid as a parent attribute type olcAttributeTypes: {76}( ORANGE-AT:77 NAME 'xuid' SUP uid EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE )

- define xuid attribute using uid as a parent attribute type with additional extended flags olcAttributeTypes: {76}( ORANGE-AT:77 NAME 'xuid' SUP uid EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE X-NDS_NAME 'uniqueID' X-NDS_LOWER_BOUND '1' X-NDS_UPPER_BOUND '64' X-NDS_PUBLIC_READ '0' X-NDS_NONREMOVABLE '0' )

Where injecting the modified configurations , the Open LDAP server seems to accept them (no error message).

When we add the xuid attribute to an existing ftperson object, it works

But the same xuid value can be set for different ftperson objects and so, the unicity constraint rule for xuid is not respected. :-(

Any idea that idea that could help to fix this issue ?

Regards

[logo Orange]http://www.orange.com/

Pascal Foulon Concepteur Développeur Responsable Technique / MOE portail Intranet France Mobile Expert technique VMPAL-E / Quartz / Web Admin / IFM / Annuaire Groupe Orange/TGI/OLS/SOFT/IDF-NANCY/DPI

fixe : +33 3 90 31 25 79 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%203%2090%2031%2025%2079 mobile : +33 6 82 57 28 73 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2082%2057%2028%2073 pascal.foulon@orange.commailto:pascal.foulon@orange.com

EDS Océane 58H « Annuaire Groupe » : BJC031 EDS Océane IFM « Intranet France Mobile » : BJC038

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.