This section explains LDAP schema differences, class and attribute mappings, auxiliary class support, and LDAP syntax.
All LDAP clients bind or connect to eDirectory as one of the following types of users:
The type of bind the user authenticates with affects the content the LDAP client can access. LDAP clients access a directory by building a request and sending it to the directory. When an LDAP client sends a request through LDAP Services for eDirectory, eDirectory completes the request for only those attributes to which the LDAP client has the appropriate access rights. For example, if the LDAP client requests an attribute value (which requires the Read right) and the user is granted only the Compare right to that attribute, the request is rejected.
Standard login restrictions and password restrictions still apply; however, any restrictions are relative to where LDAP is running. Time and address restrictions are honored, but address restrictions are relative to where the eDirectory login occurred---in this case, the LDAP server.
An anonymous bind is a connection that does not contain a username or password. If an LDAP client without a name and password binds to LDAP Services for eDirectory and the service is not configured to use a Proxy User, the user is authenticated to eDirectory as user [Public].
User [Public] is a nonauthenticated eDirectory user. By default, user [Public] is assigned the Browse right to the objects in the eDirectory tree. The default Browse right for user [Public] allows users to browse eDirectory objects but blocks user access to object attributes.
The default [Public] rights are typically too limited for most LDAP clients. Although you can change the [Public] rights, changing them will give these rights to all users. Because of this, we recommend that you use the Proxy User Anonymous Bind. For more information, see Connecting as a Proxy User.
To give user [Public] access to object attributes, you must make user [Public] a trustee of the appropriate container or containers and assign the appropriate object and attribute rights.
A proxy user anonymous bind is an anonymous connection linked to an eDirectory username. If an LDAP client binds to LDAP for eDirectory anonymously, and the protocol is configured to use a Proxy User, then the user is authenticated to eDirectory as the Proxy User. The name is then configured in both LDAP Services for eDirectory and in eDirectory.
The anonymous bind traditionally occurs over port 389 in LDAP. However, you can manually configure different ports during the install to work on different nodes, such as Active Directory.
The key concepts of proxy user anonymous binds are as follows:
To give the Proxy User rights to only selected properties:
Right-click the top container the Proxy User has rights over > click Add Trustees of This Objects.
Browse to Proxy User > click OK.
Deselect the following rights:
Click Selected Rights > select all inheritable rights for the Proxy User, such as mail stop and phone number.
To implement proxy user anonymous binds, you must create the Proxy User object in eDirectory and assign the appropriate rights to that user. Assign the Proxy User Read and Search rights to all objects and attributes in each subtree where access is needed. You also need to enable the Proxy User in LDAP Services for eDirectory by specifying the same proxy username.
In ConsoleOne, right-click the LDAP Group object.
Click Properties > General tab.
Enter the name of an eDirectory User object in the Proxy Username field.
An eDirectory user bind is a connection that an LDAP client makes using a complete eDirectory username and password. The eDirectory user bind is authenticated in eDirectory, and the LDAP client is allowed access to any information the eDirectory user is allowed to access.
The key concepts of eDirectory user binds are as follows:
By default, eDirectory user bind requests using clear text (unencrypted) passwords are refused. Clear text passwords and eDirectory usernames entered by LDAP clients on non-SSL connections can be captured by network monitoring equipment. Anyone who captures an eDirectory username and password has immediate access to all the eDirectory objects that the captured username has access to. For this reason, eDirectory user binds are more secure on LDAP servers that are configured to use SSL.
To support eDirectory user binds on non-SSL connections, you must set the clear text passwords within the LDAP Group object.
In ConsoleOne, right-click the LDAP Group object.
Click Properties > the General tab.
Click Allow Clear Text Passwords.
To assign eDirectory rights for LDAP clients:
Determine the type of username the LDAP clients will use to access eDirectory:
See Connecting to eDirectory with LDAP for more information.
If users will use one proxy user or multiple eDirectory usernames to access LDAP, use ConsoleOne to create these usernames in eDirectory or through LDAP.
Assign the appropriate eDirectory rights to the usernames that LDAP clients will use.
The default rights that most users receive provide limited rights to the user's own object. To provide access to other objects and their attributes, you must change the rights assigned in eDirectory.
When an LDAP client requests access to an eDirectory object and attribute, eDirectory accepts or rejects the request based on the LDAP client's eDirectory identity. The identity is set at bind time.
A class is a type of object in a directory, such as a user, server, or group. An attribute is a directory element that defines additional information about a specific object. For example, a User object attribute might be a user's surname or phone number. In ConsoleOne, classes are called object types or classes and attributes are called properties.
A schema is a set of rules that defines the classes and attributes allowed in a directory and the structure of a directory (where the classes can be in relation to one another). Because the schemas of the LDAP directory and the eDirectory directory are sometimes different, mapping LDAP classes and attributes to the appropriate eDirectory objects and attributes might be necessary. These mappings define the name conversion from the LDAP schema to the eDirectory schema.
LDAP Services for eDirectory provides default mappings. In many cases, the correspondence between the LDAP classes and attributes and the eDirectory object types and properties is logical and intuitive. However, depending on your implementation needs, you might want to reconfigure the class and attribute mapping.
In most instances, the LDAP class to eDirectory object type mapping is a one-to-one relationship. However, the LDAP schema supports alias names such as CN and common names that refer to the same attribute.
The default LDAP Services for eDirectory configuration contains a predefined set of class and attribute mappings. These mappings map a subset of LDAP attributes to a subset of eDirectory attributes. If an attribute is not already mapped in the default configuration, an auto-generated map is assigned to the attribute. Also, if the schema name is a valid LDAP name with no spaces or colons, no mappings are required. You should examine the class and attribute mapping and reconfigure as needed.
In ConsoleOne, right-click the LDAP Group object.
Click the Attribute Map tab.
Add, delete, or modify the attributes you want.
Because there might be alternate names for certain LDAP attributes (such as CN and common name), you might need to map more than one LDAP attribute to a corresponding eDirectory attribute name. When LDAP Services for eDirectory returns LDAP attribute information, it returns the value of the first matched attribute it locates in the list.
If you map multiple LDAP attributes to a single eDirectory attribute, you should reorder the list to prioritize which attribute should take precedence because the order is significant.
When an LDAP client requests LDAP class information from the LDAP server, the server returns the corresponding eDirectory class information. The default LDAP Services for eDirectory configuration contains a predefined set of class and attribute mappings.
In ConsoleOne, right-click the LDAP Group object.
Click the Class Map tab.
Add, delete, or modify the classes you want.
LDAP Services for eDirectory is preconfigured to map a subset of LDAP classes and attributes to a subset of eDirectory classes and attributes.
The default LDAP Services for eDirectory configuration contains a predefined set of class and attribute mappings. These mappings map a subset of LDAP classes and attributes to a subset of eDirectory classes and attributes. If an attribute or class is not mapped in the default configuration, an auto-generated map is assigned to the attribute or class. Also, if the schema name is a valid LDAP name with no spaces or colons, no mappings are required. You should examine the class and attribute mapping and reconfigure as needed.
Because the schemas of the LDAP directory and the eDirectory directory are different, mapping LDAP classes and attributes to the appropriate eDirectory objects and attributes is necessary. These mappings define the name conversion from the LDAP schema to the eDirectory schema.
No LDAP schema mappings are required for a schema entry if the name is a valid LDAP schema name. In LDAP, the only characters allowed in a schema name are alphanumeric characters and hyphens (-). No spaces are allowed in an LDAP schema name.
To ensure that searching by object IDs works after a schema extension other than LDAP, such as for .SCH files, you must refresh the LDAP server configuration if the schema is extended outside of LDAP.
In ConsoleOne, right-click the LDAP Server object.
Click Properties.
On the General tab, click Refresh LDAP Server Now.
To support LDAP from eDirectory, LDAP Services uses mappings in the protocol level (instead of the directory service level) to translate between LDAP and eDirectory attributes and classes. Because of this, two LDAP classes or attributes can be mapped to the same eDirectory class or attribute.
For example, if you create a Cn through LDAP then search for attributeclass=CommonName, you can get back a Cn.
If you request all attributes, you get the attribute that is first in the mappings list for that class. If you ask for an attribute by name, you will get the correct name.
Table 107 shows the many-to-one class mappings. Table 108 shows the many-to-one attribute mappings.
Table 107. Many-to-One LDAP Class Mappings
| LDAP Class Name | eDirectory Class Name |
|---|---|
MailGroup rfc822mailGroup |
NSCP:mailGroup1 |
GroupOfNames GroupOfUniqueNames Group |
Group |
Table 108. Many-to-One LDAP Attribute Mappings
eDirectory contains a compatibility mode switch that allows non-standard schema output so that current ADSI and old Netscape* clients can read the schema. This is implemented by setting an attribute in the LDAP Server object. The attribute name is nonStdClientSchemaCompatMode. The LDAP Server object is usually in the same container as the Server object.
The non-standard output does not conform to the current IETF standards for LDAP, but it will work with the current version of ADSI and old Netscape clients.
In non-standard output format:
To enable non-standard schema output:
In ConsoleOne, right-click the LDAP Server object.
Click Properties > the General tab.
Click Enable Non-Standard Client Schema Compatible Mode > Refresh NLDAP Server Now.
Click Apply > OK.
You can also add and set this attribute using LDAP Modify calls. If this is done through LDAP you need to refresh your LDAP server. For more information, see Refreshing the LDAP Server.
The following specialized LDAP schema files are available from the Novell download site:
The default LDAP schema maps the object class inetOrgPerson to the eDirectory User class. Since this is a direct mapping and not a schema extension, the attributes of User are applied to inetOrgPerson.
The Novell eDirectory download site contains the NOV_INET.ZIP file. This file contains a separate schema extension file (NOV_INET.SCH) and instructions (NOV_INET.TXT) that modify the eDirectory User class to provide all the attributes in compliance with the definition of the informational RFC 2798. Adding this schema extension exposes an object class with all the RFC and Netscape attributes specified by the IETF.
The default schema file shipping with this release does not provide an object class definition for residentialPerson. The eDirectory download site contains the RPERSON.ZIP file. The file contains the schema extension file (RPERSON.SCH) and an instruction file (RPERSON.TXT). If you plan to use this object class, we recommend that you extend the schema instead of simply mapping residentialPerson to the eDirectory User class.
The default schema file shipping with this release does not provide an object class definition for newPilotPerson. The eDirectory download site contains the NPERSON.ZIP file. The file contains the schema extension file (NPERSON.SCH) and an instruction file (NPERSON.TXT). If you plan to use this object class, you should extend the schema instead of simply mapping newPilotPerson to User in eDirectory.
If you try to extend the schema to include a photo attribute, this attribute might conflict with a prior definition for this class. The photo attribute can be located in either the INETORGPERSON.ZIP file or the NOV_INET.ZIP schema extension file described above. The photo attribute can be defined either as a SYN_STREAM (which can only be single-valued in eDirectory), or as a SYN_OCTET_STRING (which can be multivalued). RFC 1274 calls for a photo to be multivalued with a maximum string length of 250,000 octets. eDirectory allows a maximum of 63,000 octets in a SYN_OCTET_STRING. You will have to select the photo restrictions that you prefer. The schema extension file for inetOrgPerson contains an ldapPhoto attribute definition based on multivalue and SYN_OCTET_STRING.
Copy the .SCH file to the SYS:SYSTEM\SCHEMA directory.
Run NWCONFIG.NLM from your server console.
Select Directory Options > Extend Schema.
Log in with your administrator name and password.
Press F3 to specify a different path.
Enter SYS:SYSTEM\SCHEMA\ and the name of the .SCH file.
In ConsoleOne, right-click the LDAP Server object.
Click Properties > Refresh LDAP Server Now.
Load INSTALL.DLM.
Select Install Additional Schema Files.
Log in with your administrator name and password, then select a schema file.
eDirectory also provides LDAP LDIF schema extension support. For more information, see Using LDIF to Extend the Schema.
You can use the ndssch utility to apply schema on Linux or Solaris systems. For more information, see Using the ndssch Utility to Extend the Schema on Linux or Solaris.
LDAP and eDirectory use different syntaxes. Some important differences are:
LDAP uses commas as delimiters rather than periods. For example, a distinguished (or complete) name in eDirectory looks like this:
Using LDAP syntax, the same distinguished name would be:
Some additional examples of LDAP distinguished names include:
eDirectory uses both typeless (.JOHN.MARKETING.ABCCORP) and typeful (CN=JOHN.OU=MARKETING.O=ABCCORP) names. LDAP uses only typeful names with commas as the delimiters (CN=JOHN,OU=MARKETING,O=ABCCORP).
The backslash (\) is used in LDAP distinguished names as an escape character. If you use the plus sign (+) or the comma (,), you can escape them with a single backslash character. Some examples include
CN=Pralines\+Cream,OU=Flavors,O=MFG (CN is Pralines+Cream)
CN=D. Cardinal,O=Lionel\,Turner and Kaye,C=US (O is Lionel, Turner and Kaye)
See Internet Engineering Task Force RFC 232 for more information.
Objects can be defined with multiple naming attributes in the schema. In both LDAP and eDirectory, the User object has two: CN and OU. The plus sign (+) separates the naming attributes in the distinguished name. If the attributes are not explicitly labeled, the schema determines which string goes with which attribute (the first would be CN, the second is OU for eDirectory and LDAP). You can reorder them in a distinguished name if you manually label each portion.
For example, the following are two relative distinguished names:
Smith (CN is Smith CN=Smith)
Smith+Lisa (CN is Smith, the OU is Lisa CN=Smith OU=Lisa)
Both relative distinguished names (Smith and Smith+Lisa) can exist in the same context because they must be referenced by two completely different relative distinguished names.
The LDAP 3 protocol allows LDAP clients and LDAP servers to use controls and extensions for extending an LDAP operation. Controls and extensions allow you to specify additional information as part of a request or a response. Each extended operation is identified by an OID. LDAP clients can send extended operation requests specifying the OID of the extended operation that should be performed and the data specific to that extended operation. When the LDAP server receives the request, it performs the extended operation and sends a response containing an OID and any additional data to the client.
For example, a client can include a control that specifies a sort with the search request that it sends to the server. When the server receives the search request it sorts the search results before sending the search results back to the client. Servers can also send controls to clients. For example, a server can send a control with the authentication request that informs the client about password expiration.
By default the eDirectory LDAP server will load all system extensions and selected optional extensions and controls when the LDAP server starts up. The extensionInfo attribute of LDAP Server object for optional extensions allows the system administrator to select or deselect the optional extensions and controls.
To enable extended operations, LDAP 3 protocol requires servers to provide a list of supported controls and extensions in the supportedControl attribute and supportedExtension attribute in the root DSE. Root DSE (DSA [Directory System Agent] Specific Entry) is an entry that is located at the root of the Directory Information Tree (DIT).
Table 109 lists the supported LDAP extensions:
Table 109. Supported LDAP Extensions
Table 110 lists the supported LDAP controls:
Table 110. Supported LDAP Controls