Chapter 7 Identifying Security Requirements

How you secure data in Directory Server Enterprise Edition has an impact on all other areas of
design. This chapter describes how to analyze your security needs and explains
how to design your directory service to meet those needs.

Tampering. Information
in transit is changed or replaced and then sent on to the recipient. For example,
someone could alter an order for goods or change a person’s resume.

This threat includes unauthorized modification of data or configuration
information. If your directory cannot detect tampering, an attacker might
alter a client’s request to the server. The attacker might also cancel
the request or change the server’s response to the client. The Secure
Socket Layer (SSL) protocol and similar technologies can solve this problem
by signing information at either end of the connection.

Impersonation. Information
passes to a person who poses as the intended recipient.

Impersonation can take two forms, spoofing and misrepresentation.

Spoofing. A person or computer
impersonates someone else. For example, a person can pretend to have the
mail address jdoe@example.com, or a computer can identify
itself as a site called www.example.com when it is not.

Misrepresentation. A person
or organization misrepresents itself. For example, suppose the site www.example.com pretends to be a furniture store when it is really just a site
that takes credit-card payments but never sends any goods.

Denial of service. An attacker
uses the system resources to prevent these resources from being used by legitimate
users.

In a denial of service attack, the attacker’s goal
is to prevent the directory from providing service to its clients. Directory Server Enterprise Edition provides
a way of preventing denial of service attacks by setting limits on the resources
that are allocated to a particular bind DN.

Overview of Security Methods

A security policy must be able to prevent sensitive information
from being modified or retrieved by unauthorized users, but easy enough to
administer.

Authentication. Provides
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. As
part of the authentication process, password policies define
the criteria that a password must satisfy to be considered valid, for example,
age, length, and syntax. Account inactivation disables
a user account, group of accounts, or an entire domain so that all authentication
attempts are automatically rejected.

Encryption. Protects the
privacy of information. When data is encrypted, the data is scrambled in a
way that only the recipient can decode. The Secure Sockets Layer (SSL)
maintains data integrity by encrypting information in transit. If encryption
and message digests are applied to the information being sent, the recipient
can determine that the information was not tampered with during transit. Attribute encryption maintains data integrity by encrypting stored
information.

Access control. Tailors
the access rights that are granted to different directory users, and provides
a means of specifying required credentials or bind attributes.

Auditing. Enables you to
determine if the security of your directory has been compromised. For example,
you can audit the log files maintained by your directory.

These security tools can be used in combination in your security design.
You can also use other features of the directory, such as replication and
data distribution, to support your security design.

Anonymous Access

Anonymous access is the simplest form of directory access. Anonymous
access makes data available to any directory user, regardless of whether the
user has authenticated.

Anonymous access does not allow you to track who is performing searches
or what kind searches are being performed, only that someone is performing
searches. When you allow anonymous access, anyone who connects to your directory
can access the data. If you allow anonymous access to data, and attempt to
block a user or group from that data, the user can access the data by binding
to the directory anonymously.

You can restrict the privileges of anonymous access. Usually, directory
administrators allow anonymous access only for read, search, and compare
privileges. You can also limit access to a subset of attributes that contain
general information such as names, telephone numbers, and email addresses.
Do not allow anonymous access to sensitive data, such as government identification
numbers, home telephone numbers and addresses, and salary information.

Anonymous access to the root DSE (base DN "") is
required. Access to the root DSE enables applications to discover the capabilities
of the server, the supported security mechanisms, and the supported suffixes.

Simple Password Authentication

If anonymous access is not set up, a client must authenticate
to Directory Server to access the directory contents. With simple password
authentication, a client authenticates to the server by providing a simple,
reusable password.

The client authenticates to Directory Server through a bind operation
in which the client provides a distinguished name and credentials. The server
locates the entry that corresponds to the client DN, then checks whether the
client's password matches the value stored with the entry. If the password
matches, the server authenticates the client. If the password does not match,
the authentication operation fails and the client receives an error message.

