LDAP Schema changes in R5.0.2

04 Documentation updates

Server
LDAP Schema changes in R5.0.2

There are several LDAP schema changes in R5.0.2 as described in the following topics.

Street and postalAddress attribute mapping
LDAP RFC 2256 makes a distinction between the attributes street and postalAddress. Street is defined as a physical delivery location and postalAddress as a mailing address used by the postal service. In addition, postalAddress isn't comprised of component parts. In Release 5.0 and 5.0.1, the LDAP service mapped the attribute street to a street portion of the postalAddress and also derived postal addresses by concatenating values for multiple fields. To better comply with LDAP standards, in Release 5.0.2 the LDAP service correctly distinguishes between street and postalAddress attributes. Also, the Domino LDAP service no longer derives postalAddress attributes from multiple fields. The following table summarizes these mapping changes:

LDAP attribute Schema source Previous field mapping
in Person documents
(R5.0 and R5.0.1)* Current field mapping
in Person documents (R5.0.2)*

Street
(or the alias, streetAddress) RFC 2256 OfficeStreetAddress Street
(new, hidden)

postalAddress RFC 2256 OfficeStreetAddress, OfficeCity, OfficeState, OfficeZip, OfficeCountry PostalAddress
(new, hidden)

homePostalAddress InetOrgPerson Draft HomeStreetAddress, HomeCity, HomeState, HomeZip, HomeCountry HomePostalAddress
(new, hidden)

homeStreetAddress Domino StreetAddress StreetAddress

officeStreetAddress
(new) Domino
------
OfficeStreetAddress

*Names refer to the fields themselves rather than the labels used to display them.

In R5.0.2, if a user searches for the attribute street (or streetAddress) and there is no value in the Street field, the LDAP service returns nothing (it will not revert to the previous behavior).

If a user searches for the attribute postalAddress, the LDAP service first looks for a value in the PostalAddress field. If it does not find a value there, it reverts to the previous behavior as described in the table above. Similarly, if a user searches for the attribute homePostalAddress and there is no value in the HomePostalAddress field, the LDAP service reverts to the previous behavior.

If users add or modify values for the postalAddress or homePostalAddress attribute, changes only apply to the PostalAddress field or HomePostalAddress field, respectively. For example, if users specify the attribute postalAddress in a modify command, the LDAP service does not change values in the fields OfficeStreetAddress, OfficeCity, OfficeState, OfficeZip, and OfficeCountry if there is no value in the PostalAddress field.

New mappings for LDAP name attributes
In R5.0 and R5.0.1, LDAP name attributes in the schema were derived from components of distinguished names. In R5.0.2, the LDAP service uses distinct name attributes. The following table summarizes these changes.

LDAP attribute Previous mapping
(R5.0 and 5.0.1) Current mapping
(R5.0.2)

cn RDN* 2nd-nth values in the FullName field, ListName field (for groups) or ServerName field (for servers). Also maps to the RDN if cn is specified as the RDN.

uid RDN ShortName field. Also maps to the RDN if uid is specified as the RDN.

ou ou component of DN ou attribute; no longer derived from a DN**

o o component of DN o attribute; no longer derived from a DN**

l OfficeCity field OfficeCity field. Also maps to the RDN if l is specified as the RDN.

*The RDN (Relative Distinguished Name) is the left-most component of the DN (Distinguished Name). The value for a DN is the first value listed in the FullName field, ListName field (for groups), or ServerName field (for servers).

**The "ou" and "o" attributes do not typically map to fields in the directory. An exception to this is the Person form (which represents the dominoPerson object class) which contains a new hidden field called "ou."

When you add an entry, the RDN specified for the entry becomes the value for the RDN as well as a distinct attribute For example, if you add a person entry with the DN "uid=jdoe, ou=west, o=acme," "jdoe/west/acme" is added as the first value in the FullName field and "jdoe" is added to the ShortName field.

When you search on cn, uid, or l, the LDAP service searches an RDN as well as the distinct attributes. For example, for a search on "uid=jdoe" , the LDAP service searches for "jdoe" in the RDN and also in the ShortName field.

When you search on o or ou attributes, the LDAP service no longer returns a component of a DN. For example, a search on "ou=west" doesn't return the value "west" from the DN "jdoe/west/acme."

If you specify one of the above attributes in an LDAP modify command, the change doesn't affect an RDN. Assuming previous examples, if you do an LDAP modify-add operation to add "johnd" as an additional UID attribute value, the ShortName field then contains the values, "jdoe" and "johnd." If you then specify "uid=johnd" in an LDAP modify-delete operation, the "johnd" value is deleted but if you specify instead "uid=jdoe", the "jdoe" value is not deleted because it is the RDN.

textEncodedORAddress and mhsORAddress attributes
In R5.0, the textEncodedORAddress attribute was included as part of the ePerson object class and had the alias mhsORAddress. textEncodedORAddress mapped to the field X400Address in Person documents. In R5.01, the ePerson object class was removed from the schema, and so textEncodedORAddress (and its alias, mhsORAddress) then were re-defined as part of the dominoPerson object class.
In R5.0.2, textEncodedORAddress and mhsORAddress are no longer part of the directory schema. You must add these attributes to the schema if you want to use them.

X400Address remains as a Domino defined attribute with syntax type 'DN', which is derived from the X400Address field assigned the data type "Names."

physicalDeliveryOfficeName and roomNumber attributes
In R5.0 and R5.0.1, roomNumber is treated as an alias of physicalDeliveryOfficeName, which maps to the field OfficeNumber. In R5.0.2, roomNumber is a distinct attribute in the schema; roomNumber does not have a field correlation in the Domino Directory. Note that physicalDeliveryOfficeName continues to map to the OfficeNumber field.

