Authentication and Security

This section contains information on the following:

Requiring TLS for Simple Binds with Passwords

Secure Socket Layer (SSL) 3.1 was released through Netscape. IETF took ownership for that standard by implementing Transport Layer Security (TLS) 1.0.

TLS allows for connections to be encrypted in the Session layer. The encrypted port doesn't have to be used to get a TLS connection. There's another way: port 636 is the implied TLS port and the LDAP server automatically starts a TLS session when a client connects to the secure port.

A client can also connect to the clear-text port and later use TLS to upgrade the connection to an encrypted connection.

To require TLS for simple binds with passwords:

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

  2. Click LDAP > LDAP Overview > View LDAP Groups.

  3. Click the LDAP Group object, then click Information on the General tab.

  4. Check the Require TLS for Simple Binds with Passwords check box.

    The Require TLS for Simple Binds with Passwords check box
  5. Click Apply, then click OK.

Starting and Stopping TLS

The extended LDAP operation STARTTLS enables you to upgrade from a clear connection to an encrypted connection. This upgrade was new to eDirectory 8.7.

When you use the encrypted connection, the entire packet is encrypted. Therefore, sniffers are unable to diagnose data sent across the network.

Scenario: Using STARTTLS---You create a clear connection (to port 389) and do some anonymous searches. However, when you get into secure data, you prefer to start a TLS session. You issue a STARTTLS extended operation to upgrade from a clear connection to an encrypted connection. Your data is secure.

You stop TLS to turn an encrypted session into a clear connection. A clear connection requires less overhead because data to and from the client is not encrypted and decrypted. Therefore, data moves faster when you use a clear connection. At this point, the connection is downgraded to Anonymous.

When you authenticate, you use the LDAP Bind operation. Bind establishes your ID based on your provided credentials. When you stop TLS, the LDAP service removes any authentication previously established. Your authentication state changes to Anonymous. Therefore, if you want a state other than Anonymous you must reauthenticate.

Scenario: Reauthenticating---Henri runs STOPTLS. His status changes to Anonymous. To access and use his files on the Net, Henri runs the Bind command, provides his login credentials, is authenticated, and continues working in clear text on the Internet.

Configuring the Server for TLS

When a TLS session is instantiated, a handshake occurs. The server and the client exchange data. The server determines how the handshake occurs. To establish that the server is legitimate, the server always sends the server's certificate to the client. This handshake guarantees to the client that the server is indeed the expected server.

To require that the client also establish legitimacy, you set a value on the server. This attribute is ldapTLSVerifyClientCertificate.

Value Description


Off. During a handshake, the server provides a certificate to the client. The server never requires the client to send a certificate. The client can use or ignore the certificate. A secure session is established.


During the handshake, the server provides a certificate to the client and requests a certificate from the client. The client can choose to send its certificate back. The client's certificate is validated. If the server cannot validate the client's certificate, the connection is terminated.

If the client doesn't send a certificate, the server maintains the connection.


During the handshake, the server requests and requires a certificate from the client. If the client does not provide a certificate, or if the certificate can't be validated, the connection is terminated.

Before the server can support TLS, you must provide the server with an X.509 certificate that the server can use to establish its legitimacy.

This certificate is automatically provided during the eDirectory installation. During installation, Key Material objects are created as part of Public Key Infrastructure (PKI) and Novell Modular Authentication Services (NMASTM). The following figure illustrates these objects in iManager:

SSL objects

The installation automatically associates one of those certificates with the LDAP server. In Novell iManager, the Connections tab for the LDAP Server object displays a DN. This DN represents the X.509 certificate. The Server Certificate field in the following figure illustrates this DN.

Server Certificate field

In Novell iManager, you can browse to the Key Material object (KMO) certificates. Using the drop-down list, you can change to a different certificate. Either the DNS or the IP certificate will work.

As part of the validation, the server should validate the name (the hard IP address or the DN) that is in the certificate.

To establish a TLS connection, ensure the following:

