Plan Your Installation

How will you set up your Active Directory? Single domain? Multiple domains?

The LDAP-UX B.03.00 allows you to store your passwd 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 domain is chosen, you need to decide how you want to group your data into different domains. You could group your data based on organization, geography, or any choice which suites your environment.

If multiple domain is chosen, how will you store your data 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 dateless search always starts from the local domain. It is recommended that you store frequently accessed information in the local domain.

For remote domains, you could choose to store information in every remote domain, or some of remote domains, which ever make senses to your environment.

If multiple domain is chosen, how will you want the data retrieved?

When multiple domain is chosen, LDAP-UX Client Services has some rules to search data from remote domains. If you care about the search sequence, you need to follow the configuration described in "Configure the LDAP-UX Client Services"

How many directory databases will you need?

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 number of domain controllers necessary in your network depends on the size and configuration of your network. The recommendation is for a minimum of two Active Directory domain controllers per domain. For more information, please see the available literature on Active Directory. Useful information can also be found at http://www.microsoft.com/Windows2000 and http://windowsupdate.microsoft.com. Write your directory server host and TCP port number in Appendix A.

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

You can get it from /etc/passwd and /etc/group or, if you are using NIS, from the same source files you create your NIS maps from, or you can get it from your NIS maps themselves. Write this information in Appendix A.

See “Import Name Service Data into Your Directory” for how to import your information into the directory and "Name Service Migration Scripts" in Chapter 5 for details on the migration scripts.

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

	NOTE: You should 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 in your directory will you put your name service data?

Your directory architect needs to decide where in your directory to place your name service information. LDAP-UX Client Services by default expects 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. Write the base DN of your user and group data in Appendix A.

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. See LDAP-UX Client Services Object Classes.

How will you put your user and group data 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 will have to write your own scripts or use other tools to merge the data into your directory. You can add the posixAccount attributes to your users already in the directory to leverage your existing directory data.

See “Import Name Service Data into Your Directory” for how to import your information into the directory and Name Service Migration Scripts for details on the migration scripts.

	CAUTION: If you place a root login in the Active Directory, that user and password will be able to log in as root to any client using LDAP-UX Client Services. Keeping the root user in /etc/passwd on each client system allows the root user to be managed locally. This can be especially useful if the network is down because it allows local access to the system. It is not recommended that you put the same users both in /etc/passwd and in the directory. This could lead to conflicts and unexpected behavior.

How many profiles do you need?

If you will be using ADS multiple domains, you should refer to Chapter 3 for more information about configuring remote domains. If you will not be using ADS multiple domains, 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:

If these parameters are the same for all your clients, you would 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. Look at the posixNamingProfile object class in Appendix B, LDAP-UZ Client Services Object Classes to see what is in a profile 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 in your directory will you put your profile?

The profile contains directory access information. It specifies 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 & in what order?

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

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. See /etc/nsswitch.ldap for an example nsswitch.conf file using files and ldap. See 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 unwante d user from logging in to the system via 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 that you not edit the [profile] section. The [NSS] section contains the disable_uid_range flag along with two logging flags. For example, the flag might look like this: disable_uid_range=0-100, 300-450, 189.

Another common example would be to disable root access This flag would look like this: 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, etc.

	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 Release Notes for any other limitations and tell your users how they can work around them.