S 4.104 LDAP Services for NDS

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrators

The Lightweight Directory Access Protocol (LDAP) has become the de facto standard for accessing directory information based on the X.500 standard via the Internet or an intranet. Novell Directory Services (NDS) is one of the LDAP directories whose main task is to be able to process a multiplicity of search operations at the same time. With the aid of NDS the administrator is able to create and manage all company employees and all resources available in the network as objects in a hierarchical directory tree. For example, users can be assigned access rights to Unix, Microsoft Windows NT or Novell Netware servers or other resources, such as access to the mailing system and printers. Previously, information had to be maintained in application-specific lists and consolidated beyond the various system boundaries. If directory-capable applications are used, a single point of administration is created, i.e. all information is maintained from one location.

All directory services based on X.500 use a Directory Access Protocol (DAP) to synchronise the directory information and to provide a communications interface between the various network components.

LDAP is a Directory Access Protocol whose primary task is the high-speed extraction of information, based on a lower protocol overhead. In this case not the whole of the OSI protocol stack is implemented; instead, LDAP is based directly on the TCP/IP protocol. As a consequence, the LDAP clients are far less complex than the DAP clients. As the implementation of LDAP is founded on the Internet standard RFC 1777, developers are able to use platform-independent application program interfaces (APIs). There is therefore no need to pay attention to manufacturer-specific notation, because the LDAP server takes care of converting an LDAP request to the necessary format.

LDAP version 2 is implemented in LDAP Services for NDS for Netware 4.11; this deals with client-to-directory communication. Version 3 of LDAP contains specifications on directory-to-directory communication, for example on replication and the synchronisation of directory information in the network. To date, though, the standard (RFC 2551) has not been definitively adopted. An implementation of LDAP version 3 is used under Netware 5.

LDAP Services for NDS assumes the role of an intermediary between NDS, which of course has to be installed, and the LDAP client. The client sends an LDAP request to the server on which LDAP Services is running. The request is accepted and converted into an NDS request by LDAP Services for NDS. NDS evaluates the request and returns the requested information to LDAP Services for NDS. In turn, this uses the NDS response to generate an LDAP response, and forwards it to the client.

Novell itself does not offer an LDAP client. Currently the most common clients are browsers, such as Netscape Communicator, which have a corresponding LDAP interface. There are however also other, freely available LDAP clients in the Internet. Certain things have to be taken into consideration before using these clients, though. For example, Netscape Communicator is not able to grant access to LDAP servers which require a user name and a password. LDAP Services for NDS therefore recognises a user who uses this browser as a client as an anonymous user, and by default makes him a trustee of [Public], which typically comprises only a browse right for NDS. If additional rights are required, a proxy user must be set up who has the corresponding NDS rights. As well as this, the proxy user feature must also be enabled in the LDAP group object.

As LDAP Services for NDS is fully integrated into NDS, an extension of the NDS scheme must be set up at the time of installation. This can only be done via an account with supervisor rights for the [Root] object. During installation of the first LDAP server in an NDS tree, the database scheme of NDS is extended so as to make two new NDS objects LDAP Server and LDAP Group available. LDAP Services for NDS is configured with the aid of these two objects. If additional LDAP servers are installed in this NDS tree, it is not necessary to install the scheme extension again because NDS already has the current database scheme.

The configuration of LDAP Services for NDS is stipulated in the properties of the two objects, LDAP Server and LDAP Group. The settings must be made in accordance with the security strategy that has been devised. Some of the properties that are particularly relevant to the security of the system are examined below.

Log file size limit (LDAP Server object)

This property can be used to set the maximum size of the log file specified in the Log filename property. When the log file reaches the size specified here, the information in the Log filename file is copied to the file specified under Backup log file. All new log data is written to the Log filename file.

Default: 1.000.000

Minimum: 0 (unlimited file size)

Maximum: 4.294.967.295

If the size is set to zero, there is no size limit for the log file. In this case the file should not be stored on the SYS volume because the file is liable to grow to such an extent that the available storage space on the volume will be fully taken up. Inconsistencies within the NDS may occur as a result, and the availability of the server is reduced.

In the LDAP Group object the following properties are particularly relevant to security:

Suffix

The Suffix box is where the subtree is defined that is made available to the LDAP clients. If this box is blank, the clients are granted access to the entire NDS tree, in other words from the [Root] object. If a client sends a request to the server relating to an object outside the defined subtree, an error is returned, unless a value is entered in the Referral box.

Referral

A uniform resource locator (URL) of an alternative LDAP server can be entered in this text box. If for example a client sends a request to the server which the latter cannot reply to because the Suffix was set, this URL is returned to the LDAP client. The client is then able to forward the request to the specified server.

Enable NDS User Bind

If this check box is activated, a user has to authenticate himself with his NDS password when issuing a bind request. The passwords are not encrypted between the LDAP client and the LDAP server, however, i.e. they are transmitted across the network as plain text. Given a suitable network monitor (LANalyzer), an attacker is therefore in a position to spy out these passwords in this way. For security reasons this setting should not be used, unless you are using accounts that have been set up specifically for LDAP accesses and apart from that have no further rights in NDS nor with respect to the Netware file system.

Proxy Username

The proxy user is an NDS account that does not require a password, nor a password change. When an anonymous bind is requested (a connection setup without a user name or password), the LDAP server authenticates this request with the Proxy Username in NDS. Typically, the rights of these proxy users will be heavily restricted. If no Proxy Username has been defined, however, these anonymous binds will be validated as a user [Public] and will therefore also be given the corresponding rights.

LDAP Services for NDS obtains an additional security feature via the Access Control Page: the Access Control List (ACL). The LDAP ACL defines the access rights to the LDAP object properties for users and groups. The LDAP server uses the ACL to establish whether a user request is forwarded to the NDS or rejected. If a user has the appropriate rights, the request is forwarded to the NDS. In turn, NDS checks on the basis of the NDS rights whether the request will be processed or rejected.

Rights can be assigned to the users via the LDAP ACL dialog window. The following levels are possible:

None

If this option is activated, the user is granted no rights of any kind to the NDS tree.

Search

This right allows the user to search for LDAP object properties. These must be defined in the Access To list, however. Access to properties can be explicitly enabled by clicking on the Add button.

Compare

Assignment of this right enables the user to compare LDAP object property values with the corresponding NDS object property values.

Read

If a user has the Read right, he is permitted to view the LDAP property values defined in the Access To list. The Read right includes the Search right and the Compare right.

Write

If a user has the Write right, he can write the LDAP property values defined in the Access To list. The Write right includes the Search, Compare and Read rights.

Over and above these five security access levels, access can be restricted yet further. For example, an entry can be made in the IP Address field to specify that a request can only be accepted from one IP address or a group of IP addresses.