Configuring LDAP-UX Client Services

Log in as root and run the setup program:

cd /opt/ldapux/config
./setup

The setup program asks you a series of questions and usually provides default answers. Press the Enter key to accept the default, or change the value and press the Enter key. At any point during setup, press the Control-b keys to return to the previous screen or press the Control-c keys to exit setup.

Choose Windows 2000, 2003 or 2003 R2 as your LDAP directory server (option 2).

Enter either the host name or IP address of the directory server where your profile exists, or where you want to create a new profile.

Enter the port number of the previous specified directory server that you want to store the profile, from Appendix A. The default port number is 389.

Setup will check the directory to see if the schema has been extended with the LDAP-UX Client Services object class DUAConfigProfile, enter the DN (Distinguished Name) and password of a user. This must be done once. See Appendix B for a detailed description of these object classes.

If the schema has already been extended, setup skips this step. Otherwise, to extend the schema, enter the DN and password of a directory user who can extend the directory schema from Appendix A.

If the new automount schema has already been imported, setup skips this step.

Otherwise, you will be asked whether or not you want to install the new automount schema which is based on RFC 2307-bis. Enter "yes" to extend the new automount schema into the LDAP directory server. Enter "no" if you do not want to import new automount schema into the LDAP directory server. Setup skips to step 7 if you enter "no".

For new profiles, the profile object must be created under the 'ConfigurationNamingContext' container, which is usually CN=Configuration, <domain root>, or it can be created under any path with an object class of 'Container'. These container entries must exist before any new profile entries can be created.

Enter either the DN of a new profile, or the DN of an existing profile, from Appendix A.

To display all the profiles in the directory, use a command like the following:

If you are using an existing profile, setup configures your client, downloads the profile, and exits. In this case, continue by going to the section “Step 2: Install the PAM Kerberos Product”.

If you are creating a new profile, enter the DN and password of a directory user who can create a new profile, from Appendix A.

Choose the attribute map set to be used with the directory server. You can select SFU 2.0 (option 1), SFU 3.0/SFU3.5 (option 2) or RFC2307 (option 3). By default, the SFU 3.0/SFU3.5 (option 2) is used as the attribute map set.

Setup now checks the value of the enable_starttls parameter. Setup also checks if the certificate database files, cert7.db or cert8.db and key3.db, exist on your client system. If these files do not exist, setup skips this step.

If the value of the enable_starttls parameter is 0 (disabled) or undefined, you will be asked whether you want to use SSL or not. Enter "yes" if you want to use SSL for the secure communication between LDAP clients and the Windows 2000, 2003 or 2003 R2 Active Directory Server. Enter "no" if you don't want to use SSL. Continue to step 12.

Otherwise, if the value of the enable_starttls parameter is 1 (enabled), you will be asked whether you want to use TLS or not. Enter "yes" if you want to use TLS for the secure communication between LDAP clients and the Windows 2003 or 2003 R2 Active Directory Server. Enter "no" if you don't want to use TLS. Continue to step 12.

Next, it will prompt you for selecting the authentication method for users to bind/authenticate to the server. You need to choose the authentication method from one of the following prompts based on your selection in step 11:

Next, enter the host name and port number of the directory where your account and group data is, from Appendix A.You can enter up to three hosts, to be searched in order.

Enter the base DN where clients should search for name service data, from Appendix A.

Enter Yes when prompted to ask if you want to accept the remaining default configuration parameters.

Next, if you do not use SASL GSSAPI authentication, skip this step and go to step 18. Otherwise, it will prompt you for setting up principals used for SASL GSSAPI authentication as below:

There are two ways to set up principals used for SASL GSSAPI
authentication for LDAP-UX name service proxy authentication:
* Host or service principal defined in a keytab file (such as
 /etc/krb5.keytab)
* Proxy principal defined in LDAP-UX proxy credential file 
(/etc/opt/ldapux/pcred)
The principal defined in a keytab file can be shared among 
several services, such as Kerberized Interface Service or 
LDAP-UX using the host principal for authentication. The 
LDAP-UX proxy principal is used solely for LDAP-UX.

It will prompt you for selecting the type of principal. Enter H if you wish to use a host/service principal. Enter P if you wish to use a proxy principal. By default, the host or service principal is used.

