This chapter covers the following topics.LDAP Data Interchange Format (LDIF) Using Fully Qualified Domain Names With LDAP Default Directory Information Tree (DIT) Default LDAP Schema Service Search Descriptors (SSDs) and Schema Mapping LDAP Client Profiles ldap_cachemgr Daemon LDAP Naming Services Security Model LDIFLDIF 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 ldaplist1 with thel option to display the following information.% ldaplist l hosts myhosthosts 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 user1passwd 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 nameservices 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 mygroupgroup 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 lnetgroup mynetgroupnetgroup 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.0networks 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.0netmasks 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 ypservrpc dn: cn=ypserv,ou=Rpc,dc=mydc,dc=mycom,dc=com cn: ypserv cn: ypprog oncrpcnumber: 100004 objectclass: top objectclass: oncRpc% ldaplist l protocols tcpprotocols 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 myhostbootparams 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 myhostethers 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 myhostpublickey 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 mynamealiases dn: mail=myname,ou=aliases,dc=mydc,dc=mycom,dc=com cn: myname mail: myname objectclass: top objectclass: mailgroup mgrprfc822mailmember: my.name FQDNUnlike 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.netBoth gethostbyname and getnameinfo return the FQDN version when looking up the host name server:server.west.example.netAlso, 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. Directory Information Tree 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 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 14, 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. schema mappingAs 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.SSDsService Search DescriptorsThe 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=TRUEIt is also possible to associate multiple containers with a particular service type. In the following example, the service search descriptor specifies searching for the password entries in three containers.ou=myuser,dc=example,dc=comou=newuser,dc=example,dc=comou=extuser,dc=example,dc=com Note that a trailing ',' in the example 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=comAttribute mapThe 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 14, 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=homeThere 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 titleThis maps the gecos values to a space separated list of the cn, sn, and title attribute values. objectClass MapThe 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 ProfilesLDAP clientTo 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 idsconfig1M man page for information on how to set a client profile manually.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, proxy, or self (also known as per user). 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_cachemgr1M. 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 ldapclient1M man page for more information.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. When you start the LDAP client, the ldap_cachemgr daemon is invoked. The daemon performs the following key functions.ldap_cachemgr daemonGains 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_cachemgr1M man page for detailed information. Solaris LDAP naming services can use the LDAP repository in two different ways. One is as a source of both a naming service and an authentication service. The other is strictly as the source of naming data, using Kerberos as the enterprise-wide authentication system. This section discusses the concepts of client identity, authentication methods, pam_ldap5 and pam_unix modules, and account management when the LDAP repository is used as both a naming service and authentication service. This section also discusses the use of LDAP naming services in conjunction with the Kerberos environment (Part VI, Kerberos Service, in System Administration Guide: Security Services) and pam_krb55 modules.&pamldapnote;If you use Kerberos as your authentication system and integrate it with the LDAP naming system, you will be able to support a single sign on (SSO) environment in your enterprise through Kerberos. You will also be able to use that same identity system when querying LDAP naming data on a per-user or per-host basis. access control informationTo 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 Java System 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.When you use pam_ldap 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_ldap5 man page for more information about the authentication service.When Kerberos is used to perform authentication, and when authentication in LDAP naming services is also enabled (as is required for per-user mode), Kerberos can provide dual functions. Kerberos authenticates to the server and the Kerberos identity for the principal (user or host) is used to authenticate to the directory. In this way, the same user identity used to authenticate to the system is also used to authenticate to the directory for lookups. Administrators can use access control information (ACI) in the directory to limit the results out of the naming service if desired. 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. Transport Layer SecuritySSL protocolTLS 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 Java System Directory Server for SSL, see the Administration Guide for the version of Sun Java System Directory Server that you are using. You will also need to set up your LDAP client for SSL.If using TLS, the necessary security databases must be installed. In particular, the certificate and key database files are needed. For example, if you adopt an older database format from Netscape Communicator, two files, cert7.db and key3.db, are required. Or if you use a new database format from Mozilla, three files, cert8.db, key3.db, and secmod.db are needed. The cert7.db or cert8.dbfile contains trusted certificates. The key3.dbfile contains the client's keys. Even if the LDAP naming service client does not use client keys, this file must be present. The secmod.db file contains the security modules such as the PKCS#11 module. This file is not required if the older format is used.See Setting Up TLS Security for more information. Credential LevelsLDAP clientLDAP naming services clients authenticate to the LDAP server according to a client's credential level. LDAP clients can be assigned four possible credential levels with which to authenticate to a directory server.anonymous proxy credential levelproxy proxy anonymous credential levelproxy anonymous per-user index levelself credential levelself (called per user in this document) AnonymousIf you use anonymous access, you can access only the data that is available to everyone. In anonymous mode, an LDAP BIND operation does not take place. 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 Java System 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 Java System Directory Server that you are using. Proxyproxy credentialsThe client authenticates or binds to the directory using a single 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. The proxy account is a shared-per-machine resource. That is, each user logged into a machine using proxy access, including the root user, sees the same results as all other users on that machine. 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, or they must use the per-user authentication model. 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 credentialsProxy anonymousProxy 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.per-user credentialsPer UserPer-user (self) authentication uses the Kerberos identity (principal) to perform a lookup for each user or each system when authenticating to the directory server. 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. When configuring per-user mode, the configuration value to enable this mode is “self,” which denotes per-user mode. To use the per-user authentication model, the Kerberos single sign-on service must be deployed. In addition, the one or more directory servers used in the deployment must support SASL and the SASL/GSSAPI authentication mechanism. Because Kerberos expects to use files and DNS for host name lookups, instead of LDAP, DNS should be deployed in this environment. Also, to use per-user authentication, nscd must be enabled. Nscd is not an optional component in this configuration.Credential StorageLDAP clientIf 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 12, Setting Up LDAP Clients (Tasks) for more information on setting up client profiles.If you configure a client to use per-user authentication, the Kerberos identity and Kerberos ticket information for each principal (each user or host) are used during authentication. In this environment 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 then use its access control instruction (ACI) mechanisms to allow or deny access to naming service data as necessary. In this situation, Kerberos ticket information is used to authenticate to the directory server and the system does not store authentication DNs or passwords on the system. 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.authentication methodsnoneThe authentication method, like the credential level, may be multivalued. 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.noneThe client does not authenticate to the directory. This is equivalent to the anonymous credential level. authenticationsimplesimpleipsec(7)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. authenticationdigest-MD5sasl/digest-MD5The client's password is protected during authentication, but the session is not encrypted. Some directory servers, including Sun Java System 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 Java System Directory Server, the password must be stored in the clear in the directory. sasl/cram-MD5In this case, the LDAP session is not encrypted, but the client's password is protected during authentication, as authentication is performed by 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 Java System Directory Server does not support cram-MD5. sasl/GSSAPIThis authentication method is used in conjunction with the self credential mode to enable per-user lookups. A per-user nscd assigned to use the client's credentials binds to the directory server using the sasl/GSSAPI method and the client's Kerberos credentials. Access can be controlled in the directory server on a per-user basis. tls:simpleThe client binds using the simple method and the session is encrypted. The password is protected. tls:sasl/cram-MD5The LDAP session is encrypted and the client authenticates to the directory server using sasl/cram-MD5. tls:sasl/digest-MD5The LDAP session is encrypted and the client authenticates to the directory server using sasl/digest-MD5. Sun Java System 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. Bind Password on wire Password on Sun Java System Directory Server Session none No N/A N/A No encryption simple Yes Clear Any No encryption sasl/digest-MD5 Yes Encryption Clear No encryption sasl/cram-MD5 Yes Encryption N/A No encryption sasl/GSSAPI Yes Kerberos Kerberos Encryption tls:simple Yes Encryption Any Encryption tls:sasl/cram-MD5 Yes Encryption N/A Encryption tls:sasl/digest-MD5 Yes Encryption Clear Encryption The authentication method can be specified for a given service in the serviceAuthenticationMethod attribute. The following services currently support this.passwd-cmdThis service is used by passwd1 to change the login password and password attributes. keyservThis service is used by the chkey1 and newkey1M utilities to create and change a user's Diffie-Hellman key pair. pam_ldapThis service is used for authenticating users with pam_ldap5.pam_ldap supports account management. If the service does not have a serviceAuthenticationMethod set, it will default to the value of the authenticationMethod attribute. In per-user mode, pam_krb5 (pam Kerberos) is used as the authentication service. ServiceAuthenticationMethod is not needed in this mode of operation. 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 PAM Pluggable Authentication Methods By using the PAM framework, you can choose among several authentication services, including pam_unix, pam_krb5, and pam_ldap.If the per-user authentication method is used, pam_krb5, the strongest authentication service of the three methods listed above, must be enabled. See pam_krb55 and the System Administration Guide: Security Services.The pam_krb5 authentication system may be used even if per-user authentication is not enabled. If proxy or anonymous credential levels are used to access directory server data then restricting access to directory data on a per-user basis is not possible.Because of its increased flexibility, support of stronger authentication methods, and ability to use account management, the use of pam_ldap is recommended over the use of pam_unix when anonymous or proxy authentication methods are used.If you have not changed the pam.conf4 file, pam_unix functionality is enabled by default.The pam_unix module has been removed and is no longer supported with Solaris. A set of other service modules provides equivalent or greater functionality. Therefore, in this guide, pam_unix refers to the equivalent functionality, not to the pam_unix module itself. Following is a list of the modules that provide the equivalent pam_unix functionality.pam_authtok_check5 pam_authtok_get5 pam_authtok_store5 pam_dhkeys5 pam_passwd_auth5 pam_unix_account5 pam_unix_auth5 pam_unix_cred5 pam_unix_session5 pam_unix follows the traditional model of UNIX authentication, as described in the following list.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 Java System 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. Refer to pam_krb55 and the System Administration Guide: Security Services. When implementing pam_ldap, the user binds to the LDAP server by using the authentication method defined in pam_ldap's serviceAuthenticationMethod parameter, if one exists. Otherwise, authenticationMethod is used.If pam_ldap is able to bind to the server with the user's identity and supplied password, it authenticates the user.&pamldapnote;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_unix. Also, 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_ldap5 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, pam_ldap, and pam_krb5. pam_unix pam_ldap pam_krb5 Password Sent Uses passwd service authentication method Uses passwd service authentication method Uses Kerberos single sign on technology, not passwords New Password Sent Encrypted No encryption (unless TLS is used) Uses Kerberos, no passwords are sent over the wire New Password Stored crypt format Password storage scheme defined on Sun Java System Directory Server Passwords are managed via Kerberos Requires password read? Yes No 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. No. sasl/GSSAPI is used. There are no passwords over the wire and there are no passwords to be stored in the directory server, except when using a Kerberos kdc that manages its password database in the LDAP directory server. Use passwd1 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, 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. See the pam_authtok_store5 man page for more information.As of the Solaris 10 software release, pam_ldap no longer supports password update. The previously recommended use of pam_authtok_store with the server_policy option now replaces the pam_ldap password update capability. When you use pam_authtok_store, the new password is sent to the LDAP server in the clear. Therefore, to ensure privacy, use TLS. If TLS is not used, the new userPassword is subject to snooping. If you set an untagged password with Sun Java System Directory Server, the software encrypts the password by using the passwordStorageScheme attribute. For more information about the passwordStorageScheme, see the section on user account management in the Administration Guide for the version of Sun Java System Directory Server that you are using.You need to consider the following configuration issues 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 Java System Directory Server, passwordStorageScheme must be set to clear. If you select pam_krb5 as your account and password management system, the Kerberos environment will manage all your account, password, account lockout, and other account management details. Refer to pam_krb55 and the System Administration Guide: Security Services.If you do not use pam_krb5, then LDAP naming services can be configured to take advantage of the password and account lockout policy support in Sun Java System Directory Server. You can configure pam_ldap5 to support user account management. passwd1 enforces password syntax rules set by the Sun Java System Directory Server password policy, when used with the proper PAM configuration.Password ManagementAccount ManagementLDAPaccount managementAccount ManagementThe following account management features are supported through pam_ldap5. These features depend on Sun Java System 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 notificationUsers 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 checkingNew 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 checkingUsers cannot reuse passwords. If a user attempts to change the password to one that was previously used, passwd1 fails. LDAP administrators can configure the number of passwords kept in the server's history list. User account lockoutA 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 account management features only work with the Sun Java System Directory Server. 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 Java System Directory Server that you are using. Also see Example pam_conf file for pam_ldap Configured for Account Management. Do not enable account management for proxy accounts. Before configuring the password and account lockout policy on Sun Java System Directory Server, make sure all hosts use the “newest” LDAP client with pam_ldap account management.In addition, make sure the clients have a properly configured pam.conf4 file. Otherwise, LDAP naming services will not work when proxy or user passwords expire.&pamldapnote;