LDAP-UX Client Services B.04.15 with Microsoft Windows Active Directory Server Administrator's Guide (edition 8)
Table Of Contents
- LDAP-UX Client Services B.04.15 with Microsoft Windows Active Directory Administrator's Guide
- Table of Contents
- Preface
- 1 Introduction
- 2 Installing LDAP-UX Client Services
- Before You Begin
- Summary of Installing and Configuring LDAP-UX Client Services
- Planning Your Installation
- Installing LDAP-UX Client Services on a Client
- Configuring Active Directory for HP-UX Integration
- Step 1: Install Active Directory
- Step 2: Install SFU 2.0, 3.0 or 3.5 including Server for NIS
- Step 3: Create a Proxy User
- Step 4: Add an HP-UX Client Machine Account to Active Directory
- Step 5: Use ktpass to Create the Keytab File for the HP-UX client machine
- Step 6: Add POSIX Attributes into the Global Catalog
- Importing Name Service Data into Your Directory
- Configuring LDAP-UX Client Services
- Step 1: Run the Setup Program
- Step 2: Install the PAM Kerberos Product
- Step 3: Configure Your HP-UX Machine to Authenticate Using PAM Kerberos
- Step 4: Configure the Name Service Switch (NSS)
- Step 5: Configure the PAM Authorization Service Module (pam_authz)
- Step 6: Configure the Disable Login Flag
- Step 7: Verify LDAP-UX Client Services for Single Domain
- Step 8: Configure Subsequent Client Systems
- Configuring the LDAP-UX Client Services with SSL or TLS Support
- Downloading the Profile Periodically
- 3 Active Directory Multiple Domains
- 4 LDAP-UX Client Services with AutoFS Support
- 5 LDAP Printer Configurator Support
- 6 Dynamic Group Support
- 7 Administering LDAP-UX Client Services
- Using the LDAP-UX Client Daemon
- Integrating with Trusted Mode
- SASL GSSAPI Support
- PAM_AUTHZ Login Authorization
- Policy And Access Rules
- How Login Authorization Works
- PAM_AUTHZ Supports Security Policy Enforcement
- Policy File
- Policy Validator
- Dynamic Variable Support
- Constructing an Access Rule in pam_authz.policy
- Static List Access Rule
- Dynamic Variable Access Rule
- Security Policy Enforcement with Secure Shell (SSH) or r-commands
- Adding Additional Domain Controllers
- Adding Users, Groups, and Hosts
- User and Group Management
- Displaying the Proxy User's Distinguished Name
- Verifying the Proxy User
- Creating a New Proxy User
- Displaying the Current Profile
- Creating a New Profile
- Modifying a Profile
- Changing Which Profile a Client is Using
- Creating an /etc/krb5.keytab File
- Considering Performance Impacts
- Client Daemon Performance
- Troubleshooting
- 8 Modifying User Information
- 9 Mozilla LDAP C SDK
- A Configuration Worksheet
- B LDAP-UX Client Services Object Classes
- C Command, Tool, Schema Extension Utility, and Migration Script Reference
- LDAP-UX Client Services Components
- Client Management Tools
- LDAP User and Group Management Tools
- Environment Variables
- Return Value Formats
- Common Return Codes
- The ldapuglist Tool
- The ldapugadd Tool
- The ldapugmod Tool
- The ldapugdel Tool
- The ldapcfinfo Tool
- LDAP Directory Tools
- Schema Extension Utility
- Name Service Migration Scripts
- Unsupported Contributed Tools and Scripts
- D Sample PAM Configuration File
- E Sample /etc/krb5.conf File
- F Sample /etc/pam.conf File for HP-UX 11i v1 Trusted Mode
- G Sample /etc/pam.conf File for HP-UX 11i v2 Trusted Mode
- H Sample PAM Configuration File for Security Policy Enforcement
- Glossary
- Index

For information about importing information into the directory, refer to “Importing Name
Service Data into Your Directory” (page 35). For information on migration scripts, refer to
“Command, Tool, Schema Extension Utility, and Migration Script Reference” (page 163).
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” (page 57)
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:
— Your directory server hosts.
— Where your supported name service data is in 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 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” (page 159) 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
DC=cup, DC=hp, DC=com
CN=Configuration
CN=Users
profile
data
group
data
user
data
26 Installing LDAP-UX Client Services