Chapter 13 Basic Components and Concepts (Overview)

This chapter covers the following topics.

• LDAP Data Interchange Format (LDIF)

• Using Fully Qualified Domain Names

• Default Directory Information Tree (DIT)

• Default Schema

• Service Search Descriptors (SSDs) and Schema Mapping

• Client Profiles

• ldap_cachemgr Daemon

• LDAP Naming Services Security Model

LDAP Data Interchange Format (LDIF)

LDIF is a text-based format for describing directory service entities and their attributes. Using LDIF format you can move information from one directory to another with commands such as ldapadd and ldapmodify. The following are examples of LDIF format for each service. Use ldaplist(1) with the -l option to display the following information.

% ldaplist -l hosts myhost

hosts

dn: cn=myhost+ipHostNumber=7.7.7.115,ou=Hosts,dc=mydc,dc=mycom,dc=com
cn: myhost
iphostnumber: 7.7.7.115
objectclass: top
objectclass: device
objectclass: ipHost
description: host 1 - floor 1 - Lab a - building b

% ldaplist -l passwd user1

passwd

dn: uid=user1,ou=People,dc=mydc,dc=mycom,dc=com
uid: user1
cn: user1
userpassword: {crypt}duTx91g7PoNzE
uidnumber: 199995
gidnumber: 20
gecos: Joe Smith [New York]
homedirectory: /home/user1
loginshell: /bin/csh
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount

% ldaplist —l services name

services

dn: cn=name+ipServiceProtocol=udp,ou=Services,dc=mydc,dc=mycom,dc=com
cn: name
cn: nameserver
ipserviceprotocol: udp
ipserviceport: 42
objectclass: top
objectclass: ipService

% ldaplist —l group mygroup

group

dn: cn=mygroup,ou=Group,dc=mydc,dc=mycom,dc=com
cn: mygroup
gidnumber: 4441
memberuid: user1
memberuid: user2
memberuid: user3
userpassword: {crypt}duTx91g7PoNzE
objectclass: top
objectclass: posixGroup

% ldaplist —l netgroup mynetgroup

netgroup

cn=mynetgroup,ou=netgroup,dc=central,dc=sun,dc=com
objectclass=nisNetgroup
objectclass=top
cn=mynetgroup
nisnetgrouptriple=(user1..mydc.mycom.com,-,)
nisnetgrouptriple=(user1.,-,)
membernisnetgroup=mylab

% ldaplist —l networks 200.20.20.0

networks

dn: ipNetworkNumber=200.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com
cn: mynet-200-20-20
ipnetworknumber: 200.20.20.0
objectclass: top
objectclass: ipNetwork
description: my Lab Network
ipnetmasknumber: 255.255.255.0

% ldaplist —l netmasks 201.20.20.0

netmasks

dn: ipNetworkNumber=201.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com
cn: net-201
ipnetworknumber: 201.20.20.0
objectclass: top
objectclass: ipNetwork
description: my net 201
ipnetmasknumber: 255.255.255.0

% ldaplist —l rpc ypserv

rpc

dn: cn=ypserv,ou=Rpc,dc=mydc,dc=mycom,dc=com
cn: ypserv
cn: ypprog
oncrpcnumber: 100004
objectclass: top
objectclass: oncRpc

% ldaplist —l protocols tcp

protocols

dn: cn=tcp,ou=Protocols,dc=mydc,dc=mycom,dc=com
cn: tcp
ipprotocolnumber: 6
description: transmission control protocol
objectclass: top
objectclass: ipProtocol

% ldaplist —l bootparams myhost

bootparams

dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com
bootparameter: root=boothost:/export/a/b/c/d/e
objectclass: top
objectclass: device
objectclass: bootableDevice
cn: myhost

% ldaplist —l ethers myhost

ethers

dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com
macaddress: 8:1:21:71:31:c1
objectclass: top
objectclass: device
objectclass: ieee802Device
cn: myhost

