1 # Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
2 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
6 OpenLDAP clients and servers are capable of authenticating via the
7 {{TERM[expand]SASL}} ({{TERM:SASL}}) framework, which is detailed
8 in {{REF:RFC2222}}. This chapter describes how to make use of
11 There are several industry standard authentication mechanisms that
12 can be used with SASL, including Kerberos V4, GSSAPI, and some of
13 the Digest mechanisms. The standard client tools provided with
14 OpenLDAP, such as {{ldapsearch}}(1) and {{ldapmodify}}(1), will by
15 default attempt to authenticate the user to the {{slapd}}(8) server
16 using SASL. Basic authentication service can be set up by the LDAP
17 administrator with a few steps, allowing users to be authenticated
18 to the slapd server as their LDAP entry. With a few extra steps,
19 some users and services can be allowed to exploit SASL's proxy
20 authorization feature, allowing them to authenticate themselves and
21 then switch their identity to that of another user or service.
23 This chapter assumes you have read {{Cyrus SASL for System
24 Administrators}}, provided with the {{PRD:Cyrus}} {{PRD:SASL}}
25 package (in {{FILE:doc/sysadmin.html}}).
27 Note that in the following text the term {{user}} is used to describe
28 a person or application entity who is connecting to the LDAP server
29 via an LDAP client, such as {{ldapsearch}}(1). That is, the term
30 {{user}} not only applies to both an individual using an LDAP client,
31 but to an application entity which issues LDAP client operations
32 without direct user control. For example, an e-mail server which
33 uses LDAP operations to access information held in an LDAP server
34 is an application entity.
37 H2: SASL Security Considerations
39 SASL offers many different authentication mechanisms. This section
40 briefly outlines security considerations.
42 Some mechanisms, such as PLAIN and LOGIN, offer no greater security over
43 LDAP "simple" authentication. Like "simple" authentication, such
44 mechanisms should not be used unless you have adequate security
45 protections in place. It is recommended that these mechanisms be
46 used only in conjunction with {{TERM[expand]TLS}} (TLS). Use of
47 PLAIN and LOGIN are not discussed further in this document.
49 The DIGEST-MD5 mechanism is the mandatory-to-implement authentication
50 mechanism for LDAPv3. Though DIGEST-MD5 is not a strong authentication
51 mechanism in comparison with trusted third party authentication
52 systems (such as Kerberos or public key systems), yet it does offer
53 significant protections against a number of attacks. Unlike the
54 CRAM-MD5 mechanism, it prevents chosen plaintext attacks. DIGEST-MD5
55 is favored over the weaker and even more dangerous use of plaintext
56 password mechanisms. The CRAM-MD5 mechanism is deprecated in favor
57 of DIGEST-MD5. Use of {{SECT:DIGEST-MD5}} is discussed below.
59 The KERBEROS_V4 mechanism utilizes Kerberos IV to provide secure
60 authentication services. There is also a GSSAPI based mechanism
61 which is generally used in conjunction with Kerberos V. Kerberos
62 is viewed as a secure, distributed authentication system suitable
63 for both small and large enterprises. Use of {{SECT:KERBEROS_V4}}
64 and {{SECT:GSSAPI}} are discussed below.
66 The EXTERNAL mechanism utilizes authentication services provided
67 by lower level network services such as {{TERM:TLS}} (TLS). When
68 used in conjunction with TLS {{TERM:X.509}}-based public key technology,
69 EXTERNAL offers strong authentication. Use of EXTERNAL is discussed
70 in the {{SECT:Using TLS}} chapter.
72 There are other strong authentication mechanisms to choose from,
73 including OTP (one time passwords) and SRP (secure remote passwords).
74 These mechanisms are not discussed in this document.
77 H2: SASL Authentication
79 Getting basic SASL authentication running involves a few steps.
80 The first step configures your slapd server environment so
81 that it can communicate with client programs using the security
82 system in place at your site. This usually involves setting up a
83 service key, a public key, or other form of secret. The second step
84 concerns mapping authentication identities to LDAP DN's, which
85 depends on how entries are laid out in your directory. An explanation
86 of the first step will be given in the next section using Kerberos
87 V4 as an example mechanism. The steps necessary for your site's
88 authentication mechanism will be similar, but a guide to every
89 mechanism available under SASL is beyond the scope of this chapter.
90 The second step is described in the section
91 {{SECT:Mapping Authentication identities to LDAP entries}}.
95 This section describes the use of the SASL KERBEROS_V4 mechanism
96 with OpenLDAP. It will be assumed that you are familiar with the
97 workings of the Kerberos IV security system, and that your site has
98 Kerberos IV deployed. Your users should be familiar with
99 authentication policy, how to receive credentials in
100 a Kerberos ticket cache, and how to refresh expired credentials.
102 Client programs will need to be able to obtain a session key for
103 use when connecting to your LDAP server. This allows the LDAP server
104 to know the identity of the user, and allows the client to know it
105 is connecting to a legitimate server. If encryption layers are to
106 be used, the session key can also be used to help negotiate that
109 The slapd server runs the service called "{{ldap}}", and the server
110 will require a srvtab file with a service key. SASL aware client
111 programs will be obtaining an "ldap" service ticket with the user's
112 ticket granting ticket (TGT), with the instance of the ticket
113 matching the hostname of the OpenLDAP server. For example, if your
114 realm is named {{EX:EXAMPLE.COM}} and the slapd server is running
115 on the host named {{EX:directory.example.com}}, the {{FILE:/etc/srvtab}}
116 file on the server will have a service key
118 > ldap.directory@EXAMPLE.COM
120 When an LDAP client is authenticating a user to the directory using
121 the KERBEROS_IV mechanism, it will request a session key for that
122 same principal, either from the ticket cache or by obtaining a new
123 one from the Kerberos server. This will require the TGT to be
124 available and valid in the cache as well. If it is not present or
125 has expired, SASL will print out the message
127 > ldap_sasl_interactive_bind_s: Local error
129 When the service ticket is obtained, it will be passed to the LDAP
130 server as proof of the user's identity. The server will extract
131 the identity and realm out of the service ticket using SASL
132 library calls, and convert them into an {{authentication request
135 > uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth
137 So in our above example, if the user's name were "adamson", the
138 authentication request DN would be:
140 > uid=adamsom,cn=example.com,cn=kerberos_v4,cn=auth
142 This authentication request DN by itself could be placed into ACL's
143 and {{EX:groupOfNames}} "member" attributes, since it is of legitimate
144 LDAP DN format. The section
145 {{SECT:Mapping Authentication identities to LDAP entries}},
146 however, tells how to map that
147 DN into the DN of a person's own LDAP entry.
149 Also note that this example, being for Kerberos, shows the <realm>
150 portion of the DN being filled in with the Kerberos realm of the
151 company. Several other authentication mechanisms do not employ the
152 concept of a realm, so the ",cn=<realm>" portion of the authentication
153 request DN would not appear.
158 This section describes the use of the SASL GSSAPI mechanism and
159 Kerberos V with OpenLDAP. Since Kerberos V is being used, the information
160 is very similar to the previous section.
161 It will be assumed that you have Kerberos
162 V deployed, you are familiar with the operation of the system, and that
163 your users are trained in its use. This section also assumes you have
164 familiarized yourself with the use of the GSSAPI mechanism by reading
165 {{Configuring GSSAPI and Cyrus SASL}} (provided with Cyrus SASL in
166 the {{FILE:doc/gssapi}} file) and successfully experimented with
167 the Cyrus provided sample_server and sample_client applications.
168 General information about Kerberos is available at
169 {{URL:http://web.mit.edu/kerberos/www/}}.
171 To use the GSSAPI mechanism with {{slapd}}(8) one must create a service
172 key with a principal for {{ldap}} service within the realm for the host
173 on which the service runs. For example, if you run {{slapd}} on
174 {{EX:directory.example.com}} and your realm is {{EX:EXAMPLE.COM}},
175 you need to create a service key with the principal:
177 > ldap/directory.example.com@EXAMPLE.COM
179 When {{slapd}}(8) runs, it must have access to this key. This is
180 generally done by placing the key into a keytab, such as
181 {{FILE:/etc/krb5.keytab}}.
183 To use the GSSAPI mechanism to authenticate to the directory, the
184 user obtains a Ticket Granting Ticket (TGT) prior to running the
185 LDAP client. When using OpenLDAP client tools, the user may mandate
186 use of the GSSAPI mechanism by specifying {{EX:-Y GSSAPI}} as a
189 For the purposes of authentication and authorization, {{slapd}}(8)
190 associates a non-mapped authentication request DN of the form:
192 > uid=<principal>,cn=<realm>,cn=gssapi,cn=auth
194 Continuing our example, a user
195 with the Kerberos principal {{EX:kurt@EXAMPLE.COM}} would have
198 > uid=kurt,cn=example.com,cn=gssapi,cn=auth
200 and the principal {{EX:ursula@FOREIGN.REALM}} would have the
203 > uid=ursula,cn=foreign.realm,cn=gssapi,cn=auth
208 This section describes the use of the SASL DIGEST-MD5 mechanism using
209 secrets stored either in the directory itself or in Cyrus SASL's own
210 database. DIGEST-MD5 relies on the client and the server sharing a
211 "secret", usually a password. The server generates a challenge and the
212 client a response proving that it knows the shared secret. This is much
213 more secure than simply sending the secret over the wire.
215 Cyrus SASL supports several shared-secret mechanisms. To do this, it
216 needs access to the plaintext password (unlike mechanisms which pass
217 plaintext passwords over the wire, where the server can store a hashed
218 version of the password).
220 Secret passwords are normally stored in Cyrus SASL's own {{sasldb}}
221 database, but if OpenLDAP has been compiled with Cyrus SASL 2.1 it is
222 possible to store the secrets in the LDAP database itself. With Cyrus
223 SASL 1.5, secrets may only be stored in the {{sasldb}}. In either
224 case it is very important to apply file access controls and LDAP access
225 controls to prevent exposure of the passwords.
227 The configuration and commands discussed in this section assume the use
228 of Cyrus SASL 2.1. If you are using version 1.5 then certain features
229 will not be available, and the command names will not have the trailing
232 To use secrets stored in {{sasldb,}} simply add users with the
233 {{saslpasswd2}} command:
235 > saslpasswd2 -c <username>
237 The passwords for such users must be managed with the {{saslpasswd2}}
240 To use secrets stored in the LDAP directory, place plaintext passwords
241 in the {{EX:userPassword}} attribute. It will be necessary to add an
242 option to {{EX:slapd.conf}} to make sure that passwords changed through
243 LDAP are stored in plaintext:
245 > password-hash {CLEARTEXT}
247 Passwords stored in this way can be managed either with {{EX:ldappasswd}}
248 or by simply modifying the {{EX:userPassword}} attribute.
250 Wherever the passwords are stored, a mapping will be needed from SASL
251 authentication IDs to regular DNs. The DIGEST-MD5 mechanism produces
252 authentication IDs of the form:
254 > uid=<username>,cn=<realm>,cn=digest-md5,cn=auth
256 NOTE that if the default realm is used, the realm name is omitted from
259 > uid=<username>,cn=digest-md5,cn=auth
261 See {{SECT: Mapping Authentication identities to LDAP entries}} below
262 for information on mapping such IDs to DNs.
264 With suitable mappings in place, users can specify SASL IDs when
265 performing LDAP operations, and the password stored in {{sasldb}} or in
266 the directory itself will be used to verify the authentication.
267 For example, the user identified by the directory entry:
269 > dn: cn=Andrew Findlay+uid=u000997,dc=example,dc=com
270 > objectclass: inetOrgPerson
271 > objectclass: person
274 > userPassword: secret
276 can issue commands of the form:
278 > ldapsearch -U u000997 -b dc=example,dc=com 'cn=andrew*'
280 or can specify the realm explicitly:
282 > ldapsearch -U u000997@myrealm -b dc=example,dc=com 'cn=andrew*'
284 If several SASL mechanisms are supported at your site, it may be
285 necessary to specify which one to use, e.g.:
287 > ldapsearch -Y DIGEST-MD5 -U u000997 -b dc=example,dc=com 'cn=andrew*'
290 Note: in each of the above cases, no authorization identity (e.g. {{EX:-X}})
291 was provided. Unless you are attempting {{SECT:SASL Proxy
292 Authorization}}, no authorization identity should be specified.
293 The server will infer an authorization identity from authentication
294 identity (as described below).
297 H3: Mapping Authentication identities to LDAP entries
299 The authentication mechanism in the slapd server will use SASL
300 library calls to obtain the authenticated user's "username", based
301 on whatever underlying authentication mechanism was used. This
302 username is in the namespace of the authentication mechanism, and
303 not in the LDAP namespace. As stated in the sections above, that
304 username is reformatted into an authentication request DN of the
307 > uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth
311 > uid=<username>,cn=<mechanism>,cn=auth
313 depending on whether or not <mechanism> employs the concept of
314 "realms". Note also that the realm part will be omitted if the default
315 realm was used in the authentication.
317 It is not intended that you should add LDAP entries of the above
318 form to your LDAP database. Chances are you have an LDAP entry for
319 each of the people that will be authenticating to LDAP, laid out
320 in your directory tree, and the tree does not start at cn=auth.
321 But if your site has a clear mapping between the "username" and an
322 LDAP entry for the person, you will be able to configure your LDAP
323 server to automatically map a authentication request DN to the
324 user's {{authentication DN}}.
326 Note: it is not required that the authentication request DN nor the
327 user's authentication DN resulting from the mapping refer to an
328 entry held in the directory. However, additional capabilities
329 become available (see below).
331 The LDAP administrator will need to tell the slapd server how to
332 map an authentication request DN to a user's authentication DN.
333 This is done by adding one or more {{EX:sasl-regexp}} directives to
334 the {{slapd.conf}}(5) file. This directive takes two arguments:
336 > sasl-regexp <search pattern> <replacement pattern>
338 The authentication request DN is compared to the search pattern
339 using the regular expression functions {{regcomp}}() and {{regexec}}(),
340 and if it matches, it is rewritten as the replacement pattern. If
341 there are multiple {{EX:sasl-regexp}} directives, only the first
342 whose search pattern matches the authentication identity is used.
343 The string that is output from the replacement pattern should be
344 the authentication DN of the user, in a legitimate LDAP DN format.
345 It can also be an LDAP URL, which is discussed below.
347 The search pattern can contain any of the regular expression
348 characters listed in {{regexec}}(3C). The main characters of note
349 are dot ".", asterisk "*", and the open and close parenthesis "("
350 and ")". Essentially, the dot matches any character, the asterisk
351 allows zero or more repeats of the immediately preceding character or
352 pattern, and terms in parenthesis are
353 remembered for the replacement pattern.
355 The replacement pattern will produce the final authentication DN
356 of the user. Anything from the authentication request DN that
357 matched a string in parenthesis in the search pattern is stored in
358 the variable "$1". That variable "$1" can appear in the replacement
359 pattern, and will be replaced by the string from the authentication
360 request DN. If there were multiple sets of parentheses in the search
361 pattern, the variables $2, $3, etc are used.
363 For example, suppose the user's authentication identity is written
366 > uid=adamson,cn=example.com,cn=kerberos_v4,cn=auth
368 and the user's actual LDAP entry is
370 > uid=adamson,ou=person,dc=example,dc=com
372 The {{EX:sasl-regexp}} directive in {{slapd.conf}}(5) could be
376 > uid=(.*),cn=example.com,cn=kerberos_v4,cn=auth
377 > uid=$1,ou=person,dc=example,dc=com
379 An even more lenient rule could be written as
382 > uid=(.*),cn=.*,cn=auth
383 > uid=$1,ou=person,dc=example,dc=com
385 Be careful about setting the search pattern too leniently, however,
386 since it may mistakenly allow people to become authenticated as a
387 DN to which they should not have access. It is better to write
388 several strict directives than one lenient directive which has
389 security holes. If there is only one authentication mechanism in
390 place at your site, and zero or one realms in use, you might be
391 able to map between authentication identities and LDAP DN's with
392 a single {{EX:sasl-regexp}} directive.
394 Don't forget to allow for the case where the realm is omitted as well
395 as the case with an explicitly specified realm. This may well
396 require a separate {{EX:sasl-regexp}} directive for each case, with the
397 explicit-realm entry being listed first.
399 Some sites may have people's DN's spread to multiple areas of the
400 LDAP tree, such as if there were an {{EX:ou=accounting}} tree and an
401 {{EX:ou=engineering}} tree, with people interspersed between them. Or
402 there may not be enough information in the authentication identity
403 to isolate the DN, such as if the above person's LDAP entry looked
406 > dn: cn=mark adamson,ou=person,dc=example,dc=com
407 > objectclass: Person
411 In this case, the information in the authentication identity can
412 only be used to search for the user's DN, not derive it directly.
413 For both of these situations, and others, the replacement pattern
414 in the {{EX:sasl-regexp}} directives will need to produce an LDAP
415 URL, described in the next section.
418 H3: Performing searches for a person's DN
420 When there is not enough information in the authentication identity
421 to derive a person's authentication DN directly, the {{EX:sasl-regexp}}
422 directives in the {{slapd.conf}}(5) file will need to produce an
423 LDAP URL. This URL will then be used to perform an internal search
424 of the LDAP database to find the person's authentication DN.
426 An LDAP URL, similar to other URL's, is of the form
428 > ldap://<host>/<base>?<attrs>?<scope>?<filter>
430 This contains all of the elements necessary to perform an LDAP
431 search: the name of the server <host>, the LDAP DN search base
432 <base>, the LDAP attributes to retrieve <attrs>, the search scope
433 <scope> which is one of the three options "base", "one", or "sub",
434 and lastly an LDAP search filter <filter>. Since the search is for
435 an LDAP DN within the current server, the <host> portion should be
436 empty. The <attrs> field is also ignored since only the DN is of
437 concern. These two elements are left in the format of the URL to
438 maintain the clarity of what information goes where in the string.
440 Suppose that the person in the example from above did in fact have
441 an authentication username of "adamson" and that information was
442 kept in the attribute "uid" in their LDAP entry. The {{EX:sasl-regexp}}
443 directive might be written as
446 > uid=(.*),cn=example.com,cn=kerberos_v4,cn=auth
447 > ldap:///ou=person,dc=example,dc=com??sub?(uid=$1)
449 This will initiate an internal search of the LDAP database inside
450 the slapd server. If the search returns exactly one entry, it is
451 accepted as being the DN of the user. If there are more than one
452 entries returned, or if there are zero entries returned, the
453 authentication fails and the user's connection is left bound as
454 the authentication request DN.
456 Note that if the search scope <scope> in the URL is "base", then
457 the only LDAP entry that will be returned is the searchbase DN
458 <base>, so the actual search of the database is skipped. This is
459 equivalent to setting the replacement pattern in the directive to
460 a DN directly, as in the section above.
462 The attributes that are used in the search filter <filter> in the
463 URL should be indexed to allow faster searching. If they are not,
464 the authentication step alone can take uncomfortably long periods,
465 and users may assume the server is down.
467 A more complex site might have several realms in use, each mapping to
468 a different sub-tree in the directory. These can be handled with
469 statements of the form:
471 > # Match Engineering realm
473 > uid=(.*),cn=engineering.example.com,cn=digest-md5,cn=auth
474 > ldap:///dc=eng,dc=example,dc=com??sub?(&(uid=$1)(objectClass=person))
476 > # Match Accounting realm
478 > uid=(.*),cn=accounting.example.com,cn=digest-md5,cn=auth
479 > ldap:///dc=accounting,dc=example,dc=com??sub?(&(uid=$1)(objectClass=person))
481 > # Default realm is customers.example.com
483 > uid=(.*),cn=digest-md5,cn=auth
484 > ldap:///dc=customers,dc=example,dc=com??sub?(&(uid=$1)(objectClass=person))
486 Note that the explicitly-named realms are handled first, to avoid the
487 realm name becoming part of the UID. Note also the limitation of
488 matches to those entries with objectClass=person to avoid matching
489 other entries that happen to refer to the UID.
491 See {{slapd.conf}}(5) for more detailed information.
494 H2: SASL Proxy Authorization
496 The SASL offers a feature known as {{proxy authorization}}, which
497 allows an authenticated user to request that they act on the behalf
498 of another user. This step occurs after the user has obtained an
499 authentication DN, and involves sending an authorization identity
500 to the server. The server will then make a decision on whether or
501 not to allow the authorization to occur. If it is allowed, the
502 user's LDAP connection is switched to have a binding DN derived
503 from the authorization identity, and the LDAP session proceeds with
504 the access of the new authorization DN.
506 The decision to allow an authorization to proceed depends on the
507 rules and policies of the site where LDAP is running, and thus
508 cannot be made by SASL alone. The SASL library leaves it up to the
509 server to make the decision. The LDAP administrator sets the
510 guidelines of who can authorize to what identity by adding information
511 into the LDAP database entries. By default, the authorization
512 features are disabled, and must be explicitly configured by the
513 LDAP administrator before use.
516 H3: Uses of Proxy Authorization
518 This sort of service is useful when one entity needs to act on the
519 behalf of many other users. For example, users may be directed to
520 a web page to make changes to their personal information in their
521 LDAP entry. The users authenticate to the web server to establish
522 their identity, but the web server CGI cannot authenticate to the
523 LDAP server as that user to make changes for them. Instead, the
524 web server authenticates itself to the LDAP server as a service
527 > cn=WebUpdate,dc=example,dc=com
529 and then it will SASL authorize to the DN of the user. Once so
530 authorized, the CGI makes changes to the LDAP entry of the user,
531 and as far as the slapd server can tell for its ACLs, it is the
532 user themself on the other end of the connection. The user could
533 have connected to the LDAP server directly and authenticated as
534 themself, but that would require the user to have more knowledge
535 of LDAP clients, knowledge which the web page provides in an easier
538 Proxy authorization can also be used to limit access to an account
539 that has greater access to the database. Such an account, perhaps
540 even the root DN specified in {{slapd.conf}}(5), can have a strict
541 list of people who can authorize to that DN. Changes to the LDAP
542 database could then be only allowed by that DN, and in order to
543 become that DN, users must first authenticate as one of the persons
544 on the list. This allows for better auditing of who made changes
545 to the LDAP database. If people were allowed to authenticate
546 directly to the priviliged account, possibly through the {{EX:rootpw}}
547 {{slapd.conf}}(5) directive or through a {{EX:userPassword}}
548 attribute, then auditing becomes more difficult.
550 Note that after a successful proxy authorization, the original
551 authentication DN of the LDAP connection is overwritten by the new
552 DN from the authorization request. If a service program is able to
553 authenticate itself as its own authentication DN and then authorize
554 to other DN's, and it is planning on switching to several different
555 identities during one LDAP session, it will need to authenticate
556 itself each time before authorizing to another DN (or use a different
557 proxy authorization mechanism). The slapd server does not keep
558 record of the service program's ability to switch to other DN's.
559 On authentication mechanisms like Kerberos this will not require
560 multiple connections being made to the Kerberos server, since the
561 user's TGT and "ldap" session key are valid for multiple uses for
562 the several hours of the ticket lifetime.
565 H3: SASL Authorization Identities
567 The SASL authorization identity is sent to the slapd server via the
568 -X switch for {{ldapsearch}}(1) and other tools, or in the *authzid
569 parameter to the {{lutil_sasl_defaults}}() call. The identity can
570 be in one of two forms, either
578 In the first form, the <username> is from the same namespace as
579 the authentication identities above. It is the user's username as
580 it is refered to by the underlying authentication mechanism.
581 Authorization identities of this form are converted into a DN format
582 by the same function that the authentication process used, producing
583 an {{authorization request DN}} of the form
585 > uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth
587 That authorization request DN is then run through the same
588 {{EX:sasl-regexp}} process to convert it into a legitimate authorization
589 DN from the database. If it cannot be converted due to a failed
590 search from an LDAP URL, the authorization request fails with
591 "inappropriate access". Otherwise, the DN string is now a legitimate
592 authorization DN ready to undergo approval.
594 If the authorization identity was provided in the second form, with
595 a {{EX:"dn:"}} prefix, the string after the prefix is already in
596 authorization DN form, ready to undergo approval.
599 H3: Proxy Authorization Rules
601 Once slapd has the authorization DN, the actual approval process
602 begins. There are two attributes that the LDAP administrator can
603 put into LDAP entries to allow authorization:
608 Both can be multivalued. The {{EX:saslAuthzTo}} attribute is a
609 source rule, and it is placed into the entry associated with the
610 authentication DN to tell what authorization DNs the authenticated
611 DN is allowed to assume. The second attribute is a destination
612 rule, and it is placed into the entry associated with the requested
613 authorization DN to tell which authenticated DNs may assume it.
615 The choice of which authorization policy attribute to use is up to
616 the administrator. Source rules are checked first in the person's
617 authentication DN entry, and if none of the {{EX:saslAuthzTo}} rules
618 specify the authorization is permitted, the {{EX:saslAuthzFrom}}
619 rules in the authorization DN entry are then checked. If neither
620 case specifies that the request be honored, the request is denied.
621 Since the default behaviour is to deny authorization requests, rules
622 only specify that a request be allowed; there are no negative rules
623 telling what authorizations to deny.
625 The value(s) in the two attributes are of the same form as the
626 output of the replacement pattern of a {{EX:sasl-regexp}} directive:
627 either a DN or an LDAP URL. For example, if a {{EX:saslAuthzTo}}
628 value is a DN, that DN is one the authenticated user can authorize
629 to. On the other hand, if the {{EX:saslAuthzTo}} value is an LDAP
630 URL, the URL is used as an internal search of the LDAP database,
631 and the authenticated user can become ANY DN returned by the search.
632 If an LDAP entry looked like:
634 > dn: cn=WebUpdate,dc=example,dc=com
635 > saslAuthzTo: ldap:///dc=example,dc=com??sub?(objectclass=Person)
637 then any user who authenticated as cn=WebUpdate,dc=example,dc=com
638 could authorize to any other LDAP entry under the search base
639 "dc=example,dc=com" which has an objectClass of "Person".
642 H4: Notes on Proxy Authorization Rules
644 An LDAP URL in a {{EX:saslAuthzTo}} or {{EX:saslAuthzFrom}} attribute
645 will return a set of DNs. Each DN returned will be checked.
646 Searches which return a large set can cause the authorization
647 process to take an uncomfortably long time. Also, searches should
648 be performed on attributes that have been indexed by slapd.
650 To help produce more sweeping rules for {{EX:saslAuthzFrom}} and
651 {{EX:saslAuthzTo}}, the values of these attributes are allowed to
652 be DNs with regular expression characters in them. This means a
655 > saslAuthzTo: uid=.*,dc=example,dc=com
657 would allow that authenticated user to authorize to any DN that
658 matches the regular expression pattern given. This regular expression
659 comparison can be evaluated much faster than an LDAP search for
662 Also note that the values in an authorization rule must be one of
663 the two forms: an LDAP URL or a DN (with or without regular expression
664 characters). Anything that does not begin with "ldap://" is taken
665 as a DN. It is not permissable to enter another authorization
666 identity of the form "u:<username>" as an authorization rule.
668 H4: Policy Configuration
670 The decision of which type of rules to use, {{EX:saslAuthzFrom}}
671 or {{EX:saslAuthzTo}}, will depend on the site's situation. For
672 example, if the set of people who may become a given identity can
673 easily be written as a search filter, then a single destination
674 rule could be written. If the set of people is not easily defined
675 by a search filter, and the set of people is small, it may be better
676 to write a source rule in the entries of each of those people who
677 should be allowed to perform the proxy authorization.
679 By default, processing of proxy authorization rules is disabled.
680 The {{EX:sasl-authz-policy}} directive must be set in the
681 {{slapd.conf}}(5) file to enable authorization. This directive can
682 be set to {{EX:none}} for no rules (the default), {{EX:from}} for
683 source rules, {{EX:to}} for destination rules, or {{EX:both}} for
684 both source and destination rules.
686 Destination rules are extremely powerful. If ordinary users have
687 access to write the {{EX:saslAuthzTo}} attribute in their own entries, then
688 they can write rules that would allow them to authorize as anyone else.
689 As such, when using destination rules, the {{EX:saslAuthzTo}} attribute
690 should be protected with an ACL that only allows privileged users