Part I Directory Server Reference (Sun Java System Directory Server Enterprise Edition 6.0 Reference)
&& Part I Directory Server ReferenceSun Java System Directory Server Enterprise Edition 6.0 ReferencePart&I Directory Server Reference
This part explains how Directory Server works. The information here
is primarily descriptive. For instructions, try
This part covers the following chapters.
a short, high level view of key Directory Server concepts.
you background on authentication, encryption, access control ACIs, and auditing.
the SNMP, CMM/JMX, and LDAP interfaces available for monitoring Directory Server.
you understand Directory Server replication, replication topologies, and
use of the retro changelog.
what caches are used by Directory Server, and how to size caches.
how Directory Server work, and identifies the default and system indexes.
describes Directory Server log
how groups and roles are used by Directory Server to associate entries
with each other.
the CoS mechanism, which allows attributes to be shared between entries.
how Directory Server implements the DSMLv2 standard.
lists supported locales and language subtypes.
LDAP URLs that are used to search the directory.
the LDAP Data Interchange Format, and LDAP search filters.
lists common error and warning messages Directory Server can
write to the errors log file.
describes the file layout resulting when you install Directory Server and
create Directory Server instances.
For additional reference information, see .
Chapter&1 Directory Server Overview
This chapter outlines the architecture of Directory Server. This
chapter includes the following topics.
introduces Directory Server.
addresses key Directory Server concepts.
Introduction to Directory Server
Directory Server serves directory data to standards compliant LDAP
and DSML applications. Directory Server stores the data in customized,
binary tree databases, allowing quick searches even for large data sets.
Directories are object oriented databases. Directories organize their
data objects, called entries, into a directory information tree, often called
a DIT. Each entry is identified by a distinguished name, such as uid=bjensen,ou=people,dc=example,dc=com. The distinguished name identifies where the entry is located in
the directory information tree. For example, uid=bjensen,ou=people,dc=example,dc=com is a user entry for Barbara Jensen on the ou=people branch
of the dc=example,dc=com part of the tree.
Each directory entry has attributes. For entries that concern people,
these attributes may reflect names, phone numbers, and email addresses, for
example. An attribute has at least one type name, which is the name of the
attribute. For example, people entries can have an attribute surname,
which can also be called by the shorter name sn. Attributes
can also have one or more values. For example, if Barbara Jensen marries Quentin
Cubbins, and takes Quentin's surname, her entry could have sn: Jensen and sn: Cubbins.
Directories are designed to be fast when looking up entries based on
the values of their attributes. An example query might be, &Find all
the entries under dc=example,dc=com with surname Jensen.&
This fast lookup capability makes directories well suited for applications
where you store information that must be read often. Directories are therefore
good data stores for telephone and email information. Directories are also
good for handling authentication credentials, identity information, and application
configuration data.
Directory Server is also designed to handle high update rates as
the information in the directory changes. Today, the size of many directory
deployments mean that handling updates well can be as important as handling
Directory Server supports many directory related standards and RFCs. Directory Server allows
fast data replication across the network for high availability. Directory Server lets
you configure servers comprehensively without restarting them. Furthermore, Directory Server gives
you extensive control over access to directory data.
The list of Directory Server features is too long to cover in a short
introduction.
a more extensive list. The other chapters in this part of this Reference help
you to understand many of the features in detail.
Directory Server Architecture
This section succinctly addresses key concepts of Directory Server from
the point of view of someone who must install and manage Directory Server.
This section touches on the following topics.
Comparison of Software Installation
and Server Instances
For each installation of Directory Server software, you can create
multiple server instances. Although you may create server instances in the
place on the file system where you install the software, nothing requires
you to put both the software and the instances side by side.
The Directory Server software you install includes the executable
files, template data, and sample files needed to create, run, and manage actual
servers. As the software is separate from the actual servers, you can apply
patches or service packs to the software without changing the server data.
You therefore do not need to patch each server instance, but instead only
the software installation.
A Directory Server instance holds the configuration data and the
directory data required to serve directory client applications. Although in
production systems you carefully control the user identity of the server,
you can typically create and run a Directory Server instance as any user
on the system. The directory data belongs then to the user who created the
In , you see that
is clearly separate from .
In particular, notice that the documentation mentions install-path when
referring to the software installation, but instance-path when
referring to a server instance.
Communication With Client Applications
Directory Server listens for LDAP and DSML client application traffic
on the port numbers you configure. Directory Server listens for LDAP connections
as soon as the server starts. Directory Server only listens for DSML connections
over HTTP if you enable the DSML service.
By default, Directory Server listens for LDAP connections on port
389 if the instance was created by root, 1389 if the instance
was created by non-root. By default, Directory Server listens
for LDAP connections over SSL on port 636 if the instance was created by root, 1636 if the instance was created by non-root.
The DSML/HTTP port number is not defined by default. Instead, you supply a
port number when enabling the DSML service.
In order to enable client applications to reach Directory Server,
you create instances on hosts with static IP addresses. The hostname is also
usually referenced in DNS. Client applications typically need at least two
pieces of information to access the directory.
The hostname, or at least the IP address, of the system on
which Directory Server runs.
The port number on which Directory Server listens for client
connections.
LDAP clients and servers do not usually open a new connection for every
request. In the LDAP model, a client connects to the server to authenticate
before performing other operations. The connection and authentication process
is referred to as binding. Client applications can bind with credentials,
but they can also bind anonymously. Directory Server lets you configure
access accordingly both for known and anonymous clients. Client applications
can also keep a connection open, but bind again, thus changing the authentication
identity. This technique can reduce the costs of creating a new connection.
Once the bind has been performed and the client is authenticated, the
client can request the following operations.
Add a new directory entry.
Checks whether an attribute value is the same as a given value.
Delete a directory entry.
Change one or more attributes of a directory entry.
Change the distinguished name of a directory entry.
This operation is for moving directory entries from one part of the
directory information tree to another. For example, you could move uid=bjensen,ou=employees,dc=example,dc=com to uid=bjensen,ou=people,dc=example,dc=com.
When you move an parent entry, such as ou=people,dc=example,dc=com, the operation can take a very long time as Directory Server must
move all child entries of the parent as well.
Change the relative distinguished name of a directory entry.
The relative distinguished name is the attribute value used to distinguish
a directory entry from the others at the same level of the directory information
This operation is for renaming directory entries. For example, you could
rename uid=bjensen,ou=employees,dc=example,dc=com to uid=bcubbins,ou=people,dc=example,dc=com.
This operation is a special case of modDN. The modRDN operation is always
relatively fast, however, as it involves moving only leaf entries.
Find all the directory entries under a specified point in
the directory tree that have attribute values matching a filter.
A search filter can specify one or more attribute characteristics. For
example, to find entries with the surname Jensen, you use the LDAP filter (sn=Jensen). To find entries with surname Jensen and user ID beginning
with the letter B, you use the LDAP filter (&(sn=Jensen)(uid=b*)).
When finished performing operations, a client can unbind. After unbinding,
the connection is dropped by the client and the server. Client applications
can also abandon operations, such as a search that is taking too long.
Directory Server can handle many client connections simultaneously.
To handle connections, Directory Server consumes free file descriptors,
and manages a number of threads. You can limit the system resources available
to Directory Server through the server configuration. See
for details.
Directory Server Configuration
Directory Server stores server instance configuration data in files,
but the configuration data is also accessible over LDAP.
The files are stored under instance-path as
follows. Directory Server stores the LDAP schema, which define what directory
entries can contain, under instance-path/config/schema/. See
reference information about the schema, and
for instructions
on managing schema. Directory Server stores other configuration information
file, instance-path/config/dse.ldif. Avoid updating this
file by hand.
Over LDAP, the schema information is accessible under cn=schema.
The other configuration information is accessible under cn=config.
In practice, you do not generally update data under cn=config directly.
Instead, you use either the web based Directory Service Control Center, or the dsconf command.
Both Directory Service Control Center and the dsconf command change Directory Server over
LDAP. Yet, both also spare you much of the complexity of making configuration
adjustments with LDAP modify operations.
Almost all Directory Server product documentation is devoted to Directory Server configuration.
find extensive instructions for accomplishing a variety of tasks using command
line configuration tools. The Directory Service Control Center online help can help get you back
on track when the Directory Service Control Center interface does not seem intuitive enough.
Data Storage in Directory Server
Directory Server manages at least one binary tree database to hold
directory data. By default, database files are stored under instance-path/db/. In general, do not change or move
these files.
If you examine the content of the instance-path/db/ directory, you find database log files. You also find subdirectories
for each database managed by the server. For instance, instance-path/db/example/ holds data for the directory entries
under dc=example,dc=com. When you examine the files, you
find a number of database indexes, such as example_sn.db3 for
surname attribute values. You also find a example_id2entry.db3 file
containing directory entry information. You can configure Directory Server to
encrypt the information in these files if necessary.
From the point of view of client applications, Directory Server presents
the directory data stored as directory entries arranged in the directory information
tree. Directory Server uses the attribute value indexes to retrieve entries
quickly. You can configure which indexes Directory Server maintains.
For instructions on backing up directory data, see .
For instructions on configuring indexes, see . You
can also back up directory data and configure indexes using Directory Service Control Center.
Data Replication Between Server Instances
Directory Server allows you to replicate directory data among as
many server instances as necessary. Directory Server replication works
as an LDAP extended operation that replays update operations from one server
to another. The protocol for Directory Server replication is optimized
to work quickly over the network. The protocol is also optimized to resolve
conflicts when the same data is modified simultaneously on two different server
instances.
The unit of Directory Server replication is the suffix. A replication
agreement between two servers handles all the directory entries under a base
entry in the directory information tree, such as dc=example,dc=com.
Each agreement to replicate is set up point to point. On one hand, point to
point agreements prevent replication from single points of failure when the
network becomes partitioned. On the other hand, point to point agreements
can be complex to manage as the number of replicas increases. Luckily, Directory Service Control Center handles
much of the complexity for you. Directory Service Control Center allows you to manage groups of
replicas that provide a common directory service.
You can configure timing, priority, and which data is replicated. You
can also configure some servers, called masters, to
accepts both updates and lookups. You can configure other servers, called consumers, to accept only lookups. In addition, you can publish
update information over LDAP for client applications that must follow updates
as they happen. For further explanation of replication, see . For
instructions on configuring replication, see .
Access Control in Directory Server
Directory Server offers an access control mechanism that works through aci attributes placed on directories entries. ACI stands for Access
Control Instruction.
ACIs are evaluated based on a user's bind identity. ACIs can be evaluated
therefore for all users who can bind to the directory. ACIs can also be applied
for anonymous users who did not provide bind credentials. Rules about the
bind identity can specify not only which users, but also which systems the
users connect from, what time of day they connect, or what authentication
method they use.
You configure an ACI to apply to the entries in its scope. Entries that
can be in scope include entries on the branch of the directory information
tree starting with the entry holding the ACI. Directory Server allows you
to configure ACIs to be applied according to a number of different criteria. Directory Server also
lets you configure ACIs not only to allow access, but also to deny access.
ACIs can specify which operations are allowed and denied. For example,
you typically allow many users to read information, but only a few to update
and add directory data.
For further explanation of access control in Directory Server, see . For
instructions on configuring access control, see .
Chapter&2 Directory Server Security
For information about the security in Directory Server, see the following
How Directory Server Provides Security
Directory Server provides security through a combination of the following
Authentication
Authentication is a means for one
party to verify another&s identity. For example, a client gives a password
to Directory Server during an LDAP bind operation. Policies define the
criteria that a password must satisfy to be considered valid, for example,
age, length, and syntax. Directory Server supports anonymous authentication,
password-based authentication, certificate-based authentication, SASL-based
authentication, and proxy authentication. When authentication is denied, Directory Server
provides the following mechanisms to protect data: account inactivation and
global lockout. For information about authentication, see .
Encryption
Encryption protects the privacy of
information. When data is encrypted, the data is scrambled in a way that only
a legitimate recipient can decode. Directory Server supports SSL encryption
and attribute encryption. For information about encryption, see .
Access control
Access control tailors the access
rights granted to different directory users, and provides a means of specifying
required credentials or bind attributes. For information about access control
Auditing determines whether the security
of a directory has been compromised. For example, log files maintained by
a directory can be audited. For information about log files, see .
How Directory Server Provides Access Control
Directory Server uses access control instructions (ACIs) to define
what rights to grant or deny to requests from LDAP clients. When a directory
server receives a request, it uses the ACIs defined in the server, and any
authentication information provided by the user to allow or deny access to
directory information. The server can allow or deny permissions such as read,
write, search, or compare.
For information about ACIs in Directory Server, see the following
Introduction to ACIs
ACIs are stored in the aci operational attribute.
The aci attribute is available for use on every entry in
the directory, regardless of whether the aci attribute
is defined for the object class of the entry. The aci attribute is multi-valued, therefore multiple
ACIs can be defined for the same portion of a directory.
ACIs can be used to control access to the following portions of a directory:
The entire directory
A subtree of the directory
Specific entries in the directory, including entries that
define configuration tasks
A specific set of entry attributes
Specific entry attribute values
ACIs can be used to define access for the following users:
A specific user
All users belonging to a specific group or role
All users of the directory
A specific client identified by its IP address or DNS name
Scope and Hierarchy in ACIs
ACIs can be created at any node in a directory tree, including the root
The scope of an ACI can be the target entry, the target entry and its
immediate children, or the target entry and all of its children. When no scope
is specified, the ACI applies to the target entry and all of its children.
When a server evaluates access permissions to an entry, it verifies
the ACIs for the entry and the ACIs for the parent entries back up to the
base of the entry&s root suffix. ACIs are not evaluated across chained
suffixes on other servers.
Access to an entry in a server must be explicitly granted by an ACI.
By default, ACIs define anonymous read access and allow users to modify their
own entries, except for attributes needed for security. If no ACI applies
to an entry, access is denied to all users except the Directory Manager.
Access granted by an ACI is allowed unless any other ACI in the hierarchy
denies it. ACIs that deny access, no matter where they appear in the hierarchy,
take precedence over ACIs that allow access to the same resource.
The Directory Manager is the only privileged user to whom access control
does not apply. When a client is bound to the directory as the Directory Manager,
the server does not evaluate any ACIs before performing operations.
In previous versions of Directory Server, ACIs could not be added or
deleted directly under the root DSE. This limitation has been
removed in Directory Server
ACI Limitations
The following restrictions apply to ACIs
If your directory tree is distributed over several servers
by using the chaining feature, the following restrictions apply to the use
of keywords in access control statements:
ACIs that depend on the groupdn keyword
must be located on the same server as the group entry. If the group is dynamic,
then all members of the group must have an entry on the server too. If the
group is static, the members& entries can be located on remote servers.
ACIs that depend on the roledn keyword
must be located on the same server as the role definition entry. Every entry
that is intended to have the role must also be located on the same server.
Attributes generated by a CoS cannot be used in all ACI keywords.
Specifically, you should not use attributes generated by CoS with the userattr and userdnattr keywords because the access control
rule will not work.
Access control rules are always evaluated on the local server.
You must not specify the hostname or port number
of the server in LDAP URLs used in ACI keywords.
You cannot grant a user the right to proxy as the Directory
Manager, nor can you grant proxy rights to the Directory Manager.
The cache settings used for ensuring that the server fits
the physical memory available do not apply to ACI caches,
which means that an excessive number of ACIs may saturate available memory.
Default ACIs
The following default ACIs are defined on the root DSE:
All users have anonymous access to the directory for search,
compare, and read operations (except for the userpassword attribute).
Bound users can modify their own password.
Users in the group cn=Administrators,cn=config have
full access to all entries. This is equivalent to Directory Manager access,
although unlike Directory Manager, users in the Administration Group are subject
ACIs and Replication
ACIs are stored as attributes of entries. Therefore, if an entry that
contains ACIs is part of a replicated suffix, the ACIs are replicated like
any other attribute.
ACIs are always evaluated locally, on the directory server that services
the incoming LDAP requests.
When a consumer server receives an update request, the consumer server
returns a referral to the master server for evaluation of whether the request
can be serviced on the master.
Effective Rights
The effective rights feature can be used to obtain the following information:
Rights information, including entry level rights, attribute
level rights and logging.
Permissions for write, self write add, and self write delete.
Logging information for debugging access control problems.
To use the effective rights feature, you must have the access control
rights to use the effective rights control and read access to the aclRights attribute.
If a proxy control is attached to an effective rights control-based
search operation, the effective rights operation is authorized as the proxy
user. Therefore the proxy user needs to have the right to use the effective
rights control. The entries that the proxy user has the right to search and
view are returned.
ACI Syntax
The aci attribute has the following syntax:
aci: (target)(version 3.0; acl "name";permission bindRules;)
The following values are used in the ACI syntax:
Specifies the entry, attributes, or set of entries and attributes
for which you want to control access. The target can
be a distinguished name, one or more attributes, or a single LDAP filter.
The target is optional. When a target is not specified,
the ACI applies to the entry on which it is defined and its subtree. For information
about targets, see .
version 3.0
A required string that identifies the ACI version.
A required string that identifies the ACI. Although there
are no restrictions on the name, it is good practice to use unique, descriptive
names for ACIs. Using unique names, will allow you to use Get Effective
Rights to determine which ACI is in force.
permission
States what rights you are allowing or denying. For information
about permissions, see .
Specifies the credentials and bind parameters that a user
has to provide to be granted access. Bind rules can also be based on user
membership, group membership, or connection properties of the client. For
information about bind rules, see .
The permission and bind rule portions of the ACI are set as a pair,
also called an Access Control Rule (ACR). The specified permission to access
the target is granted or denied depending on whether the accompanying bind
rule is evaluated to be true or false.
Multiple targets and multiple permission-bind rule pairs can be used.
This allows you to refine both the entry and attributes being targeted and
efficiently set multiple access controls for a given target. The following
example shows an ACI with multiple targets and multiple permission-bind rule
aci: (targetdefinition)...(targetdefinition)(version 3.0;acl "name";
permission bindR ...; permission bindR)
In the following example, the ACI states that bjensen has
rights to modify all attributes in her own directory entry:
aci: (target="ldap:///uid=bjensen,dc=example,dc=com"
(targetattr="*")(targetScope="subtree")(version 3.0; acl "example";
allow (write) userdn="ldap:///self";)
The following sections describe the syntax of targets, permissions and
bind rules.
ACI Targets
An ACI target statement specifies the entry, attributes, or set of entries
and attributes for which you want to control access.
Target Syntax
An ACI target statement has this syntax:
(keyword = "expression")
The following values are used in the target.
Indicates the type of target.
expression
Identifies the target. The quotation marks ("")
around expression are syntactically required, although
the current implementation accepts expressions like targetattr=*.
Indicates that the target is or is not the object specified
in the expression.
The != operator cannot be used with the targettrfilters keyword or the targetscope keyword.
Target Keywords
For a description of target keywords, see the following sections:
The following table lists the target keywords and their associated expressions.
Target Keywords and Their Expressions
Type of target&
Expression&
A directory entry or its subtree&
ldap:///distinguished_name
targetattr
The attributes of an entry&
targetfilter
A set of entries or attributes that match an LDAP filter&
LDAP_filter
targetattrfilters
An attribute value or combination of values that match an LDAP filter&
LDAP_operation:LDAP_filter
targetScope
The scope of the target&
base, onelevel, subtree
target KeywordThe target keyword specifies that an ACI is defined
for a directory entry. The target keyword uses the following
(target = "distinguished_name")
(target != "distinguished_name")
The distinguished name must be in the subtree rooted at the entry where
the ACI is defined. For example, the following target may be used in an ACI
on ou=People,dc=example,dc=com:
(target = "ldap:///uid=bjensen,ou=People,dc=example,dc=com")
The DN of the entry must be a distinguished name in string representation
(RFC 4514). Therefore, characters that are syntactically significant for a
DN, such as commas, must be escaped with a single backslash (\).
Wild cards, show as asterisk characters can be used in the expression
for the target keyword. The asterisk matches an attribute
value, a substring of a value, or a DN component. For example, all of the
following expressions match uid=bjensen,ou=people,dc=example,dc=com.
target= "ldap:///uid=bj*,ou=people,dc=example,dc=com"
target= "ldap:///uid=*,ou=people,dc=example,dc=com"
target= "ldap:///*,ou=people,dc=example,dc=com"
target= "ldap:///uid=bjensen,*,dc=com"
target= "ldap:///uid=bjensen*"
The following further examples show permitted uses of wild cards.
target="ldap:///uid=*,dc=example,dc=com"
This target matches every entry in the entire < tree
that has the UID attribute in the entry's RDN.
target="ldap:///*Anderson,ou=People,dc=example,dc=com"
This target matches every entry in the ou=People branch
whose RDN ends with Anderson, regardless of the naming attribute.
target="ldap:///uid=*,ou=*,dc=example,dc=com"
This target matches every entry in the < tree
whose distinguished name contains the uid and ou attributes.
Other usage of wild cards to such as target="ldap:///uid=bjensen,o*,dc=com" might be accepted, but are deprecated.
targetattr KeywordThe targetattr keyword specifies that an ACI is defined
for one or more attributes in the targeted entries. The targetattr keyword
uses the following syntax:
(targetattr = "attribute")
(targetattr != "attribute")
If no targetattr keyword is present, no attributes
are targeted. To target all attributes, the targetattr keyword
must be targetattr="*".
Targeted attributes do not need to exist on the target entry or its
subtree, but the ACI applies whenever they do.
Targeted attributes do not need to be defined in the schema. The absence
of schema checking makes it possible to implement an access control policy
before importing data and its schema.
The targetattr keyword can be used for multiple attributes,
by using this syntax:
(targetattr = "attribute1 || attribute2|| ... attributeN")
Targeted attributes include all subtypes of the named attribute. For
example, (targetattr = "locality") also targets lang-fr.
Wild cards can be used in the expression for the targetattr keyword,
but the use of wild cards would serve no purpose and may reduce performance.
targetfilter KeywordThe targetfilter keyword is used in ACIs to target
entries that match an LDAP filter. The ACI applies to all entries that match
the LDAP filter and that are in the scope of the ACI.
The targetfilter keyword uses the following syntax:
(targetfilter = "(standard LDAP search filter)")
Example 2&1
Using the targetfilter Keyword
to Target Specific EntriesThe following example is for employees with a status of salaried or
contractor, and an attribute for the number of hours worked as a percentage
of a full-time position. The filter targets entries for contractors or part-time
employees:
(targetfilter = "(|(status=contractor)(fulltime&=79))")
The Netscape extended filter syntax is not supported in ACIs. For example,
the following target filter is not valid:
(targetfilter = "(locality:fr:=&= Qu&bec)")
The filter syntax that describes matching rules for internationalized
values is supported. For example, the following target filter is valid:
(targetfilter = "(locality:2.16.840.1..3.2.18.1.4:=Qu&bec)")
The targetfilter keyword selects whole entries as
targets of the ACI. The targetfilter keyword and the targetattr keyword can be used together to create ACIs that apply
to a subset of attributes in the targeted entries.
targetattrfilters KeywordThe targetattrfilters keyword is used in ACIs to
target specific attribute values by using LDAP filters. By using the targetattrfilters keyword, you can grant or deny permissions on an attribute if that
attribute's value meets the criteria defined in the ACI. An ACI that grants
or denies access based on an attribute's value, is called a value-based
ACI. The targetattrfilters keyword uses this
(targettrfilters="Op=attr1:F1 [(&& attr2:F2)*][;Op=attr:F [(&& attr:F)*]")
The targetattrfilters keyword can have the following
An add or delete operation
To create an attribute
To delete an attribute
The target attributes
Filters that apply to the associated attribute
The following conditions must be met when filters apply to entries,
and those entries are created, deleted or modified:
When an entry is created or deleted, each instance of that
attribute must satisfy the filter.
When an entry is modified, if the operation adds an attribute,
then the add filter that applies to that attribu if the
operation deletes an attribute, then the delete filter that applies to that
attribute must be satisfied.
If individual values of an attribute already present in the
entry are replaced, then the add and delete filters must be satisfied.
Example 2&2
Using the targetattrfilters Keyword
to Allow Users to Add Roles to Their Own EntriesThe following ACI allows users to add any role to their own entry, except
the superAdmin role. It also allows users to add a telephone
number with a 123 prefix.
(targettrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin))
&& telephoneNumber:(telephoneNumber=123*)")
Example 2&3
Using the targetattrfilters Keyword
to Allow Group Members to Modify Specific AttributesThe following example allows members of the Engineering Admins group
to modify the departmentNumber and manager attributes
of all entries in the Engineering business category. This example filters
entries with the businessCategory attributes set to Engineering:
dn: dc=example,dc=com
objectClass: top
objectClass: organization
aci: (targetattr="departmentNumber || manager")
(targetfilter="(businessCategory=Engineering)")
(version 3.0; acl "eng-admins-write"; allow (write)
groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)
targetScope KeywordThe targetScope keyword is used in ACIs to specify
the scope of the ACI. The targetScope keyword uses this
(targetScope="base")
The targetScope keyword can have one of these values:
The ACI applies to the target resource only
The ACI applies to the target resource and its first-generation
The ACI applies to the target resource and its subtree
If the targetScope keyword is not specified, the
default value is subtree.
ACI Permissions
Permissions specify the type of access that is allowed or denied by
the ACI. For information about bind rules, see the following sections:
Permission Syntax
An ACI permission statement has this syntax:
allow|deny (right1, right2 ...)
Rights define the operations you can perform on directory data. In an
ACI statement, rights is a list of comma-separated keywords enclosed within
parentheses.
Rights are granted independently of one another. This means, for example,
that a user who is granted add rights but not delete rights
can create an entry but cannot delete an entry. When you are planning the
access control policy for your directory, ensure that you grant rights in
a way that makes sense for users. For example, it might not make sense to
grant write permission without granting read and search permissions.
Permission Rights
The following rights can be allowed or denied in an ACI permission statement:
Permission to read directory data. This permission applies
only to the search operation.
Permission to modify an entry by adding, modifying, or deleting
attributes. This permission applies to the modify and modify DN operations.
Permission to create entries. This permission applies only
to the add operation
Permission to delete entries. This permission applies only
to the delete operation.
Permission to search for directory data. Users must have Search and Read rights in order to view the data
returned as part of a search result. This permission applies only to the search
operation.
Permission for users to compare data they supply with data
stored in the directory. With compare rights, the directory returns a success
or failure message in response to an inquiry, but the user cannot see the
value of the entry or attribute. This permission applies only to the compare
operation.
Permission for users to add or delete their own DN in an attribute
of the target entry. The syntax of this attribute must be distinguished
name. This right is used only for group management. The Selfwrite permission works with it grants the right
to add or delete the proxy DN from the group entry (not the DN of the bound
Permission for the specified DN to access the target with
the rights of another entry. You can grant proxy access using the DN of any
user in the directory except the Directory Manager DN. You cannot grant proxy
rights to the Directory Manager.
Permission for an entry to be imported to the specified DN.
This permission applies the modify DN operation.
Permission for an entry to be exported from the specified
DN. This permission applies the modify DN operation.
Permission for the specified DN to have the following rights
for the targeted entry: read, write, search, delete, compare, and selfwrite. The All access right does control
permission for the following rights to the target entry: proxy, import, and export.
Permissions for Typical LDAP Operations
This section describes the rights required to perform a set of LDAP
operations.
Adding an entry:
Grant add permission on the entry being added.
Grant write permission on the value of each attribute in the
entry. This right is granted by default but could be restricted using the targettrfilters keyword.
Deleting an entry:
Grant delete permission on the entry to be deleted.
Grant write permission on the value of each attribute in the
entry. This right is granted by default but could be restricted using the targettrfilters keyword.
Modifying an attribute in an entry:
Grant write permission on the attribute type.
Grant write permission on the value of each attribute type.
This right is granted by default but could be restricted using the targettrfilters keyword.
Modifying the RDN of an entry:
Grant write permission on the entry.
Grant write permission on the attribute type used in the new
Grant write permission on the attribute type used in the old
RDN, if you want to grant the right to delete the old RDN.
Grant write permission on the value of attribute type used
in the new RDN. This right is granted by default but could be restricted using
the targettrfilters keyword.
Moving an entry to another subtree:
Grant export permissions on the entry that you want to move.
Grant import permission on the new superior entry of the entry
that you want to move.
Comparing the value of an attribute:
Grant compare permission on the attribute type.
Searching for entries:
Grant search permission on each attribute type used in the
search filter.
Grant read permission on at least one attribute type used
in the entry to ensure that the entry is returned.
Grant read permission an each attribute type to be returned
with the entry.
Example 2&4
Granting ACI Permissions to Perform a SearchThis example configures permissions to allow bjensen to
search her own entry.
(target="ldap:///dc=example,dc=com")
ldapsearch -h host -p port -D "uid=bjensen,dc=example,dc=com" \
-w password -b "dc=example,dc=com" \
"(objectclass=*)" mail
The following ACI determines whether bjensen can
be granted access for searching her own entry:
aci: (targetattr = "mail")(version 3.0; acl "self access to
mail"; allow (read, search) userdn = "ldap:///self";)
The search result list is empty because this ACI does not allow bjensen the right to search on the objectclass attribute.
To perform the search operation described, you must modify the ACI as follows:
aci: (targetattr = "mail || objectclass")(version 3.0; acl
"self access to mail"; allow (read, search) userdn =
"ldap:///self";)
ACI Bind Rules
Bind rules identify the set of users to which an ACI applies. The permission
and bind rule portions of the ACI are set as a pair. The specified permission
to access the target is granted or denied depending on whether the accompanying
bind rule is evaluated to be true or false.
For information about bind rules, see the following sections:
Introduction to Bind Rules
Bind rules identify a set of users by using the following methods:
The users, groups, and roles that are granted access.
The location from which an entity must bind. The location
from which a user authenticates can be spoofed and cannot be trusted. Do not
base ACIs on this information alone.
The time or day on which binding must occur.
The type of authentication that must be in use during binding.
A simple bind rule might require a person accessing the directory to
belong to a specific group. A complex bind rule can require a person to belong
to a specific group and to log in from a machine with a specific IP address,
between 8 am and 5 pm. Additionally, bind rules can be complex constructions
that combine these criteria by using Boolean operators.
The server evaluates the logical expressions used in ACIs according
to a three-valued logic, similar to the one used to evaluate LDAP filters,
as described in section 4.5.1.7 of RFC 4511 Lightweight Directory
Access Protocol (v3). Therefore, if any component in the expression
evaluates to Undefined (for example if the evaluation of the expression aborted
due to a resource limitation), then the server handles this case correctly.
The server does not erroneously grant access because an Undefined value occurred
in a complex Boolean expression.
Bind Rule Syntax
An ACI bind rule has this syntax:
keyword = "expression";
keyword != "expression";
The following values are used in the bind rule:
Indicates the type of bind rule.
expression
Identifies the bind rule.
Bind Rule Keywords
For information about bind rule keywords, see the following sections:
The following table summarizes the keywords for bind rules.
Bind Rule Keywords and Their Expressions
Used to define access based on&
Expression&
Specified user&
ldap:///distinguished_name
ldap:///all
ldap:///anyone
ldap:///self
ldap:///parent
ldap:///suffix??sub?(filter)
Specified group or groups&
[ldap:///DN]
Specified role or roles&
[ldap:///DN]
Matched attribute value&
attribute#bindType
attribute#value
Specified IP address or IP addresses&
IP_address
Specified domain or domains&
DNS_host_name
Specified time of day&
Specified day or days of the week&
sun, mon, tue, wed, thu, fri, and sat
authmethod
Specified authentication method&
none, simple, ssl, sasl authentication_method
userdn KeywordThe userdn keyword is used to allow or deny access
to a specified user. The following sections contain more information about
the userdn keyword.
Syntax of the userdn KeywordThe userdn keyword uses this syntax:
userdn = "ldap:///dn [|| ldap:///dn]..."
userdn != "ldap:///dn [|| ldap:///dn]..."
The userdn keyword can alternatively be expressed
as an LDAP URL filter. For information about expressing the userdn keyword
as an LDAP URL, see .
dn can have of the following values:
distinguished-name
A fully qualified DN. Characters that are syntactically significant
for a DN, such as commas, must be escaped with a single backslash (\).
The wild card * can be used to specify a set of users.
For example, if the following user DN is specified, users with a bind DN beginning
with the letter b are allowed or denied access:
uid=b*,dc=example,dc=com
Allows or denies access for anonymous and authenticated users,
regardless of the circumstances of the bind.
This access can be limited to specific types of access (for example,
access for read or access for search) or to specific subtrees or individual
entries within the directory. The following ACI on the dc=example,dc=com node allows anonymous access to read and search the entire dc=example,dc=com tree.
aci: (version 3.0; acl "anonymous-read-search";
allow (read, search) userdn = "ldap:///anyone";)
Allows or denies access for authenticated users. This all value prevents anonymous access. The following ACI on the dc=example,dc=com node allows authenticated users to read the entire dc=example,dc=com tree:
aci: (version 3.0; acl "all-read";
allow (read) userdn="ldap:///all";)
Allows or denies users access to their own entries if the
bind DN matches the DN of the targeted entry. The following ACI on the dc=example,dc=com node allows authenticated users in the dc=example,dc=com tree
to write to their userPassword attribute.
aci: (targetattr = "userPassword")
(version 3.0; acl "modify own password"; allow (write)
userdn = "ldap:///self";)
Allows or denies users access to the entry if the bind DN
is the parent of the targeted entry.
The following ACI on the dc=example,dc=com node allows
authenticated users in the dc=example,dc=com tree to modify
any child entries of their bind DN:
aci: (version 3.0; acl "parent access";
allow (write) userdn="ldap:///parent";)
LDAP URLs in the userdn KeywordThe userdn keyword can also be expressed as an LDAP
URL with a filter, by using this syntax:
userdn = ldap:///suffix??sub?(filter)
LDAP URLs always apply to the local server. Do not specify a hostname
or port number within an LDAP URL.
The following ACI on the dc=example,dc=com node allows
all users in the accounting and engineering branches
of the < tree to access to the targeted resource
dynamically based on the following URL
userdn = "ldap:///dc=example,dc=com??sub?(|(ou=eng)(ou=acct))"
LDAP URLs can be used with the logical OR operator and the not-equal
operator as shown in the following examples.
Example 2&5
Using the userdn Keyword With
a Logical OR Operator in LDAP URLsThis bind rule is evaluated to be true for users that bind with either
of the specified DN patterns.
userdn = "ldap:///uid=b*, || ldap:///cn=b*,dc=example,dc=com";
Example 2&6
Using the userdn Keyword With
a Not-Equal Operator in LDAP URLsThis bind rule is evaluated to be true if the client is not binding
as a UID-based DN in the accounting subtree. This bind rule only makes sense
if the targeted entry is not under the accounting branch of the directory
userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";
groupdn KeywordThe groupdn keyword specifies that access to a targeted
entry is granted or denied if the user binds by using a DN that belongs to
a specific group. The groupdn keyword uses this syntax:
groupdn="ldap:///groupDN [|| ldap:///groupDN]..."
The bind rule is evaluated to be true if the bind DN belongs to a group
that is specified by any of the values for groupDN.
In the following example, the bind rule is true if the bind DN belongs
to the Administrators group :
aci: (version 3.0; acl "Administrators-write"; allow (write)
groupdn="ldap:///cn=Administrators,dc=example,dc=com";)
Characters that are syntactically significant for a DN, such as commas,
must be escaped with a single backslash (\).
roledn KeywordThe roledn keyword specifies that access to a targeted
entry is granted or denied if the user binds using a DN that belongs to a
specific role. The roledn keyword requires one or more
valid distinguished names, in this format:
roledn = "ldap:///dn [|| ldap:///dn]... [|| ldap:///dn]"
The bind rule is evaluated to be true if the bind DN belongs to the
specified role.
Characters that are syntactically significant for a DN, such as commas,
must be escaped with a single backslash (\).
The roledn keyword has the same syntax and is used
in the same way as the groupdn keyword.
userattr KeywordThe userattr keyword specifies which attribute values
in the entry that was used to bind must match those in the targeted entry.
The userattr keyword can be used for the following
attributes:
LDAP filter, in an LDAP URL
Any attribute type
An attribute generated by a Class of Service (CoS) definition cannot
be used with the userattr keyword. ACIs that contain bind
rules that depend on attribute values generated by CoS will not work.
The userattr keyword uses this syntax:
userattr = "attrName#bindType"
Alternatively, if you are using an attribute type that requires a value
other than a user DN, group DN, role DN, or an LDAP filter, the userattr keyword uses this syntax:
userattr = "attrName#attrValue"
The userattr keyword can have one of the following
The name of the attribute used for value matching
One of the following types of bind: USERDN,GROUPDN,ROLEDN,LDAPURL
Any string that represents an attribute value
Examples of userattr Keyword With
Various Bind TypesExample 2&7
Using the userattr Keyword With
the USERDN Bind TypeThe following is an example of the userattr keyword
associated with a bind based on the user DN:
userattr = "manager#USERDN"
The bind rule is evaluated to be true if the bind DN matches the value
of the manager attribute in the targeted entry. You can
use this to allow a user&s manager to modify employees& attributes.
This mechanism only works if the manager attribute in the
targeted entry is expressed as a full DN.
The following example grants a manager full access to his or her employees&
aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0;acl "manager-write";
allow (all) userattr = "manager#USERDN";)
Example 2&8
Using the userattr Keyword With
the GROUPDN Bind TypeThe following is an example of the userattr keyword
associated with a bind based on a group DN:
userattr = "owner#GROUPDN"
The bind rule is evaluated to be true if the bind DN is a member of
the group specified in the owner attribute of the targeted
entry. For example, you can use this mechanism to allow a group to manage
employees& status information. You can use an attribute other than owner, as long as the attribute you use contains the DN of a group
The group you point to can be a dynamic group, and the DN of the group
can be under any suffix in the directory. However, the evaluation of this
type of ACI by the server is very resource intensive.
If you are using static groups that are under the same suffix as the
targeted entry, you can use the following expression:
userattr = "ldap:///dc=example,dc=com?owner#GROUPDN"
In this example, the group entry is under the dc=example,dc=com suffix.
The server can process this type of syntax more quickly than the previous
Example 2&9
Using the userattr Keyword With
the ROLEDN Bind TypeThe following is an example of the userattr keyword
associated with a bind based on a role DN:
userattr = "exampleEmployeeReportsTo#ROLEDN"
The bind rule is evaluated to be true if the bind DN belongs to the
role specified in the exampleEmployeeReportsTo attribute
of the targeted entry. For example, if you create a nested role for all managers
in your company, you can use this mechanism to grant managers at all levels
access to information about employees that are at a lower grade than themselves.
The DN of the role can be under any suffix in the directory. If, in
addition, you are using filtered roles, the evaluation of this type of ACI
uses a lot of resources on the server.
Example 2&10
Using the userattr Keyword With
the LDAPURL Bind TypeThe following is an example of the userattr keyword
associated with a bind based on an LDAP filter:
userattr = "myfilter#LDAPURL"
The bind rule is evaluated to be true if the bind DN matches the filter
specified in the myfilter attribute of the targeted
entry. The myfilter attribute can be replaced by
any attribute that contains an LDAP filter.
Example 2&11
Using the userattr Keyword With
Any Attribute ValueThe following is an example of the userattr keyword
associated with a bind based on any attribute value:
userattr = "favoriteDrink#Milk"
The bind rule is evaluated to be true if the bind DN and the target
DN include the favoriteDrink attribute with a value of Milk.
Use of the userattr Keyword With
the parent Keyword for InheritanceThe userattr keyword can be used with the parent keyword to specify the number of levels below the target that should
inherit the ACI. The userattr keyword and parent keyword use this syntax:
userattr = "parent[inheritance_level].attribute#bindType"
The userattr keyword and parent keyword can have the following values:
inheritance_level
A comma separated list that indicates how many levels below
the target should inherit the ACI. These levels below the targeted entry can
be specified: [0,1,2,3,4]. Zero (0) indicates the targeted
The attribute targeted by the userattr or groupattr keyword.
The type of bind can be USERDN or GROUPDN. Inheritance cannot be used with LDAPURL and ROLEDN binds.
The following example shows how the userattr keyword
is used with the parent keyword for inheritance:
userattr = "parent[0,1].manager#USERDN"
This bind rule is evaluated to be true if the bindDN matches
the manager attribute of the targeted entry. The permissions granted when
the bind rule is evaluated to be true apply to the target entry and to
all entries immediately below it.
Use of the userattr Keyword to
Grant Add PermissionsIf you use the userattr keyword in conjunction with all or add permissions, you might find that the behavior of the server
is not what you expect. Typically, when a new entry is created in the directory, Directory Server
evaluates access rights on the entry being created, and not on the parent
entry. However, for ACIs that use the userattr keyword,
this behavior could create a security hole, and the server&s normal
behavior is modified to avoid it.
Consider the following example:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "manager-write"; allow (all)
userattr = "manager#USERDN";)
This ACI grants managers all rights on the entries of employees that
report to them. However, because access rights are evaluated on the entry
being created, this type of ACI would also allow any employee to create an
entry in which the manager attribute is set to their own DN. For example,
disgruntled employee Joe (cn=Joe,ou=eng,dc=example,dc=com),
might want to create an entry in the Human Resources branch of the tree, to
use (or misuse) the privileges granted to Human Resources employees.
He could do this by creating the following entry:
dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com
objectclass: top
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=example,dc=com
To avoid this type of security threat, the ACI evaluation process does
not grant add permission at level 0, that is, to the entry itself. You can,
however, use the parent keyword to grant add rights below
existing entries. You must specify the number of levels below the parent for
add rights. For example, the following ACI allows child entries to be added
to any entry in the dc=example,dc=com that has a manager attribute that matches the bind DN:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "parent-access"; allow (add)
userattr = "parent[0,1].manager#USERDN";)
This ACI ensures that add permission is granted only to users whose
bind DN matches the manager attribute of the parent entry.
ip KeywordThe ip keyword is used to specify that a bind operation
must originate from a specific IP address. The ip keyword
uses this syntax:
ip = "IPaddressList" or ip != "IPaddressList"
The IPaddressList value is a list of one
or more comma-separated elements from the following elements:
A specific IPv4 address: 123.45.6.7
An IPv4 address with wild cards to specify a subnetwork: 12.3.45.*
An IPv4 address or subnetwork with subnetwork mask: 123.45.6.*+255.255.255.192
An IPv6 address in any of its legal forms and contained in
square brackets [ and ], as defined
The following addresses are equivalent:
ldap://[12AB::CD30:00:0000]
ldap://[12AB::CD30:0:0:0:0]
ldap://[12AB:0:0:CD30::]
An IPv6 address with a subnet prefix length: ldap://[12AB::CD30:0:0:0:0]/60
The bind rule is evaluated to be true if the client accessing the directory
is located at the named IP address.
The ip keyword can be used to force all directory
updates to occur from a given machine or network domain. However, the IP address
from which a user authenticates can be spoofed, and can therefore not be trusted.
Do not base ACIs on this information alone.
The wild card * can be used to specify a set of IP
addresses.
dns KeywordNote & The dns keyword requires that the naming service
used on your machine is DNS. If the name service is not DNS, you should use
the ip keyword instead.
The dns keyword is used to specify that a bind operation
must originate from a specific domain or host machine. The dns keyword
uses this syntax:
dns = "DNS_Hostname" or dns != "DNS_Hostname"
The dns keyword requires a fully qualified DNS domain
name. Granting access to a host without specifying the domain creates a potential
security threat. For example, the following expression is allowed but not
recommended:
dns = "legend.eng";
You should use a fully qualified name such as:
dns = "legend.";
The dns keyword allows wild cards.
dns = "*.";
The bind rule is evaluated to be true if the client accessing the directory
is located in the named domain. This can be useful for allowing access only
from a specific domain. Note that wild cards do not work if your system uses
a naming service other than DNS.
timeofday KeywordThe timeofday keyword is used to specify that access
can occur at a certain time of day. The time and date on the server are used
for the evaluation of the timeofday and dayofweek bind
rules, and not the time on the client. The timeofday keyword
uses this syntax:
timeofday operator "time"
The timeofday keyword can have the following values:
Equal to (=)
Not equal to (!=)
Greater than or equal to (&=)
Less than (&)
Less than or equal to (&=)
Four digits representing hours and minutes in the 24-hour
clock (0 to 2359)
timeofday = "1200"; is true if the client
is accessing the directory during the minute that the system clock shows noon.
timeofday != "0100"; is true for access
at any other time than 1 a.m.
timeofday & "0800"; is true for access
from 8:01 a.m. through 11:59 p.m.
timeofday &= "0800"; is true for access
from 8:00 a.m. through 11:59 p.m.
timeofday & "1800"; is true for access
from 12:00 midnight through 5:59 p.m.
dayofweek KeywordThe dayofweek keyword is used to specify that access
can occur on a certain day or on certain days of the week.
The time and date
on the server are used for the evaluation of the timeofday and dayofweek bind rules, and not the time on the client. The dayofweek keyword uses this syntax:
dayofweek = "day1, day2 ..."
The bind rule is true if the directory is being accessed on one of the
days listed.
The dayofweek keyword can have one or more of the
following values: sun, mon, tue, wed, thu, fri, sat.
authmethod KeywordThe authmethod keyword is used to specify that
a client must bind to the directory by using a specific authentication method.
The authmethod keyword uses this syntax:
authmethod = "authentication_method"
The authmethod keyword can have the following values:
Authentication is not checked during bind rule evaluation.
This is the default.
The bind rule is evaluated to be true if the client is accessing
the directory using a username and password.
The client must bind to the directory over a Secure Sockets
Layer (SSL) or Transport Layer Security (TLS) connection.
The bind rule is evaluated to be true if the client authenticates to
the directory by using a certificate over LDAPS. It will not be true if the
client authenticates by using simple authentication (bind DN and password)
over LDAPS.
SASL sasl_mechanism
The bind rule is evaluated to be true if the client authenticates
to the directory by using one of the following SASL mechanisms: DIGEST-MD5, GSSAPI, or EXTERNAL.
Boolean Bind Rules
Bind rules can be complex expressions that use the Boolean expressions AND, OR, and NOT to set precise
access rules. Boolean bind rules use this syntax:
(bindRuleA and (bindRuleB or (bindRuleC and bindRuleD));)
Parentheses defines the order in which rules are evaluated, and a trailing
semicolon must appear after the final rule.
Example 2&12
Boolean Bind RuleThe bind rule is true if both of the following conditions are met:
The bind DN client is accessed from within the < domain
The bind DN client is a member of either the administrators
group or the bind DN client a member of both the mail
administrators and calendar administrators groups
(dns = "*."
and (groupdn = "ldap:///cn=administrators, dc=example,dc=com"
or (groupdn = "ldap:///cn=mail administrators, dc=example,dc=com"
and groupdn = "ldap:///cn=calendar administrators, dc=example,dc=com"));)
Tuning and Access Control
Directory Server offers performance and scalability improvements
for Access Control Instructions. The improvements include better memory management.
The improvements also include support for macro ACIs. Improvements notwithstanding, Directory Server
uses significant system resources to evaluate complex ACIs. Extensive use
of complex ACIs can therefore negatively impact performance.
Macro ACIs help you limit the number of ACIs used. By limiting the number
of ACIs, you render access control easier to manage and reduce the load on
the system. Macros are placeholders that represent a DN, or a portion of a
DN, in an ACI. A macro can be used in an ACI target, in an ACI bind rule,
or in both. When Directory Server receives a request, it checks which ACI
macros match against the resource targeted for the resulting operation. If
a macro matches, Directory Server replaces it with the value of the actual
DN. Directory Server then evaluates the ACI normally.
Testing has demonstrated that a Directory Server instance can support
more than 50,000 ACIs. Nevertheless, keep the number of ACIs as small as possible.
Keeping the number of ACIs small limits negative impact on performance. Keeping
the number small also reduces the complexity of managing access controls.
For deployments involving complex ACI environments, consider using Directory Proxy Server
to provide some access control features.
How Directory Server Provides Authentication
Authentication is the process of confirming an identity. In network
interactions, authentication involves the confident identification of one
party by another party. Network interactions typically take place between
a client, such as browser software running on a personal computer, and a server,
such as the software and hardware used to host a Web site. Client
authentication refers to the confident identification of a client
server authentication refers to the confident
identification of a server by a client.
For information about authentication, see the following sections:
Anonymous Access
Anonymous access lets a user bind to the directory without providing
authentication credentials. With access control, you can give anonymous users
whatever privileges you choose. Often, anonymous users are allowed to read
non-sensitive data from the directory, such as names, telephone numbers, and
email addresses.
You can also restrict the privileges of anonymous access, or limit anonymous
access to a subset of attributes that contain address book information. Anonymous
access should not be allowed for sensitive data.
In cases where anonymous users have access to something, you may want
to prevent users who fail to bind properly nevertheless being granted access
as anonymous. See the require-bind-pwd-enabled in
for more information.
Password-Based Authentication
Simple password authentication offers an easy way of authenticating
users. In password authentication, the user must supply a password for each
server, and the administrator must keep track of the name and password for
each user, typically on separate servers.
Steps in Password-Based Authentication
shows the steps involved
in authenticating a client by using a name and password. The figure assumes
the following points.
The user has already decided to trust the system, either without
authentication, or on the basis of server authentication via SSL.
The user has requested a resource controlled by the server.
The server requires client authentication before permitting
access to the requested resource.
Figure 2&1
Password-Based Authentication
In , password authentication
is performed in the following steps.
The user enters a name and password.
For the LDAP
bind to Directory Server, the client application must bind with a Distinguished
Name. Therefore the client application may use the name entered by the user
to retrieve the DN.
The client sends the DN and password across the network.
The server determines whether the password sent from the client
matches the password stored for the entry with the DN sent from the client.
If so, the server accepts the credentials as evidence authenticating
the user identity.
The server determines whether the identified user is permitted
to access the requested resource.
If so, the server allows the
client to access the resource.
Password Policy
A password policy is a set of rules that govern how passwords are administered
in a system. Directory Server supports multiple password policies. The
password policy can be configured to suit the security requirements of your
deployment.
Instances of Directory Server are created with a default password
Types of Password PolicyDirectory Server provides the following password policies.
Default password policy
The default password policy is defined in the configuration
entry cn=PasswordPolicy,cn=config. The default password
policy applies to all accounts in the directory except for the directory manager.
The parameters of the default policy can be modified to override the
default settings. However, because the default password policy is part of
the configuration for the instance, modifications to the default password
policy cannot be replicated.
Specialized password policy
A password policy can be configured for an individual user
or for set of users by using the CoS and roles features. However, specialized
password policies can not be applied to static groups.
A specialized password policy is defined in a subentry in the directory
tree. Like the default password policy, the specialized password policy uses
the pwdPolicy object class. For example, the following
entry defines a specialized password policy:
dn: cn=TempPolicy,dc=example,dc=com
objectClass: top
objectClass: pwdPolicy
objectClass: LDAPsubentry
cn: TempPolicy
pwdCheckQuality: 2
pwdLockout: on
pwdLockoutDuration: 300
pwdMaxFailure: 3
pwdMustChange: on
A specialized password policy can be assigned to a single user account
or can be assigned to a set of users by using roles. For example, in the following
entry the password policy defined in cn=TempPolicy,dc=example,dc=com is
assigned to the pwdPolicySubentry attribute of the user
dn: uid=dmiller,ou=people,dc=example,dc=com
objectClasaccess controls: person
objectClass: top
sn: miller
userPassword: secret12
pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com
When referenced by a user entry, a specialized password policy overrides
the default password policy.
Because specialized password policies are defined the}