% ldaplist —l publickey myhost

publickey

dn: cn=myhost+ipHostNumber=200.20.20.99,ou=Hosts,dc=mydc,dc=mycom,dc=com
cn: myhost
iphostnumber: 200.20.20.99
description: Joe Smith
nispublickey: 9cc01614d929848849add28d090acdaa1c78270aeec969c9
nissecretkey: 9999999998769c999c39e7a6ed4e7afd687d4b99908b4de99
objectclass: top
objectclass: NisKeyObject
objectclass: device
objectclass: ipHost

% ldaplist —l aliases myname

aliases

dn: mail=myname,ou=aliases,dc=mydc,dc=mycom,dc=com
cn: myname
mail: myname
objectclass: top
objectclass: mailgroup
mgrprfc822mailmember: my.name

Using Fully Qualified Domain Names

Unlike NIS or NIS+ clients, an LDAP client always returns a fully qualified domain name (FQDN) for a host name. The LDAP FQDN is similar to the FQDN returned by DNS. For example, suppose your domain name is the following:

west.example.net

Both gethostbyname() and getnameinfo() return the FQDN version when looking up the host name server:

server.west.example.net

Also, if you use interface-specific aliases such as server-#, a long list of fully qualified host names are returned. If you are using host names to share file systems or have other such checks, you must account for the checks. For example, if you assume non-FQDNs for local hosts and FQDNs only for remote DNS-resolved hosts, you must account for the difference. If you set up LDAP with a different domain name from DNS, the same host might end up with two different FQDNs, depending on the lookup source.

Default Directory Information Tree (DIT)

By default, Solaris LDAP clients access the information assuming that the DIT has a given structure. For each domain supported by the LDAP server, there is a subtree with an assumed structure. This default structure, however, can be overridden by specifying Service Search Descriptors (SSDs). For a given domain, the default DIT will have a base container that holds a number of well known containers that hold entries for a specific information type. See the following table for the names of these subtrees. (This information can be found in RFC 2307 and others.)

Default Schema

Schemas are definitions describing what types of information can be stored as entries in an LDAP directory. To support LDAP naming clients, the directory server's schema might need to be extended. Detailed information about IETF and Solaris specific schemas is included in Chapter 18, LDAP General Reference (Reference). The various RFCs can also be accessed on the IETF Web site http://www.ietf.org.

Service Search Descriptors (SSDs) and Schema Mapping

If you use schema mapping, you must do so in a very careful and consistent manner. Make sure the syntax of the mapped attribute is consistent with the attribute it is mapped to. In other words, make sure that single-valued attributes map to single-valued attributes, that the attribute syntaxes are in agreement, and that mapped object classes have the correct mandatory (possibly mapped) attributes.

As previously discussed, LDAP naming services expect, by default, the DIT to be structured in a certain way. If you want, you can instruct the Solaris LDAP naming service to search in other locations than the default locations in the DIT. Additionally, you can specify that different attributes and object classes be used in place of those specified by the default schema. For a list of default filters, see Default Filters Used by LDAP Naming Services.

SSDs

The serviceSearchDescriptor attribute defines how and where an LDAP naming service client should search for information for a particular service. The serviceSearchDescriptor contains a service name, followed by one or more semicolon-separated base-scope-filter triples. These base-scope-filter triples are used to define searches only for the specific service and are searched in order. If multiple base-scope-filters are specified for a given service, then when that service looks for a particular entry, it will search in each base with the specified scope and filter.

The default location is not searched for a service (database) with an SSD unless it is included in the SSD. Unpredictable behavior will result if multiple SSDs are given for a service.

In the following example, the Solaris LDAP naming service client performs a one-level search in ou=west,dc=example,dc=com followed by a one-level search in ou=east,dc=example,dc=com for the passwd service. To look up the passwd data for a user's username, the default LDAP filter (&(objectClass=posixAccount)(uid=username)) is used for each BaseDN.

serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east,
dc=example,dc=com 

In the following example, the Solaris LDAP naming service client would perform a subtree search in ou=west,dc=example,dc=com for the passwd service. To look up the passwd data for user username, the subtree ou=west,dc=example,dc=com would be searched with the LDAP filter (&(fulltimeEmployee=TRUE)(uid=username)).

serviceSearchDescriptor: passwd:ou=west,dc=example,
dc=com?sub?fulltimeEmployee=TRUE

It is also possible to associate multiple containers with a particular service type.

For example, the following service search descriptor specifies that the three containers, ou=myuser,dc=example,dc=com, ou=newuser,dc=example,dc=com, and ou=extuser,dc=example,dc=com are searched for the password entries. Note that a trailing ',' implies that the defaultSearchBase is appended to the relative base in the SSD.

defaultSearchBase: dc=example,dc=com
serviceSearchDescriptor: \
passwd:ou=myuser;ou=newuser,ou=extuser,dc=example,dc=com

Attribute Map

The Solaris LDAP naming service allows one or more attribute names to be remapped for any of its services. (The Solaris LDAP client uses the well-known attributes documented in Chapter 18, LDAP General Reference (Reference).) If you map an attribute, you must be sure that the attribute has the same meaning and syntax as the original attribute. Note that mapping the userPassword attribute might cause problems.

There are a couple of reasons you might want to use schema mappings.

• You want to map attributes in an existing directory server

• If you have user names that differ only in case, you must map the uid attribute, which ignores case, to an attribute that does not ignore case

The format for this attribute is service:attribute-name=mapped-attribute-name.

If you want to map more than one attribute for a given service, you can define multiple attributeMap attributes.

In the following example, the employeeName and home attributes would be used whenever the uid and homeDirectory attributes would be used for the passwd service.

attributeMap: passwd:uid=employeeName
attributeMap: passwd:homeDirectory=home

There exists one special case where you can map the passwd service's gecos attribute to several attributes. The following is an example.

attributemap: gecos=cn sn title

This maps the gecos values to a space separated list of the cn, sn, and title attribute values.

objectClass Map

The Solaris LDAP naming service allows object classes to be remapped for any of its services. If you want to map more than one object class for a given service, you can define multiple objectclassMap attributes. In the following example, the myUnixAccount object class is used whenever the posixAccount object class is used.

objectclassMap: passwd:posixAccount=myUnixAccount

Client Profiles

To simplify Solaris client setup, and avoid having to reenter the same information for each and every client, create a single client profile on the directory server. This way, a single profile defines the configuration for all clients configured to use it. Any subsequent change to the profile attributes is propagated to the clients at a rate defined by the refresh interval.

These client profiles should be stored in a well-known location on the LDAP server. The root DN for the given domain must have an object class of nisDomainObject and a nisDomain attribute containing the client's domain. All profiles are located in the ou=profile container relative to this container. These profiles should be readable anonymously.

Client Profile Attributes

The following table shows the Solaris LDAP client's profile attributes, which can be set automatically when you run idsconfig(1M). See Initializing a Client Manually for information on how to set a client profile manually.

Local Client Attributes

The following table lists the client attributes that can be set locally using ldapclient(1M).

If the BaseDN in an SSD contains a trailing comma, it is treated as a relative value of the defaultSearchBase. The values of the defaultSearchBase are appended to the BaseDN before a search is performed.

ldap_cachemgr Daemon

ldap_cachemgr(1M) is a daemon that runs on LDAP client machines. It performs the following key functions.

• Gains access to the configuration files, running as root

• Refreshes the client configuration information stored in the profiles on the server and pulls this data from the clients

• Maintains a sorted list of active LDAP servers to use

• Improves lookup efficiency by caching some common lookup requests submitted by various clients

• Improves the efficiency of host lookups

