14.7 Authentication and Security

14.7.1 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 1.0 has backward compatibility with SSLv2 and v3.

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

  2. Click LDAP > LDAP Options > 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.

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

14.7.3 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

0

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.

1

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.

2

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 NetIQ Modular Authentication Services (NMAS). The following figure illustrates these objects in iManager:

SSL objects

The installation automatically associates one of those certificates with the LDAP server. In NetIQ 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 NetIQ 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:

  • The LDAP server must know the server's KMO

  • You connect to the secure port or start TLS after connecting to the clear port

After you reconfigure the LDAP server, refresh the server. See Refreshing the LDAP Server. iManager automatically refreshes the server.

14.7.4 Configuring the Client for TLS

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

IMPORTANT:eDirectory 9.1 onwards, all LDAP utilities including ndsindex and ice will accept certificates in .PEM format only. For more information on how to use the .PEM certificates in LDAP operations, see Using LDAP Tools on Linux.

When an eDirectory tree is configured, by default the configuration creates:

  • A certificate authority for the tree (the tree CA).

  • A KMO from the tree CA.

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. IE has one way, and ICE has another way. These are different LDAP clients. Each client has its method for locating the certificates that it trusts.

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

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

  2. Click LDAP > LDAP Options.

  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.

14.7.7 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 supports multiple certificate authorities. NetIQ'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.

14.7.8 Creating and Using LDAP Proxy Users

NetIQ 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 NetIQ iManager, the value is named the Proxy User field. The following figure illustrates this field in NetIQ 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 Linux 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 NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click Directory 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 Options > 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.

14.7.9 Using SASL

Simple Authentication and Security Layer (SASL) is a mechanism for adding authentication support and data security services to connection-based protocols through different mechanisms. It presents a well-formed interface between the protocols and mechanisms. In addition, it provides a protocol for securing subsequent protocol exchanges within a data security layer along with data integrity, data confidentiality, and other services.

SASL is designed to allow new protocols to reuse the existing mechanisms without requiring redesign of the mechanisms, and it also allows existing protocols to make use of new mechanisms without the redesign of protocols. To use SASL, each protocol provides a method for identifying which mechanism is to be used, a method for exchange of mechanism-specific server-challenges and client-responses, and a method for communicating the outcome of the authentication exchange.

SASL mechanisms are named by strings, consisting of uppercase letters, digits, hyphens, and underscores. SASL mechanism names must be registered with the Internet Assigned Numbers Authority (IANA).

If a server supports the requested mechanism, it initiates an authentication protocol exchange. This consists of a series of server challenges and client responses that are specific to the requested mechanism. During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity from the client to server, and negotiates the use of a mechanism-specific security layer. If the use of a security layer is agreed upon, then the mechanism must also define or negotiate the maximum cipher-text buffer size that each side is able to receive.

The LDAP server supports the following mechanisms:

These mechanisms are installed on the server during an eDirectory installation or upgrade. However, on Linux, the nmasinst utility must be used to install the NMAS methods.

As specified above, 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 are the registered mechanisms, the correct naming conventions must be used to make use of them.

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

DIGEST-MD5

LDAP supports the DIGEST-MD5 mechanism through the bind request. Instead of requesting an LDAP simple bind (DN and clear-text password), you request an LDAP SASL bind by providing the DN and the MD5 credentials. The DIGEST-MD5 mechanism does not require TLS. The LDAP server supports DIGEST-MD5 over clear and secure connections.

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 tries to sniff this connection, the password cannot be detected. However, the entire connection can be spoofed or hijacked.

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

EXTERNAL

The EXTERNAL mechanism informs the LDAP server that the user DN and credentials have already been supplied to the server. Therefore, the DN and credentials do not need to come across in the bind request.

The LDAP bind request uses the SASL EXTERNAL mechanism to instruct the server to do the following:

  • Ask an EXTERNAL layer what the credentials were

  • Authenticate the user with those credentials and user

After this is done, a secure handshake occurs. The LDAP server requests credentials from the client and the client passes them to the server, then the server receives the certificate that was passed from the client, passes the certificate to the NMAS module, and authenticates 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.The following could be possible 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.

NMAS_LOGIN

NetIQ Modular Authentication Service (NMAS) is a development framework that allows you to write applications that authenticate to the network using various login and authentication methods. The NMAS framework allows you to design a flexible and expandable login and authentication system using modular plug-in methods that leverage Novell International Cryptographic Infrastructure (NICI) and NetIQ Directory Services (eDirectory).

The NMAS_LOGIN mechanism provides the LDAP server with the biometrics capability of NMAS. For more information, see the NetIQ Modular Authentication Services NDK.

GSSAPI

The GSSAPI mechanism enables a Kerberos user to authenticate to an eDirectory server using a ticket, without needing to enter a separate LDAP user password. This functionality is targeted at LDAP application users in environments that already have the Kerberos infrastructure in place. Such users must be able to use the Kerberos server-issued tickets to authenticate to the LDAP server without providing a separate LDAP user password.

For information on configuring GSSAPI, refer to Section E.0, Configuring GSSAPI with eDirectory.

14.7.10 Using NMAS Based Logins for LDAP Authentication

The NMAS login is enabled by default in eDirectory. To disable the NMAS login, set NDSD_TRY_NMASLOGIN_FIRST to false.

NOTE:You must add all the environment variables required for the eDirectory service to run in the pre_ndsd_start_custom script on RHEL 7.x and SLES 12.x platforms.