13.2 Understanding How LDAP Works with eDirectory

This section explains the following:

13.2.1 Connecting to eDirectory from LDAP

All LDAP clients bind (connect) to NetIQ eDirectory as one of the following types of users:

  • [Public] User (Anonymous Bind)

  • Proxy User (Proxy User Anonymous Bind)

  • NDS or eDirectory User (NDS User Bind)

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.

You can configure a timeout for the write blocked connections from LDAP clients by using the NDSD_NLDAP_WRITEBLOCK_TIMEOUT environment variable. This variable defines the time interval for which a connection between a LDAP client and eDirectory server remains open for the client to read the data from the server. If the connection is blocked and the LDAP client is unable to read the data within the specified time, the connection is considered invalid and subsequently closed. The value must be provided in terms of seconds for this variable as shown in the below example:

NDSD_NLDAP_WRITEBLOCK_TIMEOUT=<seconds>NDSD_NLDAP_WRITEBLOCK_TIMEOUT=60

The default value is 60 seconds.

NOTE:From eDirectory 9.2.6 and onward, the NDSD_NLDAP_WRITEBLOCK_TIMEOUT environment variable is applicable to both read and write blocked connections from LDAP clients. In the previous version, that is eDirectory 9.2.5, this variable applied to write blocked connections only.

Connecting As a [Public] User

An anonymous bind is a connection that does not contain a user name 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.

Connecting As a Proxy User

A proxy user anonymous bind is an anonymous connection linked to an eDirectory user name. 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:

  • All LDAP client access through anonymous binds is assigned through the Proxy User object.

  • Because LDAP clients do not supply passwords during anonymous binds, the Proxy User must have a null password and must not have any password restrictions (such as password change intervals). Do not force the password to expire or allow the Proxy User to change passwords.

  • You can limit the locations that the user can log in from by setting address restrictions for the Proxy User object.

  • The Proxy User object must be created in eDirectory and assigned rights to the eDirectory objects you want to publish. The default user rights provide Read access to a limited set of objects and attributes. Assign the Proxy User Read and Search rights to all objects and attributes in each subtree where access is needed.

  • The Proxy User object must be enabled on the General page of the LDAP Group object that configures LDAP Services for eDirectory. Because of this, there is only one Proxy User object for all servers in an LDAP group. For more information, see Configuring LDAP Objects.

  • You can grant a Proxy User object rights to All Properties (default) or Selected Properties.

To give the Proxy User rights to only selected properties:

  1. On the Identity Console home page, click the Rights Management tile.

  2. Click Trustee.

  3. Specify, or use the Search Object to find the name of the object whose trustee list you want to view, then click OK.

    The list of the trustees assigned to the selected object is displayed.

    Click Add Trustee , to assign a new trustee to the object. Select a Trustee from the list and click to remove it from the assignment.

  4. Select a trustee whose details to be modified as needed, then click Assigned Rights.

  5. On the Modify Trustee screen, assign the rights as needed and click Done.

  6. On the Modify Trustee screen, click Add Property, then check the Show All Properties in Schema check box.

  7. Select an inheritable right for the Proxy User and assign the rights as needed.

    To add additional inheritable rights, repeat Step 6 and Step 7.

    Select a the Property Name from the list and click to remove it from the assignment.

  8. Click Done., then click Apply.

    The Resource modified successfully! message appears.

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 user name.

  1. On the NetIQ Identity Console home page, click the LDAP Configuration tile.

  2. Click Create Object.

  3. On the Create LDAP Object page > specify the Name > select Type > search Context of an eDirectory User object.

  4. Click Create, then click OK.

Using the ldapconfig Utility on Linux

For example, LDAP Search Referral Usage specifies how the LDAP server processes LDAP referrals.

  1. At a system prompt, enter the following command:

    ldapconfig -s "LDAP:otherReferralUsage=1"

  2. Enter the User FDN (Fully Distinguished eDirectory User Name) and password.