ldap_cachemgr must be running at all times for LDAP naming services to work.

Refer to the ldap_cachemgr(1M) man page for detailed information.

LDAP Naming Services Security Model

Introduction

Solaris LDAP naming services use the LDAP repository as a source of both a naming service and an authentication service. This section discusses the concepts of client identity, authentication methods, pam_ldap(5) and pam_unix(5) modules, and password management.

To access the information in the LDAP repository, clients can first establish identity with the directory server. This identity can be either anonymous or as an object recognized by the LDAP server. Based on the client's identity and the server's access control information (ACI), the LDAP server will allow the client to read or write directory information. For more information on ACIs, consult the Sun ONE Directory Server 5.1 Administrator's Guide.

If the client is connecting as anything other than anonymous for any given request, the client must prove its identity to the server using an authentication method supported by both the client and the server. Once the client has established its identity, it can then make the various LDAP requests.

There is a distinction between how the naming service and the authentication service (pam_ldap) accesses the directory. The naming service reads various entries and their attributes from the directory based on predefined identity. The authentication service (pam_ldap(5)) establishes whether the user has entered the correct password by using that user's name and password to authenticate to the LDAP server.

Transport Layer Security (TLS)

TLS can be used to secure communication between an LDAP client and the directory server, providing both privacy and data integrity. The TLS protocol is a superset of the Secure Sockets Layer (SSL) protocol. Solaris LDAP naming services support TLS connections. Be aware that using SSL will add load to the directory server and the client.

You will need to set up your directory server for SSL. See the Sun ONE Directory Server 5.1 Administrator's Guide for more information on setting up Sun ONE Directory Server 5.1 for SSL. You will also need to set up your LDAP client for SSL.

In order to use TLS for Solaris LDAP naming services, the directory server must use the default ports, 389 and 636, for LDAP and SSL, respectively. If your directory server does not use these ports, you cannot use TLS at this time.

See Setting Up TLS Security for more information.

Assigning Client Credential Levels

LDAP naming services clients authenticate to the LDAP server according to a client's credential level. LDAP clients can be assigned three possible credential levels with which to authenticate to a directory server.

• anonymous

• proxy

• proxy anonymous

Anonymous

If you use anonymous access, you can access only the data that is available to everyone. Also, you should consider the security implications. Allowing anonymous access for certain parts of the directory implies that anyone with access to the directory will have read access.. If you are using an anonymous credential level, you will need to allow read access to all the LDAP naming entries and attributes.

Allowing anonymous write to a directory should never be done, as anyone could change information in the DIT to which they have write access, including another user's password, or their own identity.

Sun ONE Directory Server 5.1 allows you to restrict access based on IP addresses, DNS name, authentication method, and time-of-day. You might want to limit access with further restrictions. See “Managing Access Control” in the Sun ONE Directory Server 5.1 Administrator's Guide for more information.

Proxy

The client authenticates or binds to the directory using a proxy account. This proxy account can be any entry that is allowed to bind to the directory. This proxy account needs sufficient access to perform the naming service functions on the LDAP server. You will need to configure the proxyDN and proxyPassword on every client using the proxy credential level. The encrypted proxyPassword will be stored locally on the client. You can set up different proxies for different groups of clients. For example, you can configure a proxy for all the sales clients to access both the company-wide-accessible and sales directories, while preventing sales clients from accessing human resource directories with payroll information. Or, in the most extreme cases, you can either assign different proxies to each client or assign just one proxy to all clients. A typical LDAP deployment would probably lie between the two extremes. Consider the choices carefully. Too few proxy agents might limit your ability to control user access to resources. However, having too many proxies complicates the setup and maintenance of the system. You need to grant the appropriate rights to the proxy user. This will vary depending on your environment. See Credential Storage for information on how to determine which authentication method makes the most sense for your configuration.

If the password changes for a proxy user, you need to update it on every client that uses that proxy user. If you use password aging on LDAP accounts, be sure to turn it off for proxy users.

