|
| Sun ONE Directory Server 5.2 Deployment Guide |
Chapter 7 Designing a Secure Directory
How you secure the data in Directory Server affects all of the previous design areas. Your security design needs to protect the data contained by your directory and meet the security and privacy needs of your users and applications.
This chapter describes how to analyze your security needs and explains how to design your directory to meet these needs. It includes the following sections:
- About Security Threats
- Analyzing Your Security Needs
- Overview of Security Methods
- Selecting Appropriate Authentication Methods
- Preventing Authentication by Account Inactivation
- Designing your Password Policies
- Designing Access Control
- Securing Connections With SSL
- Encrypting Attributes
- Grouping Entries Securely
- Securing Configuration Information
- Other Security Resources
About Security Threats
There are many potential threats to the security of your directory. Understanding the most common threats helps you plan your overall security design. The most typical threats to directory security fall into the following three categories:
The remainder of this section provides a brief overview of the most common security threats to assist you with designing your directory's security policies.
Unauthorized Access
While it may seem simple to protect your directory from unauthorized access, the problem can in fact be more complicated. There are several opportunities along the path of directory information delivery for an unauthorized client to gain access to data.
For example, an unauthorized client can use another client's credentials to access the data. Or an unauthorized client can eavesdrop on the information exchanged between a legitimate client and Directory Server.
Unauthorized access can occur from inside your company, or if your company is connected to an extranet or to the Internet, from outside.
The scenarios described here are just a few examples of how an unauthorized client might access your directory data.
The authentication methods, password policies, and access control mechanisms provided by the Sun ONE Directory Server offer efficient ways of preventing unauthorized access. Refer to "Selecting Appropriate Authentication Methods", "Designing your Password Policies", and "Designing Access Control", for more information about these topics.
Unauthorized Tampering
If intruders gain access to your directory or intercept communications between Directory Server and a client application, they have the potential to modify (or tamper with) your directory data. Your directory is rendered useless if the data can no longer be trusted by clients, or if the directory itself cannot trust the modifications and queries it receives from clients.
For example, if your directory cannot detect tampering, an attacker could change a client's request to the server (or not forward it) and change the server's response to the client. SSL and similar technologies can solve this problem by signing information at either end of the connection. For more information about using SSL with Sun ONE Directory Server, refer to "Securing Connections With SSL".
Denial of Service
With a denial of service attack, the attacker's goal is to prevent the directory from providing service to its clients. For example, an attacker might simply use the system's resources to prevent them from being used by someone else.
Sun ONE Directory Server offers a way of preventing denial of service attacks by setting limits on the resources allocated to a particular bind DN. For more information about setting resource limits based on the user's bind DN, refer to the Setting Resource Limits Based on the Bind DN section of the Sun ONE Directory Server Administration Guide.
Analyzing Your Security Needs
You need to analyze your environment and users to determine your specific security needs. When you performed your site survey in Chapter 2 "Planning and Accessing Directory Data" you made some basic decisions about who can read and write the individual pieces of data in your directory. This information now forms the basis of your security design.
The way you implement security is also dependent on how you use the directory to support your business. A directory that serves an intranet does not require the same security measures as a directory that supports an extranet, or e-commerce applications that are open to the Internet.
If your directory serves an intranet only, your concerns are:
- To provide users and applications with access to the information they need to perform their jobs.
- To protect sensitive data regarding employees or your business from general access.
- To guarantee information integrity.
If your directory serves an extranet, or supports e-commerce applications over the Internet, in addition to the previous points, your concerns are:
- To offer your customers and business partners a guarantee of privacy.
- To guarantee information integrity.
This section contains the following information about analyzing your security needs:
- Determining Access Rights
- Ensuring Data Privacy and Integrity
- Conducting Regular Audits
- Example Security Needs Analysis
Determining Access Rights
When you perform your data analysis, you decide what information your users, groups, partners, customers, and applications need to access.
You may grant access rights in two ways:
- Grant all categories of users the ability to perform self-administration or delegate management while still protecting your sensitive data.
If you choose this open method, you must concentrate on determining what data is sensitive or critical to your business.
- Grant each category of users the minimum access they require to do their jobs.
If you choose this restrictive method, you must spend some time understanding the information needs of each category of user inside, and possibly outside of your organization.
No matter how you decide to grant access rights, you should create a simple table that lists the categories of users in your organization and the access rights you grant to each. You may also want to create a table that lists the sensitive data held in the directory, and for each piece of data, the steps taken to protect it.
For information about checking the identity of users, refer to "Selecting Appropriate Authentication Methods". For information about restricting access to directory information, refer to "Designing Access Control".
Ensuring Data Privacy and Integrity
When you are using the directory to support exchanges with business partners over an extranet, or to support e-commerce applications with customers on the Internet, you must ensure the privacy and the integrity of the data exchanged.
You can do this in several ways, by:
- Encrypting data
- Using certificates to sign data
- Encrypting data transfers
For information about encryption methods provided in the Sun ONE Directory Server, refer to "Password Storage Scheme" and "Encrypting Attributes". For information about signing data, refer to "Securing Connections With SSL".
Conducting Regular Audits
As an extra security measure, you should conduct regular audits to verify the efficiency of your overall security policy. You can do this by examining the log files and the information recorded by the SNMP agents. For more information about monitoring your directory, refer to Chapter 8 "Monitoring Your Directory."
Example Security Needs Analysis
The examples provided in this section illustrate how the imaginary ISP company Example.com analyzes its security needs.
Example.com's business is to offer web hosting and internet access. Part of Example.com's activity is to host the directories of client companies. It also provides internet access to a number of individual subscribers.
Therefore, Example.com has three main categories of information in its directory:
- Example.com internal information
- Information belonging to corporate customers
- Information pertaining to individual subscribers
Example.com needs the following access controls:
- Provide access to the directory administrators of Example2 and Example3 to their own directory information.
- Implement Example2's and Example3's own access control policies for their directory information.
- Implement a standard access control policy for all individual clients who use Example.com for Internet access from their homes.
- Deny access to Example.com's corporate directory to all outsiders.
- Grant read access to Example.com's directory of subscribers to the world.
Overview of Security Methods
Sun ONE Directory Server offers a number of methods that you can use to design an overall security policy that is adapted to your needs. Your security policy should be strong enough to prevent sensitive information from being modified or retrieved by unauthorized users while simple enough to administer easily. A complex security policy can lead to mistakes that either prevent people from accessing information that you want them to access or, worse, allow people to modify or retrieve directory information that you do not want them to access.
Sun ONE Directory Server provides the following security methods:
- Authentication
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.
- Password policies
Defines the criteria that a password must satisfy to be considered valid, for example, age, length, and syntax.
- Encryption
Protects the privacy of information. When data is encrypted, it is scrambled in a way that only the recipient can understand.
- Access control
Tailors the access rights granted to different directory users, and provides a means of specifying required credentials or bind attributes.
- Account inactivation
Disables a user account, group of accounts, or an entire domain so that all authentication attempts are automatically rejected.
- Secure Sockets Layer (SSL)
Maintains the integrity of information. If encryption and message digests are applied to the information being sent, the recipient can determine that it was not tampered with during transit.
- Auditing
Allows 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 tools for maintaining security 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.
Selecting Appropriate Authentication Methods
A basic decision you need to make regarding your security policy is how users access Directory Server. Will you allow anonymous access, or will you require every person who uses Directory Server to bind to the directory?
Sun ONE Directory Server supports the following authentication mechanisms:
- Anonymous Access
- Simple Password
- Proxy Authorization
- Simple Password Over a Secure Connection
- Certificate-Based Client Authentication
- SASL-Based Client Authentication
Directory Server uses the same authentication mechanism for all users, whether they are people or LDAP-aware applications.
For information about preventing authentication by a client or group of clients, see "Preventing Authentication by Account Inactivation".
Anonymous Access
Anonymous access provides the easiest form of access to your directory. It makes data available to any user of your directory, whether they have authenticated or not.
However, anonymous access does not allow you to track who is performing what kinds of searches; only that someone is performing searches. When you allow anonymous access, anyone who connects to your directory can access the data.
Therefore, if you attempt to block a specific user or group of users from seeing some kinds of directory data, but you have allowed anonymous access to that data, then those users can still access the data simply by binding to the directory anonymously.
You can restrict the privileges of anonymous access. Usually directory administrators only allow anonymous access for read, search, and compare privileges (not for write, add, delete, or selfwrite). Often, administrators limit access to a subset of attributes that contain general information such as names, telephone numbers, and email addresses. Anonymous access should never be allowed for more sensitive data such as government identification numbers (social security numbers in the US), home telephone numbers and addresses, and salary information.
If a user attempts to bind with an entry that does not contain a user password attribute, Directory Server either:
- Grants anonymous access if the user does not attempt to provide a password.
- Denies access if the user provides any non-null string for the password.
For example, consider the following ldapsearch command:
% ldapsearch -h ds.example.com -D "cn=joe,dc=Example,dc=com"
-w secretpwd -b "dc=Example,dc=com cn=joe" objectclass=*Although Directory Server allows anonymous access for read, Joe cannot access his own entry because it does not contain a password that matches the one he provided in the ldapsearch command.
Simple Password
If you have not set up anonymous access, you must authenticate to Directory Server before you can access the directory contents. With simple password authentication, a client authenticates to the server by sending a simple, reusable password.
For example, a client authenticates to Directory Server via a bind operation in which it provides a distinguished name and its credentials. The server locates the entry in the directory that corresponds to the client DN and checks whether the password given by the client matches the value stored with the entry. If it does, the server authenticates the client. If it does not, the authentication operation fails and the client receives an error message.
The bind DN often corresponds to the entry of a person. However, some directory administrators find it useful to bind as an administrative entry rather than as a person. Directory Server requires the entry used to bind to be of an object class that allows the userPassword attribute. This ensures that the directory recognizes the bind DN and password.
Most LDAP clients hide the bind DN from the user because users may find the long strings of DN characters hard to remember. When a client attempts to hide the bind DN from the user, it uses a bind algorithm such as the following:
- The user enters a unique identifier such as a user ID (for example, bjensen).
- The LDAP client application searches the directory for that identifier and returns the associated distinguished name (such as uid=bjensen,ou=people,dc=Example,dc=com).
- The LDAP client application binds to the directory using the retrieved distinguished name and the password supplied by the user.
Simple password authentication offers an easy way of authenticating users, but it is best to restrict its use to your organization's intranet. It does not offer the level of security required for transmissions between business partners over an extranet, or for transmissions with customers out on the Internet.
Proxy Authorization
The proxy authorization method is a special form of access control: a user that binds to Directory Server using its own identity is granted through proxy authorization the rights of another user.
For example, using proxy authorization, directory administrators can request access to Directory Server by assuming the identity of a regular user. They bind to the directory using their own credentials, but for purposes of access control evaluation, are granted the rights of the regular user. This assumed identity is called the proxy user, and the DN of that user, the proxy DN.
To configure Directory Server to allow proxy requests:
- You must grant the administrators the right to proxy as other users
- You must grant your regular users normal access rights as defined in your access control policy.
The proxy mechanism is very powerful. One of its main advantages is that you can enable an LDAP application to use a single thread with a single bind to service multiple users making requests against the Directory Server. Instead of having to bind and authenticate for each user, the client application binds to the Directory Server and uses proxy rights.
For more information on proxy authorization, refer to Chapter 6, "Managing Access Control" in the Sun ONE Directory Server Administration Guide.
Simple Password Over a Secure Connection
A secure connection uses encryption to make data unreadable to third parties while it is sent over the network between Directory Server and its clients. Clients may establish secure connections in either of the following ways:
- Bind to the secure port using the Secure Socket Layer (SSL).
- Bind to the insecure port with anonymous access, and then send 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. As a result, the client knows that it is connected to the intended server and that the server is not being tampered with.
The client and server then begin to encrypt all data transmitted through the connection for privacy. 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 or 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 they are returned to the client.
For more information about SSL, refer to "Securing Connections With SSL". For information about configuring certificates and activating SSL, see Chapter 11, "Implementing Security" in the Sun ONE Directory Server Administration Guide.
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 credentials, and not the DN, are used to determine the bind DN. Client authentication protects against user impersonation and is the most secure type of connection.
One form of credentials that a client may send is the user's certificate. To perform certificate-based authentication, the directory must be configured to perform certificate mapping, and all users must store a copy of their certificate in their entry. After receiving a user certificate from a client, the server performs a mapping based on the certificate contents to find a user entry in the directory. This entry must contain an exact copy of the certificate for the user to be positively identified. All operations proceed using this entry's DN as the bind DN, and all results are encrypted over the SSL or TLS connection.
For more information about certificate mapping, see "Using Client Authentication" in Chapter 10 of the Managing Servers with Sun ONE Console. See also "Configuring Certificate-Based Authentication in Clients" in Chapter 11 of the Sun ONE Directory Server Administration Guide.
SASL-Based Client Authentication
Another type of client authentication during an SSL or TLS connection uses the Simple Authentication and Security Layer (SASL) to establish the identity of the client. Directory Server supports the following mechanisms through the generic security interface of 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 wishing to be authenticated through DIGEST-MD5 must have {CLEAR} passwords in the directory.
- GSSAPI - Available only on the Solaris Operating Environment, the General Security Services API (GSSAPI) allows Directory Server to interact with the Kerberos V5 security system to positively identify a user. The client application must present its credentials to the Kerberos systems, which in turn validates the user's identity to Directory Server.
When using either SASL mechanism, the server must also be configured to perform identity mapping. The SASL credentials are called the Principal, and each mechanism must have specific mappings to determine the bind DN from the contents of the Principal. When the Principal is mapped to a single user entry and the SASL mechanism validates that user's identity, the user's DN is the bind DN for the connection.
For more information, see "SASL Authentication Through DIGEST-MD5" and "SASL Authentication Through GSSAPI (Solaris Only)" in Chapter 11 of the Sun ONE Directory Server Administration Guide.
Preventing Authentication by Account Inactivation
You can temporarily inactivate a user account or a set of accounts. Once inactivated, a user cannot bind to Directory Server, and the authentication operation fails.
Account inactivation is implemented through the operational attribute nsAccountLock. When an entry contains the nsAccountLock attribute with a value of true, the server rejects the bind.
You use the same procedures for inactivating users and roles. However, inactivating a role means that you inactivate all of the members of that role and not the role entry itself. For more information about roles, refer to "Managed, Filtered, and Nested Roles".
Designing your Password Policies
A password policy is a set of rules that govern how passwords are administered in a given system. Password policy in Directory Server defines the following:
- password change policy
- password minimum length
- password maximum age
- password expiration policy and its associated warning procedure
- password syntax check policy
- password storage scheme used
- password history procedure
- password failure record procedure
- account lockout procedure
In contrast to previous releases of Directory Server, password policy functionality provided by Sun ONE Directory Server 5.2 offers increased flexibility in that you can configure multiple password policies as opposed to one global policy for your entire directory. You can configure multiple password policies and you can choose to assign them either to particular users or to whole sets of users using the CoS and Roles functionality. This affords users and administrators of Directory Server significantly more scope when it comes to implementing password policy security measures, because they can tailor password policies to specific users or roles and thus cater precisely for their complex security requirements.
This section will begin with a presentation of basic password policy features. We will then take a look at the different ways in which you can configure your password policy, and examine the order of precedence that governs the application of multiple password policies. Finally, we will examine account lockout policy and the implications of designing password policies in a replicated environment. For detailed information regarding the attributes users have at their disposal to build a password policy that is suited to their needs, see the Password Policy Attributes and Account Lockout Attributes sections in the Sun ONE Directory Server Reference Manual. This section is divided into the following parts:
- Password Policy Features
- Configuring Your Password Policies
- Designing an Account Lockout Policy
- Designing Password Policies in a Replicated Environment
Password Policy Features
This section takes you through the main password policy features and is divided into the following sub-sections:
User-Defined Passwords
You can set up your password policy to either allow or not allow users to change their own passwords. A good password is the key to a strong password policy. Good passwords do not use trivial words—that is, any word that can be found in a dictionary, names of pets or children, birthdays, user IDs, or any other information about the user that can be easily discovered (or stored in the directory itself).
Also, a good password should contain a combination of letters, numbers, and special characters. Often, however, users simply use passwords that are easy to remember. This is why some enterprises choose to set passwords for users that meet the criteria of a "good" password, and do not allow the users to change passwords.
However, assigning passwords to users takes a substantial amount of an administrator's time. In addition, by providing passwords for users rather than letting them come up with passwords that are meaningful to them and therefore more easily remembered, you run the risk that the users will write their passwords down somewhere where they can be discovered. By default, user-defined passwords are allowed.
Password Change After First Login or Reset
The Directory Server password policy lets you decide whether users must change their passwords after the first login or after the password is reset by the administrator.
Often the initial passwords set by the administrator follow some sort of convention, such as the user's initials, user ID, or the company name. Once the convention is discovered, it is usually the first value tried by a hacker trying to break in. In this case, it is a good idea to require users to change their passwords after such a change. If you configure this option for your password policy, users are required to change their password even if user-defined passwords are disabled. For further information see "User-Defined Passwords".
If you choose not to allow users to change their own passwords, administrator assigned passwords should not follow any obvious convention and should be difficult to discover.
By default, users do not need to change their passwords after their login or a reset.
Password Expiration
You can configure your password policy so that users can use the same passwords indefinitely. Or, you can configure your policy so that passwords expire after a given time. In general, the longer a password is in use, the more likely it is to be discovered. On the other hand, if passwords expire too often, users may have trouble remembering them and resort to writing their passwords down. A common policy is to have passwords expire every 30 to 90 days.
Directory Server remembers the password expiration configuration even if you disable password expiration. This means that if you re-enable password expiration, passwords are valid only for the duration you set before you last disabled the feature. For example, suppose you set up passwords to expire every 90 days and then decided to disable password expiration. When you decide to re-enable password expiration, the default password expiration duration is 90 days because that is what you had it set to before you disabled the feature.
By default, user passwords never expire.
Expiration Warning
If you choose to set your password policy so that user passwords expire after a given number of days, it is a good idea to send users a warning before their passwords expire. You can set your policy so that users are sent a warning 1 to 24,855 days before their passwords expire. Directory Server displays the warning when the user binds to the server. If password expiration is turned on, by default, a warning is sent (via an LDAP message) to the user one day before the user's password expires, provided the user's client application supports this feature.
Password Syntax Checking
The password policy establishes syntax guidelines for password strings. The password syntax-checking mechanism ensures that password strings conform to the password syntax guidelines established by the password policy. By default, password syntax checking is turned off.
Password Length
Directory Server allows you to specify a minimum length for user passwords. In general, shorter passwords are easier to crack. You can require passwords that are from 2 to 512 characters. A good length for passwords is 8 characters. This is long enough to be difficult to crack, but short enough so that users can remember the password without writing it down.
By default the minimum password length is 6 characters. The minimum length of a password is checked only if password syntax checking is turned on.
Password Minimum Age
You can configure Directory Server to not allow users to change their passwords for a given time. You can use this feature in conjunction with the passwordInHistory attribute to discourage users from reusing old passwords.
Setting the password minimum age (passwordMinAge) attribute to 2 days, for example, prevents users from repeatedly changing their password during a single session to cycle through the password history and reuse an old password once it is removed from the history list. You can specify any number from 0 to 24,855 days. A value of zero (0) indicates that the user can change the password immediately.
Password History
You can configure Directory Server to store a maximum of 24 used passwords by entering an integer value in the passwordInHistory attribute. If you enter a value of 0, then the password history function will not be enabled. As a result, no previously used passwords will be stored and users will be able to reuse passwords.
If, however, you enter a value between 1 and 24 in the passwordInHistory attribute, the directory will store that number of old passwords in the passwordHistory attribute. If a user attempts to reuse one of the passwords Directory Server has stored, the directory rejects the password. This feature prevents users from reusing one or two passwords that are easy to remember.
By default, Directory Server does not store any previously used passwords.
Password Storage Scheme
The password storage scheme specifies the type of encryption used to store Directory Server passwords within the directory. You can specify:
- Clear text (no encryption).
- Secure Hash Algorithm (SHA).
- Salted Secure Hash Algorithm (SSHA). This encryption method is the default method.
- UNIX CRYPT algorithm.
Although passwords stored in the directory can be protected through the use of access control information (ACI) instructions, it is still not a good idea to store clear text passwords in the directory. The crypt algorithm provides compatibility with UNIX passwords. SSHA is the most secure of the choices and is the default hash algorithm for Directory Server.
Configuring Your Password Policies
In Sun ONE Directory Server 5.2 you have four password policy options available to you. Directory Server provides you with a default password policy, which will be applied automatically, the parameters of which you can change should you wish to do so. As a backup to the default password policy, Directory Server also provides a hard-coded password policy, which is applied should the default password policy be absent or, following modifications, no longer valid. The attribute values of the hard-coded password policy are the same as the default password policy values. Otherwise you can choose to define a password policy and apply it to a particular user, or to a set of users using the CoS and Roles functionality.
This section will describe each of these password policy options in more detail, and will explain the order of precedence that governs the application of password policies when multiple password policies exist for a given user entry. This section is divided into the following parts:
- Default Password Policy
- Defining Password Policies for Users or Sets of Users
- Multiple Password Policies and Their Order of Precedence
Default Password Policy
The default password policy provided with Sun ONE Directory Server is, as its name suggests, the password policy that is used should users not design their own.
Note Should you wish to change any of the default password policy attribute values, do not forget that in contrast to previous releases of Directory Server, the password policy attributes are no longer stored directly under cn=config, but instead under cn=Password Policy,cn=config.If this entry does not exist then the hard-coded password policy provided with Directory Server will be applied.
For more information about the password policy attributes see the Password Policy Attributes section in the Sun ONE Directory Server Reference Manual.
By default your password policy will enforce the following:
- The SSHA storage scheme.
- Users can change their passwords.
- Users do not have to change their password after their first login or after the password is reset by the administrator.
- Password syntax checks (i.e., compliance with the minimum number of characters) will not be performed.
- Passwords will never expire.
- The maximum age of a password is 100 days but only if you decide to activate password expiration.
- No time needs to elapse between modifications to the password.
- If you decide to activate the password expiration mechanism, a password expiration warning will be sent 1 day before the password is due to expire on your first bind attempt.
- Passwords used will not be recorded.
- Users are never locked out of their accounts.
- If you decide to activate the account lockout mechanism, then by default users will be locked out after a maximum number of 3 failed bind attempts, and the lockout will last for 1 hour.
- Password failures are purged from the failure counter after 600 seconds.
How you adapt the default password policy will of course depend on how stringent your security requirements are. A password policy such as the default password policy where passwords never expire, where no syntax checks are performed, and which does not have an account lockout mechanism enabled does not come without its security risks. You will have to be sure to balance your security requirements against the management overheads generated by a demanding password policy. Once you have established your precise security requirements and deployed a certain password policy solution, you will be able to analyze its pros and cons, and make changes should you be concerned that your chosen policy does not provide sufficient security or is proving to be too unwieldy.
Defining Password Policies for Users or Sets of Users
To define a password policy for a given user entry or a set of users a new attribute called passwordPolicySubentry is used. The value of this attribute is the DN of an LDAPsubentry that contains the password policy attributes you wish to apply directly to the user's entry. This attribute can either be a real attribute, in the sense that you enter it, or a virtual attribute, in that it is generated by a CoS definition. A natural way of defining password policies for a set of users is to configure the CoS definition to provide values for the passwordPolicySubentry attribute in user entries as a function of the Roles that those user entries have. Assigning password policies to sets of users by assigning them as a function of the Roles those users have is not the only possibility you have available to you, but it is the one presented to you by Directory Server Console.
Defining a Password Policy for a User
When you want to configure a password policy for a given user you must define it for a particular subtree by adding an LDAP entry whose immediate superior is the root of the subtree in question.
Caution
Users must not be able to modify their own passwordPolicySubentry attribute which should be controlled by an ACI.
Imagine that as system administrator of the company Example.com, you want to apply a more stringent password policy called strictPwdPolicy to a user in the dc=example,dc=com subtree. The strictPwdPolicy password policy you wish to apply, in contrast to the default policy, performs syntax checks, enforces the expiration of passwords after 10 days, and proceeds with account lockout once 3 consecutive bind attempts have failed. You would add the following passwordPolicySubentry attribute directly to the user entry in the dc=example,dc=com subtree:
passwordPolicySubentry:cn=strictPwdPolicy,dc=example,dc=com
The value of the above passwordPolicySubentry attribute is the DN of the LDAPsubentry that stores attributes which define the strictPwdPolicy password policy. This LDAPsubentry for your strictPwdPolicy password policy would read as follows:
dn:cn=strictPwdPolicy,dc=example,dc=com
objectclass:top
objectclass:passwordPolicy
objectclass:LDAPsubentry
passwordStorageScheme:SSHA
passwordChange:on
passwordMustChange:on
passwordCheckSyntax:on
passwordExp:on
passwordMinLength:6
passwordMaxAge:8640000
passwordMinAge:0
passwordWarning:8640000
passwordInHistory:6
passwordLockout:on
passwordMaxFailure:3
passwordUnlock:off
passwordLockoutDuration:3600
passwordResetFailureCount:600
Defining a Password Policy for a Set of Users Using CoS and Roles Functionality
In the same way, imagine that as system administrator of the company Example.com, where contractors are assigned to a contractor managed role, and all in-house employees are assigned to an employee managed role, you decide that you want to apply your more stringent password policy veryStrictPwdPolicy to all contractors and a less stringent password policy called normalPwdPolicy to your employees.
Table 7-1 presents your contractor role and employee role definitions:
By defining a CoS definition entry and a CoS template entry that contain the required password policy for both roles, your passwordPolicySubentry attributes (which point to DN of the LDAPsubentry containing the appropriate password policy) will be generated for each role.
Note When assigning a password policy to (members of) a role, do NOT add the passwordPolicySubentry attribute to the role itself , but instead to the CoS associated with that role.
You will want to create one CoS definition entry that will generate the passwordPolicySubentry attribute values for each role. The CoS definition entry you will need to create is presented in Table 7-2:
By specifying the following operational qualifier:
cosAttribute:passwordPolicySubentry operational
you are specifying that you want the generated, and therefore virtual, value of the cosAttribute to override any real attribute that may exist. It is in actual fact necessary to specify the operational qualifier here. For more information on Roles and CoS, see Chapter 4 "Designing the Directory Tree."
Once you have created the CoS definition entry, you will then create the CoS template entries that contain the values of the virtual passwordPolicySubentry attributes. In our example, the virtual value of the passwordPolicySubentry attribute for the contractor managed role will be the dn of the strictPwdPolicy LDAPsubentry, and the dn of the normalPwdPolicy LDAPsubentry for the employee managed role. The CoS template entry you will need to create for the contractor managed role is presented below in Table 7-3
and the CoS template entry you will need to create for the employee managed role is presented below in Table 7-4
The above entries also show that you have decided to store your template entries in a container called cn=PwdPolTempContainer,dc=example,dc=com which appears in ldif as follows:
dn:cn=PwdPolTempContainer,dc=example,dc=com
objectclass:top
objectclass:nsContainer
Multiple Password Policies and Their Order of Precedence
Now that Directory Server allows for multiple password policies, we can easily imagine the scenario where a password policy exists for a user entry while that same user entry belongs to a role that also has a password policy assigned to it. Which password policy takes precedence? In order to deploy password policies that actually correspond to your security needs, you need to understand the order of precedence that governs their application and how to control that order when defining your CoS template entries.
There are three main rules of precedence that govern the application of password policies when a user entry has more than one password policy assigned to it. The rules are as follows:
- A password policy generated by a CoS definition will take precedence over a password policy assigned directly to the same user entry. This is true because the cosAttribute value defined in the CoS definition entry is obliged to contain an operational qualifier, which causes the CoS generated password policy to override any real attributes that may have been assigned directly to the user. For more information about the Roles and CoS mechanism, see Chapter 4 "Designing the Directory Tree."
- A password policy assigned to a user entry will take precedence over the default password policy.
- The default password policy, stored under cn=Password Policy,cn=config, will take precedence over the hard-coded password policy values provided with Directory Server.
Caution
When you are configuring password policies using CoS, it is important to establish an order of precedence in the event that a user entry is affected by more than one CoS generated password policy, You specify the desired order of precedence by entering the appropriate value in the cosPriority attribute when you create your CoS template entry. You assign the highest priority with a value of 0. CoS templates that contain no cosPriority attribute are considered lowest priority, and when templates have the same (or no) cosPriority attribute value, a priority is chosen arbitrarily. Again, for more information on Roles and CoS, see Chapter 4 "Designing the Directory Tree."
Designing an Account Lockout Policy
Once you have established the password policies for your directory, you can protect your user passwords from potential threats by configuring an account lockout policy.
The lockout policy works in conjunction with the password policy to provide further security. You can set up your password policy so that a specific user is locked out of the directory after a given number of failed attempts to bind.
The account lockout feature protects against hackers who try to break into the directory by repeatedly trying to guess a user's password. Account lockout counters are local to a directory server. This feature is not designed as a global lockout from your directory service, which means that even in a replicated environment, account lockout counters are not replicated.
Designing Password Policies in a Replicated Environment
Password and account lockout policies are enforced in a replicated environment as follows:
- Password policies are enforced on the master copy of the data.
- Account lockout is enforced on all servers participating in replication.
Some of the password policy state information in your directory is replicated. The replicated attributes are:
- passwordHistory
- passwordAllowChangeTime
- passwordExpirationTime
When configuring password policies in a replicated environment, consider the following points:
- In an environment that uses multiple password policies, you need to be sure to replicate the LDAP subentry that contains the definition of the policy to apply to the replicated entries. If you fail to do so, the LDAP subentry containing the definition of your policy will not exist and the default password policy will be applied.
- All replicas issue warnings of an impending password expiration. This information is kept locally on each server, so if a user binds to several replicas in turn, the user receives the same warning several times. In addition, if the user changes the password, it may take time for this information to be updated on the consumer replicas. If a user changes a password and then immediately rebinds, the bind may fail until the consumer replica registers the changes made to the master replica.
- You want the same bind behavior to occur on all servers, including suppliers and consumers. Make sure you create the same password policy configuration information on each server.
- Account lockout counters may not work as expected in a multi-master environment, given that they are not replicated.
- Entries that are created for replication (for example, the server identity Replication Manager entries) need to have passwords that never expire. To make sure that these special users have passwords that do not expire, add the passwordExpirationTime attribute to the entry and give it a value of 20380119031407Z (i.e. the maximum value in the valid range).
Designing Access Control
Once you decide on one or more authentication schemes to establish the identity of directory clients, you need to decide how to use the schemes to protect information contained in your directory. Access control allows you to specify that certain clients have access to particular information, while other clients do not.
You specify access control using one or more access control lists (ACL). Your directory's ACLs consist of a series of one or more access control information (ACI) statements that either allow or deny permissions (such as read, write, search, proxy, add, delete, and compare) to specified entries and their attributes.
Using the 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 belonging to a specific 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.
This section will examine the Sun ONE Directory Server access control mechanism and is divided into the following parts:
- About the ACI Format
- Default ACIs
- Deciding How to Set Permissions
- Requesting Effective Rights Information
- Tips on Using ACIs
- ACI Limitations
About the ACI Format
When designing your security policy, it is helpful to understand how ACIs are represented in Directory Server. It is also helpful to understand what permissions you can set in your directory. This section gives you a brief overview of the ACI mechanism. For a complete description of the ACI format, see the Managing Access Control chapter of the Sun ONE Directory Server Administration Guide.
Access control instructions are stored in the directory, as attributes of entries. The aci attribute is an operational attribute; it is available for use on every entry in the directory, regardless of whether it is defined for the object class of the entry. It is used by Directory Server to evaluate what rights are granted or denied when it receives an LDAP request from a client. The aci attribute is returned in an ldapsearch operation if specifically requested. Directory ACIs take the following general form:
target permission bind_rule
The ACI variables are defined below:
- target
Specifies the entry (usually a subtree) that the ACI targets, the attribute it targets, or both. In other words, the target identifies the directory element that the ACI applies to. An ACI can target only one entry, but it can target multiple attributes. In addition, the target can contain an LDAP search filter. This allows you to set permissions for widely scattered entries that contain common attribute values.
- permission
Identifies the actual permission being set by this ACI. The permission says that the ACI allows or denies a specific type of directory access, such as read, write, search, proxy, add, delete, and compare to the specified target.
- bind_rule
Identifies the bind DN or network location to which the permission applies. The bind rule may also specify an LDAP filter, and if that filter is evaluated to be true for the binding client application, then the ACI applies to the client application.
So, ACIs are expressed as follows:
"For the directory object target, allow or deny permission if the bind_rule is true."
An example ACI which allows all users search, read and compare permissions for all attributes would appear as follows:
aci: (targetattr = "*")(version 3.0; acl "my aci"; allow
(search,read,compare) userdn="ldap:///all";)
The permission and bind_rule portions of the ACI are set as a pair, and are also called an Access Control Rule. You can have multiple permission bind_rule pairs for every target. This allows you to efficiently set multiple access controls for any given target. For example:
target (permission bind_rule) (permissions bind_rule)...
For example, you can set a permission that allows anyone binding as Babs Jensen to write to Babs Jensen's telephone number. The bind rule in this permission is the part that states "if you bind as Babs Jensen." The target is Babs Jensen's phone number, and the permission is write access.
Targets
You must decide what entry is targeted by every ACI you create in your directory. If you target a directory entry that is a directory branch point, then that branch point, as well as all of its child entries, is included in the scope of the permission. The advantage of this is that you can place at a high level in the directory tree a general ACI that effectively applies to entries more likely to be located lower in the tree. For example, at the level of an organizationalUnit entry or a locality entry, you could create an ACI that targets entries that include the inetorgperson object class. You can use this feature to minimize the number of ACIs in the directory tree by placing general rules at high level branch points. To limit the scope of more specific rules, you should place them as close as possible to leaf entries.
If you do not explicitly specify a target entry for the ACI, then the ACI is targeted to the directory entry that contains the ACI statement. Also, the default set of attributes targeted by the ACI is any attribute available in the targeted entry's object class structure.
For every ACI, you can target only one entry or only those entries that match a single LDAP search filter.
Note ACIs placed in the root DSE entry apply only to that entry.
In addition to targeting entries, you can also target attributes on the entry. This allows you to set a permission that applies to only a subset of attribute values. You can target sets of attributes by explicitly naming those attributes that are targeted, or by explicitly naming the attributes that are not targeted by the ACI. Use the latter case if you want to set a permission for all but a few attributes allowed by an object class structure. The aci attribute is multi-valued, which means that you can define several ACIs for the same entry or subtree.
Permissions
You allow or deny permissions. In general, you should avoid denying permissions for the reasons explained in "Allowing or Denying Access".
You can allow or deny the following permissions:
- Read
Indicates whether directory data may be read.
- Write
Indicates whether directory data may be changed or created. This permission also allows directory data to be deleted, but not the entry itself. To delete an entire entry, the user must have delete permissions.
- Search
Indicates whether the directory data can be searched. This differs from the read permission in that read allows directory data to be viewed if it is returned as part of a search operation. For example, if you allow searching for common names and read for a person's room number, then the room number can be returned as part of the common name search, but the room number cannot, itself, be searched for. This would prevent people from searching your directory to see who occupies a particular room.
- Compare
Indicates whether the data may be used in comparison operations. Compare implies the ability to search, but actual directory information is not returned from the search. Instead, a simple Boolean value is returned that indicates whether the compared values match. This is used to match userPassword attribute values during directory authentication.
- Selfwrite
Used only for group management. This permission allows users to add or delete themselves from a group. Selfwrite works with proxy authorization: it grants the right to add or remove the proxy DN from a group entry (not the DN of the bound user).
- Add
Indicates whether child entries can be created. This permission allows a user to create child entries beneath the targeted entry.
- Delete
Indicates whether an entry can be deleted. This permission allows a user to delete the targeted entry.
- Proxy
Indicates that the user can use any other DN (except Directory Manager) to access the directory with the rights of this DN.
Bind Rules
The bind rule usually indicates the bind DN subject to the permission. It can also specify bind attributes such as time of day or IP address.
Bind rules allow you to easily express that the ACI applies only to a user's own entry. You can use this to allow users to update their own entries without running the risk of a user updating another user's entry.
Using bind rules, you can indicate that the ACI is applicable:
- Only if the bind operation is arriving from a specific IP address or DNS hostname. This is often used to force all directory updates to occur from a given machine or network domain.
- If the person binds anonymously. Setting a permission for anonymous bind means that the permission also applies to anyone who binds to the directory.
- For anyone who successfully binds to the directory. This allows general access while preventing anonymous access.
- Only if the client has bound as the immediate parent of the entry.
- Only if the entry that the person has bound as meets a specific LDAP search criteria.
The following keywords are provided to help you express these kinds of access more easily:
- Parent
If the bind DN is the immediate parent entry, then the bind rule is true. This allows you to grant specific permissions that, for example, allow a directory branch point to manage its immediate child entries.
- Self
If the bind DN is the same as the entry requesting access, then the bind rule is true. For example, you can grant specific permission that allows individuals to update their own entries.
- All
The bind rule is true for anyone who has successfully bound to the directory.
- Anyone
The bind rule is true for everyone. This keyword is what allows or denies anonymous access.
Default ACIs
From an access control design perspective it is important to understand which default ACIs apply to the directory information you have stored in the userRoot database, so that you can then decide how best to tailor it to your deployment needs by modifying them. Whenever you create a new database in the directory, the top entry has the default ACIs listed below:
- Users can modify their own entry in the directory, but not delete it. They cannot modify the aci and nsroledn attributes.
- Users have anonymous access to the directory for search, compare, and read operations.
- The administrator (by default uid=admin,ou=Administrators, ou=TopologyManagement,o=NetscapeRoot) has all rights except proxy rights.
- All members of the Configuration Administrators group have all rights except proxy rights.
- All members of the Directory Administrators group have all rights except proxy rights.
- SIE group.
The o=NetscapeRoot subtree has its own set of default ACIs:
- All members of the Configuration Administrators group have all rights on the o=NetscapeRoot subtree except proxy rights.
- Users have anonymous access to the o=NetscapeRoot subtree for search and read operations.
- Entries under o=NetscapeRoot can define which groups have read, search, and compare access to them using the value of the uniqueMember attribute.
- All authenticated users have search, compare, and read rights to configuration attributes that identify the administration server.
For information on how to modify these default settings and implement your access control policy, see the Sun ONE Directory Server Administration Guide.
Deciding How to Set Permissions
If there are no ACIs present in the directory, then the default policy is not to grant users access rights of any kind. The exception to this is the directory manager. For this reason, you must set some ACIs for Directory Server if you want your users to be able to access your directory. The following sections describe the access control mechanism provided by Directory Server. For information about how to set ACIs, see the Managing Access Control chapter of the Sun ONE Directory Server Administration Guide.
The Precedence Rule
When a user attempts any kind of access to a directory entry, Directory Server examines the access control set in the directory. To determine access, Directory Server applies the precedence rule. The rule states that when two conflicting permissions exist, the permission that denies access always takes precedence over the permission that grants access.
For example, if you deny write permission at the directory's root level, and you make that permission applicable to everyone accessing Directory Server, then no user can write to the directory regardless of any other permissions that you may allow. To allow a specific user write permissions to Directory Server, you have to restrict the scope of the original deny-for-write so that it does not include that user. Then you have to create an additional allow-for-write permission for the user in question.
Allowing or Denying Access
You can explicitly allow or deny access to your directory tree. Be careful of explicitly denying access to Directory Server. Because of the precedence rule, if the directory finds rules explicitly forbidding access, it will forbid access regardless of any conflicting permissions that may grant access.
Limit the scope of your allow access rules to include only the smallest possible subset of users or client applications. For example, you can set permissions that allow users to write to any attribute on their directory entry, but then deny all users except members of the Directory Administrators group the privilege of writing to the uid attribute. Alternatively, you can write two access rules that allow write access in the following ways:
- Create one rule that allows write privileges to every attribute except the uid attribute. This rule should apply to everyone.
- Create one rule that allows write privileges to the uid attribute. This rule should apply only to members of the Directory Administrators group.
By providing only allow privileges, you avoid the need to set an explicit deny privilege.
When to Deny Access
You rarely need to set an explicit deny. However, you may find an explicit deny useful in the following circumstances:
- You have a large directory tree with a complicated ACL spread across it.
For security reasons, you find that you suddenly need to deny access to a particular user, group, or physical location. Rather than take the time to carefully examine your existing ACL to understand how to appropriately restrict the allow permissions, you may want to temporarily set the explicit deny until you have time to do this analysis. If your ACL has become this complicated, then, in the long run, the deny ACI only adds to your administrative burden. As soon as possible, rework your ACL to avoid the explicit deny and simplify your overall access control scheme.
- You want to restrict access control based on a day of the week or an hour of the day.
For example, you can deny all writing activities from Sunday at 11:00 p.m. (2300) to Monday at 1:00 a.m. (0100). From an administrative point of view, it may be easier to manage an ACI that explicitly restricts time-based access of this kind than to search through the directory for all the allow for write ACIs and restrict their scopes in this time frame.
- You want to restrict privileges when you are delegating directory administration authority to multiple people.
If you are allowing a person or group of people to manage some part of the directory tree, but you want to make sure that they do not modify some aspect of the tree, use an explicit deny. For example, if you want to make sure the Mail Administrators do not allow write access to the common name attribute, then set an ACI that explicitly denies write access to the common name attribute.
Where to Place Access Control Rules
Access control rules can be placed on any entry in the directory. Often administrators place access control rules on entries of type country, organization, organizationalUnit, inetOrgPerson, or group.
To simplify your ACL administration, group your rules as much as possible. Since a rule generally applies to its target entry and to all that entry's children, it is best to place access control rules on root points in the directory or on directory branch points, rather than to scatter them across individual leaf (such as person) entries.
Note From a performance standpoint it is important to realize that ACIs are kept in memory and can considerably impact your memory usage performance. When a server starts all access controls are brought into memory, although cache limits do not apply to them. We recommend therefore, that in organizations using repeating directory tree structures, you optimize the number of ACIs used in Directory Server by using macro ACIs where possible.
Macros are placeholders that are used to represent a DN, or a portion of a DN, in an ACI. You can use a macro to represent a DN in the target portion of the ACI, or in the bind rule portion, or both. In practice, when Directory Server gets an incoming LDAP operation, the ACI macros are matched against the resource targeted by the LDAP operation. If there is a match, the macro is replaced by the value of the DN of the targeted resource. Directory Server then evaluates the ACI normally. For more information on macro ACIs refer to the Managing Access Control chapter of the Sun ONE Directory Server Administration Guide.
Using Filtered Access Control Rules
One of the more powerful features of the Directory Server ACI model is the ability to use LDAP search filters to set access control. LDAP search filters allow you to set access to any directory entry that matches a defined set of criteria.
For example, you could allow read access for any entry that contains an organizationalUnit attribute that is set to Marketing.
Filtered access control rules let you use predefine levels of access. For example, suppose your directory contains home address and telephone number information. Some people want to publish this information, while others want to be "unlisted." You can handle this situation by doing the following:
- Create an attribute on every user's directory entry called publishHomeContactInfo.
- Set an access control rule that grants read access to the homePhone and homePostalAddress attributes only for entries whose publishHomeContactInfo attribute is set to TRUE (meaning enabled). Use an LDAP search filter to express the target for this rule.
- Allow your directory users to change the value of their own publishHomeContactInfo attribute to either TRUE or FALSE. In this way, the directory user can decide whether this information is publicly available.
For more information about using LDAP search filters, and on using LDAP search filters with ACIs, see the Sun ONE Directory Server Administration Guide.
Requesting Effective Rights Information
The rich access control model provided by Directory Server is powerful in that access can be granted to users via many different mechanisms, but this richness, although very welcome when you are having to configure your access control policy, means that it can be a complex affair trying to determine what the policy actually comprises at a later date. Because there are several parameters that can define the security context of a user, for example, IP address and machine name, time of day, authentication method, or simply the type of attribute you may be trying to add, the need to be able to list the entry and attribute permissions becomes critical. Without this ability to request the rights of a given user to directory entries and attributes, user administration, access control policy verification, and debugging would be much more difficult.
Sun ONE Directory Server 5.2 provides a new feature called Effective Rights, which allows clients to query what access control rights they have to directory entries and attributes.
This section examines the effective rights feature in more detail and is divided into the following sub-sections:
- About the Effective Rights Feature
- Access Control on the Effective Rights Feature
- Understanding the Effective Rights Results
About the Effective Rights Feature
The effective rights feature works via an ldapsearch operation. Note that this feature requires the ldapsearch utility supplied with the Directory Server Resource Kit (DSRK).
The rights information you require is specified using a particular option (discussed below) and the information relative to these rights is returned with your ldapsearch results. To specify the rights information you require, use the following elements in your ldapsearch operation:
- An Effective Rights control (1.3.6.1.4.4.42.2.27.9.5.2) to specify that you are requesting effective rights information. You include this control in your ldapsearch operation using the -J option.
- Arequest for an operational attribute aclRights to return access control effective rights information at both an entry and attribute level.
- The -c option of ldapsearch to specify the user whose rights you are requesting
- If necessary, the -X option of ldapsearch to specify the list of attribute types for which you want to have rights information, if they are not already being returned with the entry.
The first question you need to ask yourselves when using the effective rights feature is for which user you are trying to obtain the effective access control rights. Once you know which user's rights you require, you can then specify that user with the -c ldapsearch option. It is worth noting that if you include
-c "dn:"
in your ldapsearch command, you are requesting effective rights for an anonymous user, and if you have NULL or an empty string for the -c option, that is -c "", then you are requesting the bound user's rights.
The next question you need to ask yourself is for which attributes you are requesting the effective rights. The attributes for which you require rights information do not necessarily need to exist in the entry. We can imagine the scenario where an entry does not include the description attribute, but that you want to know which rights a given user would have on that attribute. To specify the list of attribute types for which you want rights information, you use the -X ldapsearch option followed by the attribute name, for example -X description.
The effective rights feature provided with Directory Server also allows you to specify different levels of access control information. You can choose either to request only the rights information, only the logging information, or both together. Since the logging information (which includes a synopsis of the rights information) provides detail down to a permission level, it allows you not only to establish what access control policy is effective, but also to understand why a given operation may have been denied or allowed. The subtyping for the operational aclRights attribute that allows you to specify the information you want to have returned is as follows:
aclRights
Requests the rights information only
aclRightsInfo
Requests the logging information only
aclRights aclRightsInfo
Requests both the rights and logging information
Caution
You cannot use the aclRights attribute in a search filter.
Access Control on the Effective Rights Feature
In order to successfully obtain the effective rights information, users must have the access control rights to use the Effective Rights control, and, in order to have any rights information returned to the user for a given entry, the user will also need read access to the aclRights attribute. This double layer of access control for the effective rights feature provides basic protection which can then be more finely tuned where necessary. By analogy with proxy, if you have read access to the aclRights attribute in an entry, then you can ask about anyone's rights to that entry and its attributes. The logic behind this access control setup is that it makes sense for the user who manages the resource to know who has rights to that resource, even if that same user does not actually manage those with the rights.
If a user requesting rights information does not have the rights to use the Effective Rights control, then the operation will fail and an error message to that effect will be sent. However, if the user requesting rights information does have the rights to use the control but lacks the rights to read the aclRights attribute, then the aclRights attribute will simply be absent from the returned entry. This behavior reflects the Directory Server's general search operation behavior.
Understanding the Effective Rights Results
This part presents the effective rights search results and is divided into the following subparts:
Rights Information
The effective rights information is presented according to the following subtypes:
Once the information has been presented down to this level then the permissions and attribute names are used to subtype and separate the information.
For Sun ONE Directory Server 5.2 the aclRights string appears as follows:
permission:value(permission:value)*
Possible entry level permissions are add, delete, read, write, and proxy while possible attribute level permissions are read, search, compare, write, selfwrite_add, selfwrite_delete, and proxy.
Caution
In future releases of Directory Server new permissions may be added to this string.
The aclRights string containing the results of the requested rights information will either mark these permissions as:
- "0" for not granted
- "1" for granted or
- "?" for cases where the granting of rights depends on the value of the attribute you are adding, deleting, or replacing. If you see a ?, then you are advised to consult the logging information to establish exactly why the permissions will or will not be granted.
- "-" to indicate that the attribute in question is a virtual attribute, and therefore not updatable. The only way to modify a virtual attribute is to modify the mechanism that generates it.
By way of an example, imagine that you wanted to request the effective rights (excluding the logging information) for the cn attribute of the user cn=justread in the cn=peopletestResource subtree. You would run the following ldapsearch command:
./ldapsearch -D "cn=directory manager" -w secret12
-c "dn:cn=justread,dc=france,dc=sun,dc=com" -p 5200
-b cn=peopletestResource,dc=france,dc=sun,dc=com
objectclass=* cn "aclRights"If the user cn=justread has only read permissions on the cn attribute, then the requested effective rights information would appear as follows:
dn: cn=peopleTestResource,dc=france,dc=sun,dc=com
aclRights;attributeLevel;cn:search:0,read:1,compare:0,write:0,
selfwrite_add:0,selfwrite_delete:0,proxy:0
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0Write, Selfwrite_add, and Selfwrite_delete permissions
In Sun ONE Directory Server 5.2 only the write attribute level permissions can be marked with a "?", although this may change in future releases. For the add and delete permissions, the entries you can add and delete can depend on the values of the attributes in the entry. However, instead of returning a "?" should it prove to be the case, the permission (i.e. "0" or "1") is returned on the entries as they are returned with the ldapsearch operation.
If the value for a write permission is "1", then this means that the permission is granted for both add and delete ldapmodify operations for all values except possibly the authorization dn value. A value of 0 for a write permission means that the permission is not granted for either add or delete ldapmodify operations for any values, except possibly the value of the authorization dn. The permission in force for the value of the authorization dn is returned explicitly in one of the selfwrite permissions; that is, either selfwrite_add or selfwrite_delete.
It is necessary to make a distinction between selfwrite-add and selfwrite-delete attribute level permissions in the effective rights functionality. Although these permissions do not actually exist as such in the context of ACIs, the reality of a set of ACIs can be to grant a user selfwrite permission for just the add or just the delete part of a modify operation. The same distinction is not made for the write permission because, in contrast to the selfwrite permission where the value of the attribute being modified is defined, in that it is the authorization dn, the value of the attribute being modified for a write permission is undefined. When the effective permission depends on a targattrfilters ACI, we cannot extend the analysis further, and therefore use the "?" value to indicate that the logging information should be consulted for more permission detail. Given the relative complexity of the interdependencies between the write, selfwrite_add, and selfwrite_delete permissions, Table 7-5 explains what the possible combinations of these three permissions actually mean.
Logging Information
The effective rights logging information provides you with the key to understanding, and therefore being able to debug access control difficulties. The logging information contains an access control summary statement, called the acl_summary, that provides you with the reasons as to why your access control has either been allowed or denied. The access control summary statement tells you the following:
- Whether access was allowed or denied
- The permissions granted
- The target entry of the permissions
- The name of the target attribute
- The subject of the rights being requested
- Whether or not the request was made by proxy, and if so, the proxy authentication DN
- And, most importantly, for debugging purposes, the reason for allowing or denying access. The possible reasons are listed in Table 7-6:
Note Write permissions for virtual attributes are not provided, nor is any associated logging evaluation information, because virtual attributes are not updatable.
For the actual log file format see Sun ONE Directory Server Reference Manual.
Tips on Using ACIs
The following tips can help to lower the administrative burden of managing your directory security model and improve directory performance.
Some of the following hints have already been described earlier in this chapter. They are included here to provide you with a complete list.
- Minimize the number of ACIs in your directory and use macro ACIs where possible.
Although Directory Server can evaluate over 50,000 ACIs, it is difficult to manage a large number of ACI statements, and, because ACIs are kept in memory, overly large numbers of ACIs can make inefficient use of your ACI memory. A large number of ACIs makes it hard for you to determine immediately the directory object available to particular clients. Reducing the number of ACIs in your directory tree, and preferring the use of macro ACIs where possible, will not only make it easier to manage your access control policy, but will also improve the efficiency of ACI memory usage.
- Balance allow and deny permissions.
Although the default rule is to deny access to any user who has not been specifically granted access, you might find that you can save on the number of ACIs by using one ACI allowing access close to the root of the tree, and a small number of deny ACIs close to the leaf entries. This scenario can avoid the use of multiple allow ACIs close to the leaf entries.
- Identify the smallest set of attributes on any given ACI.
This means that if you are allowing or restricting 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. If you want to allow a user to update just one or two of these attributes, then write your ACI so that it allows write access for just those few attributes. If, however, you want to allow a user to update all but one or two attributes, then create the ACI so that it allows write access for everything but a few named attributes.
- Use LDAP search filters cautiously.
Because search filters do not directly name the object that you are managing access for, their use can result in unexpected surprises, especially as your directory becomes more complex. If you are using search filters in ACIs, run an ldapsearch operation using the same filter to make sure you know what the results of the changes mean to your directory.
- Do not duplicate ACIs in differing parts of your directory tree.
Watch out for overlapping ACIs. For example, if you have an ACI at your directory root point that allows a group write access to the commonName and givenName attributes and another ACI that allows the same group write access for just the commonName attribute, then consider reworking your ACIs so that only one control grants the write access for the group.
As your directory grows more complicated, it becomes increasingly easy to accidentally overlap ACIs in this manner. By avoiding ACI overlap, you make your security management easier while potentially reducing the total number of ACIs contained in your directory.
- Name your ACIs.
While naming ACIs is optional, giving each ACI a short, meaningful name helps you to manage your security model, especially when examining your ACIs from the Directory Server console.
- Use standard attributes in user entries to determine access rights.
As far as possible, use information that is already part of standard user entries to define access rights. If you need to create special attributes, consider creating them as part of a role or Class of Service (CoS) definition. For more information on roles and CoS, refer to "Grouping Directory Entries and Managing Attributes".
- Group your ACIs as closely together as possible within your directory.
Try to limit ACI placement to your directory root point and to major directory branch points. Grouping ACIs helps you manage your total list of ACIs, and also helps you keep the total number of ACIs in your directory 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 perfectly acceptable to the server, it is confusing for a human administrator.
ACI Limitations
When creating an access control policy for your directory service, you need to be aware of the following restrictions:
- If your directory tree is distributed over several servers using the chaining feature, some restrictions apply to the keywords you can use in access control statements:
- ACIs that depend on group entries (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 role definitions (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.
However, you can do value matching of values stored in the target entry with values stored in the entry of the bind user (for example, using the userattr keyword). Access is evaluated normally even if the bind user does not have an entry on the server that holds the ACI.
For more information on how to chain access control evaluation, see Database Links and Access Control Evalutation in the Sun ONE Directory Server Administration Guide.
- Attributes generated by a CoS cannot be used in all ACI keywords. Specifically, you should not use attributes generated by CoS with the userattr keyword because the access control rule will not work. For more information on this keyword, refer to Chapter 4 "Designing the Directory Tree."
- Access control rules are always evaluated on the local server. Therefore, it is not necessary to specify the hostname or port number of the server in LDAP URLs used in ACI keywords. If you do, the LDAP URL will not be taken into account at all. For more information on LDAP URLs, see LDAP URLs in the Sun ONE Directory Server Reference Manual.
- 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.
When granting proxy rights, you cannot grant a user the right to proxy as the Directory Manager, nor can you grant proxy rights to the Directory Manager.
Securing Connections With SSL
After designing your authentication scheme for identified users and your access control scheme for protecting information, you must protect the integrity of the information in transit over the network between servers and client applications.
To provide secure communications over the network you can use both the LDAP and DSML-over-HTTP protocols over the Secure Sockets Layer (SSL). When you have configured and activated SSL, clients connect to a dedicated secure port where all communications are encrypted once the SSL connection is established. Directory Server also supports the Start Transport Layer Security (Start TLS) control, which allows the client to initiate an encrypted connection over the standard LDAP port.
By having separate ports, Directory Server supports SSL-secured connections and non-SSL connections simultaneously.
SSL uses encryption for privacy and hashing of checksums for data integrity. When establishing an SSL connection, the client application and Directory Server select the strongest encryption algorithm, called a cipher, in common to their configurations. Directory Server may use any of the following ciphers:
- DES - 56-bit block cipher
- 3DES ("triple-DES") - 156-bit block cipher
- RC2 - 128-bit block cipher (or 40-bit export cipher)
- RC4 - 128-bit stream cipher (or 40-bit export cipher)
Ciphers are combined with one of the following hashing algorithms:
- MD5
- SHA-1
For more information about ciphers and hashing algorithms, refer to "Other Security Resources".
After encryption of the connection has been established, the SSL protocol requires the server to send its certificate to the client. Using public-key cryptography, the client can determine the authenticity of the certificate and verify that it was issued by a certificate authority that the client trusts. By verifying the certificate, the client can prevent a man-in-the-middle impersonation of the server by a third party.
Now the connection is secure and the server is authenticated to the client. You may configure the server to further request authentication from the client. Directory Server supports certificate-based and SASL-based client authentication. These mechanisms are further described in "Selecting Appropriate Authentication Methods". Client authentication to the server provides the highest level of security by ensuring that no third party may intercept or interfere with the communication between the client and the server.
To enhance the performance for connections using the SSL protocol with certificate-based authentication, Directory Server 5.2 supports the Sun Crypto Accelerator Board. This board accelerates SSL key-related calculations, and may be useful in deployments where client applications repeatedly bind over SSL, search, and then unbind. SSL accelerator boards may not improve Directory Server performance when key-related calculations are not the performance bottleneck. In addition, SSL accelerator boards are most effective if the clients that are establishing connections are doing so from different machines. If a system establishes multiple SSL-based connections, it is likely that the SSL caching session will limit the number of RSA operations, which will in turn limit the benefit that the accelerator board may provide. For information on how to install and configure the Sun Crypto Accelerator Board see Appendix B, "Using a Sun Crypto Accelerator Board" in the Sun ONE Directory Server Installation and Tuning Guide.
For information about configuring and enabling SSL in both Directory Server and its clients, refer to Chapter 11, "Implementing Security" in the Sun ONE Directory Server Administration Guide.
Encrypting Attributes
This section presents the attribute encryption functionality new to Sun ONE Directory Server 5.2 and is divided into the following sub-sections:
- What is Attribute Encryption?
- Attribute Encryption Implementation
- Attribute Encryption and Performance
- Attribute Encryption Usage Considerations
What is Attribute Encryption?
Directory Server provides a variety of features to protect data at access level (during reads and writes to the directory), including simple password authentication, certificate-based authentication, Secure Sockets Layer (SSL), and proxy authorization. However, there is often an additional need for the data stored in database files, backup files, and ldif files to be protected. Consider a bank storing 4-digit PIN codes in the directory. If the database files were unprotected and were dumped, unauthorized users could have access to this sensitive information. The new attribute encryption feature prevents users from accessing this sensitive data while it is in storage.
Attribute encryption allows you to specify that certain attributes be stored in an encrypted form. It is configured at the database level, which means that once you decide to encrypt an attribute, that particular attribute will be encrypted for every entry in the database. Because attribute encryption occurs at an attribute level rather than an entry level, the only way to encrypt an entire entry is to encrypt all of its attributes.
When in storage, encrypted attributes are prefaced with a cipher tag that indicates the encryption algorithm used. An encrypted attribute using the DES encryption algorithm would appear as follows:
{CKM_DES_CBC}3hakc&jla+=snda%
In addition to protecting data while in storage, attribute encryption also allows you to export data to another database in encrypted format. However, because the purpose of attribute encryption is to protect sensitive data only when it is in storage or being exported, the encryption is always reversible. Encrypted attributes are therefore decrypted when returned via search requests. Figure 7-1 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 Directory Server attribute encryption feature supports a wide range of encryption algorithms, and ensures portability across different platforms. The required encryption algorithm is specified using the dsEncryptionAlgorithm attribute. See the Sun ONE Directory Server Reference Manual for further information regarding attribute encryption configuration attributes.
As an additional security measure, attribute encryption uses the private key of the server's SSL certificate to generate its own key, which is used to perform the encryption and decryption operations. This implies that, in order to be able to encrypt attributes, your server must be running over SSL. The SSL certificate and its private key are stored securely in the database in that they are protected by a password, and it is this key database password that is required to authenticate to the server. It is assumed that whoever has access to this key database password will be authorized to export decrypted data.
When importing data online with a view to encrypting it, you will already have provided the key database password to authenticate to the server, and will not be prompted a second time. If you are importing data offline, Directory Server will prompt you for the password before it allows you to encrypt the data you are importing. When decrypting your data (a more security sensitive operation), Directory Server automatically prompts you for the key database password, irrespective of whether your export operation be online or offline. This provides an additional security layer.
Attribute Encryption and Performance
While attribute encryption offers increased data security, it does incur certain performance costs. Bearing this in mind, you should think carefully about which attributes require encryption and encrypt only those attributes you consider to be particularly sensitive.
Because sensitive data can be accessed directly through index files, it is necessary to encrypt the index keys corresponding to the encrypted attributes, to ensure that the attributes are fully protected. Given that indexing already has an impact on Directory Server performance (without the added cost of encrypting index keys), it is advisable to configure attribute encryption before data is imported or added to the database for the first time. This procedure will ensure that encrypted attributes are indexed as such from the outset.
Attribute Encryption Usage Considerations
The following list of usage considerations outlines some of the items you must take into account when using the attribute encryption feature:
- As a general best practice when making attribute encryption configuration changes, we recommend that you export your data, make the configuration changes, and then import the newly configured data.
Adopting such a practice will ensure that all configuration changes are taken into account in their entirety, without any loss in functionality. Failing to adopt such a practice could result in some functionality loss and thus compromise the security of your data.
- Modifying attribute encryption configuration on an existing database can have a significant performance impact.
Imagine for example that you have a database instance with existing data. The database contains previously stored entries with a sensitive attribute called mySensitiveAttribute. The value of this attribute is stored in clear text, in the database and in the index files. If you decide at a later stage that you want to encrypt the mySensitiveAttribute attribute, all the data in the database instance must be exported and re-imported into the database to ensure that the server updates the database and index files taking the attribute encryption configuration into account. This will have a significant performance impact that could have been avoided had the mySensitiveAttribute attribute been encrypted from the beginning.
- When exporting data in decrypted format the export will be refused if an incorrect password is given.
As a security measure, the server prompts users for passwords if they want to export data in decrypted format, and refuses the decrypted export operation should users provide an incorrect password.
- Users can either enter passwords directly or enter a path to the file containing the password that has the same syntax as the SSL password file.
For more information concerning attribute encryption procedures, see "Encrypting Attribute Values" in Chapter 2 of the Sun ONE Directory Server Administration Guide.
- Algorithm changes are supported, but can result in lost indexing functionality, if they are not made correctly.
To change the algorithm used to encrypt your data, export your data, make the attribute encryption configuration changes, and then import your data, to avoid any functionality loss related to indexing. If you do not follow this procedure, the indexes created on the basis of the initial encryption algorithm will no longer function.
Because the encrypted attributes are prefaced with a cipher tag that indicates the encryption algorithm used, the internal server operations take care of importing the data. Therefore, Directory Server provides additional security as it enables you to export data in encrypted form before making the algorithm change.
- Changing the server's SSL certificate will result in you no longer being able to decrypt your encrypted data.
Because the server's SSL certificate is used by the attribute encryption feature to generate its own key, which is then used to perform the encryption and decryption operations, this certificate is required to be able to decrypt encrypted data. Changing the certificate without decrypting the data beforehand will result in you no longer being able to decrypt your data. Once again we recommend the best practice of exporting your data in decrypted format, changing your certificate and then re-importing your data.
- To transport data in encrypted format, that is, export and import it from one server instance to another, both server instances must have used the same certificate.
Grouping Entries Securely
This section deals with the security issues related to grouping entries securely and contains the following sections:
Using Roles Securely
Not every role is suitable for use within a security context. When creating a new role, consider how easily the role can be assigned to and removed from an entry. Sometimes it is appropriate for users to be able to easily add themselves to or remove themselves from a role. For example, if you had an interest group role called Mountain Biking, you would want interested users to add themselves or remove themselves easily.
However, in some security contexts it is inappropriate to have such open roles. For example, consider account inactivation roles. By default, account inactivation roles contain ACIs defined for their suffix (for more information about account inactivation, see the section on Inactivating Users and Roles in the Sun ONE Directory Server Administration Guide). When creating a role, the server administrator decides whether or not a user can assign themselves to or remove themselves from the role.
For example, user A possesses the managed role, MR. The MR role has been locked using account inactivation through the command line. This means that user A cannot bind to the server because the nsAccountLock attribute is computed as "true" for that user. However, suppose the user was already bound and noticed that he is now locked through the MR role. If there are no ACIs preventing him, the user can remove the nsRoleDN attribute from his entry and unlock himself.
To prevent users from removing the nsRoleDN attribute, you would need to apply ACIs. With filtered roles you would have to be sure to protect the part of the filter that would prevent the user from being able to relinquish the filtered role by modifying an attribute. The user should not be allowed to add, delete, or modify the attribute used by the filtered role, and in the same way if the value of the filter attribute is computed then all the attributes that can modify the value of the filter attribute should be protected too. As nested roles can be comprised of filtered and managed roles, the above points should be considered for each of the roles that comprise the nested role.
Using CoS Securely
Access control for reading applies to both the real and virtual attributes of an entry. A virtual attribute generated by the Class of Service mechanism is read just as a normal attribute and should be given read protection in the same way.
However, in order to make the CoS value secure, you must protect all of the sources of information it 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 should be controlled to protect the value that is generated from them.
The following sections describe the general principals for read and write protection of data in each of the CoS entries. The detailed procedure for defining individual access control instructions (ACIs) is described in "Managing Access Control" in the Sun ONE Directory Server Administration Guide.
Protecting the CoS Definition Entry
Even though the CoS definition entry does not contain the value of the generated attribute, it provides the information to find that value. Reading the CoS definition entry would reveal how to find the template entry containing the value, and writing to this entry would modify how the virtual attribute is generated.
You should therefore define both read and write access control on the CoS definition entries.
Protecting the CoS Template Entries
The CoS template entry contains the value of the generated CoS attribute. Therefore, as a minimum, the CoS attribute in the template should be protected for both reading and updating.
In the case of pointer CoS, there is a single template entry that should not be allowed to be renamed. In most cases, it is simplest to protect the entire template entry.
With classic CoS, all template entries have a common parent given in the definition entry. If only templates are stored in this parent entry, access control to the parent entry will protect the templates. However, if other entries beneath the parent require access, the template entries will need to be protected individually.
In the case of indirect CoS, the template may be any entry in the directory, including user entries that might still need to be accessed. Depending on your needs, you can either control access to the CoS attribute throughout the directory, or choose to ensure that the CoS attribute is secure in each entry used as a template.
Protecting the Target Entries of a CoS
All entries in the scope of a CoS definition, for which the virtual CoS attribute will be generated, also contribute to computing its value.
When the CoS attribute already exists in a target entry, by default, the CoS mechanism will not override this value. If you do not want this behavior, you should either define your CoS to override the target entry or protect the CoS attribute in all potential target entries. For information regarding these procedures see the Sun ONE Directory Server Administration Guide.
Both indirect and classic CoS also rely on a specifier attribute in the target entry. This attribute gives the DN or RDN of the template entry to use. You should protect this attribute either globally throughout the scope of the CoS or individually on each target entry where needed.
Protecting Other Dependencies
Finally, it is possible to define virtual CoS attributes in terms of other generated CoS attributes and roles. You will need to understand and protect these dependencies in order to guarantee the protection of your virtual CoS attribute.
For example, the CoS specifier attribute in a target entry could be nsRole, and therefore the role definition would also need to be protected. For more information, see "Grouping Entries Securely".
In general, any attribute or entry that is involved in the computation of the virtual attribute value should have both read and write access control. For this reason, complex dependencies should be well planned or simplified to reduce subsequent complexity of access control implementation. Keeping dependencies on other virtual attributes to a minimum also improves directory performance and reduces maintenance.
Securing Configuration Information
For the majority of deployments no additional access controls are required either for the root DSE entry (which is the entry that is returned for a base object search with a zero-length DN) or for the subtrees below cn=config, cn=monitor or cn=schema. The root DSE entry and these subtrees contain attributes that are automatically generated by Directory Server and used by LDAP clients to determine the capabilities and configuration of the directory server.
However, one of the root DSE entry attributes called namingContexts contains a list of the base DNs for each of the Directory Server databases. In addition to this list, these DNs are also stored in the mapping tree entries below cn=config and cn=monitor. Should you wish to hide the existence of one or more subtrees and protect your configuration information for security reasons, it will be necessary to place:
- An ACI attribute in the entry at the base of the subtree you wish to hide.
- An ACI in the root DSE entry on the namingContexts attribute.
- An ACI on the cn=config and cn=monitor subtrees.
Other Security Resources
For more information about designing a secure directory, take a look at the following:
- Sun ONE Middleware Developer Security Resources
http://developer.iplanet.com/tech/security/
- Understanding and Deploying LDAP Directory Services.
T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999.
- SecurityFocus.com
http://www.securityfocus.com/
- Computer Emergency Response Team (CERT) Coordination Center
http://www.cert.org/
- CERT Security Improvement Modules
http://www.cert.org/security-improvement/