Friday June 16, 2006
Friday June 16, 2006 LDAP Authentication Mechanisms
One of the most common tasks that the Directory Server is given is to serve as the repository for authenticating users. Traditionally, this is accomplished by binding to the server using simple authentication, but there are other options that may have their own advantages and disadvantages. These options come in the form of SASL mechanisms, where SASL is the Simple Authentication Security Layer defined in RFC 2222 and recently updated in RFC 4422. Many people may not be familiar with all of these methods, so I'll briefly describe them here.Note that this post isn't going to go into a lot of detail about how to configure the server or clients to perform these types of authentication. The Directory Server Administration Guide, and in particular Chapter 11: Managing Authentication and Encryption provides instructions for doing this.
LDAP simple authentication is aptly-named because it is a very straightforward mechanism. A user binding with simple authentication needs only to provide their DN and password. This is the most widely supported LDAP authentication method, so chances are pretty good that if your application supports authenticating against a Directory Server then it can use simple authentication. However, there are a couple of disadvantages to using simple authentication. The first is that in order to authenticate the client must know the users's DN, which is not necessarily something that the end user is likely to know. However, this is generally overcome by first performing a search to find the user's entry (e.g., based on a uid or e-mail address), and then take the DN from that user entry to use in the simple authentication. The second disadvantage is that simple authentication does nothing to protect the user's password as it is transmitted over the network, so anyone that can listen in can see the password in the clear. This can be overcome by encrypting the communication with the server (e.g., using SSL/TLS to perform the encryption at the client-server level, or using IPsec to achieve it at a host or network level).
Even though it is a relatively straightforward process to encrypt the communication between the client and the server to protect the credentials used for simple authentication, this does incur a cost for the entire set of communication because it is not possible to encrypt only the bind request (it is possible to use the StartTLS extended operation to encrypt only a portion of the interaction between the client and the server, but it also requires that any existing authentication be disregarded when transitioning from secure to insecure communication). In some cases, encrypting the entire session between the client and the server may add an undesirable amount of overhead if the password is the only thing that would need to be protected. In this case, an alternative that you could consider would be the use of SASL authentication with the DIGEST-MD5 mechanism.
The DIGEST-MD5 mechanism is a password-based authentication method whose primary benefit is that it doesn't expose the bind password to anyone that might happen to be listening in on the network communication between the client and the server. It is able to accomplish this because the password itself is never transferred, but rather just information that proves the client does know the user's real password. It is a little more complicated than the simple authentication process because it requires a multi-stage bind (basically, the client and server both come up with some random data and then use that in combination with the user's password to generate an MD5 hash), but ultimately the password is never exposed in the clear, and the mechanism is relatively secure against replay and man-in-the-middle attacks. It also has the benefit of being able to authenticate using an authorization ID (which can specify either a user ID or a full DN), which means that the client doesn't necessarily have to do a search first in order to get the user's DN. The primary downside of using the DIGEST-MD5 authentication mechanism is that it requires the Directory Server to know the clear-text password for the user. For our current server, this means that the values must be stored in the clear (i.e., using the "CLEAR" scheme). This is an unacceptable proposition in most cases because of the dangers associated with keeping the passwords in the clear, although we will likely eliminate many of these concerns in the future by adding password storage schemes based on reversible encryption.
While passwords are certainly very commonly used in LDAP authentication, they are certainly not the only form of credentials that are available. In particular, our Directory Server supports two other SASL mechanisms that don't directly involve passwords: EXTERNAL and GSSAPI. The EXTERNAL mechanism tells the Directory Server that the user wants to authenticate based on some other identifying information that may be available. In our Directory Server, this currently is available only for client connections that have been established using SSL where the client has provided its own certificate to the server (i.e., SSL client authentication). The Directory Server can use the information in that certificate to map it to a user's entry and can accept that as authentication. Since this is based on relatively strong cryptographic methods, it can be significantly more secure than using passwords, but it is also more complicated to manage because each user must have their own certificate and the Directory Server must have enough information available to determine whether to trust that certificate. On a large scale, this generally involves a PKI deployment and may also require storing public keys in user entries for use in the validation process, and this can be a cumbersome process to set up and manage.
The SASL GSSAPI mechanism allows a user to authenticate to the Directory Server through Kerberos V. For cases in which Kerberos is already deployed and used as a single sign-on solution for other applications in the environment, this can be a relatively simple way to expand that to include authenticating to the Directory Server. In that case, the server will require its own Kerberos key and must be able to map the client principals to user entries for the authentication process, but it may be an attractive option for environments where Kerberos is already widely deployed.
There are a number of other SASL mechanisms that have been defined, but at present our server only supports EXTERNAL, DIGEST-MD5, and GSSAPI. We are considering adding support for other mechanisms like CRAM-MD5 and PLAIN in future releases, but if there are other mechanisms that you might find useful then that would be helpful for us to know as well.
Posted by cn_equals_directory_manager ( Jun 16 2006, 02:02:12 PM CDT ) Permalink Comments [2]
Post a Comment:
Comments are closed for this entry.
| Archives | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Language | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Links | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Referrers | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Today's Page Hits: 34 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Posted by Darren Moffat on June 21, 2006 at 07:29 AM CDT #
I've only configured GSSAPI against SEAM, so I honestly don't know if there would be any differences in the process if you were using Active Directory as the KDC. But that documentation is the starting point that I would use if I needed to set it up.
Posted by Neil Wilson on June 21, 2006 at 07:50 AM CDT #