This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding the SASL Mechanism
This section explains what the Simple authentication security layer (SASL) is, how this is implemented in Sun ONE Directory Server 5.2 software, and what authentication methods it supports.
The Simple Authentication and Security Layer (RFC 2222) is an Internet Specification (DRAFT standard like LDAPv3) and method for adding authentication support with an optional security layer to connection-based protocols, such as LDAPv3. SASL also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASLcompatible authentication mechanism can be used with any SASL-compatible protocol.
Before going into any more detail, let’s take a brief look at why SASL is so important. Before SASL was introduced, what happened when a new protocol was written that required authentication? The answer is similar to that of the Solaris Operating Environment before the Pluggable Authentication Module (PAM) feature was introduced. Developers of the protocol had to explicitly allow and define the individual authentication mechanism. You ended up with a protocol that was developed in such a way that it had a particular way of handling how a CRAM-MD5 login was handled, a particular way of handling how a Kerberos v4 login was handled, and so on.
One of the biggest concerns of this model was when a new authentication method was developed and the protocol needed to be modified to support this particular authentication mechanism. This led to a lengthy process before the new authentication mechanisms could be released, and if your application used more than one protocol, for example, an email client, the developer was required to support CRAM MD5 for IMAP and CRAM-MD5 for POP, which would potentially create many different authentication mechanisms to implement and support. This process, of course, was not desirable for the protocol or application developer in an ever-changing environment where new authentication mechanisms are always being developed.
What was needed was a mechanism whereby developers could simply have one framework to write to. This is where the Simple Authentication Security Layer (SASL) which is described in RFC 2222 comes in to its own and addresses some, but not all, of the above issues. As an example, not all forms of SASL mechanisms can be handled by simply linking with some external library. DIGEST-MD5 authentication is a very good example of this because while you can use an external library to handle all the negotiation and the work of verifying the password, it is necessary to establish some mapping between the identity provided by the user and an account in the directory server. SASL EXTERNAL is an even better example because in many cases it has to be handled entirely by the server.
The Simple Authentication and Security Layer (SASL), is a generic mechanism and framework for protocols to accomplish authentication. Applications such as the Sun ONE Directory Server software and Solaris OE Secured LDAP Clients use the SASL library as a means of informing the application how to accomplish the SASL protocol exchange, and what the results are.
SASL is a framework whereby SASL authentication mechanisms control the exact protocol exchange. For example, if you have two protocols (such as IMAP and POP) and a number of different ways of authenticating, SASL attempts to make it so that only n plus m different specifications need be written instead of n times m different specifications. With the Sun SASL library, the mechanisms need only be written once, and they’ll work with all servers that use them.
FIGURE 3-1 shows the SASL components.
)
Figure 3-1. SASL Components
SASL DIGEST-MD5
The basic idea of the SASL DIGEST-MD5 mechanism is that both the client and server have a shared secret which is namely the user’s password. Each side uses this secret together with nonces (defined on page 46) to prove to the other side that they do indeed know this shared secret without revealing the secret to the other side. If the client uses the wrong password, the server detects it. Similarly, if the server doesn’t know the secret, the client detects that.
The Sun ONE Directory Server version 5.2 software integrates a new SASL library (libsasl), which is based on the Cyrus CMU implementation. Through this SASL framework, the directory server supports DIGEST-MD5 and the GSSAPI (which implements Kerberos v5).
Currently the GSSAPI is only supported on the Solaris OE.
The SASL security feature is configurable through LDAP and is accessible through the entry cn=sasl, cn=security, cn=config. Using this entry, you can enable authentication mechanisms and also update the path where the SASL authentication mechanism is loaded by libsasl.
To solve the issue of mapping protocol identities to LDAP identities, there is a feature called identity mapping in the Sun ONE Directory Server 5.2 software. This feature maps from specific authentication protocols, such as DIGEST-MD5, GSSAPI, and HTTP, to an LDAP identity by applying mapping rules that are entirely customizable through LDAP. By default, there is an identity mapping for DIGEST-MD5 in the case where the client passes a dn as authid. It is possible to define as many mappings as you want. The identity mapping feature is described in the Sun ONE Directory Server 5.2 software documentation.
One of the important things to remember is that there is an authentication ID and an authorization (or proxy) ID. SASL also refers to the authorization ID as the user name. In the case when there is no proxy, the two identities are the same. Currently, the Sun ONE Directory Server 5.2 software does not support proxies through SASL.
The LDAPv3 Technical Specification (particularly RFC 2829), mandates the support of SASL DIGEST-MD5. Authenticating clients using the Digest authentication mechanism does not provide a strong authentication mechanism when compared to public key based mechanisms, but does prevent the much weaker and even more dangerous use of plain text passwords. In addition, the DIGEST-MD5 offers no confidentiality protection beyond protecting the actual password during the authentication phase. This means that the rest of the challenge and response, including the user’s name and authentication realm, are available to an eavesdropper. However, the DIGEST-MD5 method can be used to provide integrity and confidentiality on the connection after the authentication process has been completed.
The MD5 message-digest algorithm is primarily used in three areas of the Solaris 9 Operating Environment. The Secured LDAP Client, the kernel (TCP and IPsec), and the User (SLP and PPP). Ronald Rivest, who was at the time working at the Laboratory for Computer Science at the Massachusetts Institute of Technology, published MD5 as an RFC (RFC 1321) in April 1992.
When you send data over the wire, you are concerned with three general issues: security, authenticity, and integrity. The security of your data ensures that no one else can read your data. This issue is important in many organizations that have information that cannot be exposed to external sources. Authenticity guarantees knowledge of the originator of the data; in other words, where the data source is from. This issue is important in areas such as the legal world where authentication issues (like digital signatures) are of great importance. Lastly, integrity guarantees that the data has not been tampered with in any way when it was transmitted, thus determining whether the data you received was the same data that was actually sent.
It is also very important to understand that MD5 hashing only guarantees the integrity of the data if it is possible to guarantee the integrity and/or authenticity of the MD5 digest itself. That is, if you use an MD5 digest to guarantee the integrity of a file, you should not store the digest with the file because if the file data is compromised it is very easy for a new MD5 digest to be generated. Alternately (and this is the way that DIGEST-MD5 works), all or part of the digest can include some shared secret that is known only by the originator and valid recipients, but not by untrusted third parties.
The MD5 algorithm guarantees the integrity of your data by taking a bit pattern of arbitrary but finite length and producing a 128-bit fingerprint or message digest of that pattern. This pattern is always 128-bit, regardless of the length of the bit pattern. It is extremely unlikely for two different files to produce the same fingerprint, but because an MD5 hash only consists of 128 bits, there are theoretically an infinite number of bit sequences that when hashed using MD5 will produce the same digest. The MD5 algorithm is not complex and does not require large substitution tables. Security experts estimate that the difficulty of finding two-bit patterns having the same digest is 264 operations, and the difficulty of finding a bit pattern having predetermined digest is 2128 operations. It is computationally possible to determine a file based on its fingerprint, but it is not feasible based on current technology and techniques. This means that it is not possible for someone to figure out your data based on its MD5 fingerprint. Before we look at an example, we need to be aware that the Solaris 9 OE does not ship with the MD5 binary.
Take a look at an example of the output produced by MD5 on the binary file /usr/bin/crypt.
# md5-sparc /usr/bin/crypt
You should see output similar to the following:
MD5 (/usr/bin/crypt) = c54740de32d1903b78322a9be712a31d
In particular, the string c54740de32d1903b78322a9be712a31d is the fingerprint of /usr/bin/crypt:.
What happened in the above example is that the MD5 message-digest algorithm applied a mathematical algorithm to the binary crypt and produced the fingerprint. What you see is that you get the exact same fingerprint; if you do not, then you know that the binary has been altered in some way. Finally, since MD5 does not encrypt data, it is not restricted by any exportation laws, so you can distribute this tool freely anywhere in the world.
In the Solaris 9 OE, there is no md5 binary. What you will find is the /platform/sun4u/kernel/misc/md5 and /platform/sun4u/kernel/misc/sparcv9/md5 kernel modules, which export the standard MD5 calls to a user program. To obtain the md5 binary, download the following file:
Now that we have taken a look into what the MD5 message-digest is and how it works, it is time to apply this to how this actually translates and works in the Sun ONE Directory Server 5.2 software environment. This section introduces a new element that is discussed later in this chapter and called the Secured LDAP Client, which supports, and thus can be used to authenticate using DIGEST-MD5, to the Sun ONE Directory Server 5.2 software.
The following process describes how the Secured LDAP Client authenticates to the Sun ONE Directory Server 5.2 software using the SASL DIGEST-MD5 authentication mechanism.
-
Initial Authentication
This process starts with the Secured LDAP Client sending a bind request with either the SIMPLE or SASL method. In this context, if it’s SASL, the DIGEST-MD5 mechanism is specified. The DIGEST-MD5 authentication is a two-step bind operation.
The Secured LDAP Client issues a SASL DIGEST bind request, as well as requesting a SASL DIGEST-MD5 bind. While it is possible to specify the bind DN in the initial request, the DN should not be sent, but if it is, if should be ignored. Rather, the authorization ID (which may be a DN, but may also be basically any other kind of ID provided that it can be uniquely resolved to a user entry using the directory server’s identity mapping API) is provided by the client in the second stage of the bind request.
In this process, both sides can compute a shared secret, A1. A1 consists of a hash of the username, realm and password, which is concatenated with the directory server nonce and the directory client nonce. It is assumed that both the Secured LDAP client and directory server can obtain this hash, given the username and realm.
Although the directory server does need to have access to the clear text password in order for the client to use DIGEST-MD5 authentication, the attribute encryption feature of the Sun ONE Directory Server 5.2 software can at least somewhat mitigate the risk of having clear text passwords in the server by ensuring that they are not stored on disk in clear text (and therefore would not show up clearly in most backups or LDIF exports).
-
Digest Challenge Stage
The directory server starts by sending a challenge, whereby the data encoded in the challenge contains a string formatted according to the rules for a digestchallenge which is shown in the following example:
# From RFC 2831 "Digest SASL Mechanism" digest-challenge = 1#( realm | nonce | qop-options | stale | maxbuf | charset algorithm | cipher-opts | auth-param ) realm = "realm" "=" <"> realm-value <"> realm-value = qdstr-val nonce = "nonce" "=" <"> nonce-value <"> nonce-value = qdstr-val qop-options = "qop" "=" <"> qop-list <"> qop-list = 1#qop-value qop-value = "auth" | "auth-int" | "auth-conf" | token stale = "stale" "=" "true" maxbuf = "maxbuf" "=" maxbuf-value maxbuf-value = 1*DIGIT charset = "charset" "=" "utf-8" algorithm = "algorithm" "=" "md5-sess" cipher-opts = "cipher" "=" <"> 1#cipher-value <"> cipher-value = "3des" | "des" | "rc4-40" | "rc4" | "rc4-56" | token auth-param = token "=" ( token | quoted-string )As you can see in this example, there are various directives and values declared. The following is a short description of what each directive value means:
-
realm – A string which enables users to know which user name and password to use, in the event that they have different ones for different servers. Conceptually, it is the name of a collection of accounts that might include the user’s account. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be registered_users@gotham.news.example.com. This directive is optional; if not present, the client should solicit it from the user or be able to compute a default. A plausible default might be the realm supplied by the user when they logged in to the client system. Multiple realm directives are allowed, in which case the user or client must choose one as the realm for which to supply to username and password.
In the Sun ONE Directory Server 5.2 software, the realm is always the FQDN host name of the server that appears in the value of the nsslapd-localhost attribute in the cn=config entry.
-
nonce – The server’s nonce is a random 32-byte (256-bit) random number, which is platform dependent. The server-specified data string which must be different each time a digest-challenge is sent as part of initial authentication. It is recommended that this string be base64 or hexadecimal data. Because the string is passed as a quoted string, the double-quote character is not allowed unless escaped. The contents of the nonce are implementation dependent. The security of the implementation depends on a good choice. It is recommended that it contain at least 64 bits of entropy. The nonce is opaque to the client. This directive is required and must appear exactly once; if not present, or if multiple instances are present, the client should abort the authentication exchange.
-
qop-options – A quoted string of one or more tokens indicating the quality of protection values supported by the server. The value auth indicates authentication; the value auth-int indicates authentication with integrity protection; the value auth-conf indicates authentication with integrity protection and encryption. This directive is optional; if not present it defaults to auth. The client must ignore unrecognized options; if the client recognizes no option, it should abort the authentication exchange.
At present, the Sun ONE Directory Server software only supports auth qop.
-
stale – The stale directive is not used in initial authentication. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
At present, the Sun ONE Directory Server software does not support reauth, thus the server will not report a reauthentication stale because of a nonce timeout.
-
maxbuf – A number indicating the size of the largest buffer the server is able to receive when using auth-int or auth-conf. If this directive is missing, the default value is 65536. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
maxbuf is only used if confidentiality or integrity is specified. The Sun ONE Directory Server software sets this to 65535.
-
charset – This directive, if present, specifies that the server supports UTF-8 encoding for the username and password. If not present, the username and password must be encoded in ISO 8859-1 (of which US-ASCII is a subset). The directive is needed for backwards compatibility with HTTP Digest, which only supports ISO 8859-1. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
Only UTF-8 is supported. Any other charset will be rejected.
-
algorithm – This directive is required for backwards compatibility with HTTP Digest, which supports other algorithms. This directive is required and must appear exactly once; if not present, or if multiple instances are present, the client should abort the authentication exchange.
Only md5-sess is supported. Any other algorithm is rejected.
-
cipher-opts – A list of ciphers that the server supports. This directive must be present exactly once if auth-conf is offered in the qop-options directive, in which case implementation of the 3des and des modes is mandatory. The client must ignore unrecognized options; if the client recognizes no option, it should abort the authentication exchange.
-
des – Data Encryption Standard (DES) cipher [FIPS] in cipherblock chaining (CBC) mode with a 56-bit key.
-
3des – the triple DES cipher in CBC mode with EDE with the same key for each E stage (aka “two keys mode”) for a total key length of 112 bits.
-
rc4, rc4-40, rc4-56 – the RC4 cipher with a 128-bit, 40-bit, and 5-bit key, respectively.
No ciphers are currently offered by the Sun ONE Directory Server software because confidentiality is not yet supported.
-
-
auth-param – This construct allows for future extensions; it may appear more than once. The client must ignore any unrecognized directives. The size of a digest-challenge must be less than 2048 bytes.
No auth-param is sent by Sun ONE Directory Server software at this time.
-
-
Digest Response Stage
The Secured LDAP Client makes note of the digest-challenge and responds with a string formatted and computed according to the rules for a digestresponse. The Secured LDAP Client performs two MD5 hashes of the password with the challenge, and the realm. The challenge is the nonce; the realm is the realm containing the user’s account. This directive is required if the server provided any realms in the digest-challenge, in which case it may appear exactly once and its value should be one of those realms. If the directive is missing, realm value is set to the empty string when computing. The way to understand this, is to think of A1 which is the shared secret, whereby A1 is not sent over the wire, but where just a one way hash of it is. Time is not used in the response, but it is possible to generate a random nonce. In the Solaris 9 OE, use /dev/urandom. For SASL, users are considered to be located in a realm. It is an organizational item. In this case, the server’s specified realm (if there is one) is returned.
# From RFC 2831 "Digest SASL Mechanism" digest-response = 1#( username | realm | nonce | cnonce | nonce-count | qop | digest-uri | response | maxbuf | charset | cipher | authzid | auth-param ) username = "username" "=" <"> username-value <"> username-value = qdstr-val cnonce = "cnonce" "=" <"> cnonce-value <"> cnonce-value = qdstr-val nonce-count = "nc" "=" nc-value nc-value = 8LHEX qop = "qop" "=" qop-value digest-uri = "digest-uri" "=" <"> digest-uri-value <"> digest-uri-value = serv-type "/" host [ "/" serv-name ] serv-type = 1*ALPHA host = 1*( ALPHA | DIGIT | "-" | "." ) serv-name = host response = "response" "=" response-value response-value = 32LHEX LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" cipher = "cipher" "=" cipher-value authzid = "authzid" "=" <"> authzid-value <"> authzid-value = qdstr-valIn this example, there are various directives and values declared. Below is a short description of what each directive value means:
-
username – The user’s name in the specified realm, encoded according to the value of the charset directive. This directive is required and must be present exactly once; otherwise, authentication fails.
-
realm – The realm containing the user’s account. This directive is required if the server provided any realms in the digest-challenge, in which case it may appear exactly once and its value should be one of those realms. If the directive is missing, realm-value sets to the empty string when computing A1.
If the same realm is not specified in the response as was in the challenge (the server’s FQDN), then the authentication will fail.
-
nonce – The server-specified data string received in the preceding digestchallenge. This directive is required and must be present exactly once; otherwise, authentication fails.
The following is an example of what would be returned in the digest response:
# From RFC 2831 "Digest SASL Mechanism" HEX( KD ( HEX(H(A1)), { nonce-value, ":" nc-value, ":", cnonce-value, ":", qop-value, ":", HEX(H(A2)) })) This is where SASL digest-md5 will support authzid. NOTE: If the userid and authzid do not
match, then the Sun ONE Directory Server policy is to refuse the authentication.
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value }
Here the username (which must be UTF-8) is in the form that the directory server will map. For example: dn: ldap_dn or u: username or any other form for which you have matching rules defined.
The realm must be the FQDN of the directory server specified, which is sent to the client in the initial challenge stage, and the passwd would be the user’s password. H(x) is the DIGEST-MD5 hash of the string, and nonce value is supplied by the directory server. The cnonce is a nonce generated by the Secured LDAP Client.
# From RFC 2831 "Digest SASL Mechanism" A2 = { "AUTHENTICATE:", digest-uri-value } Let { a, b, ... } be the concatenation of the octet strings a, b, ... Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s. Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string k, a colon and the string s.
Let HEX (n) be the representation of the 16-octet MD5 hash n as a string of 32 hex digits (with alphabetic characters always in lower case, because MD5 is case sensitive).
Example: (S==Directory Server and C==Secured LDAP Client
S: realm="example.com",nonce="OA6MG9tEQGm2hh",qop="auth", algorithm=md5-sess,charset=utf-8
This is the directory server reply, indicating realm, nonce, quality of protection it offers, mechanisms, and a specified character set.
The Secured LDAP Client implementation only supports UTF-8.
C: charset=utf8,username="michaelh",realm="example.com", nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk", digest-uri="ldap/example.com", response=d388dad90d4bbd760a152321f2143af7,qop=auth
We reconfirm a number of elements, and add additional ones, such as cnonce and digest-uri. These are needed by the directory server to confirm the Secured LDAP Client’s password, which the directory server must know. The directory server has all the elements to be able to recompute the response.
The following step can be done if the directory server authentication is desired. However, The Secured LDAP Client currently does not check this, but instead retrieves this information from the server. Future versions of the Secured LDAP Client will check this.
S: rspauth=ea40f60335c427b5527b84dbabcdfff
The directory server calculates a new digest based on the above algorithm, to prove to the Secured LDAP Client that it knows the Secured LDAP Client password.
The size of a digest-response is 2048 bytes, which is the limit for all authentication exchanges for DIGEST-MD5.
-
-
The authentication exchange is completed once the directory server has sent the reauth packet.
Additionally, the DIGEST-MD5 authentication can be used for integrity and confidentiality. Currently neither the Sun ONE Directory Server 5.x software or the Secured LDAP Client supports this functionality.
It is important to understand that in the final exchange from the directory server to the client, the server is indicating that it too can calculate the shared secret A1. This will prove that this is a trusted server because it knows how to compute our shared secret.
The DIGEST-MD5 details are buried deep in the underlying libldap.so.5 library, which is used by the Secured LDAP Client (libsldap.so.1) library. In libsldap, we just call the LDAP client C API (which is currently a private Solaris OE interface), to bind. The rest is handled by the libldap library.
In summary, it is important to emphasize and understand that digests are one-way functions that are relatively easy to compute, but are extremely difficult to determine the possible inverses.
Setting up the SASL DIGEST-MD5 Authentication Mechanism
This procedure in this section uses the ldapsearch utility to authenticate against the Sun ONE Directory Server version 5.2 software, using the SASL DIGEST-MD5 authentication mechanism.
Before we get into the step-by-step instructions, it’s worth discussing how SASL DIGEST-MD5 is configured because it can be a little tricky.
The DIGEST-MD5 authentication mechanism is now a loadable authentication plug-in in the Sun ONE Directory Server version 5.2 software. Now the LDAP tools (such as ldapsearch) rely on the LDAP C-SDK that relies on the libsasl to perform a SASL bind. This means that the libsasl has to be aware of where to load the DIGEST-MD5 plug-in. When you install the Sun ONE Directory Server version 5.2 software, the plug-ins are copied under root_server/lib/sasl/libdigestmd5.so (for 32-bit plug-ins), and root_server/lib/sasl/64/libdigestmd5.so (for 64-bit plug-ins). The directory server needs to be able to load these plug-ins, and know where to get the plug-ins. To achieve this, the directory server looks at the attribute value dsSaslPluginsPath under the config entry cn=sasl,cn=security,cn=config in the dse.ldif. By default, the dsSaslPluginsPath is set up to point to root_server/lib/sasl. You can update this multi-valued attribute if you want to load plug-ins that are stored in another location.
On the client side, it’s a little bit different. First, a client might not be aware of where the directory server is installed. But the client needs to retrieve the SASL plug-ins anyway (at least the DIGEST-MD5 plug-in). In the Sun ONE Directory Server 5.2 software (on Solaris OE), the sasl library looks at /usr/lib/mps/sasl2 (for 32-bit plug-ins) and /usr/lib/mps/sparcv9 (for 64-bit plug-ins).
To Set up the SASL DIGEST-MD5 Authentication Mechanism
This procedure refers to the installation of the unbundled version of the Sun ONE Directory Server 5.2 software. On future versions of Solaris OE, the Sun ONE Directory Server 5.2 software might include a set of SVR4 packages that you install using the pkgadd command, and configure using the directoryserver utility. If you are installing the directory server from SVR4 packages, your installation steps are different than those listed here. Refer to the product documentation, and to “Differentiating Server and Client Versions” on page 191 for details.
-
Download the Sun ONE Directory Server version 5.2 software product from the http://www.sun.com web site.
-
Uncompress and extract the Sun ONE Directory Server software.
Extract in a directory other than the directory where you intend to install the server (not ServerRoot).
-
Run the idsktune utility
The idsktune utility is located in the root of the directory server distribution. Apply any necessary patches and modifications that are reported by idsktune. Once this is done, rerun the idsktune utility to confirm that all is as it should be before running the setup command.
-
Install and Configure the Sun ONE Directory Server version 5.2 software.
Refer to the product documentation for details.
-
Create user accounts in the directory server.
Use either the Sun ONE Directory Server Console or the MakeLDIF utility (this utility is available for download. See “Creating LDIF for Benchmarks” on page 479). This example uses the Java MakeLDIF utility.
# /usr/ccs/bin/make Building... Processed 1000 entries 1002 entries written to example-1k.ldif Writing filters to example-1k-filter-file.ldif Wrote 1000 equality filters for uid Wrote 1000 equality filters for givenname Wrote 1000 equality filters for sn Wrote 2479 substring filters for cn . . . dn: employeeNumber=1000,ou=People,dc=example,dc=com telephoneNumber: 1-510-315-4801 departmentNumber: 1000 sn: Ruble employeeType: Employee employeeNumber: 1000 objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mailRecipient objectclass: nsCalUser givenName: Lucille mailDeliveryOption: mailbox cn: Lucille Ruble initials: LR uid: lucyr mail: Lucy.Ruble@example.com userPassword: secret123 l: Menlo Park, United States st: CA description: This is the description for Lucille Ruble mailhost: mailhost.example.com nsCalHost: calhost.example.com -
Add the newly created user accounts to the directory server.
Example using the ldif2db utility using the default database back end:
$ cd /var/Sun/mps/slapd-instance $ ./stop-slapd $ ./ldif2db -n userRoot -i LDIF_file $ ./start-slapdExample output from ldif2db:
importing data ... [08/Jan/2003:15:46:27 +0000] - import userRoot: Index buffering enabled with bucket size 16 [08/Jan/2003:15:46:27 +0000] - import userRoot: Beginning import job... [08/Jan/2003:15:46:27 +0000] - import userRoot: Processing file "$(LDIF_FILE)" [08/Jan/2003:15:46:32 +0000] - import userRoot: Finished scanning file "$(LDIF_FILE)" (1002 entries) [08/Jan/2003:15:46:33 +0000] - import userRoot: Workers finished; cleaning up... [08/Jan/2003:15:46:36 +0000] - import userRoot: Workers cleaned up. [08/Jan/2003:15:46:36 +0000] - import userRoot: Cleaning up producer thread... [08/Jan/2003:15:46:36 +0000] - import userRoot: Indexing complete. Postprocessing... [08/Jan/2003:15:46:36 +0000] - import userRoot: Flushing caches... [08/Jan/2003:15:46:36 +0000] - import userRoot: Closing files... [08/Jan/2003:15:46:37 +0000] - import userRoot: Import complete. Processed 9002 entries in 10 seconds. (900.20 entries/sec)
Example using the ldapmodify utility:
Make sure that you use the ldapmodify command from the /var/Sun/mps/shared/bin directory, or some of the options may not be recognized because there are other versions of the ldapmodify command in the Solaris OE.
$ cd /var/Sun/mps/shared/bin $./ldapmodify -a -c -h directoryserver_hostname -p ldap_port -D "cn=Directory Manager" -w "password" -f LDIF_file -e /var/tmp/ldif.rejects 2> /var/tmp/ldapmodify.logIf the ldapmodify command is not executed as ./ldapmodify from the server-root/shared/bin directory, you must have LD_LIBRARY_PATH set to serverroot/lib so that ldapmodify finds the appropriate dynamic libraries.
In this example, the -e /var/tmp/ldif.rejects 2>/var/tmp/ldapmodify.log string is redirecting messages to a log file.
Example output from ldapmodify:
adding new entry employeeNumber=8995,ou=People,dc=example,dc=com adding new entry employeeNumber=8996,ou=People,dc=example,dc=com adding new entry employeeNumber=8997,ou=People,dc=example,dc=com adding new entry employeeNumber=8998,ou=People,dc=example,dc=com adding new entry employeeNumber=8999,ou=People,dc=example,dc=com adding new entry employeeNumber=9000,ou=People,dc=example,dc=com . . .
Example output from the access log:
[08/Jan/2003:14:57:49 +0000] conn=24 op=997 msgId=998 - ADD dn= "employeeNumber=8995,ou=People,dc=example,dc=com" [08/Jan/2003:14:57:49 +0000] conn=24 op=997 msgId=998 - RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2003:14:57:49 +0000] conn=24 op=998 msgId=999 - ADD dn= "employeeNumber=8996,ou=People,dc=example,dc=com" [08/Jan/2003:14:57:49 +0000] conn=24 op=998 msgId=999 - RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2003:14:57:49 +0000] conn=24 op=999 msgId=1000 - ADD dn= "employeeNumber=8997,ou=People,dc=example,dc=com" [08/Jan/2003:14:57:49 +0000] conn=24 op=1000 msgId=1001 - ADD dn= "employeeNumber=8998,ou=People,dc=example,dc=com" [08/Jan/2003:14:57:49 +0000] conn=24 op=999 msgId=1000 - RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2003:14:57:49 +0000] conn=24 op=1000 msgId=1001 - RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2003:14:57:49 +0000] conn=24 op=1001 msgId=1002 - ADD dn= "employeeNumber=8999,ou=People,dc=example,dc=com" [08/Jan/2003:14:57:49 +0000] conn=24 op=1001 msgId=1002 - RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2003:14:57:49 +0000] conn=24 op=1002 msgId=1003 - ADD dn= "employeeNumber=9000,ou=People,dc=example,dc=com" [08/Jan/2003:14:57:49 +0000] conn=24 op=1002 msgId=1003 - RESULT err=0 tag=105 nentries=0 etime=0 [08/Jan/2003:14:57:49 +0000] conn=24 op=1003 msgId=1004 - UNBIND [08/Jan/2003:14:57:49 +0000] conn=24 op=1003 msgId=-1 - closing - U1 [08/Jan/2003:14:57:50 +0000] conn=24 op=-1 msgId=-1 - closed . . .
-
Confirm the current value of the passwordStorageScheme attribute value.
The SASL DIGEST-MD5 authentication mechanism is a two-stage bind operation. In the first stage, the client issues a SASL DIGEST bind request (as previously mentioned, the bind DN is not typically included in the first request issued by the client when authenticating using DIGEST-MD5). The directory server returns a challenge. The client performs two DIGEST-MD5 hashes of the password with the Challenge, and the Realm. The client sends the result to the directory server. The directory server performs the same hashes and compares the results. Because the directory server must perform the hashes, the server requires a clear text password. Before changing the passwordStorageScheme attribute value, you can confirm the current value using the ldapsearch command.
Example output from ldapsearch:
$ cd /usr/sunone/servers/shared/bin $ ./ldapsearch -h directoryserver_hostname -p ldap_port -D "cn=Directory Manager" -w password -b "cn=Password Policy,cn=config" "(objectclass=*)" passwordStorageScheme cn=Password Policy,cn=config passwordStorageScheme=SSHA -
Run ldapsearch to verify the user, and to verify a successful bind.
When you create directory user accounts, the passwords are stored in the default password storage mechanism (Salted Secure Hashing Algorithm (SSHA)). Using one of these accounts, you must change the userpassword to be in the clear. Before changing the userpassword of an entry, you should run ldapsearch to verify that the user exists in the directory server, (also note the format of the userpassword attribute value) and that you can bind successfully with the password.
Example running ldapsearch to verify a user entry:
$./ldapsearch -h directoryserver_hostname -p ldap_port -b "dc=example,dc=com" uid=lucyr 1.1 dn: employeeNumber=1000,ou=People,dc=example,dc=comExample of searching for the user entry lucyr and displaying the current userpassword attribute value:
$./ldapsearch -h directoryserver_hostname -p ldap_port -b "dc=example,dc=com" -D "cn=Directory Manager" -w password uid= lucyr userpassword dn: employeeNumber=1000,ou=People,dc=example,dc=com userpassword: {SSHA}zDGUDF2HHAMzheLjjXSNSem/NS2YSmItdXh8cQ==Example of binding to the directory server as user lucyr using the correct credentials:
$./ldapsearch -h directoryserver_hostname -p ldap_port -b "dc=example,dc=com" -D "employeeNumber=1000,ou=People,dc= example,dc=com" -w password uid=lucyr 1.1 dn: employeeNumber=1000,ou=People,dc=example,dc=comIf the preceding ldapsearch was not successful, you will see something similar to the following output:
ldap_simple_bind: Invalid credentials
The correct way in LDAPv3 to request that no attributes be returned is to specify an attribute list of 1.1 as specified in RFC 2251.
-
Change the passwordStorageScheme attribute value to {CLEAR}.
It is not necessary to set the default storage scheme to clear in the directory server in order to store passwords in clear text. Passwords can be stored in clear text regardless of the default password storage scheme by prefixing the clear text password with {CLEAR}. This can be beneficial if there are only a few special accounts in the server for which authentication will be performed using DIGEST-MD5 and it is not desirable to store passwords for those other accounts in clear text. However, you will not be able to use pam_unix for authentication if you store passwords in clear text.
Example changing the passwordStorageScheme attribute value:
$ cd /usr/sunone/servers/shared/bin $ ./ldapmodify -h directoryserver_hostname -p ldap_port -D "cn=Directory Manager" -w passwordYou are now in the ldapmodify interactive mode. Enter the information, and when you are done, use Control-d to exit ldapmodify.
Example:
dn: cn=Password Policy,cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: clear modifying entry cn=Password Policy,cn=config -
Confirm the passwordStorateScheme attribute value change.
When you verify this attribute change, you see that an entry has been added to cn= # Password Policy,cn=config which looks like this:
$ ./ldapsearch -h directoryserver_hostname -p ldap_port -D "cn=Directory Manager" -w password -b "cn=Password Policy, cn=config" "(objectclass=*)" passwordStorageScheme cn=Password Policy,cn=config passwordStorageScheme: clearIn this particular example, we loaded the directory user entries with the passwordStorageScheme attribute value set to {SSHA}. It is possible to make the modification to the passwordStorageScheme attribute prior to loading your directory entries, however, in practice this is never really the case.
-
Change the userpassword attribute value to be in the clear for a user.
Example:
$ ./ldapmodify -h directoryserver_hostname -p ldap_port -D "cn=Directory Manager" -w password dn: employeeNumber=1000,ou=People,dc=example,dc=com changetype: modify replace: userPassword userPassword: password123 modifying entry employeeNumber=1000,ou=People,dc=example,dc=com (Note: use contol-d to exit interactive mode -
Verify that the password for the user is now in the clear.
When you search the directory server for the user entry lucyr and return the userpassword attribute value, you should see the clear text value of the password.
Example:
$./ldapsearch -h directoryserver_hostname -p ldap_port -b "dc=example,dc=com" -D "cn=Directory Manager" -w password uid= lucyr userpassword dn: employeeNumber=1000,ou=People,dc=example,dc=com userpassword: {clear}password123Example of authenticating using SASL DIGEST-MD5:
$./ldapsearch -h directoryserver_hostname -p ldap_port -D "" -w password -o mech=DIGEST-MD5 -o authid="dn:employeeNumber=1000,ou= People,dc=example,dc=com" -o authzid="dn:employeeNumber=1000,ou= People,dc=example,dc=com" -b "dc=example,dc=com" -s base "(uid=lucyr)"Because of the way the Solaris OE packages install the SASL plug-ins, it is necessary to specify a value for the SASL_PATH environment variable that points to the server-root/lib/sasl directory.