Directory Server Security

Directory Server Security

Several security considerations must be taken into account when configuring the

iPlanet™ Directory Server to support Solaris™ Operating Environment (Solaris OE)

native Lightweight Directory Access Protocol (LDAP) clients. To protect naming

service data from intruders, users must be authenticated before gaining access, and

once authenticated must be authorized to perform operations on the naming service

data. Since the LDAP security model for user authentication and authorization is

different than the NIS model that administrators are familiar with, this article

provides an overview of what the LDAP security model consists of and what

security changes need to be made to accommodate the Solaris OE naming service

requirements.

LDAP Security Model

There are two aspects of directory security that affect how native LDAP clients

interact with the directory server: authentication and authorization. Authentication

is the process of identity validation, that is, proving a user’s identity. Authorization

is the granting of access rights to authenticated users. In the NIS naming service,

clients bind to an NIS server without the need for authentication and all clients are

granted the same permissions. All NIS maps are readable by all clients and the

password shadow map is writable by users through the rpc.yppasswdd process

which runs on NIS servers.

Compared to NIS, the iPlanet Directory Server provides a much more flexible

security model. Clients can either be authenticated by one of several methods or

connect to the directory server anonymously. Permissions, or access rights, can be set

for the entire directory content, directory entries, or even data items within an entry.

LDAP Authentication

Clients authenticate to an LDAP server by attempting a bind operation. A connection

between the client and the server is established if the bind is successful. As part of

the bind request, the client chooses which authentication method it wants to use and

supplies the credentials required by that method. If a method is not specified,

credentials are not sent and the client is bound as an anonymous user. The available

methods in iPlanet Directory Server 4.12 are simple name/passwords and digital

certificates using secure socket layer (SSL).

The simple authentication method is the easiest to implement and the only method

currently supported when the native LDAP client is serviced by the iPlanet

Directory Server is used as the server. This method requires a distinguished name

(DN) -and a password associated with the entry identified by the DN. The password

is stored on the directory server in one of three formats: 1) clear text, 2) SHA-1, or 3)

UNIX® crypt. When the server receives the password, either in clear text or in one of

the hashed formats, a comparison is made. If a match is successful, then the

authentication succeeds.

Unlike the Solaris OE, LDAP does not require a specific user account format. Any

directory entry which contains the userPassword attribute can be specified as the

bind DN. One exception to this is the root DN which has the common name (cn) of

Directory Manager. This entry resides outside the directory information tree

(DIT) and has privileges similar to what root has in the Solaris OE. Users who bind

to the directory with this DN have unlimited access rights and can establish rights

for other users.

LDAP Authorization

Authorization to directory objects is based on an access control list (ACL) which is

maintained in the DIT. The ACL is composed of a series of access control

instructions (ACIs). The ACI is an attribute that can be assigned to any directory

object. Each ACI defines a set of access rules and multiple ACIs can be assigned to

the same object. To define access rights for the entire directory, an ACI is set for the

directory suffix of the DIT.

Since there can be, and usually are, multiple ACIs per DIT, rules are established to

determine which ACIs take precedence. ACIs set on objects which appear lower in

the DIT, take precedence over ACIs on objects above them. For example, you may

LDAP Security Model 3

grant read permission for everyone at the top of the DIT, but restrict read access for

subtrees that contain sensitive data. Access can be specified as allow or deny. If there

is a conflict between ACIs, deny always takes precedence.

Note – The ACI is not defined in the LDAP standard and is only used in the iPlanet

Directory Server implementation. Other LDAP servers have their own mechanism

for assigning access rights.

The ACI Structure

Since ACIs are so fundamental to securing directory data, it is helpful to understand

them in detail. During the configuration of the iPlanet Directory Server to support

native LDAP clients, several ACIs are created or modified. While access rights on

certain objects must be set correctly for native LDAP to work, other access rights are

optional and are only recommended. You should have sufficient knowledge of how

ACIs work to customize access rights in accordance with your company’s security

policy.

ACI Format

ACIs are in this general format:

<target> <permission> <bind rules>

n <target>—Specifies the entry to which the ACI is targeted. This is usually a

subtree and/or an attribute that is targeted. In addition, an LDAP search filter can

be specified.

n <permissions>—Defines what the access rights are. These include:

n Read

n Write

n Search

n Compare

n Selfwrite

n Add

n Delete

