203 lines
13 KiB
HTML
203 lines
13 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow"/>
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<title>Directory Server (LDAP) - Authentication</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="rzahyauthentication"></a>
|
||
|
|
<h3 id="rzahyauthentication">Authentication</h3>
|
||
|
|
<p>Access control within the Directory Server is based on the distinguished
|
||
|
|
name (DN) associated with a given connection. That DN is established as the
|
||
|
|
result of a bind to (logging into) the Directory Server.</p>
|
||
|
|
<p>When the Directory Server is first configured, the following identities
|
||
|
|
can be used to authenticate to the server:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Anonymous</li>
|
||
|
|
<li>The directory administrator (cn=administrator by default)</li>
|
||
|
|
<li>A projected i5/OS user profile (see <a href="rzahyprojbkend.htm#rzahyprojbkend">Operating system projected backend</a>)</li></ul>
|
||
|
|
<p>It is a good idea to create additional users that can be given authority
|
||
|
|
to manage different parts of the directory without requiring that you share
|
||
|
|
the directory administrator identity.</p>
|
||
|
|
<p>See <a href="rzahymanageuser.htm#rzahymanageuser">Manage users</a> for more information.</p>
|
||
|
|
<p>From an LDAP perspective, the frameworks for authenticating to LDAP follow:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Simple bind, in which an application provides a DN and the clear text
|
||
|
|
password for that DN</li>
|
||
|
|
<li><img src="delta.gif" alt="Start of change" />Simple Authentication and Security Layer (SASL), which provides
|
||
|
|
several additional authentication methods, including CRAM-MD5, DIGEST-MD5,
|
||
|
|
EXTERNAL, GSSAPI, and OS400-PRFTKN.<img src="deltaend.gif" alt="End of change" /></li></ul>
|
||
|
|
<p><span class="bold">Simple bind, DIGEST-MD5, and CRAM-MD5</span></p>
|
||
|
|
<p>To use a simple bind, the client must supply the DN of an existing LDAP
|
||
|
|
entry and a password which matches the userPassword attribute for that entry.
|
||
|
|
For example, you could create an entry for John Smith as follows:</p>
|
||
|
|
<pre class="xmp">sample.ldif:
|
||
|
|
dn: cn=John Smith,cn=users,o=acme,c=us
|
||
|
|
objectclass: inetorgperson
|
||
|
|
cn: John Smith
|
||
|
|
sn: smith
|
||
|
|
userPassword: mypassword
|
||
|
|
|
||
|
|
ldapadd -D cn=administrator -w secret -f sample.ldif</pre>
|
||
|
|
<p>You can now use the DN "cn=John Smith,cn=users,o=acme,c=us" in access control,
|
||
|
|
or make it a member of a group used in access control.</p>
|
||
|
|
<p>Several predefined objectclasses allow userPassword to be specified, including
|
||
|
|
(but not limited to): person, organizationalperson, inetorgperson, organization,
|
||
|
|
organizationalunit, and others.</p>
|
||
|
|
<p>The Directory Server passwords are case sensitive. If you create an entry
|
||
|
|
with the userPassword value <tt class="xph">secret</tt>, a bind that specifies the password <tt class="xph">SECRET</tt> will fail.</p>
|
||
|
|
<p>When using a simple bind, the client sends the clear text password to the
|
||
|
|
server as part of the bind request. This makes the password susceptible to
|
||
|
|
protocol level snooping. An SSL connection could be used to protect the password
|
||
|
|
(all information sent over an SSL connection is encrypted). Or the DIGEST-MD5
|
||
|
|
or CRAM-MD5 SASL methods can be used.</p>
|
||
|
|
<p></p>
|
||
|
|
<p>The CRAM-MD5 method requires that the server have access to the clear text
|
||
|
|
password (password protection is set to <tt class="xph">none</tt>, which really means
|
||
|
|
the password is stored in decryptable form and returned on searches as clear
|
||
|
|
text), and the QRETSVRSEC (Retain server security data) system value must
|
||
|
|
be 1 (Retain data). The client sends the DN to the server. The server retrieves
|
||
|
|
the userPassword value for the entry and generates a random string. The random
|
||
|
|
string is sent to the client. Both the client and the server hash the random
|
||
|
|
string using the password as the key, and the client sends the result to the
|
||
|
|
server. If the two hashed strings match, the bind request is successful,
|
||
|
|
and the password was never sent to the server.</p>
|
||
|
|
<p><img src="delta.gif" alt="Start of change" />The DIGEST-MD5 method is similar to CRAM-MD5. It requires that
|
||
|
|
the server have access to the clear text password (password protection is
|
||
|
|
set to <tt class="xph">none</tt>) and that the QRETSVRSEC system value be set to 1.
|
||
|
|
Instead of sending the DN to the server, DIGEST-MD5 requires that the client
|
||
|
|
send a username value to the server. To be able to use DIGEST-MD5 for a regular
|
||
|
|
user (not an admin) requires that no other entries in the directory have the
|
||
|
|
same value for the username attribute. Other differences with DIGEST-MD5 include
|
||
|
|
more configuration options: server realm, username attribute, and adminstrator
|
||
|
|
password. iSeries allows users to bind as projected or published users, where
|
||
|
|
the server verifies the supplied password against a user profile's password
|
||
|
|
on the system. Since the clear text password for user profiles is not available
|
||
|
|
to the server, DIGEST-MD5 cannot be used with projected or published users.<img src="deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p>For more information, see <a href="rzahydigest.htm#rzahydigest">Configure DIGEST-MD5 authentication on the Directory Server</a>.</p>
|
||
|
|
<p><span class="bold">Binding as a published user</span></p>
|
||
|
|
<p>The Directory Server provides a means to have an LDAP entry whose password
|
||
|
|
is that of an the operating system user profile on the same system. To do
|
||
|
|
this, the entry must:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Have a UID attribute, whose value is the name of an the operating system
|
||
|
|
user profile</li>
|
||
|
|
<li>Not have a userPassword attribute</li></ul>
|
||
|
|
<p>When the server receives a bind request for an entry that has a UID value
|
||
|
|
but no userPassword, the server calls the operating system security to validate
|
||
|
|
that the UID is a valid user profile name and that the specified password
|
||
|
|
is the correct password for that user profile. Such an entry is called a
|
||
|
|
published user in reference to publishing of the system distribution directory
|
||
|
|
(SDD) to LDAP, which creates such entries.</p>
|
||
|
|
<p><span class="bold">Binding as a projected user</span></p>
|
||
|
|
<p>An LDAP entry representing an operating system user profile is referred
|
||
|
|
to as a projected user. You can use the DN of a projected user along with
|
||
|
|
the correct password for that user profile in a simple bind. For example,
|
||
|
|
the DN for user JSMITH on system my-system.acme.com would be:</p>
|
||
|
|
<pre class="xmp">os400-profile=JSMITH,cn=accounts,os400-sys=my-system.acme.com</pre>
|
||
|
|
<p><span class="bold">SASL EXTERNAL bind</span></p>
|
||
|
|
<p>If an SSL or TLS connection is used with client authentication (for example,
|
||
|
|
the client has a private certificate), the SASL EXTERNAL method can be used.
|
||
|
|
This method tells the server to get the client's identity from an external
|
||
|
|
source, in this case the SSL connection. The server gets the public portion
|
||
|
|
of the client certificate (sent to the server as part of establishing the
|
||
|
|
SSL connection) and extracts the subject DN. That DN is assigned by the LDAP
|
||
|
|
server to the connection.</p>
|
||
|
|
<p>For example, given a certificate assigned to:</p>
|
||
|
|
<pre class="xmp">common name: John Smith
|
||
|
|
organization unit: Engineering
|
||
|
|
organization: ACME
|
||
|
|
locality: Minneapolis
|
||
|
|
state: MN
|
||
|
|
country: US
|
||
|
|
</pre>
|
||
|
|
<p>The subject DN would be:</p>
|
||
|
|
<pre class="xmp">cn=John Smith,ou=Engineering,o=acme,l=Minneapolis,st=MN,c=US</pre>
|
||
|
|
<p>Note that the cn, ou, o, l, st, and c elements are used in the order shown
|
||
|
|
to generate the subject DN.</p>
|
||
|
|
<p><span class="bold">SASL GSSAPI bind</span></p>
|
||
|
|
<p>The SASL GSSAPI bind mechanism is used to authenticate to the server using
|
||
|
|
a Kerberos ticket. This is useful when the client has done a KINIT or other
|
||
|
|
form of Kerberos authentication (for example, Windows 2000 domain login).
|
||
|
|
In this case, the server validates the client's ticket and then gets the
|
||
|
|
Kerberos principal and realm names; for example, principal jsmith in realm
|
||
|
|
acme.com, normally expressed as jsmith@acme.com. The server can be configured
|
||
|
|
to map this identity to a DN in one of two ways:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Generate a pseudo DN of the form ibm-kn=jsmith@acme.com</li>
|
||
|
|
<li>Search for an entry having the ibm-securityidentities auxiliary class
|
||
|
|
and an altsecurityidenties value of the form KERBEROS:<principal>@<realm>.</li></ul>
|
||
|
|
<p>An entry that could be used for jsmith@acme.com might look like:</p>
|
||
|
|
<pre class="xmp">dn: cn=John Smith,cn=users,o=acme,c=us
|
||
|
|
objectclass: inetorgperson
|
||
|
|
objectclass: ibm-securityidentities
|
||
|
|
cn: John Smith
|
||
|
|
sn: Smith
|
||
|
|
altsecurityidentities: kerberos:jsmith@acme.com</pre>
|
||
|
|
<p>For information about how to enable Kerberos authentication, see <a href="rzahyekbpi.htm#rzahyekbpi">Enable Kerberos authentication on the Directory Server</a>.</p>
|
||
|
|
<p><span class="bold">OS400-PRFTKN bind</span></p>
|
||
|
|
<p>The OS400-PRFTKN SASL bind mechanism is used to authenticate to the server
|
||
|
|
using a profile token (refer to the Generate Profile Token API). When this
|
||
|
|
mechanism is used, the server validates the profile token and associates the
|
||
|
|
DN of the projected user profile with the connection (for example, os400-profile=JSMITH,cn=accounts,os400-system=my-as400.mycompany.com).
|
||
|
|
If the application already has a profile token, this mechanism avoids the
|
||
|
|
need to get the user profile name and user password to perform a simple bind.
|
||
|
|
To use this mechanism, use the <a href="../apis/ldap_sasl_bind_s.htm">ldap_sasl_bind
|
||
|
|
s</a> API, specifying a null DN, <tt class="xph">OS400-PRFTKN</tt> for the mechanism,
|
||
|
|
and a berval (binary data that is encoded using simplified basic encoding
|
||
|
|
rules) containing the 32-byte profile token for the credentials. When using
|
||
|
|
the LDAP APIs in i5/OS or using the QSH command utilities (such as ldapsearch)
|
||
|
|
to access the local directory server, you can omit the password, and the client
|
||
|
|
APIs will authenticate to the server as the current user profile for the job.
|
||
|
|
For example:</p>
|
||
|
|
<p> <tt class="xph">> ldapsearch -m OS400-PRFTKN -b "o=ibm,c=us" "(uid=johndoe)"</tt></p>
|
||
|
|
<p>will perform the search under the authority of the current user profile
|
||
|
|
as if you had used:</p>
|
||
|
|
<p><tt class="xph">> ldapsearch -D os400-profile=myprofile,cn=accounts,os400-sys=mysystem
|
||
|
|
-w mypassword -b "o=ibm,c=us" "(uid=johndoe)"</tt></p>
|
||
|
|
<p><span class="bold">LDAP as an authentication service</span></p>
|
||
|
|
<p>LDAP is commonly used to provide an authentication service. You can configure
|
||
|
|
a Web server to authenticate to LDAP. By setting up multiple Web servers
|
||
|
|
(or other applications) to authenticate to LDAP, you can establish a single
|
||
|
|
user registry for those applications, rather than defining users over and
|
||
|
|
over for each application or Web server instance.</p>
|
||
|
|
<p>How does this work? In short, the Web server prompts the user for a user
|
||
|
|
name and password. The Web server takes this information and then does a
|
||
|
|
search in the LDAP directory for an entry with that user name (for example,
|
||
|
|
you might configure the Web server to map the user name to the LDAP 'uid'
|
||
|
|
or 'mail' attributes). If it finds exactly one entry, the Web server then
|
||
|
|
sends a bind request to the server using the DN of the entry it just found
|
||
|
|
and the user provided password. If the bind is successful, the user is now
|
||
|
|
authenticated. SSL connections can be used to protect the password information
|
||
|
|
from protocol level snooping.</p>
|
||
|
|
<p>The Web server can also keep track of the DN that was used so that a given
|
||
|
|
application can use that DN, perhaps by storing customization data in that
|
||
|
|
entry, another entry associated with it, or in a separate database using the
|
||
|
|
DN as a key to find the information.</p>
|
||
|
|
<p>A common alternative to using a bind request is to use the LDAP compare
|
||
|
|
operation. For example <tt class="xph">ldap_compare(ldap_session, dn, "userPassword",
|
||
|
|
enteredPassword)</tt>. This allows the application to use a single LDAP
|
||
|
|
session, rather than starting and ending sessions for each authentication
|
||
|
|
request.</p>
|
||
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
|
</body>
|
||
|
|
</html>
|