From: Howard Chu Date: Sat, 20 Apr 2002 07:24:14 +0000 (+0000) Subject: Typos, slight rearrangement X-Git-Tag: OPENLDAP_REL_ENG_2_MP~160 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=45cac8e03f1ecdcbbd121c7fd782f15eeb1789bd;p=openldap Typos, slight rearrangement --- diff --git a/doc/guide/admin/config.sdf b/doc/guide/admin/config.sdf index 6355de07bd..7dc2b9e1eb 100644 --- a/doc/guide/admin/config.sdf +++ b/doc/guide/admin/config.sdf @@ -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. diff --git a/doc/guide/admin/sasl.sdf b/doc/guide/admin/sasl.sdf index cab4801ee8..2dfb4380d2 100644 --- a/doc/guide/admin/sasl.sdf +++ b/doc/guide/admin/sasl.sdf @@ -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 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=" 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=,cn=,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