n <bind rules>—Indicates which bind situation the ACI applies to.

The target is usually expressed as the path to the directory entry it applies to

followed by the attribute(s) it applies to. Wildcards can be used to specify several or

all attributes within an entry. Multiple attributes can be specified to target more than

one specific attribute. If you wish to exclude certain attributes, the not (!) operator

can be used.

Permissions are expressed by either allowing or denying access. Seven types of

access are defined. Use these to restrict whether the data is used in searches and

compares or whether values are modified or deleted. The purpose of one type listed

above, called Selfwrite, may not be obvious. If Selfwrite is set, then users can add/

delete themselves from groups.

The bind rules define which user(s) or bind DN, the ACI applies to along with what

type of access is acceptable. Users can be placed in groups with permissions set for

members of the groups. In addition to restricting or allowing access to user and

groups, you can specify other binding criteria. For example, you could only allow

connections from clients with particular IP addresses or restrict access to certain

times of the day.

Use bind rules to set permissions for all users who successfully bind to the directory.

They can also set permissions for users who do not supply a bind DN, which is also

called an anonymous bind. It is important to note that these are two different

situations although the keywords used, all and anyone, sound similar. If allowing

anonymous binding is desired, the anyone keyword is required.

How Native LDAP Clients Bind

Before the native LDAP client can access naming service data in the iPlanet

Directory Server, it must first perform a bind operation. Since this occurs during the

boot sequence, a user is not logged in at the time. Therefore, the client must have a

LDAP Security Model 5

bind DN and password stored locally to use the data. The client obtains this

information from client profiles that are stored on the directory server. The following

is a sample profile in LDAP Data Interchange Format (LDIF) format.

The sample profile LDIF is generated by the ldap_gen_profile command. Of

interest in the output is the DN:

cn=proxyagent,ou=people,dc=blueprints,dc=com

This is the DN the client will use to bind with. Associated with the bind DN is a

password stored in the SolarisBindPassword attribute. This is stored in a hashed

format and sent over the network to the iPlanet Directory Server along with the DN

for the entry cn=proxyagent. This entry could be named anything, but the name

proxyagent gives it some meaning. The entry is set up using the following LDIF:

dn: cn=default,ou=profile,dc=blueprints,dc=com

SolarisBindDN:

cn=proxyagent,ou=people,dc=blueprints,dc=com

SolarisBindPassword: {NS1}c53708877bc6

SolarisLDAPServers: 129.148.181.130

SolarisSearchBaseDN: dc=blueprints,dc=com

SolarisAuthMethod: NS_LDAP_AUTH_SIMPLE

SolarisTransportSecurity: NS_LDAP_SEC_NONE

SolarisSearchReferral: NS_LDAP_FOLLOWREF

SolarisSearchScope: NS_LDAP_SCOPE_ONELEVEL

SolarisSearchTimeLimit: 30

SolarisCacheTTL: 43200

cn: default

ObjectClass: top

ObjectClass: SolarisNamingProfile

dn: cn=proxyagent,ou=people,dc=blueprints,dc=com

cn: proxyagent

userpassword: secret

objectclass: top

objectclass: person

In the previous LDIF example, the objectclass person is used to create the entry, but

any objectclass which contains the userpassword attribute will work. The profile

information for binding is stored in the /var/ldap/ldap_client_cred file as

shown below:

The Proxy Agent ACI

Since the native LDAP client is binding as cn=proxyagent, this DN needs to be

able to access user passwords so that Solaris OE users can be authenticated. To

enable this, an ACI must be created similar to the following LDIF.

This ACI will be added to the top entry (suffix) of the directory server. It is

important to note that compare, read, and search permissions must be granted.

Self Entry Modification

If the iPlanet Directory Server is installed using the Typical option, an ACI is

automatically created that grants write permission to the entry which the user binds

to the directory with. Leaving this ACI unchanged creates a security hole since the

blueprints# more ldap_client_cred

#

# Do not edit this file manually; your changes will be lost.Please

use ldapclient (1M) instead.

#

NS_LDAP_BINDDN= cn=proxyagent,ou=people,dc=blueprints,dc=com

NS_LDAP_BINDPASSWD= {NS1}c53708877bc6

dn: dc=blueprints,dc=com

changetype: modify

add: aci

aci: (target="ldap:///dc= blueprints,dc=com")

(targetattr="userPassword")