Connecting As an NDS or eDirectory User

An eDirectory user bind is a connection that an LDAP client makes using a complete eDirectory user name 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:

  • eDirectory user binds are authenticated to eDirectory using the user name and password entered at the LDAP client.

  • The eDirectory user name and password used for LDAP client access can also be used for Novell Client access to eDirectory.

  • With non-TLS connections, the eDirectory password is transmitted in clear text on the path between the LDAP client and LDAP Services for eDirectory.

  • If clear text passwords are not enabled, all eDirectory bind requests that include a user name or password on non-TLS connections are rejected.

  • If an eDirectory user password has expired, eDirectory bind requests for that user are rejected.

Assigning eDirectory Rights for LDAP Clients

  1. Determine the type of user name the LDAP clients will use to access eDirectory:

    • [Public] User (Anonymous Bind)

    • Proxy User (Proxy User Anonymous Bind)

    • NDS User (NDS User Bind)

    See Connecting to eDirectory from LDAP for more information.

  2. When the users use one proxy user, or multiple eDirectory user names to access LDAP, use the LDAP to create these user names in eDirectory.

  3. Assign the appropriate eDirectory rights to the user names 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.

13.2.2 Class and Attribute Mappings

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.

Mapping LDAP Group Attributes

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.

  1. On the NetIQ Identity Console home page, click the LDAP Configuration tile.

  2. Click LDAP Group.

  3. On the Modify LDAP Group page > click Attribute Map drop-down.

  4. 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.

  5. Click Save.

Class Mapping in LDAP Groups

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.

NOTE:eDirectory does not propagate class mappings in LDAP Group objects across LDAP servers. To use the same class mapping on more than one server, manually add the mapping to all LDAP group objects in your environment.

  1. On the NetIQ Identity Console home page, click the LDAP Configuration tile.

  2. Click LDAP Group.

  3. On the Modify LDAP Group page > click Class Map drop-down.

  4. 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.

  5. Click Save.

Mapping LDAP Classes and Attributes

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.

Many-to-One Mappings

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.

Many-to-One Class Mappings

LDAP Class Name

eDirectory Class Name

alias aliasObject

Alias

groupOfNames groupOfUniqueNames group

Group

mailGroup rfc822mailgroup

NSCP:mailGroup1

Many-to-One Attribute Mappings

LDAP Attribute Name

eDirectory Attribute Name

c countryName

C

cn commonName

CN

uid userId

uniqueID

description multiLineDescription

Description

l localityname

L

member uniqueMember

Member

o organizationname

O

ou organizationalUnitName

OU

sn surname

Surname

st stateOrProvinceName

S

certificateRevocationList;binary certificateRevocationList

ndspkiCertificateRevocationList

authorityRevocationList;binary authorityRevocationList

authorityRevocationList

deltaRevocationList;binary deltaRevocationList

deltaRevocationList

cACertificate;binary cACertificate

cACertificate

crossCertificatePair;binary crossCertificatePair

crossCertificatePair

userCertificate;binary userCertificate

userCertificate

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.

13.2.3 Syntax Differences

LDAP and eDirectory use different syntaxes. Some important differences include the following:

Commas

LDAP uses commas as delimiters rather than periods. For example, a distinguished (or complete) name in eDirectory looks like this:

  • CN=JANEB.OU=MKTG.O=EMA

Using LDAP syntax, the same distinguished name would be

  • CN=JANEB,OU=MKTG,O=EMA

Some additional examples of LDAP distinguished names:

  • CN=Bill Williams,OU=PR,O=Bella Notte Corp
  • CN=Susan Jones,OU=Humanities,O=University College London,C=GB

Typeful 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).

Escape Character

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 2253 for more information.

Multiple Naming Attributes

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 UID 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.

13.2.4 Supported NetIQ LDAP Controls and Extensions

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 eDirectory Integration NDK.