This chapter covers the following topics.
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 |
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.
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.)
Table 13–1 DIT Default Locations
Default Container |
Information Type |
---|---|
ou=Ethers |
bootparams(4), ethers(4) |
ou=Group |
group(4) |
ou=Hosts |
hosts(4), ipnodes(4), publickey for hosts |
ou=Aliases |
aliases(4) |
ou=Netgroup |
netgroup(4) |
ou=Networks |
networks(4), netmasks(4) |
ou=People |
passwd(1), shadow(4), user_attr(4), audit_user(4), publickey for users |
ou=printers |
printers(4) |
ou=Protocols |
protocols(4) |
ou=Rpc |
rpc(4) |
ou=Services |
services(4) |
ou=SolarisAuthAttr |
auth_attr(4) |
ou=SolarisProfAttr |
prof_attr(4), exec_attr(4) |
ou=projects |
project |
automountMap=auto_* |
auto_* |
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.
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.
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 |
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.
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 |
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.
The following table shows the Solaris LDAP client's profile attributes, which can be set automatically when you run idsconfig. See Initializing a Client Manually and the idsconfig(1M) man page for information on how to set a client profile manually.
Table 13–2 Client Profile Attributes
Attribute |
Description |
---|---|
cn |
The profile name. The attribute has no default value. The value must be specified. |
preferredServerList |
The host addresses of the preferred servers is a space separated list of server addresses. (Do not use host names.) The servers in this list are tried in order before those in defaultServerList until a successful connection is made. This has no default value. At least one server must be specified in either preferredServerList or defaultServerList. |
defaultServerList |
The host addresses of the default servers is a space separated list of server addresses. (Do not use host names.) After the servers in preferredServerlist are tried, those default servers on the client's subnet are tried, followed by the remaining default servers, until a connection is made. At least one server must be specified in either preferredServerList or defaultServerList. The servers in this list are tried only after those on the preferred server list. This attribute has no default value. |
defaultSearchBase |
The DN relative to which to locate the well-known containers. There is no default for this value. However, this can be overridden for a given service by the serviceSearchDescriptor attribute. |
defaultSearchScope |
Defines the scope of a database search by a client. It can be overridden by the serviceSearchDescriptor attribute. The possible values are one or sub. The default value is a one level search. |
authenticationMethod |
Identifies the method of authentication used by the client. The default is none (anonymous). See Choosing Authentication Methods for more information. |
credentialLevel |
Identifies the type of credentials a client should use to authenticate. The choices are anonymous or proxy. The default is anonymous. |
serviceSearchDescriptor |
Defines how and where a client should search for a naming database, for example, if the client should look in one or more points in the DIT. By default no SSDs are defined. |
serviceAuthenticationMethod |
Authentication method used by a client for the specified service. By default, no service authentication methods are defined. If a service does not have serviceAuthenticationMethod defined, it will default to the value of authenticationMethod. |
attributeMap |
Attribute mappings used by client. By default no attributeMap is defined. |
objectclassMap |
Object class mappings used by client. By default no objectclassMap is defined. |
searchTimeLimit |
Maximum time [in seconds] a client should allow for a search to complete before timing out. This does not affect the time the LDAP server will allow for a search to complete. The default value is 30 seconds. |
bindTimeLimit |
Maximum time in seconds a client should allow to bind with a server before timing out. Default value is 30 seconds. |
followReferrals |
Specifies whether a client should follow an LDAP referral. Possible values TRUE or FALSE. The default value is TRUE. |
profileTTL |
Time between refreshes of the client profile from the LDAP server by the ldap_cachemgr(1M). Default is 43200 seconds or 12 hours. If given a value of 0, the profile will never be refreshed. |
The following table lists the client attributes that can be set locally using ldapclient. See the ldapclient(1M) man page for more information.
Table 13–3 Local Client Attributes
Attribute |
Description |
---|---|
domainName |
Specifies the client's domain name (which becomes the default domain for the client machine). This attribute has no default value and must be specified. |
proxyDN |
The proxy's distinguished name. If the client machine is configured with credentialLevel of proxy, the proxyDN must be specified. |
proxyPassword |
The proxy's password. If the client machine is configured with credentialLevel of proxy, proxyPassword must be defined. |
certificatePath |
The directory on the local file system containing the certificate databases. If a client machine is configured with authenticationMethod or serviceAuthenticationMethod using TLS, then this attribute is used. The default value is /var/ldap. |
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 is a daemon that runs on LDAP client machines. It performs the following key functions.
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.
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 Administration Guide for the version of Sun ONE Directory Server that you are using.
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) access the directory. The naming service reads various entries and their attributes from the directory based on predefined identity. The authentication service establishes whether the user has entered the correct password by using that user's name and password to authenticate to the LDAP server. See the pam_ldap(5) man page for more information about the authentication service.
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 adds load to the directory server and the client.
You will need to set up your directory server for SSL. For more information about setting up Sun ONE Directory Server for SSL, see the Administration Guide for the version of Sun ONE Directory Server that you are using. 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.
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
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 has read access. If you use an anonymous credential level, you 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 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. For more information, see “Managing Access Control” in the Administration Guide for the version of Sun ONE Directory Server that you are using.
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 need to configure the proxyDN and proxyPassword on every client using the proxy credential level. The encrypted proxyPassword is 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, 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.
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.
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.
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.
The client's password is protected during authentication, but the session is not encrypted. Some directory servers, including Sun ONE Directory Server, 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.
If you are using Sun ONE Directory Server, 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 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 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.
Table 13–4 Authentication Methods
|
Bind |
Session |
Password on wire |
Password on Sun ONE Directory Server |
Session |
---|---|---|---|---|---|
none |
No |
No encryption |
N/A |
N/A |
No encryption |
simple |
Yes |
No encryption |
Clear |
Any |
No |
sasl/digest-MD5 |
Yes |
No encryption |
Encryption |
Clear |
No |
sasl/cram-MD5 |
Yes |
No encryption |
Encryption |
N/A |
No |
tls_simple |
Yes |
No encryption |
Encryption |
Any |
Encryption |
tls:sasl/cram-MD5 |
Yes |
Encryption |
Encryption |
N/A |
Encryption |
tls:sasl/digest-MD5 |
Yes |
Encryption |
Encryption |
Clear |
Encryption |
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 by passwd(1) to change the login password and password attributes.
keyserv
This service is used by the chkey(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 |
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
If you have not changed the pam.conf(4) file, pam_unix is enabled by default. pam_unix follows the traditional model of UNIX authentication, which means the following:
The client retrieves the user's encrypted password from the name service.
The user is prompted for his password.
The user's password is encrypted.
The client compares the two encrypted passwords to determine whether the user should be authenticated.
Additionally, there are two restrictions when using pam_unix.
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 is not compatible with the sasl authentication method digest-MD5, since Sun ONE Directory Server requires passwords to be stored in the clear in order to use digest-MD5. pam_unix requires the password be stored in crypt format.
See the pam_unix(5) man page for details.
pam_ldap
When using , 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 is able to bind to the server with the user's identity and supplied password, it authenticates the user.
pam_ldap 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_ldap. pam_ldap does not support the none authentication method. Thus, you must define the serviceAuthenticationMethod or the authenticationMethod attributes so clients can use pam_ldap. See the pam_ldap(5) man page for more information.
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. See the pam_unix(5) and pam_ldap(5) man pages for more information.
Table 13–5 pam_unix versus pam_ldap
|
pam_unix |
pam_ldap |
---|---|---|
Password Sent |
Uses passwd service authentication method |
Uses passwd service authentication method |
New Password Sent |
Encrypted |
No encryption (unless TLS is used) |
New Password Stored |
crypt format |
As defined on Sun ONE Directory Server by default passwd storage scheme |
Requires password read? |
Yes |
No |
sasl/digest-MD5 compatibility after changing password |
No. Password is not stored in clear. User cannot authenticate. |
Yes. As long as default storage scheme is set to clear, user can authenticate. |
Use passwd(1) to change a password. In order to change the password, the userPassword attribute must be writable by the user. Remember that the serviceAuthenticationMethod for passwd-cmd overrides the authenticationMethod for this operation. Depending on the authentication used, the current password might be unencrypted 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 unencrypted. 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, the password is encrypted using the passwordStorageScheme (as it is untagged). For more information about the passwordStorageScheme attribute, see “User Account Management” in the Administration Guide for the version of Sun ONE Directory Server that you are using.
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, passwordStorageScheme must be set to clear. See the following section for more information.
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.
LDAP naming services take advantage of the password and account lockout policy support in Sun ONE Directory Server. 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'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 the Sun ONE Directory Server version 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 Administration Guide for the version of Sun ONE Directory Server that you are using. 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, 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.