(version 3.0; acl "password read"; allow (compare,read,search)

userdn = "ldap:///

cn=proxyagent,ou=people,dc=blueprints,dc=com"; )

LDAP Security Model 7

user would be able to change the uidNumber attribute in the entry to 0. This

effectively grants root permissions to that user. To prevent this, the default ACI is

changed as reflected in the following LDIF.

The userPassword attribute is excluded in the previous LDIF example, because

users must still be able to change their passwords.

VLV Control Access

Another modification needed to the default ACI settings is to allow anonymous

access to the Virtual List View (VLV) control object. As discussed in the Directory

Server Indexing article , VLVs are used to create browsing indexes that are frequently

used by the native LDAP client when accessing data. By default, an ACI is set to

allow all users who successfully bind to the directory permission to access the VLV

control object. However, during client initialization, an anonymous bind is required

since a bind DN has not been established.

To allow anonymous binding, the userdn field needs to be changed from all to

anyone as shown below.

dn: dc=blueprints,dc=com

changetype: modify

replace: aci

aci: (targetattr != "cn || uid || uidNumber || gidNumber ||

gidNumber || homeDirectory || shadowLastChange || shadowMin ||

shadowWarning || shadowInactive || shadowExpire || shadowFlag ||

memberUid") (version 3.0; acl "Allow self entry modification";

allow (write) userdn = "ldap:///self"; )

dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config

changetype: modify

replace: aci

aci: (targetattr != "aci")(version 3.0; acl "VLV Request

Control"; allow( read ,

search, compare ) userdn = "ldap:///anyone";)

Authenticating Solaris OE Users

After the native LDAP client binds to the directory server, account information

stored there is used to authenticate users attempting to log in. There are two options

for authentication: 1) Traditional UNIX system-based and 2) LDAP-based. Which

authentication method is used depends on the client’s Pluggable Authentication

Module (PAM) configuration. The PAM UNIX (pam_unix) module has been

enhanced so that passwords stored in UNIX crypt format are retrieved from an

LDAP server instead of an NIS or NIS+ server. A new PAM module, PAM LDAP

(pam_ldap), is used to perform the authentication on the LDAP server.

While the PAM LDAP module is capable of performing authentication using

sophisticated methods such as Challenge Response Authentication Mechanism,

Message digest 5 (CRAM-MD5), the iPlanet Directory Server version 4.12 does not

support this method. Simple username/password pairs are the only method

currently supported through thePAM UNIX module. However, the use of this

method is discouraged since passwords are transmitted in clear text over the

network. Instead, use the enhanced PAM UNIX module since only the crypt format

is sent over the network.

Conclusion

The LDAP security model is measurably different than any previous naming service

supported by the Solaris OE. The iPlanet Directory Server provides a flexible

mechanism for controlling access to directory data, but this mechanism can be quite

complex and requires becoming well-acquainted with it. When configuring the

iPlanet Directory Server to support native LDAP clients, modifications to the default

ACIs is required. Understanding what these modifications do and why they are

necessary will help you diagnose directory access problems you may encounter in

the future.

e�@0t
8@� �� ack'>VLV Implementation

The VLV mechanism is implemented as a control in the iPlanet Directory Server.

Clients wishing to use this mechanism do so by accessing the VLV control. To do

this, the client must have permission to access it.

Note – By default, the VLV control does not grant anonymous access. Since the

Solaris OE LDAP client requires an anonymous bind during initialization, the ACI

for the VLV control must be modified.

Through the VLV control, the client has access to two object classes: vlvSearch and

vlvIndex. The vlvSearch object class specifies the result set of the search and the

vlvIndex object class specifies how the returned result set is sorted. This is done

through the vlvSort attribute.

Creating a VLV requires a pair of entries which include the vlvSearch and

vlvIndex object classes. The vlvSearch entry includes a search base and the

vlvFilter attribute which specifies the object class that contains the attribute(s)

you intend to sort. The vlvIndex object class includes the vlvSort attribute which

specifies one or more attributes to sort and in which order to sort them (a minus “-”

sign denotes reverse order).

The following is an example of the LDIF which creates the getpwent VLV index

that is used by the Solaris OE LDAP client when retrieving a list of user login IDs or

common names. The entries are always stored in the directory information tree

(DIT) under cn=config,cn=ldbm and must each be given a unique name. The

vlvBase is an attribute which reflects where your naming service data is stored

and varies depending on your configuration.

