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>
[email protected]<mailto:[email protected]>

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.

Reply via email to