Initializing an LDAP Client

The ldapclient command is used to set up LDAP clients on an Oracle Solaris system. The command assumes that 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.

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.

  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.

How to Initialize an LDAP Client by Using Profiles

1. Become an administrator.

   For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

2. Run the ldapclient command with the init option.

   # ldapclient init -a profileName=new \
   -a domainName=west.example.com 192.168.0.1
   System successfully configured

How to Initialize an LDAP Client by Using Per-User Credentials

Before You Begin

Before you set up an LDAP client with per-user credentials, the following must already be configured:

• One or more Kerberos key distribution center (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 such as the following must exist:

  # cat /usr/tmp/krb5.profile
  REALM EXAMPLE.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 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.

• The idsconfig command 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 the idsconfig command 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 Directory Server's hostname to setup: kdc.example.com
  Enter the port number for DSEE (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.COM

  ---

  Note - In addition, for a gssapi profile, you must supply a credential level of 4 self and the authentication method of 6 sasl/GSSAPI.

  ---

• The necessary user principals must exist in the KDC.

• On the client machine, Kerberos must be initialized by using the client profile with a command such as the following:

  # /usr/sbin/kclient -p /usr/tmp/krb5.profile

• The name service switch must be configured to use dns for hosts. The following command checks the current repository values:

  % svcprop -p config/host system/name-service/switch
  files\ dns\ nis

• DNS 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 preloaded with (at a minimum) the users of this client machine, the client host, and the necessary auto_home LDAP entries. See other sections of this manual for details on how to add entries by using the ldapaddent command.

1. Run ldapclient init to initialize the client by using the gssapi profile.

   # /usr/sbin/ldapclient init -a profilename=gssapi_EXAMPLE.COM -a \
   domainname=example.com 9.9.9.50

2. Try to log in as a user:
   • Run kinit -p user
   • Run ldaplist -l passwd user in the user's login session and you should see userpassword.
   • Run ldaplist -l passwd bar can get the entry without userpassword. By default root can still see userpassword of everybody.

Notes About Using Per-User Credentials

• If the syslog file has this message: 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 the klist command to browse it. For example, 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 that it will automatically run the kinit command 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 has run the kinit command and the syslog message indicates Invalid credential, then the problem could be that the root host entry or the user entry is not in the LDAP directory or mapping rules are not correct.

• When the ldapclient init command is executed, it checks if the LDAP profile contains a self/ sasl/GSSAPI configuration. If it fails in the switch check, then the usual reason is that DNS was not the search criteria for the hosts database.

  • If the check fails because the DNS client id not enabled, run svcs -l dns/client to determine if the service is disabled. Run svcadm enable dns/client to enable the service.

  • If the check fails because of a sasl/GSSAPI bind, check syslog to determine the problem.

See other references in this guide and in the Oracle Solaris 11.1 Administration: Security Services for details.

How to Initialize an LDAP Client by Using Proxy Credentials

1. Become an administrator.

   For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

2. Define 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 stored in the svc:/network/ldap/client service in the config and cred property groups.

How to Initialize an LDAP Client to Enable the Updating of Shadow Data

1. Become an administrator.

   For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

2. To set the enableShadowUpdate switch and define the admin credential, run the ldapclient command.
   • To update an already running LDAP 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 an LDAP 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=<proxy_password> \
     192.168.0.1
     System successfully configured

3. To verify the configuration, display the contents of the cred property of the network/ldap/client service.

   The output appears similar to the following:

   # svcprop -p cred svc:/network/ldap/client
   cred/read_authorization astring solaris.smf.value.name-service.ldap.client
   cred/value_authorization astring solaris.smf.value.name-service.ldap.client
   cred/bind_dn astring cn=proxyagent,ou=profile,dc=west,dc=example,dc=com
   cred/bind_passwd astring {NS1}4a3788f8eb85de11
   cred/enable_shadow_update boolean true
   cred/admin_bind_dn astring cn=admin,ou=profile,dc=west,dc=example,dc=com
   cred/admin_bind_passwd astring {NS1}4a3788f8c053434f

How to Initialize an LDAP Client Manually

Root users or administrators with an equivalent role can perform manual LDAP 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.

1. Become an administrator.

   For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

2. 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

3. Verify the LDAP client configuration.

   # 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_CREDENTIAL_LEVEL= proxy

How to Modify a Manual LDAP Client Configuration

1. Become an administrator.

   For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

2. Use the ldapclient mod command to change the authentication method to simple.

   # ldapclient mod -a authenticationMethod=simple

3. Verify the change was made to the LDAP client configuration.

   # 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

Troubleshooting

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 How to Initialize an LDAP Client by Using Profiles. Or, run the ldapclient manual command, as described in How to Initialize an LDAP Client Manually.

How to Uninitialize an LDAP Client

The ldapclient uninit command restores the client name service to what it was prior to the most recent init, modify, or manual operation. In other words, the command 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.

1. Become an administrator.

   For more information, see How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.

2. Uninitialize the LDAP client.

   # ldapclient uninit
   System successfully recovered

Setting Up TLS Security

If using transport layer security (TLS), the necessary security databases must be installed. In particular, the certificate and key database files are required. For example, if you use a newer database format from Mozilla Firefox, three files, cert8.db, key3.db and secmod.db are required. The 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.

See the section about configuring LDAP clients to use SSL in the “Managing SSL” chapter of the Administrator's Guide for the version of Oracle Directory Server Enterprise Edition 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 cert8.db, key3.db, and secmod.db files by using Mozilla Firefox, copy the files to the default location as follows:

# cp $HOME/.mozilla/firefox/*.default/cert8.db /var/ldap
# cp $HOME/.mozilla/firefox/*.default/key3.db /var/ldap
# cp $HOME/.mozilla/firefox/*.default/secmod.db /var/ldap

Next, give everyone read access.

# chmod 444 /var/ldap/cert8.db
# chmod 444 /var/ldap/key3.db
# chmod 444 /var/ldap/secmod.db

Configuring PAM

The pam_ldap module is one authentication and account management PAM module option for LDAP. See the pam_ldap(5) man page 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 module. See the pam_krb5(5) man page and the Oracle Solaris 11.1 Administration: Security Services documentation for further details.

Configuring PAM to Use UNIX policy

To configure PAM to use UNIX policy, use the default /etc/pam.conf file. No changes are needed. For details, see the pam.conf(4) man page.

However, if password aging and password policy as controlled by the shadow data are required, the client must be configured and run with the enableShadowUpdate switch. See How to Initialize an LDAP Client to Enable the Updating of Shadow Data for more information.

Configuring PAM to Use LDAP server_policy

To configure PAM to use LDAP server_policy, follow the sample in Example pam_conf File Using the pam_ldap Module 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.

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).