Virtual List Views 9

Note – The distinguished name (DN) given to the vlvIndex entry is confusing

since it also contains the component cn=getpwent. However, this is the naming

convention chosen and it must be adhered to.

TABLE 2 lists the other VLV indexes recommended along with the changes to the

search base, filter, and attributes to be sorted on.

After you create an LDIF file with the information provided in TABLE 2, you need to

import it into your directory server, it assumes the LDIF file name of vlv.ldif (see

example here).

dn: cn=getpwent,cn=config,cn=ldbm

objectclass: top

objectclass: vlvSearch

cn: getpwent

vlvBase: ou=people,dc=blueprints,dc=com

vlvScope: 1

vlvFilter: (objectclass=posixAccount)

aci: (target="ldap:///

cn=getpwent,cn=config,cn=ldbm")(targetattr="*)

(version 3.0; acl

"Config";allow(read,search,compare)userdn="ldap:///anyone";)

dn: cn=getpwent,cn=getpwent,cn=config,cn=ldbm

cn: getpwent

vlvSort: cn uid

objectclass: top

objectclass: vlvIndex

TABLE 2 Solaris OE LDAP Client VLV Indexes

VLV Name Search Base: Filter on: Sort on:

getpwent ou=people posixAccount cn.uid

getgrent ou=group posixGroup cn,gidNumber

gethostent ou=hosts ipHost cn,ipHostNumber

getnetent ou=networks ipNetwork cn,ipNetworkNumber

getspent ou=people posixAccount cn,uidNumber

# ldapmodify -a -D “cn=Directory Manager” -w password -f vlv.ldif

10 Directory Server Indexing • November 2000

Once the VLV indexes are added to the directory, you still need to enable them

before they can be used. To do this, run the vlvindex command as shown here.

Since it is always a good practice to verify that the VLV indexes have been defined,

run the ldapsearch command and observe the vlvsearch lines as shown here.

You should also observe the creation of the new db files.

Viewing Index Activity

The iPlanet Directory Console provides a convenient way to monitor the database

cache activity. Cumulative statistics are displayed which show how often the indexes

have been accessed and what the cache hit ratio is. Once the caches are full, you

should see close to a 100% hit ratio with no pages being written out. If you do not,

# install-dir/slapd-instance/vlvindex getpwent

# install-dir/slapd-instance/vlvindex getgrent

# install-dir/slapd-instance/vlvindex gethostent

# install-dir/slapd-instance/vlvindex getnetent

# install-dir/slapd-instance/vlvindex getspent

# ldapsearch -s base -b "" objectclass=\*

. . .

vlvsearch: cn=getspent,cn=config,cn=ldbm

vlvsearch: cn=getpwent,cn=config,cn=ldbm

vlvsearch: cn=getnetent,cn=config,cn=ldbm

vlvsearch: cn=gethostent,cn=config,cn=ldbm

vlvsearch: cn=getgrent,cn=config,cn=ldbm

. . .

# cd install-dir slapd-instance/db

# ls -l | grep vlv

-rw------- 1 nobody nobody 16384 Sep 8 10:07 vlv#gethostent.db2

-rw------- 1 nobody nobody 16384 Sep 8 10:07 vlv#getgrent.db2

-rw------- 1 nobody nobody 16384 Sep 8 10:07 vlv#getnetent.db2

-rw------- 1 nobody nobody 16384 Sep 8 10:07 vlv#getpwent.db2

-rw------- 1 nobody nobody 16384 Sep 8 10:07 vlv#getspent.db2

#

Conclusion 11

this could be an indication that the database cache is too small and should be

enlarged. Little or no activity on an index is an indication that the index is not

being used and it may be a candidate for removal.

You can view the following screen by going to the Status-—>Performance

Counters—>Database tab in the Directory Console. Only a portion of the screen

is shown here and it displays three of the VLV indexes that were created. Since

this was taken just after the VLV indexes were created, there is no current activity.

Conclusion

Indexing plays an important role in optimizing the performance of your directory

server. Both types of indexing discussed in this article, attribute and VLV, should be

deployed when configuring a directory server to support the native LDAP naming

service which is included in the Solaris 8 OE.

After indexes are created you should always verify that they were configured

correctly by examining the DIT and verifying that the associated index files were

created. Since it is not always obvious that a poorly indexed server is the root cause

of a performance problem, careful monitoring is also recommended.