Note –

The drawback of simple password authentication is that the password
is transmitted in clear text, which can compromise security. If a rogue user
is listening, that user can impersonate an authorized user.

Simple password authentication offers an easy way of authenticating
users. However, you need to restrict the use of simple password authentication
to your organization’s intranet. This kind of authentication does not
offer the level of security that is required for transmissions between business
partners over an extranet or for transmissions with customers on the Internet.

Simple Password Authentication Over a Secure Connection

A secure connection uses encryption to make data unreadable to third
parties while the data is sent over the network between Directory Server and
its clients. Clients can establish secure connections in either of the following
ways:

Binding to the secure port by using the Secure Socket Layer
(SSL)

Binding to an insecure port with anonymous access, then sending
the Start TLS control to begin using Transport Layer Security (TLS)

In either case, the server must have a security certificate, and the
client must be configured to trust this certificate. The server sends its
certificate to the client to perform server authentication,
using public-key cryptography. This results in the client knowing that it
is connected to the intended server and that the server is not being tampered
with.

Then, for privacy, the client and server encrypt all data transmitted
through the connection. The client sends the bind DN and password on the encrypted
connection to authenticate the user. All further operations are performed
with the identity of the user. The operations might also be performed with
a proxy identity if the bind DN has proxy rights to other user identities.
In all cases, the results of operations are encrypted when these results are
returned to the client.

Certificate-Based Client Authentication

When establishing encrypted connections over SSL or TLS, you can
also configure the server to require client authentication.
The client must send its credentials to the server to confirm the identity
of the user. The user's certificate, not the DN, is used to determine the
bind DN. Client authentication protects against user impersonation and is
the most secure type of connection.

Certificate-based client authentication operates at the SSL, TLS layer
only. To use a certificate-based authentication ID with LDAP, you must use
SASL EXTERNAL authentication after establishing the SSL connection.

You can configure certificate-based client authentication by using the dsconf get-server-prop command. See dsconf(1M) for more information.

SASL-Based Client Authentication

Client authentication during an SSL or TLS connection can also
use the Simple Authentication and Security Layer (SASL), a generic security
interface, to establish the identity of the client. Directory Server Enterprise Edition supports the
following mechanisms through SASL:

DIGEST-MD5. This mechanism
authenticates clients by comparing a hashed value sent by the client with
a hash of the user's password. However, because the mechanism must read user
passwords, all users wanting to be authenticated through DIGEST-MD5 must have {CLEAR} passwords in the directory.

GSSAPI. The General Security
Services API (GSSAPI) is available only on the Solaris Operating System.
It allows Directory Server to interact with the Kerberos V5 security system
to identify a user. The client application must present its credentials to
the Kerberos system, which in turn validates the user's identity to Directory Server.

EXTERNAL. This mechanism
authenticates a user in LDAP based on the credentials specified by an external
security layer, such as SSL or TLS.

Preventing Authentication by Using Global Account
Lockout

In this version of Directory Server, authentication failures
with a password are monitored and replicated. This enables rapid, global account
lockout after a specified number of authentication attempts with an invalid
password. Global account lockout is supported in any of the following cases:

Client applications bind to a single server in the topology
only

The topology does not include any read-only consumers

Directory Proxy Server is used to control all bind traffic

Imagine a situation where all bind attempts are not directed to the
same server, and the client application performs bind attempts on multiple
servers faster than lockout data can be replicated. In the worst-case scenario,
the client would be allowed the specified number of attempts on each server
where the client attempted to bind. This situation would be unlikely if the
client application were driven by input from a human user. However, an automated
client built to attack a topology could exploit this deployment choice.

To retain a strictly local lockout policy in a replicated topology,
you must maintain compatibility with the 5.2 password policy. In this situation,
the policy in effect must not be the default password policy. Local lockout
can also be achieved by restricting binds to read-only consumers.

External Authentication Mappings and Services

