Working With Oracle® Solaris 11.2 Directory and Naming Services: LDAP

Exit Print View

Updated: July 2014
 
 

Client Credential Levels

The LDAP server authenticates LDAP clients according to the client credential level. LDAP clients can be assigned one of the following credential levels:

anonymous

With an anonymous credential level, you can access only the data that is available to everyone. No LDAP BIND operation occurs.

An anonymous credential level is a high security risk. Any client can change information in the DIT to which the client has write access, including another user's password or their own identity. Further, the anonymous level enables all clients to have read access to all the LDAP naming entries and attributes.


Note -  Oracle Directory Server Enterprise Edition enables you to restrict access based on IP addresses, DNS name, authentication method, and time-of-day. Thus, you can implement security measures. For more information, see “Managing Access Control” in the Administration Guide for the version of Oracle Directory Server Enterprise Edition that you are using.
proxy

With a proxy credential level, the client binds to a single shared set of LDAP bind credentials. The shared set is also called a proxy account. The proxy account can be any entry that is allowed to bind to the directory. The account requires sufficient access to perform the naming service functions on the LDAP server.

The proxy account is a shared-per-system resource, which means that users, including the root user, who are logged into a system using proxy access see the same information. You must configure the proxyDN and proxyPassword attributes on every client system that use the proxy credential level. Further, the proxyDN must have the same proxyPassword on all of the servers.

The encrypted proxyPassword is stored locally on the client. If the password changes for a proxy user, you must update the password on every client system that uses that proxy user. Also, if you use password aging on LDAP accounts, make sure to exempt proxy users.

You can set up different proxies for different groups of clients. For example, you can configure a proxy that limits all the sales clients to access only the company-wide accessible directories and sales directories. Access to human resource directories with payroll information are forbidden. Or, in the most extreme cases, you can either assign different proxies to each client or assign just one proxy to all clients.

If you plan to set up multiple proxies for different clients, consider the choices carefully. Too few proxy agents can limit your ability to control user access to resources. However, too many proxies complicate the setup and maintenance of the system. You need to grant the appropriate rights to the proxy user, depending on your environment. See Credential Storage for LDAP Clients for information on how to determine which authentication method makes the most sense for your configuration.

The proxy credential level applies to all users and processes on any specific system. Users that need to use different naming policies must log in to different systems, or use the per-user authentication model.

proxy anonymous

The proxy anonymous credential level is a multi-valued entry, where more than one credential level is defined. With this level, a client assigned first attempts to be authenticated by using its proxy identity. If the authentication fails, for example because of user lockout or expired password, then the client uses anonymous access. Depending on how the directory is configured, different credential levels might be associated with different levels of service.

self

The self credential level is also known as the per-user mode. This mode uses the Kerberos identity, called the principal, to perform a lookup for each system or user for authentication. With per-user authentication, the system administrator can use access control instructions (ACI's), access control lists (ACL's), roles, groups or other directory access control mechanisms to grant or deny access to specific naming service data for specific users or systems.

To use the per-user authentication model, the following are required:

  • Deployment of the Kerberos single sign-on service

  • Support for the SASL and the SASL/GSSAPI authentication mechanism in one or more directory servers

  • Configuration of DNS, which Kerberos uses together with files to perform host name lookups

  • Enabling of the nscd daemon