Next, it will prompt you for entering the path to the Kerberos keytab file. Enter the keytab file if you want to specify the keytab file to be used. If no file is specified, LDAP-UX will use the default keytab file configured in /etc/krb5.conf using "default_keytab_name". If there is no default keytab file configured in /etc/krb5.conf, then the keytab file /etc/krb5.keytab will be used.

Next, it will prompt you for specifying an alternate principal name. If you do not want to use the default principal name, enter an alternate principal name. For example, host/hpntc20.cup.hp.com@CUP.HP.COM.

LDAP-UX uses ldapux/<FQHN>@<REALM> as the default service principal. If it does not exist, the host/<FQHN>@<REALM> in the keytable file is the principal to be used.FQHN stands for Fully Qualified Host Name.

For Active Directory, you must set access to the directory by proxy user because anonymous binding does not grant enough access right to an Active Directory. Enter the DN and password of your proxy user from Appendix A.

Enter the maximum time in seconds the client should wait for binding to the directory before aborting ("bind time"). Enter 0 for no time limit.

	CAUTION: The default client binding time is 5 seconds. Depending on the load on your directory, this default value may not be high enough to service all database requests.

Enter the maximum time in seconds the client should wait for directory searches before aborting. Enter 0 for no time limit.

Enter the Profile Time To Live (TTL) value. This value defines the time interval between automatic downloads (refreshes) of new configuration profiles from the directory. Automatic refreshing ensures that the client is always configured using the newest configuration profile. If you want to disable automatic refresh or manually control when the refresh occurs, enter a value of 0. Refer to “Downloading the Profile Periodically”

In this step, the setup program initiates a dialog where you can remap the standard object class attributes to alternate attributes. You may want to do this if the attributes in your directory do not conform to the object classes defined in RFC 2307.

You can remap the attributes for any of the supported services: passwd, shadow passwd, group, PAM, netgroup, rpc, protocols, networks, hosts, services and automount.

	NOTE: Make sure that the attribute names are entered correctly to avoid unpredictable results later.

Refer to RFC 2307 at http://www.ietf.org/rfc/rfc2307.txt for a description of the standard object classes and attributes.

At this point, the setup program will display the following dialog:

LDAP-UX Client Services supports the following services:
1.Password                              7.Networks
2.Shadow passwd                         8.Hosts
3.Group                                 9.Services
4.PAM (Pluggable Authentication Module)10.Printers
5.RPC                                  11.Automount
6 Protocols                            

Each services uses a standard object class (defined by RFC 2307)
You can remap any of these attributes to alternate attributes.
Do you want to remap any of the standard RFC 2307 attributes?

Enter “yes” if you want to remap object class attributes for any of the supported services. Then go to the “Remapping Attributes for Services” section for details of the procedures.

Enter “no” to this prompt to continue to step 25 of the setup process.

In this step, the setup program initiates a dialog where you can create a custom search descriptor. A custom search descriptor allows you to specify a different search location or filter for retrieving entries for services supported by LDAP-UX Client. Each name service can have up to three different search descriptors. A custom search descriptor consists of three parts: a search base DN, scope, and filter.

	NOTE: Custom search descriptors have no relevance for PAM Kerberos. PAM Kerberos is the only certified authentication method for LDAP-UX Client Services with Active Directory.

Each service can have up to three different search descriptors. The client uses the search descriptors in order until it finds what it is looking for.

	NOTE: The default search base DN for all requests will be set to the previously specified default search base DN (specified in step 12), usually the domain root. For very large databases, search performance can be greatly increased by specifying custom search descriptors. For example, to search user and group information, set the search base DN for the user and group services to CN=Users, DC=cup, DC=hp, DC=com.If your search filters overlap, enumeration requests will result in duplicate entries being returned. For example, if one search filter searched a subset of your organization and a second search filter searched your entire organization, an enumeration request would return duplicate entries. Refer to “Enumeration Requests”.

To begin the process to create custom search descriptors, setup will prompt you for the following information:

LDAP-UX Client Services supports the following services:
1.Password                              7.Networks
2.Shadow passwd                         8.Hosts
3.Group                                 9.Services
4.PAM (Pluggable Authentication Module)10.Printers
5.RPC                                  11.Automount
6 Protocols 

You can create up to three custom search descriptors for each name
service to search different locations in the directory.  
Do you want to create custom search descriptors? [No]:               