Directory Server provides user account host mapping, which associates
a network user account with a Directory Server user account. This feature
simplifies the management of both user accounts. Host mapping is required
for users who are externally authenticated.

Proxy Authorization

Proxy authorization is a special form of access control. Proxy authorization
or proxy authentication is when an application is forced to use a specific
username/password combination to gain access to the server.

With proxy authorization, an administrator can request access to Directory Server by
assuming the identity of a regular user. The administrator binds to the directory
with his own credentials and is granted the rights of the regular user. This
assumed identity is called the proxy user. The DN of
that user is called the proxy DN.
The proxy user is evaluated as a regular user. Access is denied if the proxy
user entry is locked or inactivated or if the password has expired.

An advantage of the proxy mechanism is that you can enable an LDAP application
to use a single bind to service multiple users who are accessing Directory Server.
Instead of each user having to bind and authenticate, the client application
binds to Directory Server and uses proxy rights.

Password Policy Options

A default password policy is applied. The parameters of this
default policy can be changed.

An additional, specialized password policy can be applied
to a particular user.

An additional, specialized password policy can be applied
to a set of users by using the CoS and Roles functionality. Password policies
cannot be applied to static groups.

Password Policies in a Replicated Environment

Configuration information for the default password policy is not replicated.
Instead, it is part of the server instance configuration. If you modify the
default password policy, the same modifications must be made on each server
in the topology. If you need a password policy that is replicated,
you must define a specialized password policy under a part of the directory
tree that is replicated.

All password information that is stored in the user entry is replicated.
This information includes the current password, password history, password
expiration dates and so forth.

Consider the following impact of password policies in a replicated environment:

A user with an impending password expiration receives a warning
from every replica to which the user binds before changing his password.

When a user changes his password, the new password might take
a while to be updated on all replicas. A situation could arise where a user
changes his password and then immediately rebinds to one of the consumer replicas
with the new password. In this case, the bind could fail until the replica
receives the updated password. This situation can be alleviated using prioritized
replication to force password changes to be replicated first.

Determining Encryption Methods

Securing Connections With SSL

Security design involves
more than an authentication scheme for identifying users and an access control
scheme for protecting information. You must also protect the integrity of
information between servers and client applications while it is being sent
over the network.

To provide secure communications over the network, you can use both
the LDAP and DSML protocols over the Secure Sockets Layer (SSL). When SSL
is configured and activated, clients connect to a dedicated secure port where
all communications are encrypted after the SSL connection is established. Directory Server and
Directory Proxy Server also support the Start Transport Layer Security (Start
TLS) control. Start TLS allows the client to initiate an encrypted connection
over the standard LDAP port.

What Is Attribute Encryption?

Directory Server Enterprise Edition provides various features to protect data at the access level,
including password authentication, certificate-based authentication, SSL,
and proxy authorization. However, the data stored in database files, backup
files, and LDIF files must also be protected. The attribute encryption feature
prevents users from accessing sensitive data while the data is stored.

Attribute encryption enables certain attributes to be stored in encrypted
form. Attribute encryption is configured at the database level. Thus, after
an attribute is encrypted, the attribute is encrypted in every entry in the
database. Because attribute encryption occurs at the attribute level (not
the entry level), the only way to encrypt an entire entry is to encrypt all
of its attributes.

Attribute encryption also enables you to export data to another database
in an encrypted format. The purpose of attribute encryption is to protect
sensitive data only when the data is being stored or exported. Therefore,
the encryption is always reversible. Encrypted attributes are decrypted when
returned through search requests.

The following figure shows a user entry being added to the database,
where attribute encryption has been configured to encrypt the salary attribute.

Figure 7–1 Attribute Encryption Logic

Attribute Encryption Implementation

The attribute encryption feature supports a wide range of encryption
algorithms. Portability across different platforms is ensured. As an additional
security measure, attribute encryption uses the private key of the server’s
SSL certificate to generate its own key. This key is then used to perform
the encryption and decryption operations. To be able to encrypt attributes,
a server must be running over SSL. The SSL certificate and its private key
are stored securely in the database and protected by a password. This key
database password is required to authenticate to the server. The server assumes
that whoever has access to this key database password is authorized to export
decrypted data.

