Security Model

To access the information stored in the directory, clients must authenticate to the directory first. Once authenticated, and depending on the authorization information stored in the directory in the form of Access Control Information the client will have access to part or all of the information available in the directory. In this section, the concepts of client identity, authentication methods, and finally PAM modules will be discussed. For more information on ACI, please consult the iPlanet Directory Server Administrator's Guide.

Authentication Identity

LDAP name services could be configured to use one of two possible identities for authenticating clients to the directory: anonymous, and proxy agent.

• Anonymous

  Authentication is all about establishing identity, and anonymous is considered a special case of identity. Obviously anonymous does not provide any level of security and means that all unauthenticated connections to the directory will be able to browse and read all Network Information records (including password and shadow information). However even with the absence of security it might be an appropriate choice for some installations and it is allowed.

• Proxy Agent

  In case of proxy agent identity, the client authenticates to the directory using a proxy account in the directory. This proxy account can be any entry that is allowed to bind to the directory (in the iPlanet Directory Server, this translates to any entry which has a userPassword attribute).

  Access control to parts of the information in the directory can be achieved by setting appropriate ACI's restricting or granting various rights based on the proxy's identity. Furthermore, since there is no relationship between the number of proxy agents and clients, you can have any combination of the two. For example, in one extreme a deployment could have one proxy agent for all its clients and grant the proxy read access to all parts of the DIT that contain naming information. On the other hand one could setup a server where each client authenticates using a different proxy agent and can set the ACI to restrict access per client. These examples demonstrate two extreme cases of using proxy agents; however, a typical deployment lies somewhere in between the two extremes. The granularity level of this is a choice for the directory architect, and must be considered carefully. Too few proxy agents might limit the ability of the system administrator to control access to resources, but too many agents complicates the setup and maintenance of the system as it would require a large number of profiles as well.

  ---

  Note –

  Because client configuration is stored in profiles, there is a direct relationship between the number of proxies used and profiles that need to be defined.

  ---

Authentication Method

When a proxy agent is used the system administrator also needs to choose an authentication method for that identity to authenticate to the directory. Currently the supported mechanisms by Solaris 8 clients are SIMPLE, and CRAM-MD5.

• SIMPLE

  If SIMPLE is chosen, the client authenticates to an LDAP server by sending a simple bind request to the server. It is worth noting that with this authentication method, the password is transmitted in the clear and is subject to snooping. The primary advantage of using SIMPLE is that it is the required authentication method as defined in the LDAP standard, and all directory servers support it.

• CRAM-MD5

  Some directory servers also support Challenge Response Authentication Mechanism (CRAM-MD5) through Simple Authentication and Security Layer (SASL). The primary advantage of CRAM-MD5 is that the password does not go over the wire in the clear during authentication and therefore is more secure than SIMPLE. See RFC 2195 for information on CRAM-MD5. See RFC 2222 for information on SASL.

Currently the iPlanet Directory Server version 4.11 does not support the CRAM-MD5 method.

Pluggable Authentication Module (PAM)

PAM provides a way for applications to remain independent of authentication scheme used in the Solaris Operating Environment. By using the PAM layer, applications can perform authentication without worrying about what authentication method is defined by the system administrator for the given client. To use LDAP naming service, one of two pam modules can be configured in pam.conf: pam_unix(5) and pam_ldap(5).

• pam_unix

  When pam_unix is used, the traditional model of UNIX authentication is followed which means that the encrypted password of the user is retrieved from the directory to the local machine, the user is prompted for his password, user's password is encrypted, and finally the two encrypted passwords are compared to decide if the user should be authenticated or not. If clients using LDAP are configured with this module, the userPassword attribute must be readable by the identity that the client is using (anonymous or the configured proxy agent). Additionally, there are two more restrictions when using pam_unix:

  1. The password must be stored in an attribute called userPassword.

  2. The password must be stored in UNIX crypt format (not clear text or encrypted by other encryption methods).

• pam_ldap

  Since the traditional method of authentication used by pam_unix is not necessarily the best option when deploying LDAP directories, a new PAM module was added in Solaris 8 which authenticates users directly to the directory instead. This will allow Solaris clients to work with newer and more advanced authentication methods that the directory server might support. By definition, clients using pam_ldap do not require read access to the password attribute, and they do not need the password to be stored in any specific format in the directory.

  As an added benefit, because pam_ldap authenticates users directly to the directory server, user level access controls can be put in place to control an individuals' authentication using ACI's.

  As with using pam_unix, use the passwd command to change a password.