This chapter describes how to set up a Solaris LDAP naming services client. This chapter covers the following topics:
In order for a Solaris client to use LDAP as a naming service the following needs to be in place.
The client's domain name must be served by the LDAP server
The nsswitch.conf file needs to point to LDAP for the required services
The client needs to be configured with all the given parameters that define its behavior
ldap_cachemgr needs to be running on the client
At least one server for which a client is configured must be up and running
The ldapclient utility is the key to setting up an LDAP client, as it performs all of the above steps, except for starting the server. The rest of this chapter will show examples of how to use the ldapclient utility to set up an LDAP client and use the various other LDAP utilities to get information about, and check the status of, an LDAP client.
The LDAP client service is managed by using the Service Management Facility. For an overview of SMF, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.
Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command.
Temporarily disabling a service by using the -t option provides some protection for the service configuration. If the service is disabled with the -t option, the original settings would be restored for the service after a reboot. If the service is disabled without -t, the service will remain disabled after reboot.
The Fault Managed Resource Identifier (FMRI) for the LDAP client service is svc:/network/ldap/client:<instance>.
You can query the status of the LDAP client and ldap_cachemgr by using the svcs command.
Example of svcs command and output.
# svcs \*ldap\* STATE STIME FMRI online 15:43:46 svc:/network/ldap/client:default |
Example of svcs -l command and output. To get the output shown below, you must use the instance name in the FMRI.
# svcs -l network/ldap/client:default fmri svc:/network/ldap/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 1598 dependency require_all/none file://localhost/var/ldap/ldap_client_file (-) dependency require_all/none svc:/network/initial (online) dependency require_all/none svc:/system/filesystem/minimal (online) |
You can check a daemon's presence by using the ps command.
# ps -e | grep slapd root 23320 1 0 Aug 27 ? 16:30 ./ns-slapd -D \ /usr/iplanet/ds5/slapd-lastrev -i /usr/iplanet/ds5/slapd-lastrev/ root 25367 25353 0 15:35:19 pts/1 0:00 grep slapd |
Do not use the -f option with ps because this option attempts to translate user IDs to names, which causes more naming service lookups that might not succeed.
ldapclient(1M) is a utility used to set up LDAP clients in the Solaris system. ldapclient assumes the server has already been configured with the appropriate client profiles. You must install and configure the server with the appropriate profiles before you can set up clients.
The Solaris OS does not support a configuration in which an NIS client and a native LDAP client co-exist on the same client system.
There are two main ways to set up a client by using ldapclient.
Profile
At a minimum, you need to specify the server address containing the profile and domain you want to use. If no profile is specified, then the “default” profile is assumed. The server will provide the rest of the required information, except for proxy and certificate database information. If a client's credential level is proxy or proxy anonymous, you must supply the proxy bind DN and password. See Assigning Client Credential Levels for more information.
Starting in the Solaris 10 10/09 release, the enableShadowUpdate switch is available. To enable shadow data update, you must provide the admin credential (adminDN plus adminPassword).
Manual
You configure the profile on the client itself, which means that you define all parameters from the command line. Thus, the profile information is stored in cache files and is never refreshed by the server.
Though you can manually configure clients, it is not recommended. Using the configuration profiles decreases the complexity and cost of managing clients.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.
Run ldapclient with init.
# ldapclient init \ -a profileName=new \ -a domainName=west.example.com 192.168.0.1 System successfully configured |
Do not edit either of the client configuration files directly. Use the ldapclient command to create or modify the content of these files.
Before you set up a client with per-user credentials the following items must already be configured:
One or more Kerberos KDC servers must be configured and running.
DNS, client access to a DNS server, and at least one DNS server, must be configured and running.
Kerberos on the client machine must be configured and enabled.
A Kerberos client installation profile must exist. Such a profile might be:
# cat /usr/tmp/krb5.profile REALM SPARKS.COM KDC kdc.example.com ADMIN super/admin FILEPATH /usr/tmp/krb5.conf NFS 1 DNSLOOKUP none |
The LDAP server must be installed and configured to support the sasl/GSSAPI.
Appropriate identity mapping configurations must exist.
Kerberos host principals for the directory server and the KDC must be set up in the KDC.
idsconfig must have been run on the directory server DIT to be used.
An appropriate per-user gssapi profile (such as gssapi_EXAMPLE.COM) must have been created.
An illustration of a per-user profile in idsconfig is shown in the following partial example:
# /usr/lib/ldap/idsconfig Do you wish to continue with server setup (y/n/h)? [n] y Enter the iPlanet Directory Server's (iDS) hostname to setup: kdc.example.com Enter the port number for iDS (h=help): [389] <Enter your port> Enter the directory manager DN: [cn=Directory Manager] <Enter your DN> Enter passwd for cn=Directory Manager : <Enter your password> Enter the domainname to be served (h=help): [example.com] <Enter your domain> Enter LDAP Base DN (h=help): [dc=example,dc=com] <Enter your DN> GSSAPI is supported. Do you want to set up gssapi:(y/n) [n] y Enter Kerberos Realm: [EXAMPLE.COM] EXAMPLE.COMYou can create a sasl/GSSAPI enabled profile with default values now. Do you want to create a sasl/GSSAPI default profile ? [n] y Enter. the profile name (h=help): [gssapi_EXAMPLE.COM] <Enter> GSSAPI setup is done. ... |
The necessary user principals must exist in the Key Distribution Center (KDC).
On the client machine, Kerberos must be initialized using the client profile with a command such as:
# /usr/sbin/kclient -p /usr/tmp/krb5.profile |
/etc/nsswitch.ldap must be configured to use dns for hosts and ipnodes. Modify this file with an editor as necessary, as in the following:
host: files dns ipnodes: files dns |
/etc/resolv.conf must be configured and the dns service must be running. See the DNS chapters in this document for details.
The directory server DIT must be pre-loaded with (at a minimum) the users of this client machine, the client host and necessary auto_home LDAP entries. See other sections of this manual for details on how to add entries using ldapaddent.
Run ldapclient init to initialize the client by using the gssapi profile:
# /usr/sbin/ldapclient init -a profilename=gssapi_SPARKS.COM -a \ domainname=example.com 9.9.9.50 |
Try to log in as a user:
Run kinit -p user.
Run ldaplist -l passwd user in user's login session and you should see “userpassword.”
But ldaplist -l passwd bar can get the entry without userpassword. By default root can still see userpassword of everybody.
If the syslog has messages: libsldap: Status: 7 Mesg: openConnection: GSSAPI bind failed - 82 Local error, it is likely that Kerberos is not initialized or its ticket is expired. Run klist to browse it. Run kinit -p foo or kinit -R -p foo and try again.
If you want to, you can add pam_krb5.so.1 to /etc/pam.conf so it will automatically kinit when you log in.
For example:
login auth optional pam_krb5.so.1 rlogin auth optional pam_krb5.so.1 other auth optional pam_krb5.so.1 |
If a user is kinited and the syslog message indicates Invalid credential, then the problem could be the host entry (root) or user entry is not in LDAP directory or mapping rules are not correct.
When ldapclient init is executed, it makes some checks if the LDAP profile contains self/ sasl/GSSAPI configuration. If it fails at /etc/nsswitch.ldap check, then the usual reason is that dns was not added to host: and ipnodes:.
If it fails because the DNS client not enabled, run svcs -l dns/client to see if /etc/resolv.conf is missing or it is just disabled. Run svcadm enable dns/client to enable it.
If the check fails because of sasl/GSSAPI bind, check syslog to find out what went wrong.
See other references in this guide and in the System Administration Guide: Security Services for details.
Do not edit either of the client configuration files directly. Use ldapclient to create or modify the content of these files.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.
Run ldapclient (defining proxy values).
# ldapclient init \ -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \ -a domainName=west.example.com \ -a profileName=pit1 \ -a proxyPassword=test1234 192.168.0.1 System successfully configured |
The -a proxyDN and -a proxyPassword are required if the profile to be used is set up for proxy. As the credentials are not stored in the profile saved on the server, you must supply the information when you initialize the client. This method is more secure than the older method of storing the proxy credentials on the server.
The proxy information is used to create /var/ldap/ldap_client_cred. The rest of the information is put in /var/ldap/ldap_client_file.
Starting in the Solaris 10 10/09 release, the enableShadowUpdate switch is available.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.
To set the enableShadowUpdate switch and define the admin credential, run the ldapclient command.
To update an already running client, run this command:
# ldapclient mod -a enableShadowUpdate=TRUE \ -a adminDN=cn=admin,ou=profile,dc=west,dc=example,dc=com \ -a adminPassword=admin-password System successfully configured |
To initialize a client, run this command:
# ldapclient init \ -a adminDN=cn=admin,ou=profile,dc=west,dc=example,dc=com \ -a adminPassword=admin-password -a domainName=west.example.com \ -a profileName=WestUserProfile \ -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \ -a proxyPassword=i<proxy_password> \ 192.168.0.1 System successfully configured |
To verify the configuration, display the contents of the /var/ldap/ldap_client_cred file.
The output should contain lines similar to the following:
# cat /var/ldap/ldap_client_cred NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788f8eb85de11 NS_LDAP_ENABLE_SHADOW_UPDATE= TRUE NS_LDAP_ADMIN_BINDDN= cn=admin,ou=profile,dc=west,dc=example,dc=com NS_LDAP_ADMIN_BINDPASSWD= {NS1}4a3788f8c053434f |
Superusers. or administrators with an equivalent role, can perform manual client configurations. However, many of the checks are bypassed during the process, so it is relatively easy to misconfigure your system. In addition, you must change settings on every machine, instead of in one central place, as is done when using profiles.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.
Use ldapclient manual to initialize the client.
# ldapclient manual \ -a domainName=dc=west.example.com \ -a credentialLevel=proxy \ -a defaultSearchBase=dc=west,dc=example,dc=com \ -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \ -a proxyPassword=testtest 192.168.0.1 |
Use ldapclient list to verify.
NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.1 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_CREDENTIAL_LEVEL= proxy |
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.
Use the ldapclient mod command to change the authentication method to simple.
# ldapclient mod -a authenticationMethod=simple |
Use ldapclient list to verify the change was made.
# ldapclient list NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.1 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_AUTH= simple NS_LDAP_CREDENTIAL_LEVEL= proxy |
You cannot change some attributes of an LDAP client configuration by using the mod subcommand. For example, you cannot change the profileName and profileTTL attributes. To change these attributes, create a new profile by using the ldapclient init command, as described in Using Profiles to Initialize a Client. Or, run the ldapclient manual command, as described in Initializing a Client Manually.
ldapclient uninit restores the client name service to what it was prior to the most recent init, modify, or manual operation. In other words, it performs an “undo” on the last step taken. For example, if the client was configured to use profile1 and was then changed to use profile2, using ldapclient uninit would revert the client back to using profile1.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.
Use ldapclient uninit.
# ldapclient uninit System successfully recovered |
The security database files must be readable by everyone. Do not include any private keys in the key3.db.
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 newer database format from Mozilla, three files, cert8.db, key3.db and secmod.db are needed. The cert7.db or cert8.db file contains trusted certificates. The key3.db file 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 PKCS#11 module. This file is not required if the older format is used.
Before running ldapclient, you should set up and install the needed security database files described in this section.
See the section about configuring LDAP clients to use SSL in the “Managing SSL” chapter of the Administrator's Guide for the version of Sun Java System Directory Server you are using. For information on how to create and manage these files. Once configured, these files must be stored in the location expected by the LDAP naming services client. The attribute certificatePath is used to determine this location. This is by default /var/ldap.
For example, after setting up the necessary cert7.db and key3.db files using Netscape Communicator, copy the files to the default location.
# cp $HOME/.netscape/cert7.db /var/ldap # cp $HOME/.netscape/key3.db /var/ldap |
Next, give everyone read access.
# chmod 444 /var/ldap/cert7.db # chmod 444 /var/ldap/key3.db |
While Netscape manages the cert7.db and key3.db files in the $HOME/.netscape directory, Mozilla has its cert8.db, key3.db and secmod.db files managed in a sub-directory under $HOME/.mozilla. Copies of these security databases must be stored on a local file system if you are using them for an LDAP naming services client.
pam_ldap is one authentication and account management PAM module option for LDAP. See the pam_ldap(5) man page and Appendix A, Solaris 10 Software Updates to DNS, NIS, and LDAP for more information about the features currently supported with pam_ldap.
If you have selected both the per-user mode and the self credentials option, then you must also enable the PAM Kerberos pam_krb5(5) pam modules. See pam_krb5(5) and the System Administration Guide: Security Services documentation for further details.
To configure PAM to use UNIX policy, follow the sample in Example pam.conf File for pam_ldap. Add the lines that contain pam_ldap.so.1 to the client's /etc/pam.conf file. For details, see the pam.conf(4) man page.
To configure PAM to use LDAP server_policy, follow the sample in Example pam_conf file for pam_ldap Configured for Account Management. Add the lines that contain pam_ldap.so.1 to the client's /etc/pam.conf file. In addition, if any PAM module in the sample pam.conf file specifies the binding flag and the server_policy option, use the same flag and option for the corresponding module in the client's /etc/pam.conf file. Also, add the server_policy option to the line that contains the service module pam_authtok_store.so.1.
Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.
Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.
pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.
To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid:1.3.6.1.4.1.42.2.27.9.5.8 cn:Password Policy Account Usable Request Control aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; allow (read, search, compare, proxy) (groupdn = "ldap:///cn=Administrators,cn=config");) creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=server,cn=plugins,cn=config |
The binding control flag
Using the binding control flag allows a local password override of a remote (LDAP) password. For example, if a user account is found on both the local files and the LDAP namespace, the password associated with the local account takes precedence over the remote password. Thus, if the local password expires, authentication fails even if the remote LDAP password is still valid.
The server_policy option
The server_policy option instructs pam_unix_auth, pam_unix_account, and pam_passwd_auth to ignore a user found in the LDAP namespace and to allow pam_ldap to perform authentication or account validation. In the case of pam_authtok_store, a new password is passed to the LDAP server without encryption. The password is thereby stored in the directory according to the password encryption scheme configured on the server. For more information, see pam.conf(4) and pam_ldap(5).
You can retrieve information about LDAP naming services by using the ldaplist utility. This LDAP utility lists the naming information from the LDAP servers in LDIF format. It can be useful for troubleshooting. See ldaplist(1) for further information.
ldaplist displays its output with a blank line separating records, which is helpful for big multiline records.
The output of ldaplist depends upon the client configuration. For example, if the value of ns_ldap_search is sub rather than one, ldaplist lists all the entries under the current search baseDN.
The following is an example of ldaplist output.
# ldaplist dn: ou=people,dc=west,dc=example,dc=com dn: ou=group,dc=west,dc=example,dc=com dn: ou=rpc,dc=west,dc=example,dc=com dn: ou=protocols,dc=west,dc=example,dc=com dn: ou=networks,dc=west,dc=example,dc=com dn: ou=netgroup,dc=west,dc=example,dc=com dn: ou=aliases,dc=west,dc=example,dc=com dn: ou=hosts,dc=west,dc=example,dc=com dn: ou=services,dc=west,dc=example,dc=com dn: ou=ethers,dc=west,dc=example,dc=com dn: ou=profile,dc=west,dc=example,dc=com dn: automountmap=auto_home,dc=west,dc=example,dc=com dn: automountmap=auto_direct,dc=west,dc=example,dc=com dn: automountmap=auto_master,dc=west,dc=example,dc=com dn: automountmap=auto_shared,dc=west,dc=example,dc=com |
To list specific information such as a user's passwd entry, use getent as follows:
# getent passwd user1 user1::30641:10:Joe Q. User:/home/user1:/bin/csh |
If you want to list all attributes, use ldaplist with the -l option.
# ldaplist -l passwd user1dn: uid=user1,ou=People,dc=west,dc=example,dc=com uid: user1 cn: user1 uidNumber: 30641 gidNumber: 10 gecos: Joe Q. User homeDirectory: /home/user1 loginShell: /bin/csh objectClass: top objectClass: shadowAccount objectClass: account objectClass: posixAccount shadowLastChange: 6445 |
The following sections describe how you can customize the client environment.
You can change any of the services, but be careful, because if the data is not populated on the server for the service specified, things will stop working. Also, in some cases files may not be set up by default.
You can modify your /etc/nsswitch.conf file to customize where each service gets its information. The default settings are stored in /etc/nsswitch.ldap and ldapclient uses this file to create your /etc/nsswitch.conf file when the client is initialized.
If you want to enable DNS by setting up a /etc/resolv.conf file, add DNS to your hosts lines as shown below.
hosts: ldap dns [NOTFOUND=return] files |
The recommended configuration is:
hosts: files dns
ipnodes: files dns
If per-user authentication is used, the sasl/GSSAPI and Kerberos mechanisms expect the dns naming service to be configured and enabled. See the chapters on DNS in this administration guide for further details.