LEX Online Manual Content

Attribute Syntaxes

Each attribute has a data type which determines more or less the nature or the value(s) stored in the attribute. This topic describes all the data types and how LEX handles these types.

Official LDAP Attribute Syntaxes

There are 'official' data types which are called 'LDAP attribute syntaxes' in the terminology of LDAP. They are registered by an official Object Identifier (OID). Such syntaxes can be specified and documented in two different ways:

Through the LDAP standard RFC 4517 - LDAP Syntaxes and Matching Rules. Most of these syntaxes have OIDs beginning with 1.3.6.1.4.1.1466.115.121.1.
Through proprietary definitions from different manufacturers. Although they are not part of the LDAP standard, nevertheless there are documented specifications about such syntaxes and the appropriate handling. LEX knows additional syntaxes from two manufacturers:
- There are Microsoft syntaxes for the use in Active Directory or old Exchange 5.5 environments. The regarding OIDs begin with 1.2.840.113556.1.4 or 2.5.5.
- There are Novell syntaxes for the use in eDirectory environments. The regarding OIDs begin with 2.16.840.1.113719.1.1.5.1.

LEX can detect this kind of attribute syntax easily by evaluating the directory schema.

Specific Attribute Content

There attributes which hold specific information, although they are marked in the directory schema with one of the 'basic' official syntaxes. Often the manufacturer of the regarding LDAP directory systems tries to encode some information which is 'encapsulated' in one of the generic data types. Examples for such attributes:

Date/Time information is stored in a numeric value
Time interval information is stored in a numeric value
Bitmaps or photos are stored in a binary value
Passwords with complex hash calculation are stored in binary values or string values

So in these cases, the schema says 'this attribute has a normal generic type', but nevertheless the attribute should be treated according to it's real content characteristics. LEX handles this by holding lists of attributes, which should be treated differently and not according to their generic schema type. There have to be attribute names in theses lists. LEX comes with a bunch of default list content for special attribute types, but you can easily add or remove attributes here. You just have to use the menu option Tools - Option - Attribute Syntaxes:

Handling non-generic data types

LEX Attribute Syntaxes

LEX determines internally the data type of each attribute. The attribute are assigned to one of the following internal LEX attribute syntaxes. All the further display and handling decisions according to an attribute are based on this assignment:

