The LDAP server authenticates LDAP clients according to the client credential level. You can assign any one of the following credential levels for LDAP clients:
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 LDAP naming entries and attributes.
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 uses the proxy credential level. Further, the proxyDN must have the same proxyPassword on all of the LDAP 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. For more information about how to determine which authentication method to use, see Storing Credential for LDAP Clients.
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 first attempts to be authenticated by using its proxy identity. If the authentication fails 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 (ACIs), access control lists (ACLs), 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 configurations 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
If the enableShadowUpdate switch is set to true on the client, administrator credentials are used to update the shadow data. Shadow data is stored in the shadowAccount object class on the directory server. Administrator credentials are defined by the values of the adminDN and adminPassword attributes, as described in Defining LDAP Local Client Attributes.
Administrator credentials have properties similar to proxy credentials. However, for administrator credentials, the user must have all privileges for the zone or have an effective UID of root to read or update the shadow data.
You can assign administrator credentials to any entry that is allowed to bind to the directory. However, do not use the same directory manager identity (cn=Directory Manager) of the LDAP server.
An entry with administrator credentials must have sufficient access to read and write the shadow data to the directory. The entry is a shared-per-system resource. Therefore, you must configure the adminDN and adminPassword attributes on every client.
The encrypted adminPassword is stored locally on the client. The admin password uses the same authentication methods that are configured for the client. All users and processes on a specific system uses the administrator credentials to read and update the shadow data.
In the LDAP implementation, proxy credentials that are set during initialization are stored in the SMF repository instead of a client’s profile. This implementation improves security surrounding a proxy’s distinguished name (DN) and password information.
The SMF repository is svc:/network/ldap/client. It stores proxy information of clients that use a proxy identity. Likewise, shadow data updates of clients whose credential level is not self are also saved to this repository.
For clients that use per-user authentication, the Kerberos identity and Kerberos ticket information for each principal is used during authentication. The directory server maps the Kerberos principal to a DN and the Kerberos credentials are used to authenticate to that DN. The directory server can use its access control mechanisms to allow or deny access to naming service data as necessary.
In this environment, Kerberos ticket information is used to authenticate to the directory server. The system does not store authentication DNs or passwords. Therefore, setting the adminDN and adminPassword attributes is unnecessary when you initialize the client with the ldapclient command.