After you reconfigure the LDAP server, refresh the server. See Refreshing the LDAP Server. ConsoleOne and Novell iManager automatically refresh the server.

Configuring the Client for TLS

An LDAP client is an application (for example, Netscape Communicator, Internet Explorer, or ICE). The client must understand the certificate authority that LDAP server uses.

When a server is added into an eDirectory tree, by default the installation creates

The LDAP server uses this certificate provider.

The client needs to import a certificate that the client will trust so that the client can validate the tree CA that the LDAP server claims to be using. The client must import a certificate from the server so that whenever the server sends its certificate, the client can validate it and verify that the server is who it claims to be.

So that the client can get a secure connection, the client must be configured before the connection.

The way that the client imports the certificate differs, based on the kind of application being used. Each application must have a method to import a certificate. Netscape browser has one way, IE has another way, and ICE has a third way. These are three different LDAP clients. Each client has its method for locating the certificates that it trusts.

Exporting the Trusted Root

You can automatically export the trusted root while accepting the certificate server.

To manually export the trusted root, see Exporting a Trusted Root or Public Key Certificate.

The Export functionality will create the specified file. Although you can modify the filename, it's a good idea to leave "DNS" or "IP" in the filename, so that you can recognize the type of material object. Also leave the servername.

Install the self-assigned CA in all browsers that establish secure LDAP connections to eDirectory.

If you are using the certificate with Microsoft products (for example, Internet Explorer), leave the .der extension.

If applications or SDKs require the certificate, import it into a certificate database.

Internet Explorer 5 exports root certificates automatically with a registry update. The traditional .X509 extension used by Microsoft is required.

Authenticating with a Client Certificate

Mutual Authentication requires a TLS session and a client certificate. Both the server and the client must verify that they are the objects that they claim to be. The client certificate was validated at the Transport layer. However, at the LDAP protocol layer, the client is anonymous until the client issues an LDAP bind request.

Up to this point, the client has proven its authenticity to the server but not to LDAP. If a client wants to authenticate as the identity contained in the client certificate, the client binds by using the SASL EXTERNAL mechanism.

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

  2. Click LDAP > LDAP Overview.

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

  4. Click Connections.

  5. In the Transport Layer Security section, select the drop-down menu for Client Certificate, then select Required.

    This enables Mutual Authentication.

  6. Click Apply, then click OK.

Using Certificate Authorities from Third-Party Providers

During the eDirectory installation, the LDAP server receives a tree Certificate Authority (CA). The LDAP Key Material object is based on that CA. Any certificate that a client sends to the LDAP server must be able to be validated through that tree CA.

LDAP Services for eDirectory 8.7.3 supports multiple certificate authorities. Novell's tree CA is just one certificate authority. The LDAP server might have other CAs (for example, from VeriSign*, an external company.) This additional CA is also a trusted root.

To configure the LDAP server to use multiple certificate authorities, set the ldapTLSTrustedRootContainer attribute on the LDAP Server object. By referencing multiple certificate authorities, the LDAP server allows a client to use a certificate from an external authority.

Creating and Using LDAP Proxy Users

Novell eDirectory assigns a [Public] identity to users who are not authenticated. In the LDAP protocol, an unauthenticated user is an Anonymous user. By default, the LDAP server grants Anonymous users the rights of the [Public] identity. These rights enable unauthenticated eDirectory and Anonymous LDAP users to browse eDirectory by using [Public] rights.

The LDAP server also allows Anonymous users to use the rights of a different proxy user. That value is located on the LDAP Group object. In Novell iManager, the value is named the Proxy User field. In ConsoleOne, the value is named the Proxy Username field. The following figure illustrates this field in Novell iManager.

Proxy User field

The proxy user is a Distinguished Name. You can grant that proxy identity different rights than the Public identity has. With the proxy user, you can control LDAP Anonymous access to specific containers in the eDirectory tree.

NOTE:  Don't set login restrictions for the proxy user unless you want to have them apply to all Anonymous LDAP users.

