Skip to content
GitLab
Commit 43a8dc82 authored by Gavin Henry's avatar Gavin Henry
Browse files

New Access Control Section, including a new Sets section incorporating... 

New Access Control Section, including a new Sets section incorporating ITS#5278, ITS#5279 and ITS#5281.
parent f77bd7ff
Expand all Hide whitespace changes
Inline Side-by-side
doc/guide/admin/Makefile
View file @ 43a8dc82
......@@ -21,6 +21,7 @@ sdf-src: \
../plain.sdf \
../preamble.sdf \
abstract.sdf \
access-control.sdf \
appendix-changes.sdf \
appendix-common-errors.sdf \
appendix-configs.sdf \
......@@ -65,7 +66,10 @@ sdf-img: \
dual_dc.png \
intro_dctree.png \
intro_tree.png \
refint.png
refint.png \
set-following-references.png \
set-memberUid.png \
set-recursivegroup.png
guide.html: guide.sdf sdf-src sdf-img
sdf -2html guide.sdf
......
doc/guide/admin/access-control.sdf 0 → 100644
View file @ 43a8dc82
This diff is collapsed.
doc/guide/admin/aspell.en.pws
View file @ 43a8dc82
personal_ws-1.1 en 1559
personal_ws-1.1 en 1567
commonName
Masarati
subjectAltName
......@@ -36,8 +36,8 @@ DIB
dev
reqNewSuperior
librewrite
memberof
memberOf
memberof
BSI
updateref
buf
......@@ -85,8 +85,8 @@ dlopen
eng
AttributeValue
attributevalue
DUA
EOF
DUA
inputfile
DSP
refreshDone
......@@ -112,6 +112,7 @@ GHz
Bint
memalloc
FSF
usernames
strtol
idl
IDN
......@@ -120,10 +121,10 @@ iff
contextCSN
auditModify
auditSearch
OpenLDAP
openldap
resultcode
OpenLDAP
resultCode
resultcode
sysconfig
indices
blen
......@@ -156,13 +157,13 @@ argv
kdz
notAllowedOnRDN
hostport
StartTLS
starttls
StartTLS
ldb
servercredp
ldd
IPv
ipv
IPv
hyc
joe
bindmethods
......@@ -170,6 +171,7 @@ armijo
ldp
ISP
len
carLicense
Choi
Clatworthy
scherr
......@@ -185,16 +187,16 @@ attrstyle
directoryOperation
creatorsName
mem
oldPasswdFile
oldpasswdfile
oldPasswdFile
uniqueMember
krb
libpath
acknowledgements
jts
createTimestamp
MIB
LLL
MIB
OpenSSL
openssl
LOF
......@@ -231,10 +233,10 @@ Subbarao
aeeiib
oidlen
submatches
PEM
olc
OLF
PEM
PDU
OLF
LDAPSchemaExtensionItem
auth
Pierangelo
......@@ -271,12 +273,13 @@ rdn
wZFQrDD
OTP
olcSizeLimit
PRD
sbi
pos
sbi
PRD
pre
stringal
retoidp
sudoadm
sdf
efgh
accesslog
......@@ -290,8 +293,8 @@ sel
bvec
TBC
stringbv
SHA
Sep
SHA
ptr
conn
pwd
......@@ -308,8 +311,8 @@ myOID
supportedSASLMechanism
supportedSASLmechanism
realnamingcontext
UCD
SMD
UCD
keytab
portnumber
uncached
......@@ -322,8 +325,8 @@ sasldb
UCS
searchDN
keytbl
UDP
tgz
UDP
freemods
prepend
errText
......@@ -340,22 +343,22 @@ crit
objectClassViolation
ssf
ldapfilter
vec
TOC
rwm
TOC
vec
pwdChangedTime
tls
peernamestyle
xpasswd
SRP
tmp
SRP
SSL
dupbv
CPUs
SRV
entrymods
sss
rwx
sss
reqNewRDN
rebindproc
olcOverlayConfig
......@@ -380,8 +383,8 @@ wildcards
uri
tty
url
sortKey
XED
sortKey
UTF
vlv
TXN
......@@ -406,12 +409,13 @@ MANCOMPRESSSUFFIX
memberAttr
multiclassing
memberURL
sudoers
pwdMaxFailure
pseudorootdn
GDBM
LIBRELEASE
DSA's
DSAs
DSA's
realloc
booleanMatch
compareTrue
......@@ -467,8 +471,8 @@ pwdMinLength
iZ
ldapdelete
xyz
rdbms
RDBMs
rdbms
extparam
mk
ng
......@@ -527,8 +531,8 @@ ZZ
LDVERSION
testAttr
backend
backends
backend's
backends
BerValues
Solaris
structs
......@@ -540,9 +544,9 @@ ostring
policyDN
testObject
pwdMaxAge
binddn
bindDN
bindDn
bindDN
binddn
distributedOperation
schemachecking
strvals
......@@ -570,6 +574,7 @@ protocolError
errno
errOp
serverctrls
recursivegroup
integerMatch
moduledir
dynstyle
......@@ -582,14 +587,14 @@ IEEE
regex
SIGINT
slappasswd
errABsObject
errAbsObject
errABsObject
ldapexop
objectIdentifier
objectidentifier
objectIdentifier
deallocators
mirrormode
MirrorMode
mirrormode
loopDetect
SIGHUP
authMethodNotSupported
......@@ -606,8 +611,8 @@ filtercomp
expr
syntaxes
memrealloc
returncode
returnCode
returncode
OpenLDAP's
exts
bitstringa
......@@ -630,8 +635,8 @@ lastName
lldap
cachesize
slapauth
attributeType
attributetype
attributeType
GSER
olcDbNosync
typedef
......@@ -665,9 +670,9 @@ proxying
organisations
rewriteMap
monitoredInfo
modrDN
ModRDN
modrdn
ModRDN
modrDN
HREF
inline
multiproxy
......@@ -679,8 +684,8 @@ reqReferral
rlookups
siiiib
LTSTATIC
timelimitExceeded
timeLimitExceeded
timelimitExceeded
XKYnrjvGT
subtrees
unixODBC
......@@ -730,8 +735,8 @@ POSIX
pathname
noSuchObject
proxyOld
BerElement
berelement
BerElement
sbiod
plugin
http
......@@ -741,8 +746,8 @@ ldbm
numericStringSubstringsMatch
internet
storages
WhoAmI
whoami
WhoAmI
criticality
addBlanks
logins
......@@ -804,6 +809,7 @@ logold
proxyattrset
proxyAttrSet
proxyAttrset
mary
crlcheck
olcBdbConfig
kadmin
......@@ -989,6 +995,7 @@ subord
namingViolation
inappropriateAuthentication
mixin
suders
syntaxOID
olcTLSCACertificateFile
IGJlZ
......@@ -1099,6 +1106,7 @@ dynamicObject
objectclass
objectClass
sizeLimitExceeded
accountadm
reqControls
modme
shtool
......@@ -1408,8 +1416,8 @@ reqOld
kbyte
monitorCounter
quickstart
olcConstraintConfig
UUID
olcConstraintConfig
rootpw
veryclean
syslogged
......@@ -1555,6 +1563,6 @@ slimit
ali
attributeoptions
uidNumber
CA's
CAs
CA's
namingContext
doc/guide/admin/master.sdf
View file @ 43a8dc82
......@@ -42,6 +42,9 @@ PB:
!include "slapdconfig.sdf"; chapter
PB:
!include "access-control.sdf"; chapter
PB:
!include "runningslapd.sdf"; chapter
PB:
......
doc/guide/admin/slapdconf2.sdf
View file @ 43a8dc82
This diff is collapsed.
doc/guide/admin/slapdconfig.sdf
View file @ 43a8dc82
......@@ -91,9 +91,8 @@ H4: access to <what> [ by <who> [<accesslevel>] [<control>] ]+
This directive grants access (specified by <accesslevel>) to a set
of entries and/or attributes (specified by <what>) by one or more
requestors (specified by <who>). See the {{SECT:The access
Configuration Directive}} section of this chapter for a summary of
basic usage.
requestors (specified by <who>). See the {{SECT:Access Control}} section of
this guide for basic usage.
!if 0
More details discussion of this directive can be found in the
......@@ -503,418 +502,3 @@ containing the database and associated indices live.
\Default:
> directory /usr/local/var/openldap-data
H2: The access Configuration Directive
Access to entries and attributes is controlled by the
access configuration file directive. The general form of an
access line is:
> <access directive> ::= access to <what>
> [by <who> [<access>] [<control>] ]+
> <what> ::= * |
> [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
> [filter=<ldapfilter>] [attrs=<attrlist>]
> <basic-style> ::= regex | exact
> <scope-style> ::= base | one | subtree | children
> <attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
> <attr> ::= <attrname> | entry | children
> <who> ::= * | [anonymous | users | self
> | dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
> [dnattr=<attrname>]
> [group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
> [peername[.<basic-style>]=<regex>]
> [sockname[.<basic-style>]=<regex>]
> [domain[.<basic-style>]=<regex>]
> [sockurl[.<basic-style>]=<regex>]
> [set=<setspec>]
> [aci=<attrname>]
> <access> ::= [self]{<level>|<priv>}
> <level> ::= none | disclose | auth | compare | search | read | write | manage
> <priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
> <control> ::= [stop | continue | break]
where the <what> part selects the entries and/or attributes to which
the access applies, the {{EX:<who>}} part specifies which entities
are granted access, and the {{EX:<access>}} part specifies the
access granted. Multiple {{EX:<who> <access> <control>}} triplets
are supported, allowing many entities to be granted different access
to the same set of entries and attributes. Not all of these access
control options are described here; for more details see the
{{slapd.access}}(5) man page.
H3: What to control access to
The <what> part of an access specification determines the entries
and attributes to which the access control applies. Entries are
commonly selected in two ways: by DN and by filter. The following
qualifiers select entries by DN:
> to *
> to dn[.<basic-style>]=<regex>
> to dn.<scope-style>=<DN>
The first form is used to select all entries. The second form may
be used to select entries by matching a regular expression against
the target entry's {{normalized DN}}. (The second form is not
discussed further in this document.) The third form is used to
select entries which are within the requested scope of DN. The
<DN> is a string representation of the Distinguished Name, as
described in {{REF:RFC4514}}.
The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
or {{EX:children}}. Where {{EX:base}} matches only the entry with
provided DN, {{EX:one}} matches the entries whose parent is the
provided DN, {{EX:subtree}} matches all entries in the subtree whose
root is the provided DN, and {{EX:children}} matches all entries
under the DN (but not the entry named by the DN).
For example, if the directory contained entries named:
> 0: o=suffix
> 1: cn=Manager,o=suffix
> 2: ou=people,o=suffix
> 3: uid=kdz,ou=people,o=suffix
> 4: cn=addresses,uid=kdz,ou=people,o=suffix
> 5: uid=hyc,ou=people,o=suffix
\Then:
. {{EX:dn.base="ou=people,o=suffix"}} match 2;
. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
Entries may also be selected using a filter:
> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
search filter, as described in {{REF:RFC4515}}. For example:
> to filter=(objectClass=person)
Note that entries may be selected by both DN and filter by
including both qualifiers in the <what> clause.
> to dn.one="ou=people,o=suffix" filter=(objectClass=person)
Attributes within an entry are selected by including a comma-separated
list of attribute names in the <what> selector:
> attrs=<attribute list>
A specific value of an attribute is selected by using a single
attribute name and also using a value selector:
> attrs=<attribute> val[.<style>]=<regex>
There are two special {{pseudo}} attributes {{EX:entry}} and
{{EX:children}}. To read (and hence return) a target entry, the
subject must have {{EX:read}} access to the target's {{entry}}
attribute. To add or delete an entry, the subject must have
{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
have {{EX:write}} access to the entry's parent's {{EX:children}}
attribute. To rename an entry, the subject must have {{EX:write}}
access to entry's {{EX:entry}} attribute AND have {{EX:write}}
access to both the old parent's and new parent's {{EX:children}}
attributes. The complete examples at the end of this section should
help clear things up.
Lastly, there is a special entry selector {{EX:"*"}} that is used to
select any entry. It is used when no other {{EX:<what>}}
selector has been provided. It's equivalent to "{{EX:dn=.*}}"
H3: Who to grant access to
The <who> part identifies the entity or entities being granted
access. Note that access is granted to "entities" not "entries."
The following table summarizes entity specifiers:
!block table; align=Center; coltags="EX,N"; \
title="Table 6.3: Access Entity Specifiers"
Specifier|Entities
*|All, including anonymous and authenticated users
anonymous|Anonymous (non-authenticated) users
users|Authenticated users
self|User associated with target entry
dn[.<basic-style>]=<regex>|Users matching a regular expression
dn.<scope-style>=<DN>|Users within scope of a DN
!endblock
The DN specifier behaves much like <what> clause DN specifiers.
Other control factors are also supported. For example, a {{EX:<who>}}
can be restricted by an entry listed in a DN-valued attribute in
the entry to which the access applies:
> dnattr=<dn-valued attribute name>
The dnattr specification is used to give access to an entry
whose DN is listed in an attribute of the entry (e.g., give
access to a group entry to whoever is listed as the owner of
the group entry).
Some factors may not be appropriate in all environments (or any).
For example, the domain factor relies on IP to domain name lookups.
As these can easily be spoofed, the domain factor should be avoided.
H3: The access to grant
The kind of <access> granted can be one of the following:
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
title="Table 6.4: Access Levels"
Level Privileges Description
none =0 no access
disclose =d needed for information disclosure on error
auth =dx needed to authenticate (bind)
compare =cdx needed to compare
search =scdx needed to apply search filters
read =rscdx needed to read search results
write =wrscdx needed to modify/rename
manage =mwrscdx needed to manage
!endblock
Each level implies all lower levels of access. So, for example,
granting someone {{EX:write}} access to an entry also grants them
{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
{{EX:disclose}} access. However, one may use the privileges specifier
to grant specific permissions.
H3: Access Control Evaluation
When evaluating whether some requester should be given access to
an entry and/or attribute, slapd compares the entry and/or attribute
to the {{EX:<what>}} selectors given in the configuration file.
For each entry, access controls provided in the database which holds
the entry (or the first database if not held in any database) apply
first, followed by the global access directives. Within this
priority, access directives are examined in the order in which they
appear in the config file. Slapd stops with the first {{EX:<what>}}
selector that matches the entry and/or attribute. The corresponding
access directive is the one slapd will use to evaluate access.
Next, slapd compares the entity requesting access to the {{EX:<who>}}
selectors within the access directive selected above in the order
in which they appear. It stops with the first {{EX:<who>}} selector
that matches the requester. This determines the access the entity
requesting access has to the entry and/or attribute.
Finally, slapd compares the access granted in the selected
{{EX:<access>}} clause to the access requested by the client. If
it allows greater or equal access, access is granted. Otherwise,
access is denied.
The order of evaluation of access directives makes their placement
in the configuration file important. If one access directive is
more specific than another in terms of the entries it selects, it
should appear first in the config file. Similarly, if one {{EX:<who>}}
selector is more specific than another it should come first in the
access directive. The access control examples given below should
help make this clear.
H3: Access Control Examples
The access control facility described above is quite powerful. This
section shows some examples of its use for descriptive purposes.
A simple example:
> access to * by * read
This access directive grants read access to everyone.
> access to *
> by self write
> by anonymous auth
> by * read
This directive allows the user to modify their entry, allows anonymous
to authentication against these entries, and allows all others to
read these entries. Note that only the first {{EX:by <who>}} clause
which matches applies. Hence, the anonymous users are granted
{{EX:auth}}, not {{EX:read}}. The last clause could just as well
have been "{{EX:by users read}}".
It is often desirable to restrict operations based upon the level
of protection in place. The following shows how security strength
factors (SSF) can be used.
> access to *
> by ssf=128 self write
> by ssf=64 anonymous auth
> by ssf=64 users read
This directive allows users to modify their own entries if security
protections have of strength 128 or better have been established,
allows authentication access to anonymous users, and read access
when 64 or better security protections have been established. If
client has not establish sufficient security protections, the
implicit {{EX:by * none}} clause would be applied.