mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-01-24 13:24:56 +08:00
Code Issues Packages Projects Releases Wiki Activity

Misc cleanup

Browse Source
This commit is contained in:
Kurt Zeilenga 2002-06-14 20:53:52 +00:00
parent 220b41bc91
commit 76cb3243d3
2 changed files with 17 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/guide/admin/runningslapd.sdf
View File

@ -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}}

31
doc/guide/admin/sasl.sdf
View File

@ -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: