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

Activity

1. vharseko commented on Jun 1, 2026

   

   vharseko

   on Jun 1, 2026

   Member

   More actions

   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.
2. OpenIdentityPlatform

   locked and limited conversation to collaborators on Jun 1, 2026
3. vharseko

   converted this issue into a discussion #647 on Jun 1, 2026