Be aware that the proxy credential level applies to all users and processes on any given machine. If two users need to use different naming policies, they must use different machines.

In addition, if clients are using a proxy credential to authenticate, the proxyDN must have the same proxyPassword on all of the servers.

proxy anonymous

proxy anonymous is a multi-valued entry, in that more than one credential level is defined. A client assigned the proxy anonymous level will first attempt to authenticate with its proxy identity. If the client is unable to authenticate as the proxy user for whatever reason (user lockout, password expired, for example), then the client will use anonymous access. This might lead to a different level of service, depending on how the directory is configured.

Credential Storage

If you configure a client to use a proxy identity, the client saves its proxyDN and proxyPassword in /var/ldap/ldap_client_cred. For the sake of increased security, this file is restricted to root access only, and the value of proxyPassword is encrypted. While past LDAP implementations have stored proxy credentials in a client's profile, Solaris 9 LDAP naming services do not. Any proxy credentials set using ldapclient during initialization are stored locally. This results in improved security surrounding a proxy's DN and password information. See Chapter 16, Setting Up Clients (Tasks) for more information on setting up client profiles.

Choosing Authentication Methods

When you assign the proxy or proxy-anonymous credential level to a client, you also need to select a method by which the proxy authenticates to the directory server. By default, the authentication method is none, which implies anonymous access. The authentication method may also have a transport security option associated with it.

The authentication method, like the credential level, may be multi-valued. For example, in the client profile you could specify that the client first tries to bind using the simple method secured by TLS. If unsuccessful, the client would try to bind with the sasl/digest-MD5 method. The authenticationMethod would then be tls:simple;sasl/digest-MD5.

LDAP naming services support some Simple Authentication and Security Layer (SASL) mechanisms. These mechanisms allow for a secure password exchange without requiring TLS. However, these mechanisms do not provide data integrity or privacy. See RFC 2222 for information on SASL.

The following authentication mechanisms are supported.

• none

  The client does not authenticate to the directory. This is equivalent to the anonymous credential level.

• simple

  If the client machine uses the simple authentication method, it binds to the server by sending the user's password in the clear. The password is thus subject to snooping unless the session is protected by ipsec(7). The primary advantages of using the simple authentication method are that all directory servers support it and that it is easy to set up.

• sasl/digest-MD5

  The client's password is protected during authentication, but the session is not encrypted. Some directory servers, including Sun ONE Directory Server 5.1, also support the sasl/digest-MD5 authentication method. The primary advantage of digest-MD5 is that the password does not go over the wire in the clear during authentication and therefore is more secure than the simple authentication method. See RFC 2831 for information on digest-MD5. digest-MD5 is considered an improvement over cram-MD5 for its improved security.

  When using sasl/digest-MD5, the authentication is secure, but the session is not protected.

  ---

  Note –

  If you are using Sun ONE Directory Server 5.1. the password must be stored in the clear in the directory.

  ---

• sasl/cram-MD5

  In this case, the LDAP session is not encrypted, but the client's password is protected during authentication, as authentication is performed using sasl/cram-MD5.

  See RFC 2195 for information on the cram-MD5 authentication method. cram-MD5 is only supported by some directory servers. For instance, Sun ONE Directory Server 5.1 does not support cram-MD5.

• tls:simple

  The client binds using the simple method and the session is encrypted. The password is protected.

• tls:sasl/cram-MD5

  The LDAP session is encrypted and the client authenticates to the directory server using sasl/cram-MD5.

• tls:sasl/digest-MD5

  The LDAP session is encrypted and the client authenticates to the directory server using sasl/digest-MD5.

Sun ONE Directory Server 5.1 requires passwords to be stored in the clear in order to use digest-MD5. If the authentication method is set to sasl/digest-MD5 or tls:sasl/digest-MD5, then the passwords for the proxy user will need to be stored in the clear. Be especially careful that the userPassword attribute has the proper ACIs if it is stored in the clear, so that it is not readable.