Note that attribute encryption only protects stored attributes. If you
are replicating these attributes, replication must be configured over SSL
to protect the attributes during transport.

If you use attribute encryption, you cannot use the binary copy feature
to initialize one server from another server.

Attribute Encryption and Performance

Sensitive data can be accessed directly through index files. Thus, you
must encrypt the index keys corresponding to the encrypted attributes, to
ensure that the attributes are fully protected. Indexing already has a performance
impact, without the added cost of encrypting index keys. Therefore, configure
attribute encryption before data is imported or added
to the database for the first time. This procedure ensures that encrypted
attributes are indexed as such from the outset.

Designing Access Control With ACIs

Access control enables you to specify that certain clients have access
to particular information, while other clients do not. You implement access
control using one or more access control lists (ACLs). ACLs consist of a series
of access control instructions (ACIs) that either allow or deny permissions
to specified entries and their attributes. Permissions include the ability
to read, write, search, proxy, add, delete, compare, import and export.

By using an ACL, you can set permissions for the following:

The entire directory

A particular subtree of the directory

Specific entries in the directory

A specific set of entry attributes

Any entry that matches a given LDAP search filter

In addition, you can set permissions for a specific user, for all users
that belong to a group, or for all users of the directory. You can also define
access for a network location, such as an IP address or a DNS name.

ACI Scope

Starting with 6.x, Directory Server includes two major changes to
ACI scope.

Ability to specify the scope of an
ACI. In Directory Server 5.2, you could not specify the scope
of an ACI. ACIs automatically applied to the entry that contained the ACI
and all of its subtree. Therefore, it was necessary to use deny ACIs
in several cases. Deny ACIs can be difficult to manage, particularly when
a deny ACI and an allow ACI apply to a single entry.

Root ACIs now apply to the root entry
and its entire subtree. In Directory Server 5.2, ACIs located
in the root DSE applied to the root entry only and not its children. ACIs
placed in any other entry applied to the entry that contained the ACI and
all of its subtree. In Directory Server Enterprise Edition ACIs placed in the root entry are treated
like ACIs placed anywhere else.

The new root ACIs have an obvious
security advantage. Administrators no longer have to bind as the Directory
Manager to perform certain operations. Administrators can now be forced to
bind by using strong authentication such as SSL. When configuring ACIs that
are intended to apply only to the root entry, the scope
of the ACI must now specifically be set to base.

Obtaining Effective Rights Information

The access
control model provided by Directory Server can grant access to users through
many different mechanisms. However, this flexibility can make your security
policy fairly complex. Several parameters can define the security context
of a user, including IP address, machine name, time of day, and authentication
method.

Tips on Using ACIs

The following tips can simplify your directory security model and improve
directory performance:

Minimize the number of ACIs in your directory, and use macro
ACIs where possible.

Although Directory Server can evaluate
over 50,000 ACIs, managing a large number of ACI statements can be difficult.
Excessive ACIs can also have a negative impact on memory consumption.

Balance allow and deny permissions.

The default
rule is to deny access to any user who has not been specifically granted access.
However, you can reduce the number of ACIs by using one ACI that allows access
close to the root of the tree and using a small number of deny ACIs close
to the leaf entries. This approach can prevent excessive allow ACIs close
to the leaf entries.

Identify the smallest set of attributes on any given ACI.

If you allow or deny access to a subset of attributes on an object,
determine whether the smallest list is the set of attributes that are allowed
or the set of attributes that are denied. Then express your ACI so that you
are managing the smallest list.

For example, the people object class contains dozens of attributes.
To allow a user to update just a few attributes, write your ACI so that it
allows write access for just those few attributes. To allow a user to update
all but one or two attributes, create the ACI so that it denies write access
for those one or two attributes.

Use LDAP search filters cautiously.

