Planning Your Installation

Will Active Directory be set up with a single domain or multiple domains?

Starting from the release of B.03.00, LDAP-UX allows you to store your password and group data in multiple domains. You need to decide if you want to store data in a single domain or multiple domains. If multiple domains are selected, decide how to group data into different domains. Data could be grouped based on organization, geography, or any variable appropriate to your environment.

If multiple domains are selected, how will data be stored in the forest?

LDAP-UX Client Services treats the first domain configured as the local domain, and all other domains in the forest as remote domains. When retrieving data, the search always starts from the local domain. Frequently accessed information should be stored in the local domain.

For remote domains, information can be stored in every remote domain or only in some remote domains. Determine the appropriate structure for your environment.

If multiple domains are selected, how will data be retrieved?

When multiple domains are selected, LDAP-UX Client Services has search rules for remote domains. For information about configuring the search sequence, refer to “Active Directory Multiple Domains”.

How many directory databases are needed?

Each client system binds to an Active Directory server containing your supported name service data (such as user and group data). On Active Directory networks, each domain controller contains a copy of the Active Directory database.

The specific number of domain controllers necessary in your network depends on the network size and configuration. A minimum of two Active Directory domain controllers are recommended for each domain. For more information, refer to the Active Directory documentation, or to http://www.microsoft.com/Windows2000 and http://windowsupdate.microsoft.com.

Where will you get your name service data when migrating the data to the directory?

You can get the data from:

For information about importing information into the directory, refer to “Importing Name Service Data into Your Directory”. For information on migration scripts, refer to “Command, Tool, Schema Extension Utility, and Migration Script Reference”.

To add an individual user entry or modify an existing user entry in your directory, use the ldapmodify command or other directory administration tools, such as the Active Directory Users and Computers interface tool.

	NOTE: Keep a small subset of users in /etc/passwd, particularly the root login. This allows administrative users to log in during installation and testing. Also, if the directory is unavailable you can still log in to the system.

Where will name service data be located in your directory?

LDAP-UX Client Services, by default, expect user and group data to use the object classes and attributes specified by RFC 2307. The migration scripts for Active Directory, by default, populate the existing Users container. “Example Directory Structure for a Single Domain” shows a base DN of DC=cup, DC=hp, DC=com.

If you prefer to merge your name service data into an existing directory structure, you can map the standard RFC 2307 attributes to alternate attributes. Refer to “LDAP-UX Client Services Object Classes”.

How will user and group data be migrated into your directory?

The migration scripts provided with LDAP-UX Client Services for Active Directory migrate all user and group data to the "Users" container.

If you merge your data into an existing directory, for example, to share user names and passwords with other applications, the migration scripts can create LDIF files of your user data, but you must write your own scripts or use other tools to merge the data into your directory. PosixAccount attributes can be added to your users already in the directory to leverage your existing directory data.

For information about importing information into the directory, refer to “Importing Name Service Data into Your Directory”. For information on migration scripts, refer to “Command, Tool, Schema Extension Utility, and Migration Script Reference”.

	CAUTION: If a root login is placed in the Active Directory, that user and password will be able to log in as root to any client using LDAP-UX Client Services. It is recommended that you keep the root user in /etc/passwd on each client system so the root user can be managed locally, and to allow local access to the system. It is not recommended to put the same users both in /etc/passwd and in the directory, as this could cause conflicts and unexpected behavior.

How many profiles do you need?

If you use ADS multiple domains, refer to “Active Directory Multiple Domains” for more information about configuring remote domains.

If ADS multiple domains are not used, refer to the following information.

A configuration profile is a directory entry that contains configuration information shared by a group of clients. The profile contains the information clients need to access user and group data in the directory. For example, this information includes:

If these parameters are the same for all your clients, you need only one profile. You will need at least one profile per Active Directory Domain Controller. In general, it is a good idea to have as few profiles as necessary to simplify maintenance. Refer to “LDAP-UX Client Services Object Classes” to decide how many different profiles you need.