Enter 'yes' if you want to create custom search descriptors for any of the supported services. Then enter the number of the service for which you want to create a custom search descriptor.

If, you do not want to create custom search descriptors, enter 'no' to this prompt to continue to step 25 of the setup process.

Creating the Custom Search Filter for LDAP Printer Configurator Service

LDAP-UX Client Services uses the printlpd search filter for the printer service as default. The default object class, printerlprr, is not defined in the Windows Active Directory Server. To use the LDAP printer configurator feature, you must execute the following procedures to change default printerlpr object class for the printer service to the alternate object class to search a different location in the directory. As an example, the following procedures are used to change the default object class, printerlpr, to the alternate object class, printQueue:

Enter Yes to the question Are you ready to create the Profile Entry?, then press any key to continue.

At this point, you will choose whether or not to configure for Multiple Domains.

Reply to the question, Would you like to start/restart the LDAP-UX daemon.

Starting with LDAP-UX Client Services B.03.20 or later, the product daemon, /opt/ldapux/bin/ldapclientd, must be running for LDAP-UX functions to work. With LDAP-UX Client Services B.03.10 or earlier, running the client daemon, ldapclientd, is optional. For LDAP-UX Services B.03.10 or earlier, users need to start the LDAP-UX daemon in order to use multiple domains and X.500 features.

Create /etc/krb5.conf, the Kerberos configuration file which specifies the default realm, the location of a Key Distribution Center (KDC) server and the logging file names. The Kerberos client depends on the configuration to locate the realm's KDC. The following is an example of /etc/krb5.conf which has the realm CUP.HP.COM, and machine myhost.cup.hp.comas KDC:

default_realm = CUP.HP.COM
default_tgs_enctypes = DES-CBC-CRC
default_tkt_enctypes = DES-CBC-CRC 
ldapux_multidomain = 1 (this line adde only if using Mutiple Domains)
ccache_type = 2
[realms]
CUP.HP.COM = {
kdc = MYHOST.CUP.HP.COM:88
kpasswd_server = MYHOST.CUP.HP.COM:464
}
[domain_realm]
cup.hp.com = CUP.HP.COM 
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log

	NOTE: The permissions of the /etc/krb5.conf file should be set to 644 and ownership should be root user.

For Multiple Domains

For each domain you configure in LDAP-UX, you need to add its KDC entry into the /etc/krb5.conffile.

For a sample file that supports two domains, refer to“Sample /etc/krb5.conf File”.

Add the Kerberos services to the/etc/services file if they do not exist yet. A Kerberos client requires the following entries in the /etc/services file for the Kerberos PAM services:

kerberos5    88/udp   kdc  # Kerberos V5 kdc
kerberos5    88/tcp   kdc  # Kerberos V5 kdc
kerberos-sec 88/udp   kdc  # Kerberos V5 kdc
kerberos-sec 88/tcp   kdc  # Kerberos V5 kdc
kerberos     750/udp  kdc  # Kerberos V5 kdc
kerberos     750/tcp  kdc  # Kerberos V5 kdc
klogin       543/tcp       # Kerberos rlogin -kfall
kshell       544/tcp  cmd  # Kerberos remote shell
kerberos-adm 749/tcp       # Kerberos 5 admin/changepw
kerberos-adm 749/udp       # Kerberos 5 admin/changepw
krb5_prop    754/tcp       # Kerberos slave propagation
kerberos-adm 464/udp       # Kerberos Password Change protocol
kerberos-cpw 464/tcp       # Kerberos Password Change protocol

Add a host key to the /etc/krb5.keytab file

The keytab file is the one described in the previous section on Windows 2000 or 2003 using ktpass. You need to securely transfer the keytab file previously created to your HP-UX machine and name it krb5.keytab in the /etc directory. If you already have an existing/etc/krb5.keytab file, merge the new keytab file with the existing one.ktutil is a tool provided with the Kerberos product for you to maintain the keytab file.

	NOTE: The keytab file should only be readable by the root user.

Synchronize the HP-UX clock to the Windows 2000 or 2003 clock. These must be synchronized within two minutes. You can run Network Time Synchronizer to synchronize both clocks. If the tool is not available, you can manually synchronize them by setting "Date/Time Properties" on Windows 2000 or 2003 and running /etc/set_parms date_time on HP-UX.

