LDAP-UX Client Services B.05.00 Administrator's Guide

has been made through the addition of a new caching daemon that caches passwd, group,
and X.500 group membership information retrieved from an LDAP server. This significantly
reduces LDAP-UX's response time to applications. To improve performance further, the
daemon re-uses connections for LDAP queries and maintains multiple connections to an
LDAP server.
The migration scripts provided with LDAP-UX Client Services can build and populate a
new directory subtree for your user and group data.
If you merge your data into an existing directory, such as 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 object class to your users already in the directory
to leverage your existing directory data.
For information about how to import your information into the directory, see Section 2.5.1
(page 90). For information about the migration scripts, see Section 7.6 (page 326) .
CAUTION: If you place a root login (any account with UID number 0) in the LDAP 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 when the network is down, because it
allows local access to the system when access to the directory server is unavailable.
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.
Note that LDAP-UX Client Services (version B.05.00 or later) offers offline, long-term
credential caching that enables LDAP-UX to authenticate users attempting to log in to the
system when credential information is unavailable from the directory server (when the
server or network is down, for example). For information about this feature and how to
configure it, see Section 2.5.4 (page 102).
NOTE: If you are planning a first-time deployment of managing user and group data in
the directory server, HP suggests that you devise a strategy to avoid UID number and GID
number overlap. Most likely, you will need to continue managing some accounts local to
the hosts. Often the root user, and sometimes application accounts (such as www for the
httpd process) remain managed in the local /etc/passwd file. Devise a convention
establishing a range for UID numbers and one for GID numbers such that accounts and
groups in LDAP do not conflict with those on local hosts. For example, accounts in LDAP
could all have UID numbers greater than 1000, while accounts on local hosts would be
restricted to UID numbers less than 1000.
For information about ensuring that user and group numbers to be migrated or imported
into a new directory server do not collide with the ones created by the guided installation,
see Section 2.5.1.1 (page 90).
• How many profiles do you need?
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:
— Your directory server hosts
— Where user, group, and other information is in the directory
— The method clients use to bind to the directory
— Other configuration parameters such as search time limits
If these parameters are the same for all your clients, you need only one profile. You need at
least one profile per directory server or replica. In general, to simplify maintenance, it is a
60 Installing and configuring LDAP-UX Client Services