mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-02-17 14:00:30 +08:00
Typos, slight rearrangement
This commit is contained in:
Howard Chu
parent
39ec9cf91b
commit
45cac8e03f
@ -54,7 +54,7 @@ provide the required reliability or availability.
|
||||
H2: Distributed Local Directory Service
|
||||
|
||||
In this configuration, the local service is partitioned into smaller
|
||||
services, each which may be replicated, and {{glued}} together with
|
||||
services, each of which may be replicated, and {{glued}} together with
|
||||
{{superior}} and {{subordinate}} referrals.
|
||||
!if 0
|
||||
An example of this configuration is shown in Figure 3.4.
|
||||
|
||||
@ -87,58 +87,8 @@ of the first step will be given in the next section using Kerberos
|
||||
V4 as an example mechanism. The steps necessary for your site's
|
||||
authentication mechanism will be similar, but a guide to every
|
||||
mechanism available under SASL is beyond the scope of this chapter.
|
||||
The next section after that describes the second step of mapping
|
||||
authentication identities to DN's.
|
||||
|
||||
|
||||
H3: GSSAPI
|
||||
|
||||
This section describes the use of the SASL GSSAPI mechanism and
|
||||
Kerberos V with OpenLDAP. It will be assumed that you have Kerberos
|
||||
V deployed, you are familiar with the operation of the system, and that
|
||||
your users are trained its use. This section also assumes you have
|
||||
familiarized yourself with the use of the GSSAPI mechanism by reading
|
||||
{{Configuring GSSAPI and Cyrus SASL}} (provided with Cyrus SASL in
|
||||
the {{FILE:doc/gssapi}} file) and successfully experimented with
|
||||
the Cyrus provided sample_server and sample_client applications.
|
||||
General information about Kerberos is available at
|
||||
{{URL:http://web.mit.edu/kerberos/www/}}.
|
||||
|
||||
To use the GSSAPI mechanism with {{slapd}}(8) one must create a service
|
||||
key with a principal for {{ldap}} service within the realm for the host
|
||||
on which the service runs. For example, if your run {{slapd}} on
|
||||
{{EX:directory.example.com}} and your realm is {{EX:EXAMPLE.COM}},
|
||||
you need to create a service key with the principal:
|
||||
|
||||
> ldap/directory.example.com@EXAMPLE.COM
|
||||
|
||||
When {{slapd}}(8) runs, it must have access to this key. This is
|
||||
generally done by placing the key into a keytab, such as
|
||||
{{FILE:/etc/krb5.keytab}}.
|
||||
|
||||
To use the GSSAPI mechanism to authenticate to the directory, the
|
||||
user obtains a Ticket Granting Ticket (TGT) prior to running the
|
||||
LDAP client. When using OpenLDAP client tools, the user may mandate
|
||||
use of the GSSAPI mechanism by specifying {{EX:-Y GSSAPI}} as a
|
||||
command option.
|
||||
|
||||
For the purposes of authentication and authorization, {{slapd}}(8)
|
||||
associates a non-mapped authentication DN of the form:
|
||||
|
||||
> uid=principal,cn=GSSAPI,cn=auth
|
||||
|
||||
If the user principal is within the same realm, the realm is
|
||||
trimmed from the principal. Continuting our example, a user
|
||||
with the Kerberos principal {{EX:kurt@EXAMPLE.COM}} would have
|
||||
the associated DN:
|
||||
|
||||
> uid=kurt,cn=GSSAPI,cn=auth
|
||||
|
||||
and the principal {{EX:ursula@@FORIEGN.REALM}} would have the
|
||||
associated DN:
|
||||
|
||||
> uid=ursula@FOREIGN-REALM,cn=GSSAPI,cn=auth
|
||||
|
||||
The second step is described in the section
|
||||
{{SECT:Mapping Authentication identities to LDAP entries}}.
|
||||
|
||||
H3: KERBEROS_V4
|
||||
|
||||
@ -146,7 +96,7 @@ This section describes the use of the SASL KERBEROS_V4 mechanism
|
||||
with OpenLDAP. It will be assumed that you are familiar with the
|
||||
workings of Kerberos IV security system, and that your site has
|
||||
Kerberos IV deployed. Your users should be familiar with
|
||||
authentication policy, are aware of how to receive credentials in
|
||||
authentication policy, how to receive credentials in
|
||||
a Kerberos ticket cache, and how to refresh expired credentials.
|
||||
|
||||
Client programs will need to be able to obtain a session key for
|
||||
@ -187,27 +137,79 @@ DN}} of the form
|
||||
So in our above example, if the user's name were "adamson", the
|
||||
authentication request DN would be:
|
||||
|
||||
> uid=ADAMSON,cn=EXAMPLE.COM,cn=KERBEROS_V4,cn=AUTH
|
||||
> uid=adamsom,cn=example.com,cn=kerberos_v4,cn=auth
|
||||
|
||||
This authentication request DN by itself could be placed into ACL's
|
||||
and {{EX:groupOfNames}} "member" attributes, since it is of legitimate
|
||||
LDAP DN format. The next section, however, tells how to map that
|
||||
LDAP DN format. The section
|
||||
{{SECT:Mapping Authentication identities to LDAP entries}},
|
||||
however, tells how to map that
|
||||
DN into the DN of a person's own LDAP entry.
|
||||
|
||||
Also note that this example, being for Kerberos, shows the <realm>
|
||||
portion of the DN being filled in with the Kerberos realm of the
|
||||
company. Several other authentication mechanisms do not emply the
|
||||
company. Several other authentication mechanisms do not employ the
|
||||
concept of a realm, so the ",cn=<realm>" portion of the authentication
|
||||
request DN would not appear.
|
||||
|
||||
|
||||
H3: GSSAPI
|
||||
|
||||
This section describes the use of the SASL GSSAPI mechanism and
|
||||
Kerberos V with OpenLDAP. Since Kerberos V is being used, the information
|
||||
is very similar to the previous section.
|
||||
It will be assumed that you have Kerberos
|
||||
V deployed, you are familiar with the operation of the system, and that
|
||||
your users are trained in its use. This section also assumes you have
|
||||
familiarized yourself with the use of the GSSAPI mechanism by reading
|
||||
{{Configuring GSSAPI and Cyrus SASL}} (provided with Cyrus SASL in
|
||||
the {{FILE:doc/gssapi}} file) and successfully experimented with
|
||||
the Cyrus provided sample_server and sample_client applications.
|
||||
General information about Kerberos is available at
|
||||
{{URL:http://web.mit.edu/kerberos/www/}}.
|
||||
|
||||
To use the GSSAPI mechanism with {{slapd}}(8) one must create a service
|
||||
key with a principal for {{ldap}} service within the realm for the host
|
||||
on which the service runs. For example, if you run {{slapd}} on
|
||||
{{EX:directory.example.com}} and your realm is {{EX:EXAMPLE.COM}},
|
||||
you need to create a service key with the principal:
|
||||
|
||||
> ldap/directory.example.com@EXAMPLE.COM
|
||||
|
||||
When {{slapd}}(8) runs, it must have access to this key. This is
|
||||
generally done by placing the key into a keytab, such as
|
||||
{{FILE:/etc/krb5.keytab}}.
|
||||
|
||||
To use the GSSAPI mechanism to authenticate to the directory, the
|
||||
user obtains a Ticket Granting Ticket (TGT) prior to running the
|
||||
LDAP client. When using OpenLDAP client tools, the user may mandate
|
||||
use of the GSSAPI mechanism by specifying {{EX:-Y GSSAPI}} as a
|
||||
command option.
|
||||
|
||||
For the purposes of authentication and authorization, {{slapd}}(8)
|
||||
associates a non-mapped authentication request DN of the form:
|
||||
|
||||
> uid=<principal>,cn=<realm>,cn=gssapi,cn=auth
|
||||
|
||||
Continuing our example, a user
|
||||
with the Kerberos principal {{EX:kurt@EXAMPLE.COM}} would have
|
||||
the associated DN:
|
||||
|
||||
> uid=kurt,cn=example.com,cn=gssapi,cn=auth
|
||||
|
||||
and the principal {{EX:ursula@FOREIGN.REALM}} would have the
|
||||
associated DN:
|
||||
|
||||
> uid=ursula,cn=foreign.realm,cn=gssapi,cn=auth
|
||||
|
||||
|
||||
H3: Mapping Authentication identities to LDAP entries
|
||||
|
||||
The authentication mechanism in the slapd server will use SASL
|
||||
library calls to obtain the authenticated user's "username", based
|
||||
on whatever underlying authentication mechanism was used. This
|
||||
username is in the namespace of the authentication mechanism, and
|
||||
not in the LDAP namespace. As stated in the section above, that
|
||||
not in the LDAP namespace. As stated in the sections above, that
|
||||
username is reformatted into an authentication request DN of the
|
||||
form
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user