Primary Authentication#
First, this is about Novell Directory Service (NDS) authentication and NOT LDAP.Servers often contain confidential data (for example, employee payroll and home addresses). On a network where all stations have access to the same network cable, making sure that only the right people can read and understand transmitted confidential data from the wire is problematic.
NDS is a distributed loosely coupled database containing directory information. Distributed usually means that multiple servers participate in maintaining the directory. Conversely, the directory is often used for Access Control to the secure services and data residing on those NDS servers. The directory does this by requiring an accessing client application to prove that its user is in fact someone who has rights to access requested services or data.
NDS Authentication is the process of proving one's identification to NDS. Authentication is accomplished by having an object in the NDS tree represent the user requesting access. This object contains or has access to all of the pertinent information about the user (i.e., NDS Password signature, encryption keys, etc.) that NDS needs to prove that a user communicating from a client machine is who he says he is.
When a user logs in to NDS through a client application (the Novell login utility can be considered such an application), the client application engages in a primary authentication protocol with NDS. If the user can provide the information which enables the application to successfully complete the primary authentication protocol (i.e., the password), the NetWare client and the NDS server will designate the connection between them to be authenticated. From that point on, the authenticated user will have access to every object which has the authenticated user object's distinguished name listed in its access control list or ACL (eDirectory Attribute).
Every object in NDS has an access control list. The entries in an object's ACL are distinguished names of other objects selected by an administrator. The administrator marks each object's ACL entries for various levels of access (i.e., read, write, and so on) to the object and its attributes.
Since administration objects often contain information required to gain access to services and data running on NDS servers, NDS becomes a finely grained access control mechanism for all of the data and services that are represented in its NDS Tree-name.
NDS Connection States#
The NetWare connection model has three states:- Unauthenticated
- Authenticated but not licensed
- Licensed
Obtaining an Authenticated Client-side Connection#
After an application (the login utility, for example) establishes an authenticated connection to a server, users should not be required to re-enter their name and password every time a different application needs to connect to the same server.To prevent this from happening when an application requests a connection handle, the NetWare client will check the connection reference table to see if a connection already exists to the specified server or tree. If one does exist, the NetWare client will create another handle to the connection reference and increment the usage count for the associated connection reference.
The application should test the connection handle to make sure that the connection it references is authenticated. If it is, the handle can be used as is. If not, the application must obtain a user name and password from the user to perform the authentication.
If an existing authenticated connection can be used, the application can obtain the new connection handle without ever asking the user for a password.
Background Authentication#
After any client station application establishes an authenticated connection to a server on a given NDS Tree-name, the client's user should not be required to re-enter her name and password every time a connection to a different server on the same NDS Tree-name is needed.Background authentication is the process NDS uses to obtain subsequent authenticated connections to different servers on the same NDS Tree-name.
After a primary authenticated connection between a client application and an NDS server has already been established, the other NDS servers in the tree do not know that the client has been authenticated. So, a connection request coming from the client to a different server on the same tree must be re-authenticated.
If the client indicates that it already has an authenticated connection to the server's tree, the receiving NDS server will attempt to verify that assertion. The NDS server and NetWare client perform this verification by following a secondary authentication protocol (Refer to Figure 7).
If the client has already established an authenticated connection to the tree, it will have some secret material (credentials) obtained as a side-effect of the primary authentication protocol. The secondary server will interact with the client and NDS to determine if the client possesses the credentials. If it does, the new connection is authenticated without the user having to re-enter a password. If it doesn't, the user will need to provide a password and name to log in. The details of how this is done are explained later in this article.
NetWare's Primary Authentication Protocol#
The goal of the primary NDS authentication protocol is to prove to an NDS server in the target NDS Tree-name, that the user has entered the correct password. The actual password is never passed over the wire in any form. Refer to Figure 8 for the following description of NetWare's primary NDS authentication protocol.- The user enters his or her name and password into a login dialog running on the workstation. The workstation sends the user's distinguished name encapsulated in an authentication request to the designated primary NDS server in the NDS Tree-name.
- The NDS server connected to the client uses the received distinguished name to obtain a reference to the user's object which contains the user's Public Key and Private Keys and password hash.
ndsChallenge is a random number that NDS has already generated to use in authentication transactions. The NDS server connected to the client generates another random number especially for this authentication session that we will call serverChallenge. The server then sends serverChallenge and ndsChallenge along with NDS's own Public Key to the client workstation. - The workstation hashes the password together with the received ndsChallenge to obtain a value,clientX. The workstation generates another random number we will call clientChallenge and hashes clientX with it to obtain clientY.
The workstation performs Asymmetric Key encryption on clientY and clientChallenge using the NDS public key and sends the message to the server.
The server performs asymmetric key decryption of the received message using the NDS private key to obtain clientY and clientChallenge.
The server hashes the password hash (obtained from the user's object) with ndsChallenge to obtain a value we will call serverX.
The server hashes serverX with clientChallenge to obtain serverY.
The server compares serverY with received clientY. If they are the same, then NDS determines that the client must have the correct password. - Using the user's encrypted private key (obtained from the user's object) and an authentication period timeout value, the server uses a variant of the Gillou-Quisquater algorithm to generate a key we will call shortTimeKey. The unique thing about this key is that it is equivalent to the user's private key but only for a limited length of time.
The server symmetric key encrypts the shortTimeKey using clientY as the secret key and sends the encrypted message to the workstation. Then it promptly throws the client's shortTimeKey and other authentication materials away. - The workstation performs Symmetric Key decryption on the received message using clientY as the secret key to obtain shortTimeKey.
The workstation is now authenticated to the NDS tree. It will use the shortTimeKey to background authenticate with other NDS servers on the NDS Tree-name until the shortTimeKey expires (the authenticated period timeout occurs).
NetWare Background Authentication Protocol]#
Once a client workstation has what we have referred to as a shortTimeKey, the client will be able to background authenticate to any other NDS server on the tree using the protocol described below. Refer to Figure 9 for the following discussion.The following steps are completed during server-side background authentication:
- The NetWare client will pass the user's distinguished name to the new server when any application on its workstation attempts to get a connection to a secondary NDS server participating on a tree to which the client has already performed a primary authentication. The client will also send the server an asymmetric key encrypted handshake message using the shortTimeKey it obtained from the primary authentication process as the private key.
- The NDS server uses the distinguished name from the client to obtain a reference to the user's object (which it can use to obtain the user's security information). The server then attempts to asymmetric key decrypt the client's handshake message using the user's public key. If the handshake message decrypts to a usable handshake, then the server determines that the client must possess a valid shortTimeKey and so must already be authenticated to the tree. If the client is authenticated, the NDS server authenticates the connection on its side and generates a sessionKey for symmetrical encryption and decryption on both sides. It then encrypts the sessionKey with the user's public key and sends it to the client.
- The workstation and NDS server will sign all messages sent to each other with the sessionKey to ensure the integrity of transmitted data.
Category#
%category eDirectory%More Information#
There might be more information for this subject on one of the following:- [#1] - NDS102: Authenticating to NDS Using C (NDAP) APIs
- based on information obtained 2016-02-03