If you are familiar with NIS, one example is to create a separate profile for each NIS domain.

Where will you put your profile in your directory?

The profile contains directory access information, specifying how and where clients can find user and group data in the directory. You can put the profile with your user data, or in a separate configuration area. Clients must have access to the profile and the user, as well as the group data. The following example shows a configuration profile DN of CN=profile1, CN=Configuration, DC=cup, DC=hp, DC=com.

Figure 2-1 Example Directory Structure for a Single Domain

Figure 2-2 Example Directory Structure for Multiple Domains

	NOTE: By default, the CN=configuration, DC=cup, DC=hp, DC=com configuration container only exists in the root domain. To create the standard profile path for each child domain, in LDAP-UX, you need to manually create the containers CN=Configuation in each child domain, using ADSI Edit before you run the setup tool to configure profiles.

Write your configuration profile DN on the worksheet in Appendix A.

By what method will client systems bind to the directory?

By default, Active Directory does not grant enough access rights to retrieve user and group information by anonymous access. Therefore, a proxy user needs to be configured.

Write your proxy user DN on the worksheet in Appendix A.

How will you set up /etc/pam.conf? What other authentication do you want to use and in what order?

PAM provides authentication services. You can configure PAM to use LDAP, Kerberos, or other traditional UNIX locations (for example: files, NIS, NIS+) as controlled by NSS. Refer to pam(3), pam.conf(4), and Managing Systems and Workgroups at http://docs.hp.com/hpux/os for more information on PAM.

Do you want to use SSL or TLS for secure communication between LDAP clients and the Windows 2000, 2003 or 2003 R2 Active Directory Server?

The LDAP-UX Client Services supports SSL or TLS with password as the credential, using either simple or SASL GSSAPI authentication (SASL GSSAPI is available for the Windows 2000, 2003 or 2003 R2 Active Directory Server only) to ensure confidentiality and data integrity between the clients and servers. StartTLS is a new extension operation of TLS (Transport Layer Security) protocol. You can utilize the startTLS operation to set TLS secure communication over an un-encrypted ( a regular) LDAP port. The secure connection can also be established on an encrypted LDAP port when using SSL. By default, SSL and TLS are disabled. For detailed information, refer to “Configuring the LDAP-UX Client Services with SSL or TLS Support”.

What authentication method will you use when you choose to enable TLS?

You have a choice between SIMPLE (the default), or SASL GSSAPI with TLS.

LDAP-UX Client Services includes support for the SASL Generic Security Services Application Programming Interface (GSSAPI) authentication method using Kerberos v5. Currently, Kerberos v5 is the only security mechanism that is implemented to work with GSSAPI. For this release, we only provide SASL GSSAPI authentication method support for Microsoft Windows 2000, 2003 or 2003 R2 Active Directory. SASL GSSAPI authentication is only for proxy user authentication for the name service subsystem. Host, service or other principles may be used for the LDAP-UX proxy identity. For detailed information on SASL GSSAPI support, see “SASL GSSAPI Support”.

What authentication method will you use when you choose to enable SSL?

You have a choice between SIMPLE (the default), or SASL GSSAPI with SSL.

What authentication method will you use when you choose to not enable SSL or TLS?

You have a choice between SIMPLE (the default), or SASL GSSAPI.

Do you want to specify the keytab file when you use SASL GSSAPI authentication.

LDAP-UX Client Services allows you to specify the keytab file when you use the SASL GSSAPI authentication. You can run the setup program to specify the keytab file. 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 file is used.

Do you want to store and manage automount maps in the LDAP directory? If so, the setup program can be used to import the new automount schema into your LDAP directory server.

LDAP-UX Client Services B.04.10 supports the automount service under the AutoFS subsystem. This new feature allows you to store or retrieve automount maps in/from an LDAP directory. LDAP-UX Client Services supports the new automount schema based on RFC2307-bis.

The setup program will import the new automount schema into your Directory Server.

For the detailed information about AutoFS with LDAP support, see the “LDAP-UX Client Services with AutoFS Support” chapter.

What name services will you use? How will you set up /etc/nsswitch.conf? What order do you want NSS to try services?

NSS is the Name Service Switch, providing naming services for user names, group names, and other information. You can configure NSS to use files, LDAP, or NIS in any order and with different parameters. Refer to /etc/nsswitch.ldap for an example nsswitch.conf file using files and LDAP. Refer to switch(4) and "Configuring the Name Service Switch" in Installing and Administering NFS Services at http://docs.hp.com/hpux/communications/ for more information.

It is recommended you use files first, followed by LDAP for passwd, group and other supported name services. With this configuration, NSS will first check files, then check the directory if the user or group is not in the respective files. /etc/nsswitch.ldap is an example of this configuration.

Do you need to set up login authorization for a subset of users from a large repository such as an LDAP directory? How will you set up the /etc/opt/ldapux/pam_authz.conf and /etc/pam.conf files to implement this feature?

The pam_authz service module for PAM provides functionality that allows the administrator to control who can login to the system. These modules are located at /usr/lib/security/libpam_authz.1 on the HP 9000 machine and at libpam_authz.so.1 on the Integrity (ia64) machine. pam_authz has been created to provide access control. Starting with LDAP-UX Client Services B.04.00, pam_authz has been enhanced to allow system administrators to configure and customize their local access rules in a local policy file, /etc/opt/ldapux/pam_authz.policy. pam_authz uses these access control rules defined in the local policy file to control the login authorization. Because pam_authz doesn't provide authentication, it doesn't verify if a user account exists.

If the /etc/opt/ldapux/pam_authz.policy file does not exist in the system, pam_authz performs access control based on the netgroup information found in the /etc/passwd and /etc/netgroup files. If the /etc/opt/ldapux/pam_authz.policy file exists in the system, pam_authz uses the access rules defined in the policy file to determine who can login to the system.

For detailed information on this feature and how to configure the /etc/opt/ldapux/pam_authz.policy file, see “PAM_AUTHZ Login Authorization ” or the pam_authz(5) man page.

Do you want to configure the /etc/opt/ldaux/pam_authz.policy to enforce account and password policies, stored in an LDAP directory server.

LDAP-UX provides pam_authz enhancement to support enforcement of account and password policies, stored in an LDAP directory server. This feature works in conjunction with SSH (Secure Shell), r-commands with rhost enabled where authentication is not performed via the PAM subsystem, but is performed by the command itself.

For detailed information on this feature and how to configure the pam_authz.policy file, see the “Account and Password Security Policy Enforcement” section in Chapter 7 for details.

How will you increase the security level of the product to prevent an unwanted user from logging in to the system using LDAP? What is the procedure to set up increased login security?

The default is to allow all users stored in the LDAP directory to login. To disallow specific users to login to a local system, you will have to configure the disable_uid_range flag in /etc/opt/ldapux/ldapux_client.conf file. There are two sections in this file, the [profile] section and the [NSS] section. HP recommends not editing the [profile] section. The [NSS] section contains the disable_uid_range flag, along with two logging flags. For example, the flag might look like:

disable_uid_range=0-100, 300-450, 189

Another common example would be to disable root access. This flag would look like:

disable_uid_range=0

This flag will prevent the users who have UNIX UIDs between 0 to 100, 300 to 450, or 189 from logging in to the local system.

When the disable_uid_range is turned on, the disabled uid will not be displayed when you run commands such as pwget, listusers, logins,and so on.

	NOTE: The passwdcommand may still allow you to change a password for a disabled user when alternative authentication methods, such as PAM Kerberos, are used since LDAP does not control these subsystems.

How will you communicate with your user community about the change to Active Directory?

For the most part, your user community should be unaffected by the directory. Most HP-UX commands will work as always.

Check the LDAP-UX Integration Release Notes for any other limitations and any solutions that have been developed to workaround them.