Scenario: Setting Up an NLDAP Proxy User---Digital Airlines has contracted with DataSure, a research group. DataSure will use LDAP to access and store research on DigitalAir43, a NetWare 6 server at Digital Airlines. You don't want DataSure to have Public rights to directories on DigitalAir43.

Therefore, you create an LDAP proxy user and assign that user specific rights to the DataSure directory. You populate the proxy Distinguished Name on the LDAP Group object and refresh the server. The server automatically starts using the proxy user rights for any new or existing Anonymous users.

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

  2. Click eDirectory Administration > Create Object, then create a proxy user (for example, LDAPProxy).

  3. Assign a null password to that user.

  4. (Optional) Assign the proxy user rights to specified directories.

  5. Click LDAP > LDAP Overview > View LDAP Groups > the LDAP Group object.

  6. In the Proxy User field, click the Browse button, browse to and select the LDAPProxy user, then click OK.

Using SASL

Simple Authentication and Security Layer (SASL) defines various authentication mechanisms that must be registered with the Internet Assigned Numbers Authority (IANA). The LDAP server supports the following mechanisms:

These mechanisms are installed on the server during an eDirectory installation or upgrade. However, on UNIX, you have to run the nmasinst utility to install NMAS methods.

The LDAP server queries SASL for the installed mechanisms when it gets its configuration, and automatically supports whatever is installed. The LDAP server also reports the current supported SASL mechanisms in its rootDSE by using the supportedSASLMechanisms attribute.

Because these mechanisms are registered, you must enter them using all uppercase characters. Otherwise, the LDAP server won't recognize them.

The LDAP bind protocol allows the client to use various SASL mechanisms for authentication. When the application uses the LDAP bind API, it would either need to choose the simple bind and supply a DN and password, or choose the SASL bind and supply the SASL mechanism name in upper case, and any associated SASL credentials required by the mechanism.


The DIGEST-MD5 mechanism does not require TLS. The LDAP server supports DIGEST-MD5 over clear and secure connections.

LDAP supports SASL mechanisms in the bind request. Instead of requesting an LDAP simple bind (DN and clear-text password), you request an LDAP SASL bind. This request provides a DN and MD5 credentials.

MD5 provides an encrypted hash of passwords. Passwords are encrypted even on clear connections. Therefore, the LDAP server accepts passwords that use MD5 on either the clear-text or encrypted port.

If someone sniffs this connection, the password can't be detected. However, the entire connection can be spoofed or hijacked.

This mechanism is an LDAP SASL bind (and not a simple bind). Therefore, the LDAP server accepts these requests, even if you checked the Require TLS for Simple Binds with Passwords check box during installation.


The EXTERNAL mechanism informs the LDAP server that a user's DN and credentials have already been supplied to the server. Therefore, the DN and credentials don't need to come across in the bind request.

The LDAP bind request using the SASL EXTERNAL mechanism instructs the server to do the following:

  • Ask an EXTERNAL layer what the credentials were
  • Authenticate the user as those credentials and user

A secure handshake has occurred. The server requested credentials from the client and the client passed them to the server. The LDAP server received the certificate that was passed from the client, passed the certificate to the NMAS module, and authenticated the user as whatever DN was supplied in the certificate.

Having a certificate with a usable DN requires some setup on the client. For information about setting up the certificate, see the NMAS online documentation.

Even if the client sends an EXTERNAL mechanism, the LDAP server could fail the request. Novell iMonitor can provide the reasons for failure:

  • The connection is not secure.
  • Although the connection is secure, the client did not provide the required certificate during the handshake.
  • The SASL module is unavailable.
  • The client failed to check the rootDSE before sending the request.


The NMAS_LOGIN mechanism provides the LDAP server with the biometrics capability of NMAS. For more information, see the Novell NDK.

When the server comes up, the LDAP server initializes with the SASL module and then asks the SASL module which mechanisms are available to the LDAP server.

The client can query the rootDSE to find out the supported attribute for the mechanism. Then the LDAP server displays the supported mechanisms.