This section explains the following:
All LDAP clients bind (connect) to Novell eDirectory as one of the following types of users:
The type of bind the user authenticates with determines the content that 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 that the LDAP client has the appropriate access rights to.
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 non-authenticated 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 the majority of 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, 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, during the installation you can manually configure different ports.
The key concepts of proxy user anonymous binds are as follows:
To give the Proxy User rights to only selected properties:
In Novell iManager, click the Roles and Tasks button .
Click Rights > Modify Trustees.
Specify the name and context of the top container the Proxy User has rights over, or click to browse to the container in question, then click OK.
On the Modify Trustees screen, click Add Trustee.
Browse to and click the Proxy User's object, then click OK.
Click Assigned Rights to the left of the Proxy User you just added.
Check the All Attributes Rights and Entry Rights check boxes, then click Delete Property.
Click Add Property, then check the Show All Properties in Schema check box.
Select an inheritable right for the Proxy User, such as mailstop (in the lowercase section of the list) or Title, then click OK.
To add additional inheritable rights, repeat Steps 9 and 10.
Click Done, then click OK.
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.
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:
Determine the type of username the LDAP clients will use to access eDirectory:
See Connecting to eDirectory from LDAP for more information.
If users will use one proxy user or multiple eDirectory usernames to access LDAP, use iManager 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 last name or phone number.
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 commonName 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 Novell iManager, click the Roles and Tasks button .
Click LDAP > LDAP Overview > View LDAP Groups.
Click an LDAP Group object, then click Attribute Map.
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.
Click Apply, then click OK.
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 Novell iManager, click the Roles and Tasks button .
Click LDAP > LDAP Overview.
Click an LDAP Group object, then click Class Map.
Add, delete, or modify the classes you want.
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.
Click Apply, then click OK
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.
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 and then search for CommonName=Value, you will get back a commonName, which might be the same attribute value for 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.
LDAP Class Name | eDirectory Class Name |
---|---|
alias |
Alias |
groupOfNames |
Group |
mailGroup |
NSCP:mailGroup1 |
NOTE: The attributes with ;binary are security related. They are in the mapping table in case your application needs the name retrieved with ;binary. If you need it retrieved without ;binary, you can change the order of the mappings.
eDirectory contains a compatibility mode switch that allows nonstandard 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 nonstandard 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 nonstandard output format:
OID or Object Identifier is a string of octet digits that is required to add an attribute or objectclass of your own to an LDAP server.
To enable nonstandard schema output:
In Novell iManager, click the Roles and Tasks button .
Click LDAP > LDAP Overview.
Click View LDAP Servers, then click an LDAP Server object.
Click Searches, then click Enable old ADSI and Netscape Schema Output.
The nonstandard output does not conform to the current IETF defined standards for LDAP, but it works with the current ADSI and old Netscape clients.
Click Apply, click Information, then click Refresh.
LDAP and eDirectory use different syntaxes. Some important differences include the following:
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:
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.
For example:
CN=Pralines\+Cream,OU=Flavors,O=MFG (CN is Pralines+Cream)
CN=DCardinal,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 UID. 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 UID 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 UID=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 Object Identifier (OID), which is a string of octet digits that are required to add an attribute or objectclass of your own to an LDAP server. 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 loads 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 rootDSE. RootDSE (DSA [Directory System Agent] Specific Entry) is an entry that is located at the root of the Directory Information Tree (DIT). For more information, see Getting Information about the LDAP Server.
For a list of supported LDAP controls and extensions, see LDAP Controls and LDAP Extensions in the LDAP and NDS Integration Guide.