Solutions

The provided value cannot be parsed as a valid IA5 string because it contains an illegal character error in DS/OpenDJ (All versions)

Last updated Nov 19, 2018

The purpose of this article is to provide assistance if you encounter the following error when working with directory data: "The provided value "[value with special characters]" cannot be parsed as a valid IA5 string because it contains an illegal character "-n" that is not allowed in the IA5 (ASCII) character set". This error can also manifest in IDM/OpenIDM when used in conjunction with DS/OpenDJ.


Symptoms

This error occurs when working with directory data and typically affects the mail attribute, but can affect custom attributes. Some common scenarios are:

  • Modifying the mail attribute, for example using the ldapmodify command will give a response similar to the following:
    # The LDAP modify request failed: 21 (Invalid Attribute Syntax)
    # Additional Information:  When attempting to modify entry uid=jdoe,ou=People,dc=example,dc=com to replace the set of values for attribute mail, value "ää@example.com" was found to be invalid according to the associated syntax: The provided value "ää@example.com" cannot be parsed as a valid IA5 string because it contains an illegal character "-61" that is not allowed in the IA5 (ASCII) character set
    
  • Importing data using the import-ldif command will give a response similar to the following:
    # Entry cn=jdoe,ou=people,dc=example,dc=com read from LDIF starting at line 100 includes value "Buenos Días" for attribute customGreeting that is invalid according to the associated syntax:  The provided value "Buenos Días" cannot be parsed as a valid IA5 string because it contains an illegal character "-61" that is not allowed in the IA5 (ASCII) character set
    
  • Adding a new user (could be via another system such as IDM/OpenIDM) will result in an error similar to the following in the Access log:
    "response":{"status":"FAILED","statusCode":"21","elapsedTime":1,"elapsedTimeUnits":"MILLISECONDS","detail":"Entry "uid=jdoe,ou=People,dc=example,dc=com" contains a value "êê@example.com" for attribute mail that is invalid according to the syntax for that attribute: The provided value "êê@example.com" cannot be parsed as a valid IA5 string because it contains an illegal character "-61" that is not allowed in the IA5 (ASCII) character set"},"timestamp":"2018-11-10T12:04:53.850Z","_id":"2fff31b5-4682-4760-b32a-fbbfed6bd9ac-433"}
    

Recent Changes

The following are some example use cases of administrative changes that commonly introduce these errors:

  • Changed the mail attribute to use internationalized email addresses.
  • Created users with special characters (symbols) or internationalized characters in their username.
  • Defined a custom attribute where the provided value contains special characters (symbols) or internationalized characters.

Causes

The mail attribute is a standard RFC definition that predates the SMTP enhancements that allow UTF-8 addresses and is defined with the following syntax: IA5String 1.3.6.1.4.1.1466.115.121.1.26 as shown in the 00-core-ldif file:

attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' )
  EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} X-ORIGIN 'RFC 4524' )

See LDAP Schema Reference › mail for further information.

The IA5 character set does not include special characters (such as accented characters, Japanese characters etc):

This means the default mail attribute (and any other attributes defined in a similar way) do not support these special characters.

Solution

This issue can be resolved by ensuring all entries for the affected attribute only contain permitted characters.

Alternatively, you could change the default schema that comes with DS/OpenDJ (in the 00-core-ldif file above), but in doing so you may run into issues with other systems that expect the mail attribute to conform to the standard schema. Similarly, email servers may also take exception to the characters used. As such, we strongly advise against changing the schema.

The Developer Guide states that you should: Reuse Schemas Where Possible, with the pertinent information being:

You therefore should reuse schema definitions that already exist whenever you reasonably can. Reuse them as is. Do not try to redefine existing schema definitions.

If you must add schema definitions for your application, extend existing object classes with AUXILIARY classes of your own. Take care to name your definitions such that they do not clash with other names.

See Also

Installing and Administering DS/OpenDJ

Administration Guide › Managing Schema

Reference › Standards, RFCs, and Internet-Drafts

Related Training

N/A

Related Issue Tracker IDs

N/A



Copyright and TrademarksCopyright © 2018 ForgeRock, all rights reserved.
Loading...