Configure /etc/pam.conf, the PAM configuration file which specifies PAM service modules for PAM applications. To use PAM Kerberos as authentication module, edit /etc/pam.conf to include the PAM Kerberos library /usr/lib/security/libpam_krb5.1 for all four services: authentication, account management, session management, and password management. A sample PAM configuration file can be found in “Sample PAM Configuration File”.

	NOTE: The sample file reflects the recommendation to keep the root user in /etc/passwd local on each client machine, and to allow for local account management of the root user. This guarantees local access to the system in case the network is down.

Use the nsquery(1) command to test the name service:

nsquery lookup_type lookup_query [lookup_policy]

For example, to test the name service switch to resolve a username lookup, enter:

nsquery passwd username ldap

where usernameis the login name of a valid user whose POSIX account information is in the directory. You should see output something like the following depending on how you have configured /etc/nsswitch.conf:

Using "ldap" for the passwd policy.
Searching ldap for jbloggs
User name: jbloggs
user Id: 10000
Group Id: 2000
Gecos:
Home Directory: /home/jbloggs
Shell: /bin/sh
Switch configuration: Terminates Search

This tests the NSS configuration in /etc/nsswitch.conf. If you do not see output similar to above, check /etc/nsswitch.conf for proper configuration.

Use other commands to display information about users in the directory, making sure the output is as expected:

pwget -n username
grget -n groupname
ls -l

Use the beq search utility to search for the following services: pwd (password), grp (group), shd (shadow password), srv (service), prt (protocol), rpc (RPC), hst (host), net (network), ngp (netgroup), and grm (group membership). An example beq command using name as the search key, grp as the service, and ldap as the library is shown below.

./beq -k n -s grp -l /usr/lib/libnss_ldap.1 igrp1

nss_status........NSS_SUCCESS
pw_name...........(iuser1)
pw_passwd.........(*)
pw_uid............(101)
pw_gid............(21)
pw_age............()
pw_comment........()
pw_gecos..........(gecos data in files)
pw_dir............(/home/iuser1)
pw_shell..........(/usr/bin/sh)
pw_audid..........(0)
pw_audflg.........(0)

Refer to "beq Search Tool" in “Command, Tool, Schema Extension Utility, and Migration Script Reference” for command syntax and examples.

Log in to the client system from another system using rlogin or telnet. Log in as a user in the directory and as a user in /etc/passwd to make sure both work.

Optionally, test your pam_authz authorization configuration:

If the pam_authz is configured without the pam_authz.policy file, verify the followings:

If the pam_authz is configured with the pam_authz.policy file, verify the followings:

Open a new hpterm (1X) window and log in to the client system as a user whose account information is in the directory. It is important you open a new hpterm window or log in from another system because if login does not work, you could be locked out of the system and would have to reboot to single-user mode.

This tests the PAM configuration in /etc/pam.conf. If you cannot log in, check /etc/pam.conf for proper configuration. Also check your directory to make sure the user account information is accessible by the proxy user or anonymously, as appropriate. Check your profile to make sure it looks correct. Also refer to “Troubleshooting” for more information.

Use the ls (1) or ll (1) command to examine files belonging to a user whose account information is in the directory. Make sure the owner and group of each file are accurate:

If any owner or group shows up as a number instead of a user or group name, the name service switch is not functioning properly. Check the file /etc/nsswitch.conf, your directory, and your profile.

If you have configured a multi-domain setup and you want to verify it, execute the following two steps. Otherwise, continue below with “Step 8: Configure Subsequent Client Systems”.

The following steps will verify that LDAP-UX is able to retrieve data from ADS multiple domains:

Use swinstall to install LDAP-UX Client Services on the client system. This requires rebooting the client system.

Copy the following files from a configured client to the client being configured:

Download the profile by running get_profile_entry as follows:

If you are using multiple domains, download profiles for the GCS and each remote domain. Refer to “Command, Tool, Schema Extension Utility, and Migration Script Reference”, section titled "The get_profile_entry Tool" for information about downloading these profiles.

Alternatively you could interactively run the setup program to download the profile from the directory and respond No when prompted to select if you want to change the current configuration:

If you are using a proxy user, verify the proxy user by calling ldap_proxy_config as follows:

Refer to "Verify the LDAP-UX Client Services for Single Domain" for more information to verify the installation and configuration of your LDAP-UX Client Services.