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 Chapter 3 “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 Appendix C “Command, Tool, 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. Figure 2-1 “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 Appendix B “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 Appendix C “Command, Tool, 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 Chapter 3 “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 Appendix B “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 for secure communication between LDAP clients and the Windows 2000 Active Directory Server?

The LDAP-UX Client Services B.03.20 supports password-based authentication with SSL enabled to ensure confidentiality and data integrity between the clients and servers. By default, SSL is disabled. For detailed information, refer to “Configuring the LDAP-UX Client Services with SSL Support”

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/#NFS 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.

How will you increase the security level of th e 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 passwd command 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 Client Services Release Notes for any other limitations and tell your users how they can work around them.