The following table summarizes the various authentication methods and their respective characteristics.

Authentication and Services

The authentication method can be specified for a given service in the serviceAuthenticationMethod attribute. The following services currently support this.

• passwd-cmd

  This service is used bypasswd(1) to change the login password and password attributes.

• keyserv

  This service is used by thechkey(1) and newkey(1M) utilities to create and change a user's Diffie-Hellman key pair.

• pam_ldap

  This service is used for authenticating users with pam_ldap(5).

  pam_ldap supports account management.

If the service does not have a serviceAuthenticationMethod set, it will default to the value of the authenticationMethod attribute.

The following example shows a section of a client profile in which the users will use sasl/digest-MD5 to authenticate to the directory server, but will use an SSL session to change their password.

serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5
serviceAuthenticationMethod=passwd-cmd:tls:simple

Pluggable Authentication Methods

By using the PAM framework, you can choose among several authentication services. You can use either pam_unix(5) or pam_ldap(5) in conjunction with LDAP.

Because of its increased flexibility, support of stronger authentication methods, and ability to use account management, the use of pam_ldap is recommended.

pam_unix(5)

If you have not changed the pam.conf(4) file, pam_unix(5) is enabled by default. pam_unix(5) follows the traditional model of UNIX authentication, which means the following:

1. The client retrieves the user's encrypted password from the name service.

2. The user is prompted for his password.

3. The user's password is encrypted.

4. The client compares the two encrypted passwords to determine whether the user should be authenticated.

• The password must be stored in UNIX crypt format and not in any other encryption methods, including clear.

• The userPassword attribute must be readable by the name service.

  For example, if you set the credential level to anonymous, then anyone must be able to read the userPassword attribute. Similarly, If you set the credential level to proxy, then the proxy user must be able to read the userPassword attribute.

pam_unix(5) is not compatible with the sasl authentication method digest-MD5, since Sun ONE Directory Server 5.1 requires passwords to be stored in the clear in order to use digest-MD5. pam_unix requires the password be stored in crypt format.

pam_ldap(5)

When using pam_ldap(5), the user binds to the LDAP server using the authentication method defined in pam_ldap's serviceAuthenticationMethod parameter, if one exists. Otherwise, authenticationMethod is used by default.

If pam_ldap(5) is able to bind to the server with the user's identity and supplied password, it authenticates the user.

pam_ldap(5) does not read the userPassword attribute. Therefore, there is no need to grant access to read the userPassword attribute unless there are other clients using pam_unix(5). pam_ldap(5) does not support the none authentication method. Thus, you must define the serviceAuthenticationMethod or the authenticationMethod attributes so clients can use pam_ldap(5).

If the simple authentication method is used, the userPassword attribute can be read on the wire by third parties.

See Example pam.conf File for pam_ldap.

The following table summarizes the main differences between pam_unix and pam_ldap.

PAM and Changing Passwords

Use passwd(1) to change a password. In order to change the password, the userPassword attribute must be writeable by the user. Remember that the serviceAuthenticationMethod for passwd-cmd will override the authenticationMethod for this operation. Depending on the authentication used, the current password might be un-encrypted on the wire.

In the case of pam_unix(5), the new userPassword attribute is encrypted using UNIX crypt format and tagged before being written to LDAP. Therefore, the new password is encrypted on the wire, regardless of the authentication method used to bind to the server.

For pam_ldap, when a password is changed, the new password is un-encrypted. Therefore, to insure privacy, use TLS. If TLS is not used, the new userPassword will be subject to snooping.

When setting the password with pam_ldap(5) with Sun ONE Directory Server 5.1, the password is encrypted using the passwordStrorageScheme (as it is untagged). See “User Account Management” in the Sun ONE Directory Server 5.1 Administrator's Guide for additional information about the passwordStorageScheme attribute.

