error 20 when adding entry: Duplicate value rejected for multi value attribute (with unique-attribute plugin DISABLED (default)!)

[gudtanha2]

LDAP: error code 20 - The provided LDAP attribute mobile contains duplicate values

Default 00-core.ldif is in use, which defines

attributeTypes: ( 0.9.2342.19200300.100.1.41
NAME ( 'mobile' 'mobileTelephoneNumber' ) EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
X-ORIGIN 'RFC 4524' )

So this is a multi value attribute.

Plugin : Type : enabled
-----------------------------------:---------------------------------:--------
...
UID Unique Attribute : unique-attribute : false

The UID Unique Attribute is disabled.

Nevertheless this operation fails:

May 19 00:00:00 - ERROR - Error while adding entry cn=exampleuser,ou=EXAMPLE,ou=People,dc=example,dc=com in directory :javax.naming.directory.AttributeInUseException: [LDAP: error code 20 - The provided LDAP attribute mobile contains duplicate values]; remaining name 'cn=exampleuser,ou=EXAMPLE,ou=People'
May 19 00:00:02 - ERROR - Error while synchronizing ID cn=exampleuser,ou=EXAMPLE,ou=People,dc=example,dc=com: java.lang.Exception: Technical problem while applying modifications to the destination
# Tue May 19 00:00:00
dn: cn=exampleuser,ou=EXAMPLE,ou=People,dc=example,dc=com
changetype: add
employeenumber: n/a
gender: M
telephonenumber: +0123456789
mail: redacted
....
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
registrationauthority: 1
uid: 0000000
...
ou: EXAMPLE
mobile: +1-234-567890
mobile: +1-234/567890
cn: exampleuser
...

Expected Behaviour
Entry will be added (like our previous LDAP server (389-ds) accepts this)

Additional context
OpenDJ 4.10.2 on RHEL9,.7

Am I missing a global directive?

Vote to raise the priority 🖐️

[vharseko]

Hi, thanks for the detailed report.

This is not related to the unique-attribute plugin (which controls uniqueness across entries, not within a single entry). The rejection happens in the core schema layer, and the behavior is actually compliant with the LDAP standard.

Root cause

The mobile attribute uses EQUALITY telephoneNumberMatch (per RFC 4524 / RFC 4517). The matching rule is implemented in TelephoneNumberEqualityMatchingRuleImpl.java and, per the RFC, it normalizes values by stripping every character that is not a digit before comparison:

// Iterate through the characters in the value and filter out
// everything that isn't a digit.
for (int i = 0; i < valueLength; i++) {
    final char c = valueString.charAt(i);
    if (StaticUtils.isDigit(c)) {
        buffer.append(c);
    }
}

So your two values normalize to the same key:

Raw value	Normalized
+1-234-567890	1234567890
+1-234/567890	1234567890

From LDAP's point of view these are the same phone number, hence error 20 — attribute contains duplicate values. This is the behavior mandated by X.520 / RFC 4517 for telephoneNumberMatch; 389-ds happens to be more permissive here, but OpenDJ follows the spec strictly.

There is no global directive to disable this — the duplicate check is done by the schema/core layer using the normalized value of the matching rule.

Workarounds

1. Clean up the source data (recommended). The two values really are the same number; storing both adds no information to the directory.

2. Override the mobile attribute type in a custom schema file (e.g. config/schema/99-user.ldif) to use a non-telephone matching rule, for example:

   dn: cn=schema
   changetype: modify
   delete: attributeTypes
   attributeTypes: ( 0.9.2342.19200300.100.1.41
     NAME ( 'mobile' 'mobileTelephoneNumber' )
     EQUALITY telephoneNumberMatch
     SUBSTR telephoneNumberSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.50
     X-ORIGIN 'RFC 4524' )
   -
   add: attributeTypes
   attributeTypes: ( 0.9.2342.19200300.100.1.41
     NAME ( 'mobile' 'mobileTelephoneNumber' )
     EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
     X-ORIGIN 'user defined' )
   

   With caseIgnoreMatch, +1-234-567890 and +1-234/567890 are no longer considered equal. Note: any existing equality/substring index on mobile will need to be rebuilt (rebuild-index).

3. Use a different attribute (e.g. telexNumber-style or a custom one) for storing alternative formatted representations of the same number.

Summary

The rejection is correct LDAP behavior for telephoneNumberMatch, not a bug and not something the unique-attribute plugin is involved in. Either deduplicate the values on the client side, or redefine the mobile attribute in a user schema file with a different equality rule.