Access Point
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.2 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
ACI Item
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.1 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517 'LDAP Syntaxes and Matching Rules'. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Attribute Type Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.3 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.1. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Audio
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.4 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. LEX treats such attributes as binary attributes .
Backlink {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.4 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. The value is a 'tagged name' string:

<numeric string> # <distinguished name>

LEX has a specific editor for Novell Backlink values. In attribute lists, these attributes are labeled with this icon: . LEX can identify the containing DN and offers the option to jump directly to the regarding object. In directory export operations, you can choose to extract the DNs from these attributes.
Binary
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.5 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517 'LDAP Syntaxes and Matching Rules'. LEX treats such attributes as binary attributes . LEX has a specific editor for binary values.
Bit String
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.6 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.2. It represents an binary value, encoded in a string of '0' and '1', for example '010001101'B.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Boolean
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.1.7 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.3. Boolean attribute values always have to be one of the following strings: 'TRUE' or ' FALSE'.

LEX has a specific editor for boolean values. In attribute lists, these attributes are labeled with this icon: .
Boolean {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.8 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the general Boolean syntax, but it is used quite exclusively by Microsoft in Active Directory environments. Attribute values always have to be one of the following strings: 'TRUE' or ' FALSE'.

LEX has a specific editor for boolean values. In attribute lists, these attributes are labeled with this icon: .
CaseIgnore List {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.6 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. LEX treats these attributes like string value attributes which can be multi valued. In attribute lists, these attributes are labeled with this icon: .
Certificate
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.8 is found in the schema for the regarding attribute. This OID is described in the RFC 4523 'LDAP Schema Definitions for X.509 Certificates' in section 2.1. The data contained in such attributes represents an X.509 certificate.

This attribute always have to be accessed with the 'binary' option (=> when used in protocol messages, it has to be named '<attribute>;binary').

LEX treats these attributes like binary value attributes. In attribute lists, these attributes are labeled with this icon: . LEX has a specific editor for binary values.
Certificate List
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.9 is found in the schema for the regarding attribute. This OID is described in the RFC 4523 'LDAP Schema Definitions for X.509 Certificates' in section 2.2. The data contained in such attributes represents an X.509 certificate list.

This attribute always have to be accessed with the 'binary' option (=> when used in protocol messages, it has to be named '<attribute>;binary').

LEX treats these attributes like binary value attributes. In attribute lists, these attributes are labeled with this icon: . LEX has a specific editor for binary values.
Certificate Pair
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.10 is found in the schema for the regarding attribute. This OID is described in the RFC 4523 'LDAP Schema Definitions for X.509 Certificates' in section 2.2. The data contained in such attributes represents an X.509 certificate pair.

This attribute always have to be accessed with the 'binary' option (=> when used in protocol messages, it has to be named '<attribute>;binary').

LEX treats these attributes like binary value attributes. In attribute lists, these attributes are labeled with this icon: . LEX has a specific editor for binary values.
Counter {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.22 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. LEX treats these attributes like string value attributes which can be multi valued. In attribute lists, these attributes are labeled with this icon: . LEX has a specific editor for integer values.
Country String
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.11 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.4. It is one of the two-character codes from ISO 3166 for representing a country, for example 'uk', 'nz', 'ch', 'fr' or 'de'.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Data Quality Syntax
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.13 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Delivery Method
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.14 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.5. It is a string that indicates the service on which a system is capable to receive messages. The following services are defined in the basic standard: 'any', 'mhs', 'physical', 'telex', 'teletex', 'g3fax', '4fax', 'ia5', 'videotex' and 'telephone'.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
DIT Content Rule Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.16 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.7. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
DIT Structure Rule Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.17 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.8. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
DL Submit Permission
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.18 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
DN
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.1.12 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.9. It's used for all distinguished name attributes which have to express a referential relationship between objects (for example: member or memberOf).

LEX has a specific editor for distinguished name values. In attribute lists, these attributes are labeled with this icon: . LEX offers the option to jump directly to the referenced object.

When you switch the general object DN output to Novell DNs, these attributes are displayed accordingly. You also can configure the attribute names for DN attributes which should be displayed with short friendly names when the friendly name output is active.
DSA Quality Syntax
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.19 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
DSE Type
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.20 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .

EMail Address {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.14 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. The value is a 'tagged' address string:

<numeric string> # <mail address string>

The leading numeric value normally specifies the address type: 1 - SFM70(MHS), 2 - SFM71(MHS), 3 - SMTP, 4 - x.400, 5 - SNADS, 6 - PROFS.

LEX has a specific editor for Novell EMail Address values. In attribute lists, these attributes are labeled with this icon: .
Enhanced Guide
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.21 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.10. An enhanced guide attribute contains information regarding LDAP filters. It suggest filter attributes and operators to be used when searching for specific object class instances.

LEX treats such attributes as string attributes .
Facsimile Telephone Number
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.22 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.11. Attributes with this syntax contain a FAX number.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Fax
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.23 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.12. Attributes with this syntax contain a G3 FAX image. Therefore LEX tries to handle these attributes as bitmaps.

LEX has a specific editor for bitmap values. In attribute lists, these attributes are labeled with this icon: .
Generalized Time
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.24 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.13. Attributes with this syntax contain a string which specifies a date and a time value, down to a tenth part of a second, optional with information about the deviation from the coordinated universal time. This generalized time string syntax is conform to the ISO 8601 standard for representation of dates and times. Examples for this syntax:

196820100644+0100    6:44 AM, October 20, 1968   (Middle European Time)
200306032015230Z      8:15:30 PM, July 03, 2003    (Coordinated Universal Time)
200912241600-0800     4 PM, December 24, 2009     (Pacific Standard Time)

The difference between generalized time strings and UTC time strings: In generalized time strings, the minutes, seconds and fractions of seconds are optional. In UTC time strings, only the seconds are optional and fractions of seconds are not allowed here. In most directories, servers use time strings which includes minutes and seconds, but no fractions of seconds: So these are conform two both syntaxes.

LEX has a specific editor for date and time values, which allows the comfortable display or specification of such a data type. In attribute lists, these attributes are labeled with this icon: .

Guide
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.25 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.14. A guide attribute contains information regarding LDAP filters. It suggest filter attributes and operators to be used when searching for specific object class instances. This syntax is an older version of the 'Enhanced Guide' attribute syntax.

LEX treats such attributes as string attributes .
IA5 String
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.26 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.15. Such attributes contain a string with characters from the International Alphabet 5 (IA5), the international version of the ASCII character set.

LEX treats such attributes as string attributes .
Integer
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.27 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.16. Such attributes contain a numeric integer value.

LEX treats such attributes as integer attributes . LEX has a specific editor for integer values.
Integer {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.9 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the general Integer syntax, but it is used quite exclusively by Microsoft in Active Directory environments. Microsoft Integer attribute values are 32 bit signed integers (-2147483648 - 2147483647).

LEX has a specific editor for integer values. In attribute lists, these attributes are labeled with this icon: .

JPEG
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.28 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.17. Attributes with this syntax contain a G3 FAX image. Therefore LEX tries to handle these attributes as bitmaps.

LEX has a specific editor for bitmap values. In attribute lists, these attributes are labeled with this icon: .
Large Integer/Interval {MS} as an integer values

LEX assigns this syntax to an attribute if the syntax 2.5.5.16 or 1.2.840.113556.1.4.906 is found in the schema for the regarding attribute. The OID 2.5.5.16 is described in the Microsoft Active Directory Technical Specification [MSADTS]. The other OID was specified by Microsoft for the old Exchange 5.x schema.

Both syntaxes describe a 64 bit singed integer value (-9223372036854775808 - 9223372036854775807). Because such values are 8 byte long, this syntax is called Integer8 sometimes. In several APIs, large integer values are handled by accessing two 32 bit parts of the value: the HighPart and the LowPart.

LEX has a specific editor for large integer values. In attribute lists, these attributes are labeled with this icon: .
Large Integer/Interval {MS} as a date/time values

In some cases, a large integer value (see paragraph above) has to be interpreted as a date and time value. It can be read as a Microsoft Filetime structure then, expressing the 100-nanosecond steps since 12:00 AM, January 1, 1601.

Some of the most interesting date/time attributes in AD environments (for example lastLogon, lastLogonTimestamp, pwdLastSet, accountExpires) are Large Integers which have to be interpreted as date and time. Since this internal characteristics are not expressed in the directory schema, LEX has to hold a list of names of such attributes.

You can configure this list in the Tools - Options - Attribute Syntaxes tab with the Datetime Attributes button. Normally you will not have to work hard on this list because all the standard Large Integer attributes which are date and time values are predefined as default here.

LEX has a specific editor for Microsoft date/time values, which allows the comfortable display or specification of date and time values - and which allows to edit the raw string value also. In attribute lists, these attributes are labeled with this icon: .
Large Integer/Interval {MS} as a time interval values

In some cases, a large integer value (see paragraph above) has to be interpreted as a time interval. Time intervals are always negative numbers. Their absolute value can be read as a Microsoft Filetime structure then, expressing 100-nanosecond steps which determine the length of the time interval.

Some interesting time interval attributes in AD environments (for example parameters for the password policies in an AD domain) are Large Integers which have to be interpreted as an interval. Since this internal characteristics are not expressed in the directory schema, LEX has to hold a list of names of such attributes.

You can configure this list in the Tools - Options - Attribute Syntaxes tab with the Interval Attributes button. Normally you will not have to work hard on this list because all the standard Large Integer attributes which are date and time values are predefined as default here.

LEX has a specific editor for Microsoft interval values, which allows the comfortable display or specification of the time values - and which allows to edit the raw string value also. In attribute lists, these attributes are labeled with this icon: .
LDAP Schema Definition
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.56 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2927 but has been removed in the modern RFC 4517. LEX treats such attributes as a string attribute .
LDAP Schema Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.57 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. LEX treats such attributes as string attributes .
LDAP Syntax Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.54 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.18. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Mail Preference
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.32 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. LEX treats such attributes as string attributes .
Master And Shadow Access Points
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.29 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Matching Rule Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.30 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.19. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Matching Rule Use Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.31 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.20. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
MHS OR Address
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.33 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2156 but has been removed in the modern RFC 4517. LEX treats such attributes as a string attribute .
Modify Rights
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.55 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Name And Optional UID
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.34 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.21. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Name Form Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.35 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.22. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Net Address {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.12 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. The content is a binary value called 'tagged data' which is built like this string:

<numeric string> # <binary value>

In most cases, the leading numeric value specifies the address type, the binary data often contains an address string encoded in unicode data. Important address types: 0 for IPX, 1 for IP, 2 for SDLC, 3 for TokenRing, 4 for OSI, 5 for Appletalk, 6 for NetBEUI, 7 for Sockets, 8 for UDP, 9 for TCP, 10 for UDP6, 11 for TCP6, 12 is reserved and 13 for URLs.

LEX treats these attributes like binary value attributes. In attribute lists, these attributes are labeled with this icon: . LEX has a specific editor for binary values.
Numeric String
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.36 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.23. Such attributes contain a numeric integer value.

LEX treats such attributes as integer attributes . LEX has a specific editor for integer values.
Object ACL {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.17 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. The content is a string which defines one permission entry in an objects access control list:

<privileges> # <scope> # <object DN> # <attribute>

The privilege value depends on the setting for the attribute string (see one of the next paragraphs). For [Entry Rights] permissions, the following bits are important: 1-Browse, 2-Create, 4-Delete, 8-Rename, 16-Supervisor, 64-Inheritance Control. For normal attribute permissions, the following bits are important: 1-Compare, 2-Read, 4-Write, 8-Add Self, 32-Supervisor, 64-Inheritance Control.

The scope determines if the regarding permission is to be inherited to child objects. If the permission is only set for the object itself, the string 'entry' is used, otherwise the string 'subtree' is used.

The object distinguish name is the DN of the trustee which has the regarding permission. In addition to normal DNs, the following generic trustee strings are allowed: [Root], [Public], [Creator], [Self], [Inheritance Mask].

The attribute string specifies the attribute for which the permission is set. In addition to attribute names, the following to generic strings are allowed: [All Attributes Rights], and [Entry Rights] (which means that the permission is set according to the entire object.

LEX has a specific editor for Novell Object ACL values. In attribute lists, these attributes are labeled with this icon: . LEX can identify the containing DN and offers the option to jump directly to the regarding object. In directory export operations, you can choose to extract the DNs from these attributes.
Object Class Description
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.37 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.24. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Object(DN-Binary) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.7 or 1.2.840.113556.1.4.903 is found in the schema for the regarding attribute. The OID 2.5.5.7 is described in the Microsoft Active Directory Technical Specification [MSADTS]. The other OID was specified by Microsoft for the old Exchange 5.x schema.

Both syntaxes describe a value which is a combination of a distinguished name and a binary value in the following form:

B:<len>:<hexstring>:<dn>

An Example:
B:32:18E2EA80684F11D2B9AA00C04F79F805:CN=DeletedObjects,DC=cerrotorre,DC=de

The <len> value is the character length of the hexstring value (not the length of the binary value itself!).

LEX has a specific editor for Microsoft DN with Binary values. In attribute lists, these attributes are labeled with this icon: . LEX can identify the containing DN and offers the option to jump directly to the regarding object. In directory export operations, you can choose to extract the DNs from these attributes.

Object(DN-String) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.14 or 1.2.840.113556.1.4.904 is found in the schema for the regarding attribute. The OID 2.5.5.14 is described in the Microsoft Active Directory Technical Specification [MSADTS]. The other OID was specified by Microsoft for the old Exchange 5.x schema.

Both syntaxes describe a value which is a combination of a distinguished name and a string value in the following form:

S:<len>:<string>:<dn>

An Example:
S:10:RecycleBin:CN=DeletedObjects,DC=cerrotorre,DC=de

The <len> value is the length of the string value.

LEX has a specific editor for Microsoft DN with String values. In attribute lists, these attributes are labeled with this icon: . LEX can identify the containing DN and offers the option to jump directly to the regarding object. In directory export operations, you can choose to extract the DNs from these attributes.

Object(DS-DN) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.1 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the basic DN syntax, but it is used quite exclusively by Microsoft in Active Directory environments. It's used for all distinguished name attributes which have to express a referential relationship between objects (for example: member or memberOf).

LEX has a specific editor for distinguished name values. In attribute lists, these attributes are labeled with this icon: . LEX offers the option to jump directly to the referenced object.

When you switch the general object DN output to Novell DNs, these attributes are displayed accordingly. You also can configure the attribute names for DN attributes which should be displayed with short friendly names when the friendly name output is active.
Object(OR-Name) {MS}
LEX assigns this syntax to an attribute if the syntax 1.2.840.113556.1.4.1221 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the basic DN syntax, but was used quite exclusively by Microsoft in Exchange 5.5 environments. It can be used for all distinguished name attributes which have to express a referential relationship between objects (for example: member or memberOf).

LEX has a specific editor for distinguished name values. In attribute lists, these attributes are labeled with this icon: . LEX offers the option to jump directly to the referenced object.

When you switch the general object DN output to Novell DNs, these attributes are displayed accordingly. You also can configure the attribute names for DN attributes which should be displayed with short friendly names when the friendly name output is active.
Object(Presentation-Address) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.13 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the basic Presentation Address syntax, is referenced in the older RFC 1278 but has been removed in the modern RFC 4517. LEX treats such attributes as a string attribute .
Octet List {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.13 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Octet String
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.40 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.35. Such attributes contain binary data.

LEX has a specific editor for binary values. It allows you to edit the value, copy and paste parts of it - or load and save the data from/to files. In attribute lists, these attributes are labeled with this icon: .
Octet String as bitmaps
In some cases, an octet string value (see paragraph above) has to be interpreted as a bitmap.

Some interesting bitmap attributes in AD environments (for example photo attributes which can be stored for a user object in the directory) are binary octetstring attributes which have to be interpreted as an bitmap. Since sometimes this internal characteristics are not expressed in the directory schema, LEX has to hold a list of names of such attributes.

You can configure this list in the Tools - Options - Attribute Syntaxes tab with the Bitmap Attributes button. Normally you will not have to work hard on this list because all the important attributes which are bitmap values are predefined as default here.

LEX has a specific editor for bitmap values. In attribute lists, these attributes are labeled with this icon: .
Octet String as passwords
In some cases, an octet string value (see paragraph above) has to be interpreted as a passwords or password hash. For this case, LEX opens a specific password editor, where you can build new password hashes, or where you can check a password against the hash value which is stored in the directory. The following octet string attributes are interpreted as passwords by LEX: userPassword.

In attribute lists, these attributes are labeled with this icon: .
OID
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.38 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.26. Such attributes contain a Object Identifier (OID) string.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Other Mailbox
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.39 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.27. Such attributes contain a string which represents the mailbox type and the actual mailbox address:

<mbx type string> # <mbx address string>

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .

Path {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.15 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. The content is a string called 'tagged name and string':

<distinguished name> # <numeric string> # <text>

In most cases, the leading DN is to identify a netware volume object, the number in the middle specify the namespace type: 0 for DOS, 1 for MAC, 2 for Unix/NFS, 3 for FTAM, 4 for OS/2/Windows. The trailing text is the path on the specified volume.

LEX has a specific editor for Novell Path values. In attribute lists, these attributes are labeled with this icon: . LEX can identify the containing DN and offers the option to jump directly to the regarding object. In directory export operations, you can choose to extract the DNs from these attributes.

Postal Address
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.41 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.28. Such attributes contain postal address information encoded in UTF8 characters, where the different parts of the address can be separated by a dollar ('$') character. An example:

Graf-Rhena-Str. 20$D-76137 Karlsruhe$Germany

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .

Presentation Address
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.43 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 1278 but has been removed in the modern RFC 4517. LEX treats such attributes as a string attribute .
Printable String
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.44 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.29. Such attributes contain a string that only consists of latin alphabetic characters, numeric characters and these punctual characters ? : / ' ( ) + , - . =

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .

Protocol Information
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.42 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Replica Pointer {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.16 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers.

LEX treats these attributes like binary value attributes. In attribute lists, these attributes are labeled with this icon: . LEX has a specific editor for binary values.
String
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.15 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.6 - actually it is officially called 'Directory String'. It is a string that normally can contain any sequence of UTF-8 characters. The details are outlined in the RFC 4518 'LDAP Internationalized String Preparation'

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
String as passwords
In some cases, a string value (see paragraph above) has to be interpreted as a passwords or password hash. For this case, LEX opens a specific password editor, where you can build new password hashes, or where you can check a password against the hash value which is stored in the directory. The following string attributes are interpreted as passwords by LEX: sambaLMPassword, lmPassword, sambaNTPassword, ntPassword.

In attribute lists, these attributes are labeled with this icon: .
String(CaseSensitive) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.3 or 1.2.840.113556.1.4.1362 is found in the schema for the regarding attribute. The OID 2.5.5.3 is described in the Microsoft Active Directory Technical Specification [MSADTS]. The other OID was specified by Microsoft for the old Exchange 5.x schema. Both syntaxes describe a normal string which corresponds with the general String syntax - but the string stored in such attributes are case sensitive. This is important when you search for object with LDAP filters containing such an attribute.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
String(Generalized-Time) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.11 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the basic Generalized Time syntax, but it is used quite exclusively by Microsoft in Active Directory environments.

Attributes with this syntax contain a string which specifies a date and a time value, down to a tenth part of a second, optional with information about the deviation from the coordinated universal time. This generalized time string syntax is conform to the ISO 8601 standard for representation of dates and times. Examples for this syntax:

196820100644+0100    6:44 AM, October 20, 1968   (Middle European Time)
200306032015230Z      8:15:30 PM, July 03, 2003    (Coordinated Universal Time)
200912241600-0800     4 PM, December 24, 2009     (Pacific Standard Time)

The difference between generalized time strings and UTC time strings: In generalized time strings, the minutes, seconds and fractions of seconds are optional. In UTC time strings, only the seconds are optional and fractions of seconds are not allowed here. In most directories, servers use time strings which includes minutes and seconds, but no fractions of seconds: So these are conform two both syntaxes.

LEX has a specific editor for date and time values, which allows the comfortable display or specification of such a data type. In attribute lists, these attributes are labeled with this icon: .

String(IA5/Printable) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.5 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the general IA5 String syntax, but it is used quite exclusively by Microsoft in Active Directory environments.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
String(NT-Sec-Desc) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.15 or 1.2.840.113556.1.4.907 is found in the schema for the regarding attribute. The OID 2.5.5.15 is described in the Microsoft Active Directory Technical Specification [MSADTS]. The other OID was specified by Microsoft for the old Exchange 5.x schema. Both syntaxes are used quite exclusively by Microsoft in Active Directory environments.

The value contained in String(NT-Sec-Desc) attribute represents an Microsoft Security Descriptor in binary form.

The Security Descriptor plays an important role in access control list. Actually, the Security Descriptor REPRESENTS the access control list for any objects like files, directories, printers, AD objects and so on. It specifies the owner of an object and two different Sub-ACLs: The System ACL (SACL) which controls the audit settings for this object, and the Discretionary ACL (DACL) which specify the access permissions.

The structure of a Security Descriptor value is very complex, you can learn more about this at the manual topic regarding the appropriate editor: LEX has a specific editor for Security Descriptor values. In attribute lists, these attributes are labeled with this icon: .
String(Numeric) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.6 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the general Numeric String syntax, but it is used quite exclusively by Microsoft in Active Directory environments.

LEX has a specific editor for integer values. In attribute lists, these attributes are labeled with this icon: .
String(Object-Identifier) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.2 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the general OID syntax, but it is used quite exclusively by Microsoft in Active Directory environments.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
String(Octet) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.10 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the general Octet String syntax, and describes a pure binary data format. But it is used quite exclusively by Microsoft in Active Directory environments.

LEX has a specific editor for binary values. It allows you to edit the value, copy and paste parts of it - or load and save the data from/to files. In attribute lists, these attributes are labeled with this icon: .

Please note that there are several other interpretation for the internal binary data in some cases (bitmaps, passwords....). These interpretations are described for the Paragraphs according to the general Octet String syntax.
String(SID) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.17 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It is used quite exclusively by Microsoft in Active Directory environments.

The value contained in String(SID) attribute represents an Microsoft Security Identifier in binary form. The SID plays an important role when it comes to identify any kind of Microsoft Security Principals like users or groups, for example in access tokens, access control lists and so on.

The structure of a SID value is described in the Microsoft Data Type Reference [MSDTY]. It is a binary value ,which consists of

1-Byte Revision: An 8-bit unsigned integer that specifies the revision level of the SID structure. This value MUST be set to 0x01.

1-Byte SubAuthority Count: An 8-bit unsigned integer that specifies the number of elements in the SubAuthority array. The maximum number of elements allowed is 15.

6-Byte IdentifierAuthority: A structure that contains information, which indicates the authority under which the SID was created. It describes the entity that created the SID and manages the account.

Variable-Length SubAuthority: A variable length array of unsigned 32-bit integers that uniquely identifies a principal relative to the IdentifierAuthority. Its length is determined by SubAuthorityCount.

SIDs are expressed normally with a specific string syntax, for example like these:

S-1-5-7 (Wellknown SID for 'Anonymous Logon')
S-1-5-21-1621763826-2590103247-2238570322-1113

Every Active Directory Configuration Partition stores information about the wellknown standard SIDs which can be used by the regarding system. The according objects are in the CN=WellKnown Security Principals,CN=Configuration,DC=.... organizational unit.

LEX has a specific editor for SID values. In attribute lists, these attributes are labeled with this icon: .

String(Teletext) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.4 or 1.2.840.113556.1.4.905 is found in the schema for the regarding attribute. The OID 2.5.5.4 is described in the Microsoft Active Directory Technical Specification [MSADTS]. The other OID was specified by Microsoft for the old Exchange 5.x schema. Both syntaxes describe a teletext address which corresponds with the general Teletex Terminal Identifier syntax, but they are used quite exclusively by Microsoft.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
String(Unicode) {MS}
LEX assigns this syntax to an attribute if the syntax 2.5.5.12 is found in the schema for the regarding attribute. This OID is described in the Microsoft Active Directory Technical Specification [MSADTS]. It corresponds with the general String syntax, but it is used quite exclusively by Microsoft in Active Directory environments.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .

Please note that there are several other interpretation for the internal binary data in some cases (passwords....). These interpretations are described for the Paragraphs according to the general String syntax.
Substring Assertion
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.58 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.30. It's used normally in the schema definition.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Subtree Specification
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.45 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. LEX treats such attributes as string attributes .
Supplier And Consumer
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.48 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Supplier Information
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.46 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Supplier Or Consumer
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.47 is found in the schema for the regarding attribute. This OID is referenced in the older RFC 2252 but has been removed in the modern RFC 4517. So LEX treats such attributes according to the situation: When the directory returns binary data for this attribute, is is handled like a binary attribute , otherwise it's handled like a string attribute .
Supported Algorithm
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.49 is found in the schema for the regarding attribute. This OID is described in the RFC 4523 'LDAP Schema Definitions for X.509 Certificates' in section 2.4. The data contained in such attributes represents an name string for the supported X.509 algorithms.

This attribute always have to be accessed with the 'binary' option (=> when used in protocol messages, it has to be named '<attribute>;binary').

LEX treats these attributes like binary value attributes. In attribute lists, these attributes are labeled with this icon: .
Telephone Number
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.50 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.31. It's a string with a telephone number which conforms to the rules of the Printable String syntax.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Teletex Terminal Identifier
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.51 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.32. It's a string with a teletex terminal number which can include some parameters, separated by '$'.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Telex Number
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.52 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.33. It's a string with a teletex terminal number which can include a country code, separated by '$'.

LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .
Timestamp {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.19 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. The content is a string which contains three numeric values:

<numeric string> # <numeric string> # <numeric string>

The first value is the numeric string of a 32 bit integer value which represents the number of seconds 12:00 midnight Jan 01 1970, UTC. This date and time format is also called Unix Epoch or Posix time format.

The other two values represent 16 bit integer values. In the Novell syntax description, the second numeric value is called 'replicaNum' the third one is called 'eventID'.In most cases, these values are 0.

LEX has a specific editor for Novell Timestamp values, which allows the comfortable display or specification of date and time values - and which allows to edit the raw string value. In attribute lists, these attributes are labeled with this icon: .

Typed Name {Nov}
LEX assigns this syntax to an attribute if the syntax 2.16.840.1.113719.1.1.5.1.25 is found in the schema for the regarding attribute. This is a proprietary syntax defined by Novell. This syntax is described in the Novell LDAP Library Documentation for Developers. The content is a object distinguished name with two numeric values attached to it:

<distinguished name> # <numeric string> # <numeric string>

In the Novell syntax description, the first numeric value is called 'level' the third one is called 'interval'.

LEX has a specific editor for Novell Typed Name values, which allows the comfortable specification of date and time values - and which allows to edit the raw numeric value. In attribute lists, these attributes are labeled with this icon: . LEX can identify the containing DN and offers the option to jump directly to the regarding object. In directory export operations, you can choose to extract the DNs from these attributes.
UTC Time
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.4.1.1466.115.121.1.53 is found in the schema for the regarding attribute. This OID is described in the RFC 4517 'LDAP Syntaxes and Matching Rules' in section 3.3.34. Attributes with this syntax contain a string which specifies a date and a time value optional with information about the deviation from the coordinated universal time. This time string syntax is conform to the Abstract Syntax Notation One (ASN.1) for dates and times. Examples for this syntax:

196820100644+0100    6:44 AM, October 20, 1968   (Middle European Time)
200306032015230Z      8:15:30 PM, July 03, 2003    (Coordinated Universal Time)
200912241600-0800     4 PM, December 24, 2009     (Pacific Standard Time)

The difference between generalized time strings and UTC time strings: In generalized time strings, the minutes, seconds and fractions of seconds are optional. In UTC time strings, only the seconds are optional and fractions of seconds are not allowed here. In most directories, servers use time strings which includes minutes and seconds, but no fractions of seconds: So these are conform two both syntaxes.

LEX has a specific editor for date and time values, which allows the comfortable display or specification of such a data type. In attribute lists, these attributes are labeled with this icon: .

UUID
LEX assigns this syntax to an attribute if the syntax 1.3.6.1.1.16.1 is found in the schema for the regarding attribute. This OID is described in the RFC 4530 'LDAP entryUUID Operational Attribute' and is normally used only for one attribute: entryUUID. This 'Universally Unique Identifier' is assigned to each object in many LDAP directory systems (for example, in all modern OpenLDAP systems).

The UUID is expressed as an 128 bit value encoded in a hexadecimal string, the syntax is described in RFC 4122 'A UUID URN Namespace'. LEX treats these attributes like string value attributes. In attribute lists, these attributes are labeled with this icon: .