Misc cleanup

diff --git a/doc/guide/admin/runningslapd.sdf b/doc/guide/admin/runningslapd.sdf
index a6155f86e9eed363f378f347c37c7ba7d659dd67..b6ddc6c70c60c6a66d469771e0e5c5e664b0ced3 100644 (file)
--- a/doc/guide/admin/runningslapd.sdf
+++ b/doc/guide/admin/runningslapd.sdf
@@ -91,7 +91,7 @@ additive, you can do the math yourself. That is, if you want
 to trace function calls and watch the config file being
 processed, you could set level to the sum of those two levels
 (in this case, {{EX: -d 65}}).  Or, you can let slapd do the
-math, (e.g. {{EX: -d 1 -d 64}}).  Consult {{F: <ldap.h>}} for
+math, (e.g. {{EX: -d 1 -d 64}}).  Consult {{F: <ldap_log.h>}} for
 more details.
 
 Note: slapd must have been compiled with {{EX:-DLDAP_DEBUG}}

diff --git a/doc/guide/admin/sasl.sdf b/doc/guide/admin/sasl.sdf
index d2c61fcf963abadef1111829423c45f4ee50c03e..53b886730db983ab5cc49269123c1d5a8deda151 100644 (file)
--- a/doc/guide/admin/sasl.sdf
+++ b/doc/guide/admin/sasl.sdf
@@ -475,21 +475,22 @@ put into LDAP entries to allow authorization:
 >      saslAuthzTo
 >      saslAuthzFrom
 
-Both can be multivalued. The first is called a source rule, and it
-is placed into a person's authentication DN entry to tell what
-other authorization DN's the person is allowed to change to. The
-second form is called a destination rule, and it is placed into an
-authorization DN's entry to tell what authenticated DN a person
-must be coming from in order to switch to that authorization DN.
-The choice of which form to use is up to the administrator. Source
-rules are checked first in the person's authentication DN entry,
-and if none of the {{EX:saslAuthzTo}} rules specify the authorization
-is permitted, the {{EX:saslAuthzFrom}} rules in the authorization
-DN entry are then checked. If neither case specifies that the
-request be honored, the request is denied with an "inappropriate
-access" message. Since the default behaviour is to deny authorization
-requests, rules only specify that a request be allowed; there are
-no negative rules telling what authorizations to deny.
+Both can be multivalued.  The {{EX:saslAuthzTo}} attribute is a
+source rule, and it is placed into the entry associated with the
+authentication DN to tell what authorization DNs the authenticated
+DN is allowed to assume.  The second attribute is a destination
+rule, and it is placed into the entry associated with the requested
+authorization DN to tell which authenticated DNs may assume it.
+
+The choice of which authorization policy attribute to use is up to
+the administrator.  Source rules are checked first in the person's
+authentication DN entry, and if none of the {{EX:saslAuthzTo}} rules
+specify the authorization is permitted, the {{EX:saslAuthzFrom}}
+rules in the authorization DN entry are then checked. If neither
+case specifies that the request be honored, the request is denied.
+Since the default behaviour is to deny authorization requests, rules
+only specify that a request be allowed; there are no negative rules
+telling what authorizations to deny.
 
 The value(s) in the two attributes are of the same form as the
 output of the replacement pattern of a {{EX:saslRegexp}} directive: