Solutions
ForgeRock Identity Platform
Does not apply to Identity Cloud

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

Last updated Jan 12, 2023

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 when used in conjunction with DS.


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) 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 mail for further information.

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

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 (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 Getting Started Guide states that you should: Reuse Schemas Where Possible, with the pertinent information being:

Therefore, 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. Take care to name your schemas such that they do not clash with other names.

See Also

Installing and Administering DS

LDAP Schema

Supported Standards

Related Training

N/A

Related Issue Tracker IDs

N/A


Copyright and Trademarks Copyright © 2023 ForgeRock, all rights reserved.