You need to consider the following when setting the passwordStorageScheme attribute. If a NIS, NIS+, or another client using pam_unix is using LDAP as a repository, then passwordStorageScheme needs to be crypt. Also, if using pam_ldap with sasl/digest-MD5 with Sun ONE Directory Server 5.1, passwordStorageScheme must be set to clear. See the following section for more information.

Using Sun ONE Directory Server 5.1 With digest-MD5

If you are using the Sun ONE Directory Server with digest-MD5, a user who changes her password will not be able to login with the new password if the change fails for any password management reason.

For example, is password history is enabled on the server and the user attempts to change her password to a previously used password, pam_ldap fails to change the password due to the constraint violations (a previously used password in this case). pam ignores pam_ldap and falls through to pam_unix. As a result, the password is stored in crypt format and not in the clear. Consequently, the next time the user attempts to login with her new password, her login will fail.

To avoid having pam_ldap “fall through” to pam_unix, use the following configuration on all clients' pam.conf files:

  other   password required        pam_dhkeys.so.1
  other   password requisite       pam_authtok_get.so.1
  other   password requisite       pam_authtok_check.so.1
  other   password binding         pam_authtok_store.so.1 server_policy

Note that there is no pam_ldap.so.1 in the above configuration. The server_policy specifies that pam_authtok_store.so.1 should always send clear text for LDAP accounts to the directory server and allows the server to store the password according to its own password encryption scheme. However, when using the above configuration, you also need the matching authentication configurations. For example, use the following configuration:

login     auth     binding    pam_unix_auth.so.1 server_policy
login     auth     required   pam_ldap.so.1

and

passwd     auth    binding     pam_passwd_auth.so.1    server_policy
passwd     auth    required    pam_ldap.so.1

Make sure that every client in the same directory naming domain uses the configuration above. If even one client is using a different pam.conf, if a user changes her password on that system, login authentication will fail on the rest of the clients.

Password Management

LDAP naming services take advantage of the password and account lockout policy support in Sun ONE Directory Server 5.1. You can configure pam_ldap(5) to support user account management. passwd(1) enforces password syntax rules set by the Sun ONE Directory Server password policy, when used with the proper PAM configuration.

The following password management features are supported through pam_ldap(5). These features depend on Sun ONE Directory Server 5.1's password and account lockout policy configuration. You can enable as many or as few of the features as you want.

• Password aging and expiration notification

  Users must change their passwords according to a schedule. A password expires if it is not changed within the time configured. An expired password causes user authentication to fail.

  Users see a warning message whenever they log in within the expiration warning period. The message specifies the number of hours or days until the password expires.

• Password syntax checking

  New passwords must meet the minimum password length requirements. In addition, a password cannot match the value of the uid, cn, sn, or mail attributes in the user's directory entry.

• Password in history checking

  Users cannot reuse passwords. If a user attempts to change the password to one that was previously used, passwd(1) fails. LDAP administrators can configure the number of passwords kept in the server's history list.

• User account lockout

  A user account can be locked out after a given number of repeated authentication failures. A user can also be locked out if his account is inactivated by an administrator. Authentication will continue to fail until the account lockout time is passed or the administrator reactivates the account.

The preceding password management features only work with Sun ONE Directory Server 5.1 bundled with Solaris 9. For information about configuring the password and account lockout policy on the server, see the “User Account Management” chapter in the Sun ONE Directory Server 5.1 Administrator's Guide. Also see Example pam_conf file for pam_ldap Configured for Password Management. Do not enable password management for proxy accounts.

Before configuring the password and account lockout policy on Sun ONE Directory Server 5.1, make sure all hosts use the “newest” LDAP client with pam_ldap password management.

In addition, make sure the clients have a properly configured pam.conf(4) file. Otherwise, LDAP naming services will not work when proxy or user passwords expire.