15.2 Understanding How LDAP Works with eDirectory

This section explains the following:

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

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 Section 16.4, 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. In NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click Rights > Modify Trustees.

  3. Specify the name and context of the top container the Proxy User has rights over, or click Search button to browse to the container in question, then click OK.

  4. On the Modify Trustees screen, click Add Trustee.

  5. Browse to and click the Proxy User's object, then click OK.

  6. Click Assigned Rights to the left of the Proxy User you just added.

  7. Check the All Attributes Rights and Entry Rights check boxes, then click Delete Property.

  8. Click Add Property, then check the Show All Properties in Schema check box.

  9. 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 Step 8 and Step 9.

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

  1. In NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click LDAP > LDAP Options.

  3. Click View LDAP Groups.

  4. Click the name of an LDAP Group object to configure.

  5. Specify the name and context of an eDirectory User object in the Proxy User field.

  6. Click Apply, 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. If users will use one proxy user or multiple eDirectory user names to access LDAP, use iManager to create these user names in eDirectory or through LDAP.

  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.

15.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. In NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click LDAP > LDAP Options > View LDAP Groups.

  3. Click an LDAP Group object, then click Attribute Map.

  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 Apply, then click OK.

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. In NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click LDAP > LDAP Options.

  3. Click an LDAP Group object, then click Class Map.

  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 Apply, then click OK.

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.

15.2.3 Enabling Nonstandard Schema Output

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 older clients.

In nonstandard output format:

  • SYNTAX OID is single quoted.

  • No upper bounds are output.

  • No X- options are output.

  • If more than one name is present, only the first encountered is output.

  • Any attributes or classes without an OID defined will be output “attributename-oid” or “classname-oid” in lowercase.

  • Attributes or classes with a hyphen in the name and no defined OID are not output.

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:

  1. In NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click LDAP > LDAP Options.

  3. Click View LDAP Servers, then click an LDAP Server object.

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

  5. Click Apply, click Information, then click Refresh.

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

15.2.5 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 Section 16.10, 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.