initials, middleName, and middleInitials attributes
In R5.0.2, the LDAP attribute middleName is no longer defined in the schema; to use this attribute you must extend the schema. Previously the middleName attribute was included in the schema and mapped to the field MiddleInitial in the Person document. There is a new Domino-defined LDAP attribute called MiddleInitial that maps to the MiddleInitial field.

The LDAP attribute initials is still defined in the schema, but it does not have a field correlation in the Domino Directory.

Additional organizational units allowed in distinguished names
In R5.0.2, a distinguished name added through LDAP can include up to 12 OUs. Entries created through Domino are still limited to four OUs, however. Distinguished names with more than four OUs cannot be displayed in the usual abbreviated format by Notes clients and may have unknown side effects in the Notes client. Consequently, creating entries with more than 4 OUs in their DNs is not recommended if the entries will be used by both Notes and LDAP clients.

Changes to Object Class definitions
In R5.0.2, object class definitions have changed as follows:

R5.0 and 5.0.1 object class	Changes in R5.0.2*	Comments
ePerson	Removed (in R5.0.1)	LDAP standards define this as auxiliary, so you should add this to your schema yourself if you need it.
dominoGroup	_____	_____
dominoPerson	Superior object class is now inetOrgPerson	_____
Server	Object class name changed to dominoServer	_____
$PersonGeneralInfo	_____	Defined in the schema as an auxiliary object class with ditContentRule that associates it with the dominoPerson object class. Correlates to the $PersonGeneralInfo subform that defines the fields displayed in the Work/Home tab of a Person document.
inetOrgPerson	Redefined as a structural object class. Previously defined as abstract.**	Entries created for the inetOrgPerson object class also include attribute definitions for the dominoPerson object class. Don't add values for these attributes if you don't want to use them.
Top	_____	_____
organization	Redefined as the structural object class "organization" specified in RFC 2256.**	Entries created for the "organization" object class also include attribute definitions for the dominoOrganization object class. Don't add values for these attributes if you don't want to use them. The new dominoOrganization object class correlates to the "organization" object class previously used in R5.0 and R5.0.1.
organizationalUnit	Redefined as the structural object class "organizationalUnit" specified in RFC 2256.**	Entries created for the organizationalUnit object class also include attribute definitions for the dominoOrganizationalUnit object class. Don't add values for these attributes if you don't want to use them. The new dominoOrganizationalUnit object class correlates to the "organizationalUnit" object class previously used in R5.0 and R5.0.1.
person	Redefined as a structural object class. Previously defined as abstract.**	Entries created for the "person" object class also include attribute definitions for the dominoPerson object class. Don't add values for these attributes if you don't want to use them.
organizationalPerson	Redefined as a structural object class. Previously was defined as an abstract object class.**	Entries created for the organizationalPerson object class also include attribute definitions for the dominoPerson object class. Don't add values for these attributes if you don't want to use them.
groupOfNames	Redefined as a structural object class. Previously was defined as an abstract object class.**	Entries created for the groupOfNames object class also include attribute definitions for the dominoGroup object class. Don't add values for these attributes if you don't want to use them.
---------	New structural object class: dominoOrganization. Has definitions for Domino-specific organization attributes.	Correlates to the "organization" object class in R5.0 and R5.0.1. Entries created using the Certifier form.
---------	New structural object class: dominoOrganizationalUnit. Has definitions for Domino-specific organizationalUnit attributes	Correlates to the organizationalUnit object class in R5.0 and R5.0.1. Entries creating using the Certifier form.
---------	New structural object class: locality.	Entries created from the new, hidden form, (LDAP Locality).

*Many standard LDAP attributes have been added to the schema. This table does not list these new attributes. Please refer to the Domino LDAP Schema database updated on an R5.0.2 server for the current list of supported attributes. Some attributes defined in the schema are not physically represented in the directory as fields. However, LDAP operations work against these attributes.

**You cannot create entries for these object classes from Notes. When you add the entries via LDAP, the entries are not physically created in the directory and can only be accessed through LDAP operations.

LDAP attribute	Schema source	Previous field mapping in Person documents (R5.0 and R5.0.1)*	Current field mapping in Person documents (R5.0.2)*
Street (or the alias, streetAddress)	RFC 2256	OfficeStreetAddress	Street (new, hidden)
postalAddress	RFC 2256	OfficeStreetAddress, OfficeCity, OfficeState, OfficeZip, OfficeCountry	PostalAddress (new, hidden)
homePostalAddress	InetOrgPerson Draft	HomeStreetAddress, HomeCity, HomeState, HomeZip, HomeCountry	HomePostalAddress (new, hidden)
homeStreetAddress	Domino	StreetAddress	StreetAddress
officeStreetAddress (new)	Domino	------	OfficeStreetAddress

LDAP attribute	Previous mapping (R5.0 and 5.0.1)	Current mapping (R5.0.2)
cn	RDN*	2nd-nth values in the FullName field, ListName field (for groups) or ServerName field (for servers). Also maps to the RDN if cn is specified as the RDN.
uid	RDN	ShortName field. Also maps to the RDN if uid is specified as the RDN.
ou	ou component of DN	ou attribute; no longer derived from a DN**
o	o component of DN	o attribute; no longer derived from a DN**
l	OfficeCity field	OfficeCity field. Also maps to the RDN if l is specified as the RDN.