Search filters
do not directly name the object for which you are managing access. Search
filters can therefore result in unexpected results especially as your directory
becomes more complex. If you use search filters in ACIs, run an ldapsearch operation with the same filter. This action will ensure that you
know what the results of the changes mean to your directory.

Do not duplicate ACIs in different parts of your directory
tree.

Look for overlapping ACIs. Imagine that you have an ACI
at your directory root point that allows a group write access to the commonName and givenName attributes. Imagine also that
you have another ACI that allows the same group write access to just the commonName attribute. In this scenario, consider reworking your
ACIs so that only one attribute grants write access for the group.

As your directory grows more complicated, accidental overlapping of
ACIs becomes increasingly common. If you avoid ACI overlap, security management
becomes easier and the total number of ACIs in your directory is reduced.

Limit
ACI placement to your directory root point and to major directory branch points.
If you organize ACIs into groups, the total list of ACIs is easier to manage
and the total number of ACIs can be kept to a minimum.

Avoid using double negatives, such as deny write if the bind
DN is not equal to cn=Joe.

Although this syntax
is acceptable to the server, the syntax can be confusing for an administrator.

Designing Access Control With Connection
Rules

Connection rules enable you to prevent selected clients from establishing
connections to Directory Server. The purpose of connection rules is to
prevent a denial-of-service attack caused by malicious or poorly designed
clients that connect to Directory Server and flood the server with requests.

Designing Access Control With Directory Proxy Server

Directory Proxy Server connection
handlers provide a method of access control that enables you to classify
incoming client connections. In this way, you can restrict the operations
that can be performed based on how the connection has been classified.

You can use this functionality, for example, to restrict access to clients
that connect from a specified IP address only. The following figure shows
how you can use Directory Proxy Server connection handlers to deny write operations
from specific IP addresses.

Figure 7–2 Directory Proxy Server Connection Handler Logic

How Connection Handlers Work

A connection handler consists of a list of criteria and a list of policies.
Directory Proxy Server determines a connection's class membership by matching
the origination attributes of the connection with the criteria of the class.
When the connection has been matched to a class, Directory Proxy Server applies
the policies that are contained in that class to the connection.

Connection handler criteria can include the following:

Client physical address

Domain name or host name

Client DN pattern

Authentication method

SSL

The following policies can be associated with a connection handler:

Administrative limits policy. Enables
you to set certain limits on, for example, the number of open connections
from clients of a specific class.

Content adaptation policy. Enables
you to restrict the kind of operations a connection can perform, for example,
attribute renaming.

Data distribution policy. Enables
you to use a specific distribution scheme for a connection.

Using CoS Securely

Access control for reading applies to both the real attributes and the
virtual attributes of an entry. A virtual attribute generated by the Class
of Service (CoS) mechanism is read like a normal attribute. Virtual attributes
should therefore be given read protection in the same way. However, to make
the CoS value secure, you must protect all of the sources of information the
CoS value uses: the definition entries, the template entries, and the target
entries. The same is true for update operations. Write access to each source
of information must be controlled to protect the value that is generated
from these sources. For more information, see Chapter 12, Directory Server Class of Service, in Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition.

Using Firewalls

Firewall technology
is typically used to filter or block network traffic to and from an internal
network. If LDAP requests are coming from outside a perimeter firewall, you
need to specify what ports and protocols are allowed to pass through the firewall.

The ports and protocols that you specify depend on your directory architecture.
As a general rule, the firewall must be configured to allow TCP and UDP connections
on ports 389 and 636.

Host-based firewalls can be installed on the same server that is running Directory Server.
The rules for host-based firewalls are similar to the rules for perimeter
defense firewalls.

Running as Non-Root

You can create and run server instances as a non-root user. By running
server instances as a non-root user, you limit any potential
damage that an exploit could cause. Furthermore, servers running as non-root users are subject to access control mechanisms on the operating
system.

Other Security Resources

For more information about designing a secure directory, see the following
resources: