LDAP-UX Client Services B.05.01 Administrator Guide

LDAP-UX Client Services B.05.01
Administrator Guide
Integrating with HP Directory Servers and Microsoft
Windows Active Directory Servers
Abstract
This document describes how to install, configure, and manage the LDAP-UX Client Services product on HP-UX platforms in
conjunction with LDAP-capable directory servers including HP-UX Directory Server, Red Hat Directory Server for HP-UX, and
Microsoft Windows Active Directory Server (ADS). This document is intended for system and network administrators responsible
for installing, configuring, and managing the LDAP-UX Client Services. Administrators are expected to have knowledge of the
LDAP-UX Client Services Integration product.
HP Part Number: 5900-1479
Published: December 2010
Edition: 2.0
© Copyright 2008 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall
not be liable for technical or editorial errors or omissions contained herein.
HP CIFS Server is derived from the Open Source Samba product and is subject to the GPL license.
Trademark Acknowledgements
UNIX® is a registered trademark of The Open Group. Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.
The following table lists the publication history of this document. Search for more recent updates of the document at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
Table 1 Publishing history details
Document manufacturing part number
Operating systems supported Supported product versions Publication date
5900-1479 Edition 2.0
11i v2 and v3
B.05.01
December 2010
5900-1086 Edition 1.0
11i v2 and v3
B.05.01
October 2010
J4269-90086 Edition 1.0
11i v2 and v3
B.05.00.00
June 2010
J4269-90083
11i v1, v2, and v3
B.04.15
October 2007
J4269-90075
11i v1, v2, and v3
B.04.15
August 2007
J4269-90073
11i v1, v2, and v3
B.04.10
April 2007
J4269-90067
11i v1, v2, and v3
B.04.10
December 2006
J4269-90053
11i v1, v2, and v3
B.04.00
June 2006
J4269-90051
11i v1 and v2
B.04.00
August 2005
J4269-90048
11i v1 and v2
B.04.00
July 2005
J4269-90040
11.0, 11i v1 and v2
B.03.30
September 2004
J4269-90038
11.0, 11i v1
B.03.30
July 2004
J4269-90030
11.0, 11i v1 and v2
B.03.20
October 2003
J4269-90016
11.0, 11i
B.03.00
September 2002
NOTE:
The document printing date and part number indicate the current edition of the document. The printing date changes when a new
edition is printed. Minor changes might be made at reprint without changing the printing date. The document part number changes when
extensive changes are made.
Document updates might be issued between editions to correct errors or document product changes. To ensure that you receive the updated
or new editions, you should subscribe to the appropriate product support service. For more information, see your HP sales representative.
You can search for updates of this and related documents at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
Contents
1 Introduction.............................................................................................17
1.1 Overview of LDAP-UX Client Services....................................................................................17
1.2 How LDAP-UX Client Services works.....................................................................................19
1.3 Domains in LDAP-UX environments.......................................................................................22
1.4 Administrators and managers in the LDAP-UX directory server environment...............................23
2 Installing and configuring LDAP-UX Client Services for an HP server
environment................................................................................................25
2.1 Before you begin: general installation and configuration considerations for an HP server
environment...........................................................................................................................25
2.2 Selecting the method of installation: guided or customized.....................................................26
2.3 Guided installation (autosetup) for an HP directory server environment.....................................27
2.3.1 What autosetup does.................................................................................................30
2.3.2 Principles of the LDAP-UX domain................................................................................31
2.3.2.1 Directory information tree....................................................................................32
2.3.2.2 Information model..............................................................................................34
2.3.2.2.1 Managed objects and how they are defined..................................................34
2.3.2.2.2 Domain entity classification schema..............................................................36
2.3.2.3 Security framework.............................................................................................37
2.3.2.3.1 Proxy users................................................................................................37
2.3.2.3.2 Access control rights...................................................................................38
2.3.2.3.3 SSL/TLS and CA/server certificates...............................................................39
2.3.3 Using the guided installation autosetup command—syntax and options for HP directory
server environments............................................................................................................41
2.3.3.1 autosetup options...............................................................................................41
2.3.3.2 autosetup environment variables..........................................................................43
2.3.3.3 autosetup command examples.............................................................................46
2.3.4 Guided installation steps: New Directory Server Installation mode...................................46
2.3.4.1 Interactively running New Directory Server Installation mode ...................................47
2.3.4.2 Automating New Directory Server Installation mode...............................................50
2.3.4.3 Postinstallation steps for New Directory Server Installation mode..............................52
2.3.5 Guided installation steps: Existing Directory Server Installation mode................................52
2.3.5.1 Interactively running Existing Directory Server Installation mode................................52
2.3.5.2 Automating Existing Directory Server Installation mode...........................................54
2.3.5.3 Postinstallation steps for Existing Directory Server Installation mode ..........................54
2.3.6 Guided installation steps: Existing LDAP-UX Domain Installation mode..............................55
2.3.6.1 Interactively running Existing LDAP-UX Domain Installation mode...............................55
2.3.6.2 Automating Existing LDAP-UX Domain Installation mode..........................................57
2.3.6.3 Postinstallation steps for Existing LDAP-UX Domain Installation mode ........................57
2.4 Customized installation (setup) for an HP directory server environment.....................................57
2.4.1 Summary of customized installation and configuration steps............................................58
2.4.2 Planning for your customized installation and configuration.............................................59
2.4.3 Installing LDAP-UX Client Services on a client................................................................65
2.4.4 Configuring your HP directory server directory..............................................................65
2.4.5 Configuring LDAP-UX Client Services for an HP directory server environment.....................67
2.4.5.1 Quick configuration............................................................................................69
2.4.5.2 Custom configuration.........................................................................................72
2.4.5.3 Remapping attributes for services.........................................................................75
2.4.6 Configuring LDAP-UX Client Services with SSL or TLS support..........................................78
2.4.6.1 Supported authentication methods and their strengths and weaknesses.....................79
Contents
3
2.4.6.2 Steps for configuring LDAP-UX Client Services with SSL or TLS support.......................80
2.4.6.3 Adjusting the peer certificate policy.....................................................................81
2.4.6.3.1 Modifying preferredServerList in the LDAP-UX profile .......................................82
2.4.6.4 Creating certificate database files using the certutil utility........................................82
2.4.6.5 SSL/TLS ciphers.................................................................................................84
2.4.7 Configuring LDAP-UX Client Services with NIS publickey support.....................................85
2.4.7.1 HP-UX Enhanced Publickey-LDAP software requirement.............................................85
2.4.7.2 Extending the NIS publickey schema into your directory..........................................85
2.4.7.3 Admin Proxy user...............................................................................................86
2.4.7.3.1 Configuring an Admin Proxy user by using ldap_proxy_config..........................86
2.4.7.3.2 Password for an Admin Proxy user................................................................86
2.4.7.4 Setting ACI for key management..........................................................................86
2.4.7.4.1 Setting ACI for an Admin Proxy user.............................................................86
2.4.7.4.2 Setting ACI for a user.................................................................................87
2.4.7.5 Configuring the serviceAuthenticationMethod attribute............................................87
2.4.7.5.1 Authentication methods................................................................................87
2.4.7.5.2 Procedures used for configuring the serviceAuthenticationMethod attribute.........88
2.4.7.6 Configuring NSS...............................................................................................89
2.5 Postinstallation configuration tasks.......................................................................................89
2.5.1 Importing name service data into your directory.............................................................89
2.5.1.1 Prevent user and group number collisions with those created by autosetup..................90
2.5.1.2 Steps for importing name service data into your directory........................................91
2.5.2 Verifying LDAP-UX Client Services................................................................................91
2.5.3 Enabling AutoFS support............................................................................................94
2.5.3.1 Automount schemas............................................................................................94
2.5.3.1.1 automount schema based on RFC 2307-bis.....................................................94
2.5.3.1.2 nisObject automount schema........................................................................95
2.5.3.2 Attribute mappings between RFC 2307-bis and nisObject schema............................96
2.5.3.3 Configuring NSS to enable LDAP support for AutoFS..............................................97
2.5.3.4 Configuring automount caches............................................................................97
2.5.3.5 AutoFS migration scripts......................................................................................97
2.5.3.5.1 Environment variables..................................................................................98
2.5.3.5.2 General syntax for migration scripts..............................................................98
2.5.3.5.3 migrate_automount.pl script.........................................................................98
2.5.3.5.4 migrate_nis_automount.pl script....................................................................99
2.5.3.5.5 migrate_nisp_autofs.pl script......................................................................100
2.5.4 Enabling offline longterm credential caching for authentication when the directory server
is unavailable..................................................................................................................101
2.5.4.1 How the offline cache works..............................................................................101
2.5.4.2 Configuring the offline cache............................................................................102
2.5.5 Enabling integrated Compat Mode to control name services and user logins...................102
2.5.5.1 Overview........................................................................................................102
2.5.5.2 Netgroups in LDAP...........................................................................................103
2.5.5.3 Configuring integrated Compat Mode................................................................103
2.5.5.3.1 Limitations................................................................................................104
2.5.6 Controlling user access to the system through LDAP......................................................104
2.5.6.1 Using the disable login flag to prevent access to the local system by unwanted users
................................................................................................................................105
2.5.6.2 Using the deny_local option to prevent access to the local system by unwanted
users.........................................................................................................................105
2.5.6.3 Configuring PAM_LDAP authentication to ignore specific users...............................108
2.5.7 Configuring subsequent client systems........................................................................110
2.5.8 Downloading the profile periodically.........................................................................111
2.5.9 Enabling use of r-commands for PAM_LDAP................................................................112
4
Contents
3 Installing and configuring LDAP-UX Client Services for a Windows ADS
environment..............................................................................................114
3.1 Before you begin: general installation and configuration considerations for a Windows ADS
environment.........................................................................................................................114
3.2 Selecting the method of installation: guided or customized...................................................114
3.3 Guided installation (autosetup) for a Windows ADS environment...........................................115
3.3.1 What autosetup does...............................................................................................117
3.3.2 Using the guided installation autosetup command—syntax and options for Windows ADS
environments...................................................................................................................118
3.3.2.1 autosetup options.............................................................................................119
3.3.2.2 autosetup environment variables........................................................................120
3.3.2.3 autosetup command examples...........................................................................121
3.3.3 Guided installation steps: First Installation into a Windows Domain mode.......................122
3.3.3.1 Interactively running First Installation into a Windows Domain mode.......................122
3.3.3.2 Automating First Installation into a Windows Domain mode...................................124
3.3.3.3 Postinstallation steps for First Installation into a Windows Domain mode .................124
3.3.4 Guided installation steps: Existing Windows LDAP-UX Configuration mode......................124
3.3.4.1 Interactively running Existing Windows LDAP-UX Configuration mode......................125
3.3.4.2 Automating Existing Windows LDAP-UX Configuration mode.................................127
3.3.4.3 Postinstallation steps for Existing Windows LDAP-UX Configuration mode ................127
3.4 Customized installation (setup) for a Windows ADS environment...........................................127
3.4.1 Summary of installing and configuring LDAP-UX Client Servicesconfigurationsummary for
customized (setup)Windows ADS environmentinstallationsummary for customized (setup)Windows
ADS environmentLDAP-UX configuration and installationsummary for Windows ADS
environment....................................................................................................................127
3.4.2 Tasks that must be performed to implement Kerberos support........................................128
3.4.3 Planning your customized installation.........................................................................129
3.4.4 Installing LDAP-UX Client Services on a client..............................................................134
3.4.5 Configuring Windows Active Directory for HP-UX integration........................................135
3.4.5.1 Step 1: Install Active DirectoryinstallationActive DirectoryActive Directoryinstalling.....135
3.4.5.2 Step 2: Create a proxy user..............................................................................136
3.4.5.3 Step 3: Add an HP-UX client machine account to Active Directory..........................137
3.4.5.4 Step 4: Use ktpass to create the keytab file for the HP-UX client machine.................137
3.4.5.4.1 Validating the host user principal................................................................138
3.4.5.5 Step 5: Add POSIX attributes into the global catalog if multiple domains are
deployed...................................................................................................................138
3.4.6 Configuring LDAP-UX Client Services for a Windows ADS environment...........................138
3.4.6.1 Step 1: Install the PAM Kerberos product ............................................................139
3.4.6.2 Step 2: Run the setup program..........................................................................139
3.4.6.2.1 Remapping attributes for services................................................................146
3.4.6.3 Step 3: Configure your HP-UX machine to authenticate using PAM Kerberos............149
3.4.6.4 Step 4: Configure NSS.....................................................................................150
3.4.6.5 Step 5: Configure the PAM Authorization Service Module (PAM_AUTHZ)................150
3.4.6.6 Step 6: Configure the disable login flag.............................................................151
3.4.7 Configuring LDAP-UX Client Services with SSL or TLS support........................................151
3.5 Postinstallation configuration tasks.....................................................................................151
3.5.1 Importing name service data into your directory...........................................................151
3.5.1.1 Prevent user and group number collisions with those already on the HP-UX host.........152
3.5.1.2 Steps for importing name service data.................................................................152
3.5.2 Verifying LDAP-UX Client Services for Single Domain....................................................152
3.5.3 Enabling AutoFS support..........................................................................................152
3.5.3.1 Automount schema...........................................................................................152
3.5.3.2 Configuring NSS to enable LDAP support for AutoFS............................................153
3.5.3.3 Configuring automount caches..........................................................................154
Contents
5
3.5.3.4 AutoFS migration scripts...................................................................................154
3.5.3.4.1 Environment variables...............................................................................154
3.5.3.4.2 General syntax for migration scripts............................................................155
3.5.3.4.3 migrate_automount_ads.pl script................................................................155
3.5.3.4.4 migrate_nis_automount_ads.pl script...........................................................156
3.5.4 Controlling user access to the system through LDAP......................................................157
3.5.4.1 Using the disable_uid_range flag to prevent access to the local system by unwanted
users ........................................................................................................................157
3.5.5 Configuring subsequent client systems........................................................................157
3.5.6 Downloading the profile periodically.........................................................................158
3.6 Unconfiguring LDAP-UX (removing the host from the ADS domain).........................................158
4 Windows Active Directory multiple domains...............................................159
4.1 Domain term definitions...................................................................................................159
4.1.1 Multiple domains......................................................................................................159
4.1.2 Local domains.........................................................................................................159
4.1.3 Remote domains......................................................................................................159
4.1.4 Global Catalog Server.............................................................................................159
4.2 Retrieving data from a remote domain...............................................................................159
4.2.1 Choosing Remote Domain Configuration or GCS.........................................................160
4.3 Downloading an automatic profile....................................................................................160
4.4 Understanding the ldapux_client.conf configuration file........................................................161
4.5 Resolving duplicate entries...............................................................................................162
4.5.1 When there are duplicate entries in the local domain...................................................162
4.5.2 When there are duplicate entries in remote domains....................................................162
4.5.3 When there are duplicate entries in both local and remote domains..............................162
4.5.4 Example................................................................................................................162
4.6 Changing multiple domain configurations..........................................................................163
4.6.1 Removing a remote domain from the search scope.......................................................163
4.6.2 Adding a remote domain to the search scope.............................................................163
4.6.3 Reordering the remote domain search sequence..........................................................163
4.6.4 Adding the GCS into the search scope......................................................................163
4.6.5 Removing the GCS from the search scope..................................................................163
4.6.6 Adding POSIX attributes to the global catalog............................................................163
4.7 Limitations of multiple domains in version B.03.00 or later...................................................164
5 LDAP printer configurator support.............................................................165
5.1 Overview.......................................................................................................................165
5.1.1 Definitions...............................................................................................................165
5.1.1.1 Printer services...................................................................................................165
5.1.1.2 Printing protocol................................................................................................165
5.1.1.3 LP printer types..................................................................................................165
5.2 How the LDAP printer configurator works...........................................................................165
5.3 Printer configuration parameters........................................................................................168
5.4 Printer schema ...............................................................................................................168
5.4.1 Printer schema in an HP directory server environment...................................................168
5.4.1.1 Example of a printer object entry........................................................................168
5.4.2 Printer schema in a Windows ADS environment..........................................................168
5.4.2.1 Printer attributes...............................................................................................169
5.4.2.1.1 Default printer attributes.............................................................................169
5.4.2.1.2 Printer attribute mappings..........................................................................169
5.5 Managing the LP printer configuration...............................................................................170
5.6 Limitations of the LDAP printer configurator.........................................................................172
6
Contents
6 Dynamic group support...........................................................................173
6.1 Overview.......................................................................................................................173
6.2 Creating an HP-UX dynamic group ...................................................................................173
6.2.1 Creating an HP-UX POSIX dynamic group in an HP directory server environment..............173
6.2.1.1 Step 1: Creating a dynamic group.......................................................................173
6.2.1.2 Step 2: Adding POSIX attributes to a dynamic group.............................................174
6.2.2 Creating an HP-UX POSIX dynamic group in a Windows ADS environment.....................175
6.2.2.1 Step 1: Creating a dynamic group (an LDAP query group).....................................175
6.2.2.2 Step 2: Adding POSIX attributes to a dynamic group............................................176
6.2.2.3 Step 3: Setting read permissions for the proxy user..............................................176
6.2.3 Changing an HP-UX POSIX static group to a dynamic group.........................................176
6.2.4 Enabling dynamic group support...............................................................................177
6.3 Multiple group attribute mappings....................................................................................178
6.3.1 Multiple group attribute mapping examples.................................................................178
6.4 Number of group members returned..................................................................................180
6.5 Number of groups returned for a specific user....................................................................180
6.6 Performance impact for dynamic groups............................................................................181
6.6.1 Enabling and disabling enable_dynamic_getgroupsbymember......................................181
6.7 Configuring dynamic group caches...................................................................................181
7 Administering LDAP-UX Client Services......................................................182
7.1 Managing the LDAP-UX client daemon................................................................................182
7.1.1 Overview.................................................................................................................182
7.1.2 Using the ldapclientd administration tool.....................................................................182
7.1.2.1 Starting the client...............................................................................................182
7.1.2.2 Controlling the client..........................................................................................183
7.1.2.3 Improving client daemon performance.................................................................183
7.1.2.4 Command options.............................................................................................183
7.1.2.5 Diagnostics......................................................................................................183
7.1.2.6 Warnings........................................................................................................184
7.1.3 ldapclientd.conf configuration file...............................................................................184
7.1.3.1 Configuration file syntax.....................................................................................184
7.1.3.1.1 Section details............................................................................................185
7.1.3.2 Example Configuration file.................................................................................191
7.2 Integrating LDAP-UX with Trusted Mode..............................................................................194
7.2.1 Overview................................................................................................................194
7.2.2 Features and limitations............................................................................................194
7.2.2.1 Auditing..........................................................................................................194
7.2.2.2 Password and account policies...........................................................................195
7.2.2.3 PAM configuration file......................................................................................195
7.2.2.4 Limitations.......................................................................................................196
7.2.3 Configuration parameter...........................................................................................196
7.3 Configuring SASL/GSSAPI support for proxy user authentication (Windows ADS only).............196
7.3.1 How SASL/GSSAPI works.........................................................................................197
7.3.2 Configuring the proxy user........................................................................................197
7.3.2.1 Configuring the user principal............................................................................197
7.3.2.2 Service/host principal and keys.........................................................................197
7.3.2.3 Configuring a principal as the proxy user............................................................198
7.3.3 Keytab file..............................................................................................................198
7.3.4 Downloading SASL/GSSAPI profiles...........................................................................199
7.3.5 Changing authentication methods..............................................................................199
7.4 Configuring PAM_AUTHZ login authorization .....................................................................199
7.4.1 Policy and access rules.............................................................................................200
7.4.2 How login authorization works..................................................................................200
Contents
7
7.4.3 PAM_AUTHZ security policy enforcement....................................................................201
7.4.3.1 Authentication using PAM..................................................................................202
7.4.3.2 Authentication with secure shell (ssh) and r-commands..........................................202
7.4.4 Policy file................................................................................................................202
7.4.5 Policy validator........................................................................................................203
7.4.5.1 Example of access rule evaluation......................................................................203
7.4.6 Dynamic variable support.........................................................................................204
7.4.7 Constructing an access rule in the access policy file.....................................................204
7.4.7.1 Fields in an access rule......................................................................................204
7.4.8 Static list access rule................................................................................................208
7.4.9 Dynamic variable access rule ...................................................................................209
7.4.9.1 Supported functions for dynamic variables...........................................................209
7.4.9.2 Example of a dynamic variable access rule.........................................................210
7.4.10 Security policy enforcement with secure shell (ssh) or r-commands.................................210
7.4.10.1 Security policy enforcement access rule .............................................................210
7.4.10.1.1 Example of access rules.............................................................................212
7.4.10.2 Configuring access permissions for global policy attributes...................................212
7.4.10.3 Configuring the PAM configuration file..............................................................213
7.4.10.4 Evaluating the directory server security policy.....................................................213
7.4.10.5 PAM return codes ..........................................................................................214
7.4.10.6 Directory server security policies.......................................................................214
7.5 Adding an HP directory server directory replica..................................................................217
7.6 Adding additional Windows domain controllers..................................................................217
7.7 Managing users and groups.............................................................................................218
7.7.1 LDAP command-line tools for managing HP directory server and Windows ADS users and
groups............................................................................................................................218
7.7.1.1 Listing users (ldapuglist)......................................................................................220
7.7.1.2 Listing groups (ldapuglist)...................................................................................221
7.7.1.3 Adding a user or a group (ldapugadd)................................................................222
7.7.1.3.1 Adding users to an HP directory server or Windows ADS................................223
7.7.1.3.2 Adding a group........................................................................................225
7.7.1.3.3 Modifying defaults in /etc/opt/ldapux/ldapug.conf .....................................226
7.7.1.4 Modifying a user (ldapugmod)............................................................................227
7.7.1.5 Modifying a group (ldapugmod).........................................................................228
7.7.1.6 Deleting a user or a group (ldapugdel)................................................................229
7.7.1.7 Examining the LDAP-UX configuration ..................................................................231
7.7.1.7.1 Verifying whether LDAP-UX is configured........................................................231
7.7.1.7.2 Listing available templates...........................................................................231
7.7.1.7.3 Discovering required attributes.....................................................................232
7.7.1.7.4 Displaying configuration defaults..................................................................232
7.7.1.7.5 Displaying the DN of the LDAP-UX profile......................................................232
7.7.1.7.6 Displaying default search base....................................................................233
7.7.1.7.7 Displaying recommended attributes..............................................................233
7.7.1.7.8 Displaying attribute mapping for a specific name service.................................234
7.7.2 Windows utilities for managing Windows ADS users, groups, and hosts.........................234
7.8 Managing hosts in an LDAP-UX domain.............................................................................235
7.8.1 Adding a host.........................................................................................................235
7.8.2 Modifying a host.....................................................................................................237
7.8.3 Deleting a host........................................................................................................237
7.8.4 Managing IP addresses............................................................................................238
7.8.5 Managing hosts in groups........................................................................................239
7.8.6 Classifying hosts......................................................................................................240
7.8.7 Managing process access rights (proxy_is_restricted)...................................................241
7.9 Managing proxy users.....................................................................................................242
7.9.1 Displaying the proxy user's DN..................................................................................242
8
Contents
7.9.2 Verifying the proxy user............................................................................................242
7.9.3 Creating a new proxy user........................................................................................242
7.9.4 Changing from anonymous access to proxy access......................................................244
7.9.5 Changing from proxy access to anonymous access......................................................244
7.10 Managing the LDAP-UX configuration profile......................................................................244
7.10.1 Displaying the current configuration profile.................................................................244
7.10.2 Modifying a configuration profile.............................................................................245
7.10.2.1 Using ldapentry to modify a profile....................................................................245
7.10.2.2 Using Windows ADSI and ADSIedit to modify a profile.......................................245
7.10.3 Creating a new configuration profile.........................................................................246
7.10.4 Specifying a different profile for client use..................................................................246
7.11 Creating an /etc/krb5.keytab file.....................................................................................246
7.12 Performance considerations.............................................................................................246
7.12.1 Reducing the performance impact of enumeration and search requests...........................247
7.12.1.1 Minimizing enumeration requests for less impact on server and network
performance...............................................................................................................247
7.12.1.2 Setting search limits to reduce resource consumption and denial of service
vulnerabilities.............................................................................................................247
7.12.1.3 Setting search filters to improve enumeration performance.....................................248
7.12.2 Client daemon performance considerations................................................................248
7.12.2.1 ldapclientd caching.........................................................................................248
7.12.2.2 ldapclientd persistent connections......................................................................250
7.13 Troubleshooting.............................................................................................................251
7.13.1 Enabling and disabling LDAP-UX logging...................................................................251
7.13.2 Enabling and disabling PAM logging........................................................................252
7.13.3 Viewing log files for errors and unexpected events......................................................253
7.13.4 Troubleshooting user problem with client system logins.................................................253
8 Managing ssh host keys with LDAP-UX (HP directory servers only).................258
8.1 Overview.......................................................................................................................258
8.1.1 How it works............................................................................................................258
8.1.2 Secure framework....................................................................................................259
8.1.3 Permissions..............................................................................................................261
8.1.4 Distributed management (manage from any host).........................................................261
8.2 Setting up the key management domain............................................................................261
8.2.1 Host repository........................................................................................................262
8.2.2 Data location.........................................................................................................262
8.2.3 Trust......................................................................................................................262
8.2.4 Validating directory server identity............................................................................263
8.2.5 Authentication and access control..............................................................................263
8.2.6 Administrative users.................................................................................................264
8.3 Managing keys in the directory server...............................................................................265
8.3.1 Configuring ssh and sshd to use LDAP-managed keys...................................................266
8.3.2 Adding keys for HP-UX hosts.....................................................................................266
8.3.3 Adding keys for nonHP-UX hosts or devices.................................................................268
8.3.4 Adding keys in a batch............................................................................................268
8.3.5 Changing keys for HP-UX hosts.................................................................................269
8.3.6 Changing key size..................................................................................................269
8.3.7 Changing keys for nonHP-UX hosts............................................................................270
8.3.8 Revoking or removing keys.......................................................................................271
8.4 Managing key age.........................................................................................................271
8.4.1 Setting advisory key expiration dates.........................................................................271
8.4.2 Key auditing...........................................................................................................272
8.5 Centrally managing ssh configuration................................................................................272
Contents
9
8.5.1 Overriding central configuration................................................................................274
8.6 Distributing keys to nonHP-UX hosts...................................................................................274
9 Command and tool reference...................................................................276
9.1 The LDAP-UX Client Services components............................................................................276
9.2 Client management tools..................................................................................................278
9.2.1 The create_profile_entry tool......................................................................................279
9.2.1.1 Syntax.............................................................................................................279
9.2.2 The create_profile_cache tool....................................................................................279
9.2.2.1 Syntax............................................................................................................279
9.2.2.2 Examples........................................................................................................279
9.2.3 create_profile_schema tool........................................................................................279
9.2.3.1 Syntax............................................................................................................280
9.2.4 The display_profile_cache tool..................................................................................280
9.2.4.1 Syntax............................................................................................................280
9.2.4.2 Examples........................................................................................................280
9.2.5 The get_profile_entry tool.........................................................................................280
9.2.5.1 Syntax............................................................................................................280
9.2.5.2 Examples........................................................................................................280
9.2.6 The ldap_proxy_config tool.......................................................................................280
9.2.6.1 Syntax............................................................................................................281
9.2.6.2 Examples........................................................................................................282
9.3 LDAP user and group management tools............................................................................283
9.3.1 Environment variables...............................................................................................284
9.3.2 Return value formats.................................................................................................285
9.3.3 Common return codes..............................................................................................285
9.3.4 The ldapuglist tool...................................................................................................287
9.3.4.1 Synopsis ........................................................................................................287
9.3.4.2 Options..........................................................................................................287
9.3.4.3 Arguments......................................................................................................289
9.3.4.4 Output format..................................................................................................291
9.3.4.5 Special considerations for output format..............................................................292
9.3.4.5.1 Multi-values attributes................................................................................292
9.3.4.5.2 NonPOSIX accounts and groups................................................................293
9.3.4.5.3 Encoding of the DN..................................................................................293
9.3.4.5.4 Passwords...............................................................................................293
9.3.4.6 Specific return codes for ldapuglist.....................................................................293
9.3.4.7 Limitations......................................................................................................294
9.3.4.8 Examples........................................................................................................294
9.3.5 The ldapugadd tool.................................................................................................296
9.3.5.1 Syntax translation.............................................................................................297
9.3.5.2 Synopsis.........................................................................................................297
9.3.5.3 Options..........................................................................................................297
9.3.5.4 Arguments......................................................................................................298
9.3.5.4.1 Arguments applicable to -D........................................................................299
9.3.5.4.2 Arguments applicable to -t passwd.............................................................299
9.3.5.4.3 Arguments applicable to -t group................................................................303
9.3.5.5 LDAP User and Group (UG) tool configuration file................................................305
9.3.5.6 Template files..................................................................................................306
9.3.5.6.1 Template file naming ................................................................................306
9.3.5.6.2 Default template files................................................................................306
9.3.5.6.3 Defining template files...............................................................................308
9.3.5.6.4 Multi-valued attributes in template files........................................................309
9.3.5.7 Security considerations.....................................................................................309
10
Contents
9.3.5.8 Specific return codes for ldapugadd...................................................................310
9.3.5.9 Limitations.......................................................................................................311
9.3.5.10 Examples.......................................................................................................311
9.3.6 The ldapugmod tool.................................................................................................313
9.3.6.1 Synopsis.........................................................................................................313
9.3.6.2 Options..........................................................................................................314
9.3.6.3 Arguments......................................................................................................315
9.3.6.3.1 Options applicable to -t passwd..................................................................317
9.3.6.3.2 Options applicable to -t group...................................................................319
9.3.6.4 Warnings.......................................................................................................320
9.3.6.5 Specific return codes for ldapugmod..................................................................322
9.3.6.6 Security considerations.....................................................................................322
9.3.6.7 Limitations.......................................................................................................323
9.3.6.8 Examples........................................................................................................323
9.3.7 The ldapugdel tool..................................................................................................324
9.3.7.1 Removing attributes only....................................................................................324
9.3.7.2 Synopsis ........................................................................................................324
9.3.7.3 Options..........................................................................................................324
9.3.7.4 Arguments.......................................................................................................325
9.3.7.5 Specific return codes for ldapugdel.....................................................................327
9.3.7.6 Security considerations.....................................................................................328
9.3.7.7 Limitations.......................................................................................................328
9.3.7.8 Examples........................................................................................................328
9.3.8 The ldaphostmgr tool...............................................................................................329
9.3.8.1 Synopsis.........................................................................................................329
9.3.8.2 Options and arguments....................................................................................330
9.3.8.3 Object classes.................................................................................................337
9.3.8.4 How ldaphostmgr binds to the directory server....................................................337
9.3.8.5 Security Considerations....................................................................................338
9.3.8.6 Usage Notes...................................................................................................338
9.3.8.7 Errors and Warnings........................................................................................339
9.3.8.8 External Influences...........................................................................................340
9.3.8.8.1 Environment Variables...............................................................................340
9.3.8.8.2 LDAP-UX Profile........................................................................................340
9.3.8.9 Limitations......................................................................................................340
9.3.8.10 Examples.......................................................................................................340
9.3.8.11 Resources for more information.........................................................................340
9.3.9 The ldaphostlist tool.................................................................................................340
9.3.9.1 Synopsis..........................................................................................................341
9.3.9.2 Options and arguments....................................................................................341
9.3.9.3 Output format..................................................................................................345
9.3.9.4 Special considerations for output format..............................................................346
9.3.9.5 How ldaphostlist binds to the directory server......................................................346
9.3.9.6 Errors and Warnings........................................................................................347
9.3.9.7 External influences...........................................................................................347
9.3.9.7.1 Environment Variables................................................................................347
9.3.9.7.2 LDAP-UX Configuration..............................................................................347
9.3.9.8 Security Considerations.....................................................................................348
9.3.9.9 LDAP-UX Profile................................................................................................348
9.3.9.10 Limitations......................................................................................................348
9.3.9.11 Examples.......................................................................................................348
9.3.9.12 Resources for more information.........................................................................348
9.3.10 The ldapcfinfo tool..................................................................................................348
9.3.10.1 Synopsis........................................................................................................348
9.3.10.2 Options.........................................................................................................349
Contents
11
9.3.10.3 Specific return codes for ldapcfinfo...................................................................350
9.3.10.4 Examples.......................................................................................................352
9.4 LDAP directory tools........................................................................................................353
9.4.1 The ldapentry tool....................................................................................................354
9.4.1.1 Syntax.............................................................................................................354
9.4.1.2 Examples.........................................................................................................355
9.4.2 The ldappasswd tool................................................................................................356
9.4.2.1 Syntax............................................................................................................356
9.4.2.2 Examples........................................................................................................356
9.4.3 The ldapsearch tool.................................................................................................356
9.4.3.1 Syntax............................................................................................................356
9.4.3.2 ldapsearch options..........................................................................................357
9.4.4 The ldapmodify tool................................................................................................357
9.4.4.1 Syntax............................................................................................................357
9.4.4.2 ldapmodify options..........................................................................................358
9.4.5 The ldapdelete tool..................................................................................................358
9.4.5.1 Syntax............................................................................................................358
9.4.5.2 ldapdelete options...........................................................................................358
9.5 Schema extension utility...................................................................................................359
9.5.1 Overview................................................................................................................359
9.5.1.1 Benefits of the schema extension tool...................................................................359
9.5.2 How the schema extension utility works......................................................................359
9.5.2.1 Operations performed by the schema extension utility...........................................360
9.5.2.2 DTD and XML files used by ldapschema..............................................................360
9.5.3 The ldapschema (schema extension) tool.....................................................................361
9.5.3.1 Syntax for ldapschema......................................................................................361
9.5.3.1.1 Required command options.........................................................................361
9.5.3.1.2 Additional options (optional).......................................................................363
9.5.3.2 Security..........................................................................................................364
9.5.3.3 Environment variables.......................................................................................364
9.5.3.4 Examples........................................................................................................364
9.5.3.4.1 Example command for querying the schema status........................................364
9.5.3.4.2 Example procedures for extending the new schema into the directory server ....364
9.5.4 Schema definition file...............................................................................................365
9.5.4.1 Sample RFC3712.xml file ..................................................................................365
9.5.4.2 Defining attribute types.....................................................................................366
9.5.4.3 Attribute type definition requirements..................................................................367
9.5.4.4 Defining object classes.....................................................................................368
9.5.4.5 Object class definition requirements...................................................................369
9.5.4.6 Predefined schema definition files......................................................................369
9.5.5 Defining directory-specific information........................................................................369
9.5.5.1 Example of defining directory-specific information in the attribute type definition.......369
9.5.5.2 Example of defining directory-specific information in the object class definition.........370
9.5.6 LDAP directory server definition file............................................................................371
9.5.6.1 Example of the directory server definition file.......................................................372
9.5.6.2 Defining matching rules....................................................................................372
9.5.6.3 Defining LDAP syntaxes.....................................................................................372
9.5.7 Mapping unsupported matching rules and LDAP syntaxes.............................................373
9.5.7.1 Examples of alternate matching rules and syntaxes in
/etc/opt/ldapux/map-rules.xml....................................................................................373
9.5.8 Return values from ldapschema.................................................................................374
9.5.8.1 Schema status messages...................................................................................375
9.5.8.2 Attribute type status messages...........................................................................377
9.5.8.3 Object class status messages.............................................................................380
9.5.8.4 Matching rules status messages.........................................................................381
12
Contents
9.5.8.5 LDAP syntax status messages.............................................................................382
9.6 Name service migration scripts.........................................................................................383
9.6.1 Naming context.......................................................................................................383
9.6.2 Migrating all files....................................................................................................383
9.6.3 Migrating individual files..........................................................................................384
9.6.3.1 Migration scripts..............................................................................................384
9.6.3.2 Environment variables.......................................................................................385
9.6.3.3 General syntax for perl migration scripts.............................................................385
9.6.4 Examples...............................................................................................................385
9.7 Unsupported contributed tools and scripts..........................................................................386
9.7.1 The beq (search) tool................................................................................................386
9.7.1.1 Syntax..............................................................................................................386
9.7.1.2 Examples.........................................................................................................387
9.7.2 The certutil (certificate database) tool.........................................................................389
9.7.3 The uid2dn (display user DN) tool..............................................................................389
9.7.3.1 Syntax.............................................................................................................389
9.7.3.2 Examples........................................................................................................389
9.7.4 The get_attr_map.pl (get attributemap from profile) tool.................................................389
9.7.4.1 Syntax.............................................................................................................389
9.7.4.2 Examples........................................................................................................389
10 User tasks............................................................................................391
10.1 Modifying passwords.....................................................................................................391
10.2 Modifying personal information......................................................................................392
11 Mozilla LDAP C SDK.............................................................................394
11.1 Overview......................................................................................................................394
11.2 The Mozilla LDAP C SDK file components.........................................................................394
11.3 Legacy versions of the LDAP SDK.....................................................................................397
12 Support and other resources...................................................................399
12.1 Contacting HP...............................................................................................................399
12.2 New and changed information in this edition....................................................................399
12.3 Related information........................................................................................................401
12.4 Typographic conventions................................................................................................401
A Configuration worksheet.........................................................................403
A.1 HP directory server LDAP-UX configuration..........................................................................403
A.2 Windows ADS LDAP-UX configuration...............................................................................404
B LDAP-UX Client Services object classes.......................................................406
B.1 Profile attributes...............................................................................................................406
C Samples of LDAP-UX configuration files created or modified by autosetup......410
C.1 NSS configuration file after autosetup configuration.............................................................410
C.2 PAM configuration file after autosetup configuration............................................................410
C.2.1 PAM configuration file for HP directory server environment............................................410
C.2.2 PAM configuration file for Windows ADS environment.................................................412
C.3 ldapux_client.conf file after autosetup configuration............................................................414
C.4 ldapclientd.conf file after autosetup configuration...............................................................417
Contents
13
D Sample PAM configuration (pam.conf) files ...............................................420
D.1 Sample of a typical pam.conf file for an HP server environment.............................................421
D.2 Sample PAM configuration file typical for integration with Windows ADS..............................424
D.3 Sample pam.conf file for Trusted Mode in an HP server environment.....................................426
D.4 Sample PAM configuration file for HP-UX Trusted Mode with Windows ADS...........................428
D.5 Sample PAM configuration file for security policy enforcement in an HP server environment......430
D.6 Sample PAM configuration file for security policy enforcement with Windows ADS..................432
E Sample /etc/krb5.conf file......................................................................434
Glossary..................................................................................................435
Index.......................................................................................................438
14
Contents
Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
A simplified NIS environment.............................................................................................17
A simplified LDAP-UX Client Services environment for HP directory servers...............................18
A simplified LDAP-UX Client Services environment for Windows ADS.......................................18
The LDAP client daemon in the LDAP-UX Client Services environment.......................................19
HP-UX Client login sequence with Windows 2003 R2 and 2008 (RFC 2307) .........................20
Local startup file and the configuration profile......................................................................21
Directory information tree..................................................................................................32
LDAP-UX domain subtrees and ACIs....................................................................................33
Example directory structure................................................................................................62
Example directory structure for a single domain.................................................................132
Example directory structure for multiple domains................................................................132
Printer configurator architecture with an HP directory server.................................................167
Windows ADS attributes for printer entries........................................................................167
SASL/GSSAPI environment..............................................................................................197
PAM_AUTHZ environment...............................................................................................201
ssh host key management infrastructure.............................................................................259
ssh host key management trust framework.........................................................................260
Cannot change passwords on replica servers.....................................................................391
Changing passwords on master server with ldappasswd.....................................................392
Sample passwd command wrapper..................................................................................392
Tables
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Publishing history details.....................................................................................................2
Examples of commands and subsystems that use PAM and NSS.............................................20
New attributes.................................................................................................................36
New object classes..........................................................................................................37
New Directory Server Installation mode configuration values.................................................50
Configuration parameter default values...............................................................................71
Comparison of authentication methods...............................................................................79
Supported ciphers............................................................................................................84
Enhanced Publickey-LDAP software requirement....................................................................85
Mappings between RFC 2307-bis and nisObject automount attributes.....................................96
AutoFS Migration scripts for HP directory servers..................................................................97
Kerberos-related tasks to perform......................................................................................128
...................................................................................................................................138
AutoFS migration scripts for Windows ADS........................................................................154
Mappings between default printer and alternate printer attributes.........................................169
Mappings using existing printer attributes..........................................................................169
Mappings between default and alternate group attributes...................................................177
Field syntax in an access rule..........................................................................................204
Global security attributes supported for an HP directory server.............................................214
Global security attributes supported for a Windows Active Directory Server...........................215
Security policy status attributes supported for an HP directory server.....................................216
Security policy status attributes supported for a Windows Active Directory Server...................216
Benefits and side effects of caching..................................................................................249
LDAP-UX Client Services components................................................................................276
LDAP-UX Client Services libraries on the HP-UX 11i v2 or v3 PA-RISC machine........................278
LDAP-UX Client Services libraries on an HP-UX 11i v2 or v3 Integrity server machine...............278
Common return codes ...................................................................................................285
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Return codes for ldapuglist..............................................................................................293
Return codes for ldapugadd............................................................................................310
Return codes for ldapugmod............................................................................................322
Return codes for ldapugdel.............................................................................................328
Return codes for ldapcfinfo..............................................................................................351
Supported directory servers ............................................................................................362
Reserved LDAPv3 directory servers...................................................................................362
Directory-specific information ..........................................................................................370
Default naming context...................................................................................................383
Scripts for migrating individual files..................................................................................384
Mozilla LDAP C SDK file components on the PA-RISC machine.............................................394
Mozilla LDAP C SDK file components on an Integrity server machine....................................396
Mozilla LDAP C SDK API header files...............................................................................397
LDAP-UX Client Services configuration worksheet (HP directory server environment).................403
LDAP-UX Client Services configuration worksheet explanation (HP directory server
environment).................................................................................................................403
LDAP-UX Client Services configuration worksheet (Windows ADS).........................................404
LDAP-UX Client Services configuration worksheet explanation (Windows ADS).......................404
Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Sample host entry............................................................................................................34
Sample user entry............................................................................................................34
Sample group entry..........................................................................................................34
Sample configuration profile..............................................................................................35
autosetup: interactive mode with verbose set at the highest level.............................................46
autosetup: passing two parameters directly in the command line along with a password file......46
autosetup command for silent mode...................................................................................46
autosetup: silent mode......................................................................................................46
autosetup: interactive mode with verbose set at the highest level...........................................121
autosetup: passing two parameters directly in the command line along with a password file....121
autosetup command for silent mode.................................................................................121
autosetup: silent mode....................................................................................................122
Creating an administrator that has the rights to manage ssh public keys................................264
Extending administrator accounts with posixAttributes.........................................................265
1 Introduction
LDAP-UX Client Services simplifies HP-UX system administration by consolidating account and
configuration information into a central LDAP directory. The directory can be used as a single
source repository for HP-UX authentication, authorization, and user data/account management,
or the account information could be integrated into Microsoft Windows Active Directory Server.
The LDAP directory can reside on any LDAP-capable directory server, with tier one support provided
for the HP-UX Directory Server (HPDS) 8.1 (or later) and Red Hat Directory Server (RHDS) 8.0. It
can also reside on a Windows Server 2003 R2 or 2008. A directory server helps globalize
authentication; authorization; and management of users, accounts, and network information across
multiple systems in a large enterprise environment. The Windows Active Directory server integrates
the respective HP-UX management functionality with Windows clients.
1.1 Overview of LDAP-UX Client Services
Traditionally, HP-UX account and configuration information is stored in text files, for example, /
etc/passwd and /etc/group. NIS was developed to ease system administration by sharing
this information across systems on the network. With NIS, account and configuration information
resides on NIS servers. As shown in Figure 1, NIS client systems retrieve (and store) this shared
configuration information from NIS servers across the network.
Figure 1 A simplified NIS environment
NIS master server
Map Transfers
NIS slave server
NIS slave server
NIS Client Requests
NIS client
NIS client
NIS client
LDAP-UX Client Services improves on this configuration information sharing. HP-UX account and
configuration information is stored in an LDAP directory or Active Directory instead of on the local
client system. Client systems retrieve this shared configuration information across the network from
the directory, as shown in Figure 2 (page 18) (for a typical HP directory server ) and Figure 3
(page 18) (for Windows ADS). LDAP adds greater security, scalability, and less network traffic
from replica updates. In addition, because LDAP directory servers support management of any
type of object with extensible schema, integration with enterprise-class applications allows for
greater control and less management overhead. For example, provisioning a new employee and
HP-UX account can be an integrated and automated process.
1.1 Overview of LDAP-UX Client Services
17
NOTE: In this document, “HP directory server” is often used to refer to the HP-UX Directory Server
or Red Hat Directory Server for HP-UX product.
Figure 2 A simplified LDAP-UX Client Services environment for HP directory servers
Updates
LDAP Master
Directory Server
LDAP Directory
Server Replica
LDAP Client Requests
LDAP-UX client
LDAP-UX client
Figure 3 A simplified LDAP-UX Client Services environment for Windows ADS
Replicates
Active Directory
Domain Controller
Active Directory
Domain Controller
Replicates
LDAP Client Requests
LDAP-UX client
LDAP-UX client
LDAP-UX Client Services using an HP directory server supports the following name services data:
•
passwd
•
group
•
netgroup
•
automount
•
publickey
•
services
•
rpc
•
hosts
•
networks
•
protocols
LDAP-UX Client Services using Windows 2003 R2/2008 Active Directory Server in a single domain
supports traditional name services supported by NIS and defined by the RFC 2307 schema. For
a detailed list, see “LDAP-UX Client Services object classes” (page 406).
18
Introduction
1.2 How LDAP-UX Client Services works
LDAP-UX Client Services works by providing backend services for the authentication mechanism
provided in PAM, providing a backend database for the naming services provided by NSS.
The PAM configuration file /etc/pam.conf defines the security mechanisms that are used for
authenticating users. Its default values provide the customary operation of the system under both
standard HP-UX and trusted systems. It also provides support for controls on individual users. The
NSS configuration file /etc/nsswitch.conf defines LDAP support for the specified services.
These extensible mechanisms enable the installation and use of new authentication methods and
name services without changing the underlying HP-UX commands. In the HP directory server
environment, support of the PAM architecture enables the HP-UX client to be fully integrated into
the LDAP environment. The PAM_LDAP library allows the HP-UX system to use the LDAP directory
as a trusted server for authentication and centralized password and account policy management.
This enables passwords to be stored in any syntax and to remain hidden from view (preventing a
decryption attack on the passwords). Because passwords can be stored in any syntax, HP-UX can
share passwords with other LDAP-enabled applications, and passwords on LDAP accounts are not
subject to an 8-character limitation.
As shown in Figure 4, the client daemon ldapclientd is the nucleus of the product. It enables
LDAP-UX clients to work with LDAP directory servers, and it supports all NSS backend services for
LDAP and data enumeration. It also supports PAM_LDAP for authentication and password change.
Figure 4 The LDAP client daemon in the LDAP-UX Client Services environment
LDAP Directory Server
LDAP Client Requests
LDAP C SDK
PAM
login, ftp, ...
ldapclientd
LDAP-UX Client
NSS
ls, who, ...
In the Windows ADS environment, the PAM architecture supports Kerberos authentication, which
enables integration of HP-UX account management in Windows Server 2003 R2 and 2008.
Kerberos, an industry standard for network security, is seamlessly integrated in the Windows Server
2003 R2 and 2008 through the automatic configuration of Active Directory domain controllers to
provide Kerberos with authentication services. This enables Windows Server 2003 R2 and 2008
to authenticate Kerberos clients regardless of the platform on which they reside. Figure 5 illustrates
the integration between HP-UX and Windows 2003 R2 or 2008 (Windows Services for UNIX)
version 2.0.
1.2 How LDAP-UX Client Services works
19
Figure 5 HP-UX Client login sequence with Windows 2003 R2 and 2008 (RFC 2307)
LDAP Directory Server
LDAP Client Requests
LDAP C SDK
PAM
login, ftp, ...
ldapclientd
LDAP-UX Client
NSS
ls, who, ...
With LDAP-UX Client Services, and ldapclientd in particular, HP-UX commands and subsystems
can access name service information transparently from the LDAP directory or from the Active
Directory through PAM and NSS. Table 2 (page 20) shows some examples of commands and
subsystems that use PAM and NSS. In addition, the getpwent and getgrent family of system
calls obtain user and group information from the directory (for more information, see the
getpwent(3C) and getgrent(3C) manpages).
Table 2 Examples of commands and subsystems that use PAM and NSS
Commands that use NSS
Commands that use PAM and NSS
finger1
dtlogin
1
grget
ftp
1
groups
login
id
passwd
listusers1
rlogin
logins1
remsh
logname
su
ls
telnet
newgrp1
nslookup
nsquery2
pwget
1
who
whoami
1
These commands enumerate the entire passwd or group database, which might reduce network and directory server
2
performance for large databases.
The nsquery command is a contributed tool included with the ONC/NFS product. For more information, see the
nsquery(1) manpage.
20
Introduction
After you install and configure the LDAP directory or the Active Directory, and migrate your name
service data into it, HP-UX client systems locate the directory from a startup file. As shown in
Figure 6, the startup file tells the client system how to download a configuration profile from the
directory.
Figure 6 Local startup file and the configuration profile
Directory
Configuration
profile
The shared configuration
profile is stored in the
directory and downloaded
to all LDAP-UX clients.
The startup file points
to the configuration
profile in the directory.
Startup
file
Configuration
profile
LDAP-UX client
The configuration profile is a directory entry containing configuration information common to many
clients. Storing this information in the directory enables you to maintain it in one place and share
it among many clients rather than storing it redundantly across clients. Because the configuration
information is stored in the directory, each client simply needs to know where its profile is, which
is indicated by the startup file. Each client downloads the configuration profile from the specified
directory.
The configuration profile is an entry in the directory containing details on how clients are to access
the directory, such as:
•
Where and how clients must search the directory for user, group, and other name service
information.
•
How clients must bind to the directory: anonymously or as a proxy user. Anonymous access
is simplest and used most often because most data in the directory server is not considered
confidential. However, sometimes directory administrators do not allow anonymous access
(Active Directory definitely does not allow anonymous access), in which case a proxy user is
created to represent the OS and its users. With a proxy user, the OS can be granted access
to the data in the directory server. The proxy user credential (user ID and password) is stored
in the /etc/opt/ldapux/pcred file. Additionally, in some instances, administrators may
want to define an administrator proxy (Admin Proxy) credential. This credential is used to
represent administrators of the HP-UX OS, and may be used with administration tools such as
ldapugmod or ldaphostmgr, or may be used when NIS public keys are managed in the
directory server (management of NIS public keys in Active Directory is not supported). The
administrator credential (user ID and password) is stored in the /etc/opt/ldapux/acred
file.
The /etc/opt/ldapux/pcred file is created automatically by autosetup, which configures
the host entry as a proxy user. To manually configure a proxy user or Admin Proxy, use the
ldap_proxy_config tool. For information about this tool, see Section 9.2.6 (page 280).
NOTE: While the user credentials stored in the pcred and acred files are not visible as
plain text, the pcred and acred files are not encrypted. Access must be restricted to these
files.
•
Other configuration parameters such as search time limits.
1.2 How LDAP-UX Client Services works
21
For more information about PAM, see the pam(3) and pam.conf(4) manpages, and the Managing
Systems and Workgroups: A Guide for HP-UX System Administrators document at the following
location:
http://www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
Sample PAM configuration files and details about configuration are included in “Sample PAM
configuration (pam.conf) files ” (page 420).
For information on NSS, see the switch(4) manpage and the "Configuring the Name Service
Switch" chapter in NFS Services Administrator's Guide, available at the following location:
www.hp.com/go/hpux-networking-docs
1.3 Domains in LDAP-UX environments
Several types of domains are discussed in this manual. The following list helps you understand the
significance of each domain.
•
LDAP-UX domain — the realm of users, groups, and hosts defined by the LDAP-UX configuration
profile and managed by the LDAP directory server. All hosts configured to point to the same
LDAP-UX configuration profile are considered part of that domain. When you use the guided
installation (autosetup) script to install LDAP-UX and configure a new directory server
environment, the script creates a LDAP-UX domain. When installing into an existing LDAP-UX
(B.05.00 or later) environment, the guided installation joins an HP-UX OS instance into an
existing LDAP-UX domain. The guided installation can provision information about hosts in
the domain into the directory server. The LDAP-UX domain serves as a focal point for managing
hosts, securing data, and in HP directory server environments only, for simplifying management
of ssh host keys.
The guided installation uses the LDAP-UX domain name to define the suffix of the directory
tree. For example, if the local host is a member of the AccountingDept.acme.com domain,
the directory server instance is named AccountingDept-master by default. The directory
server suffix becomes dc=AccountingDept,dc=acme,dc=com. For more information
about the LDAP-UX domain, see Section 2.3.2 (page 31).
•
Domain Name System (DNS) domain — identifies a specific realm of administrative autonomy,
authority, or control in a namespace. DNS assigns a name server to maintain the domain
namespace and provide translation services between names and associated Internet Protocol
(IP) addresses. The domain name space consists of a tree of domain names.
The HP-UX host system managed by LDAP-UX may participate in a DNS domain. The DNS
domain is often used to register directory servers. The guided installation looks for existing
directory servers in the local host's DNS domain. When creating a new directory server, it
discovers the DNS domain name and generates the directory server instance name and suffix
from the local host's DNS name.
LDAP-UX may also be used for host-name resolution similar to DNS.
•
22
Windows Server domain — a logical collection of users, groups, and computers running
versions of the Microsoft Windows operating system that share a central directory database.
This central database (known as Active Directory starting with Windows 2000, and as Active
Directory Domain Services starting with Windows Server2003 R2), contains the user accounts
and security information for the resources in that domain. Each person who uses computers
within a domain receives his or her own unique account, or user name. This account can then
be assigned access to resources within the domain. In a domain, the directory resides on
computers that are configured as "domain controllers." A domain controller (DC) is a server
that manages all security-related aspects in user and domain interactions; it responds to all
security authentication requests (logging in, verifying permissions, and so forth) within the
domain. Each DC has a copy of the Active Directory; changes on one computer are
Introduction
synchronized (converged) among all the DC computers by multi-master replication. Servers
joined to the Active Directory that are not domain controllers are called Member Servers.
LDAP-UX Client Services for Microsoft Windows Active Directory enables integration of user
account information into a Microsoft Windows 2003 R2 or 2008 Active Directory Server.
•
NIS domain — defines the system of programs and data files that HP-UX machines use to
collect, collate, and share specific information about machines, users, file systems, and network
parameters throughout a network of computers. Traditionally, HP-UX account and configuration
information is stored in text files, for example, /etc/passwd and /etc/group. NIS was
developed to ease system administration by sharing this information across systems on the
network. With NIS, account and configuration information resides on NIS servers. NIS client
systems retrieve this shared configuration information across the network from NIS servers,
and store the retrieved information (see Figure 1 (page 17)).
The NIS/LDAP Gateway (ypldapd) is a product bundled with LDAP-UX Integration. This
product, which is not supported with Windows ADS, enables the directory server to act as a
repository for an NIS domain and provides a means to allow for a transition from an NIS
domain to a domain managed fully in an LDAP directory server. The LDAP-UX Client Services
product improves on this configuration information sharing. HP-UX account and configuration
information is stored in an LDAP directory or Windows Active Directory instead of on the local
client system. Client systems retrieve this shared configuration information across the network
from the LDAP directory (see Figure 2 (page 18) and Figure 3 (page 18)). LDAP adds greater
security, scalability, interoperability with other applications and platforms, and less network
traffic from replica updates.
•
Administration domain (Admin domain) — for HP-UX Directory Server, a container entry for
server groups, with each server group containing directory server instances that are managed
by the same Configuration Directory Server. This domain is administered by the Configuration
Administrator. Using the hpds-idm-console, the Configuration Administrator can view and
manage all the HP-UX directory server instances in this domain. The Configuration Directory
Server (configuration directory) is used by the hpds-idm-console to discover and manage
information about this domain.
1.4 Administrators and managers in the LDAP-UX directory server
environment
A variety of administrators and managers may be created and involved in the LDAP-UX environment:
•
Directory Manager — a unique, powerful user established when a directory server is created.
The Directory Manager is the “super user” who typically has the responsibility of repairing
and recovering from errors in configuration. The Directory Manager is a special entry that
does not have to conform to directory server access control policies. The Directory Manager
can correct problems that affect users who do not have access control privileges to do so.
There is no directory entry for the Directory Manager user; it is used only for authentication.
You cannot create an actual directory server entry that uses the same distinguished name (DN)
as the Directory Manager DN.
The LDAP-UX guided installation establishes the Directory Manager for a newly-created directory
server as cn=Directory Manager (in an HP server environment) or
cn=administrator,cn=user,dc=mydomain,dc=example,dc=com (in a Windows
domain), and requests that you set up a password for this user.
•
Configuration Administrator (also known as the Directory Administrator) — a user responsible
for managing the directory servers in the directory server administration domain. This user is
the “super user” that manages all directory server and Administration Server instances through
the Directory Server Console. The default Directory Administrator user name is admin. Every
1.4 Administrators and managers in the LDAP-UX directory server environment
23
directory server is configured to grant this user administrative access, thus enabling this user
to perform configuration changes.
Some important differences between the Configuration Administrator and the Directory
Manager:
24
◦
The Configuration Administrator cannot create top-level entries for a new suffix through
an add operation, neither by adding an entry with the Directory Server Console nor by
using the ldapadd tool.
◦
Password policies do not apply to the Directory Manager but do apply to the Configuration
Administrator. However, you can define a separate password policy for the Configuration
Administrator with similar rights as the Directory Manager.
◦
Size, time, and lookthrough limits do not apply to the Directory Manager but do apply
to the Configuration Administrator. However, you can define resource limits for the
Configuration Administrator similar to those of the Directory Manager.
•
LDAP-UX Domain Administrator — a user responsible for managing all data in the LDAP-UX
domain. This administrator can add a new HP-UX host to the LDAP-UX domain, create a new
administration domain, and manage all HP-UX OS instances in that domain. This user also
has privileges to log in to any HP-UX host that is a member of the LDAP-UX domain. The default
account name is domadmin. An LDAP-UX Domain Administrator is any user who is a member
of the DomainAdmins group. A subset of the Domain Administrator’s privileges are available
to users defined as members of the UserAdmins and HostAdmins groups.
•
Windows Server Administrator — Similar in privilege to both the Directory Manager and the
LDAP-UX Domain Administrator. Typically grants administrative privileges to other users by
setting up security groups and policies. The default account name is administrator.
Introduction
2 Installing and configuring LDAP-UX Client Services for an
HP server environment
This chapter describes the decisions you must make and the steps for installing the HP directory
server and for configuring LDAP-UX Client Services.
2.1 Before you begin: general installation and configuration considerations
for an HP server environment
Consider the following as you plan your installation and configuration.
•
You may use either of the following methods for installing and configuring LDAP-UX Client
Services on your HP-UX system:
◦
Guided installation, providing a simple, quick, and automated procedure that sets up a
basic installation of the software, which you can customize afterward as needed
◦
Customized installation, providing a screen-based procedure that enables you to customize
the software
For information about the benefits of each type of installation, see Section 2.2 (page 26).
•
For a customized installation, use the configuration worksheet in “Configuration worksheet”
(page 403) to record your decisions and other information that might be required later for
configuration. For a guided installation, the instructions in this manual advise you to record
the important information. You can do so in any way that is convenient. The information to
record is much less in comparison to a customized installation.
•
For the latest information, see the LDAP-UX Integration Release Notes at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
•
The functionality of LDAP-UX requires that a valid LDAP directory server be installed and
configured on your host or on another host within your network: either HP-UX Directory Server
8.1 (or later) or Red Hat Directory Server 8.0. If you are using the guided installation
(autosetup), and have installed HP-UX directory server, the guided installation can configure
a directory server instance for you.
NOTE: Most discussions in this chapter and other areas of the manual discussing HP directory
servers assume HP-UX Directory Server is the server installed in your environment. HP
recommends the HP-UX Directory Server.
You can obtain the latest version of the HP-UX Directory Server (or Red Hat Directory Server)
from your local HP sales office or at:
http://www.hp.com/go/softwaredepot
Documentation for the HP-UX Directory Server and Red Hat Directory Server is available at
http://www.hp.com/go/hpux-security-docs.
•
For advice on how to set up and configure your directory to work with HP-UX, see the white
paper Preparing Your Directory for HP-UX Integration, available at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
2.1 Before you begin: general installation and configuration considerations for an HP server environment
25
NOTE: This white paper was published before HP-UX Directory Server 8.1 was introduced.
However, much of the information continues to be relevant and helpful.
•
Most examples in this chapter are based on the HP-UX Directory Server and assume you have
some knowledge of this directory and its tools, such as the Directory Server Console and
ldapsearch. If you have another directory server, consult the documentation for your directory
server for more information.
•
For more information about how to integrate LDAP-UX Client Services with the Windows Server
2003 R2 or 2008 Active Directory, see “Installing and configuring LDAP-UX Client Services
for a Windows ADS environment” (page 114).
•
For illustrative purposes, examples in this chapter use a base DN of o=hp.com.
2.2 Selecting the method of installation: guided or customized
LDAP-UX Client Services software releases before B.05.00 provided only one installation option,
the customized installation using the setup program. This is a traditional screen-based program
that requires that you run several procedures to set up and configure a new directory server instance
after installing the directory server product bundle. This option enables an experienced administrator
to customize the software.
LDAP-UX Client Services B.05.00 introduces the guided installation using the autosetup program,
which greatly simplifies the installation and configuration process. This is a simple, quick, and
automated procedure that gets you started with a basic implementation of the software, requiring
little input other than identifying administrator-level entities. These entities automatically perform
privileged configuration tasks for you. The guided installation enables you to install and configure
a new instance of an LDAP directory server automatically, ready for use with LDAP-UX. The
autosetup script creates and configures the new directory server instance with SSL/TLS services
enabled. You can customize the software afterward.
Both the setup and autosetup programs are available in /opt/ldapux/config.
The guided installation (autosetup) is most advantageous if:
•
You prefer simplicity, ease, and quickness of installation.
•
You prefer an installation that enables immediate use of LDAP-UX, with minimal input required.
The autosetup program automatically provides default values for many parameters that
must be provided manually during a customized installation (you can customize parameters
later, if desirable).
•
You are installing and configuring LDAP-UX for the first time in an environment that has no
LDAP directory server instance. The autosetup program detects whether a directory server
instance already exists, and if one is not found, the script can set up the directory server for
you.
NOTE: If you use the custom installation in an environment that lacks an LDAP directory
server, you must set up the directory server yourself.
•
You want HP-UX host management automatically enabled in the directory server. For more
information about host management, see Section 7.8 (page 235).
•
You want secure shell (ssh) host key management automatically enabled (ssh key management
is not supported in Windows ADS environments). For more information about managing ssh
host keys, see “Managing ssh host keys with LDAP-UX (HP directory servers only)” (page 258).
You may also use autosetup to install LDAP-UX Client Services into a single Windows domain
that has been configured with SSL support. For information about installing and configuring LDAP-UX
Client Services into a Windows domain, see “Installing and configuring LDAP-UX Client Services
for a Windows ADS environment” (page 114).
26
Installing and configuring LDAP-UX Client Services for an HP server environment
The customized installation (setup) is advantageous if:
•
You are more experienced and familiar with the product, and you want to manually customize
the software during the installation.
•
You are installing into an environment that already includes an LDAP directory server, and
user and group data has already been installed on that directory server. The guided installation
makes assumptions about the location of user, group, and host data that is stored in the
directory server. The customized installation enables you to define data location and customized
attribute mapping to specifically match the schema model defined in the existing directory
server.
•
You want to install the HP-UX host into multiple-domain Windows environment. Guided
installation supports installation into a single windows domain only.
•
You cannot modify the directory server’s schema. In this case, you can deploy using a local-only
profile. The local-only profile can also be useful for small deployments and testing purposes.
For more information, see Section 2.4.5.1 (page 69).
•
You require integration with HP-UX Trusted Mode. The autosetup script does not properly
configure LDAP-UX on a host using Trusted Mode.
2.3 Guided installation (autosetup) for an HP directory server environment
The guided installation greatly simplifies installation of LDAP-UX, and it gives you the option of
creating an HP-UX Directory Server instance. Setting up an HP-UX client with LDAP-based security
can be accomplished in a matter of moments. The information required for installation is kept to
an absolute minimum. For example, the only information required when installing and configuring
LDAP-UX into an existing directory server environment is the name of the directory server or the
name of the LDAP-UX domain being joined, and the credentials of a user who is permitted to either
create a new domain or join an existing one.
NOTE: The LDAP-UX domain is created by LDAP-UX 5.0 or later installations; it is the collection
of users, groups, and hosts that can be managed in the LDAP directory server, as defined by the
LDAP-UX configuration profile. For more information, see Section 2.3.2 (page 31).
When creating a new directory server, the guided installation can automatically discover the name
of the local host and generate the name of the new directory server instance based on the DNS
domain. While the guided installation (autosetup) is intended to be an interactive utility, you
can use command-line options to specify input required by the utility and, in some scenarios, make
it completely automated. The command-line options are described in detail in Section 2.3.3
(page 41).
While one of the strengths of LDAP-UX is its ability to integrate into any environment using a variety
of configuration options, the guided installation configures LDAP-UX with the most commonly-used
installation settings that support a trusted management framework. To assure that the associated
directory server is trusted in the security management space for HP-UX, the guided installation
requires that the directory server be enabled for SSL support. The guided installation can
automatically provision a new HP-UX Directory Server instance with SSL enabled, if one is needed.
The guided installation supports the following basic installation scenarios:
•
Installing LDAP-UX to create a new directory server (New Directory Server Installation mode):
In this scenario, the guided installation creates and provisions a new SSL-enabled instance of
an HP-UX Directory Server on the local host, and then configures LDAP-UX to connect to that
directory server. (It sets up the PAM configuration file /etc/pam.conf and the NSS
configuration file /etc/nsswitch.conf; samples of these files are included in “Samples
of LDAP-UX configuration files created or modified by autosetup” (page 410).) The guided
installation prompts for a directory server administration domain name, or if one already
exists, the host name and port number of the directory server that manages the existing server
2.3 Guided installation (autosetup) for an HP directory server environment
27
administration domain (this directory server is also referred to as the Configuration Directory
Server or configuration directory).
NOTE: The directory server administration domain is the domain used for managing the
directory servers themselves. In contrast, the LDAP-UX domain is the domain used for managing
the data stored by the directory server. It consists of the collection of users, groups, and hosts
that can be managed in the LDAP directory server. For more information about the variety of
domains discussed in this manual, see Section 1.3 (page 22).
The guided installation also prompts for the initial credentials used for managing the elements
of the directory server and the data managed by that directory server. It configures the directory
server to suit managing an LDAP-UX domain. For more information about the LDAP-UX domain,
see Section 2.3.2 (page 31).
In this scenario, the guided installation:
◦
Configures the directory server with an LDAP-UX schema used for managing users, groups,
and hosts. This includes definition of the database indexes based on that schema.
◦
Defines the initial framework for the directory information tree.
◦
Defines access control rights for directory server and LDAP-UX domain administration.
◦
Creates an LDAP-UX configuration profile (based on RFC 4876) that can be used for
configuring additional clients. This file defines the LDAP-UX domain contents. For
information about this RFC, see:
http://www.ietf.org/rfc/rfc4876.txt
For more information about RFCs in general, see:
http://www.ietf.org/rfc.html
◦
Provisions HP-UX host information into the directory server, to be used for proxied
authentication and ssh key management.
◦
Creates a CA and server certificate along with a CA package depot that can be
preinstalled on HP-UX clients to be managed in the LDAP-UX domain.
The creating and provisioning of a new directory server instance is supported only with Red
Hat Directory Server 8.0 and HP-UX Directory Server 8.1 or later. The guided installation does
not create instances of previous versions of Red Hat Directory Server or Netscape Directory
Server.
For information about installing LDAP-UX for the first time in an environment without a directory
server, see Section 2.3.4 (page 46).
•
Installing LDAP-UX into an existing directory server environment (Existing Directory Server
Installation mode): In this scenario, instead of creating a new directory server instance, the
guided installation discovers information about your existing directory server and directory
information tree. The existing directory server must be HP-UX Directory Server 8.1 or later, or
Red Hat Directory Server 8.0. The guided installation then configures LDAP-UX accordingly.
The guided installation requires that the existing directory information tree follow the structure
defined in Figure 7 (page 32), unless being installed into a Windows domain.
If the directory server hosts a Windows domain, the guided installation configures the LDAP-UX
profile to follow the standard layout and attributes defined for an ADS domain. For a domain
other than Windows ADS, the guided installation creates an LDAP-UX configuration profile
based on the existing directory information tree, with the defaults defined for an LDAP-UX
domain shown in Figure 7 (page 32). The guided installation provisions information about
the current host into the directory server. For more information about the directory information
tree in an LDAP-UX domain, see Section 2.3.2.1 (page 32).
In this scenario, the guided installation prompts for several parameters, depending on the
exact circumstances. You are prompted for the existing directory server host name (and
28
Installing and configuring LDAP-UX Client Services for an HP server environment
optionally the port), and the bind DN and password of a user who has sufficient privileges to
add the local HP-UX host to the LDAP-UX domain. When you specify a remote host where the
existing directory server is located, the guided installation cannot validate the identity of the
directory server unless a valid domain (CA certificate) or server certificate exists on the local
host. If one does not exist, you are given the option of having the guided installation download
and install the CA or server certificate (without trust) or, if the server was created by
autosetup, you can download (from the server to your host) a certificate depot that installs
the CA certificate for the LDAP-UX domain.
For information about installing LDAP-UX for the first time in an existing directory server
environment, see Section 2.3.5 (page 52).
•
Installing LDAP-UX into an existing LDAP-UX domain (Existing LDAP-UX Domain Installation
mode): In this scenario, LDAP-UX has already been configured in the environment. You can
then use the guided installation to join the HP-UX host to an existing LDAP-UX domain (or to
a Windows ADS domain). The guided installation simply downloads the existing domain
configuration (LDAP-UX configuration profile) and registers the host in the domain.
In this scenario, the guided installation prompts you for similar input as does the preceding
scenario, and if you have not preinstalled the CA certificate, you are also asked if you want
to trust the directory server.
For information about installing LDAP-UX into an existing LDAP-UX domain, see Section 2.3.6
(page 55).
NOTE: You can install LDAP-UX into an existing LDAP B.04.xx environment; however, the
hosts search descriptor serviceSearchDescriptor in the LDAP-UX configuration profile
will likely define an incorrect location for host entries (it should be ou=hosts). Host tools
expect the correct location for host entries to be defined in the configuration profile. If the
location is incorrect, the ldaphostmgr tool will add hosts to an incorrect location in the
directory tree.
The guided installation (with LDAP-UX B.05.00 or later) configures the profile with the correct
location for host entries. If you are installing LDAP-UX into an LDAP-UX environment that has
not been set up by the guided installation, ensure that the correct location is specified in the
profile (normally, that is ou=hosts). To determine the location configured for hosts in the
LDAP-UX configuration profile, you can use the following command:
/opt/ldapux/bin/ldapcfinfo -t hosts -b
If you need to modify the configuration profile, you can modify the
serviceSearchDescriptor attribute for the hosts service. For information about how
to modify the LDAP-UX configuration profile, see Section 7.10.2 (page 245).
In these autosetup scenarios, you configure LDAP-UX on the local host for the first time. When
installing LDAP-UX to create a new directory server, autosetup introduces the LDAP-UX domain
to your organization, creates a directory server and a new LDAP-UX configuration profile, configures
your local HP-UX host, and joins the host to the LDAP-UX domain. When installing LDAP-UX into
an existing directory server environment, autosetup introduces the LDAP-UX domain to your
organization using an existing directory server, creates a new LDAP-UX configuration profile,
configures your local HP-UX host, and joins the host to the LDAP-UX domain. When installing
LDAP-UX into an existing LDAP-UX domain, autosetup configures your local HP-UX host based
on an existing directory server LDAP-UX configuration profile, and joins the host to the existing
LDAP-UX domain.
If no valid directory server software is installed on the local system, the guided installation prompts
you for the name of an existing remote directory server. If the specified directory server not found,
the guided installation aborts.
2.3 Guided installation (autosetup) for an HP directory server environment
29
2.3.1 What autosetup does
As mentioned, the guided installation (autosetup) greatly simplifies the configuration process.
The procedure performs numerous activities automatically, with minimal input required from whoever
runs the script, including the following:
1.
Automatically detects existing directory servers by querying the DNS server of the DNS domain
for any registered directory servers, and then tries to connect to the directory server with a
search request. If multiple SRV resource records are returned, autosetup stops searching
after it makes a successful connection. If a directory server cannot be found by DNS, you are
prompted for the host name and port number for an existing directory server in your environment
or asked if you want to create a new directory server instance on the local host.
2. If you choose to create a new directory server instance on the local host, autosetup creates
an HP-UX Directory Server instance on the local machine. This directory server instance is
configured with SSL and populated with a framework to support the LDAP-UX domain. For
information about the LDAP-UX domain created by autosetup, see Section 2.3.2 (page 31).
3. To guarantee confidentiality and data integrity, autosetup uses the StartTLS extended
operation on a regular LDAP connection with simple authentication (bind DN and password).
4. To trust the certificate presented by the server, autosetup determines whether the local HP-UX
host has a certificate database that includes the CA certificate that issues the server certificate.
5. If the CA certificate has not been preinstalled, to create certificate and key database files
(cert8.db and key3.db), autosetup obtains the server certificate from the directory
server, and then downloads all the trusted CA certificates published in the directory server.
The autosetup script places in the cert8.db database file the one CA certificate that
signed the SSL server certificate of the directory server. The cert8.db file stores public keys,
while the key3.db file stores private keys. A warning message is displayed to indicate that
an untrusted method is being used to obtain the CA certificate.
6. Because a configuration profile can be shared by LDAP-UX clients, autosetup searches for
an existing profile entry in the directory server, using a standard profile path
(ou=services,ou=configuration). If the default profile entry exists, autosetup
downloads it into an LDIF file (/etc/opt/ldapux/ldapux_profile.ldif) and creates
a binary profile file (/etc/opt/ldapux/ldapux_profile.bin) based on the LDIF file.
7. If the default profile entry does not exist, autosetup searches for any other profile entries
that might be saved. If any are found, you are prompted to select a configuration profile to
download or to create a default profile entry.
8. Before adding the profile entry, autosetup determines whether the schema defined in RFC
4876 exists in the directory server. If the schema does not exist, then the script extends the
directory server schema. Additionally, autosetup will extend the directory server with
additional LDAP-UX 5.0 schema and the ssh public key management schema.
9. Creates the startup file (/etc/opt/ldapux/ldapux_client.conf) on the LDAP-UX client
system, enabled for TLS support (enable_startTLS is set to 1). A sample of the file is
included in Section C.3 (page 414).
10. Creates a new computer account or host entry in the directory server that represents the current
HP-UX host. If a host entry already exists with the same name, an autosetup prompt asks
if the existing entry should be deleted and replaced.
11. Configures the host entry as a proxy user. It stores the encrypted proxy user information in the
/etc/opt/ldapux/pcred file. The proxy file contains the proxy user DN on the first line,
and the password on the second line.
12. Configures the NSS and PAM_LDAP by modifying the /etc/pam.conf and /etc/
nsswitch.conf files; samples of these files are included in “Samples of LDAP-UX
configuration files created or modified by autosetup” (page 410).
30
Installing and configuring LDAP-UX Client Services for an HP server environment
13. Modifies the LDAP-UX client daemon configuration file /etc/opt/ldapux/
ldapclientd.conf to:
•
Enable the LDAP-UX client daemon ldapclientd to launch automatically whenever the
system is rebooted ([StartOnBoot] is defined with enable=yes).
•
Set iproxy_is_restricted=yes in the [general] section, which indicates that the
host entry created in step 10 is not privileged. This setting enables additional capabilities
provided by the ldapuglist and ldaphostlist tools.
A sample of the ldapclientd.conf file is included in Section C.4 (page 417).
14. Starts the LDAP-UX client daemon (ldapclientd) and the central configuration service
daemon (ldapconfd).
2.3.2 Principles of the LDAP-UX domain
When used for installing LDAP-UX in an environment (other than Windows) for the first time, the
guided installation defines the management framework for, and actually creates, an LDAP-UX
domain. An LDAP-UX domain is a collection of users, groups, and hosts that can be managed in
the LDAP directory server, using the user and host management tools described in Section 7.8
(page 235).
NOTE: This section does not apply to guided installations of LDAP-UX into a Windows ADS
domain. An LDAP-UX domain is not a Windows domain. A Windows ADS domain already defines
a directory information tree, information model, and security policy. The LDAP-UX domain defines
similar elements.
An LDAP-UX domain is defined by an LDAP-UX configuration profile. All hosts configured to point
to the same LDAP-UX configuration profile are considered part of that same domain. The
configuration profile follows the standard defined by RFC 4876. As such, it can be used to define
the same domain for platforms aside from HP-UX. (For more information about configuring the
profile, see Section 7.10.2 (page 245).) While the guided installation defines this configuration
profile automatically, any configuration profile can be considered the basis of an LDAP-UX domain.
The guided installation uses the host management tools to automatically provision into the directory
server any relevant information about HP-UX hosts contained in the domain. Creating host entries
in the directory server serves the following purposes:
•
As part of the secured framework described in Section 2.3.2.3 (page 37), the guided
installation assures that data is protected from anonymous access (anonymous access is defined
when a new HP-UX Directory Server instance is created.) Directory server data is available
only to known clients. When the OS is acting on behalf of its users, it needs a proxy identity
to represent the users of the host. The host entry is used to represent that proxy identity.
•
As part of the new ssh key management feature, when the guided installation creates the new
host entry, it also uploads the host ssh public keys. This simplifies management of ssh keys in
the directory server. With HP Secure Shell A.05.50 or later, the host entry can be used to
assure trust between hosts managed in the domain. For more information about managing
ssh key management, see “Managing ssh host keys with LDAP-UX (HP directory servers only)”
(page 258).
To assure that the LDAP directory server can be trusted as a secure repository for host users and
groups, the identity of the directory server must be validated. Being SSL-enabled (as is required),
the directory server can provide that validation with SSL certificates. In addition, through SSL
encryption, it can assure that private information such as user passwords are not intercepted while
they are in transit.
2.3 Guided installation (autosetup) for an HP directory server environment
31
NOTE: SSL/TLS protocols support a variety of different cryptographic algorithms (ciphers) for
use in authentication operations between server and client, certificate transmissions, and session
key establishment. If a cipher is found to be flawed and subject to attack, administrators of HP-UX
and the directory server must know about their vulnerability. Ciphers can be disabled in the directory
server. For information about SSL/TLS ciphers and which ones are supported by LDAP-UX, see
Section 2.4.6.5 (page 84).
When a new directory server instance is created, the guided installation defines the management
framework for the LDAP-UX domain. This framework consists of:
•
Directory information tree : Defines the hierarchical structure in which different objects in the
domain are stored, as described in Section 2.3.2.1 (page 32).
•
Information model: Defines the types of objects managed in the directory server and the
attributes and object classes that represent them, as described in Section 2.3.2.2 (page 34).
•
Security framework: Defines rights to access and modify data in the directory information
tree, including the definition of three management groups, the ACIs that grant permissions to
each group to manage different objects in the directory information tree, and general access
policies such as which attributes are considered public and private. For more information, see
Section 2.3.2.3 (page 37).
2.3.2.1 Directory information tree
When the guided installation creates a new HP-UX Directory Server instance, it creates the foundation
for a directory information tree, which is a name space that stores the users, groups, hosts, and
configuration in the LDAP-UX domain. This tree can be expanded or altered, as long as appropriate
updates are made to the LDAP-UX configuration profile.
To build the directory information tree, the guided installation creates the root suffix based on the
discovered or specified DNS domain. The guided installation uses the domain component syntax
to define the root suffix DN, as defined by RFC 2247. Under that, it defines the organizational
units to act as containers for the users, groups, hosts, and configuration, as shown in Figure 7
(page 32).
Figure 7 Directory information tree
dc=example,dc=com
ou=Groups
ou=Configuration
ou=Hosts
ou=Services
cn=host1
...
ou=People
uid=domadmin
cn=domain-Idapuxprofile
cn=domain CA Certificate
cn=LDAP Server (domain-master)
The subtrees created in the directory information tree are:
32
Installing and configuring LDAP-UX Client Services for an HP server environment
cn=UserAdmins
cn=HostAdmins
cn=DomainAdmins
•
ou=People: Stores all users managed in the LDAP-UX domain. Utilities, such as the LDAP
user or group management tools (see Section 9.3 (page 283)) and ldapentry (see
Section 9.4.1 (page 354)) can be used to manage users and accounts under this subtree. The
ou=People subtree is populated with one user, the Domain Administrator. By default, the
LDAP-UX Domain Administrator is named domadmin. The guided installation enables this
name to be changed.
•
ou=Groups: Stores all groups managed in the domain. The LDAP user/group management
tools and ldapentry may also be used to manage these groups. This subtree is populated
with the initial management groups, cn=UserAdmins, cn=HostAdmins, and
cn=DomainAdmins. Members of these groups are granted privileges to manage their related
data. For more information about privileges and security in general, see Section 2.3.2.3
(page 37)“Security Framework”.
•
ou=Hosts: Registers information about hosts and devices associated with the LDAP-UX domain.
The LDAP host tools ldaphostmgr and ldaphostlist (see Section 9.3 (page 283)), or
ldapentry, can be used to manage hosts and devices under this subtree. When the guided
installation configures LDAP-UX, it initializes this subtree with the local host’s information. Any
additional hosts that use the guided installation to configure LDAP-UX is added under this
subtree (joined to the LDAP-UX domain).
•
ou=Configuration,ou=Services: Stores centrally managed configuration information
for LDAP-enabled applications, or information about services available in the domain. The
ldapentry tool can be used to manage items under this subtree. This subtree is populated
with the LDAP-UX configuration profile and will register the HP-UX Directory Server instance
and the CA certificate used in the LDAP-UX domain.
ACIs are created (using the aci attribute) at the root suffix and in the ou=Hosts, ou=People,
and ou=Groups subtrees. These ACIs grant administration privileges to the members of the initial
groups defined in the ou=Groups subtree. Figure 8 (page 33) shows the function of the ACIs for
each subtree. For more information about access control in the LDAP-UX domain, see Section 2.3.2.3
(page 37).
Figure 8 LDAP-UX domain subtrees and ACIs
ACIs allow management
by user and domain
administrator.
Identities
ou=People
LDAP_UX Domain
ACIs allow management
by domain administrator.
ou=Services,
ou=Configuration
CA Profile
Directory Server Profile
LDAP-UX Profile
ou=Groups
Domain Administrators
User Administrators
Host Administrators
...
Service Configuration
ACIs allow management by
host administrators and owners.
ou=Hosts
host 5
host 4
host 3
host 2
host 1
system and service
information such as
owner, IP address, …
host-based service
...
ACIs allow management by
user and host administrators.
2.3 Guided installation (autosetup) for an HP directory server environment
33
2.3.2.2 Information model
Within the various subtrees defined in the LDAP-UX domain, various types of objects can be
managed, including users, groups, and hosts. Management of these objects is based primarily on
existing standards (defined by RFCs 2307, 2798, and 4519) and extended schema defined for
LDAP-UX. Most manageable information registered for users, groups, and hosts is defined in the
RFCs. LDAP-UX includes two additional schemas named ssh_schema and ldapux50.
For information about the manageable objects and how they are defined in the LDAP-UX
configuration profile, see Section 2.3.2.2.1 (page 34). Information about the schema used by
LDAP-UX is included in Section 2.3.2.2.2 (page 36).
2.3.2.2.1 Managed objects and how they are defined
For the configuration objects, the LDAP-UX configuration profile created by the guided installation
uses the schema defined by RFC 4876. For service objects, the directory server and CA server
entries are described by the ldapux50 schema and RFC 4523.
The following examples display entries created for hosts, users, and groups, displayed in LDIF
format.
Example 1 Sample host entry
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
objectClass: top
objectClass: device
objectClass: ldapPublicKey
objectClass: iphost
objectClass: domainEntity
sshPublicKey: ssh-rsa AAAAB3Nza...
sshPublicKey: ssh-dss AAAAB3Nza...
sshPublicKey: 1024 35 140898...
owner: uid=domadmin,ou=people,dc=mydomain,dc=example,dc=com
ipHostNumber: 16.92.96.116
cn: hptem079
Example 2 Sample user entry
dn: uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com
uid: domadmin
givenName: Domain
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixaccount
sn: Administrator
cn: Domain Administrator
homeDirectory: /home/domadmin
loginShell: /usr/bin/sh
uidNumber: 1095
gidNumber: 1187
Example 3 Sample group entry
dn: cn=HostAdmins,ou=Groups,dc=mydomain,dc=example,dc=com
description: Administrators that are allowed to manage host attributes
objectClass: top
objectClass: groupofuniquenames
objectClass: posixgroup
34
Installing and configuring LDAP-UX Client Services for an HP server environment
owner: uid=domadmin,ou=people,dc=mydomain,dc=example,dc=com
uniqueMember: uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com
cn: HostAdmins
gidNumber: 1872
When LDAP-UX creates the configuration profile, attributes from RFC 2307 define most of the
information model used for users, groups, and hosts. The configuration profile is created mostly
with defaults, meaning that the search filters and attributes are based on RFC 2307
recommendations. However, the profile includes a few exceptions that help improve interoperability
with other LDAP-enabled applications. The following is a sample profile generated by the guided
installation. A summary of the enhancements made to improve interoperability follows the example.
Example 4 Sample configuration profile
dn: cn=mydomain-ldapuxProfile,ou=Services,ou=Configuration,
dc=mydomain,dc=example,dc=com
objectClass: top
objectClass: DUAConfigprofile
objectClass: configurableService
cn: cup-ldapuxProfile
preferredServerList: 192.168.10.20:389
profileTTL: 14400
defaultSearchBase: dc=domain,dc=example,dc=com
bindTimeLimit: 5
authenticationMethod: tls:simple
credentialLevel: proxy
attributeMap: passwd:userpassword=*NULL*
attributeMap: shadow:userpassword=*NULL*
attributeMap: group:userpassword=*NULL*
attributeMap: group:memberUid=uniqueMember member memberUid
attributeMap: passwd:gecos=cn l telephoneNumber
serviceSearchDescriptor: passwd:ou=People,
serviceSearchDescriptor: shadow:ou=People,
serviceSearchDescriptor: group:ou=Groups,
serviceSearchDescriptor: pam:ou=People,
serviceSearchDescriptor: rpc:ou=Services,
serviceSearchDescriptor: protocols:ou=Services,
serviceSearchDescriptor: networks:ou=Services,
serviceSearchDescriptor: hosts:ou=Hosts,
serviceSearchDescriptor: services:ou=Services,
serviceSearchDescriptor: printers:ou=Services,
serviceSearchDescriptor: automount:ou=Services,
serviceSearchDescriptor: netgroup:ou=Groups,
The guided installation enhances the configuration profile to improve interoperability with other
LDAP-enabled applications in the following ways:
•
Most all LDAP-enabled applications use the DN-based membership syntax, defined by the
X.500 standards. So, instead of using the memberUid attribute as the sole, primary attribute
for defining group membership, the guided installation uses the uniqueMember, member,
and memberUid attributes by default. In addition, when new members are added to a group
using the LDAP user or group management tools, LDAP-UX uses the uniqueMember attribute
to define that membership. It defines the membership based on the ordering found in
attributeMap, which lists a mapping from RFC 2307 attributes to alternate attributes.
•
Instead of using the gecos attribute to define account details, the cn (common name), l
(location), and telephoneNumber attributes are mapped to fill the GECOS field. This
eliminates the need to define the gecos attribute in the directory server.
2.3 Guided installation (autosetup) for an HP directory server environment
35
•
To use common authentication with other LDAP-enabled applications, the userPassword
attribute is defined as NULL. This means that it is not visible to applications on the HP-UX host.
But, applications use the standardized PAM framework to perform authentication.
2.3.2.2.2 Domain entity classification schema
The guided installation (and LDAP-UX B.05.00 or later) provides new schema that can be used to
manage information about users, groups, hosts, and services in your network. As indicated in
Table 3 (page 36) and Table 4 (page 37), LDAP-UX only uses some of the newly added schema
directly by default . The tables describe the full list of new attributes and object classes, and explain
how the schema are used. The recommended uses are merely advisory. Each organization can
customize usage to suit its unique needs. Table 3 (page 36) describes the new attributes.
Table 3 New attributes
Attribute name
Description and use
entityModel
Describes the model associated with the object. The ldaphostmgr tool (with
the -I option specified) uses this attribute to record the hardware model of the
HP-UX host.
entityVersion
Represents the version of the associated entity. The ldaphostmgr tool (with
the -I option specified) uses this attribute to record the version of the HP-UX OS
on a host.
entityUsage
Describes the designated usage of the object.
entityRole
Represents a role associated with the object. The ldaphostmgr tool (with the
-r option specified) will define this attribute.
entityFunction
Represents the function of the associated object.
entitySecurityLevel
Represents the security level of the associated object.
entityType
Represents the type of the associated object.
serviceConfigParam
Defines a configuration parameter for the associated service. Suggested format:
service-name[/subsystem[/...]]:service-specific-configuration-parameter
For example:
serviceConfigParam:
ssh/client/ssh_config:strictHostKeyChecking yes
serviceType
Describes the type of service supported by the entity.
servicePort
Describes the port of service supported by the entity, typically a TCP socket
number.
entityDomain
Represents a locally assigned name associated with a management collection.
The name can be a translated representation of the associatedDomain
attribute (RFC 4524) or a name provisioned from an organization-defined
procedure. The entityDomain value is expected to be unique within the larger
management space or at least within the associatedDomain.
cfgGlobalPolicyDN
Global policy DN to support central configuration service. If this attribute is
defined in the configuration profile, the central configuration service (ldapconfd)
will search the specified entry and download the configuration specified in the
serviceConfigParam attributes. As of release B.05.00, only HP Secure Shell
has configuration handlers to support centralized configuration management.
For more information about the central configuration service, see “Managing
ssh host keys with LDAP-UX (HP directory servers only)” (page 258).
sshPublicKey
Defines an ssh public key for the associated object.
Table 4 (page 37) describes the new object classes.
36
Installing and configuring LDAP-UX Client Services for an HP server environment
Table 4 New object classes
Attribute name
Description and use
networkService
Contains attributes that describe configurable service objects. It typically extends
the iPService object class.
domainEntity
An object class used to classify objects being managed, such as users, hosts,
etc.
configurableService
A subset of the networkService object class, it is used to indicate that at least
some services provided by the object can be centrally configured.
ldapPublicKey
An auxiliary object class that indicates the object has an associated ssh public
key.
The general intent of the object classes and attributes described by the schema is to provide a way
to help group and classify objects within an organization. For example, suppose an organization
wants to register printers in the directory server, and the organization has a policy that “Top Secret”
documents may only be printed on a restricted set of printers. The organization could have all
printers that are eligible for printing “Top Secret” documents created with the
entitySecurityLevel attribute value set to “Top Secret”. The conventions used with the
attributes in the preceding table, such as defining acceptable value sets, are entirely up to the
policies of the organization. The “Top Secret” printer is just one example of such a convention.
While the usage of the schema as defined in this section is entirely optional and up to the
organization, when classifying objects, organizations should consider standardizing key strings.
For example, a limited set of key strings should be defined for an object’s role, enabling the use
of LDAP search filters to easily identify all objects of the same role. For information about how to
use the schema for identifying classes of systems, see Section 7.8.6 (page 240).
Most of the attributes described in Table 3 (page 36) are multi-valued. For example, you can define
more than one role for an object by specifying the entityRole attribute with multiple values.
For more information about the schema described in this section, see the /etc/opt/ldapux/
schema/ldapux50.xml and /etc/opt/ldapux/schema/ssh_schema.xml files.
2.3.2.3 Security framework
When a new directory server instance is created, the guided installation defines a simple access
control framework that provides basic protection for data stored in that directory server.
In most directory server deployments, the general policy is to manage public data while maintaining
high data integrity. The guided installation creates access control instructions that instantiate such
a policy. Most attributes in the directory server are considered public to the organization in which
it is deployed. The guided installation establishes controls such that those attributes can be managed
by a limited (privileged) set of individuals. There are exceptions to this policy. For example, the
user’s password (stored in the userPassword attribute) is private. Another exception is that, to
protect data integrity, most attributes are modifiable only by a limited set of privileged administrators.
However, some attributes may be modified by users themselves. For example, a user may modify
his own userPassword.
Because the base access policy assumes most information is public, at least within the organization,
HP recommends that this access control policy be reviewed before you store private or confidential
data in the directory server. You can modify the ACIs to suit your organization's unique privacy
and integrity requirements. A review of the ACIs created by the guided installation are described
in the following subsections. For more specific information about the access control instructions
and how to modify them, see the HP-UX Directory Server administrator guide.
2.3.2.3.1 Proxy users
One of the primary principles of the base security policy is that, although most information is
considered public, the scope of users considered public is limited to those who can authenticate
2.3 Guided installation (autosetup) for an HP directory server environment
37
to the directory server. This means that information managed in the directory server subtree is
visible only to users who can bind and authenticate to the directory server. This policy is enforced
by the following ACI:
dn: dc=mydomain,dc=example,dc=com
aci: (targetattr!="userPassword || nisSecretKey")(version 3.0; acl "[ALL:READ:
NOT-PRIVATTRS] Enable proxied access"; allow (read, search, compare) userdn
="ldap:///all";)
Basically, this ACI states that if the name of the attribute (any attribute defining managed information)
is neither userPassword nor nisSecretKey, then it is visible to anyone who can bind to the
directory server (ldap:///all).
To assure that HP-UX hosts can retrieve user, group, and other information from the directory server,
the HP-UX OS must bind to the directory server on behalf of the users using the OS. To do this, a
proxy entry must be created in the directory server that represents the host and its OS. This is known
as the proxy user. The customized installation requires that you create the proxy user manually.
The guided installation automatically creates an entry in the directory server. This user (the host
entry) is created with a randomly-generated password. The information is recorded in the /etc/
opt/ldapux/pcred file.
2.3.2.3.2 Access control rights
To assure that administration rights are limited to specific individuals, access control instructions
are placed in the directory server to allow for administrator modification, owner modification, and
user self-modification:
•
Administration groups access control rights: These allow for three levels of administration.
Three types of administration groups are created to allow management of data in the directory
server:
◦
UserAdmins allows its members to create, modify, and remove user accounts. This
includes the ability to adjust user attributes, including passwords, account numbers, and
so forth. Members of this group can also manage groups, including creating, modifying,
and deleting groups, and adding and removing group members. The rights for
UserAdmins are granted with the following ACIs:
dn: ou=People,dc=mydomain,dc=example,dc=com
aci: (targetattr = "objectclass || cn || manager || gidNumber || givenName ||
homeDirectory || homePhone || memberUid || memberURL || memberOf || ou || s
n || uid || uidNumber || uniqueMember || userPassword || userCertificate") (
target = "ldap:///ou=People,dc=mydomain,dc=example,dc=com")(version 3.0;acl
"[USERADMIN:ALL:USERATTRS] Allow changes to User attributes by User Administ
rators";allow (all)(groupdn = "ldap:///cn=UserAdmins,ou=Groups,dc=mydomain,d
c=example,dc=com");)
dn: ou=Groups,dc=mydomain,dc=example,dc=com
aci: (targetattr = "cn || objectclass || member || uniqueMember || memberUid |
| gidNumber ")(version 3.0;acl "[USERADMIN:WRITE:USERGROUPATTRS] Allow User
Administrator Rights to modify group membership";allow (write) (groupdn = "l
dap:///cn=UserAdmins,ou=Groups,dc=mydomain,dc=example,dc=com");)
◦
HostAdmins allows its members to create, modify, and remove host accounts. This
includes the ability to adjust host attributes, including passwords, host names, IP addresses,
and so forth. Members of this group can also manage groups, including creating,
modifying, and deleting groups, and adding and removing members from these groups.
The rights for HostAdmins are granted with the following ACIs:
dn: ou=Groups,dc=mydomain,dc=example,dc=com
aci: (targetattr = "cn || objectclass || member || uniqueMember") (version 3.0
;acl "[HOSTADMIN:WRITE:HOSTGROUPATTRS] Allow Host Administrator Rights to mo
dify group membership";allow (write) (groupdn = "ldap:///cn=HostAdmins,ou=Gr
oups,dc=mydomain,dc=example,dc=com");)
dn: ou=Hosts,dc=mydomain,dc=example,dc=com
aci: (targetattr = "objectclass || cn || owner || host || ipHostNumber || ipNe
tmaskNumber || ipNetworkNumber || ipProtocolNumber || ipServicePort || ipSer
38
Installing and configuring LDAP-UX Client Services for an HP server environment
viceProtocol || sshPublicKey || oncRpcNumber || userPassword || userCertific
ate" )(version 3.0;acl "[HOSTADMIN:ALL:HOSTATTRS]: Allow changes to host att
ributes by Host Administrators";allow (all) (groupdn = "ldap:///cn=HostAdmin
s,ou=Groups,dc=mydomain,dc=example,dc=com");)
◦
DomainAdmins allows its members to have complete control of data managed under
the root suffix of the directory server. In other words, members can manage data used
by the local host OS and stored in the LDAP-UX domain. More specifically, this is the
data defined by the LDAP-UX configuration profile. Any member of this group is considered
a Domain Administrator. By default, the name of the Domain Administrator created by
the guided installation is domadmin. The rights for DomainAdmins are granted with the
following ACI:
dn: dc=mydomain,dc=example,dc=com
aci: (targetattr = "*")(version 3.0;acl "[DOMAINADMIN:ALL:ALLATTRS]: Allow changes
by Domain Administrators";allow (all) (groupdn = "ldap:///cn=DomainAdmins
,ou=Groups,dc=mydomain,dc=example,dc=com");)
•
Owners access control rights: LDAP-UX 5.0 simplifies demarcating ownership of items in the
directory server. Owners are considered any users or members of a group that have a DN in
the owner attribute of the target entry. Currently, only one type of owner exists: owners of
hosts. The rights of these owners are granted with the following ACI:
dn: ou=Hosts,dc=mydomain,dc=example,dc=com
aci: (targetattr = "sshPublicKey || ipHostNumber")(version 3.0;acl "[OWNER:ALL
:HOSTOWNERATTRS]: Allow owner modification of host information";allow (all)
userattr = "owner#USERDN";)
Based on this ACI, an owner of a host may change a host’s IP address or sshPublicKey.
Modifications for other attributes would require that of a Host or Domain Administrator.
•
Self (user) access control rights: To enable users to change their own passwords, some rights
must be granted to every user. These rights are granted through the following self-modify ACI:
dn: dc=mydomain,dc=example,dc=com
aci: (targetattr="carLicense || preferredLanguage || nisSecretKey || nisPublic
Key || sshPublicKey || userCertificate || userPassword || userSMIMECertific
ate || facsimileTelephoneNumber || homePhone || homePostalAddress || mobile
|| pager")(version 3.0; acl "[SELF:WRITE:SELFWRITEATTRS] Enable self write f
or common attributes"; allow (write) userdn="ldap:///self";)
As shown in this example, additional attributes (besides the user password) may be specified
to give users control of the associated entities, such as the car license (carLicense), preferred
language (preferredLangage), and so forth.
2.3.2.3.3 SSL/TLS and CA/server certificates
To assure the integrity of data that the directory server delivers to the HP-UX client, some means
must be established to validate the identity of the directory server. In addition, the data must be
protected in transit between the directory server and the HP-UX client. This is especially critical
when the directory server performs authentication for the HP-UX client, as the password of the
account being verified is transmitted to the directory server (when SIMPLE authentication is used).
To validate the identity of the directory server and encrypt data in transit, the guided installation
creates a CA certificate and a server certificate on the HP-UX host where the directory server
instance is created. These certificates serve to automatically enable SSL/TLS on the directory server.
To simplify distribution of the CA certificate, the guided installation automatically creates a depot
file that can be distributed to other HP-UX clients in the domain before configuring LDAP-UX on
them. This process preestablishes trust with the directory server. During the autosetup procedure,
you will see a message similar to the following, where mydomain.example.com is the name of
the LDAP-UX domain:
============================================================================
2.3 Guided installation (autosetup) for an HP directory server environment
39
NOTE: A CA certificate for the "mydomain.example.com" domain has been created.
This certificate can be pre-installed on HP-UX clients or included as part
of an HP-UX Ignite image. Installing this CA certificate on host will
pre-establish trust with this directory server. The depot file for this
CA certificate is found at : /tmp/ca-mydomain.example.com.depot
============================================================================
The depot contains one product that, when installed, will install the CA certificate for the LDAP-UX
domain on the host. For each domain, a CA certificate should be created, and the product created
will be named as follows:
#
#
#
#
#
#
swlist -d -s /tmp/ca-cup.hp.com.depot
Initializing...
Contacting target "hpt079"...
Target:
hpt079:/tmp/ca-cup.hp.com.depot
#
# No Bundle(s) on hpt079:/tmp/ca-cup.hp.com.depot
# Product(s):
#
LDAPUX-MYDOMAIN-CA
A.01.00
LDAP-UX mydomain.example.com domain CA Certificate
NOTE: SSL/TLS protocols support a variety of different cryptographic algorithms (ciphers) for
use in authentication operations between server and client, certificate transmissions, and session
key establishment. If a cipher is found to be flawed and subject to attack, administrators of HP-UX
and the directory server must know about their vulnerability. Ciphers can be disabled in the directory
server. For information about SSL/TLS ciphers and which ones are supported by LDAP-UX, see
Section 2.4.6.5 (page 84).
Some organizations might prefer to distribute this certificate product by preinstalling it on an
Ignite-UX image or on other media that can be used to distribute and install new instances of HP-UX.
As part of generating the server certificate, the guided installation creates a pin.txt file to hold
the password it uses for retrieving the server certificate private key. The guided installation requires
access to the private key to automatically start up the newly-created directory server. The private
key validates the directory server’s identity.
The private key is stored in the /etc/opt/dirsvr/slapd-domain-instanceName/key3.db
file. The pin.txt file that holds the private key password is stored in the same directory. (The
instanceName of the first directory server created on a host will always be
domain-name-prefix-master, where domain-name-prefix is the prefix of the DNS domain
name.)
WARNING! The root user, or any user that can bypass file system access controls, can read the
pin.txt file. Any user that has access to the pin.txt, cert8.db, and key3.db files can use
them to impersonate a directory server. Therefore, ensure that you restrict access to the accounts
of the root user and users that can bypass file system access restrictions.
For security purposes, you can consider removing the pin.txt file and requiring that the private
key password be manually entered whenever the directory server is restarted. However, requiring
manual password entry at every startup can have drawbacks. For example, consider the impact
for server availability after a reboot or power failure.
The CA certificate generated when the guided installation creates the first directory server (the
master instance) is stored in the /etc/opt/dirsvr/slapd-domain-master/cacert.pk12
40
Installing and configuring LDAP-UX Client Services for an HP server environment
file. The password to protect that file is stored in
/etc/opt/dirsvr/slapd-domain-master/pk12-passwd.txt.
WARNING! Any user that can access the pk12-passwd.txt file and the cacert.pk12 file
can create a new directory server with sufficient trust to be considered part of the LDAP-UX domain.
Such a user can control what data is visible to the HP-UX hosts. Any host with a server certificate
signed by the CA certificate will be considered a trusted directory server. Be sure to restrict access
to privileged accounts that can bypass file access restrictions on the local host.
2.3.3 Using the guided installation autosetup command—syntax and options for HP
directory server environments
You can run the autosetup script interactively, responding to prompts to provide information.
You can pass parameters in the command line to reduce the need for providing input during the
installation. In some cases, you can run the script in silent mode, which requires no user interaction
during the installation.
To run the script interactively, simply enter the autosetup command as is. The script prompts you
for the minimal information required. To reduce user interaction during the installation, you can
pass parameters by specifying options in the command line. In addition to these options, you can
define environment variables with defined parameter settings; ultimately, this enables you to run
the installation without any manual intervention required. This section describes the command-line
options and environment variables.
The syntax for the autosetup command line is:
autosetup [option1 option1-value [option2 option2-value] ...]
The options are described in Section 2.3.3.1 (page 41).
For detailed information about how to perform the guided installation and how autosetup
configures the LDAP-UX environment, see:
•
“Guided installation steps: New Directory Server Installation mode” (page 46)
•
“Guided installation steps: Existing Directory Server Installation mode” (page 52)
•
“Guided installation steps: Existing LDAP-UX Domain Installation mode” (page 55)
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client and the HP-UX system (where you are running autosetup) is
secured and not subject to network eavesdropping. One option to protect such communication
might be to use the ssh protocol when connecting to the HP-UX host being configured.
2.3.3.1 autosetup options
The following options may be specified on the command line for installations:
-D privileged_user_DN
When creating a new directory server, or setting up a new
LDAP-UX environment with an existing directory server, this
typically specifies the Directory Manager's distinguished name
(DN) (for the latter scenario, it can be at minimum any user who
has sufficient privileges to update the schema on the directory
server). When configuring LDAP-UX in an existing LDAP-UX
domain, this can be the DN of any member of the
DomainAdmins or HostAdmins groups — host administrators
that have privileges to add hosts to the domain (but more limited
2.3 Guided installation (autosetup) for an HP directory server environment
41
privileges than the Directory Manager) — or any user given
sufficient privileges by the directory server administrator.
This is the bind DN that LDAP-UX clients use for accessing the
HP-UX Directory Server. The default is cn=Directory Manager
when creating a new LDAP-UX domain, and
uid=domadmin,ou=people,domainBaseDN when joining
an existing one. An example of a setting for this variable is
uid=domadmin,ou=people,dc=document,dc=hp,dc=com.
-b search_base
Specifies the base DN for which search operations should be
performed for an existing LDAP-UX domain, or the base DN used
when creating a new LDAP-UX domain; for example,
dc=lab,dc=acme,dc=com. Typically, set the base DN to the
directory's suffix value. Because the directory suffix is equal to
the root, or topmost, entry in the directory, this causes all
searches to begin from the directory's root entry. If not specified,
the default when creating a new directory server instance will
be generated using the local DNS domain name. With an
existing directory server, the default is discovered from the list
of default naming contexts on the existing directory. This option
only applies for LDAP-UX installations in a directory server
environment. If specified with an LDAP-UX Windows Server AD
installation, this variable is ignored.
-h host_name
Specifies localhost or the host name (or IP address), and
optionally the port number, of an existing directory server that
contains an existing LDAP-UX domain or of a directory server
that is to be configured for LDAP-UX support. When keyword
localhost is specified, a directory server is created on the
local host. The default host name is the fully-qualified DNS
domain name of the host; the default port is 389. Specify in one
of the following formats:
localhost
host-name
host-name:port
ip-address
ip-address:port
42
-j password_filename
Specifies a file that includes the password for the user specified
with the -D option. Specifying this file enables autosetup to
run without prompting you for the password; thus, it enables you
to perform the guided installation in silent mode.
-N profile_name
Specifies the configuration profile name that autosetup will
download from the directory server, if the profile exists. If the
specified profile entry does not exist in the directory server,
autosetup creates it. The default profile name is
ldapuxprofile. The autosetup program uses this default
profile name only if you do not use this option.
-p ds_port_id
Specifies the number of the port that clients use for accessing
the directory server. This is the port clients access to search the
directory server for entries. The default is port number 389. You
need not specify the port if it has already been specified with
the host name.
Installing and configuring LDAP-UX Client Services for an HP server environment
-s ds_sslport_id
Specifies the number of the directory server SSL port for accessing
the directory server when SSL options are used. The default is
SSL port 636.
-v n
Specifies verbose level for debugging purposes, with n specifying
one of the following: 0 (turns off verbose mode), 1, 2, or 3
(specifies the highest level of verbosity).
-x domain_name
When configuring LDAP-UX in a directory server environment,
this option specifies the LDAP-UX domain name; for example,
accounting.acme.com. The specified name will be used to
define the suffix of the new directory server's directory tree. If
you do not specify the domain name, this tool obtains it from
DNS by executing nslookup on the host name of the local
system.
-q
Specifies that autosetup be invoked in silent (quiet) mode.
Silent mode runs without user intervention. Instead of prompting
for input for parameters such as the Configuration Administrator
or Domain Administrator, it uses the default values and any
values specified with command-line options or environment
variables. If values are not given for any required parameters
that do not have defaults, silent mode will abort. For this reason,
silent mode is not valid when installing LDAP-UX on a host for
the first time (creating a new directory server requires user
intervention).
NOTE: The first column of the following table lists parameters that cannot be specified with options
in New Directory Server Installation mode. These parameters can be set with the environment
variables indicated in the second column. For more information about the environment variables,
see Section 2.3.3.2 (page 43).
Parameter
Environment variable alternative
Short name of the directory server Configuration Administrator
DS_ADMIN_NAME
Password of directory server Configuration Administrator
DS_ADMIN_PASS
Host name (and optionally, port number) of the Administration Server for the
administration domain the directory server will join
DS_ADMIN_SERVER
Port number of the directory server's Administration Server
DS_ADMIN_PORT
Instance name of new directory server
DS_INSTANCE_NAME
Name of the LDAP-UX Domain Administrator
LDAP_DOMAIN_ADMIN
Password of the LDAP-UX Domain Administrator
LDAP_DOMAIN_ADM_PASSWD
2.3.3.2 autosetup environment variables
The following environment variables can be used with autosetup.
DS_ADMIN_NAME
Sets the short name of the directory server Configuration
Administrator, responsible for managing the directory servers
in the directory server administration domain. The default short
name is admin. No command option exists for passing this
name on the command line. Only used in New Directory Server
Installation mode (installing LDAP-UX for the first time).
2.3 Guided installation (autosetup) for an HP directory server environment
43
DS_ADMIN_PASS
Sets the password for the directory server Configuration
Administrator, responsible for managing the directory servers
in the directory server administration domain. Only used in
New Directory Server Installation mode (installing LDAP-UX for
the first time). No command option exists for passing this
password on the command line.
DS_ADMIN_PORT
Sets the port number of the directory server's Administration
Server, which manages the directory server administration
domain. . The default port number is 9830. You need not
specify the port if it has already been specified with the host
name. No command option exists for passing this port number
on the command line. Only used in New Directory Server
Installation mode (installing LDAP-UX for the first time).
DS_ADMIN_SERVER
Sets the host name (or IP address), and optionally the port
number, of the directory server's Administration Server, the
server that manages the directory server administration domain
that the new directory server will join. Only used in New
Directory Server Installation mode (installing LDAP-UX for the
first time). The default port is 389. Specify in one of the
following formats:
host-name
host-name:port
ip-address
ip-address:port
44
DS_INSTANCE_NAME
Sets the name of the newly created directory server instance.
This is the only way to set the instance name when creating a
directory server. If this variable is not used, autosetup
automatically generates the instance name in the format
dns-prefix-master, where dns-prefix is the prefix of
the local host's DNS domain name. For example, if the local
host's DNS domain name is west.acme.com, the generated
instance name would be west-master. Only used in New
Directory Server Installation mode (installing LDAP-UX for the
first time).
LDAP_BASEDN
Sets the search base DN; for example,
dc=lab,dc=acme,dc=com. A search operation is performed
on the base DN, the DN of the entry and all entries below it
in the directory tree. Typically, set the base DN to the directory's
suffix value. Because the directory suffix is equal to the root,
or topmost, entry in the directory, this causes all searches to
begin from the directory's root entry. Equivalent to using the
-b option in the command line.
LDAP_BINDDN
When creating a new directory server, this specifies the
Directory Manager's distinguished name (DN). When installing
and configuring LDAP-UX in an existing directory server
environment or LDAP-UX domain, this is the DN of any member
of the DomainAdmins group — host administrators that have
privileges to add hosts to the domain (but more limited
privileges than the Directory Manager). This is the bind DN
that LDAP-UX clients use for accessing the HP-UX Directory
Installing and configuring LDAP-UX Client Services for an HP server environment
Server. The default is cn=Directory Manager. An example
of a setting for this variable is:
LDAP_BINDDN=uid=domadmin,ou=people,dc=document,dc=hp,dc=com.
Equivalent to using the -D option in the command line.
LDAP_BINDCRED
Sets the password for the user defined by LDAP_BINDDN.
Equivalent to using the -j option in the command line (except
this command-line option specifies a file containing the
password).
LDAP_DOMAIN_ADMIN
Sets the name of the LDAP-UX Domain Administrator, who is
responsible for managing all data in the LDAP-UX domain and
can create a new administration domain and register all
directory servers in that domain. If this variable is not defined
for use with autosetup, the default is domadmin. No
command option exists for passing this name on the command
line.
This variable only applies for LDAP-UX installations when
creating a new directory server environment. If specified with
an LDAP-UX Windows Server AD installation, this variable is
ignored.
LDAP_DOMAIN_ADM_PASSWD
Sets the password for the LDAP-UX Domain Administrator. No
command option exists for passing this password on the
command line.
This variable only applies for LDAP-UX installations when
creating a new directory server environment. If specified with
an LDAP-UX Windows Server AD installation, this variable is
ignored.
LDAP_DOMAIN
Sets the LDAP-UX domain name; for example,
accounting.acme.com. Equivalent to using the -x option
in the command line. If the search base is not specified with
the -b option and with the LDAP_BASEDN variable, the
LDAP_DOMAIN variable determines the search base. If you do
not specify the domain name, this tool obtains it from DNS by
executing nslookup on the host name of the local system.
The LDAP_DOMAIN variable only applies for LDAP-UX
installations in a directory server environment. If specified with
an LDAP-UX Windows Server AD installation, this variable is
ignored.
LDAP_HOSTPORT
Sets the host name (or IP address), and optionally the port, of
an existing directory server that is to be configured for LDAP-UX
support. Equivalent to using the -h and -p options in the
command line. The default host name is the fully-qualified DNS
domain name of the host; the default port is 389. Specify in
one of the following formats:
host-name
host-name:port
ip-address
ip-address:port
2.3 Guided installation (autosetup) for an HP directory server environment
45
LDAP_SSLPORT
Sets the SSL port of the directory server to be created or, if one
already exists, to be configured for LDAP-UX support.. The
default is 636.
2.3.3.3 autosetup command examples
The following are examples showing how to run autosetup with command-line options:
Example 5 autosetup: interactive mode with verbose set at the highest level
# autosetup -v 3
This command runs autosetup interactively, with verbose set at the highest level.
Example 6 autosetup: passing two parameters directly in the command line along with a password
file
# autosetup -D "cn=Directory Manager" -j /tmp/jfile -x document.hp.com
This command specifies the Directory Manager and a file that includes the password required for
the Directory Manager of the directory server being created. The command also specifies the
LDAP-UX domain name. When you invoke autosetup, you are not prompted for these parameters.
Example 7 autosetup command for silent mode
# autosetup -h blipsa01 -D "uid=phil,ou=people,dc=document,dc=hp,dc=com" -j /tmp/jfile -q
This command specifies the host name of the directory server that contains the LDAP-UX domain
to be joined. In addition, it specifies the bind DN (the user who has privileges to add the host to
the LDAP-UX domain) and a file that includes the password for this user.
Example 8 autosetup: silent mode
# autosetup -q
This command invokes silent mode. It can be used in any scenario in which user intervention is not
required.
2.3.4 Guided installation steps: New Directory Server Installation mode
This section explains how to install LDAP-UX into a new environment and create a new HP-UX
Directory Server for managing the LDAP-UX data. Section 2.3.4.1 (page 47) shows how to perform
the guided installation interactively, explaining step-by-step how to respond to each prompt for
user input. Section 2.3.4.2 (page 50) shows how to run a completely-automated guided installation
by specifying all required user input in the command line.
46
Installing and configuring LDAP-UX Client Services for an HP server environment
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 that are local to the hosts
in the LDAP-UX domain. 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 the 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).
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client and the HP-UX system (where you are running autosetup) is
secured and not subject to network eavesdropping. One option to protect such communication
might be to use the ssh protocol when connecting to the HP-UX host being configured.
2.3.4.1 Interactively running New Directory Server Installation mode
To interactively install LDAP-UX and create a new HP-UX Directory Server for your LDAP-UX
environment, follow these steps. Before you begin, make sure you have installed the HP-UX Directory
Server product on the local host.
1.
Log in as root and run the autosetup command, as shown in the following example:
# /opt/ldapux/config/autosetup
2.
The script detects whether a registered LDAP-protocol directory server instance exists in the
local DNS domain. You are creating a new LDAP-UX environment that needs a new directory
server, so a directory server is not found, as indicated. The first prompt gives you several
options. To run the installation so that it sets up a new directory server, press Enter, as shown:
Scanning DNS domain west.acme.com for any registered LDAP directory servers
- No directory servers found.
Please enter the host name and port number of a directory server,
a Windows domain name, or press Return to create a new directory
server on this host: Enter
3.
The script begins creating a new directory server instance on the local host. It creates the
Directory Manager root DN as cn=Directory Manager and prompts you to create a
password and to reenter the password to confirm (the password is hidden):
The directory server requires a "super-user" ID. This ID has all
privileges (is not subject to any access control) on the directory server
and the name is set as "cn=Directory Manager". Please enter a password
for this user.
Please enter the "cn=Directory Manager" password: [password not displayed] Enter
Please re-enter the "cn=Directory Manager" password: [password not displayed] Enter
As indicated, the Directory Manager has all privileges and is not subject to directory server
access control policies. The Directory Manager is a unique, powerful entry that is typically
used to repair and recover from errors in the configuration. The Directory Manager can correct
problems that affect users who do not have access control privileges for doing so. There is no
directory entry for the Directory Manager user; it is used only for authentication. You cannot
create an actual directory server entry that uses the same distinguished name (DN) as the
2.3 Guided installation (autosetup) for an HP directory server environment
47
Directory Manager DN. For more information about the Directory Manager and other
administrators, see Section 1.4 (page 23).
4.
The script asks whether you want to manage the new directory server in an existing HP-UX
Directory Server administration domain (Admin domain) or whether you want to create a new
directory server administration domain. To direct the installation to set up the new directory
server in an existing administration domain, specify the host name and optionally the port
number of the Administration Server that manages the existing domain, such as
east.acme.com:389. To create a new directory server administration domain on the local
host, press Enter. In the following example, the user opts to create a new domain. (For more
information about this and other domains in the LDAP-UX environment, see Section 1.3
(page 22).)
HP-UX Directory Server supports management of multiple directory server
instances under one administration domain. Would you like to manage this
directory server in an existing HP-UX Directory Server administration domain?
If so, enter the host name and optionally the port of the directory server
that manages that topology (for example, acme.bus.com:389). Or, to create
a new directory server administration domain, simply press Return.
(hostname[:port]|Return): Enter
5.
Enter the short name of the Configuration Administrator required to manage the directory
servers and the new directory server administration domain. The default short name is admin.
In this example, the user takes the default.
A Configuration Administrator is required to manage the
directory servers and the administration domain. This user has
configuration and administration privileges on all directory servers
in the administration domain, but is subject to access control
(unlike the Directory Manager). Please Enter the short name of the
Configuration Administrator (typically "admin") [admin]: Enter
The Configuration Administrator (also known as the Directory Administrator) is the “super
user” who has configuration and administration privileges for all directory servers in the
managed domain, and so has the power to modify directory server configurations and to
create, start, and back up any of the directory servers in the managed domain. The
Configuration Administrator has fewer access privileges to the directory server than does the
Directory Manager.
6.
Create a password for the new Configuration Administrator and reenter it to confirm:
Please enter the password for the Configuration Administrator.
Please enter the "admin" password: [password not displayed] Enter
Please re-enter the "admin" password: [password not displayed] Enter
7.
Specify the name of the LDAP-UX domain that is to be created; this is the domain that
distinguishes data managed by the new directory server from data managed by other director
servers in other domains. The default is the host's DNS domain name. In this example, the
default is taken.
Please enter the domain name that can be used to distinguish data managed on
this directory server from data managed by other directory servers in other
domains. This will be used to define the suffix of the directory tree.
Please enter the domain [west.acme.com]: Enter
8.
Specify the name of the LDAP-UX Domain Administrator. The LDAP-UX Domain Administrator
is responsible for managing all data in the LDAP-UX domain and can create a new
administration domain (created in a previous step) and register all directory servers in that
domain. The default is domadmin.
An LDAP-UX domain administrator is used to manage all data within
48
Installing and configuring LDAP-UX Client Services for an HP server environment
the LDAP-UX domain. The domain administrator has fewer privileges than the
Directory Manager or Configuration Administrator. This account will be the
primary account used to manage data within the directory server, or its
privileges can later be distributed to other users. This account should
typically be associated with an individual and may be named as such. The
account name should be 8 characters or less, since this account can be used on
the HP-UX OS.
Enter Domain Administrator's account name [domadmin]: Enter
9.
Enter the password for the LDAP-UX Domain Administrator and then reenter it to confirm:
Please enter the "domadmin" password: [password not displayed] Enter
Please re-enter the "domadmin" password: [password not displayed] Enter
The installation now begins, followed by other related tasks; autosetup displays the progress
and results, as in the following example.
NOTE: For future reference, be sure to record the information displayed. To record this information,
you can use Table 5 (page 50) . The table also describes the parameters that were configured in
the preceding example.
Creating new directory server instance in local host...
Creating directory server master instance "west-master". Please wait ...
Successfully created master instance with the following parameters:
Instance name: west-master
Host name: acctl053.west.acme.com
Server port: 389
Admin URL: http://acctl053.west.acme.com:9830
SSL port: 636
Domain name: west.acme.com
Domain suffix: dc=west,dc=acme,dc=com
Domain Admin: domadmin
*
*
*
*
*
*
*
*
*
Generating a self-signed CA Certificate "WEST CA Certificate" ... completed.
Generating a server certificate "west-master Certificate" ... completed.
Enabling SSL on directory server instance west-master ... completed.
Restarted the Directory Server instance west-master.
Created directory server subtree.
Added Domain and Host Administrator user/groups to the directory server.
Created Domain Administrator account : "domadmin".
Extended directory server schemas.
Registered CA and server certificates in directory server.
============================================================================
NOTE: A CA certificate for the "west.acme.com" domain has been created.
This certificate can be pre-installed on HP-UX clients or included as part
of an HP-UX Ignite image. Installing this CA certificate on host will
pre-establish trust with this directory server. The depot file for this
CA certificate is found at : /tmp/ca-west.acme.com.depot
============================================================================
Setting up the LDAP-UX client using the newly created directory server.
Loading CA certificate from directory server to local host ... done.
* Extending schemas ... done.
No LDAP-UX Configuration Profile was found. Creating a new one.
*
*
*
*
*
*
*
Downloading profile from DS ... done.
Configuring ldapux_client.conf ... done.
Provisioning LDAP-UX Client information into the Directory Server ... done.
Setting up proxy user ... done.
Configuring "/etc/nsswitch.conf" and "/etc/pam.conf" to use ldap ... done.
Starting ldapclientd daemon ... done.
Starting ldapcconfd ... done.
2.3 Guided installation (autosetup) for an HP directory server environment
49
LDAP-UX was successfully configured.
As indicated in the guided installation log, the guided installation configures LDAP-UX and starts
the LDAP-UX daemon (ldapclientd) and the central configuration service (ldapconfd). For
more information about the files configured by autosetup, see “Samples of LDAP-UX configuration
files created or modified by autosetup” (page 410). For more information about the central
configuration service, see “Managing ssh host keys with LDAP-UX (HP directory servers only)”
(page 258).
For more information about the CA and server certificates that are registered in the directory server,
see Section 2.3.2.3.3 (page 39).
Table 5 (page 50) lists the items configured by the guided installation and gives the values displayed
in the example in Section 2.3.4.1 (page 47), in which no parameters were specified in the command
line.
Table 5 New Directory Server Installation mode configuration values
Parameter
Value in example
Instance name
west-master (if the instance name
is not predefined in an environment
variable (DS_INSTANCE_NAME), as
described in Section 2.3.3.2
(page 43)), it is automatically
generated as in this example, based
on the prefix of the local host's DNS
domain name west.acme.com (and
adding -master for the first directory
server created in the domain)
Host name
acct1053.west.acme.com (when
creating a new directory server, the
host name prefix is based on the local
computer name (acct1053); the
remainder of the host name is based
on the DNS name)
Server port
389 (default)
Admin URL
http://
acctl053.west.acme.com:9830
(generated from the computer name
and DNS domain name, this is the
directory server's Administration
Server location, which is used for the
Directory Server Console, for example)
SSL port
636 (the default port number for LDAP
with TLS/SSL)
Domain name
west.acme.com (this is the LDAP-UX
domain name; unless specified, it is
generated automatically from the DNS
domain name)
Domain suffix
dc=west,dc=acme,dc=com (the
LDAP-UX domain suffix was generated
automatically from the domain name)
Domain Admin
domadmin (the default for the Domain
Administrator)
Value for your installation
2.3.4.2 Automating New Directory Server Installation mode
To install LDAP-UX for the first time on a host and create a new directory server, you must run the
script interactively to indicate at minimum, when prompted, that you want a new directory server
50
Installing and configuring LDAP-UX Client Services for an HP server environment
created. You can use command-line options and environment variables to completely automate
the rest of the procedure. In the example provided in this section, the following environmental
variables are defined for all the parameters needing input. Certain parameters cannot be provided
by command-line options.
•
LDAP_BINDDN="cn=Directory Manager"
•
LDAP_BINDCRED="dmdontforget"
•
LDAP_DOMAIN_ADMIN="domadmin"
•
LDAP_DOMAIN="west.acme.com"
•
LDAP_DOMAIN_ADM_PASSWD="4getmeknot"
•
DS_ADMIN_NAME="admin"
•
DS_ADMIN_PASS="4getmenot"
Running autosetup results with the following installation. As shown (in bold), user intervention
is required only twice after the procedure starts.
# ./autosetup
Scanning DNS "west.acme.com" domain for any registered LDAP directory servers...
No directory server found.
Please enter the host name and port number of a directory server
[hostname:port], a Windows domain name, or press Return to create
a new directory server on this host: Enter
HP-UX Directory Server supports management of multiple directory server
instances under one administration domain. Would you like to manage this
directory server in an existing HP-UX Directory Server administration domain?
If so, If so, enter the host name and optionally the port of the directory server
that manages that topology (for example, acme.bus.com:389). Or to create
a new directory server administration domain, simply press Return.
(hostname[:port]|Return): Enter
Creating new directory server instance in local host...
Creating directory server master instance "west-master". Please wait ...
Successfully created master instance with the following parameters:
Instance name: west-master
Host name: acct1053.west.acme.com
Server port: 389
Admin URL: http://acct1053.acme.com:9830
SSL port: 636
Domain name: west.acme.com
Domain suffix: dc=west,dc=acme,dc=com
Domain Admin: domadmin
*
*
*
*
*
*
*
*
*
Generating self-signed CA certificate "WEST CA Certificate" ... completed.
Generating server certificate "west-master Certificate" ... completed.
Enabling SSL on directory server instance west-master ... completed.
Restarted directory server instance west-master.
Created directory server subtree.
Added Domain and Host Administrator user/groups to the directory server.
Created Domain Administrator account : "domadmin".
Extended directory server schemas.
Registered CA and server certificates in directory server.
============================================================================
NOTE: A CA certificate for the "west.acme.com" domain has been created.
This certificate can be pre-installed on HP-UX clients or included as part
of an HP-UX Ignite image. Installing this CA certificate on host will
pre-establish trust with this directory server. The depot file for this
CA certificate can be found at : /tmp/ca-west.acme.com.depot
============================================================================
2.3 Guided installation (autosetup) for an HP directory server environment
51
Setting up the LDAP-UX client using the newly created directory server.
Loading CA certificate from directory server to local host ... done.
* Extending schemas ... done.
No LDAP-UX Configuration Profile was found. Creating a new one.
*
*
*
*
*
*
*
Downloading profile from DS ... done.
Configuring ldapux_client.conf ... done.
Provisioning LDAP-UX Client information into the Directory Server ... done.
Setting up proxy user ... done.
Configuring "/etc/nsswitch.conf" and "/etc/pam.conf" to use ldap ... done.
Starting ldapclientd daemon ... done.
Starting ldapcconfd ... done.
LDAP-UX was successfully configured.
2.3.4.3 Postinstallation steps for New Directory Server Installation mode
After completing a New Directory Server mode guided installation, perform these steps:
1.
2.
3.
4.
The autosetup process created a new HP-UX account, the Domain Administrator (also known
as domadmin). It also created three new groups: DomainAdmins, HostAdmins, and
UserAdmins. Ensure that the user and group numbers (UIDs and GIDs) of the information
you are importing or migrating does not collide with those numbers that were created by
autosetup, as explained in Section 2.5.1.1 (page 90).
Consider registering the new directory server using an LDAP server record in the host's DNS
domain (contact your DNS domain administrator). For more information, refer to RFC 2782.
When a new directory server instance is created, autosetup generates a CA and server
SSL/TLS certificate for this instance. The generated CA certificate can be distributed to other
HP-UX clients to preestablish trust and confidentiality with the directory server just created. The
CA certificate has been conveniently packaged in a Software Distributor depot file. The CA
product found in this depot will install the CA certificate in the /etc/opt/ldapux/cert8.db
file on any host where you install the CA product. As a means to preestablish trust with the
directory server, you can simplify distribution of this CA certificate by including the CA product
in an Ignite-UX depot. You can view the contents of this depot file with the swlist -s
/tmp/ca-west.acme.com.depot command.
Perform the postinstallation configuration tasks documented in Section 2.5 (page 89), as
needed.
2.3.5 Guided installation steps: Existing Directory Server Installation mode
This section explains how to install LDAP-UX for the first time on a host that already has a valid
directory server. Section 2.3.5.1 (page 52) shows how to perform the guided installation
interactively, explaining step-by-step how to respond to each prompt for user input. Section 2.3.5.2
(page 54) shows how to run a completely-automated (silent mode) guided installation.
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client and the HP-UX system (where you are running autosetup) is
secured and not subject to network eavesdropping. One option to protect such communication
might be to use the ssh protocol when connecting to the HP-UX host being configured.
2.3.5.1 Interactively running Existing Directory Server Installation mode
To interactively install LDAP-UX into an environment that already has a valid directory server, follow
these steps. This example assumes that you have preinstalled a CA certificate, as described in step
2.
1.
Log in as root and run the autosetup command, as shown in the following example:
# /opt/ldapux/config/autosetup
52
Installing and configuring LDAP-UX Client Services for an HP server environment
2.
The autosetup script searches for a registered LDAP-protocol directory server in the local
DNS domain but does not find one, as indicated in the following example.
NOTE: The script searches for a registered server only if the directory server was not specified
with the -h option command-line option or LDAP_HOSTPORT environment variable. If a
registered directory server is found, autosetup uses that directory server automatically.
The script gives you the option of entering the host identification of an existing directory server
(along with two other options). The installer specifies host name hpdhcalif (a directory
server already exists, so a new directory server is not needed for serving LDAP-UX clients).
Scanning DNS domain "west.hp.com" for any registered LDAP directory servers...
- No directory servers found.
Please enter the host name and port number of a directory server,
a Windows domain name, or press Return to create a new directory
server on this host [host: hpdhcalif Enter
NOTE:
Unless you preinstall a CA or server certificate for the directory server, the autosetup tool
has no means of validating the identity of the directory server. The tool can download and
permanently install the CA or server certificate for the server; however, the server could be
an impostor. If autosetup created the specified server, it created a depot file on that server's
host that contains the CA certificate for that server. The depot on the specified host in this
example is found at : /tmp/ca-calif.acme.com.depot. The depot file can be distributed
to your host or any other HP-UX clients to be established in the same LDAP-UX domain. By
installing it on your host before configuring LDAP-UX, you preestablish trust with the specified
remote server. For more information, see Section 2.3.2.3.3 (page 39).
If the specified server was not created by autosetup, you can obtain the CA or server
certificate directly from the server (in /etc/opt/ldapux) and preinstall it on your host,
following the instructions in Section 2.4.6.4 (page 82).
If the CA certificate is not installed on your local host at this point of the guided installation,
autosetup warns you that it cannot validate the identity of the remote server and suggests
installing the CA certificate. You can abort so that you can install the CA certificate before
proceeding with the rest of the guided installation, or you can continue, trusting the CA
certificate that will be installed automatically by autosetup.
This example assumes the CA certificate has already been installed; therefore, you will not
see the warning and the prompt asking whether to abort or continue.
3.
The script then asks for the DN of the directory server user who can add the local host to the
directory server's LDAP–UX domain. This is any host administrator with such privileges (a
member of the DomainAdmins group). In this example, the DN for the user with such privileges
is uid=domadmin,ou=people,dc=calif,dc=acme,dc=com. The server's DNS domain
in this example is calif.acme.com; this will be the name of the LDAP-UX domain configured
by autosetup. This being the first time adding an HP-UX host to this directory server, LDAP-UX
will extend the server's schema.
Please enter the DN of a user that has sufficient privilege to add this host
to the "calif.acme.com" domain. Note also that if this is the first
time adding an HP-UX host to this directory server, LDAP-UX may
also need to extend the server's schema. Please enter the DN of an
Administrator with these privileges or press Return for the default value.
[uid=domadmin,ou=people,dc=calif,dc=acme,dc=com]: Enter
4.
Enter the password for the user identified in the preceding step (the entered password is not
visible):
2.3 Guided installation (autosetup) for an HP directory server environment
53
Enter the password for the above user: [password not displayed] Enter
The installation now begins, followed by other related tasks; autosetup displays the progress
and results, as in the following example. As indicated, because an existing LDAP-UX configuration
profile does not exist, autosetup creates a new one. The profile and the associated LDAP-UX
domain will be based on the existing directory tree. In addition, autosetup provisions information
about the local host into the existing directory server.
* Extending schemas ... done.
No LDAP-UX Configuration Profile was found.
*
*
*
*
*
*
*
Creating a new one.
Downloading profile from DS ... done.
Configuring ldapux_client.conf ... done.
Provisioning LDAP-UX Client information into the Directory Server ... done.
Setting up proxy user ... done.
Configuring "/etc/nsswitch.conf" and "/etc/pam.conf" to use ldap ... done.
Starting ldapclientd daemon ... done.
Starting ldapcconfd ... done.
LDAP-UX was successfully configured.
NOTE:
For more information about the configuration files created or modified by autosetup,
see “Samples of LDAP-UX configuration files created or modified by autosetup” (page 410). You
can display details about the LDAP-UX Client Services configuration by using the
/opt/ldapux/config/display_profile_cache command. For more information about
the use of this command, see Section 9.2.4 (page 280).
2.3.5.2 Automating Existing Directory Server Installation mode
For this mode of installation, you can run autosetup in silent mode and provide values for
parameters in the command line or with environment variables. As discussed in Section 2.3.5.1
(page 52), you must preestablish trust with the remote directory server by installing the CA certificate
before running autosetup. To perform this installation without user interaction, you must specify
the following in command-line options or environment variables:
The bind DN (the DN of the directory server user who can add the local host to the directory
server's LDAP-UX domain): use either the -D option or the LDAP_BINDDN variable.
The password used with the bind DN: use either -j option or the LDAP_BINDCRED variable.
The host name of the directory server being joined: use either -h option or the LDAP_HOSTPORT
variable.
In the following example, these parameters are specified in the command line:
# ./autosetup -h hpdhcalif -D "uid=domadmin,ou=people,dc=calif,dc=acme,dc=com" -j /tmp/jfile -q
* Extending schemas ... done.
No LDAP-UX Configuration Profile was found.
*
*
*
*
*
*
*
Creating a new one.
Downloading profile from DS ... done.
Configuring ldapux_client.conf ... done.
Provisioning LDAP-UX Client information into the Directory Server ... done.
Setting up proxy user ... done.
Configuring "/etc/nsswitch.conf" and "/etc/pam.conf" to use ldap ... done.
Starting ldapclientd daemon ... done.
Starting ldapcconfd ... done.
LDAP-UX was successfully configured.
2.3.5.3 Postinstallation steps for Existing Directory Server Installation mode
Perform the postinstallation configuration tasks documented in Section 2.5 (page 89), as needed.
54
Installing and configuring LDAP-UX Client Services for an HP server environment
2.3.6 Guided installation steps: Existing LDAP-UX Domain Installation mode
This section explains how to install LDAP-UX in an environment that has already been configured
for LDAP-UX, joining the local host into an existing LDAP-UX domain. In this mode, the guided
installation simply downloads the existing domain configuration (the LDAP-UX configuration profile)
and registers the host in the LDAP-UX domain. Section 2.3.6.1 (page 55) shows how to perform
the guided installation interactively, explaining step-by-step how to respond to each prompt for
user input. Section 2.3.6.2 (page 57) shows how to run a completely-automated (silent mode)
guided installation.
NOTE: This section assumes you are installing LDAP-UX on a host on which LDAP-UX is not already
installed. If you attempt to run autosetup on a host on which LDAP-UX (ldapclientd) is already
running, the procedure aborts. If the LDAP-UX is installed on the host but not running, the procedure
proceeds. However, if a previous LDAP-UX configuration profile is found on the system, the procedure
warns you that proceeding will overwrite the file and asks if you want to proceed.
You may proceed if your intention is to reconfigure LDAP-UX on the host. You could reconfigure
LDAP-UX for any of several reasons, such as:
•
You want the host to connect to a different directory server than the one the host was originally
configured to connect to.
•
The LDAP-UX configuration was corrupted (an error indicates a component is corrupted).
•
A directory server user inadvertently deleted the host entry from the directory server. This
removes the proxy user required to connect to the directory server; to correct this, rerun
autosetup to recreate the host entry and reestablish user proxies.
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client and the HP-UX system (where you are running autosetup) is
secured and not subject to network eavesdropping. One option to protect such communication
might be to use the ssh protocol when connecting to the HP-UX host being configured.
2.3.6.1 Interactively running Existing LDAP-UX Domain Installation mode
To interactively install LDAP-UX onto a host that is to join an existing LDAP-UX environment, follow
these steps. This example assumes that you preinstall a CA certificate, as described in step 2.
1.
Log in as root and run the autosetup command, as shown in the following example:
# /opt/ldapux/config/autosetup
2.
Install the domain CA certificate product from the depot created when the original directory
server instance was created. Securely copy the /tmp/ca-mydomain.example.com.depot
file to your local host and install the Domain CA product using the following command:
swinstall -s /tmp/ca-mydomain.example.com.depot \*
If you skip this step, autosetup will prompt you whether to trust the directory server.
3.
The autosetup script searches for a registered directory server in the local DNS domain but
does not find one, as indicated in the following example.
NOTE: The script searches for a registered server only if the directory server was not specified
with the -h option command-line option or LDAP_HOSTPORT environment variable. If a
registered directory server is found, autosetup uses that directory server automatically.
The script gives you the option of entering the host identification of the existing directory server
(along with two other options). In this example, the existing directory server is the one created
in Section 2.3.4 (page 46). The installer specifies its host name acct1053 (a directory server
already exists, so a new directory server instance is not created).
2.3 Guided installation (autosetup) for an HP directory server environment
55
Scanning DNS domain "west.hp.com" for any registered LDAP directory servers...
- No directory servers found.
Please enter the host name and port number of a directory server,
a Windows domain name, or press Return to create a new directory
server on this host: acct1053 Enter
NOTE: Unless you preinstall a CA or server certificate for the directory server, the autosetup
tool has no means of validating the identity of the remote directory server (acct1053). The
tool can download and permanently install the CA or server certificate for the server; however,
the server might be an impostor.
If the specified server was not created by the guided installation, you can obtain the CA or
server certificate directly from the server (in /etc/opt/ldapux) and preinstall it on your
host. For information about creating the certificate database files, see Section 2.4.6.4
(page 82).
If the CA certificate is not installed on your local host at this point of the guided installation,
autosetup warns you that it cannot validate the identity of the remote server and suggests
installing the CA certificate. You can abort so that you can install the CA certificate before
proceeding with the rest of the guided installation, or you can continue, trusting the CA
certificate that will be installed automatically by autosetup.
This example assumes the CA certificate has already been installed; therefore, you will not
see the warning and the prompt asking whether to abort or continue.
4.
The script then asks for the DN of the directory server user who can add the local host to the
directory server's LDAP-UX domain. This is any host administrator with such privileges (a
member of the DomainAdmins group). In this example, the DN for the user with such privileges
is uid=domadmin,ou=people,dc=calif,dc=acme,dc=com. The server's DNS domain
in this example is calif.acme.com; this will be the name of the LDAP-UX domain configured
by autosetup. Because the LDAP-UX domain has already been set up on the directory server,
LDAP-UX should not need to extend the server's schema. Instead, the credentials entered at
this prompt merely need the privilege to add information about the current HP-UX host to the
directory server.
Please enter the DN of a user that has sufficient privilege to add this host
to the "calif.acme.com" domain. Note also that if this is the first
time adding an HP-UX host to this directory server, LDAP-UX may
also need to extend the server's schema. Please enter the DN of an
Administrator with these privileges or press Return for the default value.
[uid=domadmin,ou=people,dc=calif,dc=acme,dc=com]: Enter
5.
Enter the password for the user identified in the preceding step (the entered password is not
visible):
Enter the password for the above user: [password not displayed] Enter
The installation now begins, followed by other related tasks; autosetup displays the progress
and results, as in the following example. Because an existing LDAP-UX configuration profile does
exist, autosetup downloads the existing profile from the directory server instead of creating a
new one. The profile and the associated LDAP-UX domain will be based on the existing directory
tree. In addition, autosetup provisions information about the local host into the existing directory
server.
*
*
*
*
*
56
Extending schemas ... done.
Downloading profile from DS ... done.
Configuring ldapux_client.conf ... done.
Provisioning LDAP-UX Client information into the Directory Server ... done.
Setting up proxy user ... done.
Installing and configuring LDAP-UX Client Services for an HP server environment
* Configuring "/etc/nsswitch.conf" and "/etc/pam.conf" to use ldap ... done.
* Starting ldapclientd daemon ... done.
* Starting ldapcconfd ... done.
LDAP-UX was successfully configured.
NOTE: For more information about the configuration files created or modified by autosetup,
see “Samples of LDAP-UX configuration files created or modified by autosetup” (page 410).
You can display details about the LDAP-UX Client Services configuration by using the
/opt/ldapux/config/display_profile_cache command. For more information about
the use of this command, see Section 9.2.4 (page 280).
2.3.6.2 Automating Existing LDAP-UX Domain Installation mode
For this mode of installation, you can run autosetup in silent mode and provide values for
parameters in the command line or with environment variables. You must preestablish trust with
the remote directory server by installing the CA certificate before running autosetup (for more
information, see Section 2.3.2.3.3 (page 39)). To perform this installation without user interaction,
you must specify the same command-line options or environment variables as required by the
automated Existing Directory Server Installation:
The bind DN (the DN of the directory server user who can add the local host to the directory
server's LDAP-UX domain): use either the -D option or the LDAP_BINDDN variable.
The password used with the bind DN: use either -j option or the LDAP_BINDCRED variable.
The host name of the directory server being joined: use either -h option or the LDAP_HOSTPORT
variable.
In the following example, these parameters are specified in the command line:
# ./autosetup -h acct1053 -D "uid=domadmin,ou=people,dc=calif,dc=acme,dc=com" -j /tmp/jfile -q
* Extending schemas ... done.
* Downloading profile from DS ... done.
* Configuring ldapux_client.conf ... done.
* Provisioning LDAP-UX Client information into the Directory Server ... done.
* Setting up proxy user ... done.
* Configuring "/etc/nsswitch.conf" and "/etc/pam.conf" to use ldap ... done.
* Starting ldapclientd daemon ... done.
* Starting ldapcconfd ... done.
LDAP-UX was successfully configured.
2.3.6.3 Postinstallation steps for Existing LDAP-UX Domain Installation mode
After completing an Existing LDAP-UX Domain mode guided installation, perform these steps:
•
If you installed LDAP-UX into an existing LDAP-UX B.04.xx environment, or into an LDAP-UX
B.05.xx environment that was configured by the customized installation (setup), or in any
LDAP-UX B.05.xx environment that was modified since being created, ensure that the
user/group and host management tools can identify the proper locations in the directory server
tree for creating new users, groups, and hosts. The tools expect the LDAP-UX configuration
profile to indicate the correct location for the host entries. For more information about assuring
the management tools properly interface with the configuration profile, see Section 9.3.5.6
(page 306) and Section 7.8.1 (page 235).
•
Perform the postinstallation configuration tasks documented in Section 2.5 (page 89), as
needed.
2.4 Customized installation (setup) for an HP directory server environment
The customized installation requires that you be familiar with the LDAP-UX and directory server
environment. This section describes how to perform this installation, tailoring the installation and
configuration to the specific needs of your organization and environment.
2.4 Customized installation (setup) for an HP directory server environment
57
2.4.1 Summary of customized installation and configuration steps
The following are the steps you take when custom installing and configuring an LDAP-UX Client
Services environment:
1.
2.
3.
4.
5.
6.
7.
8.
9.
58
Plan your installation (see Section 2.4.2 (page 59)).
Install LDAP-UX Client Services on each client system (see Section 2.4.3 (page 65)).
Install and configure an LDAP directory, if not already done (see Section 2.4.4 (page 65)).
If you want to enable SSL support with LDAP-UX, install and set up the security database files
on the LDAP-UX client system (see Section 2.4.6 (page 78)).
Migrate your name service data to the directory (see Section 2.5.1 (page 89)).
Run the setup program to configure LDAP-UX Client Services on a client system (see
Section 2.4.5 (page 67)). The setup program does the following for you:
•
Extends your RHDS/HPDS directory schema with the configuration profile schema, if not
already done.
•
Imports the LP printer schema into your HP directory server if you choose to start the LDAP
printer configurator.
•
Imports the NIS publickey schema into your HP directory if you choose to store the NIS-style
public keys of users and hosts in the LDAP directory.
•
Imports the automount schema into your HP directory server if you choose to store the
AutoFS maps in the LDAP directory.
•
Creates a startup file on the client. This enables each client to download the configuration
profile.
•
Creates a centrally-managed configuration profile in the LDAP directory server. This profile
defines how HP-UX clients should access the directory server and defines the data model
(schema) used to identify users, groups, and other OS services. This profile can be shared
across numerous clients and defines what is known as the “LDAP-UX domain”. The setup
program can download an existing configuration profile, create a new one, or define a
local-only profile.
•
Downloads the configuration profile from the directory to the client.
•
Starts the product daemon ldapclientd, if you choose to start it. Starting with LDAP-UX
Client B.03.20 or later, the client daemon must be started to obtain LDAP-UX functionality.
With LDAP-UX Client B.03.10 or previous releases, running the client daemon is optional.
To specify LDAP authentication and name service, modify the files /etc/pam.conf and
/etc/nsswitch.conf, respectively, on the client (see Section 2.4.5 (page 67)).
Optionally, configure the PAM Authorization Service Module (PAM_AUTHZ) to control access
rules defined in the /etc/opt/ldapux/pam_authz.policy policy file. In addition, verify
the user access rights of a subset of users in a large repository needing access, modifying the
/etc/opt/ldapux/pam_authz.policy and /etc/pam.conf files. For command syntax,
see the pam_authz(5) manpage; for more information about configuring this service, see
Section 7.4 (page 199).
Perform the relevant postinstallation tasks described in Section 2.5 (page 89). These include:
•
Importing name service data into your directory (see Section 2.5.1 (page 89))
•
Verifying each client is working properly (see Section 2.5.2 (page 91))
•
Enabling AutoFS support (see Section 2.5.3 (page 94))
•
Enabling offline credential caching for authentication when the directory server is not
available (see Section 2.5.4 (page 101))
•
Enabling integrated Compat Mode to control name services and user logins (see
Section 2.5.5 (page 102))
Installing and configuring LDAP-UX Client Services for an HP server environment
•
Control user access to the system, using any of several methods mentioned in Section 2.5.6
(page 104)
•
Configure subsequent client systems (see the shortcuts mentioned in Section 2.5.7
(page 110))
•
Downloading the profile periodically (see Section 2.5.8 (page 111))
•
Enabling the use of -r commands with PAM_LDAP (see Section 2.5.9 (page 112))
2.4.2 Planning for your customized installation and configuration
Before beginning your installation, you should plan how you will set up and verify your LDAP
directory and your LDAP-UX Client Services environment before putting them into production.
Consider the following questions. Record your decisions and other information that you will need
later in “Configuration worksheet” (page 403).
•
How many HP directory servers and replicas will you need?
Each client system binds to an LDAP directory server containing your user, group, and other
data. Multiple clients can bind to a single directory server or replica server. The answer
depends on your environment, the size and configuration of your directory, and how many
users and clients you have. Write your directory server host and TCP port number in
“Configuration worksheet” (page 403). For more information, see the white paper Preparing
Your LDAP Directory for HP-UX Integration at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
In addition, for more information about preparing an HP-UX Directory Server or Red Hat
Directory Server, see the appropriate Deployment Guide at the website mentioned previously.
You can add directory replicas to an existing LDAP-UX Client Services environment as described
under Section 7.5 (page 217). You can also review the LDAP-UX Integration Performance and
Tuning Guidelines, also located at the website mentioned previously.
•
Where will you get your name service data when migrating it to the directory?
You can get the data from your files in the /etc directory or, if you are using NIS, from the
same source files from which you create your NIS maps, or you can get the data from your
NIS maps themselves. Write this information in “Configuration worksheet” (page 403).
For information about how to import your information into the directory, see Section 2.5.1
(page 89). For information about the migration scripts, see Section 9.6 (page 383).
To add an individual user entry or modify an existing user entry in your directory, you may
use the ldapugadd or ldapugmod command or other directory administration tools such as
the ldapmodify command or the HP-UX Directory Server Console. For additional contributed
tools, see the LDAP-UX Integration Release Notes.
NOTE: You should keep a small subset of users in /etc/passwd, particularly the root login
. This enables 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. By default, LDAP-UX Client Services expects user and group data to use the object
classes and attributes specified by RFC 2307. By default, the migration scripts create and
populate a new subtree that conforms to RFC 2307. Figure 9 (page 62) shows a base DN of
ou=unix,o=hp.com. Write the base DN of your name service data in “Configuration
worksheet” (page 403).
2.4 Customized installation (setup) for an HP directory server environment
59
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. For more information, see
“LDAP-UX Client Services object classes” (page 406).
•
How will you put your user, group, and other data into your directory?
LDAP supports group membership defined in the X.500 syntax (using the member or
uniquemember attribute), while still supporting the RFC 2307 syntax (using the memberuid
attribute). This new group membership syntax increases LDAP-UX integration with LDAP and
other LDAP-based applications, and might reduce administration overhead eliminating the
need to manage the memberuid attribute. In addition, a new performance improvement 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
the LDAP-UX response time to applications. To improve performance further, the daemon reuses
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.
60
Installing and configuring LDAP-UX Client Services for an HP server environment
For information about how to import your information into the directory, see Section 2.5.1
(page 89). For information about the migration scripts, see Section 9.6 (page 383) .
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 enables local
management of the root user. 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 101).
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
good idea to have as few profiles as necessary. To see what is in a profile and help you
decide how many different profiles you need, look at the posixNamingProfile object class in
“LDAP-UX Client Services object classes” (page 406).
If you are familiar with NIS, one possibility 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 may put the profile anywhere you want, as long as
the client systems can read it. For example, you might put it near your user data, or you could
put it in a separate administrative area. To simplify access permission, put the profile in the
same directory as your user and group data. Clients must have access to both the profile and
2.4 Customized installation (setup) for an HP directory server environment
61
the user and group data. Figure 9 shows a configuration profile DN of
cn=profile1,ou=profiles,ou=unix,o=hp.com.
Figure 9 Example directory structure
o=hp.com
ou=unix
ou=people
user
data
ou=groups
group
data
ou=profiles
profile 1
ou=hosts
host
data
Write your configuration profile DN on the worksheet in “Configuration worksheet” (page 403).
•
By what method will client systems bind to the directory?
Clients can bind to the directory anonymously. This is the default and is simplest to administer.
If you need to prevent access to your data from anonymous users, or your directory does not
support anonymous access, you may use a proxy user. If you configure a proxy user, you
may also configure anonymous access to be attempted in the event the proxy user fails.
Write your client access method and proxy user DN, if needed, on the worksheet in
“Configuration worksheet” (page 403).
•
How will you increase the security level of the product to prevent an unwanted user from
logging in to the system through LDAP? What is the procedure to set up increased login
security?
The default is to allow all users stored in the LDAP directory to log in. To disallow specific
users to log in to a local system, you can configure the disable_uid_range flag in /etc/
opt/ldapux/ldapux_client.conf file, as described in Section 2.5.6.1 (page 105).
You may also use pam_authz or the deny_local option (in PAM_LDAP) to disable system
access for accounts defined in LDAP. For more information, about the PAM_AUTHZ service
module, see Section 7.4 (page 199) or the pam_authz(5) manpage. For information about the
deny_local option, see Section 2.5.6.2 (page 105).
•
What PAM authentication will you use? How will you set up the PAM configuration file /etc/
pam.conf? What other authentication do you want to use and in what order? Do you want
to use the Pam Authorization Service module (PAM_AUTHZ) for user access control?
PAM provides authentication services. You can configure PAM to use LDAP, Kerberos, or other
traditional UNIX locations (for example files or NIS) as controlled by NSS. For more information
about PAM, see the pam(3) and pam.conf(4) manpages, and the Managing Systems and
Workgroups: A Guide for HP-UX System Administrators document at the following location:
www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
Sample PAM configuration files and details about their structure are provided in “Sample
PAM configuration (pam.conf) files ” (page 420).
HP recommends that you use HP-UX file-based authentication first, followed by LDAP or other
authentication. The /etc/pam.ldap file is an example of this type of configuration (see the
sample file in Section D.1 (page 421)). With this configuration, PAM uses traditional
authentication first, searching /etc/passwd when any user logs in, then attempts to
62
Installing and configuring LDAP-UX Client Services for an HP server environment
authenticate to the directory if the user is not in /etc/passwd. If you have a few users in
/etc/passwd, in particular the root user, and if the directory is unavailable, you can still
log in to the client as a user in /etc/passwd.
•
Do you want to use TLS (Transport Layer Security) or SSL for secure communication between
clients and the directory server?
LDAP-UX supports SSL or TLS with password as the credential, using either simple bind or
DIGEST-MD5 authentication to ensure confidentiality and data integrity between clients and
servers. startTLS is a new extension operation of TLS protocol. You can use the StartTLS
operation to set the TLS secure connection over a regular (unencrypted) 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, see Section 2.4.6 (page 78).
•
What authentication method will you use when you choose to enable TLS?
You have a choice between SIMPLE (the default), or SASL/GSSAPI, or SASL/DIGEST-MD5.
SASL/GSSAPI is only supported for LDAP-UX used with Windows ADS.
For an overview of these authentication methods, including their strengths and weaknesses,
see Section 2.4.6.1 (page 79).
•
What authentication method will you use if you choose to enable SSL?
You have a choice between SIMPLE (the default), or SASL/GSSAPI, or SASL/DIGEST-MD5.
SASL/GSSAPI is only supported for LDAP-UX used with Windows ADS.
•
What authentication method will you use if you choose not to enable SSL and TLS?
You have a choice between SIMPLE (the default), or SASL/GSSAPI, or SASL/DIGEST-MD5.
SASL/ DIGEST-MD5 improves security, preventing snooping over the network during
authentication. SASL/GSSAPI is only supported for LDAP-UX used with Windows ADS.
Using the DIGEST-MD5 authentication might require that the password be stored in clear text
in the LDAP directory server.
•
Do you want to import the LDAP printer schema (if you choose to start the printer configurator)?
LDAP-UX Client Services B.03.20 or later provides the integration with the LDAP printer
configurator to simplify the LP printer management by updating LP printer configuration
automatically on your HP-UX system. A new printer schema, which is based on RFC 3712, is
required to start the services.
IMPORTANT: If you attempt to use this new feature, in the ldapclientd.conf file, the
start configuration parameter of the printer services section must be set to yes. If the start
option is enabled, the printer configurator will start when ldapclientd is initialized. By
default, the start parameter is enabled.
•
Do you want to import the NIS publickey schema into your LDAP directory if you choose to
store and manage NIS publickeys in the LDAP directory.
LDAP-UX Client Services supports discovery and management of NIS publickeys in an LDAP
directory. Both public and private (secret) keys used by the SecureRPC API can be stored in
user and host entries in an LDAP directory server, using the nisKeyObject object class.
•
Do you want to import the automount schema into your LDAP directory server if you choose
to store and manage automount maps in the LDAP directory?
LDAP-UX Client Services supports the automount service under the AutoFS subsystem. This new
feature enables you to store or retrieve automount maps in/from an LDAP directory. LDAP-UX
Client Services supports the new automount schema based on RFC 2307-bis. The nisObject
automount schema may also be used if configured through attribute mappings.
For the detailed information about AutoFS with LDAP support, see Section 2.5.3 (page 94).
2.4 Customized installation (setup) for an HP directory server environment
63
•
What name services will you use? How will you set up /etc/nsswitch.conf? In 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. For an example nsswitch.conf file using files and LDAP, see
/etc/nsswitch.ldap. For information on NSS, see the switch(4) manpage and the
"Configuring the Name Service Switch" chapter in NFS Services Administrator's Guide,
available at the following location:
http://www.hp.com/go/hpux-core-docs (Click HP-UX 11i v3).
HP recommends that you use files first, followed by LDAP for passwd, group, and other
supported name services. With this configuration, NSS will first search files, and if the name
service data is not in the respective files, then search the directory. The /etc/nsswitch.ldap
file is an example of this configuration.
•
Do you need to configure 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.policy
and /etc/pam.conf files to implement this feature?
The PAM_AUTHZ service module for PAM provides functionality that enables the administrator
to control who can log in to the system. These modules are located at /usr/lib/security/
libpam_authz.1 on a PA-RISC machine and at libpam_authz.so.1 on an HP Integrity
(IA64) server. The PAM_AUTHZ module has been created to provide access control similar
to the netgroup filtering feature that is performed by NIS. Starting with LDAP-UX Client Services
B.04.00, PAM_AUTHZ has been enhanced to enable system administrators to configure and
customize their local access rules in a local policy file, /etc/opt/ldapux/
pam_authz.policy. The PAM_AUTHZ module uses these access control rules defined in
the local policy file to control the login authorization. PAM_AUTHZ is intended to be used
when NIS is not used, such as when the PAM_LDAP or PAM_KERBEROS authentication modules
are used. Because PAM_AUTHZ does not 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
provides 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 log
in to the system.
For detailed information on this feature and how to configure the /etc/opt/ldapux/
pam_authz.policy file, see Section 7.4 (page 199) or the pam_authz(5) manpage.
•
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 secure shell
(ssh), r-commands (rlogin, rcp, and so forth) with rhost enabled where authentication is
not performed by 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 Section 7.4.10 (page 210).
•
How will you communicate with your user community about the change to LDAP?
For the most part, your user community should be unaffected by the directory. Most HP-UX
commands will work as always.
See the Release Notes for any other limitations and tell your users how they can work around
them.
64
Installing and configuring LDAP-UX Client Services for an HP server environment
2.4.3 Installing LDAP-UX Client Services on a client
Use swinstall to install the LDAP-UX Client Services software, the NativeLdapClient subproduct,
on a client system. For more information about the command, see the swinstall(1M) manpage. In
addition, see the LDAP-UX Integration Release Notes for any last-minute changes to this procedure.
You do not need to reboot your system after installing the product.
NOTE: Starting with LDAP-UX Client Services B.03.20 or later, system reboot is not required after
installing the product.
NOTE: For the HP 9000 and HP Integrity server client systems, you might need to install required
patches. For the detailed information about the required patches, see LDAP-UX Integration Release
Notes at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
2.4.4 Configuring your HP directory server directory
This section describes how to configure your directory to work with LDAP-UX Client Services.
Examples are given for the HP-UX Directory Server. For information about supported directories,
see the LDAP-UX Integration Release Notes . If you have a different directory, see the documentation
for your directory for more information about how to configure it.
For more information, see Preparing Your LDAP Directory for HP-UX Integration at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
1.
Install the POSIX schema (RFC 2307) into your directory.
With most directory servers, the POSIX schema is already installed. However, if you need to
install this schema, you can use the /opt/ldapux/bin/ldapschema tool to install the
/etc/opt/ldapux/schema/rfc2307.xml schema file.
For information on the POSIX schema (RFC 2307), see:
http://www.ietf.org/rfc.html
RFC 2307 consists of object classes such as: posixAccount, posixGroup, shadowAccount
(deprecated), etc. posixAccount represents a user entry from /etc/passwd. posixGroup
represents a group entry from /etc/group.
2.
Restrict write access to certain passwd (posixAccount) attributes of the POSIX schema.
CAUTION: Make sure you restrict access to the attributes listed in the following paragraph.
Allowing users to change them could be a security risk
Grant write access of the uidnumber, gidnumber, homedirectory, and uid attributes
only to directory administrators; disallow write access by all other users. You might want to
restrict write access to other attributes in the passwd (posixAccount) entry as well.
With HP-UX Directory Server, you may use the Directory Server Console or ldapmodify to
set up ACIs so ordinary users cannot change these attributes in their passwd entry in the
directory.
The following access control instruction is by default at the top of the directory tree for an
HP-UX Directory Server (version 8.1). This ACI allows a user to change any attribute in their
passwd entry:
aci: (targetattr = "*") (version 3.0; acl "Allow self entry modification";
allow (write)userdn = "ldap:///self";)
You could modify this example ACI to the following, which prevents ordinary users from
changing their uidnumber, gidnumber, homedirectory, and uid attributes:
2.4 Customized installation (setup) for an HP directory server environment
65
aci: (targetattr != "uidnumber || gidnumber || homedirectory || uid") (version
3.0; acl "Allow self entry modification, except for important POSIX attributes";
allow (write)userdn = "ldap:///self";)
You might have other attributes you need to protect as well.
To change an ACI with the Directory Server Console, select the Directory tab, select your
directory suffix in the left-hand panel, then select the Object→Set Access Permissions menu
item. In the dialog box, select the "Allow self entry modification" ACI and click OK. Use the
Set Access Permissions dialog box to modify the ACI. For more information about changing
an ACI with the Directory Server Console, see the HP-UX Directory Server administrator guide.
3.
Restrict write access to certain group (posixGroup) attributes of the POSIX schema.
Grant write access of the cn, memberuid, gidnumber, and userPassword attributes only to
directory administrators; disallow write access by all other users.
With the HP-UX Directory Server, you may use the Directory Server Console or ldapmodify
to set up access control lists (ACL) so ordinary users cannot change these attributes in the
posixGroup entry in the directory. For example, the following ACI, placed in the directory at
ou=groups,ou=unix,o=hp.com, allows only the directory administrator to modify entries
below ou=groups,ou=unix,o=hp.com:
aci: (targetattr = "*")(version 3.0;acl "Disallow modification of group
entries"; deny (write) (groupdn != "ldap:///ou=Directory Administrators,
o=hp.com");)
4.
Grant read access of all attributes of the POSIX schema.
Ensure all users have read access to the POSIX attributes.
When using PAM_LDAP as your authentication method, users do not need read access to the
userPassword attribute since the authentication is handled by the directory itself. Therefore,
for better security, you can remove read access to userPassword from ordinary users.
5.
6.
Configure anonymous access, if needed. If you do not configure a proxy user, then the attributes
of your name service data must be readable anonymously.
Create a proxy user in the directory, if needed.
To create a proxy user with the HP-UX Directory Server, go to the directory server's main
Console, select the Users and Groups tab, and then click on the Create button. For example,
you might create a user uid=proxyuser,ou=Special Users,o=hp.com.
7.
Set access permissions for the proxy user, if configured.
Give read permission for the POSIX account attributes to the proxy user created previously.
With HP-UX Directory Server, for example, the following ACI gives a proxy user permission
to compare, read, and search all POSIX account attributes except the userPassword attribute:
aci: (target="ldap:///o=hp.com")(targetattr!="userpassword")
version 3.0; acl "Proxy userpassword read rights";
allow (compare,read,search)
userdn = "ldap:///uid=proxyuser,ou=Special Users,o=hp.com";)
8.
The default ACI of Netscape Directory Server 6.11 allows a user to change his own common
attributes. But, for Netscape Directory Server 6.21 or later, you must set an ACI that gives a
user permission to change his own common attributes. By default, the Netscape Directory
Server 6.21 or later provides the following ACI named Enable self write for common
attributes that gives a user permission to change his own common attributes:
aci: (targetattr = "carLicense ||description ||displayName
||facsimileTelephoneNumber ||homePhone ||homePostalAddress ||initials
||jpegPhoto ||labeledURL ||mail ||mobile ||pager ||photo ||postOfficeBox
||postalAddress ||postalCode ||preferredDeliveryMethod ||preferredLanguage
||registeredAddress ||roomNumber ||secretary ||seeAlso ||st ||street
||telephoneNumber ||telexNumber ||title ||userCertificate ||userPassword
||userSMIMECertificate ||x500UniqueIdentifier")
(version 3.0; acl "Enable self write for common attributes"; allow (write)
(userdn = "ldap:///self"))
66
Installing and configuring LDAP-UX Client Services for an HP server environment
You can modify the default ACI and give appropriate access rights to change your own
common attributes.
9.
Index important attributes for better performance of the directory server.
Since many of your directory requests will be for the following attributes, you should index
these to improve performance. If you do not index them, your directory might search sequentially
causing a performance bottleneck. As a rule of thumb, databases containing more than 100
entries should be indexed by their key attributes.
The following attributes are recommended for indexing:
•
cn
•
objectclass
•
memberuid
•
uidnumber
•
gidnumber
•
uid
•
ipserviceport
•
iphostnumber
To index these entries with HP-UX Directory Server, go to the Directory Server Console's
Configuration tab, then the Indexes tab, and click on the Add Attributes button.
10. Determine if you need to support enumeration requests. If you do, increase the Look-Through
limit and the Size limit in the directory server.
Enumeration requests are directory queries that request all of a database, for example all
users or all groups. Enumeration requests of large directory databases could reduce network
and server performance. With large HPDS/RHDS directories and default configurations,
enumerations might fail or provide incomplete data, but the default configuration also might
prevent performance problems from enumerations.
If you need to support enumerations with large directory databases, increase the listed
parameters as described in Preparing Your LDAP Directory for LDAP-UX Integration available
at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
In HP-UX Directory Server, the Look-through limit specifies the maximum number of directory
entries to examine before aborting the search operation. The Size limit determines the maximum
number of entries to return to any query before aborting.
For information on these parameters and how to change them, see the HP-UX Directory Server
administrator guide. In addition, see Section 7.12.1.1 (page 247).
11. If you want to enable SSL support with LDAP-UX, you must turn on SSL in your directory server.
For information about configuring SSL (or TLS), see Section 2.4.6 (page 78). For detailed
information on how to set up and configure your directory server to enable SSL communication
over LDAP, see the HP-UX Directory Server administrator guide at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX Directory Server.
2.4.5 Configuring LDAP-UX Client Services for an HP directory server environment
The following list summarizes how to configure LDAP-UX Client Services with HP-UX Directory
Server. For more information about performing a default configuration, see Section 2.4.5.1
2.4 Customized installation (setup) for an HP directory server environment
67
(page 69). For more information about performing a custom configuration, see Section 2.4.5.2
(page 72) for more information.
NOTE: The setup program has only been certified with HP-UX Directory Server version 8.1,
Red Hat Directory Server 8.0, Windows Server 2003 R2 Active Directory Server, and Windows
2008 Active Directory Server. For more information, see the LDAP-UX Integration B.05.00 Release
Notes.
NOTE: The LDAP-UX Client Services supports storage of automount maps and NIS publickeys on
Red Hat Directory Server 8.0 and HP-UX Directory Server 8.1. For more information, see the
LDAP-UX Integration B.05.00 Release Notes .
•
Run the setup program. The setup program provides the following assistance:
◦
Extends your directory server schema with the configuration profile schema, if not already
done
NOTE: To use a local-only profile, run the setup program using the -l option . Use
the local-only profile for small deployments, testing purposes, and for environments where
administrators lack server administrative privileges.
68
◦
Imports the LDAP printer schema into your directory server if you choose to start the LDAP
printer configurator
◦
Imports the NIS publickey schema into your directory server if you choose to store the
public keys of users and hosts in an LDAP directory
◦
Imports the new automount schema into your directory server if you choose to store the
AutoFS maps in an LDAP directory
◦
Provides the option to enable SSL for secure communication between LDAP clients and
Directory servers
◦
Optionally configures SASL DIGEST-MD5 authentication
◦
Creates a configuration profile entry in your directory server from information you provide
◦
Updates the local client's startup file (/etc/opt/ldapux/ldapux_client.conf)
with your directory and configuration profile location
◦
Downloads the configuration profile from the directory to your local client system
◦
Configures a proxy user for the client, if needed
◦
Starts the client daemon if you choose to start it
Installing and configuring LDAP-UX Client Services for an HP server environment
IMPORTANT: Starting with LDAP-UX Client Services B.03.20, the client daemon, /opt/
ldapux/bin/ldapclientd, must be running for LDAP-UX functions to work. With LDAP-UX
Client Services B.03.10 or previous releases, running the client daemon, ldapclientd, is
optional.
NOTE: The LDAP printer configurator can support any directory servers that support the
LDAP printer schema based on RFC 3712.
However, the LDAP-UX Client Services only supports automatically importing the LDAP printer
schema into the directory server by running the setup program.
If your directory server does not support the LDAP printer schema, you might experience
problems when importing the printer schema.
•
Configure PAM by modifying the PAM configuration file /etc/pam.conf. See /etc/
pam.ldap for a sample (a sample of this file is provided in Section D.1 (page 421)).
For more information about PAM, see the pam(3) and pam.conf(4) manpages, and the
Managing Systems and Workgroups: A Guide for HP-UX System Administrators document at
the following location:
http://www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
Sample PAM configuration files and details about their structure are provided in “Sample
PAM configuration (pam.conf) files ” (page 420).
•
Configure NSS by modifying the file /etc/nsswitch.conf. See /etc/nsswitch.ldap
for a sample.
•
Optionally modify the disable_uid_range flag in the /etc/opt/ldapux/
ldapux_client.conf file to disable logins to the local system from specific users, as
described in Section 2.5.6.1 (page 105).
•
Optionally configure the authorization of one or more subgroups from a large repository such
as an LDAP directory server. For the detailed information on how to set up the policy file,
/etc/opt/ldapux/pam_authz.policy, see Section 7.4.4 (page 202).
After you configure your directory and the first client system, configuring additional client systems
is simpler. For more information, see Section 2.5.7 (page 110).
2.4.5.1 Quick configuration
You can quickly configure a HP-UX Directory Server/Rat Hat Directory Server directory and the
first client by letting most of the configuration parameters take default values as follows. For a
custom configuration, see Section 2.4.5.2 (page 72).
The steps described in this section assume that you don't use SSL or TLS support with LDAP-UX. If
you want to enable SSL support, see Section 2.4.5.2 (page 72).
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client and the HP-UX system (where you are running setup) is secured
and not subject to network eavesdropping. One option to protect such communication might be
to use the ssh protocol when connecting to the HP-UX host being configured.
1.
Log in as root and run the setup program:
cd /opt/ldapux/config
./setup
2.4 Customized installation (setup) for an HP directory server environment
69
NOTE: To use a local-only profile, run the setup program using the -l option . Use the
local-only profile for small deployments, testing purposes, and for environments where
administrators lack server administrative privileges.
The setup program asks you a series of questions and usually provides default answers.
Press Enter to accept the default, or change the value and press Enter. At any point during
setup, enter Control-b to back up or Control-c to exit setup.
2.
3.
4.
5.
Choose the directory server as your LDAP directory server (option 1).
Enter either the host name or IP address of the directory server where your profile exists, or
where you want to create a new profile from “Configuration worksheet” (page 403).
Enter the port number of the previously specified directory server that you want to store the
profile from “Configuration worksheet” (page 403). The default port number is 389.
If the profile schema has already been imported, or if you invoked setup with the -l option
to use a local-only profile, setup skips to the next step.
Otherwise, you are asked whether you want to import the profile schema with LDAP-UX Client
Services object class DUAConfigProfile. Enter yes to import the profile schema into the
LDAP directory server. This must be done once (the schema is shared with
subsequently-configured client systems). Enter no if you do not want to import the profile
schema into the LDAP directory server. The setup program skips to the next step if you enter
no.
NOTE: The LDAP-UX Integration product supports a local-only profile for testing, small LDAP
deployments, or operating in environments where the HP-UX administrators lack directory
server administrative privileges. The local-only configuration profile is intended not to push
back to the directory server.
See “LDAP-UX Client Services object classes” (page 406) for a detailed description of the
DUAConfigProfile object class.
6.
7.
8.
If the LDAP printer schema has already been extended, setup skips this steps. Otherwise,
enter yes to extend the LP printer schema if you choose to start the printer configurator. The
LDAP printer configurator is a feature that simplifies the LP printer management by refreshing
LP printer configurations on your client system. A new printer schema, which is based on RFC
3712, is required to start the services.
If the NIS publickey schema has already extended, setup skips this step. Otherwise, enter
yes to extend the publickey schema if you choose to store the public keys of users and hosts
in the LDAP directory. A publickey schema, which is based on RFC 2307-bis is required to
migrate the publickeys in the NIS credential table entries on the NIS server to the LDAP
directory.
If the new automount schema has already been imported, setup skips to the next step. (The
HP-UX Directory Server includes the new automount schema by default.)
Otherwise, you are asked whether you want to install the new automount schema which is
based on RFC 2307-bis. Enter yes if you want to import the new automount schema into the
LDAP directory server. Enter no if you do not want to import new automount schema into the
LDAP directory server.
9.
70
If you are creating a new profile, add all parent entries of the profile DN to the directory (if
any). If you attempt to create a new profile and any parent entries of the profile do not already
exist in the directory, setup will fail. For example, if your profile will be
cn=profile1,ou=profiles,o=hp,com, then ou=profiles,o=hp.com must exist in
the directory or setup will fail.
Installing and configuring LDAP-UX Client Services for an HP server environment
10. Next enter either the DN of a new profile, or the DN of an existing profile you want to use,
from “Configuration worksheet” (page 403).
To display all the profiles in the directory, use a command like the following:
ldapsearch -b o=hp.com objectclass=DUAConfigProfile dn
If you are using an existing profile, setup configures your client, downloads the profile, and
exits. In this case, continue with the next step.
11. If you are creating a new profile, enter the DN and password of the directory user who can
create a new profile from “Configuration worksheet” (page 403).
12. Next, it will prompt you for the following information:
Select authentication method for users to bind/authenticate to
the server
1. SIMPLE
2. SASL DIGEST-MD5
To accept the default shown in brackets, press the Return key.
Authentication method: [1]:
Press Enter if you choose to accept SIMPLE authentication method, type 2 if you choose SASL
DIGEST-MD5 authentication method for the following prompt:
Authentication method: [1]:
For an overview of the various authentication methods you can configure with LDAP-UX Client
Services, including their strengths and weaknesses, see Section 2.4.6.1 (page 79).
13. Next enter the host name and port number of the directory where your name service data is,
from “Configuration worksheet” (page 403). For high availability, each LDAP-UX client can
look for name service data in up to three different directory hosts. You can enter up to three
hosts, to be searched in order.
14. Enter the base DN where clients should search for name service data from “Configuration
worksheet” (page 403).
15. You can quickly configure a directory server and the first client by accepting the remaining
default configuration parameters when prompted.
If you want to use the SASL DIGEST-MD5 authentication method, you must configure a proxy
user with its credential level.
Using the SASL DIGEST-MD5 authentication, the password must be stored in the clear text in
the LDAP directory.
Table 6 shows the configuration parameters and the default values they are configured with.
Table 6 Configuration parameter default values
Parameter
Default value
Type of client binding
Anonymous
Bind time limit
5 seconds
Search time limit
no limit
Use of referrals
Yes
Profile TTL (Time To Live)
0 - infinite
Use standard RFC 2307 object class attributes for supported services
Yes
Use default search descriptions for supported services
Yes
Authentication method
Simple
To change any of these default values, see Section 2.4.5.2 (page 72).
2.4 Customized installation (setup) for an HP directory server environment
71
16. After entering all the configuration information, setup extends the schema, creates a new
profile, and configures the client to use the directory.
17. Configure PAM.
Save a copy of the file /etc/pam.conf and edit the original to specify LDAP authentication
and other authentication methods you want to use. See /etc/pam.ldap for a sample (see
also Section D.1 (page 421)). You could just copy /etc/pam.ldap to /etc/pam.conf. For
more information about PAM, see the pam(3) and pam.conf(4) manpages. In addition, see
the document Managing Systems and Workgroups: A Guide for HP-UX System Administrators
at the following location:
www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
NOTE: The options defined in /etc/pam.conf specify the default for users. If you want
to apply different PAM rules to specific users, you may also configure the pam_user.conf
file accordingly. For more information, see the pam_user.conf(4) manpage. For an example
of a pam_user.conf file, see Section 2.5.6.3 (page 108).
18. Configure NSS.
Save a copy of the file /etc/nsswitch.conf and edit the original to specify the LDAP
name service and other name services you want to use. See /etc/nsswitch.ldap for a
sample. You could just copy /etc/nsswitch.ldap to /etc/nsswitch.conf. See
nsswitch.conf(4) for more information.
19. Optionally, configure the Pam Authorization Service module (PAM_AUTHZ).
LDAP-UX Client Services provides a sample configuration file, /etc/opt/ldapux/
pam_authz.conf.template. This sample file shows you how to configure the policy file
to work with PAM_AUTHZ. You can copy this sample file and edit it using the correct syntax
to specify the access rules you want to authorize or exclude from authorization. For more
detailed information on how to configure the policy file. See Section 7.4 (page 199).
The sample /etc/pam.conf file in the pam.conf(4) manpage will help show you how to
configure the /etc/pam.conf file to work with PAM_AUTHZ. For more detailed information
about PAM_AUTHZ, see the pam_authz(5) manpage.
20. Optionally configure the disable_uid_range flag, as described in Section 2.5.6.1
(page 105).
You may also use pam_authz or the deny_local option (in PAM_LDAP) to disable system
access for accounts defined in LDAP. For more information, about the pam_authz service
module, see Section 7.4 (page 199) or the pam_authz(5) manpage. For information about the
deny_local option, see Section 2.5.6.2 (page 105).
21. Section 2.5.2 (page 91).
22. Configure subsequent clients by running setup on those clients and specifying an existing
configuration profile. Or for a simpler process see Section 2.5.7 (page 110).
2.4.5.2 Custom configuration
Running the setup program for a quick configuration, as described previously, configures your
client using default values where possible. If you would like to customize these parameters, proceed
as follows.
If you want to use SSL or TLS, you must perform the following tasks before you run the custom
configuration. For more information about configuring SSL or TLS support, see Section 2.4.6
(page 78).
•
72
Ensure that you have installed the certificate database files, cert8.db and key3.db, on
your client system.
Installing and configuring LDAP-UX Client Services for an HP server environment
•
If you choose to use TLS, set the enable_startTLS parameter to 1 in the /etc/opt/
ldapux/lldapux_client.conf file to enable TLS. To use SSL, set enable_startTLS
to 0 to disable TLS. By default, TLS is disabled.
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, you should make
sure that the connection between your client and the HP-UX system (where you are running setup)
is secured and not subject to network eavesdropping. One option to protect such communication
might be to use the ssh protocol when connecting to the HP-UX host being configured.
1.
Perform the steps described in Section 2.4.5.1 (page 69).
However, after step 11, you are asked whether you want to use SSL or not if the value of the
enable_startTLS parameter is 0 (disabled) or undefined. Enter yes to the following
question if you want to use SSL for the secure communication between LDAP clients and the
HP-UX Directory Server or Red Hat Directory Server. Enter no to the following question if you
don't want to use SSL. Skip to step 2.
Do you want to use SSL (y/n)?
Otherwise, if the value of the enable_startTLS parameter is 1 (enabled), you are asked
whether you want to use TLS or not. Enter yes to the following question if you want to use TLS
for the secure communication between LDAP clients and the HP-UX Directory Server or Red
Hat Directory Server. Enter no to the following question if you don't want to use TLS. Skip to
step 3.
Do you want to use TLS (y/n)?
2.
Next, it will prompt you for selecting the authentication method for users to bind/authenticate
to the server.
You have a choice between SIMPLE (the default), SASL/GSSAPI, or SASL/DIGEST-MD5 if you
choose to not enable SSL. However, you have a choice between SIMPLE with SSL (the default),
or SASL/GSSAPI or SASL/DIGEST-MD5 with SSL if you choose to enable SSL.
LDAP-UX supports the SASL/GSSAPI or SASL/DIGEST-MD5 authentication method.
SASL/GSSAPI is only supported for LDAP-UX used with Windows ADS.
If you select SASL DIGEST-MD5, two additional prompts will appear. The first will prompt you
for a user mapping (UID, DN, or Other). The second will prompt you for a single realm to use
when retrieving user authentication information. If no realm is specified, user information will
be retrieved from the first realm the directory server offers.
For an overview of the various authentication methods you can configure with LDAP-UX Client
Services, including their strengths and weaknesses, see Section 2.4.6.1 (page 79).
3.
Specify the host name and optional port number where your directory is running. If you choose
to use TLS, the default directory port number is 389. If you choose to use SSL, the default
directory port number is 636.
For high availability, each LDAP-UX client can look for user and group information in up to
three different directory servers. You are able to specify up to three directory hosts, to be
searched in order.
4.
5.
6.
Reply no when asked if you want to accept the remaining default configuration parameters.
Select the client binding you want from “Configuration worksheet” (page 403). This determines
the identity that client systems use when binding to the directory to search for user and group
information.
If you configured a proxy user, enter the DN and password of your proxy user, from
“Configuration worksheet” (page 403).
If you want to use the SASL/DIGEST-MD5 authentication method, you must configure a proxy
user with its credential level.
2.4 Customized installation (setup) for an HP directory server environment
73
Using the SASL/DIGEST-MD5 authentication, the password must be stored in the clear text in
the LDAP directory.
7.
8.
Enter the maximum time in seconds the client should wait for directory searches before
aborting. Enter 0 for no time limit.
Enter whether or not you want directory searches to follow referrals. Referrals are a redirection
mechanism supported by the LDAP protocol. Please see your directory manuals for more
information on referrals.
NOTE: If you want your directory searches to follow referrals, you must allow anonymous
access into your directories.
9.
Enter the Profile TTL (Time To Live) value. This value defines the time interval between automatic
downloads (refreshes) of new configuration profiles from the directory. Automatic refreshing
ensures that the client is always configured using the newest configuration profile.
If you want to disable automatic refresh or manually control when the refresh occurs, enter a
value of 0. Section 2.5.8 (page 111).
10. In this step, the setup program initiates a dialog where you can remap the standard object
class attributes to alternate attributes. You might want to do this if the attributes in your directory
do not conform to the object classes defined in RFC 2307.
You can remap the attributes for any of the supported services. For a list of supported services,
see “LDAP-UX Client Services object classes” (page 406).
NOTE: Make sure that the attribute names are entered correctly to avoid unpredictable
results later.
For a description of the standard object classes and attributes, see RFC 2307 at:
http://www.ietf.org/rfc/rfc2307.txt.
The setup program displays the following dialog:
LDAP-UX Client Services supports the following services:
1.Password
7.Networks
2.Shadow passwd
8.Hosts
3.Group
9.Services
4.PAM (Pluggable Authentication Module)10.Printers
5.RPC
11.Automount
6 Protocols
12.Netgroup
Each services uses a standard object class (defined by RFC 2307)
You can remap any of these attributes to alternate attributes.
Do you want to remap any of the standard RFC 2307 attributes?
If you want to remap attributes for any of the supported services, enter yes; for more
information about how to remap attributes, see Section 2.4.5.3 (page 75).
Otherwise, if you do not want to remap attributes for any of the supported services, then enter
no to this prompt to continue to the next step.
11. In this step, the setup program initiates a dialog where you can create a custom search
descriptor. A custom search descriptor enables you to specify a different search location or
filter for retrieving entries for services supported by LDAP-UX Client. Each name service can
have up to three different search descriptors. A custom search descriptor consists of three
parts: a search base DN, scope, and filter. The client uses the search descriptors in order until
it finds what it is looking for.
74
Installing and configuring LDAP-UX Client Services for an HP server environment
NOTE: If your search filters overlap, enumeration requests will result in duplicate entries
being returned. For example, if one search filter searched a subset of your organization and
a second search filter searched your entire organization, an enumeration request would return
duplicate entries.
For more information, see Section 7.12.1 (page 247).
To begin the process to create custom search descriptors, setup will prompt you for the
following information:
LDAP-UX Client Services supports the following services:
1.Password
7.Networks
2.Shadow passwd
8.Hosts
3.Group
9.Services
4.PAM (Pluggable Authentication Module)10.Printers
5.RPC
11.Automount
6.Protocols
12.Netgroup
You can create up to three custom search descriptors for each name
service to search different locations in the directory for user
and group information.
Do you want to create custom search descriptors? [No]:
Enter yes if you want to create custom search descriptors for any of the supported services.
Then enter the number of the service for which you want to create a custom search descriptor.
If, you do not want to create custom search descriptors, enter no to this prompt to continue
to the next step.
Creating the nisObject search filter
LDAP-UX Client Services uses the automount search filter for the automount service as default.
If you want to create the nisObject search filter for the automount service to search a different
location in the directory, use the following steps:
1.
Enter yes for the following question and press Enter:
Do you want to create custom search descriptors? [No]: yes Enter
2.
Next, a screen displays the following information:
To accept the default shown in brackets, press the Return key.
search base [dc=cup,dc=hp,dc=com]:
search scope (base, one, sub) [sub]
Search filter [(objectclass=automount)]
If you want to create the nisObject search filter for the automount service, then enter
(objectclass=nisObject) for the following prompt and press Enter; otherwise press
Enter to accept the default search filter, objectclass=automount:
Search filter [(objectclass=automount)]: Enter (objectclass=nisObject)
12. You are asked whether or not you want to start the client daemon. For LDAP-UX Client B.03.20
or later versions, the client daemon must be started for LDAP-UX functions to work. With
LDAP-UX Client B.03.10 and previous releases, the client daemon is optional, and should be
turned on in order to provide better prformance (response time) and for the X.500 group
membership to work.
2.4.5.3 Remapping attributes for services
This section describes detailed procedures on how to perform attribute mappings for automount,
dynamic group and X.500 group membership services.
2.4 Customized installation (setup) for an HP directory server environment
75
Attribute mappings for automount service
By default, LDAP-UX Client Services uses the RFC 2307-bis automount schema. The nisObject
automount schema may also be used if configured with attribute mappings.
Use the following steps if you want to remap the automount attributes to the nisObject automount
attributes:
1.
Enter yes for the following question:
Do you want to remap any of the standard RFC 2307 attributes? [yes]:
yes Enter
2.
If you want to select the automount service, then enter 11 for the following question: Enter
Specify the service you want to map? [0]: 11 Enter
3.
Next, a screen displays the following information:
Current Automount attribute names:
1.automountMapName ->[automountMapname]
2.automountKey -> [automountKey]
3.automountInformation -> [automountInformation]
Specify the attribute you want to map. [0]:
Enter 1 for the following question:
Specify the attribute you want to map. [0]:1 Enter
4.
Next, enter the attribute nisMapName that you want to map to the automountMapName
attribute for the following question:
automountMapName -> nisMapName Enter
5.
Next, a screen displays the following information:
Current Automount attribute names:
1.automountMapName ->[nisMapname]
2.automountKey -> [automountKey]
3.automountInformation -> [automountInformation]
Specify the attribute you want to map. [0]:
If you want to specify the attribute to map to the automountKey attribute, then enter 2 for
the following question:
Specify the attribute you want to map. [0]: 2 Enter
6.
Next, enter the attribute cn you want to map to the automountKey attribute and press Enter:
automountKey -> cn Enter
7.
Next, a screen displays the following information:
Current Automount attribute names:
1.automountMapName ->[nisMapname]
2.automountKey -> [cn]
3.automountInformation -> [automountInformation]
Specify the attribute you want to map. [0]:
If you want to specify the attribute to map to the automountInformation attribute , then
enter 3 for the following question:
Specify the attribute you want to map. [0]: 3 Enter
8.
Next, enter the attribute nisMapEntry you want to map to the automountInformation
attribute:
automountInformation -> nisMapEntry Enter
9.
Next, a screen displays the following information:
Current Automount attribute names:
76
Installing and configuring LDAP-UX Client Services for an HP server environment
1.automountMapName ->[nisMapname]
2.automountKey -> [cn]
3.automountInformation -> [nisMapEntry]
Specify the attribute you want to map. [0]:
Enter 0 to exit this menu for the following question:
Specify the attribute you want to map. [0]: 0 Enter
Attribute mappings for dynamic group support
If you are configuring dynamic group support, you must remap the default group member attribute,
memberuid, to memberURL (for HP-UX Directory Server or Red Hat Directory Server). For detailed
information about dynamic group support, see “Dynamic group support” (page 173).
Use the following steps to remap the memberuid attribute to the dynamic group attributes,
memberURL or nxsearchFilter. For example, the following procedures are used to remap
memberuid to memberURL:
1.
Enter yes for the following question:
Do you want to remap any of the stantdard RFC 2307 attributes? [yes]:
yes Enter
2.
Select the group service by entering 3 for the following question:
Specify the service you want to map? [0]: 3 Enter
3.
Next, a screen displays the following information:
Current Group attribute names:
1.cn ->[cn]
2.gidnumber -> [gidnumber]
3.memberuid -> [memberuid]
4.userpassword -> [userPassword]
Specify the attribute you want to map. [0]:
If you want to specify the attribute to map to memberuid, then enter 3 for the following
question:
Specify the attribute you want to map? [0]: 3 Enter
4.
Enter the attribute, memberURL or nxsearchFilter that you want to map to the memberuid
attribute:
memberuid —> memberURL Enter
5.
Next, a screen displays the following information:
Current Group.attribute names:
1.cn ->[cn]
2.gidnumber -> [gidnumber]
3.memberuid -> [memberURL]
4.userpassword -> [userPassword]
Specify the attribute you want to map. [0]:
To exit this menu, enter 0 for the following question:
Specify the attribute you want to map. [0]: 0 Enter
Attribute mappings for X.500 group membership support
If you want to configure X.500 group membership support, you should remap the group member
attribute to member or uniquemember instead of using the default attribute, memberuid.
Perform the following steps for attribute mappings to set up X.500 group membership:
2.4 Customized installation (setup) for an HP directory server environment
77
1.
Enter yes for the following question:
Do you want to remap any of the startdard RFC 2307 attributes? [yes]:
yes Enter
2.
Select the group service by entering 3 for the following question:
Specify the service you want to map? [0]: 3 Enter
3.
Next, a screen displays the following information:
Current Group attribute names:
1.cn ->[cn]
2.gidnumber -> [gidnumber]
3.memberuid -> [memberuid]
4.userpassword -> [userPassword]
Specify the attribute you want to map. [0]:
If you want to specify the attribute to map to memberuid, then enter 3 for the following
question:
Specify the attribute you want to map? [0]: 3 Enter
4.
Enter the member attribute that you want to map to the memberuid attribute:
memberuid —> member Enter
5.
Next, a screen displays the following information:
Current Group.attribute names:
1.cn ->[cn]
2.gidnumber -> [gidnumber]
3.memberuid -> [member]
4.userpassword -> [userPassword]
Specify the attribute you want to map. [0]:
To exit this menu, enter 0 for the following question:
Specify the attribute you want to map. [0]: 0 Enter
NOTE: LDAP-UX supports DN-based (X.500 style) membership syntax. This means that you do
not need to use the memberUid attribute to define the members of a POSIX group. Instead, you
may use either the member or uniqueMember attribute. LDAP-UX can convert from the DN syntax
to the POSIX syntax (an account name).
For HP-UX Directory Server or Red Hat Directory Server, the typical member attribute would be
either memberUid, member, or uniqueMember.
2.4.6 Configuring LDAP-UX Client Services with SSL or TLS support
The LDAP-UX Client Services supports either SSL (Secure Socket Layer) or TLS (Transport Layer
Security) to secure communication between LDAP clients and the LDAP directory server.
With SSL, an encrypted session is established on an encrypted port, 636. The LDAP-UX Client
Services supports SSL with a password as the credential, using either simple bind or SASL/GSSAPI,
or SASL/DIGEST-MD5 authentication to ensure confidentiality and data integrity between clients
and servers. (SASL/GSSAPI is only supported for LDAP-UX used with Windows ADS.) SSL enables
LDAP-UX clients to provide a secure way to protect the password over the network. In addition,
SSL/TLS can be used to validate the identity of the directory server (or Windows Active Directory
Server, ADS) if the privacy of the server’s and CA’s private keys can be assured. The directory
administrator can choose the authentication mechanism, such as using a simple password stored
in the directory server as a hash syntax.
The LDAP-UX Client Services supports SSL communication with Microsoft Windows Server 2003
R2 and 2008 Active Directory Server (ADS), HP-UX Directory Server 8.1 (or later), and Red Hat
Directory Server 8.0. For detailed information about how to set up and configure your HP directory
78
Installing and configuring LDAP-UX Client Services for an HP server environment
server to enable SSL communication over LDAP, see the appropriate administrator guide at the
following location:
http://www.hp.com/go/hpux-security-docs
For detailed information about how to enable SSL communication over LDAP for your Windows
Active Directory Server, see the Microsoft Knowledge Base Article at:
http://support.microsoft.com/kb/321051
Starting with LDAP-UX Client Services B.04.10, LDAP-UX Client Services supports a new extension
operation of TLS protocol called startTLS to secure communication between LDAP clients and the
directory server. An encrypted session can be established on an unencrypted port, 389. If an
encrypted port is used, it will fail to establish the secure connection. The TLS protocol provides
administrators better flexibility for using TLS in their environment by allowing the use of an
unencrypted LDAP port for communication between clients and server. LDAP-UX supports TLS with
password as the credential, using simple bind, SASL/GSSAPI (for Kerberos integration in Windows
environments), or SASL/DIGEST-MD5 authentication to ensure confidentiality and data integrity
between clients and servers.
The LDAP-UX Client Services supports TLS communication with Microsoft Windows Server 2003
R2 and 2008 Active Directory Server (ADS), HP-UX Directory Server 8.1 (or later), and Red Hat
Directory Server 8.0.
For an overview of the various authentication methods you can configure with LDAP-UX Client
Services, including their strengths and weaknesses, see Section 2.4.6.1 (page 79).
2.4.6.1 Supported authentication methods and their strengths and weaknesses
Table 7 compares the various authentication methods using the LDAP protocol in conjunction with
LDAP directory servers and LDAP-UX Client Services. This discussion does not include PAM modules.
PAM is a pluggable subsystem available on most Unix implementations that allows for integration
with various authentication systems, including LDAP. The PAM LDAPlibpam_ldap library can be
used to support some of these LDAP-specific authentication methods. For a list of authentication
mechanisms supported with libpam_ldap, see the section entitled “Supported features for
particular directory servers” in the LDAP-UX Integration Release Notes.
Table 7 Comparison of authentication methods
Authentication
method
Strengths
SIMPLE
Weaknesses
• Universal support by HP directory servers,
Windows ADS, and clients
• Clear text password transfers across network
• Flexible password hashing options are
available in the HP-UX Directory Server
• No additional setup cost (if you want to use
GSSAPI, you have to set up the Kerberos
infrastructure; if TLS, you have to set up PKI.
However, in either case, the transferability of
the clear text password across the network
imposes a vulnerability
SASL/DIGEST-MD5 • No clear text password in the network
(challenge/response, meaning the directory
server challenges you for the password and
you must respond)
• Nearly universally supported
• Clear text or equivalent password must be
stored on the directory server
• There are known attacks against the
DIGEST-MD5 algorithm
2.4 Customized installation (setup) for an HP directory server environment
79
Table 7 Comparison of authentication methods (continued)
Authentication
method
Strengths
SASL/GSSAP
(Windows
ADS only)I
Weaknesses
• No clear text password in the network (INDIA: • Clear text or equivalent password must be
Should the same be said here about
stored on the KDC
challenge/response as is documented above?)
• Single sign-on support (a user can enter one
user name and password to access multiple
applications, avoiding further prompts when
the user switches between applications during
a session)
• Integration with Kerberos domains (MS
domains)
• Validates identity of the directory server
SSL/TLS
• SSL and TLS are the same protocol, except SSL • Requires cost of managing a PKI
establishes a session on an encrypted port so
that the entire message is encrypted; TLS is
more flexible, allowing connection to a regular
port and providing on demand SSL encryption
• Often used with SIMPLE authentication, because
SIMPLE authentication transmits passwords in
clear text; less necessary for SASL/GSSAPI,
which performs the same security features
• Enables encryption of all communications with
the directory server
• Can be used to validate the identity of the
directory server
• Because LDAP-UX does not support SASL
encryption, SSL/TLS is valuable even when
using DIGEST-MD5 and SASL/GSSAPI
2.4.6.2 Steps for configuring LDAP-UX Client Services with SSL or TLS support
You can choose to enable SSL or TLS with LDAP-UX when you run the setup program. However,
to use SSL or TLS, you must install the CA certificate on your LDAP-UX client and configure your
LDAP directory server to support SSL or TLS before you run the setup program.
To configure LDAP-UX Client Services with SSL/TLS support, perform the following tasks before you
run the setup program. These steps are applicable to both HP directory server and Windows
ADS environments (readers of “Installing and configuring LDAP-UX Client Services for a Windows
ADS environment” (page 114) are referred to this section for information about configuring LDAP-UX
Client Services with SSL/TLS support).
1.
The enable_startTLS integer variable in the /etc/opt/ldapux/ldapux_client.conf
file controls whether the TLS feature is enabled or disabled. By default, TLS is disabled. To
enable TLS, edit the file to set the enable_startTLS parameter to 1.
To disable TLS (enabling SSL), set enable_startTLS to 0.
2.
3.
80
The preferredServerList string variable in the /etc/opt/ldapux/
ldapux_client.conf configuration file controls the Peer Certificate policy, setting the
validation level for assuring the identities of the clients and servers between which TLS or SSL
protects communication. To adjust the validation level, follow the instructions in Section 2.4.6.3
(page 81).
Ensure that the certificate database files cert8.db and key3.db are on your client system.
To create these database files on your client system, follow the steps in Section 2.4.6.4
(page 82).
Installing and configuring LDAP-UX Client Services for an HP server environment
NOTE: If you already have the certificate database files cert8.db and key3.db on your
client for your HP-UX applications, you can simply create a symbolic link /etc/opt/ldapux/
cert8.db that points to cert8.db, and /etc/opt/ldapux/key3.db that points to
key3.db.
4.
SSL and TLS protocols support a variety of cryptographic algorithms (known as ciphers) that
are used for such operations as authenticating the server and client to each other, transmitting
certificates, and establishing session keys. If a cipher is found to be flawed and subject to
attack, administrators of HP-UX and the directory server must know about their vulnerability.
Ciphers can be disabled in the directory server. For information about SSL/TLS ciphers and
which ones are supported by LDAP-UX, see Section 2.4.6.5 (page 84).
2.4.6.3 Adjusting the peer certificate policy
With SSL/TLS, not only communication between clients (LDAP-UX) and servers (the LDAP directory
server) can be protected, but in addition, specific levels of assurance of the identities of the clients
and servers can be validated. This section describes how to adjust this validation level.
The peer_cert_policy parameter in the /etc/opt/ldapux/ldapux_client.conf
configuration file is a string variable used to control the validation level. The valid options for this
parameter are:
WEAK
Performs no validation of SSL or TLS certificates. Communication between the client
and server can be encrypted, however the client has no assurance that it is
communicating with a trusted server.
CERT
Verifies that the issuers of peer SSL or TLS certificates are trusted. Communication
between the client and server can be encrypted and the client has some assurance that
it is communicating with a trusted server. In this scenario, it is still possible for the server
to have a certificate that has been issued for a different server if methods used to protect
private keys of server certificates are not in place. CERT is the default mode of operation
with LDAP-UX.
CNCERT
Performs both the CERT verification and also verifies that the common name or
subjectAltName values embedded in the certificate matches the address used to
connect to the LDAP server, as described in RFC 4513.
Increasing certificate validation level from the default (CERT) to CNCERT requires additional and
specific configuration steps. If not properly established, it can interfere with LDAP-UX and proper
system operation. Because LDAP-UX can be used for host-name resolution (similar to DNS), LDAP-UX
normally stores the IP address of LDAP servers in the configuration profile. This procedure assures
that if LDAP-UX is asked to resolve a host name, it can do so without first needing to resolve the
host name of the LDAP directory server (which could lead to a catch-22). However, since certificates
normally embed the host name or fully qualified host name and LDAP-UX only has the IP address
of the host, it is not possible for LDAP-UX to verify the host name on the certificate.
If you want to configure the CNCERT validation level with the peer_cert_policy parameter,
you must manually execute the following configuration steps:
1.
2.
Update the preferredserverlist setting in the profile to contain the host name of the
LDAP server such that it matches the host name specified in the LDAP server’s certificate. To
update this setting, follow the steps described in Section 2.4.6.3.1 (page 82).
Perform one of the following steps:
•
Prevent LDAP-UX from being used for host-name resolution by removing “ldap” from the
“hosts” service in the /etc/nsswitch.conf file.
•
Or, have some other name resolution service (such as files or dns) provide the host
name and IP address; the selected service must appear before “ldap” in the /etc/
nsswitch.conf file for the “hosts” service.
2.4 Customized installation (setup) for an HP directory server environment
81
2.4.6.3.1 Modifying preferredServerList in the LDAP-UX profile
Use the following steps to modify the value of the preferredServerList attribute in the LDAP-UX
configuration profile:
1.
Run the following steps to find the name of the LDAP server used on the server certificate.
Assuming this certificate has been installed in your local certificate database file, /etc/opt/
ldapux/cert8.db:
•
Run the following commands to list all server certificates used by LDAP-UX:
cd /etc/opt/ldapux
certutil -d . -L
•
Run the following command to select the nickname of the certificate from the preceding
list:
certutil -d . -L -n <selected nickname>
•
Select the first name component of the “Subject:” name. For example, if the
“Subject:” string is “CN=ldapserver.example.com, O=Example Corp” then
the name component would be “ldapserver.example.com".
NOTE: Depending on how your certificate administrator manages your network, this server
certificate might not be found in your cert8.db file. Instead you might only find certificates
for any trusted Certificate Authorities. In this case, contact your certificate administrator for
the LDAP server certificate details.
2.
3.
4.
In a separate window, use the ldapentry tool (for HP directory server) or the Active Directory
Services Interface (ADSI, for Windows ADS) tool to modify the value of the
preferredServerList attribute with the LDAP server name found in step 1. See
Section 7.10.2 (page 245) for detailed information on changing LDAP-UX configuration profile
settings manually.
Examine the “preferredServerList” attribute
Use the nslookup tool to verify the IP address specified in the preferred server list matches
that of the name of the host name found in step 1.
For example, if the preferredServerList attribute value is 192.168.1.1:636 and “Subject”
is CN=ldapserver.example.com,O=Example Corp, then
$ nslookup 192.168.1.1
Name Server: dns-resolver.example.com
Address: 192.169.1.254
Trying DNS
Name: ldapserver.example.com
Address: 192.168.1.1
2.4.6.4 Creating certificate database files using the certutil utility
The following steps show how you can create the security database files, cert8.db and key3.db
on your client system using the Certificate Database Tool command line utility (certutil):
82
Installing and configuring LDAP-UX Client Services for an HP server environment
1.
Retrieve the certificate. The procedure for this varies, depending on several factors. If your
organization is using either a certificate management system internal to the organization, or
a third-party certificate authority, you will usually use a web browser to download a CA
certificate. The certificate is downloaded in one of two forms: ASCII-encoded PEM form, or
binary DER form.
If your organization is using Microsoft Certificate Services for Windows, the web address
from which to download the certificate is typically the following:
http://windows-server-name/certsrv
Click on the Download CA certificate link.
Save the CA certificate to a file and transfer it to the HP-UX host where LDAP-UX is being
configured for SSL.
NOTE: To download the CA certificate with Internet Explorer, click Save to save the CA
certificate to a file. Additionally, the direct web address for downloading the certificate might
be required if the ActiveX control used by Microsoft Certificate Services before Windows
2008 is not supported. The direct web address would take the form of:
http://windows-server-name/certsrv/certnew.cer?ReqID=CACert&Renewal=0&Mode=inst&Enc=b64
To download the CA certificate with Mozilla Firefox, click View, open the Details tab, and
then click Export... to save the CA certificate to a file.
In PEM form the certificate looks similar to this:
--------------- BEGIN CERTIFICATE -------------------------------MIICJjCCAY+gAwIBAgIBJDANBgkghkiG9w0BAQQFADBxMQswCQYDVQQGEwJVUzEL
MAkga1UECBMCQ2ExEjAQBgNVBAcTCWN1cGVvsG1ubzEPMA0GA1UEChmgAhaUy29T
MRIwEAYDVQQLEw1RR1NMLUxkYXAxHDAaBgNVBAMTE0N1cnRpzmljYXR1IE1hbmFn
4I2vvzz2i1Ubq+Ajcf1y8sdafuCmqTgsGUYjy+J1weM061kaWOt0HxmXmrUdmenF
skyfHyvEGj8b5w6ppgIIA8JOT7z+F0w+/mig=
--------------- END CERTIFICATE ----------------------------------
As an alternative to installing the CA certificate, you can install and trust the LDAP server’s
own certificate rather than the CA certificate that is issued with the LDAP server’s certificate.
Because LDAP-UX only accepts connections to the LDAP server for which the server certificate
is valid, this alternative establishes a more narrow scope of trust. So, if you plan to connect
to multiple LDAP servers, you must install multiple server certificates. Additionally, because
server certificates tend to have a validity range shorter than that of CA certificates, you might
find yourself needing to update the certificate more often.
2.
Use the rm command as in the following example to remove the old database files /etc/
opt/ldapux/cert8.db and /etc/opt/ldapux/key3.db:
# rm -f /etc/opt/ldapux/cert8.db /etc/opt/ldapux/key3.db
3.
Create new certificate database files, using the command shown in the following example.
# /opt/ldapux/contrib/bin/certutil -d /etc/opt/ldapux –N
The certutil tool will prompt you to enter a password to protect the private key database.
If you will not be storing any private keys in the certificate database files, press Enter to leave
the password empty . LDAP-UX does not require a private key; however, if you plan to use
these certificate database files with other applications that make use of a private key, you
should set a password.
4.
Add the downloaded CA certificate to the certificate database created in the preceding step.
If the CA certificate was downloaded in binary DER form, use the following command:
# /opt/ldapux/contrib/bin/certutil -d /etc/opt/ldapux -A -n "CA
cert" -t “CT,,” -i cacert.der
If the CA certificate was downloaded in ASCII-encoded PEM form, use the –a (ASCII) option
as in the following example:
2.4 Customized installation (setup) for an HP directory server environment
83
# # /opt/ldapux/contrib/bin/certutil -d /etc/opt/ldapux -A -n "CA
cert" -t “CT,,” -i cacert.pem -a
If the certificate is a server certificate, use the “P,,” trust flag:
# # /opt/ldapux/contrib/bin/certutil -d /etc/opt/ldapux -A -n "server
cert" -t “P,,” -i servercert.der
NOTE: The required –n parameter gives the certificate a nickname in the certificate database
files. The nickname value is arbitrary. If you plan to connect to multiple LDAP servers that were
issued SSL certificates by different certificate authorities, you should use the nickname to help
differentiate between the different CA certificates. For example, you might name one Issuer1
CA cert and the other Issuer2 CA cert.
The –t parameter sets the trust bits for the certificate. For CA certificates, use “CT,,” to
indicate that the certificate is trusted as an issuer of SSL certificates. For server certificates, use
“P,,” to indicate that the certificate represents a trusted peer.
For more information about using the certutil utility, see:
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
2.4.6.5 SSL/TLS ciphers
The SSL/TLS protocols support a variety of different cryptographic algorithms called ciphers for
use in operations such as authenticating the server and client to each other, transmitting certificates,
and establishing session keys. When an LDAP client connects to an LDAP directory server, the
server usually picks the strongest cipher supported by both client and server. Clients and servers
might support different cipher suites, or sets of ciphers, depending on a variety of factors. The
ciphers currently supported by LDAP-UX are listed in Table 8 (page 84).
Table 8 Supported ciphers
Message
authentication
Version
Key exchange
Encryption
Key length
SSL3 and TLS
RSA (A public-key
algorithm for both
encryption and
authentication)
RC4 (Rivest
encryption)
128
SSL3 and TLS
RSA
3DES (Data Encryption 168
Standard applied
three times)
SHA1 (Secure Hash
Algorithm)
SSL3 and TLS
RSA
DES (Data Encryption
Standard)
56
SHA1
SSL3 and TLS
RSA
RC4
40
MD5
SSL3 and TLS
RSA
RC2
40
MD5
TLS
RSA (1024–bit public
key)
RC4
56
SHA1
TLS
RSA (1024–bit public
key)
DES
56
SHA1
MD5 (Message Digest
algorithm)
If vulnerabilities are discovered in cipher systems, administrators can use this list to determine
whether the cited vulnerabilities might affect their systems. If a cipher with a known vulnerability
is indeed being used, the appropriate administrator can disable the cipher in the central directory
server (not in LDAP-UX). For information about managing available ciphers for use with HP-UX
Directory Server, see the HP-UX Directory Server administrator guide.
84
Installing and configuring LDAP-UX Client Services for an HP server environment
2.4.7 Configuring LDAP-UX Client Services with NIS publickey support
LDAP-UX Client Services supports discovery and management of NIS publickeys in an LDAP
directory. Both public and secret keys used by the Secure RPC API can be stored in user and host
entries in an LDAP directory server, using thenisKeyObject object class. Support for discovery
of keys in an LDAP directory server is provided through the getpublickey() and
getsecretkey() APIs. You can use chkey and newkey commands to manage user and host
keys in an LDAP server. The chkey -s ldap command is used to change a user's secure RPC
public key and secret key in an LDAP directory. The newkey -u <username> -s ldap
command is used to add new keys for users to an LDAP directory while the newkey -h
<hostname> -s ldap command is used to create new keys for machines to an LDAP directory.
For detailed information on the newkey andchkey commands, see the newkey(1M),chkey(1),
getpublickey(3N), getsecretkey(), and publickey(4) manpages.
2.4.7.1 HP-UX Enhanced Publickey-LDAP software requirement
Support for NIS publickey through LDAP requires functionality enhancement in LDAP-UX Client
Services and an enhancement in the ONC product. ONC with publickey LDAP support is available
through the HP-UX Enhanced Publickey-LDAP Software Pack (SPK) web release.
To enable the publickey LDAP support, you must install the appropriate Enhanced Publickey-LDAP
software bundle listed in Table 9 (for HP-UX 11i v2 only; no patch is required for HP-UX 11i v3)
and LDAP-UX Client Services B.04.00 or later on your client systems. The software bundle contains
all the required patches plus the enablement product for this new feature. For detailed information,
see the ONC with Publickey LDAP Support Software Pack Release Notes at:
http://www.hp.com/go/hpux-networking-docs (click HP-UX 11i v2 Networking Software)
Navigate to NFS Services.
Table 9 Enhanced Publickey-LDAP software requirement
Operating System Supported
Software Bundle Version
Release Date
HP-UX 11i v2
Enhkey B.11.23.01
October, 2006
You can download the Enhanced Publickey-LDAP software bundle from the HP Software Depot
website at:
•
Go to http://www.hp.com/go/softwaredepot.
•
Click on Enhancement releases and patch bundles.
•
Select the link:
◦
•
Select the link:
◦
•
PublicKey-LDAP (for HP-UX 11i v2)
Select and download the following software bundle, place it to on your client system (/tmp):
◦
•
HP-UX Software Pack (Optional HP-UX 11i v2 Core Enhancements)
Enhkey_B.11.23.01_HP-UX_B.11.23_IA_PA depot for HP-UX 11i v2
Use swinstall to install the software bundle:
◦
swinstall -x autoreboot=true -x reinstall=false -s
/tmp/ENHKEY_B.11.23.01_HP-UX_B.11.23_IA_PA.depot for HP-UX 11i v2
2.4.7.2 Extending the NIS publickey schema into your directory
The NIS publickey schema is not loaded in the HP-UX Directory Server or Red Hat Directory Server.
If you are installing LDAP-UX B.04.00 or later on your client system, the setup program will extend
the publickey schema into your directory server. If you previously configured LDAP-UX B.03.30 or
2.4 Customized installation (setup) for an HP directory server environment
85
a previous version, and now update the product to version B.04.00 or later, you must rerun the
setup program to extend the publickey schema into your LDAP directory. You do not need to
rerun the setup program for the subsequent client systems. For detailed information on how to
run the setup program to extend the publickey schema into an LDAP directory, see Section 2.4.5.1
(page 69).
2.4.7.3 Admin Proxy user
A special type of proxy user, known as an Admin Proxy has been added to LDAP-UX to support
management of NIS publickey information in an LDAP directory server. The Admin Proxy represents
the HP-UX administrator's rights in the directory server and typically is used to represent root
privileges extended to the directory server. Only an Admin Proxy user is allowed to use the newkey
tool to add host and user keys into the LDAP directory server, or to use the chkey tool to modify
host keys in the LDAP directory server.
2.4.7.3.1 Configuring an Admin Proxy user by using ldap_proxy_config
You must use a new ldap_proxy_config tool option-A to configure an Admin Proxy user. You
must specify the -A option along with other options to perform operations applying to an Admin
Proxy user. For example, you can use the ldap_proxy_config -A -i command to create an
Admin Proxy user. For more information about using the ldap_proxy_config tool, see
Section 9.2.6 (page 280).
2.4.7.3.2 Password for an Admin Proxy user
To protect user secret keys in the LDAP directory, the secret keys are encrypted using the user's
password. This process is used in NIS environments. The host's secret key must also be encrypted.
Since the host itself does not have its own password, root's password is used to encrypt the host's
secret key. The chkey or newkey command prompts for root's password when changing or
adding a key for a host. For this reason, you might prefer to configure the Admin Proxy user in the
LDAP directory to have the same password as the root user on the master host.
Although it is not required that the Admin Proxy user and root user share the same password, this
helps you avoid storing the Admin Proxy user's password in the administrator's credential file
/etc/opt/ldapux/acred (this file and the pcred file are not encrypted). In this way, when
you run the ldap_proxy_config -A -i command to configure the Admin Proxy user, you
enter only Admin Proxy user's DN without the password. LDAP-UX will use the root password given
to the chkey and newkey commands as the Admin Proxy user's password to perform public key
operations. However, the ldap_proxy_config -A -v command is not able to validate the
Admin Proxy user because no password is available to ldap_proxy_config. As a result, the
message “No password is provided. Validation is not performed" is displayed.
2.4.7.4 Setting ACI for key management
Before storing public keys in an LDAP server, LDAP administrators might want to update their LDAP
access controls such that users can manage their own keys, and the Admin Proxy user can manage
host keys. This section describes how you set up ACIs for an Admin Proxy user or a user.
2.4.7.4.1 Setting ACI for an Admin Proxy user
With the HP-UX Directory Server, you may use the Directory Server Console or the ldapmodify
command to set up an ACI, which gives an Admin Proxy user permissions to manage host and
user keys in the LDAP directory.
An Example
The following ACI gives the permissions for the Admin Proxy user uid=keyadmin to read, write,
and compare nissecretkey and nispublickey attributes for hosts and users:
dn:dc=org,dc=hp,dc=com
86
Installing and configuring LDAP-UX Client Services for an HP server environment
aci:(targetattr ="objectclass||nispublickey||nissecretkey")
(version 3.0;acl "Allow keyadmin to change key pairs";
allow (read,write,compare)
userdn="ldap:///uid=keyadmin,ou=people,dc=org,dc=hp,dc=com";)
2.4.7.4.2 Setting ACI for a user
With the HP-UX Directory Server, you must set up an ACI which gives a user permission to change
his own nissecretkey and nispublickey attributes. To set up ACI for a user, use the Directory
Server Console or ldapmodify.
An Example
The following ACI gives a user permission to change his own nissecretkey and nispublickey
attributes for user keys:
dn:ou=People,dc=org,dc=hp,dc=com
aci:(targetattr ="nissecretkey||nispublickey")(version 3.0;
acl "Allow key self modification";allow (write)
(userdn = "ldap:///self");)
2.4.7.5 Configuring the serviceAuthenticationMethod attribute
serviceAuthenticationMethod is a newly supported attribute of the configuration profile,
/opt/ldapux/ldapux_profile.ldif. Its function is the same as authenticationMethod,
but it allows authentication configuration for specific name services. The
serviceAuthenticationMethod attribute is created to resolve issues that might arise when
the default authentication method is not considered secure enough for specific name services. For
example, if the default authenticationMethod is configured as NONE then the newkey and
chkey commands would not know how to properly bind to the directory server when changing
or adding key pairs. LDAP-UX only supports the serviceAuthenticationMethod attribute for
the keyserv service, since the keyserv service is the only one that currently needs modification
of privileges in the directory server.
To perform newkey and chkey operations, LDAP-UX binds the Admin Proxy user to the LDAP
directory using the authentication method specified in serviceAuthenticationMethod.
LDAP-UX only supports serviceAuthenticationMethod for keyserv. Any other services
configured in serviceAuthenticationMethod will be ignored.
Configuring serviceAuthenticationMethod is optional. If you do not configure
serviceAuthenticationMethod, LDAP-UX binds the Admin Proxy user to the LDAP directory
using the authentication method specified for the proxy user.
2.4.7.5.1 Authentication methods
LDAP-UX Client Services supports the following authentication methods for the keyserv service:
•
simple with SSL enabled
•
SASL/GSSAPI or SASL/DIGEST-MD5 with SSL enabled
•
simple with SSL disabled
•
SASL/GSSAPI or SASL/DIGEST-MD5 with SSL disabled
NOTE:
SASL/GSSAPI is only supported for LDAP-UX used with Windows ADS.
SSL settings for both authenticationMethod and serviceAuthenticationMethod must
be set the same. It is not supported to have SSL enabled for authenticationMethod and SSL
disabled for serviceAuthenticationMethod, or vice versa.
For an overview of these various authentication methods, including their strengths and weaknesses,
see Section 2.4.6.1 (page 79).
2.4 Customized installation (setup) for an HP directory server environment
87
2.4.7.5.2 Procedures used for configuring the serviceAuthenticationMethod attribute
Use the following steps on one of LDAP-UX client sytems to configure the
serviceAuthenticationMethod attribute in the /etc/opt/ldapux/
ldapux_profile.ldif file:
1.
2.
Log in as root.
Use the ldapentry tool to modify the profile entry in the LDAP directory server to include
serviceAuthenticationMethod. To do this, ldapentry requires the profile DN. You
can find the profile DN from PROFILE_ENTRY_DN in /etc/opt/ldapux/
ldapux_client.conf after you finish running the setup program. The following example
edits the profile entry "cn=ldapuxprofile,dc=org,dc=hp,dc=com":
For example:
cd /opt/ldapux/bin
./ldapentry -m "cn=ldapuxprofile,dc=org,dc=hp,dc=com"
After you enter the prompts for "Directory login:" and "password:", ldapentry will bring
up an editor window with the profile entry. You can add the
serviceAuthenticationMethod attribute.
The value of the serviceAuthenticatioMethod entry depends on the authentication
method you configure. The following shows the possible values of the
serviceAuthenticationMethod attribute:
•
For SASL /DIGEST-MD5 using the Distinguish Name (DN) to generate the DIGEST-MD5
hash, the data in the entry is:
serviceAuthenticationMethod:keyserv:sasl/digest-md5:username=dn
•
For SASL /DIGEST-MD5 using the uid attribute to generate the DIGEST-MD5 hash, the
data in the entry is:
serviceAuthenticationMethod:keyserv:sasl/digest-md5
•
For SASL/DIGEST-MD5 with SSL enabled using the DN to generate the DIGEST-MD5
hash, the data in the entry is:
serviceAuthenticationMethod:keyserv:tls:sasl/digest-md5:username=dn
•
For SASL/DIGEST-MD5 with SSL enabled using the uid attribute to generate the
DIGEST-MD5 hash, the data in the entry is:
serviceAuthenticationMethod:keyserv:tls:sasl/digest-md5
•
For simple authentication, the data in the entry is:
serviceAuthenticationMethod:keyserv:simple
•
For simple with SSL enabled, the data in the entry is:
serviceAuthenticationMethod:keyserv:tls:simple
For more information on ldapentry, see “Command and tool reference” (page 276).
NOTE: If you use TLS for secure communication between LDAP clients and the HP-UX Directory
Server or Red Hat Directory Server, you must use the Directory Server Console to manually
add the values of the serviceAuthenticationMethod attribute.
3.
Go to /opt/ldapux/config:
cd /opt/ldapux/config
4.
Use /opt/ldapux/config/get_profile_entry to download the modified LDIF profile:
./get_profile_entry -s nss
88
Installing and configuring LDAP-UX Client Services for an HP server environment
5.
Run the /opt/ldapux/config/display_profile_cache tool to examine the
configuration of the serviceAuthenticationMethod attribute:
./display_profile_cache
For example:
If the serviceAuthenticationMethod:keyserv:sasl/digest-md5 entry is added
to the profile entry in the LDAP directory, you can see the following information when you run
the display_profile_cache tool:
serv-auth: keyserv:sasl/digest-md5
auth opts: username: uid
realm:
For subsequent LDAP-UX client systems that share the same profile configuration, use the following
steps to download and activate the profile:
1.
2.
Log in as root.
Go to /opt/ldapux/config:
cd /opt/ldapux/config
3.
Use /opt/ldapux/config/get_profile_entry to download the modified LDIF profile:
./get_profile_entry -s nss
4.
Run the /opt/ldapux/config/display_profile_cache tool to examine the
configuration of the serviceAuthenticationMethod attribute:
./display_profile_cache
5.
Restart the LDAP-UX client daemon, ldapclientd, if you change the authentication method
from nonSSL to SSL. Otherwise, skip this step.
2.4.7.6 Configuring NSS
Configure NSS to enable the LDAP support for NIS-based publickeys.
You can save a copy of /etc/nsswitch.conf file and modify the original to add LDAP support
to the NIS publickey service. See /etc/nsswitch.ldap for a sample.
The following shows the sample file, /etc/nsswitch.ldap:
passwd:
group:
hosts:
networks:
protocols:
rpc:
publickey:
netgroup:
automount:
aliases:
services:
files ldap
files ldap
dns files ldap
files ldap
files ldap
files ldap
ldap [NOTFOUND=return] files
files ldap
files ldap
files
files ldap
2.5 Postinstallation configuration tasks
This section includes tasks you can perform after performing your guided or customized installation.
2.5.1 Importing name service data into your directory
To import your name service data into your LDAP Directory, consider the following:
•
If you have already imported data into your directory with the NIS/LDAP Gateway product,
LDAP-UX Client Services can use that data and you may skip to Section 2.4.5 (page 67).
•
If you are using NIS, the migration scripts take your NIS maps and generate LDIF files. These
scripts can then import the LDIF files into your directory, creating new entries in the directory.
2.5 Postinstallation configuration tasks
89
This only works if you are starting with an empty directory or creating an entirely new subtree
in your directory for your data.
If you are not using NIS, the migration scripts can take your user, group, and other data from
files, generate LDIF, and import the LDIF into your directory.
•
If you integrate the name service data into your directory, the migration scripts might be helpful
depending on where you put the data in your directory. You could use them just to generate
LDIF, edit the LDIF, then import the LDIF into your directory. For example, you could manually
add the posixAccount object class to your existing entries under ou=People and add their
HP-UX information there.
•
If you used the guided installation (autosetup) to create a new directory server, ensure that
the user and group numbers to be imported or migrated do not collide with those created by
autosetup (see Section 2.5.1.1 (page 90)).
2.5.1.1 Prevent user and group number collisions with those created by autosetup
The information in this section is a postinstallation task for guided installations only (autosetup);
it does not pertain to customized installations (setup).
If you used the guided installation (autosetup) and created a new directory server instance,
autosetup created one new HP-UX account, the Domain Administrator (also known as domadmin).
It also created three new groups: DomainAdmins, HostAdmins, and UserAdmins. LDAP-UX
assigned a UID number to domadmin and GID numbers to the three groups. Once you start to
migrate user information into this directory server, you must ensure that the user and group numbers
to be migrated do not collide with those created by autosetup. If you already know that some
user or group numbers will collide with those created by autosetup, you can change the UID or
GID numbers now by using the ldapugmod tool. To determine the UID numbers and GID numbers
that were assigned by autosetup, use the ldapuglist tool, as shown in the following example.
Log in as the domadmin user on the local host.
brewer (): /opt/ldapux/bin/ldapuglist -n domadmin
dn: uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com
cn: Domain Administrator
uid: domadmin
uidNumber: 123
gidNumber: 220
loginShell: /usr/bin/sh
homeDirectory: /home/domadmin
gecos: Domain Administrator
brewer (): /opt/ldapux/bin/ldapuglist -t group -f "cn=*Admins"
dn: cn=UserAdminss,ou=Groups,dc=mydomain,dc=example,dc=com
cn: UserAdmins
cn: UserAdminss
gidNumber: 1910
dn: cn=HostAdmins,ou=Groups,dc=mydomain,dc=example,dc=com
cn: HostAdmins
gidNumber: 1920
memberUid: domadmin
dn: cn=DomainAdmins,ou=Groups,dc=mydomain,dc=example,dc=com
cn: Domain Administrators
cn: DomainAdmins
gidNumber: 1900
memberUid: domadmin
Use the ldapugmod tool to change numbers as needed. In the following example, the ldapugmod
tool changes the GID number of DomainAdmins from 1900 to 1999.
90
Installing and configuring LDAP-UX Client Services for an HP server environment
brewer (): ldapugmod -P -t group -g 1999 DomainAdmins
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
ntc9-212 (src/tools): ldapuglist -t group -n DomainAdmins
dn: cn=DomainAdmins,ou=Groups,dc=mydomain,dc=example,dc=com
cn: Domain Administrators
cn: DomainAdmins
gidNumber: 1999
memberUid: domadmin
For more information about using the ldapuglist and ldapugmod tools to list and modify users
and groups, see Section 7.7 (page 218).
2.5.1.2 Steps for importing name service data into your directory
Here are the steps for importing your user and group data into your LDAP directory. Modify them
as needed.
1.
Decide which migration method and scripts you will use. Migration scripts are provided to
ease the task of importing your existing name service data into your LDAP directory.
For a complete description of the scripts, what they do, and how to use them, see Section 9.6
(page 383). Modify the migration scripts, if needed.
2.
3.
4.
Back up your directory.
Run the migration scripts, using the worksheet in “Configuration worksheet” (page 403).
If the migration method that you used did not already do so, import the LDIF file into your
directory.
2.5.2 Verifying LDAP-UX Client Services
This section describes some simple ways you can verify the installation and configuration of your
LDAP-UX Client Services. These verification steps can be used for both HP directory server and
Windows ADS environments (readers of “Installing and configuring LDAP-UX Client Services for a
Windows ADS environment” (page 114) are referred to this section for information about verifying
LDAP-UX Client Services). You might need to do more elaborate and detailed testing, especially if
you have a large environment.
If any of the following tests fail, see Section 7.13 (page 251).
1.
To test the name service, use the nsquery1 command:
nsquery lookup_type lookup_query [lookup_policy]
For example, to test the name service switch to resolve a user name lookup, enter:
nsquery passwd username ldap
where username is the login name of a valid user whose POSIX account information is in
the directory. You should see output something like the following depending on how you have
configured /etc/nsswitch.conf:
Using "ldap" for the passwd policy.
Searching ldap for jbloggs
User name: jbloggs
user Id: 10000
Group Id: 2000
Gecos:
Home Directory: /home/jbloggs
Shell: /bin/sh
Switch configuration: Terminates Search
This tests the Name Service Switch configuration in /etc/nsswitch.conf. If you do not
see similar output, see /etc/nsswitch.conf for proper configuration.
2.
Use other commands to display information about users in the directory, making sure the
output is as expected:
1. nsquery is a contributed tool included with the ONC/NFS product. For more information, see the nsquery(1) manpage.
2.5 Postinstallation configuration tasks
91
pwget -n username
nsquery hosts host_to_find
grget -n groupname
ls -l
NOTE: While you can use the following commands to verify your configuration, these
commands enumerate the entire passwd or group database, which might reduce network and
directory server performance for large databases:
pwget(with no options)
grget(with no options)
listusers
logins
3.
Use one of the following expressions of the ldapcfinfo command to verify that a particular
service is properly configured:
ldapcfinfo -t passwd
ldapcfinfo -t group
ldapcfinfo -t pam
When any of these commands return an error, the command reports what is improperly
configured.
4.
Use the beq search utility to search for the following services: pwd (password), grp (group),
shd (shadow password), srv (service), prt (protocol), rpc (RPC), hst (host), net (network),
ngp (netgroup), and grm (group membership). The following is an example beq command
using name as the search key, pwd as the service, and ldap as the library in 32-bit mode on
an HP-UX 11i v2 or v3 a PA-RISC machine.
./beq -k n -s pwd -l /usr/lib/libnss_ldap.1 iuser1
nss_status........ NSS_SUCCESS
pw_name...........(iuser1)
pw_passwd.........(*)
pw_uid............(101)
pw_gid............(21)
pw_age............()
pw_comment........()
pw_gecos..........(gecos data in files)
pw_dir............(/home/iuser1)
pw_shell..........(/usr/bin/sh)
pw_audid..........(0)
pw_audflg.........(0)
Use the following beq command if you are running 64-bit applications on an HP-UX 11i v2
or v3 HP Integrity server:
./beq -k n -s pwd -l /usr/lib/hpux64/libnss_ldap.so.1 iuser1
Use the following beq command if you are running 32-bit applications on an HP-UX 11i v2
or v3 HP Integrity server:
./beq -k n -s pwd -l /usr/lib/hpux32/libnss_ldap.so.1 iuser1
For command syntax and examples, see Section 9.7.1 (page 386) .
5.
6.
Log in to the client system from another system using rlogin or telnet. Log in as a user in
the directory and as a user in /etc/passwd to make sure both work.
Optionally, test your PAM_AUTHZ authorization configuration:
If the PAM_AUTHZ is configured without the pam_authz.policy file, verify the following:
•
92
Log into the client system from another system using rlogin or telnet. From there log
in to the directory as a member from +@netgroup to verify that PAM_AUTHZ authorizes
you and is working correctly.
Installing and configuring LDAP-UX Client Services for an HP server environment
•
Log in as a user to the directory as a member of a-@netgroup to be sure that the system
will not authorize you to log in.
If the PAM_AUTHZ module is configured with the pam_authz.policy file, verify the following:
7.
8.
•
Log in the client system with a user name that is covered by an allow access rule in the
policy file. Make sure the user will be allowed to log in.
•
Log in as a user that is covered by adeny access rule in the policy file. Make sure the
user can not log in to the client system.
Open a new hpterm window and log in to the client system as a user whose account
information is in the directory. (For more information about the hpterm command, see the
hpterm(1X) manpage.) It is important you open a new hpterm window or log in from another
system, because if login doesn't work, you could be locked out of the system and would have
to reboot to single-user mode. Logging in to the client system in this way tests the PAM
configuration in /etc/pam.conf. If you cannot log in, verify that /etc/pam.conf is
configured properly. In addition, examine your directory to make sure the user's account
information is accessible by the proxy user or anonymously, as appropriate. Examine your
profile to make sure it is correct. For troubleshooting information, see Section 7.13 (page 251).
To examine files belonging to a user whose account information is in the directory, use the
ls or ll command. Make sure the owner and group of each file are accurate:
ll /tmp
ls -l
If any owner or group shows up as a number instead of a user or group name, the name
service switch is not functioning properly. Examine the /etc/nsswitch.conf file, your
directory, and your profile.
9.
If you want to verify that you set up X.500 group membership correctly, follow these steps:
a. Create a valid POSIX user and group. Add this user as a member of this group using the
attribute "member" instead of "memberuid". Here is an example ldif file specifying
xuser2 as a member of the group xgrpup1:
#cat example_ids.ldif
dn: cn=xgroup1,ou=Groups,o=hp.com]
objectClass: posixGroup
objectClass: groupofnames
objectClass: top
cn: xgroup1
userPassword: {crypt}*
gidNumber: 999
member: uid=xuser2,ou=People,o=hp.com
dn: uid=xuser2,ou=People,o=hp.com
uid: xuser2
cn: xuser2
objectClass: top
objectClass: account
objectClass: posixAccount
userPassword: {crypt}xxxxxxxxxxxxx
loginShell: /bin/ksh
uidNumber: 9998
gidNumber: 999
homeDirectory: /home/xuser2
b.
Make sure that the file /etc/nsswitch.conf specifies ldap for group service:
cat /etc/nsswitch.conf
:
:
group: files ldap
:
:
2.5 Postinstallation configuration tasks
93
c.
Verify:
# grget -n xgroup1
xgroup1:*:999: xuser2
If xuser2 shows up as a member of xgroup1, then your setup is correct.
10. The following applies to Windows ADS environments only:
If you have configured a multi-domain setup and you want to verify it, execute the following
two steps. Otherwise, proceed to Section 3.5.5 (page 157).
The following steps will verify that LDAP-UX is able to retrieve data from ADS multiple domains:
a.
b.
Create or import a POSIX user account into an ADS remote domain (for example, the
user account smith, this is identical to how you set it up for a single domain, except
now you put it into a remote domain).
If pwget -n smith returns valid data, LDAP-UX is working with ADS multiple domains.
If no data was returned, the setup was not successful.
2.5.3 Enabling AutoFS support
AutoFS is a client-side service that automatically mounts appropriate file systems when users request
access to them. If an automounted file system has been idle for a period of time, AutoFS unmounts
it. AutoFS uses name services such as files or NIS to store and manage AutoFS maps.
LDAP-UX Client Services supports the automount service under the AutoFS subsystem. This feature
enables users to store AutoFS maps in an LDAP directory server.
2.5.3.1 Automount schemas
This section describes the following automount schemas:
•
automount schema based on RFC 2307-bis
•
nisObject automount schema
LDAP-UX Client Services supports the automount schema based on RFC 2307-bis. The nisObject
automount schema may also be used if configured using attribute mappings. The autosetup
program installs the correct schema. No adjustments are necessary when using autosetup.
2.5.3.1.1 automount schema based on RFC 2307-bis
This schema defines automountMap and automount structures to represent AutoFS maps and
their entries in the LDAP directory. AutoFS maps are stored in the LDAP directory server using
structures defined by this schema.
The RFC 2307-bis automount schema is included with HP-UX Directory Server by default. If you
are installing LDAP-UX with a different directory server, the setup program will import this
automount schema into your directory server. If you previously configured LDAP-UX B.03.30 or a
previous version, and are now updating the product to version B.04.00 or later, you must rerun
the setup program to import this automount schema into the LDAP directory. The subsequent client
systems do not need to rerun the setup program.
The following shows the RFC 2307-bis automount schema in the LDIF format:
objectClasses: ( 1.3.6.1.1.1.2.16
NAME 'automountMap'
DESC 'Automount Map information'
SUP top STRUCTURAL
MUST automountMapName
MAY description
X-ORIGIN 'user defined' )
objectClasses: ( 1.3.6.1.1.1.2.17
NAME 'automount'
94
Installing and configuring LDAP-UX Client Services for an HP server environment
DESC 'Automount information'
SUP top STRUCTURAL
MUST ( automountKey $ automountInformation )
MAY description
X-ORIGIN 'user defined' )
attributeTypes: ( 1.3.6.1.1.1.1.31
NAME 'automountMapName'
DESC 'automount Map Name'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE
X-ORIGIN 'user defined' )
attributeTypes: ( 1.3.6.1.1.1.1.32
NAME 'automountKey'
DESC 'Automount Key value'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE
X-ORIGIN 'user defined' )
attributeTypes: ( 1.3.6.1.1.1.1.33
NAME 'automountInformation'
DESC 'Automount information'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE
X-ORIGIN 'user defined' )
For the HP-UX Directory Server, each entry starting with the text "attributetypes:" or
"objectclasses:" must be one continuous line.
Example of a direct AutoFS map based on the RFC 2307-bis automount schema
The following shows an example of a direct AutoFS map, auto_direct, stored in the LDAP
directory server, using the RFC 2307-bis automount schema:
dn:automountMapName=auto_direct,dc=nishpind
objectClass: top
objectClass: automountMap
automountMapName: auto_direct
dn:automountKey=/mnt_direct/test1,\
automountMapname=auto_direct, dc=nishpind
objectClass: top
objectClass: automount
automountInformation:hostA:/tmp
automountKey: /mnt_direct/test1
dn:automountKey=/mnt_direct/test2,\
automountMapname=auto_direct, dc=nishpind
objectClass: top
objectClass: automount
automountInformation:hostB:/tmp
automountKey:/mnt_direct/test2
2.5.3.1.2 nisObject automount schema
The nisObject automount schema defines nisMap and nisObject structures to represent the
AutoFS maps and their entries. The AutoFS maps are stored in the LDAP directory server using the
nisMap and nisObject structures. There are some limitations that you need to be aware of
when using the nisObject automount schema.
Example of a direct AutoFS map based on the nisObject automount schema
The following shows an example of a direct AutoFS map, auto_direct, stored in the LDAP
directory server using the nisObject automount schema:
2.5 Postinstallation configuration tasks
95
dn:nisMapName=auto_direct,dc=nishpind
objectClass: top
objectClass: nisMap
nisMapName: auto_directdn:cn=/mnt_direct/test1,
nisMapName=auto_direct, dc=nishpind
objectClass: top
objectClass: nisObject
nisMapName: auto_direct
cn: /mnt_direct/test1
nisMapEntry:hostA:/tmp
dn:cn=/mnt_direct/test2, nisMapname=auto_direct, dc=nishpind
objectClass: top
objectClass: nisObject
nisMapName: auto_direct
cn: /mnt_direct/test2
nisMapEntry:hostB:/tmp
nisObject limitations
The nisObject automount schema contains three attributes: cn, nisMapEntry and nisMapName.
When this schema is used, the case (lowercase or uppercase characters) is not significant; LDAP
ignores case-matching for these attributes. Consider the following example showing a partial DN:
# an indirect map named auto_test
test1
server1:/source
TEST1
server2:/source
LDAP considers the two entries redundant; it considers the second entry (cn=TEST1,
nisMapName=auto_test) a redefinition of the first (cn=test1, nisMapName=auto_test).
In other words, if two keys have names that differ only by case (such as cn=TEST1 and cn=test1),
then only one of those entries will be retrieved.
Therefore, if you use the nisObject automount map schema, do not define multiple keys that
differ only in case (lowercase characters versus uppercase).
2.5.3.2 Attribute mappings between RFC 2307-bis and nisObject schema
LDAP-UX Client Services supports attribute mappings between the RFC 2307-bis automount schema
and the nisObject automount schema. This feature enables the directory administrators to continue
using the nisObject schema if they have already deployed it.
If both the RFC 2307-bis automount schema and the nisObject schema exist in the LDAP directory
server, and you choose to use the nisObject automount schema, you must run the setup program
using the custom configuration to:
•
Remap the RFC 2307-bis automount attributes to the nisObject automount attributes. The
attribute mappings are done in step 10 of the Custom Configuration. For detailed information
on how to remap the automount attributes, see Section 2.4.5.2 (page 72).
Table 10 (page 96) shows the attribute mappings:
Table 10 Mappings between RFC 2307-bis and nisObject automount attributes
•
96
RFC 2307-bis Automount Attribute
nisObject Automount Attribute
automountMapname
nisMapname
automountKey
cn
automountInformation
nisMapEntry
Change the automount search filter for the automount service to the nisObjectsearch
filter. LDAP-UX Client Services uses the automount search filter for the automount service as
a default. The search filter change can be done in step 11 of the Custom Configuration. For
Installing and configuring LDAP-UX Client Services for an HP server environment
information about configuring the nisObject search filter for the automount service to search
a different location in the LDAP directory server, see Section 2.4.5.2 (page 72).
If you want to perform attribute mappings or search filter changes by using the Custom
Configuration, ensure that you do not accept the remaining default configuration parameters in
step 4 of the Custom Configuration.
NOTE: You may use the nisObject automount schema without attribute mappings and search
filter changes if only the nisObject automount schema exists in the LDAP directory.
2.5.3.3 Configuring NSS to enable LDAP support for AutoFS
Configure NSS to enable the LDAP support for AutoFS.
You can save a copy of /etc/nsswitch.conf file and modify the original to add LDAP support
to the automount service, as shown in bold in the /etc/nsswitch.ldap example that follows.
See /etc/nsswitch.ldap for another sample.
passwd:
group:
hosts:
networks:
protocols:
rpc:
publickey:
netgroup:
automount:
aliases:
services:
files ldap
files ldap
dns files ldap
files
files
files
ldap [NOTFOUND=return] files
files
files ldap
files
files
2.5.3.4 Configuring automount caches
To improve performance of automount services, the ldapclient daemon, ldapclientd, caches
automount maps and automount entries in the maps to reduce the LDAP-UX client response time
while retrieving information for automount maps and entries.
To configure automount caches, set the parameters defined in the [automountMap] and
[automount] sections of the /etc/opt/ldapux/ldapclientd.conf file. For more
information, see Section 7.1.3 (page 184).
2.5.3.5 AutoFS migration scripts
This section describes the migration scripts that can be used to migrate your AutoFS maps from
files or NIS servers to LDIF files. After LDIF files are created, you can use the ldapmodify tool to
import LDIF files to your LDAP directory server. These migration scripts use the automount schema
defined in RFC 2307-bis to migrate the AutoFS maps to LDIF. You must import the automount
schema into your LDAP directory server before you use these migration scripts to migrate AutoFS
maps.
Table 11 (page 97) describes the migration scripts:
Table 11 AutoFS Migration scripts for HP directory servers
Migration Script
Description
migrate_automount.pl
Migrates AutoFS maps from files to LDIF.
migrate_nis_automount.pl
Migrates AutoFS maps from the NIS server to LDIF.
migrate_nisp_autofs.pl
Migrates AutoFS maps from NIS+ server to the
nisp_automap.ldif file. As of LDAP-UX Client Services B.05.01,
NIS+ is no longer supported.
2.5 Postinstallation configuration tasks
97
2.5.3.5.1 Environment variables
When you use the AutoFS migration scripts to migrate AutoFS maps, set the following environment
variables:
LDAP_BASEDN
The base distinguished name of the LDAP directory that the AutoFS maps
are to be placed in.
DOM_ENV
This only applies to the migrate_nisp_autofs.pl script. This variable
defines the fully qualified name of the NIS+ domain where you want to
migrate your data from. As of LDAP-UX Client Services B.05.01, NIS+ is
no longer supported.
NIS_DOMAINNAME
This only applies to the migrate_nis_automount.pl script. This variable
specifies the fully qualified name of the NIS domain where you want to
migrate your data from. This variable is optional. If the NIS domain name
is not specified, LDAP-UX uses the value of the NIS_DOMAIN parameter
configured in the /etc/rc.conf.d/namesvrs file.
Examples
The following command sets the fully qualified name of the NIS domain to "india.hp.com":
export NIS_DOMAINNAME="india.hp.com"
The following command sets the base DN to "dc=cup, dc=hp, dc=com":
export LDAP_BASEDN="dc=cup, dc=hp, dc=com"
2.5.3.5.2 General syntax for migration scripts
The migration scripts use the following general syntax:
scriptname
inputfile outfile
where
scriptname
Is the name of the particular script you are using.
inputfile
Is the fully qualified file name of the appropriate AutoFS map that you want to
migrate. For example, /etc/auto_master.
outputfile
This only applies to the migrate_nis_automount.pl and
migrate_automount.pl scripts. This is optional and is the name of the file
where the LDIF is written. stdout is the default output.
2.5.3.5.3 migrate_automount.pl script
This script, found in /opt/ldapux/migrate, migrates the AutoFS maps from files to LDIF.
Syntax
scriptnameinputfileoutputfile
Examples
The following commands migrate the AutoFS map /etc/auto_direct to LDIF and place the
results in the /tmp/auto_direct.ldif file:
export LDAP_BASEDN="dc=nishpind"
migrate_automount.pl /etc/auto_direct /tmp/auto_direct.ldif
The following shows the /etc/auto_direct file:
#local mount point
/mnt/direct/lab1
/mnt/direct/lab2
remote server:directory
hostA:/tmp
hostB:/tmp
The following shows the /tmp/auto_direct.ldif file:
dn:automountMapName=auto_direct,dc=nishpind
objectClass: top
98
Installing and configuring LDAP-UX Client Services for an HP server environment
objectClass: automountMap
automountMapName: auto_direct
dn:automountKey=/mnt_direct/lab1,\ automountMapname=auto_direct, dc=nishpind
objectClass: top
objectClass: automount
automountInformation:hostA:/tmp
automountKey: /mnt_direct/lab1
dn:automountKey=/mnt_direct/lab2,\
automountMapname=auto_direct, dc=nishpind
objectClass: top
objectClass: automount
automountInformation:hostB:/tmp
automountKey:/mnt_direct/lab2
You can use the /opt/ldapux/bin/ldapmodify tool to import the LDIF file /tmp/
auto_direct.ldif that you just created in the LDAP directory. For example, the following
command imports the /tmp/auto_direct.ldif file to the LDAP base DN "dc=nishpind" in
the LDAP directory server LDAPSERV1:
/opt/ldapux/bin/ldapmodify -a -h LDAPSERV1 -D "cn=Directory Manager" -w <passwd> -f /tmp/auto_direct.ldif
where options are:
-a
Adds a new entry into the LDAP directory
-h
Specifies the LDAP directory host name
-D
Specifies the Distinguish Name (DN) of the directory manager
-w
Specifies the password of the directory manager
-f
Specifies the LDIF file to be imported into the LDAP directory
2.5.3.5.4 migrate_nis_automount.pl script
This script, found in /opt/ldapux/migrate, migrates the AutoFS maps from the NIS server to
LDIF.
Syntax
scriptname inputfile outputfile
Examples
The following commands migrate the AutoFS map /etc/auto_indirect to LDIF and place the
results in the /tmp/auto_indirect.ldif file:
export LDAP_BASEDN="dc=nisserv1"
export NIS_DOMAINNAME="cup.hp.com"
migrate_nis_automount.pl /etc/auto_indirect
/tmp/auto_indirect.ldif
The following shows the /etc/auto_indirect file:
#local mount point
lab1
lab2
remote server:directory
hostA:/tmp
hostB:/tmp
The following shows the /tmp/auto_indirect.ldif file:
dn:automountMapName=auto_indirect,dc=nisserv1
objectClass: top
objectClass: automountMap
automountMapName: auto_indirect
dn:automountKey=lab1,\
automountMapname=auto_indirect, dc=nisserv1
objectClass: top
objectClass: automount
2.5 Postinstallation configuration tasks
99
automountInformation:hostA:/tmp
automountKey: lab1
dn:automountKey=lab2, \
automountMapname=auto_indirect, dc=nisserv1
objectClass: top
objectClass: automount
automountInformation:hostB:/tmp
automountKey:lab2
You can use the /opt/ldapux/bin/ldapmodify tool to import into the LDAP directory the LDIF
file /tmp/auto_indirect.ldif that you just created. For example, the following command
imports the /tmp/auto_indirect.ldif file to the LDAP base DN "dc=nisserv1" in the LDAP
directory server LDAPSERV1:
/opt/ldapux/bin/ldapmodify -a -h LDAPSERV1 -D "cn=Directory Manager"
-w <passwd> -f /tmp/auto_indirect.ldif
2.5.3.5.5 migrate_nisp_autofs.pl script
This script, found in /opt/ldapux/migrate/nisplusmigration, migrates the AutoFS maps
from the NIS+ server to the nisp_automap.ldif file. As of LDAP-UX Client Services B.05.01,
NIS+ is no longer supported.
Syntax
scriptname inputfile
Examples
The following commands migrate the AutoFS map /etc/auto_indirect to LDIF and place the
results in the nisp_automap.ldif file:
export LDAP_BASEDN="dc=nishpbnd"
export DOM_ENV ="cup.hp.com"
migrate_nisp_autofs.pl /etc/auto_indirect
The following shows the /etc/auto_indirect file:
#local mount point
lab1
lab2
remote server:directory
hostA:/tmp
hostB:/tmp
The following shows the nisp_automap.ldif file:
dn:automountMapName=auto_indirect,dc=nishpbnd
objectClass: top
objectClass: automountMap
automountMapName: auto_indirect
dn:automountKey=lab1, \
automountMapname=auto_indirect, dc=nishpbnd
objectClass: top
objectClass: automount
automountInformation:hostA:/tmp
automountKey: lab1
dn:automountKey=lab2, \
automountMapname=auto_indirect, dc=nishpbnd
objectClass: top
objectClass: automount
automountInformation:hostB:/tmp
automountKey:lab2
You can use the /opt/ldapux/bin/ldapmodify tool to import into the LDAP directory the LDIF
file nisp_automap.ldif that you just created. For example, the following command imports
the nisp_automap.ldif file to the LDAP base DN "dc=nishpbnd" in the LDAP directory server
LDAPSERV1:
100 Installing and configuring LDAP-UX Client Services for an HP server environment
/opt/ldapux/bin/ldapmodify -a -h LDAPSERV1 -D "cn=Directory Manager"
-w <passwd> -f nisp_automap.ldif
2.5.4 Enabling offline longterm credential caching for authentication when the
directory server is unavailable
Supported for HP directory server environments only.
If contact with the directory server is lost because of a network problem or server crash, LDAP users
cannot log in to the system. This might have a negative impact on the OS and its applications,
especially for mission-critical applications. To enable the OS to continue to properly function when
connection with the directory server is lost, LDAP-UX Client Services 5.0 (or later) provides an
offline credential cache that enables LDAP to continue authenticating users even when contact with
all directory servers is lost. You can enable this feature by configuring several parameters available
in the LDAP-UX client daemon configuration file, /etc/opt/ldapux/ldapclientd.conf file.
NOTE: For information about patches that must be installed to support offline credential caching,
see the LDAP-UX Integration Release Notes.
2.5.4.1 How the offline cache works
To support this feature, you can configure LDAP-UX to maintain a secondary (offline) long-term
cache that stores previously-discovered user account and group information, including authentication
passwords that are hashed using the salted Secure Hash Algorithm (SHA-512). If the directory
server becomes unavailable, LDAP-UX resorts to this cache for the information needed to authenticate
users. When the directory server becomes available again, LDAP-UX resumes referring to the
directory server for authentication information.
While LDAP-UX is in contact with the directory server, if long-term credential caching is enabled,
LDAP-UX captures user account and password information during a user's login attempt, and if the
login is successful, stores this information in the offline cache. LDAP-UX updates the cache as
necessary with new or changed account information as it becomes available during later
authentication attempts. It also updates passwords that are successfully changed by users on the
local host.
When the directory server is unreachable, LDAP-UX does not allow users to change their passwords
(because the password cannot be updated in the directory server).
The offline cache maintains information only for users who have recently logged in to the system
while the directory server was available.
The offline credential cache will survive after a reboot. However, data stored in the cache has a
configurable expiration date (two weeks, by default) to help ensure that stale user accounts are
removed. Because the long-term credential cache expires after a defined period, any user that has
not recently used the system (within the expiration period defined by the LDAP-UX administrator)
is not allowed to authenticate, since that user's cached credential might not exist or might have
been removed after it expired.
LDAP-UX allows you to enable long-term enumeration, in which case LDAP-UX periodically retrieves
and updates all user and group entries in the local on-disk storage for later reference when the
directory server is not reachable. You can specify how frequently LDAP-UX should refresh the
enumeration data in the cache.
NOTE: Enumeration requests involving large databases could reduce network and server
performance. Use this feature only if it is expedient for your environment.
LDAP-UX also allows you to specify:
•
How frequently long-term data should be saved to the offline cache
2.5 Postinstallation configuration tasks
101
•
How much memory to allocate for the offline cache (if you have numerous groups containing
a large number of members, HP recommends that the amount of offline cache memory allocated
be twice the combined size of the groups)
2.5.4.2 Configuring the offline cache
The following shows the section in /etc/opt/ldapux/ldapclientd.conf that includes the
offline credential cache variables that you can configure.
[longterm_cache]
#enable=no
#
# How long before data is considered stale and not usable. 1,209,600 = 2 weeks
#longterm_expired_interval=1209600
#
# How frequently should save long term data to permanent storage. 900 = 15 min.
#longterm_cache_backup_interval=900
#
# How much memory to allocate for the long term cache, which stores user and
# group information. This cache is only used by the working set of users and
# groups. The working set means any user or group being used or displayed on
# the system. If you have numerous large groups with numerous members, this
# value should be at least twice as large as the combined size of all those
# groups.
#longterm_cache_size=50000000
#
# Should long term caching support enumeration of users and groups. If
# getpwent() and getgrent() are not required, this can be disabled.
#longterm_enum_enable=no
#
# How frequently should the HP-UX client go to the directory server to refresh
# the enumeration cache. 84600 = once per day.
#longterm_enum_search_interval=86400
As shown, offline credential caching is disabled by default. To enable offline credential caching,
uncomment the first line of the section (remove the pound sign (#)) and specify yes instead of no
as shown:
[longterm_cache]
enable=yes
#
Configure the other parameters as noted in the comments included with the configuration file. To
keep the default settings, you can leave the lines as they are (without removing the pound signs
that precede each line that defines a parameter).
NOTE: Offline credential caching and integrated Compat Mode cannot be used together. Compat
Mode is discussed in Section 2.5.5 (page 102).
2.5.5 Enabling integrated Compat Mode to control name services and user logins
Supported for HP directory server environments only.
LDAP-UX version 5.0 and later makes available traditional NIS-style Compat (Compatibility) Mode
to control the name services that are used to obtain user and group information.
2.5.5.1 Overview
A legacy feature of NIS is the ability to allow local control of network-defined passwd entries.
Administrators of NIS clients can select which accounts would be available on the local host by
specifying lists of netgroups in the host’s /etc/passwd file. For more information, see Appendix
C of the Network Information Service (NIS) Administrator's Guide . The following example shows
how an administrator might limit logins on the local host to members of the operator and
webadmin groups. Within the /etc/passwd file, the following entries would be added:
...
+@operator::::::
102 Installing and configuring LDAP-UX Client Services for an HP server environment
+@webadmin::::::
...
While this feature was typically used to control which groups of users could log in to a particular
host, it also could be used to obscure or override fields of a user’s passwd entry. For example,
an administrator could force a particular group of users to use a specific login shell by inserting
the desired path to the desired login shell in the 7th field of the entry (the login shell is positionally
defined as the 7th field in each entry in the /etc/passwd file.):
...
+@icsuteam::::::/usr/local/bin/supportapp
...
+:x
In the previous example, any user that is a member of the icsuteam will be forced to run the
supportapp upon login to the system, regardless of how their personal login shell is defined in
the NIS passwd map. The +:x as the last line of the /etc/passwd file indicates that all remaining
accounts managed in the NIS passwd map will be visible on the system, but their passwords will
be masked with an x, which traditionally would prevent login.
2.5.5.2 Netgroups in LDAP
With LDAP, the ability to use netgroups to control which groups of users are visible on a host, or
which fields are masked, is still available. System administrators can enable NIS Compat Mode
by defining the following sequence in the /etc/nsswitch.conf file:
...
passwd: compat
passwd_compat: files ldap
...
The first line indicates that the passwd name service should operate in the traditional Compatibility
Mode, allowing netgroups to be specified in the /etc/passwd file. The second line indicates
that the files and LDAP repositories should be used as the name service repository for finding the
user accounts referenced by those netgroups.
However, use of Compat Mode with an LDAP repository can greatly impact performance of the
name service system. When Compat Mode is used to mask passwd entries, numerous requests to
the directory server must be generated to examine the netgroups to find their members and then
search for each individual member. While ldapclientd can cache netgroup and passwd
entries, the name service subsystem does the actual processing to generate the proper masked
results. In this case, while caching does improve performance, it places an extreme load on the
CPU from the ldapclientd caching daemon, as it resolves the numerous requests from the name
service subsystem.
Most deployments use Compat Mode just to control which users are allowed to log in to the host.
In this case, the libpam_authz library can be used to control which users can log in to the host,
based on the netgroups listed in the /etc/passwd file. (For more information about using
PAM_AUTHZ login authorization and libpam_authz, see Section 7.4 (page 199).) Compat Mode
can therefore be disabled. However, for deployments that rely on the field-masking feature of
Compat Mode, no alternative was available. In these situations, if a large organization used
numerous netgroups with many users, CPU usage of ldapclientd could reach maximum limits.
As a means to greatly mitigate the performance impacts of Compat Mode field masking, LDAP-UX
has integrated Compat Mode support directly into ldapclientd, allowing caching of Compat
Mode user entries.
2.5.5.3 Configuring integrated Compat Mode
To enable integrated Compat Mode, you must perform four configuration steps:
1.
Disable Compat Mode in the name service switch. In the /etc/nsswitch.conf file, replace
the following:
2.5 Postinstallation configuration tasks 103
...
passwd: compat
passwd_compat: files ldap
...
with:
...
passwd: files ldap
...
2.
Configure internal Compat Mode processing inside ldapclientd:
a. /etc/opt/ldapux/ldapclientd.conf
Search for "flush_compat_info_time". This indicates how often ldapclientd will
refresh its cached copy of the netgroup structures defined in the /etc/passwd file. If
you make changes to the netgroup list in the /etc/passwd file, these changes will not
appear until this time period has passed or you have restarted or flushed the caches of
ldapclientd (-F). Adjust this value as needed, or leave as the default (1 day).
b.
/etc/opt/ldapux/ldapux_client.conf
Search for "enable_compat_mode". To enable internal Compat Mode processing in
ldapclientd, set this value to 1.
NOTE: If LDAP-UX has been configured previously on your host, you must examine the newly
delivered configuration files found under /opt/ldapux/newconfig/etc/opt/ldapux.
Compare and merge the existing configuration files with those delivered in the newconfig
subdirectory.
3.
Restart ldapclientd. Use the following commands:
# /opt/ldapux/bin/ldapclientd -k
# /opt/ldapux/bin/ldapclientd
4.
If you change the netgroup list in the /etc/passwd or /etc/group, and want to force
ldapclientd to reflect the updated configuration, force ldapclientd to rebuild its cache
with the following command:
# /opt/ldapux/bin/ldapclientd -f
2.5.5.3.1 Limitations
When processing netgroup information for Compat Mode (that is, +@<netgroup>,
-@<netgroup> in /etc/passwd), internal Compat Mode processing in ldapclientd always
searches the LDAP directory first for definition of the netgroup entries and then the local /etc/
netgroup file. As a result, if the same network group with different group members is configured
in both /etc/netgroup and the LDAP directory, the members defined in the netgroup stored in
the LDAP directory will be used instead of the entries from the local /etc/netgroup file.
HP recommends that you do not configure netgroups with the same name in both the /etc/
netgroup file and the LDAP directory.
Also, long-term offline credential caching and integrated Compat Mode cannot be used together.
Long-term offline credential caching is discussed in Section 2.5.4 (page 101).
2.5.6 Controlling user access to the system through LDAP
By default, all users stored in the LDAP directory are allowed to log in to the local HP-UX client
system. LDAP-UX provides several ways to increase the security level to prevent unwanted users
from logging in to the local system through LDAP, including the following:
•
Using the PAM_AUTHZ service module to control login access, as described elsewhere, in
Section 7.4 (page 199)
104 Installing and configuring LDAP-UX Client Services for an HP server environment
•
Disabling logins to the local system from specified LDAP users by configuring the
disable_uid_range flag in the local client's startup file (/etc/opt/ldapux/
ldapux_client.conf), as described in Section 2.5.6.1 (page 105)
•
Preventing unwarranted access to the local system by users defined in the LDAP directory
server that have equivalent user names or user identification numbers (UIDs) in the local system
/etc/passwd file, as described in Section 2.5.6.2 (page 105) (this feature is not supported
for Windows ADS)
•
Using the ignore option to enable specified users to be ignored by PAM_LDAP authentication,
as described in Section 2.5.6.3 (page 108) (this feature is not supported for Windows ADS)
2.5.6.1 Using the disable login flag to prevent access to the local system by unwanted users
To disallow specific users to log in to a local system, you can set the disable login flag
disable_uid_range in the local client's startup file/etc/opt/ldapux/
ldapux_client.conf. The flag is in the [NSS] section of the file. (HP recommends that you
do not edit the [profile] section of the file.) The following example shows the portion of the
file containing the flag:
#
# You can disable specific users so that they are unable to log in
# through the LDAP server by uncommenting the "disable_uid_range"
# flag and adding the UID numbers you want to disable. For example:
#
#
disable_uid_range=0-100,120,300-400
#
# Note: The list of UID numbers must be on one line and the maximum
# number of ranges is 20. The system will ignore the typos and white spaces.
#
#disable_uid_range=0
To enable and configure the flag, first save a copy of the /etc/opt/ldapux/
ldapux_client.conf file and edit the original. Then uncomment the flag (remove the #) and
enter the UID ranges. For example, the flag might look like this:
disable_uid_range=0-100, 300-450, 89
Another common example would be to disable root access, in which case the flag would look like
this: disable_uid_range=0.
NOTE:
•
White spaces between numbers are ignored.
•
Only one line of the list is accepted; however, the line can be wrapped.
•
The maximum number of ranges is 20.
When the disable_uid_range is turned on, the disabled UIDs are not displayed when you run
commands such as pwget, listusers, and logins.
NOTE: The passwd command may still allow you to change a password for a disabled user
when alternative authentication methods that are not controlled by LDAP (such as PAM Kerberos)
are used.
2.5.6.2 Using the deny_local option to prevent access to the local system by unwanted users
Supported for HP directory server environments only.
LDAP-UX version 4.2 and later provides a simple and effective way to disable system access for
local user accounts that are also defined in the LDAP directory server. Without this level of security
protection, an LDAP-UX user with the same user name or account number (UID) as a user defined
in the local system's /etc/passwd file, could illegitimately gain access to the local system. For
example, if the root user is defined in the local system's /etc/passwd file, an LDAP-UX directory
2.5 Postinstallation configuration tasks 105
server administrator could create a user named “root” and then log in to the local system based
on the password associated with user “root” on the directory server.
To disable system access for local user accounts that are also defined in the LDAP directory server,
configure the deny_local option in the PAM configuration file /etc/pam.conf, entering a line
for each service, in the following format:
service module_type required libpam_ldap.so.1 deny_local
where:
service
Specifies the service used for accessing the system
module_type
Specifies the service module authentication type (test category):
authentication (auth), account management (account), session
management (session), or password management (password). Typically,
the deny_local option is specified for both authentication and account
management, and for all PAM-enabled services.
required
Specifies the control flag as required (mandatory), which means the test
for the module must succeed; authentication for any modules/libraries
listed after it must also be satisfied. (In contrast, the sufficient flag
indicates that if authentication is satisfied for the flagged module, the
user is authenticated successfully; no further tests are performed.)
libpam_ldap.so.1
Specifies the pathname to the PAM_LDAP library object that implements
the service functionality. If the pathname is not absolute, it is assumed
to be relative to /usr/lib/security/$ISA/.
deny_local
Specifies the deny_local option
The following example shows the portion of the /etc/pam.conf file that configures the
authentication and account services. As a result, for any attempt to use these services to log in or
establish a session on the HP-UX client system, if PAM_LDAP detects an equivalent account name
or UID in the /etc/passwd file, it returns PAM_IGNORE (PAM_LDAP does not authenticate the
user). If an equivalent account name or UID is not found in the /etc/passwd file, PAM_LDAP
returns the appropriate authentication status (which could be, for example, notification that the
credential is invalid, the password needs to be updated, or that the authentication succeeded; the
status reported depends on the circumstances when the user tries to authenticate).
For more information about PAM, see the pam(3) and pam.conf(4) manpages, and the Managing
Systems and Workgroups: A Guide for HP-UX System Administrators document at the following
location:
http://www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
#
# PAM configuration
#
# This pam.conf file is intended as an example only.
#
# Please note that this configuration file has only been modified for the
# default services. Other services can be added or modified as
# needed or desired. If a service is not listed, it will use the
# OTHER classification
#
# the format for a entry is
# <service> <module_type> <control> <module path> <options>
#
#Notes:
#
# If the path to a library is not absolute, it is assumed to be relative
# to the directory /usr/lib/security/$ISA/
#
# The "$ISA" (i.e Instruction Set Architecture) token is replaced by the
106 Installing and configuring LDAP-UX Client Services for an HP server environment
# PAM engine (libpam) with "hpux64" for IA 64-bit modules, or with "hpux32"
# for IA 32-bit modules, or with "pa20_64" for PA 64-bit modules, or with
# NULL for PA 32-bit modules.
#
# For PA applications, library name ending with "so.1" is a symbolic link
# that points to the corresponding PA (32 or 64-bit) backend library.
#
# see pam.conf(4) for more details
#
# Authentication management
#
login
auth required
libpam_hpsec.so.1
login
auth sufficient
libpam_unix.so.1
login
auth required
libpam_ldap.so.1 try_first_pass deny_local
su
auth required
libpam_hpsec.so.1 bypass_setaud
su
auth sufficient
libpam_unix.so.1
su
auth required
libpam_ldap.so.1 try_first_pass deny_local
dtlogin auth required
libpam_hpsec.so.1
dtlogin auth sufficient
libpam_unix.so.1
dtlogin auth required
libpam_ldap.so.1 try_first_pass deny_local
dtaction auth required
libpam_hpsec.so.1
dtaction auth sufficient
libpam_unix.so.1
dtaction auth required
libpam_ldap.so.1 try_first_pass deny_local
ftp
auth required
libpam_hpsec.so.1
ftp
auth sufficient
libpam_unix.so.1
ftp
auth required
libpam_ldap.so.1 try_first_pass deny_local
rcomds
auth required
libpam_hpsec.so.1
rcomds
auth sufficient
libpam_unix.so.1
rcomds
auth required
libpam_ldap.so.1 try_first_pass deny_local
sshd
auth required
libpam_hpsec.so.1
sshd
auth sufficient
libpam_unix.so.1
sshd
auth required
libpam_ldap.so.1 try_first_pass deny_local
OTHER
auth required
libpam_hpsec.so.1
OTHER
auth sufficient
libpam_unix.so.1
OTHER
auth required
libpam_ldap.so.1 try_first_pass deny_local
#
# Account management
#
login
account required
libpam_hpsec.so.1
login
account sufficient
libpam_unix.so.1
login
account required
libpam_ldap.so.1 deny_local
su
account required
libpam_hpsec.so.1
su
account sufficient
libpam_unix.so.1
su
account required
libpam_ldap.so.1 deny_local
dtlogin account required
libpam_hpsec.so.1
dtlogin account sufficient
libpam_unix.so.1
dtlogin account required
libpam_ldap.so.1 deny_local
dtaction account required
libpam_hpsec.so.1
dtaction account sufficient
libpam_unix.so.1
dtaction account required
libpam_ldap.so.1 deny_local
ftp
account required
libpam_hpsec.so.1
ftp
account sufficient
libpam_unix.so.1
ftp
account required
libpam_ldap.so.1 deny_local
rcomds
account required
libpam_hpsec.so.1
rcomds
account sufficient
libpam_unix.so.1
rcomds
account required
libpam_ldap.so.1 deny_local
sshd
account required
libpam_hpsec.so.1
sshd
account sufficient
libpam_unix.so.1
sshd
account required
libpam_ldap.so.1 deny_local
OTHER
account required
libpam_hpsec.so.1
OTHER
account sufficient
libpam_unix.so.1
OTHER
account required
libpam_ldap.so.1 deny_local
#
.
2.5 Postinstallation configuration tasks 107
.
.
2.5.6.3 Configuring PAM_LDAP authentication to ignore specific users
Supported for HP directory server environments only.
When PAM_LDAP is configured to be the first service module in the /etc/pam.conf file (a typical
configuration in the Trusted Mode Environment), then if you lose access to your directory server,
you might have difficulty accessing the system again unless you are included in a set of so-called
“recovery users” configured in the /etc/pam_user.conf file. LDAP-UX 5.0 (and later) supports
the ignore option for PAM_LDAP, which you can configure in pam_user.conf for specific users
(such as root). This feature enables the specified users to be ignored for authentication by PAM_LDAP
(PAM returns PAM_IGNORE). LDAP-UX supports this feature in both Standard Mode and Trusted
Mode.
The /etc/pam_user.conf file is an optional user configuration file for PAM. It is used only
when a user-based configuration is needed. It mainly specifies options used by service modules
for specific users. The options defined in /etc/pam.conf specify the default for users who are
not configured in /etc/pam_user.conf or for users without a module type configured for them.
The /etc/pam.conf file is required for PAM to work properly.
To configure the ignore option, perform the following steps:
1.
For each user that you want bypassed by PAM authentication, enter a line in the /etc/
pam_user.conf file, using the following format:
user module_type libpam_ldap.so.1 ignore
where:
user
Specifies the user to be ignored by PAM_LDAP authentication
module_type
Specifies the service module authentication type (test category):
authentication (auth), account management (account), session
management (session), or password management (password).
libpam_ldap.so.1
Specifies the pathname to the PAM_LDAP library object that
implements the service functionality. If the pathname is not absolute,
it is assumed to be relative to /usr/lib/security/$ISA/.
ignore
Specifies the ignore option.
The following is an example of a pam_user.conf file, showing the ignore option specified
for user root under authentication management, account management, session management,
and password management. As a result, when user root attempts to log in to the directory
server, the PAM_LDAP module does not authenticate the user root; it just returns PAM_IGNORE.
################################################################
# /etc/pam_user.conf
#
# Sample configuration for using the ignore option for PAM_LDAP#
# for user root.
#
# The format for a entry is
#
# <user> <module type> <module path> <options>
#
#
#
# See pam_user.conf(4) for more details.
#
#
#
#
#
# NOTE: If the path to a library is not absolute, it is assumed#
# to be relative to the directory /usr/lib/security/$ISA.
#
# The "$ISA (i.e Instruction Set Architecture) token is
#
# replaced by the PAM engine (libpam) with "hpux64" for IA
#
# 64-bit modules, or with "hpux32" for IA 32-bit modules, or
#
# with "pa20_64" for PA 64-bit modules, or with NULL for PA
#
# 32-bit modules.
#
# For PA applications, library name ending with "so.1" is a
#
# symbolic link that points to the corresponding PA (32 or 64 #
108 Installing and configuring LDAP-UX Client Services for an HP server environment
# bit) backend library.
#
################################################################
root
root
root
root
auth
account
session
password
libpam_ldap.so.1
libpam_ldap.so.1
libpam_ldap.so.1
libpam_ldap.so.1
ignore
ignore
ignore
ignore
For more information, see the pam_user.conf(4) manpage. For more information about HP-UX
user authentication and PAM, see the HP-UX System Administrator's Guide: Security
Management, available at the following location:
www.hp.com/go/hpux-core-docs (click HP-UX 11i v3)
2.
Configure the PAM_UPDBE library (libpam_updbe) in the /etc/pam.conf file.
NOTE: You must configure this library in order for the configuration in /etc/
pam_user.conf to take effect.
PAM_UPDBE is the user policy definition service module for PAM. It reads options defined in
the user configuration file, /etc/pam_user.conf, and uses pam_set_data to store the
information in the PAM handle for use by subsequent service modules. In /etc/pam.conf,
configure the PAM_UPDBE library for each service module defined in /etc/pam_user.conf,
using the following format for each line entered:
user module_type required libpam_updbe.so.1
where:
user
Specifies the user to be ignored by PAM_LDAP authentication
module_type
Specifies the service module authentication type (test category):
authentication (auth), account management (account), session
management (session), or password management (password).
required
Specifies the control flag as required (mandatory, which means
the test for the module must succeed; authentication for any
modules/libraries listed after it must also be satisfied. (In contrast,
the sufficient flag indicates that if authentication is satisfied
for the flagged module, the user is authenticated successfully; no
further tests are performed.)
libpam_updbe.so.1
Specifies the pathname to the PAM_UPDBE shared library object
that implements the service functionality. If the pathname is not
absolute, it is assumed to be relative to /usr/lib/security/
$ISA/.
For more information, see the pam_updbe(5) and pam_user.conf(4) manpages.
If PAM_HPSEC has been configured in /etc/pam.conf for the service you are going to
define for PAM_UPDBE, configure the PAM_UPDBE library in the line immediately following
the line that configures the service's PAM_HPSEC library. If PAM_HPSEC is not configured for
the given service, configure the PAM_UPDBE library as the first service module in /etc/
pam.conf. In either case, set the control flag for the PAM_UPDBE library as required.
PAM_UPDBE provides interfaces for all four PAM service module types (authentication
management, account management, session management, and password management). Each
service module reads the options defined for its type.
The following example is a portion of a /etc/pam.conf file that defines the PAM_UPDBE
library for the user login process. Because the PAM_HPSEC library is configured for each
service module, the PAM_UPDBE library configuration line is added immediately following
the corresponding service's PAM_HPSEC library configuration line.
#
#
Authentication management
2.5 Postinstallation configuration tasks 109
login
auth required
login
auth required
login
auth sufficient
login
auth required
# Account management
#
login
account required
login
account required
login
account sufficient
login
account required
# Session management
#
login
session required
login
session required
login
session required
login
session required
# Password management
#
login
password required
login
password required
login
password sufficient
login
password required
libpam_hpsec.so.1
libpam_updbe.so.1
libpam_ldap.so.1
libpam_unix.so.1 try_first_pass
libpam_hpsec.so.1
libpam_updbe.so.1
libpam_ldap.so.1
libpam_unix.so.1
libpam_hpsec.so.1
libpam_updbe.so.1
libpam_ldap.so.1
libpam_unix.so.1
libpam_hpsec.so.1
libpam_updbe.so.1
libpam_ldap.so.1
libpam_unix.so.1 try_first_pass
For more information, see the pam.conf(4) and pam_updbe(5) manpages.
For more information, see the pam.conf(4) and pam_updbe(5) manpages, and the Managing
Systems and Workgroups: A Guide for HP-UX System Administrators document at the following
location:
http://www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
2.5.7 Configuring subsequent client systems
Once you have configured your directory and one client system, you may configure subsequent
client systems by performing the following steps. These steps are applicable to both HP directory
server and Windows ADS environments (readers of “Installing and configuring LDAP-UX Client
Services for a Windows ADS environment” (page 114) are referred to this section for information
about configuring subsequent client systems).
NOTE: If you used autosetup to create your LDAP-UX domain, you can configure subsequent
client systems by using autosetup; you can run autosetup in silent mode, as described in
Section 2.3.6.2 (page 57) (for an HP directory server environment) or Section 3.3.4.2 (page 127)
(for a Windows ADS environment).
Use the following steps only if you used setup. With autosetup, a unique proxy credential is
created for each host. The proxy credential (pcred) file is not supposed to be shared across hosts
in environments configured by autosetup.
1.
Use swinstall to install LDAP-UX Client Services on the client system. This does not require
rebooting the client system.
Alternatively, use the guided installaton (autosetup), for a simpler, automated process. If
you use autosetup, you may skip to the last step to verify the installation and configuration
on the client.
2.
110
Copy the following files from a configured client to the client being configured:
•
/etc/opt/ldapux/ldapux_client.conf
•
/etc/opt/ldapux/ldapux_profile.ldif
•
/etc/opt/ldapux/pcred only if you have configured a proxy user, not if you are
using only anonymous access (Windows ADS supports proxy bind access only)
Installing and configuring LDAP-UX Client Services for an HP server environment
•
/etc/pam.conf
•
/etc/nsswitch.conf
•
/etc/opt/ldapux/acred if the /etc/opt/ldapux/acred file exists
•
cert8.bd and key3.db files, if SSL is enabled
Set all file access mode permission to be the same as those of the first client being configured.
3.
Enable the LDAP-UX configuration profile as follows:
cd /opt/ldapux/config
./create_profile_cache
Alternatively you could interactively run the setup program to download the profile from the
directory and respond no when asked if you want to change the current configuration:
cd /opt/ldapux/config
./setup
If you are using multiple Windows domains, download profiles for the GCS and each remote
domain. For information about downloading these profiles, see Section 4.3 (page 160).
4.
If you are using a proxy user, configure and verify the proxy user by calling
ldap_proxy_config as follows:
cd /opt/ldapux/config
./ldap_proxy_config -v
5.
Verify the LDAP-UX Client Services installation and configuration on the client, as described
in Section 2.5.2 (page 91) (for an HP directory server environment) or Section 3.5.2 (page 152)
(for a Windows ADS environment).
2.5.8 Downloading the profile periodically
Using the setup program, you can define a time interval after which the current profile is
automatically refreshed. The start time for this periodic refresh is determined by the time the setup
program completes and the value defined for ProfileTTL. Therefore, setup does not allow
you to define a specific time of day when the profile should be downloaded (refreshed). For more
information, see the ldapclientd(1) manpage.
If you want to manually determine the time when the profile is downloaded, you can use the
following steps, which are applicable to both HP directory server and Windows ADS environments
(readers of “Installing and configuring LDAP-UX Client Services for a Windows ADS environment”
(page 114) are referred to this section for information about downloading profiles):
NOTE: This note pertains to Windows ADS environments only: Starting with the B.03.00 release,
if multiple Windows domains are configured, one profile exists for each domain rather than just
one profile for the entire system.
1.
2.
When creating your profile entry using setup, set the ProfileTTL value to 0.
Using the command get_profile_entry -s nss, write a shell script that downloads the
profile. The following is an example that downloads the profile from the directory. Modify this
example for your environment. It also compares the new and old profiles and emails a status
message:
#!/bin/ksh
cp /etc/opt/ldapux/ldapux_profile.ldif /etc/opt/ldapux/ldapux_profile.sav
/opt/ldapux/config/get_profile_entry -s nss 2>&1>/tmp/profile.upd$$
diff /etc/opt/ldapux/ldapux_profile.ldif \
/etc/opt/ldapux/ldapux_profile.sav >> /tmp/profile.upd$$
if [ -s /tmp/profile.upd$$ ]; then
cat /tmp/profile.upd$$ | mailx -s "Profile cache
refreshed." root@sys01
else
echo "No changes." | mailx -s "Profile cache refreshed."
root@sys01
2.5 Postinstallation configuration tasks
111
fi
rm -f /etc/opt/ldapux/ldapux_profile.sav
rm -f /tmp/profile.upd$$
3.
Use the crontab command to create a crontab file (or edit your existing crontab file)
and specify how frequently you want the profile to be downloaded. For example, assuming
the script written to download the profile is in the file /ldapux/download_ldap_profile,
the following crontab specification specifies that /ldapux/download_ldap_profile
be executed nightly at midnight:
0 0 * * * /ldapux/download_ldap_profile
For more information about the crontab command, see the crontab(1) manpage.
4.
Log in as root and schedule the job with the crontab command. For example, assuming the
crontab entry is in the file crontab.profile, the following schedules the profile
downloading:
crontab crontab.profile
2.5.9 Enabling use of r-commands for PAM_LDAP
LDAP-UX supports use of r-commands (commands for remote execution, such as rlogin, rcp,
and so forth) with LDAP account users whose password is hidden, or not in clear text or crypt
syntax.
To enable the use of r-commands, follow these steps, which are applicable to both HP directory
server and Windows ADS environments (readers of “Installing and configuring LDAP-UX Client
Services for a Windows ADS environment” (page 114) are referred to this section for information
about enabling use of r-commands).
1.
Comment out the following line in the /etc/opt/ldapux/ldapux_client.conf file:
#password_as = "x"
2.
Modify the account management section in the /etc/pam.conf file for PAM_LDAP and add
the "rcommand" option as follows:
# Account
#
login
login
login
su
su
su
dtlogin
dtlogin
dtlogin
dtaction
dtaction
dtaction
ftp
ftp
ftp
rcomds
rcomds
rcomds
sshd
sshd
sshd
112
management
account
account
account
account
account
account
account
account
account
account
account
account
account
account
account
account
account
account
account
account
account
required
sufficient
required
required
sufficient
required
required
sufficient
required
required
sufficient
required
required
sufficient
required
required
sufficient
required
required
sufficient
required
libpam_hpsec.so.1
libpam_unix.so.1
libpam_ldap.so.1 rcommand
libpam_hpsec.so.1
libpam_unix.so.1
libpam_ldap.so.1
libpam_hpsec.so.1
libpam_unix.so.1
libpam_ldap.so.1
libpam_hpsec.so.1
libpam_unix.so.1
libpam_ldap.so.1
libpam_hpsec.so.1
libpam_unix.so.1
libpam_ldap.so.1
libpam_hpsec.so.1
libpam_unix.so.1
libpam_ldap.so.1 rcommand
libpam_hpsec.so.1
libpam_unix.so.1
libpam_ldap.so.1
Installing and configuring LDAP-UX Client Services for an HP server environment
OTHER
OTHER
account sufficient
account required
libpam_unix.so.1
libpam_ldap.so.1
CAUTION: Setting the user password to be returned as any string for the hidden password,
and turning on the rcommand option for PAM_LDAP account management could allow users
with active accounts on a remote host to rlogin to the local host on to a disabled account.
If you have security concerns, see Section 7.4.10 (page 210) section in chapter 5 and
Section D.5 (page 430) for information on how to configure the PAM_AUTHZ library and the
rcommand option under the account management section in the /etc/pam.conf file.
For more information about the pam.conf file, see the pam.conf(4) manpage, and the Managing
Systems and Workgroups: A Guide for HP-UX System Administrators document at the following
location:
http://www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
2.5 Postinstallation configuration tasks
113
3 Installing and configuring LDAP-UX Client Services for a
Windows ADS environment
This chapter describes the decisions you must make and the steps for installing and configuring
LDAP-UX Client Services in a Windows ADS environment.
3.1 Before you begin: general installation and configuration considerations
for a Windows ADS environment
This section lists some things to keep in mind as you plan your installation:
•
You may use either of the following methods for installing and configuring LDAP-UX Client
Services on your HP-UX system:
◦
Guided installation, providing a simple, quick, and automated procedure that sets up a
basic installation of the software, which you can customize afterward as needed
◦
Customized installation, providing a screen-based procedure that enables you to customize
the software
For information about the benefits of each type of installation, see Section 3.2 (page 114).
•
For a customized installation, use “Configuration worksheet” (page 403) to record your decisions
and other information needed for configuration.
•
For the latest information, see the LDAP-UX Client Services Release Notes , available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX LDAP-UX Integration Software)
•
For advice on how to set up and configure your directory to work with HP-UX, see the white
paper Preparing Your Directory for HP-UX Integration, available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX LDAP-UX Integration Software)
NOTE: This white paper was published before support for Windows ADS was introduced.
However, much of the information continues to be relevant and helpful.
•
For more information about how to integrate LDAP-UX Client Services with HP-UX based LDAP
directories, see “Installing and configuring LDAP-UX Client Services for an HP server
environment” (page 25).
•
The examples use a base distinguished name (DN) of DC=cup, DC=hp, DC=com for
illustrative purposes.
NOTE: LDAP-UX using Windows 2003 R2 or 2008 Active Directory Server does not support
netgroup and publickey service data. In multiple domains, it only supports the passwd and
group service data.
3.2 Selecting the method of installation: guided or customized
LDAP-UX Client Services releases before B.05.00 provided only one installation option, the
customized installation using the setup program. This is a traditional screen-based program that
requires several procedures to be executed. This option enables an experienced administrator to
customize the software. LDAP-UX Client Services B.05.00 introduces the guided installation using
the autosetup program, which greatly simplifies the installation and configuration process. This
is a simple, quick, and automated procedure that gets you started with a basic implementation of
the software, requiring little input other than identifying administrator-level entities. These entities
automatically perform privileged configuration tasks for you, including configuration of Kerberos
114
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
and creation of a host principle used for proxied authentication. You can customize the software
afterward. Both of these programs are available in /opt/ldapux/config.
The guided installation (autosetup) is most advantageous if:
•
You prefer simplicity, ease, and quickness of installation.
•
You prefer an installation that enables immediate use of LDAP-UX, with minimal input required.
The autosetup program automatically provides default values for many parameters that
must be provided manually during a customized installation (you can customize parameters
later, if desirable).
•
You want HP-UX host management automatically enabled in the Active Directory Server. For
more information about host management, see Section 7.8 (page 235).
•
Your Active Directory Server has been enabled for using SSL. The guided installation will
automatically download the domain’s CA certificate and provide a simple means to distribute
it to additional HP-UX clients.
The customized installation (setup) is advantageous if:
•
You are more experienced and familiar with the product, and you want to manually customize
the software during the installation.
•
You want to install the HP-UX host into multiple-domain Windows environment. Guided
installation supports installation into a single windows domain only.
•
You want a small LDAP deployment using a local-only profile. The local-only profile can also
be useful for testing purposes and for environments where administrators lack server
administrative privileges. Local-only profile support is enabled by running the setup program
with the -l option. For more information about using this option, see Section 3.4.6.2
(page 139).
3.3 Guided installation (autosetup) for a Windows ADS environment
The guided installation greatly simplifies installation of LDAP-UX into a Windows domain. Setting
up an HP-UX client with LDAP-based security can be accomplished in a matter of moments. The
information required for installation is kept to an absolute minimum. For example, the only
information required when installing and configuring LDAP-UX into an existing domain is the name
of the directory server or the name of the domain being joined, and the credentials of a user who
is permitted to join the host to the domain. The guided installation can automatically discover the
ADS server if the HP-UX host is using the Windows DNS server for that domain. While the guided
installation (autosetup) is intended to be an interactive utility, you can use command-line options
to specify input required by the utility and make it completely automated. The command-line options
are described in detail in Section 3.3.2 (page 118).
While one of the strengths of LDAP-UX is its ability to integrate into any environment using a variety
of configuration options, the guided installation configures LDAP-UX with the most commonly-used
installation settings that support trusted integration into a Windows domain. To assure that the
associated Active Directory Server is trusted in the security management space for HP-UX, the
guided installation requires that the Active Directory Server be enabled for SSL support.
3.3 Guided installation (autosetup) for a Windows ADS environment
115
NOTE: SSL/TLS protocols support a variety of different cryptographic algorithms (ciphers) for
use in authentication operations between server and client, certificate transmissions, and session
key establishment. If a cipher is found to be flawed and subject to attack, administrators of HP-UX
and the directory server must know about their vulnerability. Ciphers can be disabled in the directory
server. For information about SSL/TLS ciphers and which ones are supported by LDAP-UX, see
Section 2.4.6.5 (page 84).
The guided installation supports the following basic installation modes:
•
Installing LDAP-UX for the first time in a Windows domain (First Installation into a Windows
Domain mode): In this mode, LDAP-UX Client Services is being set up for the first time in the
Windows environment. The guided installation process discovers information about your
existing Active Directory Server and directory information tree and configures a new LDAP-UX
profile to follow the standard layout and attributes defined for an ADS domain.
The guided installation prompts for several parameters, depending on the exact circumstances.
These might include the DN and password of a user (the domain administrator, by default)
who has sufficient privileges to add the local host to the Windows domain.
The script gives you the option of entering the host name and port of an existing Active Directory
Server, or of specifying an existing Windows domain name. If you specify a remote host
where an existing ADS exists, the guided installation might not be able to validate the identity
of the directory server unless a valid domain (CA certificate) or server certificate has already
been installed on the host being configured. If a certificate does not exist there, you are given
the option of having the guided installation download and install the CA or server certificate
without assuring trust with the directory server unless the certificate is validated with the original.
For more information about retrieving the appropriate certificate for validation, see
Section 2.4.6.4 (page 82).
For an example and instructions for performing the First Installation into a Windows Domain
mode guided installation, see Section 3.3.3 (page 122).
•
Installing Additional HP-UX Hosts into a Windows Domain (Existing Windows LDAP-UX
Configuration mode): In this mode, LDAP-UX has already been configured in the environment
(an LDAP-UX configuration profile already exists). You can then use the guided installation to
join the HP-UX host to an existing Windows ADS domain. The guided installation simply
downloads the existing domain configuration and registers the host in the domain.
For an example and instructions for performing the Existing Windows LDAP-UX Configuration
mode guided installation, see Section 3.3.4 (page 124).
116
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
NOTE: You can install LDAP-UX into an existing LDAP B.04.xx environment; however, the
hosts search descriptor serviceSearchDescriptor in the LDAP-UX configuration profile
will likely define an incorrect location for host entries (it should be cn=Computers). Host
tools expect the correct location for host entries to be defined in the configuration profile. If
the location is incorrect, the ldaphostmgr tool will add hosts to an incorrect location in the
directory tree.
The guided installation (with LDAP-UX B.05.00 or later) configures the profile with the correct
location for host entries. If you are installing LDAP-UX into an LDAP-UX environment that has
not been set up by the guided installation, ensure that the correct location is specified in the
profile (normally, this is cn=Computers container). To determine the location configured for
hosts in the LDAP-UX configuration profile, you can use the following command:
/opt/ldapux/bin/ldapcfinfo -t hosts -b
If you need to modify the configuration profile, you can modify the
serviceSearchDescriptor attribute for the hosts service. For information about how
to modify the LDAP-UX configuration profile, see Section 7.10.2.2 (page 245).
3.3.1 What autosetup does
As mentioned, the guided installation (autosetup) greatly simplifies the configuration process.
The procedure performs numerous activities automatically, with minimal input required from whoever
runs the script, including the following:
1.
2.
3.
4.
5.
6.
7.
Automatically detects existing Active Directory Servers by querying the DNS server of a
Windows domain for any registered Active Directory Servers, and then tries to connect to the
Active Directory Server with a search request. If multiple SRV resource records are returned,
autosetup stops searching after it makes a successful connection. If a directory server cannot
be found by DNS, you are prompted for the host name and port number for an existing
directory server in your environment or asked if you want to create a new directory server
instance on the local host.
To guarantee confidentiality and data integrity, autosetup uses the StartTLS extended
operation on a regular LDAP connection with simple authentication (bind DN and password).
To trust the certificate presented by the server, autosetup determines whether the local HP-UX
host has a certificate database that includes the CA certificate that issues the server certificate.
If the CA certificate has not been installed, to create certificate and key database files
(cert8.db and key3.db), autosetup obtains the server certificate from the Active Directory
Server, and then downloads all the trusted CA certificates from the NTAuth store in the Active
Directory Server. The autosetup script places in the cert8.db database file the one CA
certificate that signed the SSL server certificate of the directory server. The cert8.db file
stores public keys, while the key3.db file stores private keys. A warning message is displayed
to indicate that an untrusted method is being used to obtain the CA certificate.
Because a configuration profile can be shared by LDAP-UX clients, autosetup searches for
an existing profile entry in the Active Directory Server, using a standard profile path
(cn=ldapuxprofile,cn=system,dc=...). If the default profile entry exists, autosetup
downloads it into an LDIF file (/etc/opt/ldapux/ldapux_profile.ldif) and creates
a binary profile file (/etc/opt/ldapux/ldapux_profile.bin) based on the LDIF file.
If the default profile entry does not exist, autosetup searches for any other profile entries
that might be saved. If any are found, you are prompted to select a configuration profile to
download or to create a default profile entry.
Before adding the profile entry, autosetup determines whether the schema defined in RFC
4876 exists in the Active Directory Server. If the schema does not exist, then the script extends
the Active Directory Server schema.
3.3 Guided installation (autosetup) for a Windows ADS environment
117
8.
9.
10.
11.
12.
13.
Creates the startup file (/etc/opt/ldapux/ldapux_client.conf) on the LDAP-UX client
system, enabled for TLS support (enable_startTLS is set to 1).
Creates a new computer account or host entry in the directory server that represents the current
HP-UX host. If a host entry already exists with the same name, an autosetup prompt asks
if the existing entry should be deleted and replaced. In addition, the autosetup script maps
the Kerberos principal name to the computer account, sets the host principal password, and
creates a keytab file. If necessary, the script merges the keytab file with an existing keytab
file (/etc/krb5.keytab).
Configures the local host as a Kerberos client of the Active Directory Server by modifying an
existing Kerberos configuration file /etc/krb5.conf, or if one does not already exist, by
creating a new one.
Configures the host principal as a proxy user. It stores the encrypted proxy user information
in the /etc/opt/ldapux/pcred file. The proxy file contains the proxy user DN on the first
line, and the password on the second line.
Configures the NSS and PAM Kerberos by modifying the /etc/pam.conf and /etc/
nsswitch.conf files.
Modifies /etc/opt/ldapux/ldapuxclientd.conf to:
•
Enable the LDAP-UX client daemon ldapclientd to launch automatically whenever the
system is rebooted ([StartOnBoot] is defined with enable=yes).
•
Set iproxy_is_restricted=yes in the [general] section, which indicates that the
entry created in step 9 is not privileged. This setting enables additional capabilities
provided by the ldapuglist and ldaphostlist tools.
14. Starts the LDAP-UX client daemon (ldapclientd) and the central configuration service
daemon (ldapconfd).
3.3.2 Using the guided installation autosetup command—syntax and options for
Windows ADS environments
You can run the autosetup script interactively, responding to prompts to provide the setup
information. You can pass parameters in the command line to reduce the need for providing input
during the installation. You can run the script in silent mode, which requires no user interaction
during the installation.
To run the script interactively, simply enter the autosetup command as is. The script prompts you
for the minimal information required. To reduce user interaction during the installation, you can
pass parameters by specifying options in the command line. In addition to these options, you can
define environment variables to include parameter settings; ultimately, this enables you to run the
installation without any manual intervention required. The command-line options and environment
variables are described in the subsections to follow.
When running the autosetup script in noninteractive mode (silent mode), the CA certificate for
the specified Windows Active Directory Server or Windows domain should already be installed.
The autosetup script will not continue if a secured and trusted connection to the directory server
cannot be established. Additionally,the domain administrator's DN and password must be provided
by command-line or environment variables. Moreover, if more than one Active Directory Server is
registered in the DNS domain, the directory server host name and port number must be specified
with command-line options or with environment variable LDAP_HOSTPORT. If values are not given
for any required parameters that do not have defaults, silent mode will abort.
Whether running autosetup interactively or in silent mode, the script requires specification of a
user who has sufficient privilege to add the local HP-UX host to a Windows domain. In addition,
if this is the first time adding an HP-UX host to the Active Directory Server, autosetup might also
need to extend the server's schema. It will add the schema described by RFC 4876 (for more
information, see “LDAP-UX Client Services object classes” (page 406)).
The syntax for the autosetup command line is:
118
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
autosetup [option1 option1-value [option2 option2-value] ...]
The options are described in Section 3.3.2.1 (page 119).
For examples and detailed information about how to perform the guided installation and how
autosetup configures the LDAP-UX environment, see the following sections:
•
Section 3.3.3 (page 122)
•
Section 3.3.4 (page 124)
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (a password), make sure that the
connection between your client and the HP-UX system (where you are running autosetup) are
secured and not subject to network eavesdropping. One option to protect such communication
might be to use the ssh protocol when connecting to the HP-UX host being configured.
3.3.2.1 autosetup options
The following options may be specified on the command line when running autosetup to install
or configure LDAP-UX in a Windows ADS environment.
-C computer_acct_container
Valid only for LDAP-UX installations with Windows Server
ADS, this is the computer account container (specifying
where the computer account should be created). The default
is CN=computers. This option is ignored if specified with
an LDAP-UX installation for an HP directory server
environment.
-D privileged_user_DN
Specifies the distinguished name (DN) of a user who has
sufficient directory server privileges to create a new
computer account. This typically specifies the domain
administrator's distinguished name (DN). When installing
LDAP-UX for the first time in a Windows Domain, it can be
any user who has sufficient privileges to update the schema
on the directory server and add a new computer account
and password to the cn=computers container. When
installing and configuring LDAP-UX to add a host to a
Windows domain that already has been configured with
LDAP-UX, this can be the DN of any user with sufficient
privilege to add a new computer account, and set a
password on that account. An example of a DN for this
variable is
CN=Administrator,CN=Users,DC=ldaptest,DC=west,DC=com.
-h host_name
Specifies the host name (or IP address), and optionally the
port number, of the Windows Active Directory Server where
the local HP-UX host (client) should be added. The default
host name is the fully-qualified DNS domain name of the
server's host; the default port is 389. Specify in one of the
following formats:
host-name
host-name:port
ip-address
ip-address:port
-j password_filename
Specifies a file that includes the password for the user
specified with the -D option. Specifying this file enables
autosetup to run without prompting you for the password;
3.3 Guided installation (autosetup) for a Windows ADS environment
119
thus, it enables you to perform the guided installation in
silent mode.
-N profile_name
Specifies the configuration profile name that autosetup
will download from the directory server, if the profile exists.
If the specified profile entry does not exist in the directory
server, autosetup creates it. The default profile name is
ldapuxprofile. The autosetup program uses this
default profile name only if you do not use this option.
-p ds_port_id
Specifies the port number for accessing the Windows Active
Directory Server host. This is the port clients access to search
the directory server for entries. The default is port number
389. You need not specify the port if it has already been
specified with the host name.
-q
Specifies that autosetup be invoked in silent mode. Silent
mode runs without user intervention. Instead of prompting
for input for parameters, it uses the default values and any
values specified with command-line options or environment
variables. The CA certificate for the specified Windows
domain should be installed before running autosetup.
The domain administrator's DN and password must be
provided by command-line or environment variables.
Moreover, if more than one Active Directory Server is
registered in the DNS domain, the directory server host
name and port number must be specified with command-line
options or with environment variable LDAP_HOSTPORT. If
values are not given for any required parameters that do
not have defaults, silent mode will abort.
-s ds_sslport_id
Specifies the port number for accessing the Windows Active
Directory Server host when SSL options are used. The default
is SSL port 636.
-U user_acct_container
Valid only for LDAP-UX installations with Windows Server
ADS, this is the user account container (specifying where
the user account should be created). The default is
CN=users. This option is ignored if specified with an
LDAP-UX installation for an HP directory server environment.
-v n
Specifies verbose level for debugging purposes, with n
specifying one of the following: 0 (turns off verbose mode),
1, 2, or 3 (specifies the highest level of verbosity).
-x domain_name
Specifies the Windows Active Directory Server domain this
host will join; for example, nwest.acme.com. Used only
when the –h option is not used.
3.3.2.2 autosetup environment variables
The following environment variables can be used with autosetup when the corresponding option
(defined in Section 3.3.2.1 (page 119)) is not used:
LDAP_BINDDN
Specifies the distinguished name (DN) of a user who has sufficient directory
server privileges to create a new computer account. This typically specifies
the domain administrator's distinguished name (DN). When installing LDAP-UX
for the first time in a Windows Domain, it can be any user who has sufficient
privileges to update the schema on the directory server and add a new
computer account and password to the cn=computers container. When
installing and configuring LDAP-UX to add a host to a Windows domain that
120 Installing and configuring LDAP-UX Client Services for a Windows ADS environment
already has been configured with LDAP-UX, this can be the DN of any user
with sufficient privilege to add a new computer account, and set a password
on that account. An example of a DN for this variable is
CN=Administrator,CN=Users,DC=ldaptest,DC=west,DC=com
Equivalent to using the -D option in the command line.
LDAP_BINDCRED
Sets the password for the user defined by LDAP_BINDDN. Equivalent to using
the -j option in the command line (except this command-line option specifies
a file containing the password).
LDAP_DOMAIN
Sets the name of the Windows Active Directory Server domain that will be
joined by the local HP-UX host (client); for example, nwest.acme.com.
Equivalent to using the -x option in the command line. Used only if the
LDAP_HOSTPORT is not specified.
LDAP_HOSTPORT
Sets the host name (or IP address), and optionally the port number, of the
Windows Active Directory Server where the local HP-UX host (client) should
be added. Equivalent to using the -h and -p options in the command line.
The default host name is the fully-qualified DNS domain name of the host;
the default port is 389. Specify in one of the following formats:
host-name
host-name:port
ip-address
ip-address:port
LDAP_SSLPORT
Specifies the port number for accessing the Windows Active Directory Server
host when SSL options are used. The default is 636.
3.3.2.3 autosetup command examples
The following are examples showing how to run autosetup with command-line options:
Example 9 autosetup: interactive mode with verbose set at the highest level
# autosetup -v 3
This command runs autosetup interactively, with verbose set at the highest level for debugging
purposes.
Example 10 autosetup: passing two parameters directly in the command line along with a password
file
# autosetup -D "cn=administrator, cn=users, dc=ldaptest, dc=west, dc=com" -j /tmp/jfile -x document.hp.com
This command specifies the domain administrator and a file that includes the password required
for the domain administrator of the directory server being created. The command also specifies
the Active Directory domain this host will join. When you invoke autosetup, you are not prompted
for these parameters.
Example 11 autosetup command for silent mode
# autosetup -h blipsa01 -D "cn=phil,cn=users,dc=document,dc=hp,dc=com" -j /tmp/jfile -q
This command specifies the host name of the Active Directory Server where the local host will be
added. In addition, it specifies the DN of a user who has privileges to add the host to the ADS
domain and a file that includes the password for this user.
3.3 Guided installation (autosetup) for a Windows ADS environment
121
Example 12 autosetup: silent mode
# autosetup -q
This command invokes silent mode. It can be used in any scenario in which user intervention is not
required. It assumes required parameters have been specified in environment variables.
3.3.3 Guided installation steps: First Installation into a Windows Domain mode
This section explains how to install LDAP-UX for the first time into an existing Windows domain, to
create a new LDAP-UX configuration profile.Section 3.3.3.1 (page 122) shows how to perform the
guided installation interactively, explaining step-by-step how to respond to each prompt for user
input. Section 3.3.3.2 (page 124) shows how to run a completely-automated (silent mode) guided
installation.
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 that are local to the hosts
in the LDAP-UX domain. 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 the 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
directory server do not collide with the ones already on the HP-UX host, see Section 3.5.1.1
(page 152).
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client (where you are running autosetup) and the HP-UX system is
secured and not subject to network eavesdropping. One option to protect such communication
might be to use the ssh protocol when connecting to the HP-UX host being configured.
3.3.3.1 Interactively running First Installation into a Windows Domain mode
To interactively install LDAP-UX into a Windows domain for the first time (where there is no existing
LDAP-UX configuration profile), follow these steps. This example assumes that you have already
installed a CA certificate, as described in step 2. If you have not installed the domain’s CA
certificate, you are prompted to answer whether to trust the directory server, which cannot be
positively identified.
1.
Log in as root and run the autosetup command, as shown in the following example:
# /opt/ldapux/config/autosetup
2.
The autosetup script searches for any registered directory servers, querying the DNS server
of the Windows domain but does not find one, as indicated in the following example.
NOTE: If a registered directory server is found, autosetup uses that directory server
automatically unless you specify another using the -h option or the LDAP_HOSTPORT
environment variable. The installation and configuration would be similar to that which follows.
The script gives you the option of entering the host name and port of an existing directory
server, or of specifying an existing Windows domain name. The installer specifies
hpdhcalif.nwest.acme.com:389 for the host name and port.
122
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
Scanning DNS domain "nwest.acme.com" for any registered LDAP directory servers...
- No directory servers found.
Please enter the host name and port number of a directory server
[hostname:port], or a Windows domain name: hpdhcalif.nwest.acme.com:389 Enter
NOTE:
Unless you have already installed a CA or server certificate for the directory server, autosetup
has no means of validating the identity of Kerberos and the directory server. The tool can
download and permanently install the CA certificate for the specified Windows domain;
however, to prevent from connecting with an impostor host, you should validate and install
the CA certificate for this domain. To determine how to discover and install the domain’s CA
certificate, see Section 2.4.6.2 (page 80).
If the CA certificate is not installed on your local host at this point of the guided installation,
autosetup warns you that it cannot validate the identity of the remote server and suggests
installing the CA certificate. You can abort so that you can install the CA certificate before
proceeding with the rest of the guided installation, or you can continue, trusting the CA
certificate that will be installed automatically by autosetup.
This example assumes the CA certificate has already been installed; therefore, you will not
see the warning and the prompt asking whether to abort or continue.
3.
The script then asks for the DN of the user who can add the local host to the Windows domain.
This being the first time adding an HP-UX host to this directory server, LDAP-UX will extend the
server's schema. So the user must have the appropriate schema-update privileges. In this
example, the default DN for the user with such privileges is
CN=Administrator,CN=Users,DC=nwest,DC=acme,DC=com, and the installer opts
for the default. The server's DNS domain in this example is nwest.acme.com.
Please enter the DN of a user that has sufficient privilege to add this host
to the "nwest.acme.com" domain. Note also that if this is the first
time adding an HP-UX host to this directory server, LDAP-UX may also need to
extend the server's schema. Please enter the DN of an Administrator with
these privileges or press Return for the default value
[CN=Administrator,CN=Users,DC=nwest,DC=acme,DC=com]: Enter
4.
Enter the password for the user identified in the preceding step (the entered password is not
visible):
Please enter the administrator's password:[password not displayed]
Enter
The installation now begins, followed by other related tasks; autosetup displays information
about the progress and results, as in the following example. As indicated, because an existing
LDAP-UX configuration profile does not exist, autosetup adds the default profile entry and
downloads the profile entry from the Windows Active Directory Server. The profile and the
associated domain will be based on the existing directory tree. In addition, autosetup provisions
information about the local host into the existing directory server. The script creates the computer
account for the LDAP-UX client system and configures it as the proxy user. (The host where
autosetup is running is hpdhcalif.) In a matter of seconds, the script finishes, successfully
adding the host to the nwest.acme.com Windows domain.
There are no profile entries in CN=system,DC=nwest,DC=acme,DC=com.
Successfully added default profile entry CN=ldapuxprofile,CN=system,
DC=nwest,DC=acme,DC=com to AD server.
Successfully downloaded profile entry from AD server.
Created "hpdhcalif.nwest.acme.com" computer account.
3.3 Guided installation (autosetup) for a Windows ADS environment
123
The Kerberos configuration file /etc/krb5.conf has been modified.
Configured "hpdhcalif.nwest.acme.com" as LDAP-UX proxy.
* Editing the name-service switch configuration ... done.
* Editing "/etc/pam.conf" ... done.
Your LDAP-UX client has been successfully configured and
is now a member of the "nwest.acme.com" domain.
3.3.3.2 Automating First Installation into a Windows Domain mode
You can run autosetup in silent mode, providing values for required parameters in the command
line or with environment variables. As discussed in Section 3.3.3.1 (page 122), you should
preestablish trust with the remote directory server by installing the CA certificate before running
autosetup. To perform this installation without user interaction, you must specify the following
in command-line options or environment variables:
The DN of the directory server user who can add the local host to the directory server's Windows
domain: use either the -D option or the LDAP_BINDDN variable.
The password for the user who can add the local host: use either -j option or the LDAP_BINDCRED
variable.
The host name, and optionally the port number, of the Windows Active Directory Server where
the local HP-UX host (client) should be added: use either -h option or the LDAP_HOSTPORT
variable.
In the following example, these parameters are specified in the command line:
# ./autosetup -h hpdhcalif.nwest.acme.com\
-D "cn=administrator,cn=users,dc=nwest,dc=acme,dc=com" -j /tmp/jfile -q
There are no profile entries in CN=system,DC=nwest,DC=acme,DC=com.
Successfully added default profile entry CN=ldapuxprofile,CN=system,
DC=nwest,DC=acme,DC=com to AD server.
Successfully downloaded profile entry from AD server.
Created "hpdhcalif.nwest.acme.com" computer account.
The Kerberos configuration file /etc/krb5.conf has been modified.
Configured "hpdhcalif.nwest.acme.com" as LDAP-UX proxy.
* Editing the name-service switch configuration ... done.
* Editing "/etc/pam.conf" ... done.
Your LDAP-UX client has been successfully configured and
is now a member of the "nwest.acme.com" domain.
3.3.3.3 Postinstallation steps for First Installation into a Windows Domain mode
Perform the postinstallation configuration tasks documented in Section 3.5 (page 151), as needed.
3.3.4 Guided installation steps: Existing Windows LDAP-UX Configuration mode
This section explains how to install LDAP-UX into an existing Windows domain that already has
an LDAP-UX configuration profile.Section 3.3.4.1 (page 125) shows how to perform the guided
installation interactively, explaining step-by-step how to respond to each prompt for user input.
Section 3.3.4.2 (page 127) shows how to run a completely-automated (silent mode) guided
installation.
124
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
NOTE: If you attempt to run autosetup on a host on which LDAP-UX (ldapclientd) is already
running, the procedure aborts. If the LDAP-UX is installed on the host but not running, the procedure
proceeds. However, if a previous LDAP-UX configuration profile is found on the system, the procedure
warns you that proceeding will overwrite the file and asks if you want to proceed.
You may proceed if your intention is to reconfigure LDAP-UX on the host. You could reconfigure
LDAP-UX for any of several reasons, such as:
•
You want the host to connect to a different directory server than the one the host was originally
configured to connect to.
•
The LDAP-UX configuration was corrupted (an error indicates a component is corrupted).
•
A directory server user inadvertently deleted the host entry from the directory server. This
removes the proxy user required to connect to the directory server; to correct this, rerun
autosetup to recreate the host entry and reestablish user proxies.
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client (where you are running setup) and the HP-UX system is secured
and not subject to network eavesdropping. One option to protect such communication might be
to use the ssh protocol when connecting to the HP-UX host being configured.
3.3.4.1 Interactively running Existing Windows LDAP-UX Configuration mode
To interactively install LDAP-UX onto a host that is to join a Windows domain in an existing LDAP-UX
environment, follow these steps. This example assumes that you have already installed a CA
certificate, as described in step 2.
1.
Log in as root and run the autosetup command, as shown in the following example:
# /opt/ldapux/config/autosetup
2.
The autosetup script searches for any registered directory servers, querying the DNS server
of the Windows domain but does not find one, as indicated in the following example.
NOTE: If a registered directory server is found, autosetup uses that directory server
automatically unless you specify another using the -h option or the LDAP_HOSTPORT
environment variable. The installation and configuration would be similar to that which follows.
If the registered directory server was originally established by autosetup, then autosetup
now downloads the existing directory server's profile to your host. If it was not established by
autosetup, then autosetup attempts to find any profile and downloads it.
The script gives you the option of entering the host name and port of an existing directory
server, or of specifying an existing Windows domain name. In this example, the installer
specifies its IP address and port number.
3.3 Guided installation (autosetup) for a Windows ADS environment
125
NOTE: Unless you install a CA or server certificate for the directory server before running
autosetup, autosetup has no means of validating the identity of Kerberos and the directory
server. The tool can download and permanently install the CA certificate for the specified
Windows domain; however, to prevent from connecting with an impostor host, you should
validate and install the CA certificate for this domain. To determine how to discover and install
the domain’s CA certificate, see Section 2.4.6.2 (page 80).
If the CA certificate is not installed on your local host at this point of the guided installation,
autosetup warns you that it cannot validate the identity of the remote server and suggests
installing the CA certificate. You can abort so that you can install the CA certificate before
proceeding with the rest of the guided installation, or you can continue, trusting the CA
certificate that will be installed automatically by autosetup.
Because the CA certificate has already been installed for this example, autosetup does not
display the warning and does not ask whether to abort or continue.
Scanning DNS domain "west.hp.com" for any registered LDAP directory servers...
- No directory servers found.
Please enter the host name and port number of a directory server
[hostname:port], or a Windows domain name: 16.93.97.233:389 Enter
3.
The script then asks for the DN of the directory server user who can add the local host to the
directory server's Windows domain. In this example, the default DN for the user with such
privileges is CN=Administrator,CN=Users,DC=nwest,DC=acme,DC=com, and the
installer opts for the default. The server's DNS domain in this example is nwest.acme.com.
Please enter the DN of a user that has sufficient privilege to add this host
to the "nwest.acme.com" domain. Note also that if this is the first
time adding an HP-UX host to this directory server, LDAP-UX may also need to
extend the server's schema. Please enter the DN of an Administrator with
these privileges or press Return for the default value
[CN=Administrator,CN=Users,DC=nwest,DC=acme,DC=com]: Enter
4.
Enter the password for the user identified in the preceding step (the entered password is not
visible):
Please enter the administrator's password: [password not displayed] Enter
The installation now begins, followed by other related tasks; autosetup displays the progress
and results, as in the following example. The script finds an existing LDAP-UX configuration profile
and downloads the existing profile from the directory server. The profile and the associated LDAP-UX
domain will be based on the existing directory tree. In addition, autosetup provisions information
about the local host into the existing directory server. (The host where autosetup is running is
hpdhcalif.) Again, in a matter of seconds, the script finishes its work.
Found default profile entry CN=ldapuxprofile,CN=system,DC=nwest,DC=hp,DC=com.
Successfully downloaded profile entry from AD server.
Created "hpdhcalif.nwest.acme.com" computer account.
The Kerberos configuration file /etc/krb5.conf has been modified.
Configured "hpdhcalif.nwest.acme.com" as LDAP-UX proxy.
* Editing the name-service switch configuration ... done.
* Editing "/etc/pam.conf" ... done.
Your LDAP-UX client has been successfully configured and
is now a member of the "nwest.acme.com" domain.
126
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
3.3.4.2 Automating Existing Windows LDAP-UX Configuration mode
You can run autosetup in silent mode and specify any required values for parameters in the
command line or with environment variables. You must already installedestablish trust with the
remote directory server by installing the CA certificate before running autosetup. To perform
this installation without user interaction, you must specify the same command-line options or
environment variables as required by the automated First Installation into a Windows Domain
mode installation:
The bind DN (the DN of the directory server user who can add the local host to the directory
server's Windows domain): use either the -D option or the LDAP_BINDDN variable.
The password used with the bind DN: use either -j option or the LDAP_BINDCRED variable.
The host name, and optionally the port number, of the Windows Active Directory Server where
the local HP-UX host (client) should be added: use either -h option or the LDAP_HOSTPORT
variable.
In the following example, these parameters are specified in the command line:
# ./autosetup -h 16.93.97.233 -p 389 \
-D "cn=administrator,cn=users,dc=nwest,dc=acme,dc=com" -j /tmp/example.passwd
Found default profile entry CN=ldapuxprofile,CN=system,DC=nwest,DC=acme,DC=com.
Successfully downloaded profile entry from AD server.
Created "hpdhcalif.nwest.acme.com" computer account.
The Kerberos configuration file /etc/krb5.conf has been modified.
Configured "hpdhcalif.west.acme.com" as LDAP-UX proxy.
* Editing the name-service switch configuration ... done.
* Editing "/etc/pam.conf" ... done.
Your LDAP-UX client has been successfully configured and
is now a member of the "nwest.acme.com" domain.
3.3.4.3 Postinstallation steps for Existing Windows LDAP-UX Configuration mode
After completing an Existing Windows LDAP-UX Configuration mode guided installation, perform
these steps:
•
If you installed LDAP-UX into an existing LDAP-UX B.04.xx environment, or into an LDAP-UX
B.05.xx environment that was configured by the customized installation (setup), or in any
LDAP-UX B.05.xx environment that was modified since being created, ensure that the
user/group and host management tools can identify the proper locations in the directory server
tree for creating new users and groups. The tools expect the LDAP-UX configuration profile to
indicate the correct location for the user and group entries. For more information about assuring
the management tools properly interface with the configuration profile, see see Section 9.3.5.6
(page 306) and Section 7.8.1 (page 235).
•
Perform the postinstallation configuration tasks documented in Section 3.5 (page 151), as
needed.
3.4 Customized installation (setup) for a Windows ADS environment
The customized installation requires that you be familiar with the LDAP-UX and directory server
environment. This section describes how to perform this installation, tailoring the installation and
configuration to the specific needs of your organization and environment.
3.4.1 Summary of installing and configuring LDAP-UX Client Services
The following section summarizes the steps you should take to install and configure an LDAP-UX
Client Services environment:
3.4 Customized installation (setup) for a Windows ADS environment
127
1.
2.
3.
4.
5.
Plan your installation (see Section 3.4.3 (page 129)).
Install LDAP-UX Client Services on each client system (see Section 3.4.4 (page 134)).
Install and configure the Active Directory, if not already done (see Section 3.4.5 (page 135)).
Install the PAM Kerberos product (see Section 3.4.6.1 (page 139))
Run the setup program to configure LDAP-UX Client Services on a client system (see
Section 3.4.6.2 (page 139)). The setup program does the following for you:
•
Extends your Active Directory schema with the configuration profile schema, if not already
done.
NOTE: To use a local-only profile, run the setup program using the -l option . Use
the local-only profile for small deployments, testing purposes, and for environments where
administrators lack server administrative privileges.
•
Creates a startup file on the client. This enables each client to download the configuration
profile.
•
Creates a configuration profile of directory access information in the directory, to be
shared by a group of (or possibly all) clients.
If the ADS multiple domains feature has been selected, the setup program will also
create the remote domains profiles, GCS profile, or both.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
•
Downloads the configuration profile from the directory to the client.
•
Starts the product daemon, ldapclientd, if you choose to start it.
Configure the LDAP name service (see Section 3.4.6.4 (page 150))(see Section 3.4.6.3
(page 149)).
Configure PAM Kerberos (see Section 3.4.2 (page 128)).
Optionally, configure the PAM Authorization Service Module (PAM_AUTHZ) to control access
rules defined in a policy file (this is a step that can be performed while configuring LDAP-UX
Client Services (see Section 3.4.6.5 (page 150)); for more information about configuring this
service, see Section 7.4 (page 199)).
Optionally, configure the disable login flag (disable_uid_range) to disallow specific users
to log in to the local system (see Section 3.4.6.6 (page 151)).
If you attempt to enable SSL or TLS support with LDAP-UX, configure your LDAP server to
support SSL or TLS (see Section 3.4.7 (page 151)).
Migrate your supported name service data to the directory. Refer to Section 3.5.1 (page 151).
Verify each client is working properly (see Section 3.5.2 (page 152)).
Enable AutoFS support (see Section 3.5.3 (page 152)).
Prevent unwanted users from accessing the system through LDAP (Section 3.5.4 (page 157)).
Configure subsequent clients, using shortcuts described in Section 3.5.5 (page 157) .
3.4.2 Tasks that must be performed to implement Kerberos support
When you use the customized installation (setup program) to install and configure LDAP-UX Client
Services, to set up Kerberos authentication support you must perform several installation and
configuration tasks documented throughout this manual. These tasks are summarized in Table 12
(page 128). You can use this table as a checklist.
Table 12 Kerberos-related tasks to perform
128
Task
Section of this manual
Install the PAM Kerberos product
Section 3.4.6.1 (page 139)
Configure the PAM Kerberos library in the PAM
configuration file
“Sample PAM configuration (pam.conf) files ” (page 420)
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
Table 12 Kerberos-related tasks to perform (continued)
Task
Section of this manual
Configure your HP-UX machine to authenticate using
PAM Kerberos
Section 3.4.6.3 (page 149)
Create the keytab file for the HP-UX machine and set up Section 3.4.5.4 (page 137)
an identity mapping the host account
If not already done, perform any tasks recommended
Section 3.4.6.2 (page 139)
prior to running the setup program, and then run the
program to configure LDAP-UX Client Services; during
the setup procedure (at step 17), you will be prompted
for the path to the Kerberos keytab file (if you do not
respond, the default is used)
(Optional) If you choose to use SASL/GSSAPI, configure Section 7.3 (page 196)
support for proxy user authentication
(Optional) For multiple domain support, merge and store Section 7.11 (page 246)
all service key files (created on each domain controller)
into /etc/krb5.keytab on your HP-UX host (this enables
the host to act as a KDC, storing the service key known
by every domain controller)
For more information about Kerberos as supported by HP-UX, refer to the following:
•
Configuration Guide for Kerberos Products on HP-UX available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX Kerberos Data Security Software)
•
Kerberos Client Release Notes available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX Kerberos Data Security Software)
3.4.3 Planning your customized installation
Before beginning your installation, plan how to set up and verify your Active Directory and your
LDAP-UX Client Services environment. Consider the following questions. Record your decisions and
configuration information in “Configuration worksheet” (page 403).
•
Will Active Directory be set up with a single domain or multiple domains?
Starting from the release of B.03.00, LDAP-UX enables you to store your password and group
data in multiple domains. You must 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 may be stored in all remote domains or only in specific
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 “Windows Active
Directory multiple domains” (page 159).
3.4 Customized installation (setup) for a Windows ADS environment
129
•
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/Windows2003 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:
◦
/etc/passwd and /etc/group
◦
The same source files used to create your NIS maps, if using NIS
◦
The NIS maps
For information about importing information into the directory, refer to Section 3.5.1 (page 151).
For information on migration scripts, see Section 9.6 (page 383).
To add an individual user entry or modify an existing user entry in your directory, use the
ldapugadd or ldapugmod commands or other directory administration tools, such as
ldapmodify or the Active Directory Users and Computers interface tool.
NOTE: Keep a small subset of users in /etc/passwd, particularly the root login (any
account with uid number 0). 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 10 (page 132) 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 (page 406).
•
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.
130 Installing and configuring LDAP-UX Client Services for a Windows ADS environment
For information about importing information into the directory, refer to Section 3.5.1 (page 151).
For information on migration scripts, see Section 9.6 (page 383).
CAUTION: If you place a root login (any account with UID number 0) in the directory server,
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 enables local
management of the root user. 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: 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 directory server do not collide with the ones already used on the HP-UX host, see
Section 3.5.1.1 (page 152).
•
How many profiles do you need?
If you use ADS multiple domains, refer to “Windows Active Directory multiple domains”
(page 159) 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. To help you determine how many
different profiles you need, see “LDAP-UX Client Services object classes” (page 406) t.
If you are familiar with NIS, one possibility 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 may put the profile with your user data, or in a
separate configuration area. HP-UX hosts must have access to the profile and the user, and
to the group data. Figure 10 shows a configuration profile DN of CN=profile data,
CN=System, DC=cup, DC=hp, DC=com for a single domain. Figure 11 shows the same
for a multiple domain environment.
3.4 Customized installation (setup) for a Windows ADS environment
131
Figure 10 Example directory structure for a single domain
DC=cup, DC=hp, DC=com
CN=System
CN=Users
profile
data
user
data
group
data
Figure 11 Example directory structure for multiple domains
DC=cup, DC=hp, DC=com
CN=System
profile
data
user
data
DC=<name1>, DC=cup, DC=hp, DC=com
CN=System
profile
data
CN=Users
user
data
CN=Users
group
data
group
data
DC=<name2>, DC=cup, DC=hp, DC=com
CN=System
profile
data
CN=Users
user
data
group
data
NOTE: By default, the CN=system, 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 must manually create the containers CN=system 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 “Configuration worksheet” (page 403).
•
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 “Configuration worksheet” (page 403).
•
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 or NIS) as controlled by NSS. For more information
on PAM, see the pam(3) and pam.conf(4) manpages, and Managing Systems and Workgroups
at:
http://www.hp.com/go/hpux-core-docs (Click HP-UX 11i v2)
132
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
•
Do you want to use SSL or TLS for secure communication between LDAP clients and the
Windows 2003 R2 or 2008 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 2003
R2 or 2008 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
unencrypted ( 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 Section 3.4.7 (page 151).
•
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 2003
R2 or 2008 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 more information about SASL/GSSAPI support, see Section 7.3 (page 196).
For an overview of these and other authentication methods you can configure with LDAP-UX
Client Services, including their strengths and weaknesses, see Section 2.4.6.1 (page 79).
•
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.
For an overview of these and other authentication methods you can configure with LDAP-UX
Client Services, including their strengths and weaknesses, see Section 2.4.6.1 (page 79).
•
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. For information about the /etc/
krb5.conffile, see “Sample /etc/krb5.conf file” (page 434).
•
Do you want to store and manage automount maps in the directory server? If so, the setup
program can be used to import the new automount schema into your directory server.
LDAP-UX Client Services B.04.10 and later supports the automount service under the AutoFS
subsystem. This feature enables you to store or retrieve automount maps in or from a directory
server. LDAP-UX Client Services supports the new automount schema based on RFC 2307-bis.
The setup program will import the new automount schema into your directory server.
For the detailed information about AutoFS with LDAP support, see Section 3.5.3 (page 152).
•
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
3.4 Customized installation (setup) for a Windows ADS environment
133
file using files and LDAP. For more information, see the nsswitch.conf(4) manpage and
"Configuring the Name Service Switch" in NFS Services Administrator's Guide at:
http://www.hp.com/go/hpux-core-docs (Click HP-UX 11i v3).
It is recommended you use files first, followed by LDAP for passwd, group and other supported
name services. With this configuration, NSS will first search files, then 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 a directory server? How will you set up the access policy file and /etc/pam.conf files
to implement this feature?
The PAM_AUTHZ service module for PAM provides functionality that enables the administrator
to control who can log in to the system. These modules are located at /usr/lib/security/
libpam_authz.1 on an HP 9000 (PA-RISC) machine and at libpam_authz.so.1 on
anHP Integrity server. The pam_authz module has been created to provide access control.
Starting with LDAP-UX Client Services B.04.00, PAM_AUTHZ has been enhanced to enable
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.
For detailed information on this feature and how to configure the /etc/opt/ldapux/
pam_authz.policy file, see Section 7.4 (page 199) or the pam_authz(5) manpage.
•
Do you want to configure the /etc/opt/ldaux/pam_authz.policy to enforce account
and password policies, stored in a directory server.
LDAP-UX provides pam_authz enhancement to support enforcement of account and password
policies, stored in a directory server. This feature works in conjunction with ssh (secure shell),
r-commands (rlogin, rcp, and so forth) with rhost enabled where authentication is not
performed by the PAM subsystem, but is performed by the command itself.
For information about this feature and how to configure the pam_authz.policy file, see
Section 7.4.10 (page 210).
•
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 directory server to log in. To disallow specific
users to log in to a local system, you can configure the disable_uid_range flag in /etc/
opt/ldapux/ldapux_client.conf file, as described in Section 3.5.4.1 (page 157).
•
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.
See the LDAP-UX Integration Release Notes for any other limitations and any solutions that
have been developed to workaround them.
3.4.4 Installing LDAP-UX Client Services on a client
These are the major steps required to install LDAP-UX Client Services on a client:
1.
134
Use swinstall(1M) to install the LDAP-UX Client Services software, the NativeLdapClient
subproducts, on a client system. See the LDAP-UX Integration Release Notes for any last-minute
changes to this procedure. You don't need to reboot your system after installing the product.
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
NOTE: For LDAP-UX Cleint Services B.03.20 or later versions, system reboot is not required
after installing the product.
2.
Install the required patches. For patch information, refer to /opt/ldapux/
README-LdapUxClient (available after the NativeLdapClient subproduct is installed).
NOTE:
at:
For information about required patches, see the LDAP-UX Integration Release Notes
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
3.4.5 Configuring Windows Active Directory for HP-UX integration
This section describes the requirements and steps for configuring Active Directory to work with
LDAP-UX Client Services.
NOTE: If you will be configuring your system for ADS multiple domains, there will be some
additional configuration instructions to follow. These are listed under the appropriate step number.
3.4.5.1 Step 1: Install Active Directory
The Active Directory must be installed separately after the Windows 2003/R2 or Windows 2008
Server installation has been completed on your computer.
Installing Active Directory on Windows 2003/R2
Use the following steps to install the Active Directory Server on Windows 2003 R2:
1.
2.
3.
4.
5.
6.
Open Manage Your Server from the Administrative Tools folder.
In the Manage Your Server screen, select add or remove a role.
In the Configure Your Server Wizard (Preliminary Steps) screen, select Next.
In the Configure Your Server Wizard (Server Role) screen, select Domain Controller (Active
Directory). Then, select Next.
Install any additional Administrative tools required for you to manage Active Directory. These
Windows 2003 R2 Administrative tools are included with Windows 2003 R2 Server to simplify
directory administration.
If ADS multiple domains will be used, set up the ADS forest. Ideally, the local domain should
contain the most frequently accessed data.
Installing Active Directory on Windows 2008
Use the following steps to install the Active Directory Server on Windows 2008:
1.
2.
3.
4.
5.
6.
Open Server Manager from the Administrative Tools folder.
The Manage Your Server screen appears. In this screen, select Roles and the Add Roles link.
In the Before You Begin, select Next.
In the Select Server Roles screen, select Active Directory Domain Services. Then, select Next.
Install any additional Administrative tools required for you to manage Active Directory. These
Windows 2008 Administrative tools are included with Windows 2008 Server to simplify
directory administration.
If ADS multiple domains will be used, set up the ADS forest. Ideally, the local domain should
contain the most frequently accessed data.
3.4 Customized installation (setup) for a Windows ADS environment
135
3.4.5.2 Step 2: Create a proxy user
The use of a proxy user is mandatory for Active Directory, as anonymous binding done not grant
enough access rights to retrieve user, group, or any other name service data.
Use the Windows 2003 R2 or 2008 management tool, Active Directory Users and
Computers, to add a proxy user as a member of the "Domain Users" group. The proxy user is
used by the LDAP-UX clients to bind to the ADS for access to the name service data on the ADS.
For example, you might add a user:
CN=Proxy User, CN=Users, DC=cup, DC=hp, DC=com
CAUTION: Make sure the proxy user is a member of the Domain Users group, which allows read
access only, and not the Administrator group to protect Active Directory entries from malicious
modifications.
A proxy user's access right to objects in an Active Directory depends on what default permissions
Active Directory has been configured with during installation.
•
Setting the "Windows 2000 Compatible Access" option
This option allows authenticated users read rights to all properties of their own objects, but
limited access to attributes of other objects. Because a proxy user must be able to read all
users' and groups' POSIX attributes, the administrator should specifically extend the access
capabilities for proxy users using one of the following alternatives:
◦
Configure the proxy user to be a member of "Pre-Windows 2000 Compatible Access"
group. By doing this, you allow the proxy user to read all properties of user and group
objects. Here is how to configure it:
1. Start Active Directory Users and Computers,
2. From the domain tree, click Builtin.
3. Double-click Pre-Windows 2000 Compatible Access, and select the Members tab.
4. Click Add, from a list of all users and groups, select the user name which you want
to configure as a proxy user, then click Add.
5. Click OK to save the configuration.
◦
Delegate POSIX attribute read access to the proxy user, allowing the proxy user to read
only POSIX attributes of user and group objects:
1. Start Active Directory Users and Computers.
2. Click the container that contains the proxy user, usually it is Users.
3. Select Delegate Control from the Action menu.
4. The Delegation of Control Wizard starts. Click Next.
5. On the screen that appears, click Add to get a list of users groups. Select the proxy
user, click Add, and then click OK to return to the screen that selects users and groups.
6. Click Next.
7. If you use Windows 2003 R2, you are given the screen to identify the task to
delegate; select Create a custom task to delegate and click Next.
Otherwise, skip this step.
8.
9.
The next screen allows you to identify the scope of the task you want to delegate.
Click Only the following objects in folder. Then select the Group objects, box, and
click Next.
You are prompted to select permissions. Click Property-specific and the following
permissions:
–
Read gidNumber
–
Read memberUid
Click Next.
136
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
10. A screen displays that confirms your configuration. Click finish if everything is correct;
otherwise, click Back to modify your responses.
11. Repeat the steps 8 and 9 to delegate user POSIX attributes to the proxy user by
choosing User objects in step 8 and choosing the following POSIX user attributes in
step 9:
•
–
Read gecos
–
Read loginShell
–
Read unixHomeDirectory
–
Read gidNumber
–
Read uidNumber
–
Read uid
If you will be using ADS multiple domains:
If you configure LDAP-UX with ADS multiple domains, and you configure a proxy user in one
of the domains, as described previously, then configure the same proxy user in every domain
that you want to include for remote domain support with LDAP-UX. For example, first configure
a proxy user proxyusr for the domain ldap.hp.com. Next, include the domain
eng.hp.com in the support, and add proxyusr@ldap.hp.com to the domain eng.hp.com
using the preceding steps. Repeat these steps for every domain that you want to include. If
you have multiple LDAP-UX clients, you may also configure one proxy user for each client as
long as the proxy user has the access right to all domains that the client wants to access.
The proxy user needs to have access right to read passwd and group information in multiple
domains.
3.4.5.3 Step 3: Add an HP-UX client machine account to Active Directory
Use the Active Directory Users and Computer tool to create a user account for your HP-UX host.
•
If you are using ADS multiple domains: add a host account for an HP-UX client machine to
every domain you want to access.
3.4.5.4 Step 4: Use ktpass to create the keytab file for the HP-UX client machine
Use the ktpass tool to create the keytab file and set up an identity mapping the host account.
The following is an example showing you how to run ktpass to create the keytab file for the
HP-UX host myhost with the KDC realm cup.hp.com:
C:> ktpass -princ host/myhost.cup.hp.com@CUP.HP.COM -mapuser myhost
-pass mypasswd -out unix.keytab
NOTE: Unless a ptype is specified, the resulting keytab will have ptype 0 KRB5_NT_UNKNOWN, whereas it should probably be set to KRB5_NT_PRINCIPAL.
NOTE: If your machine doesn't have ktpass for Windows 2003 R2, you can install it from your
Windows 2003 Server compact disc, in the directory support/tools/suptools.msi. For
Windows 2008, this is installed by default.
If you are using ADS multiple domains, repeat step 3 and step 4 in this procedure for the HP-UX
client machine in every domain to be accessed. Then, merge the keytab files on your HP-UX machine
to create /etc/krb5.keytab. For more information, see Section 7.11 (page 246).
This is one way to configure an HP-UX Kerberos client to communicate with multiple KDCs. For
other possibilities using cross-realm authentication, refer to the [capaths] section of the krb5.conf
manpage (that is: man krb5.conf). For information about the /etc/krb5.conf file, see
“Sample /etc/krb5.conf file” (page 434).
3.4 Customized installation (setup) for a Windows ADS environment
137
For more information about ktpass parameters, standard encoding types, and the defaults, see
the appropriate Microsoft documentation, including Microsoft Knowledge Base (KB) articles such
as the following:
Table 13
KB and topic
Windows
version
Location
KB833708: Encoding types (crypto); Windows
KDC does not allow clients to specify 2003
an etype
http://support.microsoft.com/kb/833708
KB919557: Bad versions of ktpass;
pre-authentication errors
Windows
2003
http://support.microsoft.com/kb/919557
KB843071: ktpass errors when using
/target and /mapuser switch
Windows
2003
http://support.microsoft.com/kb/843071
KB960830: ktpass password
problems
Windows
2008
http://support.microsoft.com/kb/960830
For information about other steps that you might need to perform to set up Kerberos support, see
Section 3.4.2 (page 128).
NOTE: The guided installation (autosetup) takes care of Kerberos integration between HP-UX
and Windows.
3.4.5.4.1 Validating the host user principal
3.4.5.5 Step 5: Add POSIX attributes into the global catalog if multiple domains are deployed
The GCS is the domain controller that hosts the global catalog for a forest. The global catalog
contains partial information of each domain in the forest. If you want LDAP-UX Client Services to
query GCS to decide which domain a queried data belongs to, then add the following POSIX
attributes into the global catalog:
For Windows 2003 R2 and Windows 2008 RFC 2307
•
uid
•
uidnumber
•
gidnumber
For detailed information on how to perform this task, refer to Section 4.6.6 (page 163).
For information about how LDAP-UX Client Services retrieves data from remote domains, see
“Windows Active Directory multiple domains” (page 159).
3.4.6 Configuring LDAP-UX Client Services for a Windows ADS environment
To configure the LDAP-UX Client Services, complete the steps in this section.
If you attempt to enable SSL or TLS support with LDAP-UX, you must configure the directory server
to support SSL or TLS and install the security database (cert8.db and key3.db) on your client
before you run the setup program. For SSL or TLS setup details, refer to Section 3.4.7 (page 151).
138
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
NOTE: The setup program has only been certified with HP-UX Directory Server version 8.1,
Red Hat Directory Server 8.0, Windows Server 2003 R2 Active Directory Server, and Windows
2008 Active Directory Server. For more information, see the LDAP-UX Integration B.05.00 Release
Notes.
3.4.6.1 Step 1: Install the PAM Kerberos product
LDAP-UX Client Services with Active Directory uses the Kerberos Authentication method. If not
already available on your system, you must install and configure PAM Kerberos. Some instructions
for doing this are included later in this section. Additional information can be found in the
Configuration Guide for Kerberos Client Products on HP-UX, available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX Kerberos Data Security Software)
To support integration with Active Directory Server, a specific version of the PAM-Kerberos product
is required. Do not use the default Kerberos product that is installed with your HP-UX 11i v2 or v3
OS. Install the appropriate version from the HP Software Depot at the location provided later in
this section. For information about version support and required patches, see the section titled
“Kerberos support on HP-UX 11i v2 or v3” in the LDAP-UX Integration Release Notes.
If you want to also use SASL/GSSAPI for proxied authentication, see the LDAP-UX Integration
Release Notes for the version of Kerberos Client and any patches that are required. Instructions
for configuring SASL/GSSAPI are included in Section 7.3 (page 196). You must add ipnodes
service information in the /etc/nsswitch.conf file as follows:
ipnodes: dns files.
NOTE:
For more information, see the Kerberos Client Release Notes available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX Kerberos Data Security Software)
Both "PAM Kerberos" (J5849AA) and "Kerberos Client" (KRB5CLIENT) products can be downloaded
from:
http://software.hp.com
They are available at the following specific locations:
http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=J5849AA
https://h20392.www2.hp.com/portal/swdepot/
displayProductInfo.do?productNumber=KRB5CLIENT
For any last-minute changes, see the Kerberos CLient Release Notes.
You also must install the required patch. For patch infomation, see the LDAP-UX Integration Release
Notes available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX LDAP-UX Integration Software)
For information about other steps that you might need to perform to set up Kerberos support, see
Section 3.4.2 (page 128).
3.4.6.2 Step 2: Run the setup program
This section describes in detail the steps you must take to configure LDAP-UX Client Services with
Windows 2003 R2 or 2008 Active Directory. In summary, you must run the setup program to
extend the profile schema into Active Directory and to create specific profile entries. The setup
program also creates the necessary files on your client system and configures the proxy user.
3.4 Customized installation (setup) for a Windows ADS environment
139
NOTE: When configuring and setting up LDAP-UX, you will likely be prompted for credentials
of an administrator. If you are asked to enter the credentials (password) of a user, make sure that
the connection between your client and the HP-UX system (where you are running setup) are secured
and not subject to network eavesdropping. One option to protect such communication might be
to use the ssh protocol when connecting to the HP-UX host being configured.
If you want to use SSL or TLS, you must perform the following tasks before you run the setup
program:
•
Ensure to have the certificate database files, cert8.db and key3.db, on your client system.
To create these database files using the certutil utility, see Section 2.4.6.4 (page 82).
NOTE: If you already have the certificate database files cert8.db and key3.db on your
client for your HP-UX applications, you can simply create a symbolic link /etc/opt/ldapux/
cert8.db that points to cert8.db, and /etc/opt/ldapux/key3.db that points to
key3.db.
•
If you choose to use TLS, set the enable_startTLS parameter to 1 in the /etc/opt/
ldapux/lldapux_client.conf file to enable TLS. To use SSL, set enable_startTLS
to 0 to disable TLS. By default, TLS is disabled. For more information about configuring LDAP-UX
Client Services with TLS or SSL support, see Section 2.4.6 (page 78).
•
You must install and configure PAM Kerberos product before you run the setup program.
For information about installing the PAM Kerberos product, see Section 3.4.6.1 (page 139).
•
Configure the Kerberos configuration file /etc/krb5.conf to specify the default realm, the
location of a KDC server and the logging file name. For information about configuring the
Kerberos configuration file, see Section 3.4.6.3 (page 149). For a sample of the /etc/
krb5.conf file, see “Sample /etc/krb5.conf file” (page 434).
•
Create a new proxy user, as described in Section 7.9.3 (page 242).
•
Configure the PAM Kerberos library, libpam_krb5.so.1 in the PAM configuration file,
pam.conf. For information about configuring this library and a sample PAM configuration
file, see “Sample PAM configuration (pam.conf) files ” (page 420).
1.
Log in as root and run the setup program:
cd /opt/ldapux/config
./setup
The setup program asks you a series of questions and usually provides default answers.
Press Enter to accept the default, or change the value and press Enter. At any point during
setup, press Control-b to return to the previous screen or press Control-c to exit setup.
NOTE: To use a local-only profile, run the setup program using the -l option . Use the
local-only profile for small deployments, testing purposes, and for environments where
administrators lack server administrative privileges.
2.
3.
4.
5.
Select Windows 2003 R2 or 2008 as your directory server (option 2).
Enter either the host name or IP address of the directory server where your profile exists, or
where you want to create a new profile.
Enter the port number of the previous specified directory server that you want to store the
profile, from “Configuration worksheet” (page 403). The default port number is 389.
The setup program verifies that the directory's profile schema has been extended with the
LDAP-UX Client Services object class DUAConfigProfile. This must be done once (the schema
140 Installing and configuring LDAP-UX Client Services for a Windows ADS environment
is shared with subsequently-configured client systems). For a detailed description of object
classes, see “LDAP-UX Client Services object classes” (page 406).
If the schema has already been extended, setup skips this step. Otherwise, to extend the
schema, enter the DN and password of a directory user who can extend the directory schema
(see “Configuration worksheet” (page 403)).
NOTE: If you ran the setup program using the -l option to maintain a local-only profile
(instead of having setup import the profile schema with LDAP-UX Client Services object class
DUAConfigProfile into your directory server), you are not asked whether to import the profile
schema; however, you are still prompted for the DN and password, as they are necessary if
the administrator wants to install other schema.
NOTE: Previous versions of Windows ADS required you to install SFU with Server for NIS
to extend Active Directory schema defined in RFC 2307; Windows 2003 R2 or 2008 Active
Directory Server already provides you with the RFC2307 schema, which is compliant with
the IETF RFC 2307 standard.
6.
If the new automount schema has already been imported, setup skips this step.
Otherwise, you are asked whether or not you want to install the new automount schema which
is based on RFC 2307-bis. Enter yes to extend the new automount schema into the directory
server. Enter no if you do not want to import new automount schema into the directory server.
The setup program skips to step 7 if you enter no.
7.
8.
For new profiles, the profile object must be created under the
ConfigurationNamingContext container, which is usually CN=system, <domain
root>, or it can be created under any path with an object class of Container. These
container entries must exist before any new profile entries can be created.
Enter either the DN of a new profile, or the DN of an existing profile, from “Configuration
worksheet” (page 403).
To display all the profiles in the directory, use a command like the following:
ldapsearch -D <directory user> -w <credentials> -s sub
-b "CN=System, DC=cup, DC=hp, DC=com" -h <Active Directory host>
-p <Active Directory port> objectclass=DUAConfigProfile
If you are using an existing profile, setup configures your client, downloads the profile, and
exits. In this case, continue by going to Section 3.4.6.3 (page 149).
9.
If you are creating a new profile, enter the DN and password of a directory user who can
create a new profile, from “Configuration worksheet” (page 403).
10. Select the default attribute map set (RFC 2307) by pressing Enter.
11. The setup program now detects the value of the enable_startTLS parameter. It also
verifies whether the cert8.db and key3.db certificate database files exist on your client
system. If these files do not exist, setup skips this step.
If the value of the enable_startTLS parameter is 0 (disabled) or undefined, you are asked
whether you want to use SSL or not. Enter yes if you want to use SSL for the secure
communication between LDAP clients and the Windows 2003 R2 or 2008 Active Directory
Server. Enter no if you don't want to use SSL. Continue to step 12.
Otherwise, if the value of the enable_startTLS parameter is 1 (enabled), you are asked
whether you want to use TLS or not. Enter yes if you want to use TLS for the secure
communication between LDAP clients and the Windows 2003 R2 or 2008 Active Directory
Server. Enter no if you don't want to use TLS. Continue to step 12.
3.4 Customized installation (setup) for a Windows ADS environment
141
12. Next, it will prompt you for selecting the authentication method for users to bind/authenticate
to the server. You must select the authentication method from one of the following prompts
based on your selection in step 11:
•
For TLS, you have a choice between SIMPLE (the default), or SASL/GSSAPI if you choose
to not enable TLS. However, you have a choice between SIMPLE with TLS (the default),
or SASL/GSSAPI with TLS if you choose to enable TLS. Skip to step 13.
•
For SSL, you have a choice between SIMPLE (the default), or SASL/GSSAPI if you choose
to not enable SSL. However, you have a choice between SIMPLE with SSL (the default),
or SASL/GSSAPI with SSL if you choose to enable SSL. Skip to step 13.
For an overview of the various authentication methods you can configure with LDAP-UX Client
Services, including their strengths and weaknesses, see Section 2.4.6.1 (page 79).
13. Next, enter the host name and port number of the directory where your account and group
data is, from “Configuration worksheet” (page 403). You can enter up to three hosts, to be
searched in order.
14. Enter the base DN where clients should search for name service data, from “Configuration
worksheet” (page 403).
15. Enter Yes when prompted to ask if you want to accept the remaining default configuration
parameters.
IMPORTANT: If you choose to accept remaining defaults, the memberUid attribute will be
used to define HP-UX group membership. However, by default, Windows uses the member
attribute to define group membership. If you want to share HP-UX groups with Windows
groups, supporting attribute mapping for dynamic groups or X.500 group membership services,
select No (do not accept remaining defaults) and modify the group service and change the
memberUid mapping to the member attribute.
16. Next, if you do not use SASL/GSSAPI authentication, skip this step and go to step 19.
Otherwise, it will prompt you for setting up principals used for SASL/GSSAPI authentication
as follows:
There are two ways to set up principals used for SASL/GSSAPI
authentication for LDAP-UX name service proxy authentication:
* Host or service principal defined in a keytab file (such as
/etc/krb5.keytab)
* Proxy principal defined in LDAP-UX proxy credential file
(/etc/opt/ldapux/pcred)
The principal defined in a keytab file can be shared among
several services, such as Kerberized Interface Service or
LDAP-UX using the host principal for authentication. The
LDAP-UX proxy principal is used solely for LDAP-UX.
It will prompt you for selecting the type of principal. Enter H if you want to use a host/service
principal. Enter P if you want to use a proxy principal. By default, the host or service principal
is used.
17. Next, it will prompt you for entering the path to the Kerberos keytab file. Enter the keytab file
if you want to specify the keytab file to be used. 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 will be used.
18. Next, it will prompt you for specifying an alternate principal name. If you do not want to use
the default principal name, enter an alternate principal name. For example,
host/hpntc20.cup.hp.com@CUP.HP.COM.
LDAP-UX uses ldapux/<FQHN>@<REALM> as the default service principal. If it does not exist,
the host/<FQHN>@<REALM> in the keytable file is the principal to be used.FQHN stands
for Fully Qualified Host Name.
142
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
19. For Active Directory, you must set access to the directory by proxy user because anonymous
binding does not grant enough access right to an Active Directory. Enter the DN and password
of your proxy user from “Configuration worksheet” (page 403).
20. Enter the maximum time in seconds the client should wait for binding to the directory before
aborting ("bind time"). Enter 0 for no time limit.
CAUTION: The default client binding time is 5 seconds. Depending on the load on your
directory, this default value might not be high enough to service all database requests.
21. Enter the maximum time in seconds the client should wait for directory searches before aborting.
Enter 0 for no time limit.
22. Enter the Profile Time To Live (TTL) value. This value defines the time interval between
automatic downloads (refreshes) of new configuration profiles from the directory. Automatic
refreshing ensures that the client is always configured using the newest configuration profile.
If you want to disable automatic refresh or manually control when the refresh occurs, enter a
value of 0. Refer to Section 3.5.6 (page 158)
23. In this step, the setup program initiates a dialog where you can remap the standard object
class attributes to alternate attributes. You might want to do this if the attributes in your directory
do not conform to the object classes defined in RFC 2307.
You can remap the attributes for any of the supported services. For a list of supported services,
see “LDAP-UX Client Services object classes” (page 406).
NOTE: Make sure that the attribute names are entered correctly to avoid unpredictable
results later.
For a description of the standard object classes and attributes, see RFC 2307 at:
http://www.ietf.org/rfc/rfc2307.txt
The setup program displays the following dialog:
LDAP-UX Client Services supports the following services:
1.Password
7.Networks
2.Shadow passwd
8.Hosts
3.Group
9.Services
4.PAM (Pluggable Authentication Module)10.Printers
5.RPC
11.Automount
6 Protocols
Each services uses a standard object class (defined by RFC 2307)
You can remap any of these attributes to alternate attributes.
Do you want to remap any of the standard RFC 2307 attributes?
If you want to remap object class attributes for any of the supported services, enter yes. For
information about remapping the attributes, see Section 3.4.6.2.1 (page 146).
Enter no to this prompt to continue to step 25 of the setup process.
24. In this step, the setup program initiates a dialog where you can create a custom search
descriptor. A custom search descriptor enables you to specify a different search location or
filter for retrieving entries for services supported by LDAP-UX Client. Each name service can
have up to three different search descriptors. A custom search descriptor consists of three
parts: a search base DN, scope, and filter.
NOTE: Custom search descriptors have no relevance for PAM Kerberos. PAM Kerberos is
the only certified authentication method for LDAP-UX Client Services with Active Directory.
Each service can have up to three different search descriptors. The client uses the search
descriptors in order until it finds what it is looking for.
3.4 Customized installation (setup) for a Windows ADS environment
143
NOTE: The default search base DN for all requests will be set to the previously specified
default search base DN (specified in step 14), usually the domain root. For very large
databases, search performance can be greatly increased by specifying custom search
descriptors. For example, to search user and group information, set the search base DN for
the user and group services to CN=Users, DC=cup, DC=hp, DC=com.
NOTE: If your search filters overlap, enumeration requests will result in duplicate entries
being returned. For example, if one search filter searched a subset of your organization and
a second search filter searched your entire organization, an enumeration request would return
duplicate entries. For information about enumeration requests and their impact on performance,
see Section 7.12.1.1 (page 247).
To begin the process to create custom search descriptors, the setup program prompts you
for the following information:
LDAP-UX Client Services supports the following services:
1.Password
7.Networks
2.Shadow passwd
8.Hosts
3.Group
9.Services
4.PAM (Pluggable Authentication Module)10.Printers
5.RPC
11.Automount
6 Protocols
You can create up to three custom search descriptors for each name
service to search different locations in the directory.
Do you want to create custom search descriptors? [No]:
Enter yes if you want to create custom search descriptors for any of the supported services.
Then enter the number of the service for which you want to create a custom search descriptor.
If, you do not want to create custom search descriptors, enter no to this prompt to continue
to step 25 of the setup process.
Creating the custom search filter for LDAP printer configurator service
LDAP-UX Client Services uses the printlpd search filter for the printer service as default. The
default object class, printerlpr, is not defined in the Windows Active Directory Server. To
use the LDAP printer configurator feature, you must execute the following procedures to change
default printerlpr object class for the printer service to the alternate object class to search
a different location in the directory. As an example, the following procedures are used to
change the default object class, printerlpr, to the alternate object class, printQueue:
a.
Type yes for the following question and press Enter:
Do you want to create custom search descriptors? [No]: yes Enter
b.
If you want to select the printer service, then enter 10 for the following question and press
Enter:
Specify the service you want to map? [0]: 10 Enter
c.
Next, a screen displays the following information:
To accept the default shown in brackets, press the Return key.
search base [dc=cup,dc=hp,dc=com]:
search scope (base, one, sub) [sub]
Search filter [(objectclass=printerlpr)]
If you want to create the alternate search filter printQueue for the printer service, enter
(objectclass=printQueue) for the following prompt and press Enter; otherwise
press Enter to accept the default search filter, objectclass=printerlpr:
Search filter [(objectclass=printerlpr)]: Enter (objectclass=printQueue)
144 Installing and configuring LDAP-UX Client Services for a Windows ADS environment
25. Enter yes to the question “Are you ready to create the Profile Entry?”, then press any key to
continue.
26. At this point, you will choose whether to configure Multiple Domains.
•
If you are not configuring Multiple Domains, enter no to the following question, then
continue to step 27:
Do you wish to configure multiple-domain support?
•
If you will be configuring Multiple Domains: enter yes to the question “Do you wish to
configure multiple-domain support?”
If you will be using Remote Domain Configuration, enter Yes to the next question “Do
you wish to configure a list of remote-domain profiles before attempting to use the Global
Catalog Server?” If you enter no, skip the remaining comments in this bullet, and proceed
to the next bulleted item.
You will loop through a series of screens that allow you to create as many profiles as you
want (one profile will be created for each pass through the loop).
Read the explanation paragraphs in the next screen carefully before answering the
question, then enter the appropriate domain name.
Next, you will return to step 3 through step 25 of this procedure for each profile to be
created.
When you have added as many profiles as you want, enter no to the question “Do you
wish to configure another profile for remote domain?”
•
If you will be using the GCS, enter yes to the next question “Do you wish to use ADS
Global Catalog Server to automatically resolve account information for users in remote
domains?”. If you enter no, then proceed to step 27.
Otherwise, you will return to step 3 through step 25 of this procedure to create the profile
for the GCS.
NOTE: When you configure the default search base for the GCS, you must make sure
that the base covers everything that you want to include. For example, for a forest
containing two domain trees (ca.hp.com and ny.hp.com), if you specify ca.hp.com as
the GCS search base, all data under the ny.hp.com domain tree will not be found. You
must specify hp.com to cover the entire forest. The setup tool provides the root domain
as the default search base. You must override it in order to cover the entire forest.
Read the instructions on each screen, carefully, as some of the answers to these questions
will be different than the last two times you went through these questions.
When you have finished building the profile for the GCS, configure the profiles for each
domain that is used by the global catalog search.
To configure the profiles for each domain that is used by the global catalog search, you
will again return to step 3 through step 25 of this procedure until you have configured
each profile needed by the global catalog search.
When this process is complete, continue to the next step.
27. Reply to the question, “Would you like to start/restart the LDAP-UX daemon?”.
Starting with LDAP-UX Client Services B.03.20 or later, the product daemon,
/opt/ldapux/bin/ldapclientd, must be running for LDAP-UX functions to work. With
LDAP-UX Client Services B.03.10 or previous releases, running the client daemon,
ldapclientd, is optional. Users must start the LDAP-UX daemon in order to use multiple
domains and X.500 features.
3.4 Customized installation (setup) for a Windows ADS environment
145
3.4.6.2.1 Remapping attributes for services
This section describes detailed procedures on how to perform attribute mappings for GECOS,
LDAP printer configurator, dynamic group, and X.500 group membership services.
Attribute mappings for GECOS
In a UNIX environment, the GECOS field of a user's password entry typically contains the user's
full name, telephone number, and building location. The RFC 2307 schema defines the gecos
attribute to contain these values. However, in a typical LDAP environment, cn (common name),
telephonenumber, l (location) are usually defined already and can be reused for the GECOS
information. The following is an example of how to remap the gecos attribute to these LDAP
attributes.
1.
Enter yes for the following question:
Do you want to remap any of the standard RFC 2307 attributes? [yes]:
yes Enter
2.
If you want to select the password service, then enter 1 for the following question:
Specify the service you want to map? [0]:1 Enter
3.
Next, a screen displays the following information:
Current Passwd service attribute names:
1.uid -> [uid]
2.uidnumber -> [uidnumber]
3.gidnumber -> [gidnumber]
4.loginshell -> [loginshell]
5.userpassword -> [*NULL*]
6.homedirectory -> [homedirectory]
7.gecos -> [gecos]
You can map the gecos attribute to multiple attributes
names by separating each by a space,
(for example: gecos -> gecos cn uid)
Enter 7 for the following question:
Specify the attribute you want to map. [0]:7 Enter
4.
Next, a screen displays the following request. Enter the LDAP attributes at the [gecos] prompt,
as shown
Type the name of the attribute gecos should be mapped to.
[gecos]: cn telephonenumber l
5.
Next, a screen displays the following information:
Current Passwd service attribute names:
1.uid -> [uid]
2.uidnumber -> [uidnumber]
3.gidnumber -> [gidnumber]
4.loginshell -> [loginshell]
5.userpassword -> [*NULL*]
6.homedirectory -> [homedirectory]
7.gecos -> [cn telephonenumber l]
You can map the gecos attribute to multiple attributes
names by separating each by a space,
(for example: gecos -> gecos cn uid)
Type 0 to exit this menu and return to the previous level, or
Specify the attribute you want to map. [0]:
To exit this menu, enter 0 for the following question:
Specify the attribute you want to map. [0]:0 Enter
146
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
Attribute mappings for LDAP printer configurator support
The default printer attributes, printer-name and printer-uri, are not defined in the Windows
Active Directory Server. You must define the alternate printer attributes and map them to
printer-name and printer-uri respectively. You must execute the following procedures to
remap the default printer attributes to alternate printer attributes. As examples, the following
procedures are used to remap the default printer attributes to the alternate attributes,
printerbyname and printer-resource.
1.
Enter yes for the following question:
Do you want to remap any of the standard RFC 2307 attributes? [yes]:
yes Enter
2.
If you want to select the printer service, then enter 10 for the following question:
Specify the service you want to map? [0]:10 Enter
3.
Next, a screen displays the following information:
Current Printer attribute names:
1.print-name ->[printer-name]
2.print-uri -> [printer-uri]
Specify the attribute you want to map. [0]:
Enter 1 for the following question:
Specify the attribute you want to map. [0]:1 Enter
4.
Next, enter printbyname to map to the printer-name attribute:
printer-name -> printerbyname Enter
5.
Next, a screen displays the following information:
Current Printer attribute names:
1.printer-name ->[printerbyname]
2.printer-uri -> [printer-uri]
Specify the attribute you want to map. [0]:
If you want to specify the attribute to map to the printer-uri attribute, then enter 2 for the
following question:
Specify the attribute you want to map. [0]: 2 Enter
6.
Next, enter the attribute printer-resource to map to the printer-uri attribute:
printer-uri -> printer-resource Enter
7.
Next, a screen displays the following information:
Current Printer attribute names:
1.printer-name ->[printer-name]
2.printer-uri -> [printer-resource]
Specify the attribute you want to map. [0]:
To exit this menu, enter 0 for the following question:
Specify the attribute you want to map. [0]:0 Enter
Attribute mappings for dynamic group support
To enable dynamic group support, you must remap the default group member attribute, memberuid,
to msDS-AzLDAPQuery (for Windows Active Directory Server). For detailed information about
dynamic group support, see “Dynamic group support” (page 173).
Use the following steps to remap the memberuid attribute to the dynamic group attributes,
msDS-AzLDAPQuery (assuming that the directory server is Windows 2003 R2 ADS):
3.4 Customized installation (setup) for a Windows ADS environment
147
1.
Enter yes for the following question:
Do you want to remap any of the startdard RFC 2307 attributes? [yes]:
yes Enter
2.
Select the group service by entering 3 for the following question:
Specify the service you want to map? [0]: 3
3.
Next, a screen displays the following information:
Current Group attribute names:
1.cn ->[cn]
2.gidnumber -> [gidnumber]
3.memberuid -> [memberuid]
4.userpassword -> [userPassword]
Specify the attribute you want to map. [0]:
If you want to specify the attribute to map to memberuid, then enter 3 for the following
question:
Specify the attribute you want to map? [0]: 3 Enter
4.
Enter the attribute msDS-AzLDAPQuery that you want to map to the memberuid attribute:
memberuid —> msDS-AzLDAPQuery Enter
5.
Next, a screen displays the following information:
Current Group.attribute names:
1.cn ->[cn]
2.gidnumber -> [gidnumber]
3.memberuid -> [msDS-AzLDAPQuery]
4.userpassword -> [userPassword]
Specify the attribute you want to map. [0]:
To exit this menu, enter 0 for the following question:
Specify the attribute you want to map. [0]: 0 Enter
Attribute mappings for X.500 group membership support
If you configure x.500 group membership support, you must remap the group member attribute
to member or uniquemember instead of using the default attribute, memberuid.
If you set up X.500, execute the following steps for attribute mappings:
1.
Enter yes for the following question:
Do you want to remap any of the startdard RFC 2307 attributes? [yes]:
yes Enter
2.
Select the group service by entering 3 for the following question:
Specify the service you want to map? [0]: 3 Enter
3.
Enter 3 for the following question:
Specify the attribute you want to map? [0]: 3 Enter
4.
Enter the attributes you want to map to the member attribute:
[memberuid]: member Enter
148
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
NOTE: LDAP-UX supports DN-based (X.500 style) membership syntax. This means that you
do not need to use the memberUid attributes to define the members of a POSIX group. Instead,
you may use either the member or uniqueMember attribute. LDAP-UX can convert from the
DN syntax to the POSIX syntax (an account name).
For ADS, the typical member attribute would be either memberUid or preferably the member
attribute.
5.
Follow the prompts to finish the setup.
3.4.6.3 Step 3: Configure your HP-UX machine to authenticate using PAM Kerberos
1.
Create /etc/krb5.conf, the Kerberos configuration file that specifies the default realm,
the location of a KDC server, and the logging file names. The Kerberos client depends on the
configuration to locate the KDC of the realm. The following is an example of /etc/krb5.conf
which has the realm CUP.HP.COM, and machine myhost.cup.hp.comas KDC:
[libdefaults]
default_realm = CUP.HP.COM
default_tgs_enctypes = DES-CBC-CRC
default_tkt_enctypes = DES-CBC-CRC
ccache_type = 2
[realms]
CUP.HP.COM = {
kdc = MYHOST.CUP.HP.COM:88
kpasswd_server = MYHOST.CUP.HP.COM:464
admin_server = myhost.cup.hp.com:749
}
[domain_realm]
.cup.hp.com = CUP.HP.COM
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
NOTE: The permissions of the /etc/krb5.conf file should be set to 644 and ownership
should be root user.
For more information about the /etc/krb5.conffile, see “Sample /etc/krb5.conf file”
(page 434).
2.
For Multiple Domains:
For each domain you configure in LDAP-UX, you must add its KDC entry into the [realms]
section of the /etc/krb5.conf file. In the [libdefaults] section, the following line is also
added:
ldapux_multidomain = 1
For a sample file that supports two domains, see “Sample /etc/krb5.conf file” (page 434).
3.
Add the Kerberos services to the/etc/services file if they do not exist yet. A Kerberos
client requires the following entries in the /etc/services file for the Kerberos PAM services:
kerberos5
kerberos5
kerberos-sec
kerberos-sec
kerberos
kerberos
klogin
kshell
kerberos-adm
kerberos-adm
88/udp
88/tcp
88/udp
88/tcp
750/udp
750/tcp
543/tcp
544/tcp
749/tcp
749/udp
kdc
kdc
kdc
kdc
kdc
kdc
cmd
#
#
#
#
#
#
#
#
#
#
Kerberos
Kerberos
Kerberos
Kerberos
Kerberos
Kerberos
Kerberos
Kerberos
Kerberos
Kerberos
V5 kdc
V5 kdc
V5 kdc
V5 kdc
V5 kdc
V5 kdc
rlogin -kfall
remote shell
5 admin/changepw
5 admin/changepw
3.4 Customized installation (setup) for a Windows ADS environment
149
krb5_prop
754/tcp
kerberos-adm 464/udp
kerberos-cpw 464/tcp
4.
Add a host key to the /etc/krb5.keytab file. The keytab file is the one described in the
previous section on Windows 2003 R2 or 2008 using ktpass. You must securely transfer
the keytab file previously created to your HP-UX machine and name it krb5.keytab in the
/etc directory. If you already have an existing/etc/krb5.keytab file, merge the new
keytab file with the existing one. The ktutil tool is provided with the Kerberos product for
you to maintain the keytab file.
NOTE:
5.
6.
# Kerberos slave propagation
# Kerberos Password Change protocol
# Kerberos Password Change protocol
The keytab file should only be readable by the root user.
Synchronize the HP-UX clock to the Windows 2003 R2 or 2008 clock. These must be
synchronized within two minutes. You can run Network Time Synchronizer to synchronize
both clocks. If the tool is not available, you can manually synchronize them by setting
"Date/Time Properties" on Windows 2003 R2 or 2008 and running /etc/set_parms
date_time on HP-UX.
Configure /etc/pam.conf to use PAM Kerberos authentication. This file is the PAM
configuration file that specifies PAM service modules for PAM applications. To use PAM
Kerberos as an authentication module, edit /etc/pam.conf to include the PAM Kerberos
library /usr/lib/security/libpam_krb5.so.1 for all four services: authentication,
account management, session management, and password management. Sample PAM
configuration files and details about their structure and configuration are provided in “Sample
PAM configuration (pam.conf) files ” (page 420).
NOTE: The sample files reflect the recommendation to keep the root user in /etc/passwd
local on each client machine, and to allow for local account management of the root user.
This helps guarantee local access to the system in case the network is down. Other conditions
are necessary to guarantee local access, as discussed in “Sample PAM configuration (pam.conf)
files ” (page 420).
For more information, see the pam(3) and pam.conf(4) manpages, and the Managing Systems
and Workgroups: A Guide for HP-UX System Administrators document at the following location:
http://www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
For a list of all steps that you might need to perform to set up Kerberos support, see Section 3.4.2
(page 128).
3.4.6.4 Step 4: Configure NSS
NSS needs to be modified to retrieve your account and group information from Active Directory.
Save a copy of the file /etc/nsswitch.confand edit the original to specify the LDAP name
service and other name services you want to use. For an example, see /etc/nsswitch.ldap.
You could just copy /etc/nsswitch.ldap to/etc/nsswitch.conf. For more information,
see the nsswitch.conf(4) manpage.
3.4.6.5 Step 5: Configure the PAM Authorization Service Module (PAM_AUTHZ)
This step is optional. You do this step only if you want to use PAM_AUTHZ to control access rules
defined in the policy file, /etc/opt/ldapux/pam_authz.policy. LDAP-UX Client Services
provides a sample policy file, /etc/opt/ldapux/pam_authz.policy.template. This sample
file shows you how to configure the policy file to work with PAM_AUTHZ. You can copy this sample
file and edit it using the correct syntax to specify the access rules you want to authorize or exclude
from authorization. For more detailed information on how to configure the policy file, see Section 7.4
(page 199).
150
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
3.4.6.6 Step 6: Configure the disable login flag
Optionally, configure the disable login flag (disable_uid_range).
The default is to allow all users stored in the directory to log in. To disallow specific users to log
in to a local system, you can configure the disable_uid_range flag in /etc/opt/ldapux/
ldapux_client.conf file, as described in Section 3.5.4.1 (page 157).
3.4.7 Configuring LDAP-UX Client Services with SSL or TLS support
The LDAP-UX Client Services supports either SSL (Secure Socket Layer) or TLS (Transport Layer
Security) to secure communication between LDAP clients and the Active Directory Servers.
With SSL, an encrypted connection can be established on an encrypted port, 636. The LDAP-UX
Client Services supports SSL with password as the credential, using either simple bind or
SASL/GSSAPI authentication to ensure confidentiality and data integrity between clients and
servers. In addition, SSL/TLS can be used to validate the identity of the Windows Active Directory
Server if the privacy of the server’s and CA’s private keys can be assured. The domain administrator
can choose the authentication mechanism.
The LDAP-UX Client Services supports SSL communication with Microsoft Windows 2003 R2 and
2008 Active Directory Server (ADS), and HP-UX Directory Server 8.1 (or later), and Red Hat
Directory Server 8.0. For detailed information about how to enable SSL communication over LDAP
for your Windows Active Directory Server, see the Microsoft Knowledge Base Article at:
http://support.microsoft.com/kb/321051
Starting with LDAP-UX Client Services B.04.10, the product supports a new extension operation
of TLS protocol called startTLS to secure communication between LDAP clients and the Windows
Active Directory Server. An encrypted session can be established on an unencrypted port, 389.
If an encrypted port is used, it will fail to establish the secure connection. The TLS protocol provides
administrators better flexibility for using TLS in their environment by allowing the use of an
unencrypted LDAP port for communication between the clients and the server. LDAP-UX supports
TLS with password as the credential, using either simple bind or SASL/GSSAPI authentication to
ensure confidentiality and data integrity between clients and servers.
The LDAP-UX Client Services supports TLS communication with Microsoft Windows 2003 R2 or
2008 Active Directory Server (ADS), HP-UX Directory Server 8.1 (or later), and Red Hat Directory
Server 8.0.
For more information about configuring LDAP-UX Client Services with SSL or TLS support, see
Section 2.4.6.2 (page 80) and the ensuing sections.
3.5 Postinstallation configuration tasks
This section includes tasks you can perform after performing your guided or customized installation.
3.5.1 Importing name service data into your directory
The next step is to import your user, group, and other services data into your Active Directory.
When planning to import your data, consider the following:
•
If you are using NIS, the LDAP-UX migration scripts take your NIS maps and generate LDIF
files. These scripts can then import the LDIF files into your directory, creating new entries in
the directory.
If you are not using NIS, the LDAP-UX migration scripts can take your user, group, and other
data from files, generate LDIF, and import the LDIF into your directory to work with Windows
Services for Unix.
•
If you integrate the name service data into your directory, the migration scripts might be helpful
depending on where you put the data in your directory. You could use them just to generate
LDIF, edit the LDIF, then import the LDIF into your directory. For example, you could manually
3.5 Postinstallation configuration tasks
151
add the unixAccount attributes to your existing entries under CN=Users and add their HP-UX
information there.
•
Ensure that the user and group numbers to be imported or migrated do not collide with those
already on the HP-UX host (see Section 3.5.1.1 (page 152)).
3.5.1.1 Prevent user and group number collisions with those already on the HP-UX host
Before you import users into Windows ADS, make sure no users or groups to be managed in the
directory server collide with users or groups managed in the /etc/passwd and /etc/group
files on the HP-UX hosts being managed in the domain. To avoid UID number or GID number
collisions, a best practice is to establish separate UID and GID number ranges used on the HP-UX
host from those that will be used for directory entries. For example, all UID numbers less than 1000
could be reserved for entries in the /etc/passwd and /etc/group files.
3.5.1.2 Steps for importing name service data
To import your user, group, and other services data into your directory, complete the following
steps, modifying them as necessary.
1.
Decide which migration method and scripts you will use.
Migration scripts are provided to ease the task of importing your existing name service data
into your Active directory. For a complete description of the scripts, what they do, and how
to use them, see Section 9.6 (page 383). Modify the migration scripts, if needed.
2.
3.
4.
Back up your directory.
Run the migration scripts.
If the migration method that you used did not already import your data, use ldapmodify to
import the LDIF file into your directory.
3.5.2 Verifying LDAP-UX Client Services for Single Domain
For simple ways to verify the installation and configuration of your LDAP-UX Client Services, see
Section 2.5.2 (page 91). You might need to do more elaborate and detailed testing, especially if
you have a large environment.
3.5.3 Enabling AutoFS support
AutoFS is a client-side service that automatically mounts appropriate file systems when users request
access to them. If an automounted file system has been idle for a period of time, AutoFS unmounts
it. AutoFS uses name services such as files or NIS to store and manage AutoFS maps.
LDAP-UX Client Services B.04.10 and later supports the automount service under the AutoFS
subsystem. This feature enables users to store AutoFS maps in an Windows 2003 R2 or 2008
Active Directory Server (ADS).
3.5.3.1 Automount schema
This section describes the automount schema based on RFC 2307-bis.
This schema defines automountMap and automount structures to represent AutoFS maps and
their entries in the directory server. AutoFS maps are stored in the directory server using structures
defined by this schema.
This automount schema is not loaded in the Windows 2003 R2 or 2008 Active Directory Server.
If you are installing LDAP-UX B.04.10 or later on your client system, the setup program will import
the automount schema into your Active Directory Server. If you previously configured LDAP-UX
B.04.00 or a previous version, and are now updating the product to version B.04.10 or later, you
must rerun the setup program to import the automount schema into the directory server. The
subsequent client systems do not need to rerun the setup program.
The following shows the automount schema based on RFC 2307-bis in the LDIF format:
152
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
objectClasses: ( 1.3.6.1.1.1.2.16
Name 'automountMap'
DESC 'AutomountMap
SUP top STRUCURAL
MUST ( automountMapName & cn )
MAY description
X-ORIGIN 'user defined' )
objectClasses: ( 1.3.6.1.1.1.2.17
NAME 'automount'
DESC 'Automount'
SUP top STRUCTURAL
MUST ( automountKey & automountInformation & cn )
MAY description
X-ORIGIN 'user defined' )
attributeTypes: ( 1.3.6.1.1.1.1.31
NAME 'automountMapName
DESC 'automountMapName'
EQUALITY caseExactIA5Match
SYNTAX 2.5.5.5 SINGLE-VALUE
X-ORIGIN 'user defined')
attributeTypes: ( 1.3.6.1.1.1.1.32
NAME 'automountKey'
DESC 'AutomountKey'
EQUALITY caseExactIA5Match
SYNTAX 2.5.5.5 SINGLE-VALUE
X-ORIGIN 'user defined' )
attributeTypes: ( 1.3.6.1.1.1.1.33
NAME 'automountInformation'
DESC 'AutomountInformation'
EQUALITY caseExactIA5Match
SYNTAX 2.5.5.5 SINGLE-VALUE
X-ORIGIN 'user defined' )
Example of a direct AutoFS map based on the automount schema
The following shows an example of a direct AutoFS map, auto_direct, stored in the Windows
Active Directory Server, using the automount schema:
dn:cn=auto_direct,dc=nishpind
objectClass: top
objectClass: automountMap
automountMapName: auto_direct
cn: auto_direct
dn:cn=/mnt_direct/usr1, cn=auto_direct, dc=nishpind
objectClass: top
objectClass: automount
automountInformation: hostA: /tmp
automountKey: /mnt_direct/usr1
cn: /mnt_direct/usr1
dn:cn=/mnt_direct/usr2, cn=auto_direct, dc=nishpind
objectClass: top
objectClass: automount
automountInformation: hostB: /tmp
automountKey: /mnt_direct/usr2
cn: /mnt_direct/usr2
3.5.3.2 Configuring NSS to enable LDAP support for AutoFS
Configure NSS to enable the LDAP support for AutoFS.
3.5 Postinstallation configuration tasks
153
You can save a copy of /etc/nsswitch.conf file and modify the original to add LDAP support
to the automount service. See /etc/nsswitch.ldap for a sample.
The following shows the sample file, /etc/nsswitch.ldap.
NOTE: Windows ADS implementations ignore the netgroup and publickey service declarations
in this file.
passwd:
group:
hosts:
networks
protocols:
rpc:
publickey:
netgroup:
automount:
aliases:
services:
files ldap
files ldap
dns files ldap
files ldap
files ldap
files ldap
ldap [NOTFOUND=return] files
files ldap
files ldap
files
files ldap
3.5.3.3 Configuring automount caches
To improve performance of automount services, the ldapclient daemon, ldapclientd, caches
automount maps and automount entries in the maps to reduce the LDAP-UX client response time
while retrieving information for automount maps and entries.
To configure automount caches, set the parameters defined in the [automountMap] and
[automount] sections of the /etc/opt/ldapux/ldapclientd.conf file. For more
information, see Section 7.1.3 (page 184).
3.5.3.4 AutoFS migration scripts
This section describes the migration scripts that can be used to migrate your AutoFS maps from
files to LDIF files. After LDIF files are created, you can use the ldapmodify tool to import LDIF
files to your directory server. These migration scripts use the automount schema defined in RFC
2307-bis to migrate the AutoFS maps to LDIF. You must import the automount schema into your
directory server before you use these migration scripts to migrate AutoFS maps.
Table 14 describes the migration scripts located in the /opt/ldapux/migrate/ads directory:
Table 14 AutoFS migration scripts for Windows ADS
Migration Script
Description
migrate_automount_ads.pl
Migrates AutoFS maps from files to LDIF.
migrate_nis_automount_ads.pl
Migrates AutoFS maps form the NIS server to LDIF.
3.5.3.4.1 Environment variables
When you use the AutoFS migration scripts to migrate AutoFS maps, set the following environment
variables:
LDAP_BASEDN
The base distinguished name of the directory server that the AutoFS maps
are to be placed in.
NIS_DOMAINNAME
This variable specifies the fully qualified name of the NIS domain where
you want to migrate your data from. This variable is optional. If the NIS
domain name is not specified, LDAP-UX uses the value of the NIS_DOMAIN
parameter configured in the /etc/rc.conf.d/namesvrs file.
This variable is only used by the migrate_nis_automount.pl script.
154 Installing and configuring LDAP-UX Client Services for a Windows ADS environment
Examples
The following command sets the base DN to "dc=example, dc=hp, dc=com":
export LDAP_BASEDN="example.hp.com"
The following command sets the fully qualified name of the NIS domain to "example.hp.com":
export NIS_DOMAINNAME="example.hp.com"
3.5.3.4.2 General syntax for migration scripts
The migration scripts use the following general syntax:
scriptname inputfile outfile
where
scriptname
Is the name of the particular script you are using.
inputfile
Is the fully qualified file name of the appropriate AutoFS map that you want to
migrate. For example, /etc/auto_master.
outputfile
This is optional and is the name of the file where the LDIF is written. stdout is
the default output.
3.5.3.4.3 migrate_automount_ads.pl script
This script, found in /opt/ldapux/migrate/ads, migrates the AutoFS maps from files to LDIF.
Syntax
scriptname inputfile outputfile
Examples
The following commands migrate the AutoFS map /etc/auto_direct to LDIF and place the
results in the /tmp/auto_direct.ldif file:
export LDAP_BASEDN="dc=nishpind"
migrate_automount_ads.pl /etc/auto_direct /tmp/auto_direct.ldif
The following shows an example of the /etc/auto_direct file:
#local mount point
/mnt/direct/lab1
/mnt/direct/lab2
remote server:directory
hostA:/tmp
hostB:/tmp
The following shows the resulting /tmp/auto_direct.ldif file:
dn:cn=auto_direct,dc=nishpind
objectClass: top
objectClass: automountMap
automountMapName: auto_direct
cn: auto_direct
dn:cn=/mnt_direct/lab1,cn=auto_direct,dc=nishpind
objectClass: top
objectClass: automount
automountInformation:hostA:/tmp
automountKey: /mnt_direct/lab1
cn: /mnt_direct/lab1
dn:cn=/mnt_direct/lab2,cn=auto_direct,dc=nishpind
objectClass: top
objectClass: automount
automountInformation:hostB:/tmp
automountKey: /mnt_direct/lab2
cn: /mnt_direct/lab2
3.5 Postinstallation configuration tasks
155
You can use the /opt/ldapux/bin/ldapmodify tool to import into the directory server the
LDIF file /tmp/auto_direct.ldif that you just created. For example, the following command
imports the /tmp/auto_direct.ldif file to the LDAP base DN "dc=nishpind" in the directory
server LDAPSERV1:
/opt/ldapux/bin/ldapmodify -a -h LDAPSERV1 -D "cn=administrator, cn=users, dc=nishpind" \
-w <passwd> -f /tmp/auto_direct.ldif
where options are:
-a
Adds a new entry into the directory server
-h
Specifies the directory server host name
-D
Specifies the Distinguish Name (DN) of the directory manager
-w
Specifies the password of the directory manager
-f
Specifies the LDIF file to be imported into the directory server
3.5.3.4.4 migrate_nis_automount_ads.pl script
This script, found in /opt/ldapux/migrate/ads, migrates the AutoFS maps from the NIS server
to LDIF.
Syntax
scriptname inputfile outputfile
Examples
The following commands migrate the AutoFS map /etc/auto_indirect to LDIF and place the
results in the /tmp/auto_indirect.ldif file:
export LDAP_BASEDN="dc=nisserv1"
export NIS_DOMAINNAME="example.hp.com"
migrate_nis_automount_ads.pl /etc/auto_indirect
/tmp/auto_indirect.ldif
The following shows an example of the /etc/auto_indirect file:
#local mount point
lab1
lab2
remote server:directory
hostA:/tmp
hostB:/tmp
The following shows the resulting /tmp/auto_indirect.ldif file:
dn:cn=auto_indirect,dc=nisserv1
objectClass: top
objectClass: automountMap
automountMapName: auto_indirect
cn: auto_indirect
dn:cn=lab1,cn=auto_indirect, dc=nisserv1
objectClass: top
objectClass: automount
automountInformation: hostA:/tmp
automountKey: lab1
cn: lab1
dn:cn=lab2,cn=auto_indirect,dc=nisserv1
objectClass: top
objectClass: automount
automountInformation: hostB:/tmp
automountKey: lab2
cn: lab2
You can use the /opt/ldapux/bin/ldapmodify tool to import into the directory server the
LDIF file /tmp/auto_indirect.ldif that you just created. For example, the following command
imports the /tmp/auto_indirect.ldif file to the LDAP base DN "dc=nisserv1" in the
directory server LDAPSERV1:
156
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
/opt/ldapux/bin/ldapmodify -a -h LDAPSERV1 -D "cn=administrator, cn=users, dc=nishpind" \
-w <passwd> -f /tmp/auto_indirect.ldif
3.5.4 Controlling user access to the system through LDAP
By default, all users stored in the directory server are allowed to log in to the local HP-UX client
system. LDAP-UX provides several ways to increase the security level to prevent unwanted users
from logging in to the local system through LDAP, including the following:
•
Using the PAM_AUTHZ service module to control login access, as described elsewhere,
inSection 7.4 (page 199)
•
Disabling logins to the local system from specified LDAP users by configuring the
disable_uid_range flag in the local client's startup file (/etc/opt/ldapux/
ldapux_client.conf), as described in Section 3.5.4.1 (page 157)
3.5.4.1 Using the disable_uid_range flag to prevent access to the local system by unwanted users
To disallow specific users to log in to a local system, you can set the disable_uid_range flag
in the local client's startup file/etc/opt/ldapux/ldapux_client.conf. The flag is in the
[NSS] section of the file. (HP recommends that you do not edit the [profile] section of the file.)
The following example shows the portion of the file containing the flag:
#
# You can disable specific users so that they are unable to log in
# through the LDAP server by uncommenting the "disable_uid_range"
# flag and adding the UID numbers you want to disable. For example:
#
#
disable_uid_range=0-100,120,300-400
#
# Note: The list of UID numbers must be on one line and the maximum
# number of ranges is 20. The system will ignore the typos and white spaces.
#
#disable_uid_range=0
To enable and configure the flag, first save a copy of the /etc/opt/ldapux/
ldapux_client.conf file and edit the original. Then uncomment the flag (remove the #) and
enter the UID ranges. For example, the flag might look like this:
disable_uid_range=0-100, 300-450, 89
Another common example would be to disable root access, in which case the flag would look like
this: disable_uid_range=0.
NOTE:
•
White spaces between numbers are ignored.
•
Only one line of the list is accepted; however, the line can be wrapped.
•
The maximum number of ranges is 20.
When the disable_uid_range is turned on, the disabled UIDs are not displayed when you run
commands such as pwget, listusers, and logins.
NOTE: The passwd command may still allow you to change a password for a disabled user
when alternative authentication methods that are not controlled by LDAP (such as PAM Kerberos)
are used.
3.5.5 Configuring subsequent client systems
Once you have configured your directory and one client system, you may configure subsequent
client systems by performing the steps described in Section 2.5.7 (page 110). If you used autosetup
to create your LDAP-UX domain, you should continue to use autosetup to configure subsequent
clients; to do this, you can run autosetup in silent mode, as described in Section 3.3.4.2
(page 127).
3.5 Postinstallation configuration tasks
157
3.5.6 Downloading the profile periodically
Using the setup program, you can define a time interval after which the current profiles are being
automatically refreshed. The start time for this periodic refresh is determined by the time the setup
program completes and the value defined for ProfileTTL. Therefore, setup does not allow
you to define a specific time of day when the profiles should be downloaded (refreshed). (For more
detailed information, refer to the ldapclientd(1m) manpage.) If you want to manually determine
the time when the profile is downloaded, follow the steps described in Section 2.5.8 (page 111).
NOTE: Starting with the B.03.00 release, if multiple domains are configured, there will be a
profile for each domain rather than just one profile for the entire system.
3.6 Unconfiguring LDAP-UX (removing the host from the ADS domain)
To remove the LDAP-UX configuration (remove the host from the Windows ADS domain), use the
netleave command located in /opt/ldapux/config. This command supports the following
command-line options:
-D privileged_user_DN
Specifies the distinguished name (DN) of a user who has sufficient
directory server privileges to remove a computer account. This
typically specifies the domain administrator's distinguished name
(DN). An example of a DN for this variable is
CN=Administrator,CN=Users,DC=ldaptest,DC=west,DC=com.
-j password_filename
Specifies a file that includes the bind password for the user
specified with the -D option. Specifying this file enables the
netleave script to run without prompting you for the password.
-v n
Specifies verbose level for debugging purposes, with n specifying
one of the following: 0 (turns off verbose mode), 1, 2, or 3
(specifies the highest level of verbosity).
The following is an example showing the script being run in interactive mode. In this example, the
defaults are taken for the user with privileges to remove the host. The user enters the password.
# /opt/ldapux/config/netleave Enter
Removing this host from the "nwest.acme.com" domain requires
permissions of Windows administrator (or a user with sufficient privilege
to delete the computer account). Please enter the DN of a Windows
administrator or press Return for the default value
[CN=Administrator,CN=Users,DC=nwest,DC=acme,DC=com]: Enter
Please enter the administrator's password: Enter
Unediting the configuration file for the name-service switch...
Successfully unedited the "/etc/nsswitch.conf" file...
editing /etc/pam.conf to unconfig ldap...
Successfully un-edited the "/etc/pam.conf" file...
Your LDAP-UX client has been successfully unconfigured.
158
Installing and configuring LDAP-UX Client Services for a Windows ADS environment
4 Windows Active Directory multiple domains
This chapter contains information specific to multiple domains in a Windows ADS environment. If
you do not store and group information in multiple domains in such an environment, you may skip
this chapter.
4.1 Domain term definitions
The following section defines common multiple domain terms.
4.1.1 Multiple domains
Supported multiple domains refer to domains in an ADS forest. Domains from different forests are
not supported.
4.1.2 Local domains
Local domain is the first domain configured using the LDAP-UX setup tool after choosing Windows
2003 R2 or 2008 ADS as your directory server. The local domain is also the only domain
configured if you select a single domain to store your POSIX information. When LDAP-UX retrieves
POSIX information, the local domain is always the first domain searched. If the entry is found in
the local domain, the search stops. Therefore, the local domain is the primary domain where
frequently accessed information should be stored. Its profile configuration is /etc/opt/ldapux/
ldapux_profile.bin.
4.1.3 Remote domains
Remote Domains are all domains in the forest other than the local domain. When multiple domain
support is selected during setup, you are guided to configure profiles for remote domains. When
LDAP-UX cannot find data from the local domain, remote domains are searched.
4.1.4 Global Catalog Server
Global Catalog Server (GCS) is the domain controller that hosts the global catalog for a forest.
The global catalog contains partial information for each domain. LDAP-UX uses this feature to
determine the domain to which queried data belongs. The root domain is the default GCS.
4.2 Retrieving data from a remote domain
LDAP-UX can retrieve data from a remote domain using three methods:
•
Remote Domain Configuration
This method enables you to configure a sequence in which LDAP-UX searched remote domains.
If you know what domains your data resides in, you can use setup to configure a remote
domain sequence. When LDAP-UX does not find data in the local domain, all remote domains
are searched in the specified order until the data is found.
•
GCS
This method enables you to configure LDAP-UX to search the GCS first. If you are not sure in
which domains the data resides, you may configure LDAP-UX to search the GCS first to
determine in which domain the requested data resides, then connect to that specific domain
controller to retrieve complete POSIX information. However, by default, the global catalog
does not contain any POSIX attributes. You should add some POSIX attributes into the global
catalog. For information, refer to Section 4.6.6 (page 163).
4.1 Domain term definitions
159
You also need a configuration profile that specifies which server (and port) serves as the GCS.
The GCS profile is stored locally in /etc/opt/ldapux/domain_profiles/
ldapux_profile.bin.gc.
•
Both Remote Domain Configuration and GCS
If you are sure that you need some specific remote domains, but don't want to exclude other
domains, you may configure both, specifying remote domains and configuring usage of the
GCS. When both are configured, LDAP-UX searches in this sequence:
1.
2.
3.
4.
local domain
remote domains in the order of configuration
GCS to determine in which domain the data resides
specific domain determined by GCS
4.2.1 Choosing Remote Domain Configuration or GCS
In order to limit the scope of the LDAP-UX remote domain search to certain domains of the forest,
configure those specific domains using the remote domain configuration. This is the only way to
exclude some domains from the LDAP-UX remote domain search. For example, if your forest contains
DomainA, DomainB, DomainC, and DomainD, but you just want users in DomainA and DomainB
to log into HP-UX, configure either DomainA or DomainB as your local domain, then another
domain as the remote domain during setup, and choose not to use the GCS.
If you want to cover the entire forest in the LDAP-UX remote domain search scope, you can either
explicitly configure every domain (one as "local," and the rest as "remote"), or configure the local
domain and the GCS to support multiple domains. When you choose to configure usage of both
remote domain and GCS support, LDAP-UX searches remote domains, then queries the GCS.
For detailed steps on how to configure multiple domains using the setup tool, see Section 3.4.6
(page 138).
4.3 Downloading an automatic profile
When you select the GCS to retrieve data from remote domains, it is not necessary to specify which
domains LDAP-UX is to search. However, you should create a profile for every domain in the forest
so LDAP-UX has the information about where and how to establish the connection with their domain
controllers in the forest.
Not every LDAP-UX client has to create the profile entry in the directory. The LDAP-UX configuration
profile created by setup and saved in the directory server (ADS domain controller) is designed
to be shared by many clients. In previous releases, when the first LDAP-UX client created the profile
entry in the directory, other LDAP-UX clients still had to download it from the server. In the B.03.00
release, LDAP-UX can automatically download the profile if the following two conditions are met:
•
If the first LDAP-UX creating the profile entry in the directory uses a standard profile path (for
example, CN=ldapuxprofile,CN=system,DC=ca,DC=hp,DC=com)
•
If LDAP-UX clients use the same DNS for ADS, which can support service location resource
records (SRVs) described in RFC 2052
When an LDAP-UX client binds to ADS, if the profile does not exist locally, LDAP-UX queries DNS
for the server and port information, then connects to the server to download the profile entry using
the standard path. This feature eliminates administration costs to set up agreements between
domains. As long as the first LDAP-UX client creates the profile entry using the standard path, the
following LDAP-UX clients automatically download it.
160 Windows Active Directory multiple domains
NOTE: By default, the cn=system,DC=myorg,DC=mycom,DC=com configuration container
only exists in the root domain. To create the standard profile path for LDAP-UX, manually create
it in each domain using ADSI Edit before running the setup tool to configure profiles.
4.4 Understanding the ldapux_client.conf configuration file
When you set up LDAP-UX, the /etc/opt/ldapux_client.conf file is automatically created
to specify where the directory is located, the profile data path, and the logging configuration. In
previous releases, typically, this file has the following contents:
Service: NSS
LDAP_HOSTPORT="192.1.2.3:389"
PROFILE_ENTRY_DN="cn=caprofile,
cn=system,DC=ab,DC=ny,DC=com"
PROGRAM="/opt/ldapux/config/create_profile_cache"
With ADS multiple domain support, this file has been modified to contain more information. A
new keyword, PROFILE_ID, has been introduced to specify the role of each configuration section.
PROFILE_ID has three possible values:
•
"local"—specifies the information for the local domain.
Service: NSS
PROFILE_ID="local"
LDAP_HOSTPORT="serverA.ca.com:389"
PROFILE_ENTRY_DN="cn=caprofile,cn=system,DC=ca,DC=com"
PROGRAM="/opt/ldapux/config/create_profile_cache"
•
"la.ca.com"—specifies the information for the remote domain.
PROFILE_ID="la.ca.com"
LDAP_HOSTPORT="serverB.la.ca.com:389"
PROFILE_ENTRY_DN="cn=ldapuxprofile,cn=system,dc=la,dc=ca,dc=com"
PROGRAM="/opt/ldapux/config/create_profile_cache -i
/etc/opt/ldapux/domain_profiles/ldapux_profile.ldif.la.ca.com -o
/etc/opt/ldapux/domain_profiles/ldapux_profile.bin.la.ca.com"
•
"gc"—specifies the information for GCS.
PROFILE_ID="gc"
LDAP_HOSTPORT="serverA.ca.com:389"
PROFILE_ENTRY_DN="cn=globalprofile,cn=system,DC=la,DC=ca, DC=com"
PROGRAM="/opt/ldapux/config/create_profile_cache -i
/etc/opt/ldapux/domain_profiles/ldapux_profile.ldif.gc -o
/etc/opt/ldapux/domain_profiles/ldapux_profile.bin.gc
The contents of this file are created as you run the setup tool. Therefore, the sequence in this file
represents the sequence in which you create remote domains while running setup, which is also
the sequence that LDAP-UX will connect to domain controllers to perform the search. The local
domain is created first, followed by remote domains, followed by the GCS, then lastly the domains
inside the forest which have not been configured during remote domain configuration.
If you configure remote domains without using the GCS, the file will only include information for
remote domains. If you skip remote domains and just configure GCS, the ldapux_client.conf
4.4 Understanding the ldapux_client.conf configuration file
161
file will have the “local” section immediately followed by the “gc” section. Any remote domain
sections in the file after the "gc" section are remote domains in the forest you configure. They are
only used by LDAP-UX to download profiles from the server, and will be ignored by LDAP-UX for
the multiple domain search scope.
4.5 Resolving duplicate entries
In the Windows 2003 R2 or 2008 environment, a user account can exist in multiple domains.
Each account has a user principal name (UPN) in the format <user>@<DNS-domain-name>.
Users can log on using UPN without choosing a domain. Due to the limitation of the HP-UX operating
system, LDAP-UX does not support UPN as in Windows 2003 R2 or 2008. It is recommended that
you configure a unique user name and uid number in the forest. When the same account exists in
multiple domains, LDAP-UX uses the following rules to return information:
4.5.1 When there are duplicate entries in the local domain
LDAP-UX returns the first entry found.
4.5.2 When there are duplicate entries in remote domains
•
If the remote domains are configured, LDAP-UX searches each domain in the configuration
sequence and returns data from the first entry found.
•
If only GCS is configured, LDAP-UX returns a NOT_FOUND message.
•
If both remote domains and GCS are configured, LDAP-UX searches remote domains first,
and returns the first entry found. If no entry is found in the remote domains, and duplicate
entries are in other domains in the forest, LDAP-UX returns a NOT_FOUND message.
4.5.3 When there are duplicate entries in both local and remote domains
LDAP-UX returns the first entry found in the local domain.
When LDAP-UX returns a NOT_FOUNDmessage, the user cannot log into HP-UX clients. Therefore,
if you want to allow a user in remote domains to log into HP-UX, it is better to have a unique user
name and uid number for each user in the entire forest. Otherwise, be sure that your multiple
domain configuration allows LDAP-UX to return data.
4.5.4 Example
The following example explains what to expect when your user accounts are not unique in the
forest.
Assume the user account jimmy resides in domainA, domainB, and domainC simultaneously:
•
If domain A is the local domain, jimmy in domainA will log into HP-UX client.
•
If all three domains are remote domains, and are configured in the sequence: domainB,
domainC, domainA, then jimmy in domainB, the first domain in the configuration, will log
into HP-UX client.
•
If all three domains are remote domains, and the GCS is selected, then jimmy cannot log
into HP-UX client at all since LDAP-UX cannot distinguish which jimmy is preferred (when
duplicate entries exist for GCS, none is valid).
•
If all three domains are remote domains, domainC is included in your remote domain
configuration, and GCS is selected, then jimmy in domainC logs into HP-UX client.
If the user name jimmy is unique in the forest, but the uid number is not unique, jimmy can log
into the HP-UX client, but depending on the uid number returned, he might have problems changing
his password using the passwd command.
162
Windows Active Directory multiple domains
4.6 Changing multiple domain configurations
The following sections explain how to modify your multiple domain configuration.
4.6.1 Removing a remote domain from the search scope
If you originally configure several remote domains without configuring the GCS, and you want to
exclude a domain from the search scope, perform one of the following options:
•
Run the setup tool, /opt/ldapux/config/setup, to reconfigure multiple domains and
exclude the one you want to remove.
•
Manually edit /etc/opt/ldapux/ldapux_client.conf to remove the configuration for
that specific domain and remove its corresponding profiles:
◦
/etc/opt/ldapux/domain_profiles/ldapux_profile.ldif.<domain>
◦
/etc/opt/ldapux/domain_profiles/ldapux_profile.bin.<domain>
NOTE: The second option is not recommended unless you are an expert administrator of
LDAP-UX in an ADS multiple domain environment.
Both options require you to restart the client daemon /opt/ldapux/bin/ldapclientd
for the changes to take effect.
4.6.2 Adding a remote domain to the search scope
If you originally configure several remote domains without configuring the GCS, and you want to
add a new remote domain into the search scope, run the setup tool to reconfigure the multiple
domains and include the new domain in your configuration. When setup is complete, restart the
client daemon, /opt/ldapux/bin/ldapclientd.
4.6.3 Reordering the remote domain search sequence
The search sequence is the sequence in which you configured the remote domains during setup.
This sequence is also shown in /etc/opt/ldapux/ldapux_client.conf. To reorder the
remote domain search sequence, either run setup to reconfigure the remote domains, or manually
edit the /etc/opt/ldapux/ldapux_client.conf file to rearrange the order. Restart the
client daemon for the change to take effect.
4.6.4 Adding the GCS into the search scope
The only way that you can add the GCS into the search scope is to run setup and add the GCS
as your multiple domain support. Restart the client daemon for the change to take effect.
4.6.5 Removing the GCS from the search scope
To remove the GCS from the search scope, either run setup to reconfigure, or manually edit
/etc/opt/ldapux/ldapux_client.conf to remove the gc section and its corresponding
profiles (/etc/opt/ldapux/domain_profiles/ldapux_profile.bin.gc and
ldapux_profile.ldif.gc). Restart the client daemon for the change to take effect.
4.6.6 Adding POSIX attributes to the global catalog
If you select GCS to support LDAP-UX integration with ADS multiple domains, you should add
POSIX attributes into the global catalog. The needed attributes are those used by getXbyY() APIs
to return data. Only passwd andgroup are supported in multiple domains. Therefore, the following
POSIX attributes must be added into the global catalog (for Windows Server 2003 R2 or 2008
RFC 2307):
uid
Used by getpwnam() and getgrnam()
4.6 Changing multiple domain configurations 163
uidNumber
Used by getpwuid()
gidNumber
Used by getgrgid()
To add these attributes to the global catalog:
1.
On your Windows 2003 R2 or 2008 GCS, click Start, then Run. In the open dialog box,
enter regsvr32 schmmgmt.dll. This makes the Active Directory Schema option available
in the snap-in dialog box; you will select this option in a subsequent step.
2. Click Start, then Run. In the open dialog box, enter mmc, then click OK. This enables access
to the Group Policy Microsoft Management Console.
3. Click the Microsoft Management Console menu, select Add/Remove Snap-in.
4. Click Add under the Standalone tab to get to the Add Standalone Snap-in dialog box.
5. In the Add Standalone Snap-In dialog box, select Active Directory Schema, then click Add and
then Close.
6. Active Directory Schema appears in the Add/Remove Snap-In dialog box. Click OK.
7. In the Microsoft Management Console, click Active Directory Schema and double-click Attribute,
under Name on the right-hand side of the box. All attributes will be shown.
8. Click the POSIX attribute to add into the global catalog, and then select Properties from the
Action menu.
9. In the Attribute Properties dialog box, select Replicate this attribute to the Global Catalog and
Index this attribute in the Active Directory, click Apply, and then OK.
10. Repeat steps 6 and 7 until all the required POSIX attributes are added into the global catalog.
4.7 Limitations of multiple domains in version B.03.00 or later
•
LDAP-UX Client Services only supports passwd and group in ADS multiple domains.
•
LDAP-UX Client Services using Windows 2003 R2 or 2008 Active Directory Server does not
support netgroup service data.
•
The following name service databases are supported in a single domain:
•
◦
hosts
◦
protocols
◦
networks
◦
rpc
◦
services
Data enumeration is not supported with ADS multiple domains. The getXXent() APIs only
enumerate data located in the local domain.
164 Windows Active Directory multiple domains
5 LDAP printer configurator support
This chapter contains information describing how LDAP-UX supports the printer configurator, how
to set up the printer schema, and how to configure the printer configurator to control its behaviors.
5.1 Overview
Management of network printing is complex, and printers themselves are more complicated. Instead
of having printer configuration and information scattered over client systems and printer servers,
they can be stored and managed from a single repository. LDAP is suited to build a backend printer
configuration database. LDAP-UX enables the centralized management of printers, and the printer
entries can easily be distributed to clients to reduce concerns about synchronization of configuration
information. LDAP-UX comes with a printer configurator to provide centralized printer management
by consolidating printer configuration and control of printer devices in the LDAP directory server.
5.1.1 Definitions
5.1.1.1 Printer services
HP-UX provides LP spooler system with the LP subsystem to manage printers and print services
requests. The LP subsystem is a collection of 18 programs that operate on the resources (files and
subdirectories) in LP spool directory to perform their functions, such as lpadmin, rlpdaemon
programs, and lp command.
5.1.1.2 Printing protocol
The LP spooler system has built-in support for sending jobs to other hosts that running rlpdaemon.
rlpdaemon is a LPD for handling remote spool requests. This feaure enables the user to install a
printer on one host and make it accessible from other hosts. It also works with printers/printservers
that have network interfaces that support the LDP protocol. The LPD network printing protocol is
the widely used network printing protocol in the UNIX world.
5.1.1.3 LP printer types
The LP spooler supports the following three types of printers:
•
A network printer which is a printer connected to a network interface or printserver.
•
A remote printer is a printer configured on a system other than the one you are logged into
when you submit a print request.
•
A local printer which is a printer that is directly connected to your system.
NOTE: The LDAP printer configurator only supports the HP LP spooler system, remote printers,
network printers and printerservers that support LPD protocol. It does not support local printers.
5.2 How the LDAP printer configurator works
The Printer Configurator is a service daemon that provides the following functions:
•
Periodically searches the existing printer entries stored in the LDAP directory server
•
Compares the search result with the master printer record file on each scheduled ldapsearch
•
Adds the print configuration to client system for each new printer
•
Deletes the printer from the client system for each removed printer
•
Updates master printer record file
5.1 Overview
165
When ldapclientd is initialized, it will enable the printer configurator services at the same time.
Once the printer configurator is up, it periodically searches for any existing printer entries in the
LDAP Direcotry Server based on predefined search filters. If there are any printer entries in the
LDAP directory server, the printer configurator will extract the LP printer configuration from each
printer entry.
Then, the printer configurator compares the printer configuration with the current LP printer
configuration in the client system. The result of comparison will generate a list of new or removed
printers. For a new printer, the printer configurator adds this printer to the LP printer spool of the
client which is running the printer configurator. For a removed printer, the printer configurator
deletes this printer from the LP printer spool of the client.
With the printer configurator, if a printer administrator attempts to remove or add a printer, all the
administrator has to do is to add or delete the printer entry in the LDAP directory server. The printer
configuration will be updated automatically without manually setting the printers on each client
system. Figure 12 (page 167) shows the basic printer configurator set up within an LDAP-UX client,
with an HP directory server that includes the printer entries for the various hosts shown. The printer
configurator architecture in a Windows ADS environment is identical to that shown in Figure 12
(page 167). However, a different schema is used in a Windows ADS environment. As a result, the
ADS (directory server) uses different attributes for printer entries, as shown in Figure 13 (page 167).
In this instance, it uses the alternate printer attributes, printerbyname and printer-resource.
The printerbyname attribute specifies the local printer name. The printer-resource attribute
provides the remote host name and remote printer name.
166 LDAP printer configurator support
NOTE: The system administrator manually adds or removes printers to the HP-UX system. The
LDAP Printer Configurator will only add or remove printers that it has discovered in the LDAP
directory according to the search filter defined for the printer.
Figure 12 Printer configurator architecture with an HP directory server
Directory Server
*New Printer Schema
*Printer Entries
dn: printer-name: laser2,ou=printers,dc=hp,dc=com
printer-name: laser2
printer-uri: lpd://hostA.corp.hp.com/lj2004
dn: printer-name: laser8,ou=printers,dc=hp,dc=com
printer-name: laser8
printer-uri: lpd://jetdirect.unit1.hp.com/lj8100
LDAP Printer Configurator
ldapclientd
LDAP-UX Client
“hostA.corp.hp.com”
“hostB.cup.hp.com”
Printer Server
“jetdirect.unit1.
hp.com”
(LPD) protocol
Create and remove remote LP printer
configurations automatically
lj2400
#lpstat-t
device for laser2:/dev/null
remote to lj2004 on hostA.corp.hp.com
device for laser8:/dev/null
remote to lj8100 on jetdirect.unit1.hp.com
lj8100
Figure 13 Windows ADS attributes for printer entries
Directory Server
*Defined Printer Attributes
*Printer Entries
dn: printerbyname: laser2,ou=printers,dc=hp,dc=com
printerbyname: laser2
printer resource: lpd://hostA.corp.hp.com/lj2004
dn: printerbyname: laser8,ou=printers,dc=hp,dc=com
printerbyname: laser8
printer-resource: lpd://jetdirect.unit1.hp.com/lj8100
5.2 How the LDAP printer configurator works
167
5.3 Printer configuration parameters
The LDAP-UX Client Services provides four printer configuration parameters, start,
search_interval , max_printers and lpadmin_option available for you to customize
and control the behaviors of the printer configurator. These parameters are defined in the
ldapclientd.conf file. For detailed information on these new parameters, see “Administering
LDAP-UX Client Services” (page 182).
5.4 Printer schema
The printer schema and attributes used in an HP directory server environment differ from those
used in a Windows ADS environment.
5.4.1 Printer schema in an HP directory server environment
In an HP directory server environment, the new printer schema RFC 3712 is used to create the
printer objects that are relevant to the printer configurator services. The draft printer schema can
be obtained from the IETF website at:
http://www.ietf.org
For the detailed structure information of the new printer schema, see “LDAP-UX Client Services
object classes” (page 406). You must import the new printer schema into the LDAP directory server
to create new printer objects.
NOTE: The LDAP printer configurator supports any LDAP-based directory servers that support the
LDAP printer schema based on RFC 3712.
5.4.1.1 Example of a printer object entry
The following shows a typical printer object entry:
dn: printer-name=printer1,ou=printers,dc=cup,dc=hp,dc=com
objectclass: top
objectclass: printerabstract
objectclass: printerservice
objectclass: printerlpd
printer-name: lj81003
printer-uri: lpd://hostA.hp.com/lj81003
printer-location: 47L
printer-make-model: hp laser jet 81003
printer-service-person: John Louie
With the new printer schema, you are able to create printer objects for the LP printer configuration.
The minimum information for a printer object entry is the local printer name, remote host name,
and the remote printer name. The remote host name is the system or device that the remote printer
is connected to. The remote host name must be the fully qualified name.
The printer-name attribute provides information of local printer name, the printer-uri
attribute identifies the remote host name and the remote printer name information. URI stands for
uniform resources identifier. The syntax of URI is based on RFC 2396. The following shows an
example of the printer-uri attribute:
printer-uri: lpd://hostA.hp.com/lj2004
5.4.2 Printer schema in a Windows ADS environment
The Windows 2003 R2 or 2008 Active Directory Server (ADS) contains the built-in printer schema.
The printer schema is used to create the printer objects that are relevant to the printer configurator
services. The attributes of this schema are not the same ones supported by the LDAP-UX printer
configurator and defined in RFC 3712 . This section describes how to use the Windows ADS
built-in schema to manage the networked printers.
168 LDAP printer configurator support
5.4.2.1 Printer attributes
With the printer schema in the Windows Active Directory Server, you are able to create printer
objects for the LP printer configuration. The minimum information for a printer object entry is the
local printer name, remote host name, and the remote printer name. The remote host name is the
system or device that the remote printer is connected to. The remote host name must be the fully
qualified name.
5.4.2.1.1 Default printer attributes
LDAP-UX supports the following two default printer attributes:
printer-name
Defines information of local printer name.
printer-uri
Defines the remote host name and the remote printer name information.
5.4.2.1.2 Printer attribute mappings
The printer-name and printer-uri attributes are not defined in the Windows Active Directory
Server schema. You must use one of the following two methods to define the alternate attributes
and map them to default printer attributes respectively.
Defining alternate printer attributes
You can define alternate printer attributes that can be remapped to printer-name and
printer-uri, and use the ldapentry or ldapmodify tool to add the alternate printer attributes
to your directory server. For example, you can define two alternate printer attributes,
printerbyname and printer-resource, and map these attributes to printer-name and
printer-uri respectively as shown in Table 15.
Table 15 Mappings between default printer and alternate printer attributes
Default Printer Attribute
Alternate Printer Attribute
printer-name
printerbyname
printer-uri
printer-resource
The printerbyname attribute provides local printer name information and the
printer-resource attribute specifies the remote host name and remote printer name. The
following shows examples of the printerbyname and printer-resource attribute values:
printerbyname: laser2
printer-resource: lpd://hostA.hp.com/lj2004
Using the existing printer attributes
You can use the existing printer attributes provided by Windows ADS schema to define alternate
printer attributes that can be remapped to printer-name and printer-uri respectively. For
example, the existing printer attributes, printerbinname and printer-color, are defined
and mapped to printer-name and printer-uri respectively as shown in Table 16.
Table 16 Mappings using existing printer attributes
Default Printer Attribute
Alternate Printer Attribute
printer-name
printerbinname
printer-uri
printer-color
The printerbinname attribute provides local printer name information and the printer-color
attribute specifies the remote host name and remote printer name. The following shows examples
of the printerbinname and printer-color attribute values:
printerbinname : laser5
5.4 Printer schema
169
printer-color: lpd://hostA.hp.com/lj2006
Printer attribute mappings
To enable the LDAP printer configurator support, you must run the setup program to perform the
attribute mappings and search filter changes. The tasks include the following:
•
Remap the default group attributes, printer-name and printer-uri to the alternate
printer attributes respectively. The attribute mappings are done in step 23 of Section 3.4.6.2
(page 139) in Section 3.4.6 (page 138).
•
Change the default search filter printerlpr for the printer services to the alternate search
filter. LDAP-UX Client Services uses the printerlpr object class for the printer service as a
default search filter. You must change default printerlpr object class to the alternate object
class. The search filter change can be done in step 24 of Section 3.4.6.2 (page 139) in
Section 3.4.6 (page 138).
5.5 Managing the LP printer configuration
The LDAP-UX Client Services provide the printer configurator integration; the product daemon
automatically updates the remote LP printer configuration of a client system based on the available
printer objects in the directory server. The printer configurator provides the printer configuration
management; it verifies if the printer configuration has any conflict with the LP printer configurations
in the client system before it actually adds or deletes a printer.
Following are five examples to show how the LDAP printer configurator provides central management
of printer services based on the printer objects stored in the directory server:
Example 1:
An administrator sets up a new printer located in the Engineering Lab and wants this printer to be
shared. This printer is physically connected to a system hostA and is set up as a local printer
lj2004. The administrator creates a new printer entry in the directory server as shown in the
examples to follow.
A new printer configuration for laser2 is created automatically in every client system if the LDAP
printer configurator is running. The print queue for laser2 is enabled and ready to accept print
jobs. Users can send their print jobs to laser2 by typing lp -dlaser2 filename.
HP directory server environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printer-name: laser2
printer-uri: lpd://hostA.hp.com/lj2004
Windows ADS environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printerbyname: laser2
printer-resource: lpd://hostA.hp.com/lj2004
Example 2:
IT department would like to store additional service information in the printer object. The
administrator modifies the printer object by adding more printer attributes. The modified content
of the printer object is shown in the examples that follow.
Since the local printer name, remote host name, remote printer name, and the printing protocol
information are still the same, the LDAP Printer Configurator will not change the current remote LP
printer configuration for laser2.
HP directory server environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printer-name: laser2
170
LDAP printer configurator support
printer-uri: lpd://hostA.cup.hp.com/lj2004
printer-location: Engineering Lab
printer-model: Hewlett Packard laserjet Model 2004N
printer-service-person: David Lott
Windows ADS environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printerbyname: laser2
printer-resource: lpd://hostA.hp.com/lj2004
printer-location: Engineering Lab
printer-model: Hewlett Packard laserjet Model 2004N
printer-service-person: David Lott
Example 3:
The system hostA.hp.com is retired. The Laserjet 2004 printer is now connected to system hostC
and set up as a local LP printer lj2004. The administrator should update the printer object by
changing the value in printer-uri attribute. The examples that follow show the updated
information of print objects.
The current remote LP laser2 printer configuration is removed from the client system, and the new
laser2 printer configuration with new remote host name information is added to the client system.
In fact, if either remote host name or remote printer name of printer-uri attribute is modified,
the printer configurator will remove the current remote LP printer configuration and create the new
printer configuration with the updated resource information.
HP directory server environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printer-name: laser2
printer-model: Hewlett Packard laserjet Model 2004N
printer-service-person: David Lott
Windows ADS environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printerbyname: laser2
printer-resource: lpd://hostC.hp.com/lj2004
printer-model: Hewlett Packard laserjet Model 2004N
printer-service-person: David Lott
Example 4:
The remote LP printer, laser2, no longer supports LPD printing protocol. IPP printing protocol is
implemented instead. The administrator updated the printer object by changing the printing protocol
to IPP. The following examples show the updated printer objects in the directory server.
IPP printing protocol is not supported by the LP spool printing system. The only action that the LDAP
printer configurator will take is to remove the current laser2 printer configuration on the client
system.
HP directory server environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printer-name: laser2
printer-uri: ipp://hostC.hp.com/lj2004
printer-location: Engineering Lab
printer-model: Hewlett Packard laserjet Model 2004N
printer-service-person: David Lott
Windows ADS environment example
dn: printer-name=laser2,ou=printers,dc=hp,dc=com
printerbyname: laser2
printer-resource: ipp://hostC.hp.com/lj2004
5.5 Managing the LP printer configuration
171
printer-location: Engineering Lab
printer-model: Hewlett Packard laserjet Model 2004N
printer-service-person: David Lott
Example 5:
The administrator created a new printer object in the directory server as shown in the examples
that follow. The printer configurator adds a new remote LP laser8 printer configuration to the
client system. However, if the user attempts to remove the laser8 printer configuration manually,
the printer configuration will no longer be managed by the printer configurator. The user has to
recreate the printer configuration manually in case the laser8 printer is needed. The printer
configurator does not try to create the printer configuration even though the printer object of laser8
still exists in the directory server.
If the user manually adds a remote LP printer configuration to the client system, the new printer
configuration is not managed by the printer configurator. The user has to remove the printer
configuration manually if the remote LP printer is no longer needed.
HP directory server environment example
dn: printer-name=laser8,ou=printers,dc=hp,dc=com
printer-name: laser8
printer-uri: lpd://hostD.hp.com/lj81003
Windows ADS environment example
dn: printer-name=laser8,ou=printers,dc=hp,dc=com
printerbyname: laser8
printer-resource: lpd://hostD.hp.com/lj81003
5.6 Limitations of the LDAP printer configurator
172
•
The new LDAP printer schema based on RFC 3712 is imported into the directory server to
create the printer objects.
•
LDAP-UX Client Services only supports the HP-UX LP spooler system, network printers, and
printerservers that support Line Printer Daemon (LPD) protocol. The printer configurator does
not support local printers.
•
In a global management environment, it is hard to determine a default printer for the individual
client system. The LDAP printer configurator treats every printer entry as the regular printer.
The administrator or user requires to manually select a printer as a default printer for the client
system.
LDAP printer configurator support
6 Dynamic group support
This chapter contains information about how LDAP-UX Client Services supports dynamic groups,
how to set up dynamic groups, and how to enable or disable dynamic group caches.
6.1 Overview
A system administrator can associate some users with a group, and apply security policies (such
as access control and password policies) to the group. As a result, all users belonging to the group
inherit the specific policies, such as being able to access a file. In LDAP directories, there are two
types of groups: static groups and dynamic groups. A static group defines all users statically. Each
user must be added to the group individually and explicitly. Dynamic groups associate users with
a group based on conditions. The condition may be specified by an LDAP web address (for an
HP directory server) or a search filter (for a Windows ADS). If a user’s data matches the specified
conditions, the user is a member of the dynamic group. Dynamic groups offer the advantage of
flexibility, and enable administrators to easily implement a role-based authorization policy based
upon a company's organizational structure. Users can be added to or removed from a group
dynamically based on the user's current status, such as the value of one or more attributes in the
user’s entry.
Since traditional POSIX-style groups are used largely to control file system access rights, dynamic
groups in LDAP-UX offers a new and flexible method for defining file system access policies. For
example, with file system ACLs, it is possible to add group access permission for users that are a
member of a particular group (say the "top secret" group). With dynamic groups, instead of
needing to insert each individual member in the group, LDAP-UX discovers all users in the directory
that have the "top secret" attribute associated with their entries. And when a user's attribute is no
longer defined as "top secret", the user's group membership in "top secret" is automatically revoked
(you do not have to make manual changes to the group).
LDAP-UX Client Services supports dynamic groups and allows you to configure dynamic groups
using the same syntaxes as the following directory servers and identity management:
•
HP-UX Directory Server or Red Hat Directory Server
•
Windows Server 2003 R2 or 2008 Active Directory Server
6.2 Creating an HP-UX dynamic group
LDAP-UX Client Services only supports HP-UX POSIX dynamic groups. To create an HP-UX POSIX
dynamic group in an HP directory server environment, follow the steps in Section 6.2.1 (page 173).
To create one in a Windows ADS environment, follow the steps in Section 6.2.2 (page 175).
6.2.1 Creating an HP-UX POSIX dynamic group in an HP directory server environment
HP-UX Directory Server and Red Hat Directory Server define the memberURL attribute and the
groupOfURLs object class to represent the dynamic group. All POSIX users who can be found
using the specified LDAP web address belong to the group.
To create an HP-UX POSIX dynamic group, follow these steps:
1.
2.
Use the Directory Server Console to create a dynamic group, as described in Section 6.2.1.1.
Add the posixgroup object class and gidNumber attribute information to the dynamic
group entry created in the preceding step, as described in Section 6.2.1.2 (page 174).
6.2.1.1 Step 1: Creating a dynamic group
Use the Directory Server Console to create a dynamic group. For detailed information about using
the Directory Server Console to create a dynamic group, see the HP-UX Directory Server
administrator guide available at:
6.1 Overview
173
http://www.hp.com/go/hpux-security-docs
Click HP-UX Directory Server.
The following shows an example of a dynamic group entry created using the Directory Server
Console. The definitions of the memberURL attribute and the groupOfURLs object class are shown
in bold type.
dn: cn=dyngroup,ou=groups,dc=example,dc=hp,dc=com
cn=dyngroup
objectClass: top
objectClass: groupofuniquenames
objectClass: groupofnames
objectClass: groupofurls
memberURL: ldap:///dc=example,dc=hp,dc=com??sub?(l=California)
The memberURL attribute in the example specifies a sub-tree search starting at any level under
dc=example, dc=hp, dc=com to find all entries matching (l=California). Any entries
which have object class account and an attribute l with the value of California will be
returned. With LDAP-UX, an additional criteria is added requiring that the user entry be a POSIX
account.
6.2.1.2 Step 2: Adding POSIX attributes to a dynamic group
To create an HP-UX POSIX dynamic group, you must use the Directory Server Console or the
ldapmodify tool to add the following object class and attribute information to the dynamic group
entry created in the preceding step:
•
posixgroup object class
•
gidNumber attribute
•
cn attribute if it does not exist in the group entry
For example, to create an HP-UX POSIX dynamic group, use the ldapmodify tool to add
posixgroup and gidNumber information to the dynamic group entry created from the Directory
Server Console as follows:
1.
Create an LDIF update file.
For example, the following LDIF update file, new.ldif, adds a posixgroup object class
and the gidNumber attribute to the “dn:
cn=dyngroup,ou=groups,dc=example,dc=hp,dc=com” entry:
dn: cn=dyngroup,ou=groups,dc=example,dc=hp,dc=com
changetype: modify
add: objectClass
objectClass: posixgroup
add: gidNumber
gidNumber: 500
2.
Use the ldapmodify tool to modify the existing entry with the LDIF file created in step 1.
For example, the following command modifies the dynamic group entry in the LDAP directory
server, ldaphost1, using the LDIF update file, new.ldif:
ldapmodify —D “cn=Directory Manager" —w <passwd> —h ldaphost1 —p
389 —f new.ldif
Example dynamic group entry
The following example is an HP-UX POSIX dynamic group entry with objectClass: posixgroup
and gidNumber: 500 information added (shown in bold type):
dn: cn=dyngourp,ou=groups,dc=example,dc=hp,dc=com
objectClass: groupofuniquenames
objectClass: groupofnames
174
Dynamic group support
objectClass: groupofurls
objectClass: posixgroup
objectClass: top
cn: dyngroup
memberURL: ldap:///dc=example,dc=hp,dc=com??sub?(l=California)
gidNumber: 500
6.2.2 Creating an HP-UX POSIX dynamic group in a Windows ADS environment
To create an HP-UX POSIX dynamic group in a Windows 2003 R2 or 2008 ADS environment,
use Authorization Manager. Authorization Manager creates an LDAP query group, which defines
group members by specifying a query (such as a search filter) using the attribute
msDS-AzLDAPQuery. LDAP query groups are dynamic groups in that group entries are retrieved
dynamically based on a search filter. LDAP-UX supports LDAP query groups only if they are POSIX
groups; that is, the groups must have PosixGroup object class and attributes.
To create an HP-UX POSIX dynamic group supported in Windows ADS, follow these steps:
1.
2.
3.
Use Authorization Manager to create dynamic groups, as described in Section 6.2.2.1
(page 175).
Use ADSI Edit to add the POSIX group ID to the dynamic group entry created in the preceding
step, as described in Section 6.2.2.2 (page 176).
Configure the proxy user to grant read permissions for searching dynamic groups in Windows
ADS, as described in Section 6.2.2.3 (page 176).
6.2.2.1 Step 1: Creating a dynamic group (an LDAP query group)
Use Authorization Manager to create dynamic groups (LDAP query groups) for your applications.
Membership in an LDAP query group is determined using an LDAP query on a given user object.
For detailed information about creating LDAP query groups using Authorization Manager, see
Dynamic Groups in Windows Server 2003 Authorization Manager, available at the following
web site:
http://msdn2.microsoft.com/en-us/library/ms952382.aspx
Example of a dynamic group entry
The following shows an example of a dynamic group entry (LDAP query group) created using
Authorization Manager:
dn: CN=group1,CN=AzGroupObjectContainer-dyngroup,CN=dyngroup,
DC=hp,DC=com
objectClass: top
objectClass: group
cn: group1
description: my dynamic group
distinguishedName: CN=group1,CN=AzGroupObjectContainer-dyngroup,
CN=dyngroup,DC=hp,DC=com
instanceType: 4
whenCreated: 20060313181428.0Z
whenChanged: 20060313182629.0Z
uSNCreated: 16588
uSNChanged: 16597
name: group1
objectGUID:: 2qO9YxkqAUuwCmkMJ371DA==
objectSid:: AQUAAAAAAAUVAAAAuEKpalCWUfgTN3lpVwQAAA==
sAMAccountName: $N21000-OA67EGECFDSP
sAMAccountType: 1073741825
groupType: 32
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hp,DC=com
msDS-AzLDAPQuery: (cn=p*)
6.2 Creating an HP-UX dynamic group
175
6.2.2.2 Step 2: Adding POSIX attributes to a dynamic group
Use ADSI Edit to add the following attribute (including POSIX group ID information) to the dynamic
group entry created in the preceding step.
•
GidNumber attribute for Windows 2003 R2 or 2008 ADS
Example dynamic group entry
The following shows an example that includes the last three lines of the HP-UX POSIX dynamic
group entry for a Windows 2003 R2 or 2008 ADS. The GidNumber information added to the
dynamic group entry is shown in bold type.
.
.
.
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hp,DC=com
msDS-AzLDAPQuery: (cn=p*)
GidNumber: 10005
6.2.2.3 Step 3: Setting read permissions for the proxy user
The LDAP query groups (dynamic groups) created by Authorization Manager are not placed under
the CN=Users container. Authorization Manager creates its own authorization store objects (for
example, CN=dyngroup). By default, a regular user is not allowed to read LDAP entries under
those authorization store objects.
To support the dynamic group feature with LDAP-UX, you must configure the proxy user to grant
the read permissions for those authorization store objects. To grant the proxy user read permissions
for a sample authorization store object CN=dyngroup containing dynamic groups, perform the
following steps:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Bring up the console by starting mmc from run.
Add snap-in ADSI Edit.
Connect to the domain from Action.
Select the authorization store object CN=dyngroup and right-click on the Properties tab.
Select the Security tab on the Properties window.
Select Add on the Security window.
Add the proxy user and select OK.
In the Permissions dialog box, select the Allow box for the read permission.
Select Advanced on the Security window.
Select proxy user and then select Edit.
Select This object and all child objects from the Apply onto drop-down list in the dialog box.
On the permissions dialog box, verify that the List Contents, Read All Properties and Read
Permissions selections are selected.
To support dynamic groups with LDAP-UX, you must configure the proxy user to grant the read
permissions for each authorization store object in Windows ADS. If you configure dynamic groups
for more than one domain, repeat the steps outlined in this section for every domain that you want
to support with LDAP-UX.
6.2.3 Changing an HP-UX POSIX static group to a dynamic group
For an HP directory server environment, to change an HP-UX POSIX static group to an HP-UX POSIX
dynamic group, use the Directory Server Console to add the following object class and attribute
information to the HP-UX POSIX static group:
176
•
groupofurls object class
•
memberURL attribute
Dynamic group support
For detailed information on how to use the Directory Server Console to modify a group, see the
HP-UX Directory Server administrator guide available at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX Directory Server.
The following shows an example of an HP-UX POSIX static group entry:
dn: cn=all,ou=groups,dc=example,dc=hp,dc=com
objectClass: groupofuniquenames
objectClass: groupofnames
objectClass: posixgroup
objectClass: top
cn: all
gidNumber: 1000
memberuid: user1
After you add information for groupofurls and memberURL to the preceding HP-UX POSIX
static group entry, the HP-UX POSIX dynamic group entry is as follows:
dn: cn=all,ou=groups,dc=example,dc=hp,dc=com
objectClass: groupofuniquenames
objectClass: groupofnames
objectClass: groupofurls
objectClass: posixgroup
objectClass: top
cn: all
memberURL: ldap:///dc=example,dc=hp,dc=com??sub?(l=California)
gidNumber: 1000
memberuid: user1
Now, the group “all” contains both static group member (user1) and dynamic members (all user
entries that can be retrieved from the tree of dc=example,dc=hp,dc=com and have an attribute
with l=California).
6.2.4 Enabling dynamic group support
To enable dynamic group support, you must run the setup program to remap the default group
attribute memberuid to the dynamic group attribute memberURL (in an HP directory server
environment) or msDS-AzLDAPQuery (in a Windows ADS environment). If the dynamic group
attribute is not mapped to memberUid, LDAP-UX will not process dynamic groups.
When running setup for an HP directory server environment, attribute mappings are done in step
10 of the Custom Configuration. For detailed information on how to remap the group attributes,
see Section 2.4.5.2 (page 72). When running setup for a Windows ADS environment, attribute
mappings are done in step 23 of Section 3.4.6.2 (page 139) in Section 3.4.6 (page 138).
Table 17 shows attribute mappings between the default group attribute and alternate group
attributes:
Table 17 Mappings between default and alternate group attributes
Default Group Attribute
Dynamic Group Attribute
Static X.500 Group Attribute
memberuid
memberURL (HP directory server
environment)
member
msDS-AzLDAPQuery (Windows ADS
environment)
If you want to perform group attribute mappings by using the Custom Configuration, ensure that
you do not accept the remaining default configuration parameters (running setup for an HP
directory server environment, this is in step 4 of the Custom Configuration, Section 2.4.5.2
(page 72); for a Windows ADS environment, this is step 15 in Section 3.4.6.2 (page 139)).
6.2 Creating an HP-UX dynamic group 177
6.3 Multiple group attribute mappings
By default, LDAP-UX uses the memberUid attribute to retrieve group members. With the support
of X.500 group member syntax, you can map the default group attribute memberUid to member
or uniquemember (or to both), specifying group members using user DNs. With dynamic group
support in an HP directory server environment, LDAP-UX enables you to map memberUid to
memberURL (if you use HP-UX Directory Server or Red Hat Directory Server to create dynamic
groups) or nxSearchFilter (if you use HP OpenView Select Access or HP-UX Select Access for
IdMI to create dynamic groups). In a Windows ADS environment, if you use Authorization Manager
to create dynamic groups, LDAP-UX enables you to map memberUid to msDS-AzLDAPQuery.
You can run the setup program and map memberUid to multiple attributes as needed. The
following output of /opt/ldapux/config/display_profile_cache in an HP directory
server environment shows that memberUid is mapped to static group attributes memberUid,
member, and uniquemember, and to dynamic group attribute memberURL:
Group Service Configuration:
Attribute:
----------name:
gid:
members:
is mapped to:
------------cn
gidnumber
memberuid memberURL
member uniquemember
The following output of /opt/ldapux/config/display_profile_cache in a Windows
ADS environment shows that memberUid is mapped to static group attributes memberUid and
member, and to the dynamic group attribute msDS-AzLDAPQuery (this example assumes that
the directory server is Windows 2003 R2 ADS):
Group Service Configuration:
Attribute:
----------name:
gid:
members:
is mapped to:
------------cn
gidnumber
memberuid msDS-AzLDAPQuery
member
LDAP-UX retrieves group members and processes groups that a specific user belongs to by looking
into all configured attributes. If needed, for a nonWindows environment, you can create a group
that includes both static and dynamic members. When returning group members, LDAP-UX will
return both static and dynamic members that belong to a specific group.
When processing dynamic group attributes in an HP directory server environment, to retrieve group
members, LDAP-UX combines the search filter of the passwd service from the profile with the search
filter specified in memberURL (for example, the last component in memberURL) or
nxSearchFilter. This ensures that group members returned are POSIX accounts and conform
to the configuration set for LDAP-UX.
In a Windows ADS environment, an LDAP query group specifies dynamic members using a search
filter. You retrieve group members, LDAP-UX uses the search base and search scope of the passwd
service from the profile, and combines the search filter of the passwd service from the profile with
the search filter specified by msDS-AzLDAPQuery. This ensures that group members returned are
POSIX accounts and conform to the configuration set for LDAP-UX.
6.3.1 Multiple group attribute mapping examples
The following output example of /opt/ldapux/config/display_profile_cache shows a
passwd service configuration established for a Windows ADS environment. This configuration is
the basis for the sample group entries that follow (it is applicable to both HP directory server and
Windows ADS environments).
178
Dynamic group support
PASSWD Service Configuration
Attribute:
---------name:
uid number:
.....
Search Descriptor
search[0]:
is mapped to:
-------------uid
uidnumber
dc=example,dc=hp,dc=com?sub?
(objectclass=posixaccount)
Sample group entry in HP directory server environment
In an HP directory server environment, the following is a sample group entry associated with the
passwd service configuration shown in the preceding example of
/opt/ldapux/config/display_profile_cache output.
dn: cn=mygroup,ou=Groups,dc=example,dc=hp,dc=com
objectClass: groupofnames
objectClass: groupofuniquenames
objectClass: posixgroup
objectClass: groupofurls
objectClass: top
cn: mygroup
gidNumber: 100
memberUid: user1
member: uid=user2,ou=people,dc=example,dc=hp,dc=com
uniqueMember: uid=user3,ou=people,dc=example,dc=hp,dc=com
memberURL: ldap:///dc=example,dc=hp,dc=com??sub?(uid=p*)
When processing memberURL to retrieve dynamic members, LDAP-UX combines
(objectclass=posixaccount) from passwd configuration with (uid=p*) as the search
filter to search the tree of "dc=example,dc=hp,dc=com".
With these attribute mappings, LDAP-UX will return user1, user2, user3 and all users starting
with "p" as group members.
Sample group entry in a Windows ADS environment
In a Windows ADS environment, the following is a sample group entry associated with the passwd
service configuration shown in the preceding example of
/opt/ldapux/config/display_profile_cache output.
dn: CN=group1,CN=AzGroupObjectContainer-dyngroup,CN=dyngroup,
DC=hp,DC=com
objectClass: top
objectClass: group
cn: group1
description: my dynamic group
gidNumber: 1000
distinguishedName: CN=group1,CN=AzGroupObjectContainer-dyngroup,
CN=dyngroup,DC=hp,DC=com
instanceType: 4
whenCreated: 20060313181428.0Z
whenChanged: 20060313182629.0Z
uSNCreated: 16588
uSNChanged: 16597
name: group1
objectGUID:: 2qO9YxkqAUuwCmkMJ371DA==
objectSid:: AQUAAAAAAAUVAAAAuEKpalCWUfgTN3lpVwQAAA==
sAMAccountName: $N21000-OA67EGECFDSP
sAMAccountType: 1073741825
groupType: 32
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hp,
6.3 Multiple group attribute mappings
179
DC=com
msDS-AzLDAPQuery: (cn=p*)
To return dynamic members, LDAP-UX searches the tree dc=hp,dc=com, and finds the POSIX
entries whose cn starts with p* (that is, using the search filter
"(&(objectclass=user)(uidNumber=*)(cn=p*))" ).
6.4 Number of group members returned
With dynamic membership support, as with regular (static) group membership support, the number
of group members for a specific group returned by getgrnam()/getgrgid()/getgrent()
on an HP-UX system is limited by internal buffer sizes. On HP-UX 11i systems, the buffer size is
7296 bytes for 32-bit applications and 10496 bytes for 64-bit applications. This limitation is mainly
impacted by the size of each member name. For a detailed description, see the "Account and
Group Management" section in the Preparing your Directory for LDAP-UX Integration white paper
available at:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
During the login process, information for getting group members is not requested. The login time
is not affected by processing group members.
6.5 Number of groups returned for a specific user
When “ldap” is configured in the /etc/nsswitch.conf file as a data repository for the group
service (see nsswitch.conf(4)), if an LDAP user logs into an HP-UX system, LDAP-UX is involved to
return all groups that the user belongs to. The login application (such as login) initializes the
user's group access based on the group information returned by LDAP-UX.
Information for getting groups that a specific user belongs to is requested by LDAP-UX during login
via initgroups(). LDAP-UX returns at most 20 groups for a system limit on HP-UX 11i v2 systems.
On HP-UX 11i v3 systems, you can increase the number of groups a user may be a member of
(known as NGROUPS). For more information, see the Group membership expansion: guidelines
for deployment white paper at:
http://www.hp.com/go/hpux-core-docs (click HP-UX 11i v3)
If the user belongs to more than 20 groups, only the first 20 groups are returned. The support of
dynamic groups does not change the system limitation.
Depending on how you configure groups, if those 20 groups happens to be the last entries of
thousands of dynamic groups, the login time could be long and performance could be impacted.
Based on the configuration of memberUid attribute mappings, LDAP-UX might return static or
dynamic groups. The first memberUid mapped attribute determines if LDAP-UX returns static or
dynamic groups first. If the first memberUid mapped attribute is a static group attribute (such as
memberUid, member, or uniquemember), LDAP-UX returns static groups first. If there are less
than 20 static groups, LDAP-UX then returns dynamic groups for the rest groups. However, if the
first memberUid mapped attribute is a dynamic group attribute (such as memberURL,
nxSearchFilter, or msDS-AzLDAPQuery), LDAP-UX returns dynamic groups first. If there are
less than 20 dynamic groups, LDAP-UX then returns static groups for the rest groups.
With this design, a group containing both static and dynamic group attributes will always be
processed, but will be limited to the first 20 groups.
For example, if a user belongs to 8 static groups and 20 dynamic groups, and you map memberUid
to memberUid memberURL ( or to memberUid msDS-AzLDAPQuery ), LDAP-UX will return 8
static groups and 12 dynamic groups. If you map memberUid to memberURL memberUid,
LDAP-UX will return 20 dynamic groups without any static groups.
180 Dynamic group support
6.6 Performance impact for dynamic groups
The dynamic group is specified by either an LDAP web address or a search filter. Depending on
how you configure dynamic groups, there could be a lot of LDAP searches involved. In that case,
the performance of those applications calling getgrnam(), getgrgid(), or getgrent() (for
example, the commands id, groups, and so forth) will be affected. For more information about
these commands, see their manpages (getgrname(3), getgrgid(3), getgrent(3)).
To reduce the performance impact, the LDAP-UX client daemon (ldapclientd) caches dynamic
group information, including dynamic members that belong to a specific group and dynamic
groups that a specific user belongs to. The caching reduces the response time for ldapclientd
information return. However, before the cache is established (that is, at the very first request) or
when the cache expires, you might experience longer response times. For more information about
dynamic group caching, see Section 6.7 (page 181).
6.6.1 Enabling and disabling enable_dynamic_getgroupsbymember
Processing dynamic groups that a specific user belongs to might potentially impact the user login
time. To control the operation for processing dynamic groups a specific user belongs to, LDAP-UX
Client Services supports the enable_dynamic_getgroupsbymember configuration parameter
in the /etc/opt/ldapux/ldapux_client.conf file.
This integer variable controls whether to enable or disable processing dynamic groups that a
specific user belongs to. The valid values of this option are 1 and 0.
By default, LDAP-UX returns the dynamic groups to which a user belongs if the group attribute,
memberUid, is mapped to memberURL or nxSearchFilter (in an HP directory server
environment) or msDS-AzLDAPQuery (in a Windows ADS environment). A user that belongs to
many dynamic groups might experience an unexpected delay when logging into an HP-UX client
system. You can reduce the delay by disabling LDAP-UX from returning dynamic groups that a
specific user belongs to unless the user specifically uses the newgrp command. As a result, the
user will not have access granted to those dynamic groups, and the id command will not show
those groups. To disable LDAP-UX from returning dynamic groups for all users, set
enable_dynamic_getgroupsbymember to 0. The default value is 1, which enables returning
dynamic groups.
NOTE: When the enable_dynamic_getgroupsbymember variable is set to 0, LDAP-UX still
returns dynamic members for a specific group. If you do not want any dynamic members returned,
you must not include the memberURL and nxSearchFilter attributes or the msDS-AzLDAPQuery
attribute in the memberUid group attribute mapping. This completely disables the LDAP-UX dynamic
group functionality.
6.7 Configuring dynamic group caches
To improve performance of dynamic groups, the LDAP client daemon ldapclientd caches
dynamic group members to reduce the LDAP-UX client response time while retrieving dynamic
group information. This cache is maintained in an independent memory space not shared with the
cache for other service data.
To configure dynamic group caches, set the parameters defined in the [dynamic_group] section
of the /etc/opt/ldapux/ldapclientd.conf file. For more information, see Section 7.1.3
(page 184).
6.6 Performance impact for dynamic groups
181
7 Administering LDAP-UX Client Services
This chapter describes how to keep your clients running smoothly and how to expand your computing
environment.
7.1 Managing the LDAP-UX client daemon
This section describes the following:
•
Overview of ldapclientd daemon operation
•
Configurable parameters and syntax in the ldapclientd configuration file,
ldapclientd.conf
•
Command line syntax and options for the ldapclientd command
7.1.1 Overview
The LDAP-UX client daemon enables LDAP-UX clients to work with LDAP directory servers. To perform
this role, the daemon executes the following tasks:
•
Receives requests from properly configured applications and services
•
Generates connections and requests to the configured directory server
•
Returns appropriate reply to requesting applications or services
In addition to the basic tasks of enabling authentication for applications and services, the client
supports the following features:
•
Multiple Windows domains: The client daemon enables LDAP-UX to use multiple domains for
Active Directory Server (ADS). The daemon also enables PAM Kerberos to authenticate POSIX
users stored in multiple domains; it supports multiple domains in the Windows 2003 R2 or
2008 Active Directory Server (ADS).
•
X.500 group membership.
•
Automatic Profile Downloading: This feature updates the LDAP client configuration profile by
downloading a newer copy from the directory server when the profile TTL (Time To Live)
configuration value expires.
•
Managing the remote LP printer configuration: The client daemon automatically searches for
certain printer objects configured in the LDAP server and executes lpshut, lpadmin, and
lpsched commands to add, modify, and remove printers accordingly for the local system.
By default, the LDAP printer configurator is enabled.
By default, ldapclientd starts at system boot time. The ldapclientd command can also be
used to launch the client daemon manually, or to control it when the daemon is already running.
For information about the ldapclientd command and its parameters, see Section 7.1.2 (page 182)
and the ldapclientd manpage.
IMPORTANT: For LDAP-UX functionality, the client daemon /opt/ldapux/bin/ldapclientd
must be running.
7.1.2 Using the ldapclientd administration tool
7.1.2.1 Starting the client
Use the following syntax to start the client daemon.
/opt/ldapux/bin/ldapclientd <[-d <level>] [-o<stdout|syslog|file[=size]>]
[-z]
182
Administering LDAP-UX Client Services
7.1.2.2 Controlling the client
Use the following syntax to control the client daemon:
/opt/ldapux/bin/ldapclientd <[-d <level>]
[-o<stdout|syslog|file[=size]>]>
/opt/ldapux/bin/ldapclientd <[-D <cache>]|-E <cache>|-S [cache]>
/opt/ldapux/bin/ldapclientd <-f| -k| -L| -h| -r>
7.1.2.3 Improving client daemon performance
Performance (client response time) is improved by the use of two techniques:
•
Reuse of connections to the directory server — This feature improves performance by reducing
the overhead associated with opening and closing bindings to the directory server and
significantly reduces network traffic and server load.
•
Enabling the client cache — Enabling the cache allows the client to cache the reply information
retrieved for the following maps:
passwd
group
dynamic group
netgroup
X.500 group membership
automount
Except for the dynamic group map, these maps share a common memory space. The dynamic
group map cache is created as an independent memory space. The length of time the reply data
is held in the cache is determined by a Time To Live timer. This timer can be set for all maps or
can be set independently for each of the maps listed. The cache can also be flushed by specifying
an option with the ldapclientd command. The cache space becomes available for new
information after the Time to Live expires or the cache is flushed.
Two categories of information are held in the cache: the reply data for those requests that were
successful, and replies when the information was not found. For example, when a specific user is
trying to log on, the userID might not exist in the directory.
The Time to Live timer for replies that were found in the directory is set by the poscache_ttl
parameter in the ldapclient.conf file; the Time to Live timer for replies where the information
was not found is set by the negcache_ttl parameter.
For more information about client daemon performance, see Section 7.12.2 (page 248).
7.1.2.4 Command options
For option information, see the ldapclientd manpage.
7.1.2.5 Diagnostics
By default, errors are logged into syslog if the system log is enabled in the LDAP-UX client startup
configuration file /etc/opt/ldapux/ldapux_client.conf. When errors occur before
ldapclientd forks into a daemon process, error messages display directly on the screen.
The following diagnostic messages may be issued:
Message: Already running
Meaning: An attempt was made to start an LDAP client
daemon when one was already running.
Message: Cache daemon is not
running (or running but not ready).
Meaning: This message can mean several things:
•
An attempt was made to use the control option features
of ldapclientd when no ldapclientd daemon
process was running to perform those features.
7.1 Managing the LDAP-UX client daemon 183
Message: Problem reading
configuration file.
•
An attempt was made to start or control ldapclientd
without superuser's privileges.
•
The ldapclientd daemon process is too busy with
other requests to respond at this time. Try again later.
Meaning: The /etc/opt/ldapux/ldapclientd.conf
file is missing or has a syntax error. If syntax is the problem,
the error message will be accompanied by a line showing
exactly where it could not recognize the syntax or where it
found a setting that is out of range.
7.1.2.6 Warnings
Whenever the system is rebooted, ldapclientd launches if [StartOnBoot] has the parameter
enabled=yes in the file /etc/opt/ldapux/ldapclientd.conf (the ldapclientd
configuation file). Downloading profiles takes time, depending on the server's response time and
the number of profiles listed in the LDAP-UX startup file /etc/opt/ldapux/
ldapux_client.conf.
7.1.3 ldapclientd.conf configuration file
The ldapclientd.conf file is the configuration file for /opt/ldapux/bin/ldapclientd,
the LDAP client daemon. For more information about the client daemon, see Section 7.1 (page 182).
7.1.3.1 Configuration file syntax
# comment
[section]
setting=value
setting=value
.
.
.
[section]
setting=value
setting=value
.
.
.
Where:
comment
ldapclientd ignores any line beginning with a # delimiter.
section
Each section is configured by setting=value information underneath. The section name
must be enclosed by brackets ("[ ]") as delimiters. Valid section names are:
•
StartOnBoot
•
general
•
passwd
•
group
•
dynamic_group
•
longterm_cache
•
netgroup2
•
uiddn
•
domain_pwd
•
domain_grp
2. LDAP-UX using Windows 2003 R2 or 2008 Active Directory Server does not support netgroup.
184 Administering LDAP-UX Client Services
•
automount
•
automountMap
•
printers2
setting
This will be different for each section.
value
Depending on the setting, this can be <yes|no|number>.
NOTE: ldapclientd uses the default values for any settings that are not specified in the
configuration file.
7.1.3.1.1 Section details
Within a section, the following syntax applies:
[StartOnBoot]
Determines if ldapclientd starts automatically when the system boots.
enable=<yes|no>
By default, this is enabled after LDAP-UX has been configured by the
LDAP-UX setup program /opt/ldapux/config/setup.
[general]
Any cache setting defined here will be used as the default setting for all
caches (passwd, group, netgroup, uiddn, domain_pwd,
domain_grp, automount, automountMap and
dynamic_group). The cache_size setting defined here will be used
for all caches except dynamic_group
max_conn=<2-500>
The maximum number of connections ldapclientd can establish to
the directory server (or multiple servers when in a multi-domain Windows
environment).
The default value is 100.
connection_ttl=<0-2147483647>
The number of seconds before an inactive connection to the directory
server is brought down and cleaned up.
The default value is 300.
num_threads=<1-100>
The number of client request handling threads in ldapclientd.
The default value is 10.
socket_cleanup_time=<0-2147483647>
The interval, in seconds, before the next attempt to clean up the socket
files created by any LDAP-UX client applications that were terminated
abnormally.
The default value is 300.
cache_cleanup_time=<1-300>
The interval, in seconds, between the times when ldapclientd
identifies and cleans up stale cache entries.
The default value is 10.
update_ldapux_conf_time=<0-2147483647>
This determines how often, in seconds, ldapclientd rereads the
/etc/opt/ldapux/ldapux_client.conf client configuration file
to download new domain profiles.
7.1 Managing the LDAP-UX client daemon 185
The default value is 600 (10 minutes).
cache_size=<102400-1073741823>
The maximum number of bytes that should be cached by ldapclientd
for all services except dynamic_group. This value is the maximum, upper
limit, of memory that can be used by ldapclientd for all services
except dynamic_group. If this limit is reached, new entries are not cached
until enough expired entries are freed to allow it.
The default value is 10000000.
state_dump_time=<0-2147483647>
As state, functions like a virtual between the client and LDAP server, is
created for setXXent() request, and stays for the subsequent
getXXent() requests. If no get requests are received in the specified
time interval (in seconds), the state will be removed. The default value
is 300 (in seconds).
max_enumeration_states=<0-95>[%]
The maximum number of states that ldapclientd allows. It means the
number of enumeration ldapclientd will handle simultaneously. This
number must be less than max_conn and it is configured as a
percentage of max_conn. The minimum value is 0% and maximum
value is 95%. The default value is 80%. A value of 0% disables
enumeration.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. There is no [general] default value for this setting. Each cache
section has its own default values. Specifying a value under [general]
will override poscache_ttl defaults in other sections (where no specific
poscache_ttl definitions are specified).
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache. There is no [general] default value for this setting. Each cache
section has its own default value.
proxy_is_restricted=yes|no
If the proxy user is configured in the LDAP-UX profile and defined in
/etc/opt/ldapux/pcred, this flag attests that the proxy user does
not hold privileged LDAP credentials, meaning the proxy user is restricted
in its rights to access "private" information in the directory server. As of
release B.05.00, ldapclientd provides a local interface to allow
specialized directory-enabled applications to access arbitrary attributes
in HP-UX related directory entries. By default, and if set to no,
ldapclientd will not allow access to attributes beyond that of the
RFC2307 schema and any attribute defined using the
allowed_attribute token. If proxy_is_restricted is set to
yes, then you are attesting that the directory server is restricting access
to private or other confidential information from access by the proxy
user. This allows specialized applications to access any attribute visible
to the proxy user. The default value for this setting is no, meaning
ldapclientd assumes the proxy user has rights beyond that of a
nonprivileged user.
allowed_attribute=service:attribute
186 Administering LDAP-UX Client Services
Some applications, like /opt/ssh/bin/ssh, use ldapclientd to
access information in the directory server, such as the sshPublicKey
for users and hosts. By setting this parameter, applications can access
any defined attribute even if the proxy_is_restricted value is set
to no (the default). There is no internal default set for this parameter. If
allowed_attribute is not specified, no attributes beyond that defined
in RFC2307 (and as mapped in the configuration profile) will be
accessible through the ldapclientd API. However, the default
delivered ldapclientd.conf file will set this parameter to allow
access to the sshPublicKey attribute for the passwd and hosts service.
This parameter may be specified more than once.
allowed_attribute example:
allowed_attribute=hosts:sshPublicKey
[passwd]
Cache settings for the passwd cache (which caches name, UID, and
shadow information).
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
If the cache is not enabled, ldapclientd will query the directory server
for any entry request from this section. Since this impacts LDAP-UX client
performance and response time, by default, caching is enabled.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. Since personal data can change frequently, this value is typically
smaller than some others.
The default value is 120 (2 minutes)
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache.
The default value is 240 (4 minutes).
[group]
Cache settings for the group cache (which caches name, gid and
membership information).
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
By default, caching is enabled.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. Since people are added and removed from groups occasionally,
this value is not typically large. If dynamic_group caching is enabled,
this value must be less than poscache_ttl of [dynamic_group].
The default value is 240 (4 minutes)
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache. If dynamic_group caching is enabled, this value must be less
than negcache_ttl of [dynamic_group]
The default value is 240 (4 minutes).
[dynamic_group]
This section describes the settings for the Dynamic Group cache. This
cache manages dynamic group information including name, group ID
7.1 Managing the LDAP-UX client daemon
187
and membership information. This cache is maintained in a independent
memory space not shared with the cache for other maps.
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
Since this impacts LDAP-UX client performance and response time,
caching is enabled by default.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. If group caching is enabled, this value must be greater than
poscache_ttl of [group].
The default value is 43200 (12 hours).
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache. If group caching is enabled, this value must be greater than
negcache_ttl of [group]
The default value is 43200 (12 hours).
cache_size=<102400–1073741823>
This integer variable specifies the maximum number of bytes that should
be cached by ldapclientd. This value is the maximum, upper limit,
of memory that can be used by ldapclientd. If this limit is reached,
new entries are not cached until enough expired entries are freed to
allow it. The default value is 100000000 (10M).
NOTE: The cache_size option defined in the [general] section
is used to configure all other caches (passwdm netgroup, group,
automount, domain_pwd, domain_grp, uiddn).
[longterm_cache]
Cache settings for the long-term (offline) cache.
enable=<yes|no>
ldapclientd only caches entries for this section when it is enabled.
By default, caching is disabled.
longterm_expired_interval=<0-2147483647>
The time, in seconds, before data is considered stale and not usable,
and therefore is removed.
The default value is 1209600 seconds (2 weeks).
longterm_cache_backup_interval=<0-2147483647>
The time interval, in seconds, after which long-term data is saved to
permanent storage.
The default value is 900 seconds (15 minutes).
longterm_cache_size=<102400–1073741823>
The maximum amount of memory (in bytes) to allocate for the long-term
cache for storing user and group information. This cache is used by the
working set of users and groups, which are any users and groups being
used or displayed on the system. If you have numerous large groups
containing a large number of members, set this value to at least twice
the combined size of all groups.
The default value is 50000000 (5M).
longterm_enum_enable=<yes|no>
188 Administering LDAP-UX Client Services
Determines whether the long-term cache should support enumeration.
The default value is no.
longterm_enum_search_interval=<0-2147483647>
The time interval, in seconds, after which the HP-UX client has the
directory server refresh the enumeration cache.
The default value is 86400 seconds (1 day).
[netgroup]
Cache settings for the netgroup cache.
enable=<yes|no>
ldapclientd only caches entries for this section when it is enabled.
By default, caching is enabled. Windows ADS implementations ignore
this setting.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. Since people are added and removed from groups occasionally,
this value is not typically large.
The default value is 240 (4 minutes)
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache.
The default value is 240 (4 minutes).
LDAP-UX using Windows 2003 R2 or 2008 Active Directory Server
does not support netgroup service data.
[uiddn]
This cache maps a user's UID to their DN from the directory.
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
By default, caching is enabled.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. Typically, once added into a directory, the user's DN rarely
changes.
The default value is 86400 (24 hours).
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache.
The default value is 86400 (24 hours).
[domain_pwd]
This cache maps user names and UIDs to the domain holding its entry.
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
By default, caching is enabled.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. Since new domains are rarely added to or removed from the
forest, the cache is typically valid for a long time.
The default value is 86400 (24 hours)
negcache_ttl=<0-2147483647>
7.1 Managing the LDAP-UX client daemon 189
The time, in seconds, before a cache entry expires from the negative
cache.
The default value is 86400 (24 hours).
[domain_grp]
This cache maps group names and GUIDs to the domain holding its
entry.
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
By default, caching is enabled.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. Since new domains are rarely added to or removed from the
forest, the cache is typically valid for a long time.
The default value is 86400 (24 hours).
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache.
The default value is 86400 (24 hours).
[automount]
Cache settings for the automount entry cache (which caches automount
entries in automount maps).
A positive cache means that the automount entry data has been recently
retrieved from the LDAP directory server and is stored in the positive
cache locally.
A negative cache is used to store the automount entry data about
nonexistent information. For example, if a user requests information
about an automount entry that does not exist, the LDAP directory server
will not return an entry, all the negative result will be stored in the
negative cache.
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
By default, caching is enabled.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. The default value is 1800 (30 minutes).
negcache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the negative
cache.
The default value is 1800 (30 minutes).
[automountMap]
Cache settings for the automount map cache.
enable=<yes|no>
ldapclientd only caches entries for this section, when it is enabled.
By default, caching is enabled.
poscache_ttl=<0-2147483647>
The time, in seconds, before a cache entry expires from the positive
cache. The default value is 1800 (30 minutes).
negcache_ttl=<0-2147483647>
190 Administering LDAP-UX Client Services
The time, in seconds, before a cache entry expires from the negative
cache.
The default value is 7200 (2 hours).
[printers]
Any printer setting defined here will be used by the LDAP printer
configurator.
start=<yes|no>
Determines if the printer configurator service will start when
ldapclientd is initialized. If it is enabled, the printer configurator will
start when ldapclientd is initialized. By default, the start parameter
is enabled.
search_interval=<1800-1209600>
Defines the interval, in seconds, before the printer configurator performs
a printer search in the directory server. The default value is 86400 (in
seconds). The minimum value is 1800 (30 minutes) and the maximum
value is 1209600 (2 weeks).
max_printers= 50 (default value)
Defines the maximum printer objects that printer configurator services
will handle. For example, a number of 100 printer entries is returned
to the printer configurator after a scheduled printer search. If the
max_printers value is set to 50, only the first 50 printer entries
received by the printer configurator will be processed. For this
configuration parameter, the value must be greater than 0 and the
maximum value is unlimited. The default value is 50.
lpadmin_option
Defines the lpadmin options. Do not include the-p, -orm and -orp
options in the option fields. The LDAP printer configurator provides the
required information of printer name (-p), remote machine name (-orm)
and remote printer name (-orp) during the run time. Do not include
any other parameters, such as stderr or stdout redirection options. If the
option fields of the lpadmin_option parameter are empty or the
lpadmin_option parameter does not exist, the default lpadmin
options are used. By default, lpadmin_option=-mrmodel
-v/dev/null -ocmrcmodel -osmrsmodel.
For detailed information about valid options and the syntax, see the
lpadmin manpages.
7.1.3.2 Example Configuration file
The LDAP client configuration file is automatically loaded when the product is installed. For additional
information, see the ldapclientd(4) and ldapcltd(4)manpages.
If you update LDAP-UX Client Services from an older version, such as B.03.00 or B.03.10, the
new configuration file will be /opt/ldapux/newconfig/etc/opt/ldapux/
ldapclientd.conf.
The following is a sample ldapclientd.conf configuration file. For a sample
ldapclientd.conf configuration file created when using autosetup, see Section C.4
(page 417).
#!/sbin/sh
# @(#) $Revision: 1.12 $
# ldap client daemon configuration.
#
# Please note, the below keys are case sensitive.
#
7.1 Managing the LDAP-UX client daemon
191
# Example:
#
# [passwd]
# enable=yes
# poscache_ttl=600
# negcache_ttl=600
#
# Note that "TTLs" (time to live) values are in seconds.
# Note that cache sizes are in bytes.
#
[StartOnBoot]
enable=yes
[general]
# If the proxy user is used and defined in /etc/opt/ldapux/pcred, this
# flag indicates if the proxy user does not hold privileged LDAP
# credentials, meaning the proxy user is restricted in it's rights to
# access "private" information in the directory server. Because
# ldapclientd provides an interface to access arbitrary information
# (attributes), ldapclientd needs to know if the proxy credential has
# more rights that it should.
#
# By default, and if set to zero, ldapclientd assumes the proxy user
# has privledged credentials, and thus will not allow access to attributes
# beyond that of the RFC2307 schema. However, you can ammend the list of
# allowed attributes using the allowed_attribute paramter defined below.
#
# If proxy_is_restricted is set to 1, then you are attesting that the
# directory server is restricting access to private or other confidential
# information from access by the proxy user.
proxy_is_restricted=1
# Allows the ldapclientd interface to return attributes that are associated
# with RFC2307-based services (such as users and groups), but that those
# attributes are not specifically part of the RFC2307 schema. Any attribute
# specified below should be considered public information.
allowed_attribute=hosts:sshPublicKey
allowed_attribute=passwd:sshPublicKey
# Maximum number of connections ldapclientd can establish to
# the directory server (or multiple servers when in a multi-domain
# environment).
#
max_conn=100
#
# Time between an inactive connection to the directory server is
# brought down and cleaned up.
#
connection_ttl=300
#
# Number of threads in ldapclientd.
#
num_threads=10
#
# Time to clean up socket files created by client applications that
# were terminated abnormally.
#
socket_cleanup_time=300
#
# Interval between how often ldapclientd identifies and cleans up
# stale cache entries.
#
cache_cleanup_time=10
#
# How often ldapclientd should re-read the ldapux-clientd.conf file.
#
update_ldapux_conf_time=600
#
# Maximum number of bytes that should be cached by ldapclientd.
# This value is the maximum upper limit of memory that can be
# used by ldapclientd. If this limit is reached, new entries are
# not cached, until enough expired entries are freed.
#
cache_size=10000000
192 Administering LDAP-UX Client Services
#
# A state, a virtual connection between the client and LDAP server,
# is created for the setXXent() request, and stays for the subsequent
# getXXent() requests. If no getXXent() requests are received in the
# specified time interval (seconds), the state will be removed.
state_dump_time=300
#
# Maximum number of states ldapclientd allows. "States" are the number
# of enumerations ldapclientd will handle simultaneously. This number
# must be less than max_conn and it is configured as % of max_conn.
#
max_enumeration_states=80%
#
# How often ldapclientd should re-build the compat information to
# reflect changes of "+/-" entries in /etc/passwd and /etc/group, as
# well as changes of netgroup configuration.
# The default value is 86400 seconds (1 day), the allowed range is
# from 600 seconds (10 minutes) to 2592000 seconds (30 days).
#
flush_compat_info_time=86400
#
[passwd]
enable=yes
[group]
enable=yes
[netgroup]
enable=yes
[uiddn]
enable=yes
[domain_pwd]
enable=yes
[domain_grp]
enable=yes
[automount]
enable=yes
[automountmap]
enable=yes
[dynamic_group]
# "dynamic_group" has its own default cache_size, poscache_ttl and negcache_ttl.
cache_size=10000000
enable=yes
poscache_ttl=43200
negcache_ttl=43200
[longterm_cache]
#
Should long term cache enabled ?
# enable=no
#
How long before data is considered stale and not usabled. 1,209600 = 2 weeks.
# longterm_expired_interval=1209600
#
How frequently should save long term data to permanemt storage. 900 = 15 minutes.
# longterm_cache_backup_interval=900
#
How much memory to allocate fpr the long term cache, which stores user and group
#
information. This cache is only used by the working set of users and groups. The
#
working set means any user or group being used or displayed on the system. If you
#
have enumerous large groups with enumerous members, this value should be at least
#
twice as large as the combined size of all those groups.
# longterm_cache_size=50000000
#
Should long term caching support enumeration of users and groups. If getpwent()
#
and getgrent() are not required, this can be disabled.
# longterm_enum_enable=no
#
How frequently should the HP-UX client go to the directory server to refresh the
#
enumeration cache. 86400 = one per day.
# longterm_enum_search_interval=86400
#
#enable=no
#longterm_expired_interval=1209600
#longterm_cache_backup_interval=900
#longterm_cache_size=50000000
#longterm_enum_enable=no
7.1 Managing the LDAP-UX client daemon
193
#longterm_enum_search_interval=86400
[printers]
# Define the status of the printer configurator when ldapclientd starts.
# Option "yes" means the printer configurator service will be activated
# when ldapclientd starts. "no" means the printer configurator will be
# disabled when ldapclientd starts. Default is "yes".
start=yes
# Define the maximum printer objects that the printer configurator service
# will handle. The value must be greater than 0.
# Default value is 50.
max_printers=50
# Define the interval, in seconds, before the printer configurator service
# searches for printer objects. The minimum value is 1800 (30 minutes) and the
# maximum value is 1209600 (14 day). Default value is 86440 seconds.
search_interval=86400
#
#
#
#
#
#
#
#
#
#
#
#
#
User defined lpadmin options. If the lpadmin_option field is empty or the
lpadmin_option is commended out, the default lpadmin options are used.
"-mrmodel -v/dev/null -ocmrcmodel -osmrsmodel"
Please DO NOT INCLUDE the -p -orm -orp options in the option field.
The required information of printer name (-p), remote machine name (-orm) and
remote printer name (-orp) will be provided by printer configurator during
the run time.
To enable the user define lpadmin options,
remove the followng # sign and customize the lpadmin options.
lpadmin_option=-mrmodel -v/dev/null -ocmrcmodel -osmrsmodel
7.2 Integrating LDAP-UX with Trusted Mode
This section describes features and limitations of integrating LDAP-UX with HP-UX Trusted Mode,
and configuration considerations and responsibilities.
7.2.1 Overview
LDAP-UX Client Services B.03.30 or later supports coexistence with Trusted Mode. This means that
local-based accounts can benefit from the Trusted Mode security policies, while LDAP-based accounts
benefit from the security policies offered by the LDAP server. This release of LDAP-UX also enables
LDAP-based and local-based accounts to be audited on the Trusted Mode.
The coexistence of LDAP-UX and Trusted Mode supports certain security features, but also has
limitations and usage requirements that you must be aware of. For detailed information, see
Section 7.2.2 (page 194).
7.2.2 Features and limitations
This subsection describes features and limitations of integrating LDAP-UX with Trusted Mode.
7.2.2.1 Auditing
Integrating LDAP-UX with Trusted Mode enables accounts stored in the LDAP directory to log in to
a local host and to be audited on the Trusted Mode. The following describes the auditing features
and limitations. To use these security features, you must enable the audit subsystem on the Trusted
Mode local host:
194
•
Auditing of both LDAP-based and local-based (/etc/passwd) accounts is possible. By default,
auditing is disabled for all LDAP-based accounts. However, you can use the audusr command
(with option -a or -d) to alter the auditing flag for individual LDAP-based account.
•
For LDAP-based accounts that are not yet known to the system, you can configure an initial
setting for the auditing flag. You can configure this flag such that when an account becomes
known to the system for the first time, auditing for that account is immediately enabled or
Administering LDAP-UX Client Services
disabled. This flag is defined as the initial_ts_auditing parameter in the /etc/opt/
ldapux/ldapux_client.conf file.
•
You must manage Trusted Mode attributes for all accounts on each host. Trusted Mode attributes
for LDAP-based accounts are not stored in the LDAP directory server. For example, enabling
auditing for an account on host A does not enable auditing on host B.
•
Audit IDs for LDAP-based accounts are unique on each system. Audit IDs are not synchronized
across hosts running in the Trusted Mode.
•
When an LDAP-based account name is changed, a new audit ID is generated on each host
that the account is newly used on. The initial_ts_auditing flag is reset to the default
value defined in the /etc/opt/ldapux/ldapux_client.conf file.
•
When an account is deleted from LDAP, the audit information for that account is not removed
from the local system. If that account is reused, the audit information from the previous account
is reused. You can choose to manually remove entries from the Trusted Mode database by
removing the appropriate file under the /tcb/files/auth/... directory, where "..."
defines the directory name based on the first character of the account name.
•
You can use the audisp command to display information about LDAP-based accounts.
However, if an LDAP-based account has never logged in to the system (through telnet,
rlogin, and so forth), the audisp -u <username> command displays the message like
"audisp: all specified users names are invalid."
7.2.2.2 Password and account policies
The primary goal of integrating Trusted Mode policies and those policies enforced by an LDAP
server is coexistence. This means that Trusted Mode policies are not enforced on LDAP-based
accounts, and LDAP server policies are not enforced on local-based accounts. The password and
account policies and limitations are described as follows:
•
Accounts stored and authenticated through the LDAP directory adhere to the security policies
of the directory server being used. These policies are specific to the brand and version of the
directory server product deloyed. Examples of these policies include password expiration,
password syntax checking, and account expiration. No policies of the HP-UX Trusted Mode
product apply to accounts stored in the LDAP server.
•
When you integrate LDAP-UX on an HP-UX system with a supported directory server, if an
LDAP-based user attempts to log in to the system, but provides the incorrect password multiple
times in a row (the default is three times in a row), Trusted Mode attempts to lock the account.
However, the Trusted Mode attributes do not impact LDAP-based accounts. So, if the user
eventually provides the correct password, he or she can log in.
7.2.2.3 PAM configuration file
•
If you integrate LDAP-UX Client Services with the HP-UX Directory Server or Red Hat Directory
Server, you must define the PAM_LDAP library before the pam_unix library in the /etc/
pam.conf file for all services. You must set the control flag for both PAM_LDAP and PAM_UNIT
libraries to required under session management. For the proper configuration, see
Section D.3 (page 426).
•
If you integrate LDAP-UX Client Services with the Windows Server 2003 R2 or 2008 Active
Directory Server, you must define the pam_krb5 library before the pam_unix library in the
/etc/pam.conf file for all services. In addition, the control flag for both pam_krb5 and
pam_unixlibraries must be set to required for session management. For the proper
configuration, see Section D.4 (page 428).
7.2 Integrating LDAP-UX with Trusted Mode 195
7.2.2.4 Limitations
•
The authck -d command removes the /tcb/files/auth/... files created for LDAP-based
accounts. When the LDAP-based account logs into the system again, a new /tcb/files/
auth/... file with new audit ID is recreated. Therfore, it is not recommended to run the
authck -d command when you configure LDAP-UX with Trusted Mode.
•
You cannot use the Trusted Mode management subsystem in SAM to manage LDAP-based
accounts.
•
The LDAP repository and /etc/passwd repository must not contain accounts with the same
login name or account number.
•
Except for the audit flag, you cannot modify other Trusted Mode properties/policies for
LDAP-based accounts. For example, attempting to lock an LDAP-based account by modifying
the Trusted Mode field for that user does not prevent that account from logging in to the host.
Instead, you must disable the account on the LDAP server itself. No runtime warning will be
given that the local locking of the account has no effect. It is important that all system
administrators are properly trained, so that administrative locks on accounts have the desired
effect.
7.2.3 Configuration parameter
LDAP-UX Client Services provides one configuration parameter, initial_ts_auditing, available
for you to configure the initial auditing setting for the LDAP-based account. This parameter is defined
in the /etc/opt/ldapux/ldapux_client.conf file.
7.3 Configuring SASL/GSSAPI support for proxy user authentication
(Windows ADS only)
LDAP-UX Client Services supports the SASL / Generic Security Services Application Programming
Interface (GSSAPI) authentication method for Kerberos v5. Currently, Kerberos v5 is the only security
mechanism that is implemented to work with GSSAPI. LDAP-UX Client Services 5.0 provides
SASL/GSSAPI authentication method support for Microsoft Windows 2003 R2 and 2008 Active
Directory only. SASL/GSSAPI authentication is limited to proxy user authentication for the name
service subsystem. Host, service or other principals may be used for the LDAP-UX proxy identity.
Because SASL/GSSAPI is only used for proxy authentication, user authentication to a Windows
domain should still be configured using PAM_KERBEROS.
For information on the realm, principal, keytab, and credential cache definitions used by the
SASL/GSSAPI authentication, refer to Configuration Guide For Kerberos Product on HP-UX and
Installing, Configuring and Administering The Kerberos Server on HP-UX 11i at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX Kerberos Data Security Software)
NOTE: For HP-UX 11i v2 (11.23) and v3 (11.31), do not use the default Kerberos product that
is installed with your OS. Instead, download and use the latest version of Kerberos (KRB5CLIENT)
from the HP Software Depot at:
https://h20392.www2.hp.com/portal/swdepot/
displayProductInfo.do?productNumber=KRB5CLIENT
For information about version support and required patches, see the section titled “Kerberos support
on HP-UX 11i v2 or v3” in the LDAP-UX Integration Release Notes.
For more information, see the Kerberos Client Release Notes available at:
http://www.hp.com/go/hpux-security-docs (Click HP-UX Kerberos Data Security Software)
For an overview of the various authentication methods you can configure with LDAP-UX Client
Services, including their strengths and weaknesses, see Section 2.4.6.1 (page 79).
196
Administering LDAP-UX Client Services
7.3.1 How SASL/GSSAPI works
Figure 14 SASL/GSSAPI environment
KDC Server
AS
1
2
TGS
3
4
5
Windows Active
Directory
LDAP-UX Client Services
6
The following describes how LDAP-UX binds a client using SASL/GSSAPI to the directory server
shown in Figure 14:
1. The LDAP-UX Client Service sends the principal name and password to the Authentication Server
(AS).
2. The AS validates the principal and sends a Ticket Granting Ticket (TGT) and associated session
key to the LDAP-UX Client Services. LDAP-UX Client Services stores the TGT and session key
information in the credential cache, /etc/opt/ldapux/krb5cc_ldap_gssapi.
3. LDAP-UX Client Services uses the TGT and requests a service ticket from Ticket Granting Service
(TGS).
4. TGS sends the service ticket and other information to LDAP-UX Client Services.
5. LDAP-UX Client Services sends the service ticket and binds to the directory server.
6. LDAP-UX Client Services verifies the received information and authenticates the LDAP client.
7.3.2 Configuring the proxy user
SASL/GSSAPI authentication is only for proxy user authentication for name service subsystem.
When proxy is configured, you use either a user or service principal as a proxy user.
7.3.2.1 Configuring the user principal
The user principal must be configured in the KDC. The user principal may be specified with a realm
(for example, user1@CUP.HP.COM) or without a realm (for example, user1). When no realm
is specified, the realm information is retrieved from /etc/krb5.conf. The credential (password)
is the same one used to create the user principal in the KDC.
7.3.2.2 Service/host principal and keys
A Kerberos keytab file contains service or host principals and associated keys information. Users
can bind using the service or host keys. The keytab file can contain multiple principals and keys.
Users can configure which service key to use. For example, the following /etc/krb5.keytab
file contains two principals:
$ klist -k
7.3 Configuring SASL/GSSAPI support for proxy user authentication (Windows ADS only)
197
Keytab name: FILE:/etc/krb5.keytab
Principal
-------------------------------------------1 ldapux/hpntc10.cup.hp.com@HP.COM
1 host/hpntc10.cup.hp.com@HP.COM
7.3.2.3 Configuring a principal as the proxy user
The following describes three different ways to configure a principal as the proxy user:
•
Configure a user principal:
Use ldap_proxy_config -i (or use the -d and -c options) to enter a Kerberos user
principal and its credential (password).
The following is an example using the ldap_proxy_config -i command with proxy user
without the realm information proxyusr and password proxywd.
cd /opt/ldapux/config
./ldap_proxy_config -i
proxyusr
proxywd
NOTE: This command has no prompt. You must enter the proxy user proxyusr and password
proxywd on two separate lines, as shown in this example.
The following is an example to use ldap_proxy_config -d -c command to create a
proxy user with the realm information john@CUP.HP.COM and the proxy user credential
proxycrd:
cd /opt/ldapux/config
./ldap_proxy_config -d john@CUP.HP.COM -c proxycrd
•
Configure a service or host principal:
Use ldap_proxy_config with the -i or -d option to specify the service or host principal
with or without entering a password. If the password is provided, LDAP-UX will retrieve the
password information from /etc/opt/ldapux/pcred file. When no password is specified,
LDAP-UX Client Services assumes the proxy user is a service or host principal and retrieves
the credential information from the keytab file.
The following is an example using the ldap_proxy_config -i command to create a host
principal hpntcA.cup.hp.com:
cd /opt/ldapux/cinfig
./ldap_proxy_config -i host/hpntcA.cup.hp.com@HP.COM
This command has no prompt. You must enter the host principal on a separate line, as shown.
•
Use only the keytab file without configuring proxy:
With this method, any old pcred file must be deleted. LDAP-UX Client Services uses ldapux/
<FQHN>@<REALM> as the default service principal. If it does not exist, the host/
<FQHN>@<REALM> in the keytable file is the principal to be used. FQHN stands for Fully
Qualified Host Name.
The principal defined in a keytab file can be shared among several services, such as Kerberized
Interface Service or LDAP-UX using the host principal for authentication. The LDAP-UX proxy principal
is used solely for LDAP-UX.
7.3.3 Keytab file
LDAP-UX enables you to specify the keytab file when you use the SASL/GSSAPI authentication. To
specify the keytab file, run the setup program or use the kerberos_keytab_file option in
/etc/opt/ldapux/ldapux_client.conf. If you do not specify a keytab file, LDAP-UX will
use the default file specified in /etc/krb5.conf (for a sample of this file, see “Sample /etc/
198 Administering LDAP-UX Client Services
krb5.conf file” (page 434)). If there is no default keytab file configured in /etc/krb5.conf,
then the keytab file /etc/krb5.keytab will be used.
Each service principal must have a service key known by every domain controller, which also acts
as a KDC.
Use the ktpass tool to create the keytab file and set up an identity mapping the host account.
The following is an example showing how to run ktpass to create the keytab file for the HP-UX
host myhost with the KDC realm cup.hp.com:
C:> ktpass -princ host/myhost.cup.hp.com@CUP.HP.COM -mapuser myhost -pass
mypasswd -out unix.keytab
7.3.4 Downloading SASL/GSSAPI profiles
LDAP-UX Client Services does not support automatic downloading of the LDAP-UX profile when
used with SASL/GSSAPI authentication using a host or service principal, where that principal's
key is stored in a Kerberos keytab file. This limitation impacts the ability of the LDAP-UX product
to support the Profile TTL (Time To Live) feature, which automatically downloads a profile when its
profileTTL time has expired.
You can download profiles manually using the get_profile_entry command, as long as you
provide a principal and password on the command line. The following command shows an example
of how to download the profile manually. If your profile changes frequently, you may want to place
this in a script that is called periodically by cron.
/opt/ldapux/config/get_profile_entry -s NSS -D \
"<administrator@my.domain.org>" -w "<adminpassword>"
7.3.5 Changing authentication methods
If you want to switch from your current authentication method, such as from SIMPLE to SASL/GSSAPI,
TLS:SIMPLE or TLS:SASL/GSSAPI, you must restart the ldapclientd daemon after making the
configuration changes. This assures that the proper GSSAPI, Kerberos, or SSL initialization is
completed.
7.4 Configuring PAM_AUTHZ login authorization
PAM is an industry standard authentication framework that is supplied as an integrated part of the
HP-UX system. PAM gives system administrators the flexibility of choosing any authentication service
available on the system to perform authentication. The PAM framework also enables new
authentication service modules to be plugged in and made available without modifying the PAM
enabled applications. The library /usr/lib/security/libpam_authz.so.1 (and
architecture-dependent library paths) provides the access control functionality described in this
section. You can add it to your existing /etc/pam.conf as shown in Section D.5 (page 430) (for
an HP directory server environment) and Section D.6 (page 432) (for a Windows ADS environment).
NOTE: The PAM_AUTHZ library should be configured in the pam.conf authentication
management and account management sections only. The PAM_AUTHZ module is an authorization
module only (not authentication). It should be listed before the PAM_LDAP or PAM_KERBEROS
libraries and flagged as required.
This section assumes you have some knowledge of how to configure PAM libraries in the /etc/
pam.conf file. For more information about configuring libraries in the pam.conf file, see “Sample
PAM configuration (pam.conf) files ” (page 420). In addition, see the Managing Systems and
Workgroups: A Guide for HP-UX System Administrators document, available at the following
location:
www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
7.4 Configuring PAM_AUTHZ login authorization 199
The PAM framework, together with the PAM_AUTHZ service module (which is defined in the
PAM_AUTHZ library known as libpam_authz) supplied with LDAP-UX Client Services, provide
support for account management services. These services enable the administrator to control who
can log in to the system based on netgroup information found in the /etc/passwd and /etc/
netgroup files. PAM and PAM_AUTHZ can also be configured to utilize LDAP-UX Client Services
to retrieve the information from a LDAP directory server to perform access of authorization.
NOTE: Beginning with version 5.0, LDAP-UX Client Services supports integrated Compat Mode
to control which users are visible on a host; user accounts are referenced by netgroups specified
in the /etc/passwd file. For more information, see Section 2.5.5 (page 102). This feature is not
supported when using LDAP-UX Client Services with Windows ADS.
Starting with LDAP-UX Client Services B.04.00, PAM_AUTHZ has been enhanced to provide
administrators a simple security configuration file to set up a local access policy to better meet
their need in the organization. PAM_AUTHZ uses the access policy to determine which users are
allowed to log in to the system. A policy specifies which groups, LDAP groups, users or other access
control objects (such as objects defined by LDAP search filters) are allowed to log in to the system.
This flexibility enables you to allow or deny access to a host or application based on a user's
membership in a group, or role within a organization. For example, PAM and PAM_AUTHZ can
define an access rule that utilizes a LDAP directory server to state that if userA works for manager
Sam then the criteria is met. When the rule is evaluated, a request would be sent to the LDAP
directory and if the attributes were found, the user could be granted or denied access.
NOTE: For information about other means for controlling access to the system, see Section 2.5.6
(page 104) (for HP directory server environments) and Section 3.5.4 (page 157) (for Windows ADS
environments).
7.4.1 Policy and access rules
Access rules are the basic elements of access control. Administrators create access rules that restrict
or permit a user's access permission. A policy is the collection of these different sets of access rules
in a given order. This consolidated list of rules defines the overall access strategy of a local client
machine. PAM_AUTHZ enables administrators to create an access policy by defining different
types of access rules and to save the policy in a file.
7.4.2 How login authorization works
The system administrator can define the access rules and store them in an access policy file.
PAM_AUTHZ uses these access rules defined in the policy file to control the login authorization.
200 Administering LDAP-UX Client Services
Figure 15 PAM_AUTHZ environment
1
PAM-enabled
application
2
Policy
configuration
file
5
7
3
PAM_AUTHZ
6
Authentication
modules, for
example:
PAM_KERBEROS
PAM_LDAP
4
LDAP_UX
client daemon
ldapclientd
/etc/group
/etc/netgroup
LDAP
directory
server
The following describes the PAM_AUTHZ policy validation process for the user login authorization
shown in Figure 15 (page 201):
PAM_AUTHZ environment
1. The administrator defines access rules and saves them in a local access policy configuration
file.
2. PAM_AUTHZ service module receives an authorization request from PAM framework. It processes
all the access rules stored in the access policy configuration file.
3. If a rule indicates that the required information is stored in a LDAP server, PAM_AUTHZ constructs
a request message and sends to the LDAP client daemon, ldapclientd. The LDAP client daemon
performs the actual LDAP query and returns the result to PAM_AUTHZ. Then the access rule is
evaluated and the final access right is returned.
4. If a rule indicates that the required information is in the UNIX files. PAM_AUTHZ retrieves user's
information from /etc/passwd, /etc/group or /etc/netgroup file through getpwname()
or getgrname() system calls. Then the rule is evaluated and the final access right is returned.
5. PAM_AUTHZ returns the corresponding pam result to PAM framework. The decision is returned
to the application which called the PAM API.
6. If the user has the permission to log in, then the decision is returned to the next PAM service
module that is configured in the pam.conf file, such as PAM_LDAP or PAM_KERBEROS. If the
access rule passed but is assigned the required action type, then PAM_AUTHZ continues and
evaluates the next access policy rule. If the access rule failed and is assigned the required action,
or if processing reaches the end of the rules (after they all failed), then login is denied.
7. The PAM service module returns the authentication result to the application that called the PAM
API.
7.4.3 PAM_AUTHZ security policy enforcement
PAM_AUTHZ supports enforcement of account and password policies stored in a directory server.
This feature works with secure shell (ssh) and with r-commands, where rhost is enabled and
authentication is performed by the command itself rather than by the PAM (Pluggable Authentication
Module) subsystem.
7.4 Configuring PAM_AUTHZ login authorization 201
For more information on how to configure access rules in the access policy configuration file, set
global policy access permissions, and configure the pam.conf file for security policy enforcement
when using ssh key pair or r-commands, see Section 7.4.10 (page 210).
7.4.3.1 Authentication using PAM
The PAM framework is pluggable, the backend support for PAM authentication, account
management, session management, and password management services can be directed to
alternate repositories, such as a directory server or Kerberos KDC. When the authentication functions
are invoked, the UNIX identity is translated into an ID that represents that user in the backend
repository (such as a distinguished name in a directory server or a principal in a Kerberos KDC).
If the backend authentication operation succeeds, then the PAM backend authentication function
will return success to the PAM authentication subsystem.
With LDAP (PAM_LDAP) or Kerberos (PAM_KERBEROS), when authentication occurs, not only is
the user authenticated, but security policy verification also occurs. If the account is locked or a
password has expired, the directory server or KDC will return an error to the PAM authentication
subsystem. However, the design of PAM is such that authentication and policy enforcement are
handled by two different functions, authentication and account management functions, respectively.
However, in some cases, services such as ssh and rlogin can authenticate users without calling
the PAM authentication function. But those services might still call the PAM account management
function to determine if the account is disabled or if a password has expired. In this case, backend
PAM modules such as PAM_LDAP and PAM_KERBEROS might not be able to perform security
policy verification, since that verification is done in the authentication function. You can use
PAM_AUTHZ to supplement security policy verification that is not performed by PAM_LDAP or
PAM_KERBEROS, if the security policy information can be found in the directory server.
For more information about pam.conf configuration and sample files, see “Sample PAM
configuration (pam.conf) files ” (page 420).
7.4.3.2 Authentication with secure shell (ssh) and r-commands
For LDAP-UX B.04.00 and previous releases, a user defined in an LDAP directory who tries to log
on to a UNIX system using ssh key pair or the rhost enabled r-command will always be able to
log in even if this user’s account has been locked or password has expired. These applications
and commands do not need to call the PAM (Pluggable Authentication Module) authentication
functions, but perform their own authentication instead. When this occurs, the LDAP bind or Kerberos
authentication operation is never performed. Thus, the directory server or KDC is never given the
opportunity to perform security policy enforcement.
LDAP-UX Client Services B.04.10 or later provides PAM_AUTHZ features to support enforcement
of account and password policies, stored in an LDAP directory server, for applications/commands
(such as ssh or r-command) where authentication is not performed by the PAM subsystem, but is
performed by the command itself.
7.4.4 Policy file
The system administrator can define a local access policy that can be stored in an access policy
file. The default access policy file is /etc/opt/ldapux/pam_authz.policy, but you can store
the local access policy in an alternate location by setting the policy option in pam.conf. The
PAM_AUTHZ service module uses this local policy file to process the access rules and to control
the login authorization. Any service that loads the libpam_authz.1 library will also load this
file. The access policy file location is set per-service in pam.conf, so access rules can be customized
for each service . For example:
login
ftp
auth
auth
required libpam_authz.so.1 policy=/etc/opt/ldapux/login.policy
required libpam_authz.so.1 policy=/etc/opt/ldapux/ftp.policy
202 Administering LDAP-UX Client Services
For a sample pam.conf file configured to define an access policy file for security enforcement, see
Section D.5 (page 430) (for an HP directory server environment) and Section D.6 (page 432) (for a
Windows ADS environment).
LDAP-UX Client Services provides a sample configuration file, /etc/opt/ldapux/
pam_authz.policy.template. This sample file shows you how to configure the policy file to
work with PAM_AUTHZ. You can copy this sample file and edit it using the correct syntax to specify
the access rules you want to authorize or exclude from authorization. For detailed information on
how to construct an access rule in the policy file, see Section 7.4.7 (page 204).
NOTE: By default, the allow:unix_local_user access rule in the /etc/opt/ldapux/
pam_authz.policy.template file is enabled.
7.4.5 Policy validator
PAM_AUTHZ works as a policy validator. After it receives a PAM request, it starts to process the
access rules defined in pam_authz.policy. It validates and determines the user's login
authorization based on the user's login name and the information it retrieves from various name
services. The result is then returned to the PAM framework.
PAM_AUTHZ processes access rules in the order they are defined in the access policy file. It stops
processing the access rules when any one of the access rules is evaluated to be true (match). That
rule is called the "authoritative" rule. If any access rule is evaluated to be false (no match), the rule
is skipped. If any access rule is evaluated to be true (match) but has the action required assigned
to it, then access rule processing continues with the next rule. An access rule that has the action
required assigned to it that evaluates to false (no match) will cause processing to end and the
user is restricted from login. If all access rules in the policy file have been evaluated but the user's
access right cannot be determined, the user is restricted from login.
NOTE:
•
If the user's login name is root or UID is 0, PAM_AUTHZ does not process the access rules
defined in the access policy file. The root user is always granted login access.
•
The default <action> of PAM_AUTHZ if no authoritative rule is found is deny.
PAM_AUTHZ skips an access rule and does not process it when:
•
An access rule contains the wrong syntax.
•
PAM_AUTHZ processes the ldap_filter and ldap_group types of access rules by querying
the LDAP directory server through the ldapclientd daemon. If LDAP-UX Client Services is
not running, PAM_AUTHZ skips all the ldap_filter and ldap_group types of rules.
7.4.5.1 Example of access rule evaluation
The following shows an example of an access policy file:
allow:unix_user:user1,user2,user3,user4
required:ldap_filter:(status=active)
allow:unix_group:group1,group2
deny:unix_group:group11,group12
allow:netgroup:netgroup1,netgroup2
allow::ldap_group:ldapgroup1,ldapgroup2
allow:ldap_filter:(&(manager=Joeh) (department=marketing)(hostname=$[HOSTNAME]))
PAM_AUTHZ processes access rules in the order they are defined in the access policy file. It stops
evaluating the access rules when any one of the access rules is matched, unless that rule has the
action required assigned. In the preceding example, if the user2 user attempts to log in, it
matches one of the user names in the first access rule, and PAM_AUTHZ stops evaluating the rest
of the access rules and allows the user2 user to log in. For another example, user5 attempts to
log in and this user is only a member of ldapgroup2. PAM_AUTHZ validates login access for
user5, and when the fifth access rule is evaluated to be true, grants login access to that user.
7.4 Configuring PAM_AUTHZ login authorization 203
Now assume that the user6 user has the attribute status set to active, reports to Joeh, the
user's job is related to marketing and has a hostname attribute with the returned value HostSrv
in the user's entry in the LDAP directory. PAM_AUTHZ starts to validate login access for user6
by evaluating all the access rules defined in the access policy file. The second rule is evaluated to
be true, but since the action assigned to this rule is required, processing continues with the next
rule. The sixth access rule is evaluated to be true, and the user6 is allowed to log in to host
HostSrv.
7.4.6 Dynamic variable support
Dynamic variable support is a method by which an access rule can be defined where part or all
of the policy criteria will be determined at the time the rule is evaluated. For example, the name
of the computer from which the user attempts to log in can be substituted into the access rule to be
evaluated. See Section 7.4.9 (page 209) for more information on how to define an access rule
using dynamic variable support.
7.4.7 Constructing an access rule in the access policy file
In the access policy file, an access rule consists of three fields as follows:
<action>:<type>:<object>
All fields are mandatory except for the <object> field when passwd_compat,
unix_local_user, or Other is specified in the <type> field. If any field is missing or contains
the incorrect syntax, the access rule is considered to be invalid and is ignored by PAM_AUTHZ.
These fields have the following limitations:
•
No leading or trailing empty space is allowed in a field
•
Fields are separated by a separator, :
•
No leading or trailing empty space is allowed in a separator
•
An access rule is terminated by a carriage return
No rule may exceed 2048 characters, the length of LINE_MAX, which is a POSIX standard whose
value is discoverable using the getconf command. For more information about the maximum
length of fields specified in a rule, see Table 18 (page 204).
7.4.7.1 Fields in an access rule
Table 18 summarizes all possible values and the syntax of an access rule:
Table 18 Field syntax in an access rule
<action>
<type>
<object>
deny, allow,required,
<pam_code>
unix_user
A list of user names. It can be the multi-valued field. Each
value is a character string that is separated by a separator
"," (ASCII 2C HEX).
Example:
user1, user2, user3
The length of a user name may not exceed 255
characters, the length of LOGIN_NAME_MAX, which is
a POSIX standard whose value is discoverable using the
getconf command.
deny, allow, required,
<pam_code>
204 Administering LDAP-UX Client Services
unix_local_user
No value is required.
Table 18 Field syntax in an access rule (continued)
<action>
<type>
<object>
deny, allow, required,
<pam_code>
unix_group
A list of group names. It can be the multi-valued field.
Each value is a character string that is separated by a
separator "," (ASCII 2C HEX).
Example:
group1, group2, group3
The length of a name may not exceed 255 characters,
the length of LOGIN_NAME_MAX, which is a POSIX
standard whose value is discoverable using the getconf
command.
required, <pam_code>
passwd_compat
No value is required.
deny, allow, required,
<pam_code>
netgroup
A list of netgroup names. It can be the multi-valued field.
Each value is a character string that is separated by a
separator ","(ASCII 2C HEX).
Example:
netgroup1, netgroup2, netgroup3
deny, allow, required,
<pam_code>
ldap_group
The distinguished name of an LDAP group with
groupofnames object class or groupofuniquenames
object class. It is a single-valued field. No separator is
required. The syntax of DN is defined in RFC2253.
Example:
cn=ldapgroup1,cn=groups,dc=mydomain,dc=com
deny, allow, required,
<pam_code>
ldap_filter
A single search descriptor that specifies one or more
(attribute=value) or (attribute=$[variable_name]) pairs.
$[variable_name] is a dynamic variable. It is a single
value field. Only one search filter is allowed. No
separator is required. The syntax of DN is defined in
RFC2254.
Example:
(&(manager=Joeh)(department=sales)(hostcontrol=$[HOSTNAME]))
LDAP search filters may not exceed 512 characters.
deny, allow, required,
<pam_code>
other
No value is required.
status
<library_name>
<function_name>
The valid value for this Specifies the function name in <library_name> that is
field can be rhds or called to evaluate certain policy settings of the login user.
ads.
Example:
status:ads:check_ads_policy
For more information, see Section 7.4.10.1 (page 210).
The following describes in more detail the fields defined in an access rule:
<action>
This field defines a user's final access permission if an access rule is evaluated to
be true. Valid entries can be allow, deny, required, and PAM return codes.
allow, deny, and required are character strings and the value itself is not case
sensitive. In additional to the general return codes, allow and deny, LDAP-UX
Client Services B.04.10 or later PAM_AUTHZ supports the meaningful PAM return
codes to the application which called the PAM API. PAM_AUTHZ does not evaluate
an access rule if no option is defined or if the action field contains an invalid
string.
<action> field can be one of following values:
7.4 Configuring PAM_AUTHZ login authorization 205
allow
This option indicates that a user is granted the login authorization.
deny
This option indicates that a user is denied the login authorization.
required
If the rule evaluates to false, this option indicates that a user is denied login
authorization; if the rule evaluates to true, the option indicates processing should
continue to the next rule.
<pam_code>
One of the following meaningful PAM return codes may be specified in the
<action> field, the PAM return codes are character strings:
•
PAM_SUCCESS
•
PAM_PERM_DENIED
•
PAM_MAXTRIES
•
PAM_AUTH_ERR
•
PAM_NEW_AUTHTOK_REQD
•
PAM_AUTHTOKEN_REQD
•
PAM_CRED_INSUFFICIENT
•
PAM_AUTHINFO_UNAVAIL
•
PAM_USER_UNKNOWN
•
PAM_ACCT_EXPIRED
•
PAM_AUTHTOK_EXPIRED
For example, if the PAM_AUTHZ policy rule indicates that an account has been
locked out or a password has expired, PAM_AUTHZ can return an appropriate PAM
error code instead of a general deny error code.
<status>
Use of the status rule only applies when the action is to call a library function. In
this case, the status rule is always evaluated and always returns a code to the
PAM subsystem. Therefore, the status rule should always be the last and only
status rule in your policy file.
<type>
The value in this field represents the type of access rule. It defines what kinds of user
information that PAM_AUTHZ needs to look for. The value also helps to determine
the correct syntax in the following <object> field.
Valid values for this field are:
unix_user, unix_local_user, unix_group, netgroup, ldap_group
Rules that have one of these specified as the <type> field define a static list access
rule. For this rule, the <object> field is specified as a predefined list of identifiers.
The identifiers are matched directly with data in the login request. This <type> field
specifies where PAM_AUTHZ will look to determine if the login field is present in
the appropriate data store, such as /etc/passwd or /etc/group. If the login
field is found, the rule is evaluated to be true. The final access right is determined
by the <action> field. For more information, see Section 7.4.8 (page 208).
passwd_compat
206 Administering LDAP-UX Client Services
Controls access permission using NIS-style escapes in /etc/passwd. This is identical
to the default behavior of PAM_AUTHZ when there is no access policy file present.
The passwd_compat type supports only status or required in the action field,
and anything specified in the <object> field is ignored.
NOTE: Use of netgroups, which are used by passwd_compat, is not supported
in ADS. References here are for information only.
other
PAM_AUTHZ ignores any access rules defined in the <object> field. The access
rule is evaluated to be true immediately. For example,
allow:other
In the preceding example, all users are granted the login access to the machine.
The primary usage of this type of rule is to toggle PAM_AUTHZ default <action>.
ldap_filter
In a role based access management, permission to access a resource can be
controlled based on the user's role such as sales force, technical support or subscriber
status and are typically defined by common business attributes of users based on
company policies. The same concept is applied to the ldap_filter access rule.
A search filter is defined in <object> field. A search filter consists of one or more
(attribute=value) pairs. If the user entry is successfully retrieved from a directory
server by using the search filter, the access rule is considered to be true. Examples
of ldap_filter type of access rule are as follows:
allow:ldap_filter:(&(manager=paulw)(business
category=marketing))
In the preceding example, if a user reports to paulw and the user's job is related
to marketing, then the user is granted the login access. The rule structure is very
flexible about how to define access for certain groups of users.
PAM_ACCT_EXPIRED:ldap_filter:(nsAccountLock=TRUE)
In the preceding example, if a user account has been locked out and this access
rule is evaluated to be true, the PAM_ACCT_EXPIRED code is returned by
PAM_AUTHZ.
In LDAP-UX Client Services B.04.10 or later, PAM_AUTHZ supports dynamic variable
in the ldap_filter type of the access rule. A search filter can consist of one or
more (attribute=$[function_name]) pairs and is defined in the <object>
field. The [function_name] is called and the return value is substituted into the
search filter. Then the search filter is processed the same as in the preceding example.
For detailed information about dynamic variable support, see Section 7.4.9
(page 209).
<library_name>
When status is specified as the <action> field, this defines a rule that is evaluated
to perform account and password policy enforcement. This access rule defines a
library, in the <library_name> field to be loaded (for HP-UX Directory Server or
Red Hat Directory Server, the <library_name> is rhds, for Windows ADS, the
<library_name> is ads), and a function in the <function_name> field that
specifies a function to be invoked to perform policy evaluation for a particular
directory server. For detailed information on the supported values and usage of this
access rule, see Section 7.4.10.1 (page 210).
<object>
The values in this field define the policy criteria that PAM_AUTHZ uses to validate
with the login name. The values in this field are dependent on the option that is
stated in the <type> field.
7.4 Configuring PAM_AUTHZ login authorization 207
7.4.8 Static list access rule
When the value in the <type> field is one of unix_user, unix_group, netgroup,
ldap_group, the rule is evaluated using a list of predefined values in the <object> field. Based
on the value in the <type> field, PAM_AUTHZ will call the appropriate service to determine if the
item requested is present. If the requested information is found then the rule is evaluated to be true.
The following describes the values for this field:
unix_user
This option indicates that an administrator wants to control the login access
by examining a user's login name with a list of predefined users. If the
login name matches one of the user names in the list, the authorization
statement is evaluated to be true. The final access right is determined by
evaluating the <action> field. An example of a unix_user type of
access rule is as follows:
allow:unix_user:myuser1,myuser2,myuser3
If a myuser3 user attempts to log in, the preceding access rule is
evaluated to be true and the user is granted login access.
unix_local_user
This option indicates that an administrator wants to control the login access
by examining a local user's login name with a list of user's accounts in
the /etc/passwd file. If the login name matches one of the user accounts
defined in /etc/passwd, the authorization statement is evaluated to be
true. Otherwise, the rule is skipped. An example of a unix_local_user
type of access rule is as follows:
allow:unix_local_user
As an example, if a user account, myuser5, is defined in /etc/
password, the preceding access rule is evaluated to be true and this
user myuser5 is granted permission to log in to the local host.
unix_group
This option specifies that an administrator wants to control the login access
right using the user's group membership. You can specify a list of group
names in the <object> field. PAM_AUTH retrieves the group information
of each listed group by querying the name services specified in
nsswitch.conf. That means the group entries might come from any
sources (files, nis, LDAP, and so forth). If the login user belongs to any
groups in the list, the access rule is evaluated to be true. Otherwise, the
rule is skipped. An example of a unix_group access rule is shown as
follows:
deny:unix_group:myunixgroup10,myunixgroup11,myunixgroup12
A user tries to log in and he is a member of myunixgroup12. The rule
is evaluated to be true and the <action> is applied. The user is restricted
from access to the machine even with a valid password.
netgroup
This option is not supported in Windows ADS environments. The option
specifies that the access permission is determined by the user's netgroup
membership. You must specify a list of netgroup name in the <object>
field. If the user is a member of one of the netgroups specified in the
netgroup list, then the access rule is evaluated to be true. PAM_AUTH
obtains the netgroup information by querying the name services specified
in nsswitch.conf. For example:
allow:netgroup:netgroup1,
netgroup2,netgroup3
A user tries to log in and he belongs to netgroup1. The preceding access
rule is evaluated to be true. The user is granted login access.
208 Administering LDAP-UX Client Services
NOTE: Beginning with version 5.0 of the product, LDAP-UX Client
Services supports integrated Compat Mode to control which users are
visible on a host, where the user accounts are referenced by netgroups
specified in the /etc/passwd file. For more information, see
Section 2.5.5 (page 102). This feature is not supported when using LDAP-UX
Client Services with Windows ADS.
ldap_group
This option specifies that an access rule is based on the nonPOSIXGroup
membership. PAM_AUTHZ supports LDAP group with groupOfNames
or groupOfUniqueNamesobjectclass. A list of ldap_group names is
specified in the <object> field. The group membership information is
stored in the LDAP directory server. An example of a ldap_group type
of access rule is as follows:
deny:ldap_group:engineering_ldapgroup,support_ldapgroup,epartner_ldapgroup
PAM_AUTHZ retrieves group membership of each listed group from the
directory server through LDAP-UX client services. Then, it examines if the
user's distinguished name (DN) matches any value in the member or
uniquemember attribute.
7.4.9 Dynamic variable access rule
PAM_AUTHZ supports dynamic variables in the ldap_filter type of the access rule. A dynamic
variable is defined in <object> (LDAP search filter) field, it can consist of one or more
(attribute=$[variable_name]) pairs. The syntax of an access rule with the dynamic variable is:
<action>:ldap_filter:(attribute=$[variable_name])
For example, if an administrator has an attribute named hostControl defined in the directory,
and wants to use this attribute to define which host a user can log on to. He may add the following
access rule in the access policy file:
allow:ldap_filter:(hostControl= hostA)
Where hostA is the value for the local host that the user must be granted access. If a user, John,
has a hostControl attribute in his user entry in the LDAP directory and the value is hostA, then
the access rule is evaluated to be true and this user is allowed to log in to the host, hostA.
In the preceding example, a dynamic variable HOSTNAME can be used. The previous access rule
can be redefined as follows:
allow: ldap_filter: (hostControl=$[HOSTNAME])
where $[HOSTNAME] represents a dynamic variable function which will be called to retrieve the
local host name information. PAM_AUTHZ will then substitute its return value to the search filter.
7.4.9.1 Supported functions for dynamic variables
In LDAP-UX Client Services, PAM_AUTHZ provides the following default dynamic variable functions
in the libpolicy_commonauthz library. These functions can be used as dynamic variables
specified in the ldap_filter type of access rules:
HOSTNAME
Returns the host name of the local system from which the user attempts to log
on. For example, hostA.
HOSTNAMEWD
Returns the fully qualified host name of the local system from which the user
attempts to log on. For example, hostA.hp.com.
HOSTIP
Returns the IP address of the local system from which the user attempts to log
on. For example, 12.10.2.105.
7.4 Configuring PAM_AUTHZ login authorization 209
TERMINAL
Returns the terminal type of the computer from which the user attempts to log
on. For example, /dev/pts/0.
Some applications (such as ssh or remsh) do not pass the terminal dynamic
variable value to PAM_AUTHZ.
TIMEOFTHEDAY
Returns the current time of the computer system from which the user attempts
to log on. For example, 20061015125535Z represents October 15, 2006
at 12:55 and 35 seconds GMT. TIMEOFTHEDAY follows the “UTC Time”
syntax as described by RFC4517.
SERVICE
Returns the name of the PAM service from which the user attempts to access.
For example, common PAM service names include ftp, login, telnet.
RHOSTIP
Returns the IP address of the remote host system from which the user starts the
PAM enabled application, such as telnet.
RHOSTNAME
Returns the name of the remote host system from which the user starts the PAM
enabled application, such as telnet.
RHOSTNAMEWD
Returns the name of the fully qualified remote host system from which the user
starts the PAM enabled application, such as telnet.
7.4.9.2 Example of a dynamic variable access rule
The following shows a sample access rule in the access policy file:
allow:ldap_filter:(WorkstationIP=$[HOSTIP])
This policy rule performs a security policy validation for users stored in the directory server. If user
Mary has a WorkstationIP attribute with the value of 1.2.3.200 in her user entry in the LDAP
directory, then when she attempts to log in to the host with the IP address 1.2.3.200, the access
rule is evaluated to be true and she is granted login access.
7.4.10 Security policy enforcement with secure shell (ssh) or r-commands
PAM_AUTHZ has a limited ability to perform account and password security policy enforcement
without requiring LDAP-based authentication. This section provides information on how to configure
the security policy enforcement access rule, set up access permissions for global policy attributes
and configure PAM configuration file to support enforcement of account and password policies,
stored in an LDAP directory server, for applications such as ssh key pair and r-commands with
rhost enabled.
This feature is designed to support applications such as secure shell (ssh) and the r-commands (such
as rlogin and rcp) with rhost enabled. With these applications, authentication is performed
by the command itself rather than by the PAM subsystem; when authentication is not performed
by PAM, the directory server is not given the opportunity to provide security policy enforcement
as normally occurs during the LDAP authentication process.
To configure and use this feature for ssh key pair or r-commands, perform the following tasks:
•
Set security policy enforcement access rule in the access policy file. For information about
setting this access rule, see Section 7.4.10.1 (page 210).
•
Set access permissions for global policy attributes. For information about setting access
permissions for global policy attributes, see Section 7.4.10.2 (page 212).
•
Configure the PAM_AUTHZ library and the rcommand option in the /etc/pam.conf file
for the sshd and rcomds services under the account management section. For more
information, see Section 7.4.10.3 (page 213) and Section D.5 (page 430).
7.4.10.1 Security policy enforcement access rule
Specifying status in the <action> field of a pam_authz.policy access rule triggers use of
the account and password security policy enforcement rule. When this rule is evaluated,
210
Administering LDAP-UX Client Services
PAM_AUTHZ will call the <function_name> in the library specified by the <library_name>
field. PAM_AUTHZ returns the value which is one of the PAM return codes described in
Section 7.4.10.5 (page 214).
This access rule consists of the following three fields:
<action>:<library_name>:<function_name>
The following describes each field:
action
When the status option is specified, PAM_AUTHZ returns whatever
<function_name> in the <library_name> returns, which is one of the
PAM return codes.
library_name
This field specifies the name of the library to be loaded that supports the
account and password policies for a particular directory server.
The following describes the valid values for this field:
function_name
•
rhds: If this option is specified, PAM_AUTHZ loads the /opt/ldapux/
lib/libpolicy_rhds library to process security policy configuration
and examine the user's security policy status attributes stored in the
HP-UX Directory Server or Red Hat Directory Server.
•
ads: If this option is specified, PAM_AUHZ loads the /opt/ldapux/
lib/libpolicy_ads library to process security policy configuration
and examine the user's security policy status attributes stored in the
Windows Server 2003 R2 or 2008 Active Directory Server.
This field defines the function name in the specified <library_name> that
PAM_AUTHZ uses to evaluate certain security policy settings with the login
user.
The following describes the valid entries for this field:
•
check_rhds_policy: If this option is specified, PAM_AUTHZ evaluates
all the necessary login user account and password policies settings
stored in the HP-UX Directory Server or Red Hat Directory Server.
•
check_ads_policy: If this option is specified, PAM_AUTHZ evaluates
all the necessary login user account and password policies settings
stored in the Windows Server 2003 R2 or 2008 Active Directory.
7.4 Configuring PAM_AUTHZ login authorization
211
NOTE: If the status:rhds:check_ads_policy access rule is configured in the access policy
file, you must perform the following tasks:
•
Define the allow:unix_local_user access rule in the access policy file to allow the local
user to log in.
•
Since the status:rhds:check_ads_policy access rule is guaranteed to match and return
a PAM return code, HP recommends that you define the status:rhds:check_ads_policy
access rule at the end of the access policy file. Otherwise, the access rules that are defined
after the status access rule are not evaluated.
•
PAM_AUTHZ might display account and password policy attributes in the syslog file when
the debug option is enabled. You can take proper action to protect the syslog file. For
example, set the syslog file permissions so that the file can be accessed or viewed by the
power user only.
WARNING! Enabling the debug option in pam.conf might enable hackers to gain additional
information that would enable them to crack password security. For example, they could
attempt to log in as a super user (su) and discover that a password has expired (observing
the super user's behavior, the hackers could determine when that user is likely to log in next).
7.4.10.1.1 Example of access rules
The following shows an example of the access rules defined in the access policy file when
configuring and using security policy enforcement for ssh key pair or r-commands:
allow:unix_local_user
status:rhds:check_ads_policy
7.4.10.2 Configuring access permissions for global policy attributes
For PAM_AUTHZ to support security policy enforcement with the directory server, PAM_AUTHZ
needs access to the security policy configuration attributes. In an HP directory server environment,
these global policy attributes are all defined under cn=config. In a Windows ADS environment,
they are defined in the Group Policy Object as part of the default domain policy in a Windows
ADS environment. Because cn=config and the Group Policy Object are part of the security
framework of the HP-UX Directory Server and Windows ADS products, respectively, access to them
is restricted to privileged users. If you plan to use the PAM_AUTHZ enhancement to provide account
and password policy enforcement, you must configure LDAP-UX with a proxy user. For HP-UX
Directory Server, grant this proxy user sufficient read and search privileges to retrieve the required
attributes in cn=config. These attributes are listed in Table 19 and Table 21. For Windows ADS,
grant this proxy user sufficient read and search privileges to retrieve the required attributes in the
base DN for the Windows domain. These attributes are listed in Table 20 (page 215) and Table 22
(page 216).
The following example ACI for an HP-UX Directory Server environment gives a proxy user permission
to read and search all global policy attributes in cn=config:
aci: (targetattr= "objectclass ||passwordLockout ||passwordUnlock
||passwordMaxFailure ||passwordExp ||passwordMustChange
||nsslapd-pwpolicy-local")
(version 3.0; acl "Proxy global security policy attributes read and
search rights";
allow (read,search)
(userdn = "ldap:///uid=proxyuser,ou=Special Users,o=hp.com");)
Just as this example for an HP-UX Directory Server allows the proxy user access to the global policy
attribute, Windows environments must grant access to similar attributes defined in Table 20
(page 215) and Table 22 (page 216). For more information about a list of security policy attributes
supported by LDAP-UX, see Section 7.4.10.6 (page 214).
212
Administering LDAP-UX Client Services
You can allow access to the Group Policy Object attributes in Windows ADS using the Active
Directory Users and Computers control panel. For more information, refer to your Microsoft Windows
documentation or the help topics provided by the Active Directory Users and Computers control
panel.
Advanced administrators with intimate knowledge of Windows ADS and security policy can also
view and modify the attributes by using ADSI Edit.
7.4.10.3 Configuring the PAM configuration file
If you want to use PAM_AUTHZ to support enforcement of account and password policies stored
in your directory server, you must define the PAM_AUTHZ library and the rcommand option in
the /etc/pam.conf file for the sshd and rcomds services in the account management section
of the file. In addition, the control flag for the PAM_AUTHZ library must be set to required. For
an example of a proper configuration, see Section D.5 (page 430). For more information about
pam.conf configuration, see the introduction to “Sample PAM configuration (pam.conf) files ”
(page 420).
7.4.10.4 Evaluating the directory server security policy
The following is an example of the access rule in the access policy file for an HP-UX Directory
Server:
status:rhds:check_rhds_policy
The following is an access rule for Windows ADS:
status:ads:check_ads_policy
If the former access rule is specified in the access policy file, the check_rhds_policy routine
in the libpolicy_rhds library is loaded and executed. If the latter access rule is specified, the
check_ads_policy routine in the libpolicy_ads library is loaded and executed. PAM_AUTHZ
constructs a request message that will be used to find the current security policy configuration and
to examine the specific user’s security policy status attributes to determine if the user complies with
the security policy. For an HP directory server, PAM_AUTHZ searches for the following information:
•
In the HP directory server Global policy attributes under cn=config: passwordLockout,
passwordUnlock, passwordMaxFailure, passwordExp, passwordMustChange,
nsslapdpwpolicy-local.
•
User specific policy attributes: accountUnlockTime, passwordExpirationTime,
pwdPolicySubEntry, passwordRetryCount, nsAccountLock.
•
If fine-grained policy is turned on and the sub-tree policy for this user has been configured,
then LDAP-UX searches for password policy attributes at the subtree and user level:
passwordLockout, passwordUnlock, passwordMaxFailure, passwordExp,
passwordMustChange.
For Windows ADS, PAM_AUTHZ searches for and needs access to (through the proxy user):
•
Global policy object attributes for the domain: lockoutDuration, maxPwdAge.
•
User specific policy attributes: userAccountControl, userWorkstations, pwdLastSet,
accountExpires, LockoutTime and logonHours.
For an HP directory server, PAM_AUTHZ performs the following by evaluating the necessary security
policy settings and returns the corresponding PAM return code to the applications or commands
that called the PAM API:
•
Determines whether an account is activated
•
Determines whether an account is locked
•
Determines whether the password has expired
7.4 Configuring PAM_AUTHZ login authorization
213
For Windows ADS, PAM_AUTHZ performs the following:
•
Determines whether an account is activated
•
Determines the hours (time of day) during which the user is allowed to log on to the domain
•
Determines whether an account password must be changed
•
Determines whether an account is locked
•
Determines whether the password has expired
7.4.10.5 PAM return codes
If the status:rhds:check_rhds_policy access rule is specified in the access policy file for
HP-UX Directory Server or Red Hat Directory Server, or the status:rhds:check_ads_policy
access rule is specified in the access policy file for Windows ADS,PAM_AUTHZ evaluates the
necessary security policy settings and returns the possible PAM return codes as follows:
PAM_USER_UNKNOWN
Returned if the user is not found in the directory server, or if any
internal errors (such as an error returned by the server) upon
attempting to find the user's policy attributes
PAM_ACCT_EXPIRED
Returned if the user account is inactive or has been locked out
PAM_NEW_AUTHTOK_REQD
Returned if the user's password has expired
PAM_SUCCESS
Returned if the user account is active and not locked, and the
user's password has not expired
7.4.10.6 Directory server security policies
Global security attributes
In a directory server, numerous attributes can be used to define security policies.
For an HP directory server, to support account and password security policy enforcement,
PAM_AUTHZ is enhanced to support the global administrative security attributes listed in Table 19.
These attributes are used to define the policy rules and are all defined under cn=config. Only
authorized users can access them. If you use the PAM_AUTHZ enhancement to support the account
and password policy enforcement, you must configure LDAP-UX with a proxy user and grant this
proxy user read and search rights to search cn=config.
Table 19 Global security attributes supported for an HP directory server
214
Attribute
Description
passwordLockout
This boolean attribute indicates whether users will be locked out of the directory
after a given number of failed bind attempts. By default, users are not locked out
of the directory after a series of failed bind attempts.
passwordUnlock
This boolean attribute indicates whether users will be locked out of the directory
for a specified amount of time or until the password is reset after an account
lockout. If the passwordUnlock attribute is disabled and the
accountUnlockTime attribute has a value of 0, then the account will be locked
indefinitely.
passwordMaxFailure
This integer attribute indicates the maximum number of password failures after
which a user will be locked out of the directory. By default, account lockout is
disabled.
passwordExp
This boolean attribute indicates whether user passwords will expire after a given
number of seconds. By default, user passwords do not expire. If this attribute is
enabled, you can use the passwordMaxAge variable to set the number of seconds
after which the password will expire.
Administering LDAP-UX Client Services
Table 19 Global security attributes supported for an HP directory server (continued)
Attribute
Description
passwordMustChange
This boolean attribute indicates whether users must change their passwords when
they first bind to the directory server or when the password has been reset by the
Directory Manager.
nsslapd-pwpolicy-local
Turns fine-grained (subtree and user level) password policy on or off. With
fine-grained password policy turned on, all entries (except for cn=Directory
Manager) in the directory are subjected to the global password policy, the server
ignores any defined subtree and user level password policy. With fine-grained
password policy turned off, the server detects password policies at the subtree
and user level and enforces those policies.
In the Windows Active Directory Server, PAM_AUTHZ is enhanced to support the global
administrative security attributes listed in Table 20. These attributes are used to define the policy
rules and are all defined under the default domain Group Policy Object. Only authorized users
can access them. If you use the PAM_AUTHZ enhancement to support the account and password
policy enforcement, you must configure LDAP-UX with a proxy user and grant this proxy user read
and search rights to retrieve the required attributes in the base DN for the Windows domain.
Because the Group Policy Object is part of the security framework of Windows ADS, access is
restricted to privileged users. If you plan to use the PAM_AUTHZ enhancement to provide account
and password policy enforcement, you must configure LDAP-UX with a proxy user. Grant this proxy
user sufficient read and search privileges to retrieve the required attributes in the base DN for the
Windows domain.
For Windows ADS, administrators can configure account and password policies using the Microsoft
Management Console snap-in Active Directory Users and Computers.
Advanced administrators with intimate knowledge of Windows ADS and security policy can also
view and modify the attributes by using ADSI Edit.
Table 20 Global security attributes supported for a Windows Active Directory Server
Attribute
Description
lockoutDuration
This integer attribute defines the amount of time that an account is locked when
the Lockout-Threshold is exceeded. This value is stored as a large integer 1 that
represents the negative of the number of 100-nanosecond intervals that must
elapse from the time the Lockout-Threshold is exceeded before the account is
unlocked.
maxPwdAge
This integer attribute specifies the maximum amount of time a password is valid.
This value is stored as a large integer1 that represents the number of
100-nanosecond intervals from the time the password was set before the password
expires.
1
Large enough to contain the number of 100–nano-second periods between now and the year 9999.
Security policy status attributes
PAM_AUTHZ supports a list of attributes that store general security policy status information for a
particular user in the directory server. The attributes supported for HP directory servers are listed
in Table 21. If you plan to use the PAM_AUTHZ enhancement to provide account and password
policy enforcement, you must configure LDAP-UX with a proxy user. For HP-UX Directory Server,
grant this proxy user sufficient read and search privileges to retrieve the required attributes in
cn=config.
7.4 Configuring PAM_AUTHZ login authorization
215
Table 21 Security policy status attributes supported for an HP directory server
Attribute
Description
nsAccountLock
This boolean attribute indicates whether an account is
locked. If this attribute does not exist, the account is
considered unlocked.
passwordRetryCount
This integer attribute specifies the number of consecutive
failed attempts at entering the correct user password.
passwordExpirationTime
This string attribute defines a date and time when a
password is considered expired. The date and time are
specified using the “Generalize Time” syntax as referenced
in RFC 2252 and specified by the ISO x.208 standard. It
uses the format YYYYMMDDHHMMSSTZ, where:
YYYY signifies the 4-digit year
MM signifies the 2-digit month
DD signifies the 2-digit day of the month
, HH signifies the 2-digit hour
MM signifies the 2-digit minute
SS signifies the 2-digit second
TZ signifies the time zone
HP directory servers use the GMT time zone, which is
represented with the letter Z for Zone time. For example,
20060215165535Z represents February 15, 2006 at
16:55 and 35 seconds GMT.
accountUnlockTime
This string attribute defines a date and time when an
account will be unlocked. The value is represented in the
Generalized Time syntax described in the
passwordExpirationTime attribute. If the attribute
does not exist, the account is considered unlocked (this
assumes nsAccountLock does not also exist).
pwdpolicysubentry
This variable defines the location of the new password
policy. The location is expressed in the DN format.
For the Windows Active Directory Server, PAM_AUTHZ supports the list of attributes listed in
Table 22. If you plan to use the PAM_AUTHZ enhancement to provide account and password
policy enforcement, you must configure LDAP-UX with a proxy user. Grant this proxy user sufficient
read and search privileges to retrieve the required attributes in the base DN for the Windows
domain.
For Windows ADS, administrators can configure account and password policies using the Microsoft
Management Console snap-in Active Directory Users and Computers.
Advanced administrators with intimate knowledge of Windows ADS and security policy can also
view and modify the attributes by using ADSI Edit.
Table 22 Security policy status attributes supported for a Windows Active Directory Server
216
Attribute
Description
userAccountControl
This attribute controls the behavior of the user account.
userWorkStations
This single-valued string attribute contains the NetBIOS
names of the workstations from which the user can log on.
Each NetBIOS name is separated by a comma.
pwdLastSet
This integer attribute defines the date and time that the
password for this account was last changed. This value is
stored as a large integer that represents the number of
100-nanosecond intervals since January 1, 1601 (UTC).
If this value is set to 0 and the userAccountControl
attribute does not contain the UF_DONT_EXPIRE_PASSWD
flag, then the user must set the password at the next logon.
Administering LDAP-UX Client Services
Table 22 Security policy status attributes supported for a Windows Active Directory Server (continued)
accountExpires
This integer attribute specifies the time when the account
expires. This value represents the number of
100-nanosecond intervals since January 1, 1601 (UTC).
A value of 0 or 0x7FFFFFFFFFFFFFFF
(9223372036854775807) indicates that the account never
expires.
lockoutTime
This integer attribute specifies the date and time (UTC) that
this account was locked out. This value is stored as a large
integer that represents the number of 100-nanosecond
intervals since January 1, 1601 (UTC). A value of zero
means that the account is not currently locked out.
logonHours
This integer attribute defines the number of hours that the
user is allowed to log on to the domain.
7.5 Adding an HP directory server directory replica
Your HP LDAP directory contains configuration profiles downloaded by each client system and
name service data accessed by each client system. As your environment grows, you might need
to add a directory replica to your environment. LDAP-UX can take advantage of replica directory
servers and the alternates if one of them fails. Follow these steps to inform LDAP-UX about multiple
directory servers:
1. Create and configure your LDAP directory replica. For the HP-UX Directory Server, see the
HP-UX Directory Server deployment guide.
2. Edit an existing profile and modify the defaultServerList or preferredServerList attribute to
specify a replica directory server. See Section 7.10.2 (page 245).
See “LDAP-UX Client Services object classes” (page 406) for a description of the
defaultServerList and preferredServer attributes.
3.
4.
On all clients that are to use the replica server, edit the startup file /etc/opt/ldapux/
ldapux_client.conf to refer to the replica host. Modify the LDAP_HOSTPORT line to
specify the replica server.
After modifying an existing profile, each client that regularly downloads its profile automatically
will get the changes as scheduled. SeeSection 2.5.8 (page 111).
NOTE: Client systems using an HP LDAP directory replica might not be able to modify the directory
replica. In this case, the passwd command will not work on those systems. They can use the
ldappasswd command described in Section 9.4.2 (page 356).
7.6 Adding additional Windows domain controllers
Your Active Directory contains configuration profiles downloaded by each client system and name
service data accessed by each client system. As your environment grows, you might need to add
additional domain controllers to your environment. Follow these steps:
1.
To install and configure a new Active Directory domain controller, use the dcpromo.exe
tool. For more information, see the respective literature on Active Directory or refer to the
Microsoft library at:
http://msdn.microsoft.com/library/default.asp
2.
Create a new profile that specifies the new domain controller. The new profile can be identical
to another profile, except the preferredServerList attribute specifies a new domain
controller. For more information, see Section 7.10.3 (page 246).
For a description of the preferredServerList attribute, see “LDAP-UX Client Services
object classes” (page 406).
7.5 Adding an HP directory server directory replica
217
3.
4.
On all clients that are to use the new controller, edit the startup file /etc/opt/ldapux/
ldapux_client.conf to refer to the new domain controller and the new profile. Modify
the PROFILE_ENTRY_DN line as described under Section 7.10.4 (page 246). Modify the
LDAP_HOSTPORT line to specify the domain controller server.
Download the new profile from the new domain controller, as described in Section 3.5.6
(page 158).
7.7 Managing users and groups
LDAP-UX Integration supports a new set of noninteractive LDAP command-line tools that enable you
to list, add, modify or delete user accounts and groups in an LDAP directory server. These new
tools provide capabilities to perform those operations without needing to discover the LDAP server
information. Each tool uses the LDAP-UX profile configuration to discover server information, such
as the host name and port number of the LDAP directory server and proper search filters for finding
users and groups. Each tool provides command options that enable you to alter these configuration
parameters. Using these new tools does not require you to have extensive knowledge of the LDAP
schema, protocol and LDAP-UX configuration of each directory server product. These tools performs
installation specific data model interpretation, such as converting UID-name based group membership
(POSIX-style) to X.500 DN based membership (LDAP-style).
The LDAP User and Group (UG) management tools support the following features:
•
Create, modify, delete, or list users and groups in an LDAP directory server.
•
Modify user or group password.
•
Support attribute mapping for definition of POSIX attributes used when creating or modifying
entries.
•
Support specification of group membership using X.500-style DN based member attributes.
•
Provide customized and default templates for defining new user and group entries, which
enables arbitrary data models to be used.
•
Support SSL or TLS encryption of data connections to the LDAP directory server if requested.
•
Provide the ability to connect to an alternate directory server other than that specified by the
LDAP-UX configuration profile.
•
Discover programmatically if LDAP-UX is installed, configured and operating properly for a
specified service.
The HP System Management Homepage (SMH) Users and Groups interface uses these LDAP UG
command line tools to implement the web-based user interface functionality that manages POSIX
users and groups in an LDAP directory server. This enables HP-UX system administrators to manage
users and groups in an LDAP directory server using SMH UG-LDAP web-based interface on an
HP-UX 11i v3 system. The HP System Management Homepage (SMH) product supports the LDAP
user and group web-based management feature via HP-UX 11i v3 September, 2007 release.
You can use the LDAP command-line tools described in Section 7.7.1 (page 218) to manage users
and groups for either HP directory servers or Windows ADS. Specific Windows utilities for managing
Windows ADS users and groups are discussed in Section 7.7.2 (page 234).
7.7.1 LDAP command-line tools for managing HP directory server and Windows
ADS users and groups
The LDAP-UX Integration product supports the following LDAP command-line tools for management
of user and group information in an LDAP directory server. These LDAP user and group tools exist
in the /opt/ldapux/bin directory. For detailed information about tool usage, syntax, options,
arguments, environment variables and return codes supported by these tools, see Section 9.3
(page 283), or see the ldapuglist(1M), ldapugadd(1M), ldapcfinfo(1M), ldapugmod(1M), and
ldapugdel(1M) manpages.
218
Administering LDAP-UX Client Services
Use of the ldapugadd, ldapugmod and ldapugdel tools requires specification of LDAP
administrator credentials with sufficient privilege to perform the requested operations in an LDAP
directory server. Specification of these credentials can be done through the LDAP_BINDDN and
LDAP_BINDCRED environment variables or an interactive prompt (-P) option. If the LDAP
administrator credential has not been specified using the two previous methods, and if configured,
the LDAP-UX administrator credential is used if the user running the tool has sufficient privilege to
read the /etc/opt/ldapux/acred file.
•
ldapuglist
You can use the ldapuglist tool to display and enumerate POSIX-like account and group
entries that reside in an LDAP directory server. The ldapuglist provides features that enable
users and applications to discover and evaluate account and group information stored in an
LDAP directory server, without requiring extensive knowledge of in-use data models or the
methods used to retrieve and evaluate that information in the LDAP directory server.
The ldapuglist tool uses the LDAP-UX profile configuration, requiring minimal command
line options to discover where to search for user or group information, such as the directory
server host and proper search filters for finding users and groups. The ldapuglist tool also
uses attribute mapping defined in the profile to translate information to POSIX syntax. By
default, ldapuglist only displays POSIX-related attributes using RFC 2307 attribute names
unless you specifically request an attribute list with the <attr> option on the command line.
This tool provides command options that enable you to alter these configuration parameters.
•
ldapugadd
You can use the ldapugadd tool to add new POSIX accounts and groups to an LDAP directory
server. Because the deployed data model might require user or group attributes beyond that
of the standard POISIX attributes, the ldapugadd tool uses user and group template files to
discover the required data model for the types of entries being created. These templates may
define arbitrary data models beyond just the required POSIX attributes. Applications can use
ldpacfinfo to discover the attributes required by the templates that are not part of the
standard POSIX data model. To use ldapugadd, you must provide LDAP administrator
credentials who have sufficient privilege to perform the user or group add operation in the
directory server.
•
ldapugmod
The ldapugmod tool enables HP-UX administrators to modify existing POSIX accounts or
groups in an LDAP directory server. When using extended options, you can use ldapugmod
to modify arbitrary attributes for user or group entries or you can extend existing user or group
entries with the POSIX data model. To use ldapugmod, you must provide LDAP administrator
credentials that have sufficient privilege to perform the user or group modify operations in the
directory server.
•
ldapugdel
Use the ldapugdel tool to remove POSIX related user or group entries from an LDAP directory
server. The ldapugdel tool can also remove the POSIX related attributes and object classes
from user or group entries, without removing the entire entry itself.
•
ldapcfinfo
The ldapcfinfo tool provides several capabilities used to report LDAP-UX configuration and
status. When used specifically with the LDAP UG tools, ldapcfinfo can be used to discover
LDAP-UX configuration details about required attributes when adding new users or groups to
a directory server.
7.7 Managing users and groups
219
The ldapcfinfo tool can provide the following information by examining LDAP UG template
files, LDAP UG configuration file or the LDAP-UX configuration profile:
◦
Determine if the LDAP-UX is properly configured and active
◦
Discover the current LDAP User and Group (UG) configuration defaults, such as home
directory and login shell
◦
Discover the distinguished name (DN) of the LDAP-UX configuration profile and the
directory server name that stores that profile
◦
Discover search filter, search base or search scope for a particular name service
◦
Discover the attribute mapping information for a specified name service
◦
Discover the list of available template files for a specific name service when you want to
add a new user or group entry to an LDAP directory server
◦
Discover LDAP-UX configuration information about required attributes when creating a
new user or group entry
◦
Discover the recommended list of attributes that an interactive management tool can
consider making available for modification for the specified entry
The following subsections provide examples on how to use these tools. Most examples pertain to
HP directory servers. A few examples are given for Windows ADS.
7.7.1.1 Listing users (ldapuglist)
You can use ldapuglist to list and enumerate POSIX-like account entries in an LDAP directory
server. To follow are examples of how to use ldapuglist to list user entries.
While use of LDAP_BINDDN is not typically required to use ldapuglist, the LDAP_BINDDN
and LDAP_BINDCRED environment variables can be used to specify the distinguished name (DN)
and password of a user with sufficient directory server privilege to display protected attributes.
Alternately, you can input LDAP administrator bind identity and credential interactively with a
prompt (-P) option.
Setting the LDAP_BINDDN and LDAP_BINDCRED environment variables is optional when using
ldapuglist.
Displaying a specified user entry
To display an account entry for user mlee, enter the following command:
cd /opt/ldapux/bin
./ldapuglist -t passwd -n mlee
Sample command output for an HP directory server follows. If ldapuglist is used to access a
Windows Active Directory Server with the RFC 2307 schema installed, the output for this and other
examples in this section would be similar, except ou=people would be displayed instead of
cn=users.
dn: cn=Mike Lee,ou=people,dc=example,dc=com
cn: Mike Lee
uid: mlee
uidNumber: 900
gidNumber: 2010
loginShell: /usr/bin/sh
homeDirectory: /home/mlee
gecos: mlee,Building-5,555-555-5555
Displaying all available account entries
To display account entries available in the directory server, enter the following command:
./ldapuglist -t passwd
Sample command output for an HP directory server follows:
220 Administering LDAP-UX Client Services
dn: cn=Mike Lee,ou=people,dc=example,dc=com
cn: Mike Lee
uid: mlee
uidNumber: 900
gidNumber: 2000
loginShell: /usr/bin/sh
homeDirectory: /home/mlee
gecos: mlee,Building-5,555-555-5555
dn: cn=Michael Sheu,ou=people,dc=example,dc=com
cn: Michale Sheu
uid: msheu
uidNumber: 880
gidNumber: 2010
loginShell: /usr/bin/sh
homeDirectory: /home/msheu
gecos: msheu,Building-8,555-555-5000
dn: cn=Pat Fong,ou=people,dc=example,dc=com
cn: Pat Fong
uid: pfong
uidNumber:750
gidNumber: 2000
loginShell: /usr/bin/sh
homeDirectory: /home/pfong
gecos: pfong,Building-10,555-552-5000
...
...
Displaying a user entry that contains a specified UID
To display an account entry that contains uid=tscott, enter the following command:
./ldapuglist -t passwd -m -f "(uid=tscott)"
Sample output for an HP directory server follows. In this example, the uidNUmber attribute has
been mapped to employeeNumber, and the gecos attribute has been mapped to cn, l, and
telephoneNumber. With the -m option, the ldapuglist tool displays the mapped attribute
names as well.
dn: cn=Tom Scott,ou=people,dc=example,dc=com
cn[cn]: Tom Scott
uid[uid]: tscott
uidNumber[employeeNumber]: 900
gidNumber[gidNumber]: 2010
loginShell[loginShell]: /usr/bin/sh
homeDirectory[homeDirectory]: /home/tscott
gecos[cn]: Tom Scott
gecos[l]: Building-12
gecos[telephoneNumber]: 555-555-6666
7.7.1.2 Listing groups (ldapuglist)
You can use ldapuglist to list and enumerate POSIX-like group entries in an LDAP directory
server.
Displaying a specified group entry
To list a regular posixGroup entry for group name groupB, enter the following command:
./ldapuglist -t group -n groupB
The output for an HP directory server follows:
dn: cn=groupB,ou=groups,dc=example,dc=com
cn: groupB
gidNumber: 620
7.7 Managing users and groups 221
memberUid: user1
memberUid: user3
memberUid: user5
Displaying group entries that include a specified member
To list all the posixGroup entries that Mike Phillips belongs to, enter the following command:
cd /opt/ldapux/bin
./ldapuglist -t group -f "(memberUid=mphillips)"
Sample output for an HP directory server follows:
dn: cn=group1,ou=groups,dc=example,dc=com
cn: group1
gidNumber: 550
memberUid: mphillips
memberUid: mlou
memberUid: apierce
memberUid: bjones
dn: cn=group2,ou=groups,dc=example,dc=com
cn: group2
gidNumber: 580
memberUid: vtam
memberUid: ajones
memberUid: mphillips
Displaying group entries that include a specified attribute or qualification
To list a regular posixGroup entry that contains cn=groupA, enter the following command:
./ldapuglist -t group -f "(cn=groupA)"
Sample output for an HP directory server follows:
dn: cn=groupA,ou=groups,dc=example,dc=com
cn: groupA
gidNumber: 620
memberUid: user1
memberUid: user3
memberUid: user5
Command arguments
The following describes the ldapuglist options and arguments used in the preceding examples:
-t <type>
Specifies the type of entry the ldapuglist tool needs to discover and process.
<type> can be passwd or group. The passwd type indicates
posixAccount-type entries. The group type indicates posixGroup-type entries.
-n <name>
Specifies a single account or group name. Use of -n is the same as -f
“(uid=<name>)” for accounts and -f “(cn=<name>)” for groups.
-f <filter>
Specifies an LDAP-style search filter, <filter>, used to select specific entries
from the LDAP directory server. When you use the -f option, the filter specified
by <filter> applies to Posix-style users or groups (depending on whether
you specify the -t passwod or -t group option).
-m
Displays the names of the mapped attributes when returning results.
7.7.1.3 Adding a user or a group (ldapugadd)
When adding user or group entries to the LDAP directory server, the ldapugadd tool uses template
files to discover the required data models for a new user and group entry. Template files define
what object classes and attributes are required to create new user and group entries. LDAP-UX
provides the flexibility that enables you to define unique data models for user and group entries.
LDAP-UX supports two default template files (for passwd and group services) for a standard HP
222 Administering LDAP-UX Client Services
directory server, along with two default template files for Windows Active Directory Server. These
template files can be found in the /etc/opt/ldapux/ug_templates directory. For detailed
information on how to define template files and how to name and create template files, see
Section 9.3.5.6 (page 306).
NOTE: The LDAP-UX Client Services provides two default template files to work with Windows
2003 R2 or 2008 Active Directory Server. If you use ldapugadd to access a Windows ADS, you
must manually use the following commands to relink the default LDAP-UX templates to the default
templates for Windows ADS:
•
ln -fs /etc/opt/ldapux/ug_templates/ug_passwd_ads.tmpl \
/etc/opt/ldapux/ug_templates/ug_passwd_default.tmpl
•
ln -fs /etc/opt/ldapux/ug_templates/ug_group_ads.tmpl \
/etc/opt/ldapux/ug_templates/ug_group_default.tmpl
When creating user or group entries for a directory server, the ldapugadd tool uses the local
configuration file /etc/opt/ldapux/ldapug.conf to manage the default values of the
uidNumber_range, gidNumber_range, user_gidNumber, default_homeDirectory,
and default_loginShell parameters. For more information about the configuration file, see
Section 9.3.5.5 (page 305).
7.7.1.3.1 Adding users to an HP directory server or Windows ADS
You can use ldapugadd to add new POSIX accounts or groups to an HP or Windows directory
server.
Use LDAP_BINDDN to specify the distinguished name (DN) of a user with sufficient directory server
privilege to add users or groups in the directory server. Use LDAP_BINDCRED to specify a password
for the LDAP user specified by LDAP_BINDDN. Alternately, you can interactively specify LDAP
administrator bind identity and credential by using the prompt (-P) option with the command.
The LDAP_UGCRED environment variable specifies the new password of a user or group being
created. You must specify the -PW option when using LDAP_UGCRED. The use of passwords for
new groups is not recommended. Alternately, you may use the -PP option to prompt for the
password of the user or group being created.
Setting environment variables
The following commands set the LDAP_BINDDN and LDAP_BINDCRED environment variables:
export LDAP_BINDDN = "cn=Jane Admin,ou=admins,dc=example,dc=com"
export LDAP_BINDCRED = "Jane's password"
The following command sets the LDAP_UGCRED environment variable:
export LDAP_UGCRED = "user_password"
Displaying attributes in the default template file that are required for a new user entry
To discover which nonPOSIX attributes defined in the default template file are required to create
the new user entry, enter the following command:
cd /opt/ldapux/bin
./ldapcfinfo -t passwd -R
In the following example from an HP directory server environment, the output of the command
reveals that the Surname attribute is required to create the new user entry:
Surname
Adding a user entry
To create the new account entry for user mtam, enter the following command (Windows ADS does
not support the surname attribute).
7.7 Managing users and groups 223
./ldapugadd -t passwd -PW -f "Mike Tam" -g 200 mtam surname="Tam"
The command adds an account entry for user mtam, with the user's primary login group id being
200. The ldapugadd tool creates the password for the new user, using the user password specified
in the LDAP_UGCRED environment variable. After creating the user entry, ldapugadd attempts to
add this user as a member of group number 200.
To display the new user entry mtam, enter the following command:
./ldapuglist -t passwd -n mtam
Sample output for this command follows:
dn: cn=Mike Tam,ou=people,dc=example,dc=com
cn: Mike Tam
uid: mtam
uidNumber: 2200
gidNumber: 200
homeDirectory: /home/mtam
loginShell: /usr/bin/ksh
Adding a user entry with specific attribute values
For an HP directory server, to add an account entry for user jsmart, with the user's primary login
group id 200 and the surname attribute value of Smart (Windows ADS does not support this
attribute). Again, the ldapugadd tool creates the password for new user jsmart, using the user
password specified in the LDAP_UGCRED environment variable. After creating the user entry,
ldapugadd attempts to add this user as a member of group number 200. The ldapugadd tool
dynamically assigns the uidNumber value from the preconfigured range.
./ldapugadd -t passwd -PW -f "John Smart" -g 200 jsmart surname="Smart"
The following command displays the new user entry jsmart:
./ldapuglist -t passwd -n jsmart sn
Sample output follows:
dn: cn=John Smart,ou=people,dc=example,dc=com
cn: John Smart
uid: jsmart
uidNumber: 2350
gidNumber: 200
homeDirectory: /home/jsmart
loginShell: /usr/bin/ksh
sn: Smart
The following command issued in an HP directory server environment adds an account entry for
user tsheu, with the user's primary login group number as 350. With the -I option, this command
specifies the gecos field information. The gecos attribute has been mapped to cn, l, and
telephone in the LDAP-UX configuration profile. ldapugadd creates the password for new user,
tsheu, using the password specified in the LDAP_UGCRED environment variable. After creating
the user entry, ldapugadd attempts to add this user as a member of the group number 350.
(Windows ADS does not support the surname attribute.)
./ldapugadd -t passwd -PW -g 350 -I "Tom Sheu,Building-1A,555-555-5555" tsheu surname="Sheu"
Use the following command to display the new user entry tsheu, including mapped attribute
information:
./ldapuglist -t passwd -m -n tsheu
Example output follows (HP directory server environment):
dn: cn=Tom Sheu,ou=people,dc=example,dc=com
cn[cn]: Tom Sheu
uid[uid]: tsheu
uidNumber[uidnumber]: 2200
gidNumber[gidnumber]: 350
homeDirectory[homeDirectory]: /home/tsheu
loginShell[loginshell]: /usr/bin/sh
224 Administering LDAP-UX Client Services
gecos[cn]: Tom Sheu
gecos[l]: Building-1A
gecos[telephone]: 555-555-5555
Command arguments
The following are the options and arguments used in the preceding examples of the ldapugadd
command:
-t <type>
Specifies the type of entry the ldapugadd tool operates. <type>
can be passwd or group. The passwd type represents LDAP user
entries that contain POSIX account-related information. The group
type represents LDAP group entries that contain POSIX group-related
information.
-f <full_name>
This optional argument only applies to the passwd service. This
option specifies the user's full name.
-g <gid/gid_nubmer>
Specifies the user's primary login group name or ID number. After
creating the user entry, ldapugadd attempts to add the user as a
member of the specified group.
-I <gecos>
Specifies the GECOS fields for the user. Typically the GECOS
argument contains four fields representing (in order):
•
The user's full name
•
The user's work location
•
The user's work telephone number
•
The user's home telephone number (often omitted)
Each field in the <gecos> argument must be separated by a
comma.
-PW
Sets the user or group password attribute. If you specify -PW, you
must specify either the LDAP-UGCRED environment variable or the
-PP option.
<uid_name>
Required argument. Specifies the POSIX style login name for the
new user entry. This argument must follow all command-line options
and must precede the <attr>=<value> parameters (if provided).
<attr>=<value>
This option specifies arbitrary LDAP attributes and values.
<attr>=<value> parameters are optional and must be specified
as the last parameters on the command line.
7.7.1.3.2 Adding a group
Adding a group entry
The following ldapugaddcommand example shows how to add a new group entry groupA. The
command defines initial group membership by adding the user account tsheu as a member.
./ldapugadd -t group -M tsheu groupA
Use the following command to display the new group entry groupA:
./ldapuglist -t group -f "(cn=groupA)"
Example output follows:
dn: cn=groupA,ou=Group,dc=example,dc=com
cn: groupA
gidNumber: 550
memberUid: tsheu
7.7 Managing users and groups 225
Command arguments
The following describes the command arguments and options used in the preceding command
example:
-M <member>
Defines initial group membership by adding the specified user accounts
as members.
-g <gid_nubmer>
Specifies the group ID number for the new group.
<group_name>
Required argument. Specifies the POSIX style group name for the new
group entry.
7.7.1.3.3 Modifying defaults in /etc/opt/ldapux/ldapug.conf
You can use the ldapugadd -D command to change default values of the uidNumber_range,
gidNumber_range, user_gidNumber, default_homeDirectory, and
default_loginShell parameters in the /etc/opt/ldapux/ldapug.conf file.
Modifying the minimum and maximum UID range
The following command sets new default minimum (1000) and maximum (5000) ranges for UID
numbers. The ldapugadd tool randomly selects a new ID from this range if you do not specify an
account number.
cd /opt/ldapux/bin
./ldapugadd -D -t passwd -u 1000:5000
Modifying the minimum and maximum GID range
The following command sets new default minimum (200) and maximum (2500) ranges for GID
numbers. The ldapugadd tool randomly selects a new ID from this range if you do not specify a
group number.
./ldapugadd -D -t group -g 200:2500
Modifying the default group ID
The following command sets the default group ID to 5000. The ldapugadd tool uses this new
value when creating new user entries in an LDAP directory server.
./ldapugadd -D -t passwd -g 5000
Modifying the default login shell
The following command sets the default login shell to /net/bin/sh. The ldapugadd tool uses
this new login shell when creating new user entries in a directory server.
./ldapugadd -D -t passwd -s /net/bin/sh
Modifying the default parent home directory
The following command sets the default parent home directory to /net/home. The ldapugadd
tool uses this new home directory when creating new user entries in the directory server.
./ldapugadd -D -t passwd -d /net/home
Command arguments
The following describes arguments used in the preceding examples:
-D
Uses this option to change local host defaults in the /etc/
opt/ldapux/ldapug.conf file that are used by ldapugadd
when creating new user or group entries in an LDAP directory
server.
-u <min_uid>:<max_uid>
Sets new default minimum and maximum ranges that
ldapugadd uses when provisioning a UID number for new
user entries.
226 Administering LDAP-UX Client Services
-g <default_gid>
Specifies the default group ID number used when creating new
user entries.
-g <min_gid>:<max_gid>
Sets new default minimum and maximum ranges that
ldapugadd uses when provisioning a GID number for new
group entries.
-s <default_shell>
Specifies the default login shell that ldapugadd uses when
creating a new user entry.
-s <default_home>
Specifies the default parent home directory that ldapugadd
uses when creating a new user home directory.
7.7.1.4 Modifying a user (ldapugmod)
You can use ldapugmod tool to modify exiting POSIX accounts or groups in an LDAP directory
server. This section provides examples of using ldapugmod to modify a user's information.
Use LDAP_BINDDN to specify the distinguished name (DN) of a user with sufficient directory server
privilege to modify users or groups in the directory server. Use LDAP_BINDCRED to specify a
password for the LDAP user specified by LDAP_BINDDN. Alternately, you can interactively specify
LDAP administrator bind identity and credential by using the prompt (-P) option with the command.
The LDAP_UGCRED environment variable specifies the new password of a user or group being
modified. You must specify the -PW option when using LDAP_UGCRED. Alternately, you may use
the -PP command option to prompt for the password of the user or group being modified.
Setting environment variables
The following commands set the LDAP_BINDDN and LDAP_BINDCRED environment variables:
export LDAP_BINDDN = "cn=Jane Admin,ou=Admins,dc=example,dc=com"
export LDAP_BINDCRED = "Jane's password"
The following command example changes the password of user mtam, using the new user password
defined in LDAP_UGCRED:
cd /opt/ldapux/bin
export LDAP_UGCRED = "new password"
./ldapugmod -t passwd -PW mtam
Modifying user attributes
The following command specifies sets the uidNumber attribute value for user entry mswartz to
300:
./ldapugmod -t passwd -u 300 mswartz
The following command sets the sn attribute value for user entry mLou to Lou:
./ldapugmod -t passwd mLou "sn=Lou"
The following command specifies a new loginShell attribute value for user mLou:
./ldapugmod -t passwd mLou "loginShell=/net/bin/ksh"
The following command replaces the gecos fields with the new values for the user entry, alouie:
./ldapugmod -t passwd -I "Ann Louie,Building-6,222-2222" alouie
The following command adds the description attribute and value to the user entry, mscott:
./ldapugmod -t passwd -A "description=test user entry" mscott
Removing user attributes
The following command removes the sn attribute and value for user entry alee:
./ldapugmod -t passwd -R "sn=Ann Lee" alee
7.7 Managing users and groups 227
Command arguments
The following describes arguments and options used in the preceding examples for the ldapugmod
-t passwd commands:
-PW
Sets the user or group password attribute. If you specify -PW, you must
specify either the LDAP-UGCRED environment variable or the -PP option.
-A <attrval>
Specifies an attribute and value to be added to a user or group entry.
When working with multi-valued attributes, you can use the -A option to
add a new value for a multi-valued attribute, without removing already
existing values for that attributes.
-R <attrval>
Specifies an attribute and value to be removed from a user or group entry.
When working with multi-valued attributes, you can use the -R option to
remove a specified value for a multi-valued attributes.
-u <uidNumber>
Replaces the user's numeric id number.
-I <gecos>
Replaces the GECOS fields for the user. Typically the GECOS argument
contains the following four fields which represent (in order):
•
The user's full name
•
The user's work location
•
The user's work telephone number
•
The user's home telephone number (often omitted)
Each field in the <gecos> argument must be separated by a comma.
<attr>=<value>
Allows modification of arbitrary LDAP attributes and values.
7.7.1.5 Modifying a group (ldapugmod)
Modifying group attributes
The following command sets the gidNumber value for the group entry GroupA to 2500:
./ldapugmod -t group -g 2500 groupA
The following group entry contains multiple description attribute values:
dn: cn=GroupB,ou=Group,dc=example,dc=com
cn: GroupB
gidNumber: 350
MemberUid: tlee
Description: Test Group
Description: A Group Entry
The following command replaces all instances of the description attribute for the GroupB entry
with a new (single) description value of Group B Entry:
./ldapugmod -t group GroupB "description=Group B Entry"
The following shows the modified GroupB entry:
dn: cn=GroupB,ou=Group,dc=example,dc=com
cn: GroupB
gidNumber: 350
MemberUid: tlee
Description: Group B Entry
To add an instance of the description attribute and value to the group entry without removing
already existing values for that attribute, use the -A option, as in the following example:
./ldapugmod -t group -A "description=Best group in the world" groupB
The following displays the GroupB entry with the added description value:
dn: cn=GroupB,ou=Group,dc=example,dc=com
cn: GroupB
228 Administering LDAP-UX Client Services
gidNumber: 350
MemberUid: tlee
Description: Group B Entry
Description: Best group in the world
Adding members to a group entry
The following command adds the three members atam, mlou, and mscott to the group entry
groupA:
./ldapugmod -t group -a atam,mlou,mscott GroupA
Removing members from a group entry
The following command removes member atam from the group entry, groupA:
./ldapugmod -t group -r atam GroupA
Command arguments
The following describes arguments and options used in the preceding examples:
-A <attrval>
Specifies an attribute and value to be added to an entry. When
working with multi-valued attributes, you can use the -A option to add
a new value for a multi-valued attribute, without removing already
existing values for that attributes.
-g <gidNumber>
Replaces the group's numeric ID number.
-a <member>[,...]
Adds one or more members to the specified group. When specifying
a list of members, you must use a comma (with no white space) to
separate each member.
-r <member>[,...]
Removes one or more members from the specified group. When you
specify a list of members, you must use a comma (with no white space)
to separate each member.
7.7.1.6 Deleting a user or a group (ldapugdel)
You can use ldapugdel to remove POSIX user and group entries from a directory server. With
the -O option, ldapugdel enables you to remove only POSIX related attributes and object classes
from a user or group entry without removing the entire entry.
The userPassword, uid, cn, and description attributes are commonly used by most other
user and group schemas. With the -O option, the ldapugdel tool does not attempt to remove
these attributes. The uidNumber, gidNUmber, loginShell, homeDirectory, gecos, and
memberUid attributes are relatively unique to the POSIX schema. All of them are removed when
the -O option is specified with the ldapugdel command accessing an HP directory server. When
accessing an HP directory server, the ldapugdel -t passwd -O command removes the
posixAccount object class and the following attributes:
•
uidNumber
•
gidNumber
•
homeDirecotry
•
loginShell
•
gecos
The -O option functions properly with a Windows ADS because the Windows server uses standard
RFC 2307 attributes with exception of the homeDirectory attribute. If accessing a Windows
2003 R2 ADS, the ldapugdel -t passwd -O command removes the posixAccount object
class and following attributes:
•
uidNumber
7.7 Managing users and groups 229
•
gidNumber
•
loginShell
•
gecos
Accessing either an HP or Windows server, the ldapugdel -t group -O command removes
the posixGroup object class and following attributes:
•
gidNumber
•
memberUId
•
userPassword
Use LDAP_BINDDN to specify the distinguished name (DN) of a user with sufficient directory server
privilege to delete users or groups in the LDAP directory server. Use LDAP_BINDCRED to specify
a password for the LDAP user specified by LDAP_BINDDN. Alternately, you can interactively specify
LDAP administrator bind identity and credential by using the prompt (-P) option with the command.
Deleting a user account entry
The following command deletes the entire user account entry skeith:
cd /opt/ldapux/bin
./ldapugdel -t passwd skeith
Deleting the posixAccount object class and associated attributes but not the entire user entry
The following command, when accessing an HP directory server, deletes only the posixAccount
object class and associated attributes uidnumber, gidNumber, homeDirectory, loginShell,
and gecos, without deleting the entire user entry msmith:
./ldapugdel -t passwd -O msmith
When accessing a Windows ADS, the command deletes only the posixAccount object class and
associated attributes uidnumber, gidNumber, loginShell, and gecos, without deleting the
entire user entry.
Run the following command to delete only the posixGroup object class and associated attributes,
gidNumber, memberUid, and userPassword, without deleting the entire group entry groupB:
./ldapugdel -t group -O groupB
Deleting a group entry that has a specified DN
The following command accessing an HP directory server deletes the entire group entry that has
the distinguished name “cn=groupA,ou=groups,dc=example,dc=com":
./ldapugdel -t group -D "cn=groupA,ou=groups,dc=example,dc=com"
For a Windows ADS, the following command deletes the entire group entry that has the distinguished
name “cn=groupA,cn=users,dc=example,dc=com":
./ldapugdel -t group -D "cn=groupA,cn=users,dc=example,dc=com"
Command arguments
The following describes the ldapugdel options and arguments used in the preceding examples:
-t <type>
Specifies the type of entry the ldapugdel tool needs to delete. <type> can be
passwd or group. The passwd type represents LDAP user entries which contain
POSIX account-related information. The group type represents LDAP group entries
which contains POSIX group-related information.
-O
Allows the ldapugdel tool to delete only the posixAccount or posixGroup object
class and associated attributes, without deleting the entire user or group entry.
-D
The ldapugdel tool searches for the named user or group using the search rules
defined by the service search descriptor in LDAP-UX configuration profile. You can
230 Administering LDAP-UX Client Services
use the -D option to specify the distinguished name (DN) of the entry being deleted.
You may specify only one of -D, <uid_name> or <group_name> parameters
on the command line.
7.7.1.7 Examining the LDAP-UX configuration
The ldapcfinfo tool provides several capabilities used to report LDAP-UX configuration and
status. When used specifically with the LDAP user and group tools, ldapcfinfo can be used to
discover LDAP-UX configuration details about required attributes when adding new users or groups
to a directory server.
NOTE: The LDAP-UX Client Services provides two user and group default template files to work
with Windows 2003 R2 or 2008 Active Directory Server. If you attempt to use default template
files when using ldapcfinfo to access a Windows ADS, you must manually use the following
commands to relink the default templates to the default templates for the Windows ADS:
•
ln -fs /etc/opt/ldapux/ug_templates/ug_passwd_ads.tmpl \
/etc/opt/ldapux/ug_templates/ug_passwd_default.tmpl
•
ln -fs /etc/opt/ldapux/ug_templates/ug_group_ads.tmpl \
/etc/opt/ldapux/ug_templates/ug_group_default.tmpl
7.7.1.7.1 Verifying whether LDAP-UX is configured
To verify that the LDAP-UX is properly configured for a specified service, use the ldapcfinfo
-t <type> command. The valid <type> value for HP directory servers can be passwd, group,
netgroup, services, rpc, hosts, networks, automount, NIS-based publickey,
protocols and pam. For Windows ADS, the valid <type> value can be passwd, group,
services, rpc, hosts, networks, protocols and pam. (LDAP-UX using Windows 2003 R2
or 2008 Active Directory Server does not support netgroup and publickey service data.)
The following command example shows how to verify that LDAP-UX is properly configured for the
passwd service:
cd /opt/ldapux/bin
./ldapcfinfo -t passwd
If LDAP-UX is properly configured, the command output would be:
INFO:
CFI_CONFIG_SUCCESS:
"passwd" service appears properly configured for LDAP-UX operation
The following command verifies that LDAP-UX is properly configured for the automount service:
./ldapcfinfo -t automount
Assume that the automount service is not configured for LDAP-UX support. The following command
example verifies that LDAP-UX is properly configured for the automount service, followed by the
command output that indicates such support is not configured.
WARNING:
CFI_CONFIG_FAILURE:
"automount" service not configured for LDAP-UX support
7.7.1.7.2 Listing available templates
Use the ldapcfinfo -t <type> -L command to display a list of available templates. The
valid <type> value can be passwd or group.
For example, the following command displays a list of available template files that ldapugadd
uses to create a new user entry for the passwd name service:
./ldapcfinfo -t passwd -L
If the /etc/opt/ldapux/ug_templates/ug_passwd_std.tmpl, /etc/opt/ldapux/
ug_templates/ug_passwd_default.tmpl, and /etc/opt/ldapux/ug_templates/
7.7 Managing users and groups
231
ug_passwd_ads.tmpl files are currently available on the system, the output of the preceding
command would be as follows:
/etc/opt/ldapux/ug_templates/ug_passwd_ads.tmpl
/etc/opt/ldapux/ug_templates/ug_passwd_std.tmpl
/etc/opt/ldapux/ug_templates/ug_passwd_default.tmpl
As another example, the following command displays a list of available template files that
ldapugadd uses to add a group entry for the group name service:
./ldapcfinfo -t group -L
If the /etc/opt/ldapux/ug_templates/ug_group_std.tmpl, /etc/opt/ldapux/
ug_templates/ug_group_default.tmpl, and /etc/opt/ldapux/ug_templates/
ug_group_ads.tmpl template files are currently available on the system, the command output
would be as follows:
/etc/opt/ldapux/ug_templates/ug_group_ads.tmpl
/etc/opt/ldapux/ug_templates/ug_group_std.tmpl
/etc/opt/ldapux/ug_templates/ug_group_default.tmpl
7.7.1.7.3 Discovering required attributes
To discover which attributes defined in a template file are required to create a new user or group
entry, use the ldapcfinfo -t <type> -R command . Because the RFC 2307 POSIX attributes
are a static known list and are required, ldapcfinfo displays only nonPOSIX attributes. The
valid <type> value can be passwd or group.
The following command displays the nonPOSIX attributes defined in the default template file /etc/
opt/ldapux/ug_tempates/ug_passwd_std.tmpl (on an HP directory server) or /etc/
opt/ldapux/ug_templates/ug_passwd_ads.tmpl (on a Windows ADS) that are required
by the ldapugadd command for the passwd name service:
./ldapcfinfo -t passwd -R
7.7.1.7.4 Displaying configuration defaults
To display the LDAP default values in the /etc/opt/ldapux/ldapug.conf file that are used
for the ldapugadd command, use the ldapcfinfo -t <type> -D command . The valid
<type> value can be passwd or group.
If you specify the -t password -D option, ldapcfinfo displays the UID range, default primary
GID number, default home directory, and default login shell information. The -t group -D option
displays the GID range.
For example, the following command displays the LDAP default values in the /etc/opt/ldapux/
ldapug.conf file:
./ldapcfinfo -t passwd -D
The following is an example of the output displayed by this command for the passwd name
service:
uidNumber_range=100:20000
default_gidNumber=20
default_homeDirectory=/home
default_loginShell=/usr/bin/sh
As another example, the following command displays the LDAP default configuration values in the
/etc/opt/ldapux/ldapug.conf file for the group name service:
./ldapcfinfo -t group -D
An example of the output for this command follows:
gidNumber_range=100:2000
7.7.1.7.5 Displaying the DN of the LDAP-UX profile
To display the location of the LDAP-UX configuration profile, use the following command:
232 Administering LDAP-UX Client Services
./ldapcfinfo -P
Example command output for an HP directory server
dn: cn=ldapux-profile,ou=org,dc=example,dc=com
host: 55.5.55.15:389
If SSL is required to download the profile, the output would appear as follows:
dn: cn=ldapux-profile,ou=org,dc=example,dc=com
hostssl: 55.5.55.15:636
Example command output for a Windows ADS
dn: cn=ldapux-profile,cn=system,dc=org,dc=example,dc=com
host: 55.5.55.15:389
If SSL is required to download the profile, the output of the command is as follows:
dn: cn=ldapux-profile,cn=system,dc=org,dc=example,dc=com
hostssl: 55.5.55.15:636
7.7.1.7.6 Displaying default search base
Use the ldapcfinfo -t <type> -b command to display the primary (first) configured search
base in the LDAP-UX profile configuration for a specific service. The valid <type> value can be
passwd or group.
For example, the following command displays the LDAP-UX default search base for the passwd
name service. In this example, “ou=People,” has been configured as the search base for the
passwd name service for an HP directory server:
./ldapcfinfo -t passwd -b
The output from this command follows:
ou=People,ou=org,dc=example,dc=com
The following command displays the LDAP-UX default search base for the group name service
for Windows Active Directory Server. In this case, cn=Groups has been configured as the search
base for the group name service:
./ldapcfinfo -t group -b
The output from this command follows:
cn=users,dc=org,dc=example,dc=com
7.7.1.7.7 Displaying recommended attributes
To display the recommended list of attributes that an interactive management tool considers making
available for modification for a specified entry, use the ldapcfinfo -t <type> - a <DN>
command.
For example, accessing an HP directory server, the following command displays the recommended
list of attributes for the user account entry with the distinguished name (DN)
"cn=sfong,ou=people,ou=org,dc=example,dc=com":
./ldapcfinfo -t passwd -a "cn=sfong,ou=people,ou=org,dc=example,dc=com"
The output of the command follows:
cn
uid
uidnumber
gidnumber
loginshell
homedirectory
gecos
description
7.7 Managing users and groups 233
7.7.1.7.8 Displaying attribute mapping for a specific name service
To display attribute mapping information defined in the LDAP-UX configuration profile, use the
ldapcfinfo -t <type> -m command. The valid <type> value can be passwd or group.
For example, the following command displays the attribute mapping for the gecos attribute that
is mapped to the cn, l, and telephone attributes:
./ldapcfinfo -t passwd -m gecos
The output of the command follows:
gecos=cn l telephoneNumber
As another example, the following command displays the attribute mapping for the gecos and
uidNumber attributes. In this example, gecos is mapped to the cn, l, and telephone attributes,
and uidNumber is mapped to the employeeNumber attribute:
./ldapcfinfo -t passwd -m gecos,uidNumber
The output of the command follows:
gecos=cn l telephoneNumber
uidNumber=employeeNumber
7.7.2 Windows utilities for managing Windows ADS users, groups, and hosts
Select one of the following methods to add data to Windows ADS.
•
You can create user, group, and other service objects by using the object classes and attributes
specified by RFC 2307. In this situation you must import an ldif file with all RFC 2307 object
classes and attributes specified.
•
Alternatively, you can add users, groups, and hosts using the Windows 2003 R2 or 2008
Active Directory Users and Computers administrative tool. If using Active Directory Users and
Computers, perform the following to set POSIX attributes:
1. Start Active Directory Users and Computers.
2. Click the users (or computers) you want to set for POSIX attributes.
3. Select Properties from the Action menu.
4. Click the Unix Attributes tab.
5. In the NIS Domain box, select a NIS domain from the list. Server for NIS creates a default
NIS domain based on your Active Directory domain name.
6. For users, fill in the UID, Login Shell, Home Directory, and Primary group name/GID fields.
Click OK.
For hosts, fill in the IP Address and the Alias Name. Click OK.
•
Add networks, protocols, services, rpc objects, or set POSIX attribute memberUID for groups
using the ADSI Edit snap-in tool. These object classes and attributes cannot be populated from
the Active Directory Users and Computers tool.
1. On your domain controller, click Start, then Run. In the Open dialog box, entermmc, then
click OK.
2. Click the Microsoft Management Console menu, then select Add/Remove Snap-In.
3. In the Add/Remove Snap-In dialog box, click Add.
4. In the Add Standalone Snap-In dialog box, select ADSI Edit, then click Add and then
Close.
5. ADSI Edit appears in the Add/Remove Snap-In dialog box. Click OK.
6. In the Microsoft Management Console, click ADSI Edit and select Connect to... from the
Action menu.
7. In the Connection dialog box, select Naming Context, and select Domain NC from the
drop-down list at the right. Then click OK..
8. Domain NC appears on the right pane. Double-click it to expand the list.
234 Administering LDAP-UX Client Services
9.
To change group attributes:
a. Click the container of the group for which you want to set POSIX attributes.
b. Click the group and select Properties from the Action menu.
10. To create an object (rpc, services, and so on):
a. Click the container of the object you want to create, click the Action menu, select
New , and click on Object.
b. Select the Object Class ( )unixIpNetwork, unixIpProtocol,
unixIpService, or unixOncRpc, and provide the mandatory attribute values
and object will be created.
c. Click the created object, and select Properties from the Action menu to set the RFC
2307 attributes.
11. In the Select Which Properties to View dialog box, select Optional from the drop-down
list on the right.
12. In the Select Which Properties to View dialog box, select the POSIX attribute for which
you want to set values.
13. After you finish all values settings, click OK.
7.8 Managing hosts in an LDAP-UX domain
LDAP-UX B.05.00 introduces utilities that simplify management of hosts, adding to the toolset
provided for managing users and groups. Two utilities have been added, /opt/ldapux/bin/
ldaphostmgr and /opt/ldapux/bin/ldaphostlist. These utilities let you discover, create,
modify, and remove host objects in the directory server. Similar to the user and group management
tools described in Section 7.7 (page 218), these host-management tools integrate with the LDAP-UX
configuration, enabling administrators and automated scripts to modify host information without
needing to know configuration information such as the directory server host name, directory server
tree location, authentication methods, attribute mapping, search filters, and so forth.
As part of the guided installation, LDAP-UX uses the ldaphostmgr tool to provision information
about the current host into the directory server, including the host’s ssh public key data. (For more
information about using LDAP-UX to manage ssh host keys and to preestablish trust between hosts,
see “Managing ssh host keys with LDAP-UX (HP directory servers only)” (page 258).)
This section describes how to use the LDAP host management tools, ldaphostmgr and
ldaphostlist, by following example usage scenarios. Additional usage scenarios are described
in “Managing ssh host keys with LDAP-UX (HP directory servers only)” (page 258).
NOTE: The examples in this section are targeted toward entries stored in an HP-UX Directory
server. Windows ADS users should translate the examples to the respective usage in ADS. For
example, instead of using an administrator DN of
uid=domadmin,ou=people,dc=mydomain,dc=eample,dc=com, you might see
cn=administrator,cn=users,dc=mydomain,dc=eample,dc=com in a Windows domain.
7.8.1 Adding a host
Use the ldaphostmgr tool to add, modify, and delete hosts to, in, and from the directory server.
ldaphostmgr relies on the LDAP-UX configuration profile to determine the proper location to
store new hosts. (For information about displaying the configuration profile, see Section 7.10.1
(page 244); for information about configuration profile object classes and attributes, see “LDAP-UX
Client Services object classes” (page 406).) The location where hosts are stored is defined in the
profile’s serviceSearchDescriptor for the hosts service. If you used the guided installation
(autosetup), this location is automatically defined to be ou=hosts,suffix or
cn=computers,suffix (for a Windows domain), where suffix is the base of your directory
tree or base of the Windows domain. If you have an existing configuration profile that was not
set up using guided installation, the location where your hosts will be stored might be defined to
7.8 Managing hosts in an LDAP-UX domain 235
a different location, or might not be defined at all (using defaults). You can use the ldapcfinfo
tool to determine where LDAP-UX believes host information should be located. For example:
# /opt/ldapux/bin/ldapcfinfo -t hosts -b
ou=Hosts,dc=mydomain,dc=example,dc=com
Before adding any hosts to the directory server, verify that the base DN discovered in the previous
example is defined to the proper location in the directory server tree. If it is not, you can reconfigure
the LDAP-UX profile and modify the host serviceSearchDescriptor attribute using the steps
outlined in Section 7.10.2 (page 245).
Use the -a option of the ldaphostmgr command to add new hosts to the directory, as shown in
the following example. (In the examples that follow, assume the PATH environment variable contains
/opt/ldapux/bin.)
# ldaphostlist
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
ipHostNumber: 16.92.96.116
# id
uid=1173(domadmin) gid=1136(DomainAdmins) groups=1411(HostAdmins)
# ldaphostmgr -a baker
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
ipHostNumber: 16.92.96.116
dn: cn=baker,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: baker
ipHostNumber: 16.89.146.146
In the previous example, one host (brewer) already existed in the directory server. Another (baker)
was added using the -a option. By default, the IP address for the host is discovered and added.
In addition, the owner is assigned by default. You can display the owner, or any attribute, using
ldaphostlist, as follows:
# ldaphostlist -n baker \*
dn: cn=baker,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: baker
ipHostNumber: 16.89.146.146
objectClass: top
objectClass: device
objectClass: iphost
owner: uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com
In this case, the owner was assigned to domadmin, which is the user that created the entry in the
preceding example. You can assign ownership to a different user or group using the -O option:
# ldaphostmgr -a -O user:bobj chef
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist -n chef owner
dn: cn=chef,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: chef
ipHostNumber: 0.0.0.0
owner: uid=bobj,ou=People,dc=mydomain,dc=example,dc=com
If you used the guided installation to create your directory server, then by default, owners of hosts
have rights to manage information about the hosts. For additional information, see Section 2.3.2
(page 31).
236 Administering LDAP-UX Client Services
7.8.2 Modifying a host
Use the -m option of ldaphostmgr to modify existing host entries. If neither -a, -m, nor -g is
specified, -m is assumed. In the -a and -m modes, ldaphostmgr can be used to add, change,
or remove arbitrary attributes. You can manage some attributes using ldaphostmgr command-line
options; for example, use -k to manage the host’s ssh public key, and -i to manage the host’s IP
address. You can add arbitrary attributes using the -A or -R options, or by adding an attribute
and value list to the end of the command line. The following example shows how to assign a “role”
to a host:
# ldaphostmgr -m -r WEBSERVER -A objectclass=labeledURIObject \
-A "labeledUri=http://baker.mydomain.example.com" baker
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist -n baker \*
dn: cn=baker,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: baker
ipHostNumber: 16.89.146.146
objectClass: top
objectClass: device
objectClass: iphost
objectClass: domainEntity
objectClass: labeledURIObject
owner: uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com
entityRole: WEBSERVER
labeledUri: http://baker.mydomain.example.com
Adding and removing attributes can be affected when these attributes are multivalued (meaning
one attribute type can contain multiple instances, with different values). Managing multivalued
attributes is handled differently for arbitrary attributes as opposed to attributes managed by
command-line options (like -r in the previous example). For example, using -r replaces all existing
values of the entityRole attribute. Refer to the ldaphostmgr(1M) manpage for additional
information for each usage scheme. IP addresses are stored in the ipHostNumber attribute, and
managed with the -i option. Additional details on how to manage IP addresses are described in
Section 7.8.4 (page 238).
7.8.3 Deleting a host
Use the -d option of ldaphostmgr to remove a host from the directory server. This removes the
entire entry from the directory server. To only remove specific attributes from an entry, see the -R
option in the ldaphostmgr(1M) manpage. The following example shows how to remove a host
entry:
# ldaphostlist entityRole
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
ipHostNumber: 16.92.96.116
dn: cn=baker,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: baker
ipHostNumber: 16.89.146.146
entityRole: WEBSERVER
dn: cn=chef,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: chef
ipHostNumber: 0.0.0.0
# ldaphostmgr -d chef
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
7.8 Managing hosts in an LDAP-UX domain 237
ipHostNumber: 16.92.96.116
dn: cn=baker,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: baker
ipHostNumber: 16.89.146.146
CAUTION:
If you used guided installation to configure LDAP-UX on a host, removing that host
entry also removes the proxy user defined for that host. Removing the host’s proxy user entry
disables the ability of the OS to use LDAP as an OS management repository. When you use guided
installation to create a directory server, that directory server will require authenticated access to
itself before returning any data. The host’s proxy user entry is used to define a way for the host’s
OS to authenticate to the directory server. Removing the proxy user (host entry) terminates the
ability of ldapclientd to bind to the directory server. For example, if we remove the proxy user
entry for the current host, the following error occurs:
# ldaphostmgr -d "$(hostname)"
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
# ldaphostlist
ERROR:
BIND_ERR:
Failed to bind to the directory server.
You can restore the host’s proxy entry and restore the proxy credential file as follows. You must
define a new password in order to recreate the proxy credentials:
# ldaphostmgr -a -P -f -k all -S "$(hostname)"
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
Host password:
Re-enter host password:
added DN: cn=brewer,ou=Hosts,dc=mydomain,dc=eample,dc=com
# su
Password:
# /opt/ldapux/config/ldap_proxy_config -i << EOD
> cn=brewer,ou=Hosts,dc=mydomain,dc=eample,dc=com
> [Host Password Used Previously]
> EOD
7.8.4 Managing IP addresses
Use the -i option to add or remove IP addresses to or from host entries. Without flags, the -i
option adds an additional IP address to a host entry. If you have a host with multiple IP interfaces,
you can use -i to add any additional IP addresses that have not yet been registered. For example:
# ldaphostlist -n brewer
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
ipHostNumber: 16.92.96.113
# ldaphostmgr -i 192.168.10.10 brewer
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist -n brewer
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
ipHostNumber: 16.92.96.113
ipHostNumber: 192.168.10.10
238 Administering LDAP-UX Client Services
To remove an IP address for a host, use the -i option with the ! flag in front of the IP address to
be removed. For example, to remove the address added in the previous example:
# ldaphostmgr -i !192.168.10.10 brewer
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist -n brewer
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
ipHostNumber: 16.92.96.113
To remove all IP addresses for a host, use the -i option with the ! flag by itself. However, after
removing all IP addresses, the special address 0.0.0.0 is added to assure that the ipHost object
class can remain as part of the host entry. The ipHost object class is the only standard object
class that is used to identify hosts and distinguish them from other types of devices. Example:
# ldaphostmgr -i "!" brewer
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist -n brewer
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
ipHostNumber: 0.0.0.0
To remove all ipHostNumber attributes, use the -R option. This removes both the ipHostNumber
attribute and the ipHost object class. However, when this occurs, ldaphostlist is no longer
able to display the host, since the ipHost object class is the critical object class used to distinguish
hosts from other types of devices managed in the directory server. You can use the -F option to
override the default ldaphostlist search filter to find hosts or other types of devices that do
not use the ipHost object class. Example:
# ldaphostmgr -R iphostNumber -R objectclass=iphost brewer
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
# ldaphostlist -n brewer 1
# ldaphostlist -F "(&(objectclass=device)(cn=brewer))"
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
1
No host was found
7.8.5 Managing hosts in groups
There are several ways to group hosts. You can accomplish simple grouping by adding hosts as
members of the traditional X.500 group structures. Use the -G option to do this. The -G option
supports the ! flag to remove a host from a group, similar to the -i option. Note that in a POSIX
environment, the grouping of hosts is not a native construct. Users may be members of groups, but
hosts may not. In an HP directory server, any object in the directory server may be a member of
any X.500 style group. So, grouping of hosts using the -G option can add hosts only as members
of the X.500 style groups, identified with the groupOfNames or groupOfUniqueNames object
classes. While you can list members of these types of groups using the /opt/ldapux/bin/
ldapsearch utility, you can also extend the display capabilities of the ldapuglist tool to list
groups that are standard X.500 groups and contain hosts as members. The following example
shows how to add a host to a group (dbhosts) that already has one member (baker):
# ldapuglist -t group -P -F "(cn=dbhosts)" uniqueMember
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
dn: cn=dbhosts,ou=groups,dc=mydomain,dc=eample,dc=com
cn: dbhosts
uniqueMember: cn=baker,ou=Hosts,dc=mydomain,dc=eample,dc=com
# ldaphostmgr -G dbhosts chef
7.8 Managing hosts in an LDAP-UX domain 239
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
# ldapuglist -t group -P -F "(cn=dbhosts)" uniqueMember
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
dn: cn=dbhosts,ou=groups,dc=mydomain,dc=eample,dc=com
cn: dbhosts
uniqueMember: cn=baker,ou=Hosts,dc=mydomain,dc=eample,dc=com
uniqueMember: cn=chef,ou=Hosts,dc=mydomain,dc=eample,dc=com
To remove a host from a group, use the ! flag in front of the host name:
# ldaphostmgr -G !dbhosts baker
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
# ldapuglist -t group -P -F "(cn=dbhosts)" uniqueMember
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
dn: cn=dbhosts,ou=groups,dc=mydomain,dc=eample,dc=com
cn: dbhosts
uniqueMember: cn=chef,ou=Hosts,dc=mydomain,dc=eample,dc=com
To list host entries that are members of a particular group, use the -g option of the ldaphostlist
command. For example, to capture all the ssh host keys for a particular group of hosts, you could
use the following command:
# ldaphostlist -g webhosts -k
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=eample,dc=com
cn: brewer
ipHostNumber: 0.0.0.0
sshPublicKey: ssh-rsa AAAAB3NzaC16AeE...
dn: cn=raptor,ou=Hosts,dc=mydomain,dc=eample,dc=com
cn: raptor
ipHostNumber: 16.92.96.215
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAA...
7.8.6 Classifying hosts
Because ldaphostmgr lets you attach arbitrary attributes to host entries, you may use these
attributes to classify systems and then use that information as a way to group hosts. Aside from
grouping hosts using an enumerated list of members in X.500 groups, LDAP directory servers offer
an efficient way to group systems based on their attributes. This is typically known as dynamic
grouping. In the previous example, we created a group of hosts known as dbhosts (assuming
these hosts might hold some form of data base). We could have just as easily defined a role for
these hosts, marking them as DBSERVERs as follows:
# ldaphostmgr -r DBSERVER brewer
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
# ldaphostmgr -r DBSERVER raptor
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com]:
Password:
Use the -f option of ldaphostlist, to quickly discover the list of DBSERVERs.
# ldaphostlist -f "(entityRole=DBSERVER)" \*
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=eample,dc=com
cn: brewer
ipHostNumber: 0.0.0.0
objectClass: top
objectClass: device
objectClass: ipHost
objectClass: ldapPublicKey
objectClass: domainEntity
owner: uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvrJ...
240 Administering LDAP-UX Client Services
entityRole: DBSERVER
dn: cn=raptor,ou=Hosts,dc=mydomain,dc=eample,dc=com
cn: raptor
ipHostNumber: 16.92.96.215
objectClass: top
objectClass: device
objectClass: ldapPublicKey
objectClass: iphost
objectClass: domainEntity
owner: uid=domadmin,ou=People,dc=mydomain,dc=eample,dc=com
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxe1...
entityRole: DBSERVER
7.8.7 Managing process access rights (proxy_is_restricted)
If you have configured LDAP-UX to use anonymous access to the directory server, you may skip
this section.
Under specific conditions described in this section, the ldaphostlist utility will not allow the
user to display arbitrary attributes associated with host entries managed in the directory server. If
you try to display an attribute and cannot view it as expected, you can use the -v option to verify
whether this attribute is restricted, as shown in the following example. Assume that a user wanted
to display the owner of a host and gets a warning message like the one shown in the example.
# ldaphostlist -n brewer owner
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=eample,dc=com
cn: brewer
ipHostNumber: 0.0.0.0
# ldaphostlist -v -n brewer owner
WARNING: LST_ATTR_RESTRICTED:
Attribute "owner" is ignored. Access rights to the attribute can not
be determined because proxy access has been defined but
proxy_is_restricted has not been set. Contact your system
administrator.
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=eample,dc=com
cn: brewer
ipHostNumber: 0.0.0.0
This message can occur if LDAP-UX is configured to use a proxy user to access the directory server
data. This is very common in an ADS environment, since by default, the ADS directory server does
not allow anonymous access to data.
If you have installed and configured a previous version of LDAP-UX or did not use the guided
installation (autosetup) to configure LDAP-UX, you would have defined your own proxy user.
Because the ldaphostlist uses this same proxy user to access directory server data,
ldaphostlist needs to know if the proxy user has access to data that a nonprivileged user
should not be allowed to view. For example, if the proxy user was defined as
cn=administrator,cn=user,dc=mydomain,dc=example,dc=com (for a Windows domain)
or cn=Directory Manager (for an HP-UX Directory Server), the proxy user has rights to access
any data in the directory server.
While it would be bad practice to create a proxy user with privileged access rights, normally the
proxy user is only used by ldapclientd, which limits what information it requests from the
directory server. However, because the user can instruct ldaphostlist to view any attribute,
ldaphostlist does not allow users to specify any attribute to be viewed, since these tools do
not know if the proxy user has more privileges than should be granted to the user running the utility.
When a host is configured using the guided installation, an entry representing the host is created;
this entry is also used as the proxy user for the OS. Because his host entry is created without adding
any special privileges, the guided installation sets a special flag (proxy_is_restricted) inside
the /etc/opt/ldapux/ldapclientd.conf file to indicate that the proxy user has been
created without any additional special privileges. This flag is also used by ldaphostlist, to
7.8 Managing hosts in an LDAP-UX domain
241
determine if it is safe to request arbitrary attributes from the directory server. ldaphostlist
assumes that the directory server has defined proper access control limits such that confidential or
private information cannot be viewed by the proxy user. The [general] section of the client
daemon configuration file (ldapclientd.conf) controls this behavior:
...
# If proxy_is_restricted is set to 1, then you are attesting that the
# directory server is restricting access to private or other confidential
# information from access by the proxy user.
proxy_is_restricted=1
# Allows the ldapclientd interface to return attributes that are associated
# with RFC2307-based services (such as users and groups), but that those
# attributes are not specifically part of the RFC2307 schema. Any attribute
# specified below should be considered public information.
allowed_attribute=hosts:sshPublicKey
allowed_attribute=passwd:sshPublicKey
Setting proxy_is_restricted to 1 means that ldaphostlist will not restrict the user from
displaying any attribute (the directory server might still deny access if access control instructions
exist to limit what is visible to the proxy user.)
Only set proxy_is_restricted to 1 if you can verify that your proxy user defined in /etc/
opt/ldapux/pcred does not have rights to access data in the directory server beyond that of
any nonprivileged user. To identify what account is defined as the proxy user, use the
ldap_proxy_config utility as follows, and then examine the directory server’s access control
settings to verify this account’s privileges:
# /opt/ldapux/config/ldap_proxy_config -p
PROXY DN: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
7.9 Managing proxy users
This section explains administrative functions pertaining to proxy users.
7.9.1 Displaying the proxy user's DN
You can display the proxy user's distinguished name by using the
/opt/ldapux/config/ldap_proxy_config -p command.
The following command example shows how to use this command to display the current proxy
user and includes the command output seen using an HP directory server:
cd /opt/ldapux/config
./ldap_proxy_config -p
PROXY DN: uid=proxy,ou=people,o=hp.com
The output from the command as seen when using Windows ADS might be as follows:
PROXY DN: CN=Proxy User, CN=Users, DC=cup, DC=hp, DC=com
7.9.2 Verifying the proxy user
The proxy user information is stored in the file /etc/opt/ldapux/pcred. You can verify that
the proxy user can authenticate to the directory by running
/opt/ldapux/config/ldap_proxy_config -v as follows. In this example, the output verifies
that the proxy user can authenticate to the directory.
cd /opt/ldapux/config
./ldap_proxy_config -v
File Credentials verified - valid
7.9.3 Creating a new proxy user
If you need to create a new proxy user and change your client systems to use the new proxy user,
use the following steps:
242 Administering LDAP-UX Client Services
1.
Add the new proxy user to your directory with appropriate access controls. For information
about adding a new proxy user to your directory, see the steps "Create a proxy user" and
"Set access permissions for the proxy user" in Section 2.4.4 (page 65).
For Windows ADS, additional steps are required to set up the HP-UX host as a Kerberos
service principal in the Windows domain. When you create a proxy, use either a user or
service principal as the proxy user. A Kerberos keytab file contains principals. For more
information, see Section 7.3 (page 196).
2.
3.
4.
Configure each client to use the new proxy user by running
/opt/ldapux/config/ldap_proxy_config. For more information about this tool, see
Section 9.2.6 (page 280). Examples follow.
Run /opt/ldapux/config/ldap_proxy_config -p to display the proxy user you just
configured and confirm that it is correct.
Run /opt/ldapux/config/ldap_proxy_config -v to verify the proxy user is working.
NOTE: While the proxy user information stored in the pcred file is protected for root-only access
and not stored in plain text, it is not encrypted. Access to the pcred file must be restricted to
prevent discovery of the proxy user’s password. The same is true for the acred file.
Configuring a new proxy for an HP directory server
For example, the following command configures the local client for an HP directory server to use
a proxy user DN of uid=proxy,ou=people,o=hp.com with a password of abcd1234:
cd /opt/ldapux/config
./ldap_proxy_config -i
uid=proxy,ou=people,o=hp.com
abcd1234
NOTE: This command has no prompt. You must enter the DN and password on two separate
lines, as shown in this example.
The following command displays the current proxy user (just created by the preceding command):
./ldap_proxy_config -p
PROXY DN: uid=proxy,ou=people,o=hp.com
Configuring a new proxy for a Windows ADS
The following command configures the local client to use a proxy user DN of CN=Proxy User,
CN=Users, DC=cup, DC=hp, DC=com with a password of abcd1234:
cd /opt/ldapux/config
./ldap_proxy_config -i
CN=Proxy User, CN=Users, DC=cup, DC=hp, DC=com
abcd1234
NOTE: This command has no prompt. You must enter the DN and password on two separate
lines, as shown in this example.
The following command displays the current proxy user (just created by the preceding command):
./ldap_proxy_config -p
PROXY DN: CN=Proxy User, CN=Users, DC=cup, DC=hp, DC=com
Verfiying the proxy user can bind to the HP or Windows directory
The following command determines whether the proxy user can bind to the directory:
./ldap_proxy_config -v
File Credentials verified - valid
7.9 Managing proxy users 243
7.9.4 Changing from anonymous access to proxy access
This section does not apply to Windows ADS.
Your directory administrator may decide to change the directory server security policy and disallow
anonymous access to data hosted on the server. In this case, you would need to add a proxy user
and change the configuration profile to require proxy access.
If you have anonymous access and you want to change to using a proxy user, do the following:
1.
2.
3.
Create the proxy user in the directory. With HP-UX Directory Server, you can use the Directory
Server Console. Select the Users and Groups tab, and then click on the Create button. For
example, you might create a user uid=proxyuser,ou=Special Users,o=hp.com.
Register the proxy user and password in the /etc/opt/ldapux/pcred file, following the
steps described in 7.9.3 Creating a new proxy user (page 242). Repeat this step for each
LDAP-UX client that uses the same profile. Alternately, you can copy the
/etc/opt/ldapux/pcred file to each host.
Change the credentialLevel attribute in your profile to be "proxy". Use the process
described in 7.10.2 to modify the profile.
If you want proxy access with anonymous access as a backup if proxy access fails, change
credentialLevel to be "proxy anonymous".
You can verify that the proxy user is configured with display_profile_cache and
ldap_proxy_config. The display_profile_cache command displays the current
configuration profile, including the credential level, which is either "proxy," "anonymous," or
"proxy anonymous." The ldap_proxy_config command displays and verifies the proxy user
the client is configured to use. For more information, see Section 9.2.4 (page 280), Section 9.2.6
(page 280), and Section 9.2.5 (page 280).
7.9.5 Changing from proxy access to anonymous access
This section does not apply to Windows ADS.
If you are using proxy access and you want to change to using anonymous access, do the following:
1.
2.
3.
Change the credentialLevel attribute in your profile to be "anonymous", using directory
administration tools such as the HPDS Directory Server Console.
Download the profile to the client. If you have an automated process to download the profile,
you can wait until it executes. Or you can download the profile manually as described in
Section 2.5.8 (page 111).
Remove the proxy information:
cd /opt/ldapux/config
./ldap_proxy_config -e
4.
Optionally, remove the proxy user from the directory if you no longer need it. With HP-UX
Directory Server, you can use the Directory Server Console.
7.10 Managing the LDAP-UX configuration profile
The LDAP-UX configuration profile /etc/opt/ldapux/ldapux_profile.bin (the configuration
profile translated from ldapux_profile.ldif in binary format) is a directory entry containing
configuration information common to many clients. Each client downloads the configuration profile
from the directory. This section explains the management operations pertaining to the configuration
profile.
7.10.1 Displaying the current configuration profile
You can display the profile in use by any client by running
/opt/ldapux/config/display_profile_cache on that client. The current profile is in the
binary file /etc/opt/ldapux/ldapux_profile.bin.
244 Administering LDAP-UX Client Services
cd /opt/ldapux/config
./display_profile_cache
You can also find out from where in the directory the client downloaded the profile by displaying
the file /etc/opt/ldapux/ldapux_client.conf and looking for the line beginning with
PROFILE_ENTRY_DN, for example:
ldapcfinfo -P
dn: cn=example-ldapuxProfile,ou=Services,ou=Configuration,dc=example,dc=acme,dc=com
hostssl: 192.192.96.116:389
You can also find the profile location by using the following command:
/opt/ldapux/bin/ldapcfinfo -P
7.10.2 Modifying a configuration profile
For an HP directory server, you can modify an existing profile directly by using your directory
administration tools, such as the HPDS Directory Server Console. (For information about using your
directory's administration tools, see the appropriate directory server documentation.) For Windows
ADS, you can modify an existing profile directly by using the Active Directory Services Interface
(ADSI) and the ADSIedit utility on a Windows host, performing the steps described in
Section 7.10.2.2 (page 245). For either directory server environment, you can use the ldapentry
tool to modify a profile, as described in Section 7.10.2.1 (page 245).
After modifying a profile, each client that regularly downloads its profile automatically will get the
changes as scheduled. For information about downloading the profile automatically, see
Section 2.5.8 (page 111). LDAP-UX Client Services does not support automatic downloading of the
LDAP-UX profile when used with SASL/GSSAPI authentication using a host or service principal,
where that principal's key is stored in a Kerberos keytab file. For information about how to download
the profile manually, see Section 7.3.4 (page 199).
For a description of the DUAConfigProfile object class used for LDAP-UX configuration profiles, its
attributes, and what values each attribute can have, see RFC 4876 and “LDAP-UX Client Services
object classes” (page 406).
7.10.2.1 Using ldapentry to modify a profile
In an HP directory server environment only, the ldapentry tool can also be used to modify the
existing profile. This can be done with the following command:
DNPROFILE=`/opt/ldapux/bin/ldapcfinfo -P | grep "^dn:" | cut -d" " -f
2-`
$ /opt/ldapux/bin/ldapentry -m "$DNPROFILE"
$ cd /opt/ldapux/config
$ ./get_profile_entry -s nss
7.10.2.2 Using Windows ADSI and ADSIedit to modify a profile
1.
2.
3.
Determine the location of the currently used configuration profile, as described in Section 7.10.1
(page 244).
On a Windows host, use ADSIedit to modify the appropriate attributes and values.
If profileTTL was previously set in the profile, ldapclientd will periodically update the
configuration on all clients (for information about enabling periodic updates, see Section 3.5.6
(page 158)). If profileTTL was not set, or you want to force an immediate update, use the
following command to download and install the current configuration profile:
/opt/ldapux/config/get_profile_entry -s NSS
7.10 Managing the LDAP-UX configuration profile 245
7.10.3 Creating a new configuration profile
To create a new profile, run /opt/ldapux/config/setup. When setup asks you for the
distinguished name (DN) of the profile, give a DN that does not exist and setup will prompt you
for the parameters to build a new profile. The setup program also configures the local client to
use the new profile.
Alternatively, you could use your directory administration tools to make a copy of an existing profile
and modify it.
You may also use the interactive tool create_profile_entry to create a new profile, as follows:
cd /opt/ldapux/config
./create_profile_entry
Once you create a new profile, configure client systems to use it, as described in Section 7.10.4
(page 246).
7.10.4 Specifying a different profile for client use
Each client uses the profile specified in its startup file /etc/opt/ldapux/ldapux_client.conf.
To make a client use a different profile in the directory, edit this file and change the DN specified
in the PROFILE_ENTRY_DN line. Then download the profile as described in Section 2.5.8
(page 111).
7.11 Creating an /etc/krb5.keytab file
In the ADS multiple domain environment, your HP-UX client machine will communicate with multiple
Windows 2003 R2 or 2008 domain controllers. To set up Kerberos authentication, your HP-UX
host needs to have a service key known by every domain controller; as such, the host acts as a
KDC. The service key is created on Windows 2003 R2 or 2008 Server using ktpass, as described
in Section 3.4.5 (page 135). After you create the service key file on each domain controller, you
must securely transfer it to your HP-UX machine. All service key files must be merged and stored
in /etc/krb5.keytab.
For example, if you integrate LDAP-UX with ADS multiple domains so that users from DomainA,
DomainB, and DomainC can log into your HP-UX client machine, you must create the service key
on each domain controller (say domainA.keytab on DomainA, domainB.keytab on DomainB
and domainC.keytab on DomainC), then transfer those files into your HP-UX machine. Finally,
merge all three service key files to create /etc/krb5.keytab. Use ktutil to merge service
key files on your HP-UX machine:
# /usr/sbin/ktutil
ktutil: rkt domainA.keytab
ktutil: rkt domainB.keytab
ktutil: rkt domainC.keytab
ktutil: wkt krb5.keytab
ktutil: quit
Use klist -k to show the different entries in the keytab file /etc/krb5.keytab, which should
be readable only by the supervisor.
For a list of all steps that you might need to perform to set up Kerberos support, see Section 3.4.2
(page 128).
7.12 Performance considerations
This section describes ways to improve network and server performance. For additional performance
information, see the LDAP-UX Integration Performance and Tuning Guidelines white paper at:
http://www.hp.com/go/hpux-security-docs
246 Administering LDAP-UX Client Services
Click HP-UX LDAP-UX Integration Software.
7.12.1 Reducing the performance impact of enumeration and search requests
The advantage of a directory server over flat files for naming and authentication services is its
design for quick access to information in large databases. Still, with very large databases,
administrators, and users should be aware of the following performance impacts.
7.12.1.1 Minimizing enumeration requests for less impact on server and network performance
Enumeration requests are directory queries that request all of a database, for example all users or
all groups. Enumeration requests of large databases could reduce network and server performance.
For this reason, you might want to restrict the use of commands and applications that generate
enumeration requests, such as:
•
finger (see the finger(1) manpage)
•
grgetwith no options (see the grget(1) manpage)
•
pwget with no options (see the pwget(1) manpage)
•
groups (see the groups(1) manpage)
•
listusers (see the listusers(1) manpage)
•
logins (see the logins(1M) manpage)
•
All netgroup calls (HP directory servers only)
In addition, depending on how they are written, applications written with families of routines such
as getpwent, getgrent, gethostent, and getnetent can enumerate a map. You could
possibly rewrite these applications so that an LDAP search request is used instead of a call to these
routines.
7.12.1.2 Setting search limits to reduce resource consumption and denial of service vulnerabilities
This section pertains to Windows ADS only.
The default configuration for Active Directory sets the search size limit to 1,000 entries and the
search time limit to two minutes. Setting search limits prevents users from consuming all the resources
of a directory and helps to minimize "denial of service" attacks; however, on large databases
search limits are not sufficient to service commands or applications that generate enumeration
requests. You can use the support tool ntdsutil to change these two search limit values. The
ntdsutil tool can be installed from the Windows 2003 R2 or 2008 Server CD in the \SUPPORT\
TOOLS folder.
NOTE: The search time limit set during the setup procedure specifies the search timeout on the
client side. To service enumeration requests, this parameter might need to be adjusted accordingly.
1.
On your domain controller, click Start, then Run.
In the Open box, enter the ntdsutil command and click OK.
2.
3.
4.
5.
At the ntdsutil prompt, enter the ldap policies command and press Enter. To see a
list of available commands, you can enter the ? symbol at any of the prompts in the ntdsutil
tool.
At the ldap policies: prompt, enter the connections command and press Enter.
At the server connections: prompt, enter the connect to server <servername>
command, where <servername> is the name of server you want to use, and then press
Enter.
At the server connections: prompt, enter the quit command and press Enter.
7.12 Performance considerations 247
6.
At the ldap policies: prompt, enter the set maxpagesize to <size> command, where
the <size> is the maximum number of search objects that you want the Active Directory to
return for a search, and then press Enter.
7. At the ldap policies: prompt, enter the set maxqueryduration to <time> command,
where the <time> is the maximum number of seconds to wait for a search request to complete,
and then press Enter.
8. At the ldap policies: prompt, enter the show values command and press Enter. This verifies
the new LDAP policies values are set correctly.
9. Once satisfied with the changes made, enter the Commit Changes command and press
Enter.
10. Enter the quit command and press Enter to return to the ntdsutil main prompt.
11. Enter the quit command and press Enter to quit ntdsutil.
7.12.1.3 Setting search filters to improve enumeration performance
This section pertains to Windows ADS only.
If enumeration requests cannot be avoided, consider the use of customized search descriptors for
each of your name services. Customized search descriptors can improve enumeration performance
because it limits the search only to the paths (containers) where the required data resides.
For example, if your default search DN is set to your domain root DC=cup, DC=acme, DC=com,
you can improve performance if you change the search base DN to CN=Users, DC=cup,
DC=acme, DC=com for the passwd and group services, confining searches to user and group
information.
7.12.2 Client daemon performance considerations
LDAP directory servers introduce numerous features that are not provided by earlier networked
name service systems. In addition, the general purpose nature of LDAP enables it to support a
greater variety of applications than does a networked OS. Although directory servers have excellent
performance and scalability, the additional features (such as security) require that directory
applications be designed and used with performance requirements in mind. To maximize the
number of HP-UX clients that can be supported by an LDAP directory server and to improve client
response, the ldapclientd daemon supports both data caching and persistent network
connections. The following subsections describe their use, benefits, and impacts on performance.
For more information about improving client daemon peformance, see Section 7.1.2.3 (page 183).
7.12.2.1 ldapclientd caching
Caching LDAP data locally enables much greater response time for name service operations.
Caching means that data that has been recently retrieved from the directory server will be retrieved
from a local store, instead of the directory server. Caching greatly reduces both directory server
load and network usage. For example, when a user logs into the system, the OS typically needs
to enquire about his/her account several times in the login process. This occurs as the OS identifies
the user, gathers account information and authenticates the user. And further requests often occur
as the account starts up new applications once a session is established. With caching, generally
only one or two LDAP operations are required.
Caching is also critical to support certain types of applications that make frequent demands on
the name service system, either because they are malfunctioning or need this specific type of
information frequently.
The ldapclientd daemon also supports what is known as a negative cache. This type of cache
is used to store meta-data about nonexistent information. For example, if an application requests
information about an account that does not exist, the directory server will not return an entry, and
that negative result will be stored in a cache. Intuitively this type of cache would seem to be
unnecessary. However, applications exist that perform these operations frequently, either on purpose
248 Administering LDAP-UX Client Services
or because they are malfunctioning. For example, if a file is created with a group ID that does not
exist, every time a user displays information about this file, using the ls command, a request to the
directory server will be generated.
The ldapclientd daemon currently supports caching of passwd, group, netgroup and
automount map information. The ldapclientd daemon also maintains a cache that maps user
accounts to LDAP DNs. This mapping enables LDAP-UX to support groupOfNames and
groupOfUniqueNames for defining membership of an HP-UX group.
Although there are many benefits to caching, administrators must be aware of the side effects of
their use. Table 23 includes examples to consider:
Table 23 Benefits and side effects of caching
Service (map) name
Benefits
Example side-effect
passwd
Reduces greatly the number of requests
sent to a directory server during a login
or other operation such as displaying files
owned by that user.
Removing this information from
the directory might not be visible
to the operating system until after
the cache has expired. In certain
cases, this might allow a user to
log in to an HP-UX host, even
after his account has been
removed from the LDAP directory
server. (In general this is not a
problem when PAM_LDAP is used
for authentication with HP
directory servers, since
authentication requests are not
cached.)
group
Frequent file system access might request
information about groups that own
particular files. Caching greatly reduces
this impact.
Removing a member of a group
might not be visible to the file
system, until after the cache
expires. During this window, a
user may be able to access files
or other resources based on
his/her group membership, which
had been revoked.
7.12 Performance considerations 249
Table 23 Benefits and side effects of caching (continued)
Service (map) name
Benefits
netgroup (not supported with Windows netgroups can be heavily used for
determining network file system access
ADS)
rights or user login rights. Caching this
information greatly reduces this impact
Example side-effect
Similar to groups, since netgroups
are used to control access to
resources, modification of these
rights might not appear until after
cache information has expired.
Users might be allowed or denied
login even though their rights
allow / deny access.
NOTE: Beginning with version
5.0 of the product, LDAP-UX
Client Services supports
integrated Compat Mode to
control which users are visible on
a host, where the user accounts
are referenced by netgroups
specified in the /etc/passwd
file. As a means to greatly
mitigate the performance impacts
of Compat Mode field masking,
LDAP-UX has integrated Compat
Mode support directly into
ldapclientd, enabling caching
of Compat Mode user entries. For
more information, see
Section 2.5.5 (page 102)
automount
Frequent file system access to a directory
might request automount information
about a network file system. A positive
AutoFS cache greatly reduces LDAP-UX
Client response time while retrieving the
automount data.
Whenever a user attempts to access a
directory that does not exist on the
physical file system, the AutoFS system is
called to determine if that directory is
available via the network through AutoFS.
A negative AutoFS cache is critical to
assure that malfunctioning applications
do not place redundant bogus requests
on the directory server.
For the positive AutoFS cache, an
alteration of the automount maps
will sometimes not appear
immediately. During this
expiration window, a network file
system might be granted access,
when in fact the automount map
should have unmounted from a
network file system.
For the negative AutoFS cache,
an alteration of the automount
maps will sometimes not appear
immediately. During this
expiration window, a user
attempting to access a network
file system might be denied
access, when in fact the
automount map should have set
up a network file system mount.
NOTE: The ldapclientd -f command will flush all caches. For more information, see the
ldapclientd(1M) manpage.
For each service listed in the preceding table (as service names), you can alter the caching lifetime
values in the /etc/opt/ldapux/ldapclientd.conf file. For additional information, see
Section 7.1.2.3 (page 183). It is also possible to enable or disable a cache using the -E or -D
(respectively) options. These options can be useful for determining the effectiveness of caching or
helpful in debugging.
7.12.2.2 ldapclientd persistent connections
Since the HP-UX can generate many requests to an LDAP server, the overhead of establishing a
single connection for every request can create excessive network traffic and slow response time
for name service requests. Depending on network latency, the connection establishment and
250 Administering LDAP-UX Client Services
tear-down can cause relatively severe delays for client response. However, a persistent connection
to the directory server will eliminate this delay.
In the ldapclientd daemon, a pool of active connections is maintained to serve requests from
NSS. If the NSS needs to perform a request to the directory server, one of the free connections in
this pool will be used. If there are no free connections in the pool, a new connection will be
established, and added to the pool. If system activity is low, then connections that have been idle
for a specified period of time (configurable in the ldapclientd.conf file) will be dropped to
free up directory server resources.
Aside from ldapclientd daemon connection time-out configuration, it is also possible to define
a maximum number of connections that ldapclientd may establish. Setting a high number of
connections means assures that ldapclientd will not become a bottleneck in performing name
service operations to the directory server. However, a high number of connections from a large
number of HP-UX clients to the same directory server might exhaust all available connection resources
on that directory server. Setting a low number of maximum connections will reduce that resource
requirement on the directory server, but might create a performance bottleneck in the ldapclientd.
7.13 Troubleshooting
This section describes troubleshooting techniques and problems you might encounter.
7.13.1 Enabling and disabling LDAP-UX logging
When something is behaving incorrectly, enabling logging is one way to examine the events that
occur to determine where the problem is. Enable LDAP-UX Client Services logging on a particular
client as follows:
1.
2.
Edit the local startup file /etc/opt/ldapux/ldapux_client.conf and uncomment the
lines starting with #log_facility and #log_level by removing the initial # symbol. You can set
log_level to LOG_INFO to log only unusual events. This is a good place to start. If LOG_INFO
is not adequate to identify the problem, set log_level to LOG_DEBUG to log trace information.
LOG_DEBUG will provide more information but will significantly reduce performance and
generate large log files on active systems.
Edit the file /etc/syslog.conf and add a new line at the bottom:
local0.debug <tab> /var/adm/syslog/local0.log
where <tab> is the Tab key on your keyboard.
3.
Restart the syslog daemon with the following command (for more information about this
command, see the syslogd(1M) manpage):
kill -HUP 'cat /var/run/syslog.pid'
4.
5.
6.
Once logging is enabled, run the HP-UX commands or applications that exhibit the problem.
Disable logging by commenting out the log_facility and log_level lines in the startup file /etc/
opt/ldapux/ldapux_client.conf. Comment them out by inserting a "#" symbol in the
first column.
Examine the log file at /var/adm/syslog/local0.log to see what actions were performed
and if any are unexpected. Look for functions with "ldap_." These are standard LDAP function
calls.
7.13 Troubleshooting
251
TIP: Enable LDAP logging only long enough to collect the data you need because logging can
significantly reduce performance and generate large log files.
You could move the existing log file and start with an empty file:
mv /var/adm/syslog/local0.log /var/adm/syslog/local0.log.save
Restart the syslogdaemon with the following command (for more information about this command,
see the see the syslogd(1M) manpage):
kill -HUP 'cat /var/run/syslog.pid'
7.13.2 Enabling and disabling PAM logging
When something is behaving incorrectly, enabling logging is one way to examine the events that
occur to determine where the problem is. Enable PAM logging on a particular client as follows.
For more information about PAM, see the pam(3) and pam.conf(4) manpages. In addition, see
the document Managing Systems and Workgroups: A Guide for HP-UX System Administrators at
the following location:
www.hp.com/go/hpux-core-docs (click HP-UX 11i v2)
1.
To each line in /etc/pam.conf that contains the libpam_ldap.so.1 library, add the
debug option as in the following example:
login account sufficient
login account required
su
account sufficient
su
account required
...
/usr/lib/security/libpam_unix.so.1
/usr/lib/security/libpam_ldap.so.1 debug
/usr/lib/security/libpam_unix.so.1
/usr/lib/security/libpam_ldap.so.1 debug
WARNING! Enabling the debug option in pam.conf might enable hackers to gain additional
information that would enable them to crack password security. For example, they could
attempt to log in as a super user (su) and discover that a password has expired (observing
the super user's behavior, the hackers could determine when he or she is likely to log in next).
2.
Edit the /etc/syslog.conf file and add a new line at the bottom, such as the following:
*.debug
3.
<tab> /var/adm/syslog/debug.log
Restart the syslog daemon with the following command (for more information about this
command, see the syslogd(1M) manpage):
kill -HUP 'cat /var/run/syslog.pid'
4.
5.
6.
Once logging is enabled, run the HP-UX commands or applications that exhibit the problem.
Restore the /etc/syslog.conf file to its previous state; otherwise, you might unintentionally
enable logging in other applications.
Restart the syslog daemon with the following command:
kill -HUP 'cat /var/run/syslog.pid'
7.
8.
Remove the debug options from /etc/pam.conf.
Examine the /var/adm/syslog/debug.log log file to see what actions were performed
and if any are unexpected. Look for lines containing "PAM_LDAP".
252 Administering LDAP-UX Client Services
TIP: Because logging can significantly reduce performance and generate large log files, enable
PAM logging only long enough to collect the data you need.
You could move the existing log file and start with an empty file:
mv /var/adm/syslog/debug.log /var/adm/syslog/debug.log.save
Then restore the file when finished.
Restart the syslog daemon with the following command:
kill -HUP 'cat /var/run/syslog.pid'
7.13.3 Viewing log files for errors and unexpected events
You can view log files to see if any unusual events have occurred with your directory.
HP-UX Directory Server log files
The HP-UX Directory Server logs information to files under
/var/opt/dirsrv/slapd-<serverID>/log, where slapd-<serverID> is the name of your
directory server.
The error logs contain startup, shutdown, and unusual events. The access logs contain all requests.
For more information, see the HP-UX Directory Server administrator guide.
Windows ADS service log files
You can view Active Directory event log files using the Windows 2003 R2 or 2008 Event Viewer.
To start the viewer, select Start→Programs→Administrative Tools→EventViewer.
7.13.4 Troubleshooting user problem with client system logins
If a user cannot log in to a client system, perform the following tests:
•
To verify that NSS is working, you can use the pwget -n command (for more information,
see the pwget(1) manpage) or the nsquery3 command, as in the following examples:
pwget -n username
nsquery passwd username
If the output shows LDAP is not being searched, verify that LDAP is specified in the /etc/
nsswitch.conf file. If username is not found, make sure that the user is in the directory
and, if using a proxy user, make sure the proxy user is properly configured.
If nsquery displays the user's information, make sure /etc/pam.conf is configured correctly
for LDAP (for more information about configuring the /etc/pam.conf, see “Sample PAM
configuration (pam.conf) files ” (page 420)). If /etc/pam.conf is configured correctly,
examine the directory's policy management status. It could be the directory's policy
management is preventing the bind because, for example, the user's password has expired
or the login retry limit has been exceeded. Use the commands suggested in the following
examples.
If you cannot bind as the user, determine whether any directory policies are preventing access.
Determining the policy management status for an HP directory server user
Use an ldapsearch command and bind as the user. For example, the second command
line in the following example obtains the DN of the user, while the third line verifies the policy
management status of that user:
cd /opt/ldapux/bin
./ldapsearch -h servername -b "baseDN" uid=username
./ldapsearch -h servername -b "baseDN" -D "userDN" -w passwd
uid=username
3. nsquery is a contributed tool included with the ONC/NFS product. For more information, see the nsquery(1) manpage.
7.13 Troubleshooting 253
In this command example, servername is the name of the directory server, baseDN is the
base distinguished name of where to start searching, userDN is the DN of the user who cannot
log in, and username is the login name of the user.
Determining the policy management status for a Windows ADS user
Similarly, for Windows ADS, enter the following commands:
cd /opt/ldapux/bin
./ldapsearch -h servername -b "baseDN" \
unixName=username -D userDN -w passwd
./ldapsearch -h servername -b "baseDN" -D "userDN" -w passwd
unixName=username
where servername is the name of the server, baseDN is the base distinguished name of
where to start searching (such as CN=Users,DC=accounting-dept,DC=acme,DC=com),
userDN is the DN of the user who cannot log in, and username is the login name of the
user.
•
Display the current configuration profile and ensure that all the values are as you expect:
cd /opt/ldapux/config
./display_profile_cache
In particular, examine the values for the directory server host and port, the default search base
DN, and the credential level. Also, if you have remapped any standard attributes to alternate
attributes, or defined any custom search descriptors, make sure these are correct and exist in
your database. If any of these are incorrect, correct them as described in Section 7.10.2
(page 245).
•
•
If you are using a proxy user, verify the proxy user configuration, as described in Section 7.9.2
(page 242).
Make sure the client system can authenticate to the directory and find a user in the directory
by searching a user's information in the directory. Use the ldapsearch command and
information from the current profile.
If you are using a proxy user (determined by the credentialLevel attribute in the
configuration profile), try searching as the proxy user for a user's information in the directory.
Searching as the proxy user for an HP directory server user's information
For an HP directory server, use a command similar to the following:
cd /opt/ldapux/bin
./ldapsearch -h servername -b "baseDN" -D "proxyuser" -w
passwd uid=username
where servername is the name of your directory server (from display_profile_cache),
baseDN is the search base DN (from display_profile_cache), proxyuser is the proxy
user (from ldap_proxy_config -p), and username is a name of a user in the directory.
For example:
cd /opt/ldapux/bin
./ldapsearch -h sys001.hp.com -b "ou=people, o=hp.com" \
-D "uid=proxyuser,ou=special users,o=hp.com" -w passwd uid=steves
You should get output similar to the following:
dn: uid=steves,ou=people o=hp.com
uid: steves
cn: Steve Sy
objectclass: top
objectclass: account
objectclass: posixAccount
loginshell: /bin/ksh
uidnumber: 2875
gidnumber: 191
homedirectory: /home/steves
gecos: Steve Sy, building 5, x50
254 Administering LDAP-UX Client Services
If you do not see such output, your proxy user might not be configured properly. Make sure
you have access permissions set correctly for the proxy user. For more information about
configuring the proxy user, see Section 2.4.4 (page 65).
You can also try binding to the directory as the directory administrator and reading the user's
information.
If you are using anonymous access, (determined by the value of the credentialLevel
attribute in the configuration profile), try searching for one of your user's information in the
directory with a command like the following:
./ldapsearch -h servername -b "o=hp.com" uid=username
using the name of your directory server (from display_profile_cache), search base DN
(from display_profile_cache), and a user name from the directory.
You should get output similar to the previous example. If you do not, anonymous access might
be configured incorrectly. Make sure you have access permissions set correctly for anonymous
access. For more information about configuring anonymous access for an HP directory server,
see Section 2.4.4 (page 65).
Searching as the proxy user for a Windows ADS user's information
The following command example shows how to search as the proxy user for a specific Windows
ADS user's information:
cd /opt/ldapux/bin
./ldapsearch -h servername -b "baseDN" -D "proxyuser" -w passwd unixName=username
where servername is the name of your directory server (from display_profile_cache),
baseDN is the search base DN (from display_profile_cache), proxyuser is the proxy
user (from ldap_proxy_config -p), and username is a name of a user in the directory.
For example:
cd /opt/ldapux/bin
./ldapsearch -h sys001.hp.com -b -D "CN=proxyuser,CN=users,DC=accts,DC=acme,DC=com" -w passwd \
unixName=biljonz
You should get output similar to the following:
dn: CN=John R Bill
Jones,CN=Users,DC=cup,DC=hp,DC=com
accountExpires: 9223372036854775807
badPasswordTime: 0
badPwdCount: 0
codePage: 0
cn: John R Bill Jones
countryCode: 0
instanceType: 4
lastLogoff: 0
lastLogon: 0
logonCount: 0
distinguishedName: CN=John R Bill Jones,CN=Users,DC=cup,DC=hp,DC=com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=cup,DC=hp,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectGUID:: m0weqe/tykmLX1yw8Y/QZw==
objectSid:: AQUAAAAAAAUVAAAAEZm5eELHdFIVJa9HtgYAAA==
primaryGroupID: 513
pwdLastSet: 0
name: John R Bill Jones
sAMAccountName: biljonz
sAMAccountType: 805306368
userAccountControl: 546
uSNChanged: 15284
uSNCreated: 15283
whenChanged: 20001222132148.0Z
whenCreated: 20001222132148.0Z
gecos: John R Bill Jones,6394,DEV
gidNumber: 1771
7.13 Troubleshooting 255
loginShell: /bin/ksh
unixHomeDirectory: /tblv006/home/biljonz
unixName: biljonz
syncNisDomain: cup
uidNumber: 467
If you do not get similar output, your proxy user might not be configured properly. For more
information about configuring the proxy user for a Windows ADS, see Section 3.4.5 (page 135).
What to do when the proxy user cannot read POSIX information
There could be several reasons why the proxy user is not able to read user and group information
using the previously-described troubleshooting steps. If the previously-described steps fail, try these
steps:
•
Try the ldapsearch command described previously (to search as the proxy user for HP
directory server or Windows ADS user information), replacing the proxy credential with an
administrator's credential. If you are able to discover user information using an administrator's
credential, then check the following:
◦
Verify that you have the correct password for the proxy user. The ldapsearch command
reports an error if you have an invalid password.
◦
Verify whether the proxy account has an expired password or expired account. The
ldapsearch command also reports an error if the account has expired or has an expired
password. If the account is expired or has an expired password, you might need to alter
the security policy for this account. Use your directory server management utilities to set
the proxy user account.
◦
If ldapsearch succeeds but returns no data, use the proxy account to search the rootDSE
using the following commands to search the rootDSE to verify that you are binding to the
correct directory server and to determine whether any information can be returned. The
hostname is the name of the host, proxyuser is the name of the proxy user account,
and password is the proxy user's password.
cd /opt/ldapux/bin ./ldapsearch -h hostname -b "" -s base "(objectclass=*)"
-D "proxyuser" -w password namingcontexts
\
If this command does not return a namingcontexts attribute, or the value of the
namingcontexts attribute does not contain the expected base DN, verify you are
connecting to the proper directory server.
◦
Verify the proxy user has sufficient privilege to read these POSIX attributes:
cn
loginshell
uid
uidnumber
gidnumber
homedirectory (nonWindows only)
gecos
unixHomedirectory (Windows ADS only)
msSFU30Aliases (Windows only)
◦
Determining access control rights for the proxy user account requires understanding the
security policy of the directory server and the access control instructions used to protect
that information. To determine how to adjust your access control settings to give sufficient
rights to access POSIX account information, consult your vendor-specific directory server
administrator guide . For a full list of attributes that must be accessible to the proxy user,
use the /opt/ldapux/config/display_profile_cache command and review
the "is mapped to:" attributes.
256 Administering LDAP-UX Client Services
•
Enable PAM logging as described in Section 7.13.2 (page 252) then try logging in again.
Examine the PAM logs for any unexpected events.
•
Enable LDAP-UX logging as described in Section 7.13.1 (page 251), then try logging in again.
Examine the log file for any unexpected events.
7.13 Troubleshooting 257
8 Managing ssh host keys with LDAP-UX (HP directory
servers only)
Managing ssh host keys with LDAP-UX is supported in HP directory server environments only.
LDAP-UX B.05.00 introduces management of host attributes in the directory server. One of the
features integrated with host management is using an LDAP directory server as a trusted repository
for a host’s ssh public key.
ssh is a great protocol for both protecting data in transit (using encryption), and for validating trust
between two parties. However, establishing that trust relationship is a weak aspect of the default
ssh toolset. In order for two parties to securely communicate and identify each other, each must
know a shared secret, known only to each other, or they must know some other piece of public
information that can be used to prove the identity of the remote party. With ssh, both methods are
often used, such as using public keys to identify remote hosts.
However, as with all secure methods of communication, how are these secrets or public keys
initially shared? There’s always a bootstrapping problem to preestablish trust between parties. The
base ssh toolset leaves this exercise to the end users. In some organizations, administrators can
attempt to predistribute public keys of hosts within their organizations. But this often leads to a
scalability problem as the number of hosts in an organization increases. And as more services are
moving to virtualized hosts, this can become a significant cost to manage.
With LDAP-UX B.05.00, ssh key management can be centralized in a trusted directory server,
eliminating the need for end users to make decisions about the trustworthiness of a remote host
and greatly mitigating the scalability issue, compared with distributing keys manually.
8.1 Overview
The following sections provide an overview of managing ssh host keys with LDAP-UX.
8.1.1 How it works
As previously mentioned, in a basic ssh deployment, each user must to determine if a remote host
should be trusted. When establishing a session with a remote host for the first time, the user is
presented with a prompt. This prompt displays a “fingerprint” for the remote host’s public key and
asks if the user still wants to connect, and if the key should be trusted and placed in the user's
personal known_hosts file. Given the average user’s motivation to continue working and limited
ability to determine if the remote host’s fingerprint is correct, users frequently just reply yes to the
prompt, uncertain if the remote host is the true host, or if there's a risk of a man-in-the-middle attack.
Starting with LDAP-UX B.05.00 and HP Secure Shell A.05.50 or later, this burden on the end user
is removed. By managing host and public key information in the directory server, ssh itself can
verify the correctness of the remote public key, and therefore determine if a trusted connection can
be established. And given that private information often travels across this connection, that trust is
critical.
When LDAP is used as a repository for managing ssh host keys, the infrastructure shown in Figure 16
(page 259) is established:
258 Managing ssh host keys with LDAP-UX (HP directory servers only)
Figure 16 ssh host key management infrastructure
LDAP Server
Host A
LDAP-UX
Host A
Host B
ssh key
ssh key
Host B
ldaphostmgr
sshd
ssh
ssh key
The LDAP directory server includes an SSL certificate. The LDAP-UX library of Host A has a copy
of that certificate. When ssh attempts to validate the public key of the remote host Host B, it connects
through a library in LDAP-UX. LDAP-UX is configured to securely communicate with the LDAP
directory server and to discover keys for the requested hosts. LDAP-UX utilities such as ldaphostmgr
and ldaphostlist can be used to manage those keys in the directory server, from any host
configured with LDAP-UX (such as Host B, in the figure). Those utilities can also manage information
about any remote host, including the ability to replace or update its keys.
8.1.2 Secure framework
For ssh to determine if the remote host is trusted, ssh must know about the remote host’s private
key so it can compare that key with the key presented when ssh connects with the remote host.
The toolset normally stores these keys in either a host-local known_hosts file (/opt/ssh/etc/
ssh_known_hosts) or in the user’s personal known_hosts file. To avoid allowing users to
make decisions whether a remote host should be trusted, some administrators try to predistribute
these keys periodically to the host-local ssh known_hosts file. However, this process encounters
scalability problems as the number of hosts grows.
To eliminate this distribution process, the LDAP directory server can be used to store and manage
host public keys in a central repository. And LDAP-UX offers tools to manage this information, either
centrally or on each host being managed.
Because the LDAP repository contains the public keys of the hosts, the LDAP directory server itself
must be trusted to assure that the user can trust the remote host’s identity. The information stored
in that directory server must also be trusted. Fortunately, LDAP directory servers meet this requirement
well. LDAP directory servers have authentication and access control frameworks that can be used
to protect data managed in the directory server and that can help assure the data's validity.
In addition, LDAP directory servers support the SSL/TLS protocol, which can be used to protect
communication with the directory server and, more importantly, to assure the integrity of the data
transmitted from the directory and validate the identity of the directory server itself. While a CA
(certificate authority) certificate, or a certificate of the directory server itself, is still required to be
distributed to each host, distribution of a single CA certificate is a much more manageable task.
Instead of every user on every host having to validate trust with every other host connected to,
each host needs to trust only one thing: the directory server. With the LDAP-UX guided installation,
8.1 Overview 259
and the HP-UX Directory Server, setting up this trust framework is nearly automatic (for more
information about this trust framework, see Section 2.3.2.3 (page 37)). When using the guided
installation, LDAP-UX generates a server certificate software depot file. This depot file can be
installed on each host being managed, and once installed, will establish trust with that central
directory server.
As a depot file, this certificate can be predistributed as part of an OS installation image, combining
the installation and trust setup processes into a single step. In Figure 17 (page 260), an HP-UX Ignite
server is shown with an HP-UX image and CA certificate. This certificate is distributed automatically
to all hosts (this figure shows hosts named Host A and Host B) to establish trust with the LDAP
directory server shown. This directory server stores and manages the host public keys for Host A
and Host B.
Figure 17 ssh host key management trust framework
LDAP Server
HostA
Ignite-UX Server
HostB
LDAP-UX domain
CA certificate
Host A
Host B
Including the LDAP_UX domain CA certificate in
installation images allows OS instances to preestablish direct trust with the directory server
and indirectly with all other OS instances.
LDAP-UX uses the sshPublicKey attribute as part of the ldapPublicKey object class to manage
ssh public keys in the directory server. The ldapPublicKey object class is an auxiliary object
class, which can be attached to host entries in the LDAP directory server. Because hosts accessible
through the ssh protocol have an IP address, the ipHost structural object class is used to instantiate
this host information in the directory server.
The following example shows an example of a host entry, displayed in LDIF format:
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
objectClass: top
objectClass: device
objectClass: ldapPublicKey
objectClass: iphost
objectClass: domainEntity
sshPublicKey: ssh-rsa AAAAB3Nza...
sshPublicKey: ssh-dss AAAAB3Nza...
sshPublicKey: 1024 35 140898...
owner: uid=domadmin,ou=people,dc=mydomain,dc=example,dc=com
ipHostNumber: 16.92.96.116
cn: hptem079
260 Managing ssh host keys with LDAP-UX (HP directory servers only)
8.1.3 Permissions
The LDAP-UX host management tool (ldaphostmgr), which is used to manage ssh public keys in
the directory server, manipulates the aforementioned object classes and attributes. This tool relies
on the directory server to provide proper access control.
To assure that only authorized modifications to the host and public key information is performed,
only a restricted set of privileged users should be allowed to modify host information, including
the sshPublickKey attribute. If you have used the guided installation and, as part of that setup
process, created a new HP-UX Directory Server Instance, these access controls are automatically
created (for more information about the access controls established by the guided installation, see
Section 2.3.2.3 (page 37)).
Several sets of users are considered privileged enough to manipulate host information in the
directory server, including the DomainAdmins group, the HostAdmins group, or the owners
(owners are any users or members of a group that are listed in the owner attribute in the host’s
entry.) These users, or any user that has rights to manipulate the sshPublicKey attribute for the
host in the directory server, will be granted permission on the HP-UX host to change the ssh key
pairs of the host. Normally, the permission to modify the host’s public and private ssh keys is
restricted to the root user. However, the ldaphostmgr will elevate its privilege to allow nonroot
users to modify a host’s public key if that user has permission to modify the sshPublicKey
attribute for the current host.
If a user runs the ldaphostmgr tool and attempts to change a host’s ssh key, ldaphostmgr will
verify if the user has the right to modify the sshPublicKey for that host. If the directory server
rejects this modification, ldaphostmgr will not elevate its privilege and not modify the host’s ssh
key.
8.1.4 Distributed management (manage from any host)
Remote management is an important feature of the ldaphostmgr tool. Specifically, if LDAP-UX
version B.05.00 or later is installed on a remote host that is part of the same LDAP-UX domain
(subscribes to the same LDAP-UX configuration profile) as the current host, it is possible to remotely
manage ssh keys on that host. As long as the current user has permissions to log in to the remote
host and to manipulate the sshPublicKey attribute, the ldaphostmgr tool can change the key
of any host in the LDAP-UX domain from any other host. This remote management is handled within
ldaphostmgr itself. The user need not remotely log in to the host to manage it.
However, this means that any user with permission to manage the sshPublicKey attribute, must
also be a user with POSIX attributes attached (the posixAccount object class), such that the HP-UX
OS will allow remote login for this user. For more information about setting up an ssh key manager
account, see Section 8.2.6 (page 264).
8.2 Setting up the key management domain
The first step in setting up an ssh key management domain is to establish the host and key data
repository. This repository must be an LDAP directory server and must meet the security requirements
previously defined, and explained in additional detail in the subsections that follow. If you have
not already targeted a directory server to act as this repository, you should consider using the
LDAP-UX guided installation (autosetup), which will automatically create a new directory server
instance, if desired. This directory server instance creates a default security and management
framework. For more information about the guided installation, see Section 2.3 (page 27).
The remaining subsections describe this process, summarized as follows:
•
Identify a directory server and a location in that directory server where host and key data will
be stored.
•
Assign and set up an SSL certificate for the directory server, so that trust can be established
between clients and the directory server.
8.2 Setting up the key management domain
261
•
Define authentication and access control, such that a limited set of privileged users will have
the ability to manage host and ssh key data in the directory server.
•
Install a CA or server certificate in the /etc/opt/ldapux/cert8.db file. This can be done
using /opt/ldapux/bin/certutil, or by installing the auto-generated LDAP-UX domain
CA depot (created with the guided installation).
•
Configure LDAP-UX on all host clients. ssh communicates through LDAP-UX to securely connect
with the directory server and discover the location of the host and key information. Be sure to
configure SSL, which is the default with a guided installation.
•
Configure the ssh client to use LDAP for key discovery. This simply requires enabling the feature
by setting flags in the /opt/ssh/etc/ssh_config and /opt/ssh/etc/sshd_config
files. HP Secure Shell A.05.50 or later is required.
•
Optionally, define a central ssh configuration, using the LDAP-UX central configuration service.
This service will enable you to centrally manage ssh configuration and will distribute that
configuration to all LDAP-UX enabled clients that are part of the same LDAP-UX domain.
8.2.1 Host repository
To centrally manage host keys, a central repository must be defined to store that information. For
clients to discover host keys, they must know the location of the repository and must trust that
repository and the data managed within it. The following subsections describe how ssh clients can
identify and trust that repository.
8.2.2 Data location
To centrally manage ssh keys for hosts, information about these hosts must be stored in the directory
server. Choose a location in the directory information tree where these hosts will reside. That
location should be within the scope of the base DN specified when you configured LDAP-UX (see
“Installing and configuring LDAP-UX Client Services for an HP server environment” (page 25) for
HP directory server environments and “Installing and configuring LDAP-UX Client Services for a
Windows ADS environment” (page 114) for Windows ADS environments). If you have used a
guided installation to create your directory server instance, that location will be ou=hosts,suffix,
where suffix is the root of your directory server data. If you have already configured LDAP-UX,
then you can use the ldapcfinfo tool to determine where LDAP-UX believes host information
should be located.
Example:
# /opt/ldapux/bin/ldapcfinfo -t hosts -b
ou=Hosts,dc=mydomain,dc=example,dc=com
If the base DN discovered previously is not the desired location within the directory tree, you can
reconfigure the LDAP-UX profile using the steps outlined in Section 7.10.2 (page 245).
8.2.3 Trust
Trust between an ssh client and a remote host depends on the ability of the client to validate the
identity of the remote host, and vice versa. As previously mentioned, this requires the ssh client to
have access to the public key of the remote host. It needs that key to validate the key presented
by the remote host when the initial connection is made. Traditionally, this key is stored in the
known_hosts file on the local client’s host. This file is under the control of the user himself, in the
~/.ssh/known_hosts file, or a system administrator might have put a list of hosts in the /opt/
ssh/etc/ssh_known_hosts file. This file is assumed to be secured. Proper files system
permissions are set to prevent unauthorized modification.
When the ssh public key is managed in the directory server, the integrity of the sshPublicKey
attribute must be assured to achieve that same level of trust. Just as the user can trust his own
known_hosts file or the ssh known_hosts file set up by his administrator, the user must also
be able to trust the integrity of the sshPublicKey attribute when managed in the directory server.
262 Managing ssh host keys with LDAP-UX (HP directory servers only)
Trusting the ssh key repository requires that the identity of the directory server can be validated,
the data in the directory server cannot be modified by unauthorized users, and the data transmitted
between the client and the directory server is protected. The following three sections describe how
to establish this trust.
8.2.4 Validating directory server identity
Just as a web browser uses SSL and SSL CA certificates to identify the validity of a remote web
server when verifying that a user is sending credit card information to a legitimate organization
instead of an impostor, the LDAP directory server can use the same SSL protocol and certificates
to validate the identity of the directory server. To establish this trust, a directory server must have
a valid signed server certificate, and the client must have a copy of the public portion of that server
certificate, or a CA (Certificate Authority) certificate of the CA that signed the server’s certificate.
When using the guided installation script to create a new HP-UX Directory Server instance, LDAP-UX
automatically creates a CA certificate and server certificate for that directory server instance. The
CA certificate is deposited into an SD depot file that can be preinstalled on any HP-UX client. For
more information about this depot file see Section 2.3.2.3.3 (page 39). . If you have this depot
file, you can install this package on your host with the following command:
# /usr/sbin/swinstall -s hostname:/depot/name LDAPUX-DOMAIN-CA
If you have your own CA certificate (not created using the guided installation), you can install that
CA certificate in the /etc/opt/ldapux/cert8.db file as in the following example:
# more /tmp/mycacert.txt
-----BEGIN CERTIFICATE----MIIBlzCCAQCgAwIBAgICBKIwDQYJKoZIhvcNAQEFBQAwETEPMA0GA1UEAxMGQ0Fj
ZXJ0MB4XDTEwMDEwODIxNDA0OVoXDTIwMDEwODIxNDA0OVowETEPMA0GA1UEAxMG
Q0FjZXJ0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8yROkmsMiCIhgki2V
Sk3iJr2SXATnvp/Bmn5p9i2PVjlk63rvJFvyEDYM40TxZmArptMXq4WsfAy4fOMB
KY+yJKK53qc+fQ8k5YERL93RWugBs7SqVhNOtWRPZWcBUNHM7tCywtI1RzbZn8sp
hAOofPPiGVvmhUYrk05Y6UY07wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAGhaRyvK
Qx5EoIVzE6iVdlEU0wopr33qVpHyEYoqDdziy0cLhqGbVKEzCaM83sdW7S9Cxe87
pr+31xbgJgXbO7kNP3cZytNcd1A7Grc0EmVb8yck+uWx7Oj2CYkac0DboWAn/uhU
hxbIaqFdC+gninQ9ECNEnUFt0hJ6SSNhYWUW
-----END CERTIFICATE----# /opt/ldapux/contrib/bin/certutil -A -d /etc/opt/ldapux -a -n "my CA Certificate" -a -t "CT,," < /tmp/mycacert.txt
Attempting to use ssh key management without using SSL provides little value, because if the
directory server can be impersonated, then the validity of the sshPublicKey attribute cannot be
trusted, and thus the identity of any remote ssh hosts cannot be validated.
Configuring the directory server with a server certificate also enables it to use SSL. This protocol
enables information in transit to be protected from eavesdropping, but even more importantly,
from tampering by a man-in-the-middle. Support for SSL meets two of the previous requirements to
assure integrity of the sshPublicKey. And when LDAP-UX is configured using the guided installation,
SSL is automatically configured. (For more information about the guided installation, see Section 2.3
(page 27).)
8.2.5 Authentication and access control
To assure its integrity, the sshPublicKey attribute must be protected from unauthorized
modification. LDAP directory servers have the inherent ability to authenticate users before allowing
access and to limit operations performed on the LDAP data with access-control policies.
As mentioned previously, any user with permission to modify the sshPublicKey attribute for a
particular host can also change the ssh key pair of that host using ldaphostmgr. This means that
permission to modify the sshPublicKey attribute must be restricted to trusted administrators. The
trust relationship between users and hosts is based on the ability to protect the integrity of the
sshPublicKey attribute in the directory server.
To allow for management of the sshPublicKey, you must grant rights to a group of administrators.
This process is different for each directory server deployment because access control features of
directory servers are different and have not yet been standardized. For the HP-UX Directory Server
(the Red Hat Directory Server and Sun Java Directory Server are similar), the ACI attribute must
8.2 Setting up the key management domain 263
be used to define this policy. The following example shows how anyone listed as an owner of a
host, a Domain Administrator, or host administrator is allowed to modify the sshPublicKey
attribute. This ACI is automatically created if you create a new directory server instance using the
guided installation.
dn: dc=mydomain,dc=example,dc=com
aci: (targetattr = "*")(version 3.0;acl "[DOMAINADMIN:ALL:ALL]: Allow changes
by Domain Administrators";allow (all) (groupdn = "ldap:///cn=DomainAdmins
,ou=Groups,dc=mydomain,dc=example,dc=com");)
dn: ou=Hosts,dc=mydomain,dc=example,dc=com
aci: (targetattr = "sshPublicKey || ipHostNumber") (version 3.0;acl "[OWNER:WR
ITE:HOSTOWNERATTRS]: Allow owner modification of host information";allow (re
ad,compare,search,write,delete,add) userattr = "owner#USERDN";)
aci: (targetattr = "objectclass || cn || dn || owner || host || ipHostNumber |
| ipNetmaskNumber || ipNetworkNumber || ipProtocolNumber || ipServicePort ||
ipServiceProtocol || sshPublicKey || oncRpcNumber || userPassword || userCe
rtificate" )(version 3.0;acl "[HOSTADMIN:READ-WRITE:HOSTATTRS]: Allow change
s to Unixattributes by Host Administrators";allow (all) (groupdn = "ldap:///
cn=HostAdmins,ou=Groups,dc=mydomain,dc=example,dc=com");)
8.2.6 Administrative users
Any user with the right to modify the sshPublicKey attribute for a host is considered an ssh key
administrator. As seen from the rights in the previous example, anyone that is a member of the
DomainAdmins or HostAdmins groups or is listed as the owner (the owner attribute has the
DN of the user), is considered an ssh key administrator. As mentioned previously, to protect the
integrity of the sshPublicKey attribute, this list of users should be restricted to trusted
administrators.
In addition to creating a trusted list of administrators, ldaphostmgr allows for management of
keys not only on the local host, but also on any remote host that is a member of the same LDAP-UX
domain (uses the same LDAP-UX configuration profile). However, for remote administration to
function, the administrators’ accounts must also be assigned POSIX account attributes (this is not
required if remote administration is not desired.)
You can create an administrator that has the rights to manage ssh public keys using the ldapugadd
and ldapugmod utilities, as in Example 13the following example:
Example 13 Creating an administrator that has the rights to manage ssh public keys
1.
Create the new account using ldapugadd:
# /opt/ldapux/bin/ldapugadd -P -f "Alice Bobson" abobson Surname=Bobson
# /opt/ldapux/bin/ldapuglist -n abobson
dn: uid=abobson,ou=people,dc=mydomain,dc=example,dc=com
cn: Alice Bobson
uid: abobson
uidNumber: 3840
gidNumber: 20
loginShell: /usr/bin/sh
homeDirectory: /home/abobson
gecos: Alice Bobson
2.
Add the user to one of the privileged groups (HostAdmins in this case):
# /opt/ldapux/bin/ldapugmod -P -t group -a abobson HostAdmins
# /opt/ldapux/bin/ldapuglist -t group -n HostAdmins
dn: cn=HostAdmins,ou=Groups,dc=mydomain,dc=example,dc=com
cn: HostAdmins
memberUid: domadmin
memberUid: abobson
If you already have users that are considered administrators, but do not have posixAccount
information attached to their directory server entries, you can use the ldapugmod command to
264 Managing ssh host keys with LDAP-UX (HP directory servers only)
extend their accounts with POSIX attributes. The following example shows how to extend
posixAccount attributes to an existing user:
Example 14 Extending administrator accounts with posixAttributes
1.
Identify the account to extend:
# /opt/ldapux/bin/ldapuglist -F "(cn=bob alison)" \*
dn: cn=Bob Alison,ou=people,dc=mydomain,dc=example,dc=com
cn: Bob Alison
gecos: Bob Alison,+1-303-555-5432
2.
Add posixAccount attributes using the -O option of ldapugmod:
# /opt/ldapux/bin/ldapugmod -P -O -n balison -u 1234 -g users -d /home/balison \
-s /usr/bin/sh -D "cn=Bob Alison,ou=people,dc=mydomain,dc=example,dc=com"
# /opt/ldapux/bin/ldapuglist -n balison \*
dn: cn=Bob Alison,ou=people,dc=mydomain,dc=example,dc=com
cn: Bob Alison
uid: balison
uidNumber: 1234
gidNumber: 20
loginShell: /usr/bin/sh
homeDirectory: /home/balison
gecos: Bob Alison,+1-303-555-5432
If Bob Alison is not already a member of a privileged group, then you can add him as a member
of the Host Administrators group, using a similar command as in the previous example:
/opt/ldapux/bin/ldapugmod -t group -P -a balison HostAdmins
NOTE: In the previous examples, the HostAdmins group is a posixGroup. By default, the
ldapugmod tool only works with posixGroups. However, you can still use ldapugmod to modify
non-posixGroups if your LDAP-UX profile specifies LDAP-style attribute mapping for LDAP-style
groups, and you use the -D option to specify the full DN of the group you want to manage.
If you use groupOfUniqueNames for your LDAP-style groups, then your attribute mapping for group
membership as defined in the LDAP-UX configuration profile should be:
attributemap: group:memberUid=uniqueMember member memberUid
If you use groupOfNames for your LDAP-style groups, then your attribute mapping for group
membership as defined in the LDAP-UX configuration profile should be:
attributemap: group:memberUid=member uniqueMember memberUid
To modify a non-posixGroup, you must use the -D option when specifying the group to modify.
For example, assume in the following that cn=Host Administrators is a groupOfNames, but
not a posixGroup. It is possible to add balison as a member using the previously-described
attributeMap and the following command:
/opt/ldapux/bin/ldapugmod -t group -P -a balison \
-D "cn=Host Administrators,ou=Groups,dc=mydomain,dc=example,dc=com"
8.3 Managing keys in the directory server
If you have not yet set up a directory server to manage your host information, you can use the
LDAP-UX guided installation (autosetup) to create a new directory server and configure LDAP-UX
to manage hosts in that directory server. The guided installation sets up an environment that meets
the host repository requirements described in the previous section.
After you establish a repository and security framework for your host information, as described in
the previous section, you can begin to manage those hosts. The remainder of this section describes
how to properly configure HP-UX hosts to use the central repository for ssh keys and how to manage
the hosts and their keys.
8.3 Managing keys in the directory server 265
8.3.1 Configuring ssh and sshd to use LDAP-managed keys
On each HP-UX client that is to use LDAP-based ssh public keys, you must install version A.05.50
or later of the HP Secure Shell product and LDAP-UX version B.05.00 or later. HP Secure Shell
A.05.50 or later is enabled to use the LDAP directory server for public key validation and is
dependent on APIs provided in LDAP-UX B.05.00.
You must configure the ssh toolset to use LDAP. To do this, configure the following two new
parameters in the ssh_config file:
•
UseLdapHostKey
Directs the ssh client tools (ssh, scp, sftp) to use the LDAP repository to discover a remote host’s
public key, if that key is not already found in the known_hosts file.
•
UpdateKeyFromLdap
Directs the ssh client tools to update the known_hosts file if the key for the specified host
does not exist or is incorrect. The key from the LDAP directory server is assumed to be correct,
based on the previously described trust agreements between the ssh client and the directory
server. If the local user has a key that does not match the one found in the directory server
file, the ssh client replaces it in the user’s personal known_hosts file. Using the
UpdateKeyFromLdap option enables the user’s known_hosts file to act as a local cache
for the information in the directory server.
NOTE: If you want the ability to revoke or remove keys for hosts (in case those keys are
compromised), do not enable the UpdateKeyFromLdap option. See Section 8.3.8 (page 271) for
additional information.
In the sshd_config file, only the UseLdapHostKey option is available. This option has the same
effect as in the ssh_config file. It is used when administrators want to configure host-based
authentication, using the HostBasedAuthentication option. In this case, sshd uses the LDAP directory
server to validate the identity of a remote host on an incoming connection. (See Section 8.2.5
(page 263)).
With LDAP-UX B.05.00 or later, it is possible to centrally manage ssh and sshd configuration
parameters using the LDAP-UX central configuration service; for more information, see Section 8.5
(page 272).
After completing this step, you have completed the setup process and can now begin to manage
keys for hosts using the steps described in the following subsections.
8.3.2 Adding keys for HP-UX hosts
Use the -k option of the ldaphostmgr command to add or manage public keys for hosts. There
are several ways to add or change ssh public keys in the directory server using this option. This
section and the sections that follow describe these various methods.
If you use the guided installation when configuring LDAP-UX on a host, during the configuration
process the current host and its RSA public key are automatically added to the directory server.
You can display the entry for the current host using the following commands:
chef(): ldaphostlist -k -n "$(hostname)"
dn: cn=chef,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: chef
cn: chef.mydomain.example.com
ipHostNumber: 16.92.96.225
sshPublicKey: ssh-rsa AAAAB...== BEGIN-KM creationtime=20100413173637Z END-KM
Notice in the preceding command sequence that keys managed by ldaphostmgr have an
extended field within the comment structure of the public key data. This extended field can be used
to determine key age and keep track of expiration information if desired. See Section 8.4.2
(page 272) for additional information.
266 Managing ssh host keys with LDAP-UX (HP directory servers only)
If you did not configure LDAP-UX on the current host using the guided installation, you might not
have an entry in the directory server that represents the current host. In that case, you can add the
host using the -a option of the ldaphostmgr command as follows:
brewer(): id
uid=8507(domadmin) gid=220(ldap) groups=88(DomainAdmins)
brewer(): ldaphostmgr -a -f -k rsa "$(hostname)"
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
brewer(): ldaphostlist -k -n "$(hostname)"
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
cn: brewer.mydomain.example.com
ipHostNumber: 16.92.96.225
sshPublicKey: ssh-rsa AAAA...== BEGIN-KM creationtime=20100423234903Z END-KM
In this example, the -a option is used to indicate that the host should be added as a new entry to
the directory server. The -f option indicates that the fully qualified domain name should be added.
And the -k option indicates the RSA (protocol version 2) key should be added. Other key types
can be used. The -k option also accepts rsa1, dsa, and the all key-type, which means
add/modify all three key types.
NOTE: Whenever you add a new host to the directory server that will contain sshPublicKeys,
you must use the -f option to add the fully qualified domain name (FQDN) for the host, if the
FQDN has not been set. The ssh toolset uses network naming services (typically DNS) to determine
the host name of IP addresses for hosts. In so doing, it resolves to a fully qualified domain name,
which ssh needs to validate in the directory server. Notice that in the previous example, you can
see the cn attribute listed twice, once with the short name and once with the FQDN.
The ldaphostmgr and ldaphostlist tools provide a smoother user interface for entering user
credentials when used by accounts that have posixAccounts managed in the directory server. For
the purposes of this demonstration, the domadmin user is used, which is created by default when
a new directory server instance is created using the guided installation.
When ldaphostmgr is used to add a new host, it determines the location to add the host using
the LDAP-UX configuration profile. By default, when using a guided installation, this location is
ou=Hosts,defaultBaseDN. You can use the ldapcfinfo command to determine the location
that ldaphostmgr will use:
# /opt/ldapux/bin/ldapcfinfo -t hosts -b
ou=Hosts,dc=mydomain,dc=example,dc=com
See Section 8.2.2 (page 262) for additional information. If you want to place the host in a different
location of the directory server tree, you can use the -B option.
While ldaphostmgr can be used to add the current ssh public keys of the local host, it is also
possible to add keys of other remote HP-UX hosts managed by LDAP-UX that are in the current
LDAP-UX domain. Just specify the name of the remote host; however, if ldaphostmgr has no way
to identify the remote host, it displays an ssh-like warning message to indicate this:
chef (): ldaphostmgr -a -f -k rsa baker
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
WARNING: The identity of the host "baker" could not be verified.
SSH key fingerprint: b4:2f:45:c2:b0:17:a2:7b:a0:a7:88:61:a9:36:f2:4c.
The SSH key for the remote host is unknown. This host's key is currently not
managed in the directory server and should be positively identified before
adding this key to the directory server. Once added, this key will be
trusted by all other LDAP-enabled ssh clients. Using ldaphostmgr on the
remote host, instead of adding this key remotely, will avoid generating
this warning message. Do you wish to trust this key (y/n)?: n
ERROR:
HST_UNTRUSTED_REMOTE_HOST:
The identity of the host "baker" could not be verified. SSH key
8.3 Managing keys in the directory server 267
fingerprint: b4:2f:45:c2:b0:17:a2:7b:a0:a7:88:61:a9:36:f2:4c. The SSH
key for the remote host is unknown and is not trusted.
If you remotely log in to the host, and can positively identify the host, you can add the host using
ldaphostmgr as originally demonstrated. Or, if you have the ssh public key of the remote host
in a local known_hosts file, the preceding message is not displayed. If you can positively identify
the fingerprint of the remote host, you can answer yes (y) to the WARNING message. Key
fingerprints for the local host can be displayed using the ssh-keygen command:
baker (): ssh-keygen -l -f /opt/ssh/etc/ssh_host_rsa_key.pub
2048 b4:2f:45:c2:b0:17:a2:7b:a0:a7:88:61:a9:36:f2:4c /opt/ssh/etc/ssh_host_rsa_key.pub (RSA)
8.3.3 Adding keys for nonHP-UX hosts or devices
Not all hosts and devices that support the ssh protocol in your network will be HP-UX systems. You
can use LDAP-UX and the LDAP directory server to manage keys for those hosts; however, to assure
key integrity, an out-of-band process is required to verify the public key of those devices. There
are two methods to do this. In the first method, the public key for a remote device can be provided
directly to ldaphostmgr in a file:
chef (): ldaphostmgr -a -k /tmp/router1_ssh_host_rsa_key.pub router1.mydomain.example.com
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
chef (): ldaphostlist -k -n router1.mydomain.example.com
dn: cn=router1,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: router1.mydomain.example.com
ipHostNumber: 192.0.32.1
sshPublicKey: ssh-rsa AAAAB...== BEGIN-KM creationtime=20100427000132Z END-KM
The file provided to ldaphostmgr must contain the ssh public key for the remote host/device,
and be in the ssh standard public key file format, as found in the /opt/etc/ssh/
ssh_host_rsa_key.pub file. This format contains the following three fields separated by spaces:
key-type, base64-key, and comments.
The second method is to let ldaphostmgr automatically discover the public key for the remote
host/device. In this case, the -k option is used with the ^ flag:
chef (): ldaphostmgr -a -k ^rsa router2.mydomain.example.com
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
WARNING: The identity of the host "router2.mydomain.example.com" could not be verified.
SSH key fingerprint: 74:ed:80:36:f9:3f:30:29:11:43:31:ea:27:3f:3b:13.
The SSH key for the remote host is unknown. This host's key is currently not
managed in the directory server and should be positively identified before
adding this key to the directory server. Once added, this key will be
trusted by all other LDAP-enabled ssh clients. Using ldaphostmgr on the
remote host, instead of adding this key remotely, will avoid generating
this warning message. Do you wish to trust this key (y/n)?: y
chef (): ldaphostlist -k -n router2.mydomain.example.com
dn: cn=router2.mydomain.example.com,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: router2.mydomain.example.com
ipHostNumber: 192.0.32.2
sshPublicKey: ssh-rsa AAAAB...UlQ== BEGIN-KM creationtime=20100427000942Z END-KM
However, with this method, and as indicated by the WARNING prompt, ldaphostmgr has no
means to verify the validity of the remote host’s or device’s public key. An out-of-band method must
be used to verify the key fingerprint before accepting the key for the specified device, unless other
means are available to assure the trust between the local host and the remote host or device.
8.3.4 Adding keys in a batch
You might already be managing and distributing an ssh known_hosts file, such as the one found
at /opt/ssh/etc/ssh_known_hosts. This file contains four fields: host-name, key-type,
base64-key, and comments. However, the host-name field may be hashed. If your
ssh_known_hosts file does not have host names, then use the following shell script to add all
the keys from the ssh_known_hosts file to the directory server automatically.
268 Managing ssh host keys with LDAP-UX (HP directory servers only)
NOTE: Because this script runs in batch mode, you must specify the LDAP host administrator’s
credentials in the LDAP_BINDDN and LDAP_BINDCRED environment variables before running the
script (or, alternatively, use the -E option to specify those values in a file.)
KNOWN_HOSTS_FILE="ssh_known_hosts"
### grep out comments and blank lines
grep -v -e "^[[:space:]]*$" -e "^[[:space:]]*#" \
"$KNOWN_HOSTS_FILE" > /tmp/myknownhosts$$
exec 4< /tmp/myknownhosts$$
while read pubkey <&4
do
hostname="$(echo "$pubkey" | cut -d" " -f 1)"
keydata="$(echo "$pubkey" | cut -d" " -f 2-)"
if ( /opt/ldapux/bin/ldaphostlist -n "$hostname" | grep -qi "^dn: " )
then
hostop="-m"
else
hostop="-a"
fi
echo "$keydata" > /tmp/keyfile$$
/opt/ldapux/bin/ldaphostmgr $hostop -X -f -k /tmp/keyfile$$ "$hostname"
done
rm -f /tmp/keyfile$$
rm -f /tmp/myknownhosts$$
8.3.5 Changing keys for HP-UX hosts
If you believe the private key for a host has been compromised, you can change the keys of that
host with ldaphostmgr. From that host, run the ldaphostmgr command with the -k option. If
the user has privilege to modify the sshPublicKey attribute, ldaphostmgr will elevate that
privilege to allow a nonroot user to modify the host’s public and private key files /opt/ssh/etc/
ssh_host_rsa_key and /opt/ssh/etc/ssh_host_rsa_key.pub). ldaphostmgr will
also update the directory server with the new public keys for this host:
baker (): ldaphostmgr -k all baker
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
The public key(s) already exists in LDAP server, do you want
to replace it [y/n]? y
In this example, the all key-type was specified to change all the active key types for the host. This
will change all three key types (RSA, RSA1, and DSA) on the host and update those key types on
the directory server. If you only want to change one key type or manage just one key type in the
directory server, specify just that type (rsa1, rsa, or dsa) instead of all.
If the root user has already updated the keys for the remote host, you can use the same process
as described previously.
8.3.6 Changing key size
To change the key size used on a host, you must first use ssh-keygen to change the key, and
then use ldaphostmgr to upload that key in the directory server. The following example shows
how to change the bit size of the RSA key. In the example, we are logged in as root on the host
chef:
# /opt/ssh/bin/ssh-keygen -b 4096 -t rsa -f /opt/ssh/etc/ssh_host_rsa_key
Generating public/private rsa key pair.
Please be patient....
Key generation may take a few minutes
/opt/ssh/etc/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /opt/ssh/etc/ssh_host_rsa_key.
8.3 Managing keys in the directory server 269
Your public key has been saved in /opt/ssh/etc/ssh_host_rsa_key.pub.
The key fingerprint is:
ab:92:ec:71:8e:24:b9:5e:b9:1e:26:60:50:84:b9:bb root@chef
The key's randomart image is:
+--[ RSA 4096]----+
| +o
|
|o.
|
|..
|
|o
|
|.o
S
|
|o. . .
.
|
| .+.B.. .
|
|E B+B .
|
| .oo=.o
|
+-----------------+
# ldaphostmgr -k /opt/ssh/etc/ssh_host_rsa_key.pub chef
bind-dn: uid=domadmin,ou=people,dc=mydomain,dc=example,dc=com
Password:
The public key(s) already exists in LDAP server, do you want
to replace it [y/n]? y
Notice that since root is required to run ssh-keygen and change the rsa key pair for the host,
you might not be prompted with your default LDAP login (as shown with domadmin in the other,
previous examples), since root typically does not have an identity managed in the LDAP directory
server.
8.3.7 Changing keys for nonHP-UX hosts
Since ldaphostmgr cannot directly modify the key files for nonHP-UX hosts (since it is not installed
on those hosts), you must use a process similar to the one described in Section 8.3.3 (page 268),
except that you must first delete the existing key before adding the new one. If you do not do this,
the following error occurs:
baker (): ldaphostmgr -k ^rsa router1.mydomain.example.com
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
ERROR:
HST_UNTRUSTED_REMOTE_HOST:
DANGER: The identity of the host router1.mydomain.example.com appears to be
invalid. The key discovered for the remote host does not match that
already managed in the directory server. This can occur if an
attacker has set up a host to impersonate the true host. Or the key
for the remote host may have been legitimately changed. Or both
events may have occurred. ldaphostmgr will not directly replace this
key in the directory server. Using ldaphostmgr on the remote host,
instead of adding this key remotely, will avoid generating this
warning message. Or use ldaphostmgr to first delete the key in the
directory server for this host before attempting to replace it.
However, do not replace this key in the directory server without
using additional validation to verify the key for the remote host is
valid. Once this key is replaced in the directory server, it will be
trusted by all other LDAP-enabled ssh clients.
Host fingerprint: 24:de:77:0e:c2:7a:af:0c:9d:15:ca:a8:8f:bb:65:d7
LDAP fingerprint: 2e:fd:98:46:31:c7:fa:d9:a8:fd:61:02:bc:6b:2c:bb
You can delete and then add the key using the following process:
baker (): ldaphostmgr -k !rsa router1.mydomain.example.com
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
baker (): ldaphostmgr -k ^rsa router1.mydomain.example.com
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
WARNING: The identity of the host "router1.mydomain.example.com" could not be verified.
SSH key fingerprint: 24:de:77:0e:c2:7a:af:0c:9d:15:ca:a8:8f:bb:65:d7.
The SSH key for the remote host is unknown. This host's key is currently not
managed in the directory server and should be positively identified before
adding this key to the directory server. Once added, this key will be
trusted by all other LDAP-enabled ssh clients. Using ldaphostmgr on the
remote host, instead of adding this key remotely, will avoid generating
this warning message. Do you wish to trust this key (y/n)?: y
270 Managing ssh host keys with LDAP-UX (HP directory servers only)
In this example, you must verify the fingerprint for the key before adding it to the directory server.
A alternative way to change a remote key is to securely obtain the public key file for the remote
host and upload it using the file option as shown in the first example of Section 8.3.2 (page 266),
but without specifying the -a option.
8.3.8 Revoking or removing keys
If a key has been compromised, and you want to revoke it and reissue a new key, use the previously
described process for changing keys. If, on the other hand, you no longer want to manage keys
for a host, you can simply remove the sshPublicKey attribute from the host’s entry using the -k
option with the ! flag, as in the following example:
baker (): ldaphostmgr -k !all router1.mydomain.example.com
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
baker (): ldaphostlist -n router1.mydomain.example.com sshPublicKey
dn: cn=router1.mydomain.example.com,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: router1.mydomain.example.com
ipHostNumber: 192.0.32.1
The ldaphostlist command shows that the sshPublicKey has been removed from the router1
entry.
If you only want to remove a specific type, you can replace all with the key type (rsa, rsa1, or
dsa).
NOTE: If you are using the UpdateKeyFromLdap option in the ssh_config file, use of the
! flag does not remove cached instances of those keys. If a client has a cached version of a
compromised key, it is possible for that client to connect to an impostor host that is using the
compromised host key. If you want to remove keys or revoke keys for hosts, you must not enable
the UpdateKeysFromLdap option because when it is enabled, the ssh client tools will update
cached versions of changed keys, but only when a connection is made to the true host.
8.4 Managing key age
LDAP-UX B.05.00 provides the ability to track ssh key age and set advisory expiration dates for
ssh host keys. By default, ldaphostmgr adds key age information to the comment fields within
the ssh public key data when new keys are added or changed in the directory server. ldaphostmgr
can also use this same field to set advisory key expiration dates when new keys are created or
existing keys are changed.
Key age expiration information appears within the comment fields and between the BEGIN-KM
and END-KM tokens. For example:
brewer(): ldaphostlist -k -n "$(hostname)"
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
cn: brewer.mydomain.example.com
ipHostNumber: 16.92.96.225
sshPublicKey: ssh-rsa AAAA...== BEGIN-KM creationtime=20100423234903Z END-KM
ldaphostmgr and ldaphostlist can be used to keep track of key age and expiration
information, which is described in the following sections.
NOTE: Key expiration data is merely advisory. It is provided to enable the ldaphostlist tool
to display hosts with keys that are considered expired. HP Secure Shell tools do not reject or take
other actions when a key’s state is considered expired.
8.4.1 Setting advisory key expiration dates
To set key expiration information, use the -e option on ldaphostmgr, and specify the number
of days (from the current date) when the key is considered expired. The following example shows
8.4 Managing key age
271
how to set a key that should be considered expired in 2 years. If the key already exists in the
directory server, you are prompted to replace it with a new key, if you so choose.
chef (): ldaphostmgr -k rsa -e 730 chef
bind-dn [uid=domadmin,ou=People,dc=cup,dc=hp,dc=com]:
Password:
The public key(s) already exists in LDAP server, do you want
to replace it [y/n]? y
To display the key expiration date, use ldaphostlist with the -k option:
chef (): ldaphostlist -k -n chef
dn: cn=chef,ou=Hosts,dc=cup,dc=hp,dc=com
cn: chef
cn: chef.cup.hp.com
ipHostNumber: 16.92.96.225
sshPublicKey: ssh-rsa AAAAB... BEGIN-KM ... expirationtime=20120426204647Z END-KM
8.4.2 Key auditing
To display hosts with expired keys or keys that are older than a specified age, use the -k option
of ldaphostlist. To display keys that are older than a specific age, use the -k option followed
by the number of days preceded by a dash. For example, to show keys that were created over 1
year ago, use the following command:
baker (): ldaphostlist -k -365
dn: cn=chef,ou=Hosts,dc=cup,dc=hp,dc=com
cn: chef
cn: chef.cup.hp.com
ipHostNumber: 16.92.96.225
sshPublicKey: ssh-rsa AAAAB3... BEGIN-KM creationtime=20090426204647Z ... END-KM
If you are setting expiration information in keys, you may also use the -k option of ldaphostlist
to display hosts with keys that have expired or will expire within a specified number of days. In
this case, specify the -k age option without the preceding dash. For example, to display keys that
have already expired or will expire within the next 20 days, use the following:
baker (): ldaphostlist -k 20
dn: cn=chef,ou=Hosts,dc=cup,dc=hp,dc=com
cn: chef
cn: chef.cup.hp.com
ipHostNumber: 16.92.96.225
sshPublicKey: ssh-rsa AAAAB3... BEGIN-KM ... expirationtime=20100515195500Z END-KM
NOTE: The preceding examples assume the commands were run on May 27th, Midnight UTC,
2010, which is represented by 20100427000000Z.
8.5 Centrally managing ssh configuration
In order to enable ssh key management on hosts, the ssh_config file, and optionally the
sshd_config file, must be configured with the UseLdapHostKey parameter, and optionally
the UdateKeyFromLdap parameter. To mitigate the management costs of changing these
configuration files on all hosts, you may configure LDAP-UX to centrally manage the parameters
of these files using the LDAP-UX central configuration service, provided by ldapconfd. Support
for ldapconfd is limited to managing HP Secure Shell configuration, as documented in this
section.
To do this, you must create a global configuration policy. Do this by first specifying the location
of a global configuration policy in the LDAP-UX configuration profile. Then create a configuration
policy entry using the configurableService object class and the serviceConfigParam
attributes. The preceding schema for the Central Configuration service is defined in the /etc/
opt/ldapux/schema/ldapux5.0.xml file delivered with LDAP-UX B.05.00. You can install
that schema on your directory server using the ldapschema tool, described in Section 9.5.3
(page 361). That schema is automatically installed if you use the guided installation.
Use the ldapentry tool to modify the LDAP-UX Configuration profile. For example:
272 Managing ssh host keys with LDAP-UX (HP directory servers only)
chef (): /opt/ldapux/bin/ldapentry -m "$profiledn"
Press <return> to accept default Directory login: "uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com"
Directory login:
Default accepted. "uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com"
password:
You are then placed in an editor window, where you can add a central configuration policy.
Bolded text in the following example indicates what items were added:
version: 1
dn: cn=mydomain-ldapuxProfile,ou=Services,ou=Configuration,dc=mydomain,dc=example,dc=com
objectClass: top
objectClass: DUAConfigprofile
objectClass: configurableService
cn: mydomain-ldapuxProfile
preferredServerList: 127.0.0.1:389
defaultSearchBase: dc=mydomain,dc=example,dc=com
bindTimeLimit: 5
authenticationMethod: tls:simple
credentialLevel: proxy
attributeMap: passwd:userpassword=*NULL*
attributeMap: shadow:userpassword=*NULL*
attributeMap: group:memberUid=member uniqueMember memberUid
serviceSearchDescriptor: passwd:ou=People,
serviceSearchDescriptor: shadow:ou=People,
serviceSearchDescriptor: group:ou=Groups,
serviceSearchDescriptor: pam:ou=People,
serviceSearchDescriptor: rpc:ou=Services,
serviceSearchDescriptor: protocols:ou=Services,
serviceSearchDescriptor: networks:ou=Services,
serviceSearchDescriptor: hosts:ou=Hosts,
serviceSearchDescriptor: services:ou=Services,
serviceSearchDescriptor: printers:ou=Services,
serviceSearchDescriptor: automount:ou=Services,
serviceSearchDescriptor: netgroup:ou=Groups,
cfgGlobalPolicyDN: cn=mydomain-ldapuxProfile,dc=mydomain,dc=example,dc=com
serviceConfigParam: ssh/client/ssh_config:useldaphostkey yes
serviceConfigParam: ssh/client/ssh_config:updatekeyfromldap no
serviceConfigParam: ssh/server/sshd_config:useldaphostkey yes
In this example, the cfgGlobalPolicyDN attribute was added; it points to an entry that contains
the serviceConfigParam attributes. In this case, the cfgGlobalPolicyDN points back to the
profile entry itself, and the serviceConfingParam attributes were added directly to the same
configuration profile entry.
The format of the serviceConfigParam value is in two parts. The first part is a hierarchical
description of the service being configured. The second part is the specific parameter being
managed. The format of the service description is:
baseService/serviceSubsystem/...:
And the format for the parameter section is specific to the configuration file being managed. For
the ssh_config file, the following service description is used:
ssh/client/ssh_config:
For the sshd_config file, the following service description is used:
ssh/server/sshd_config:
In the previous example, useldaphostkey is being centrally managed, and will be added to
any host that is part of the same LDAP-UX domain. The following shows an example of how the
ssh_config file is changed:
.
.
.
# buffer size for hpn to non-hpn connections
# HPNBufferSize 2048
#
#
#
#
#
#
Cipher 3des
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
EscapeChar ~
Tunnel no
TunnelDevice any:any
PermitLocalCommand no
# Turn on/off Visual Fingerprinnt Display mode
# VisualHostKey no
8.5 Centrally managing ssh configuration 273
checkhostip yes
###
###
###
###
###
CCD NOTE:
The following keyword-argument pairs are configured in LDAP server.
If you want to add local configurations to this file, add above the
"CCD NOTE" line. Anything added manually below this line will be
gone at next LDAP update.
# Keyword-argument pairs defined in LDAP server global entry:
updatekeyfromldap no
useldaphostkey yes
The central configuration service (ldapconfd) can be used to centrally manage other ssh and
sshd parameters. For example, once ssh host keys are managed in a directory server, users
connected to hosts managed with LDAP-UX will always have access to the public key for remote
hosts. In that case, users should not be prompted about whether they would like to accept keys
that have not been verified. So you could consider enabling the strict-host-key-checking feature of
ssh (meaning users would not be prompted if an unknown key is discovered). As an example, the
following could be added to the global configuration policy DN:
serviceConfigParam: ssh/client/ssh_config:strictHostKeyChecking yes
Values configured in the global policy will override those defined in the local configuration. For
example, if the local ssh_config file defines “strictHostKeyChecking ask”, but the
central configuration is defined as described previously, then the “strictHostKeyChecking
ask” is commented out by ldapconfd, and a “strickHostKeyChecking yes” is added to
the CCD section of the ssh_config file.
8.5.1 Overriding central configuration
There are two ways to override the global configuration on a specific host:
•
Disable ldapconfd on that specific host. To completely disable ldapconfd, modify the
/etc/opt/ldapux/ldapconfd.conf file by setting the enable_ldapconfd parameter
to zero:
enable_ldapconfd 0
•
Set a host-specific policy. For example, if the global policy for strictHostKeyChecking
is set to yes, and you want to set it to ask for a specific host, you can add a
serviceConfigParam to the host entry, using either the ldapentry or ldaphostmgr
tool. For example, use the following command to enable the ask policy on the “brewer”
system (assuming Central Configration policy has not been previously set for this host):
baker (): ldaphostmgr -A objectclass=networkService \
-A "serviceConfigParam=ssh/client/ssh_config:strictHostKeyChecking yes" brewer
bind-dn [uid=domadmin,ou=People,dc=mydomain,dc=example,dc=com]:
Password:
baker (): ldaphostlist -n brewer serviceConfigParam
dn: cn=brewer,ou=Hosts,dc=mydomain,dc=example,dc=com
cn: brewer
cn: brewer.mydomain.cup.hp.dom
ipHostNumber: 192.0.32.11
serviceConfigParam: ssh/client/ssh_config:strictHostKeyChecking yes
With ldapentry, just specify the name of the host to edit, as follows:
baker (): ldapentry -m hosts brewer
Then once in the editor established by ldapentry, simply add the networkService object
class and the serviceConfigParam as shown in the preceding example.
8.6 Distributing keys to nonHP-UX hosts
The integrated ability to automatically use LDAP as an ssh key repository is available in HP Secure
Shell A.05.50 or later. If you plan on using LDAP central ssh key management in a heterogeneous
environment, your ssh applications on other platforms might not be able to discover those keys in
the directory server. While the sshPublicKey attribute is used by other ssh implementations, it
274
Managing ssh host keys with LDAP-UX (HP directory servers only)
is not available on all platforms. To enable a heterogeneous data center to participate in central
ssh key management, you might need to distribute keys to nonHP-UX hosts. The following is a
sample script that, with platform dependent modifications, can be used to periodically retrieve an
update public key list to store in the host’s ssh_known_hosts file. It could be run as a periodic
“cron” job (see the crontab(1M) manpage).
A perl script is required to help parse the LDAP host entries. This perl script uses the perl-ldap
perl module, which is common on most UNIX and Linux platforms:
#!/usr/bin/perl
use Net::LDAP::LDIF;
use Net::LDAP::Entry;
use strict;
my $infilename = shift || die "Input LDIF file name required";
my $ldif = Net::LDAP::LDIF->new( $infilename, "r", onerror => 'undef' );
while( not $ldif->eof() ) {
my $entry = $ldif->read_entry ( );
if ( $ldif->error() ) {
print "Error msg: ", $ldif->error(), "\n";
print "Error lines:\n", $ldif->error_lines(), "\n";
} else {
my @names = $entry->get_value("cn");
my @keys = $entry->get_value("sshPublicKey");
foreach my $name (@names) {
foreach my $key (@keys) {
print "$name $key\n"
}
}
}
}
$ldif->done();
The input to this script is an LDIF file, which must be obtained through the ldapsearch command,
also available on most platforms. Note that the connection to the directory server should be made
with SSL, to make sure the client has some assurance that it is not communicating with an impostor
directory server. The following example is for the ldapsearch command available with LDAP-UX.
Your ldapsearch command might require slightly different parameters:
ldapsearch -Z -P CACertPath -b "ou=hosts,dc=mydomain,dc=example,dc=com” \
-h hostname "(&(objectclass=iphost)(sshpublickey=*))" \
cn sshpublickey > allhostkeys.ldif
To create the known_hosts file, send the output of ldapsearch into the preceding script. If you
named the preceding perl script makeKnownHosts.pl, you would then use:
makeKnownHosts.pl allhostkeys.ldif > ssh_known_hosts
8.6 Distributing keys to nonHP-UX hosts 275
9 Command and tool reference
This chapter describes the commands and tools associated with the LDAP-UX Client Services.
9.1 The LDAP-UX Client Services components
The LDAP-UX Client Services product, comprising the components listed in Table 24, can be found
under /opt/ldapux and /etc/opt/ldapux, except where noted. LDAP-UX Client Services libraries
are listed in Table 25 (page 278) and Table 26 (page 278).
Table 24 LDAP-UX Client Services components
Component
Description
/etc/opt/ldapux/ldapux_client.conf
The LDAP-UX startup file, specifies where the directory
is, where in the directory the profile data is, and logging.
/etc/pam.ldap
A sample PAM configuration file (see Section D.1
(page 421)). The actual PAM configuration file is /etc/
pam.conf.
/etc/nsswitch.ldap
A sample Name Service Switch configuration file. The
actual NSS configuration file is /etc/nsswitch.conf.
/etc/opt/ldapux/ldapux_profile.bin
The configuration profile translated from
ldapux_profile.ldif, in binary format, used by
the client. See also the discussion of
display_profile_cache later in this table.
/etc/opt/ldapux/domain_profiles/
ldapux_profile.bin.gc
GCS profile file (LDAP-UX with Windows AD Server).
Specifies which server (and port) serves as the GCS.
/etc/opt/ldapux/ldapux_profile.ldif
The configuration profile downloaded from the LDAP
directory, in LDIF format.
/etc/opt/ldapux/domain_profiles
Remote domains configuration profile file (LDAP-UX with
Windows AD Server).
/opt/ldapux/config/autosetup
Program to configure LDAP-UX Client services. Will also
automatically configure an HP-UX directory server
instance and create an LDAP-UX domain if one has not
been set up.
/opt/ldapux/config/setup
Program to configure LDAP-UX Client Services.
/opt/ldapux/config/get_profile_entry
Program to download a configuration profile from a
directory.
/opt/ldapux/config/display_profile_cache
Program to display the current configuration profile.
/opt/ldapux/config/create_profile_entry
Program to create a new configuration profile.
/opt/ldapux/config/create_profile_schema
Programs called by the setup program.
/opt/ldapux/config/create_profile_cache
/opt/ldapux/config/ldap_proxy_config
Program to configure and verify the proxy user.
/opt/ldapux/bin/ldapcfinfo
Tool to report LDAP-UX configuration and status. This
tool can be used to discover LDAP-UX configuration
details about required attributes when creating new users
or groups in an LDAP directory server.
276 Command and tool reference
Table 24 LDAP-UX Client Services components (continued)
Component
Description
/opt/ldapux/bin/ldapuglist
Tools to display, add, modify and delete user and group
entries in an LDAP directory server. For more information,
see Section 9.3 (page 283).
/opt/ldapux/bin/ldapugadd
/opt/ldapux/bin/ldapugmod
/opt/ldapux/bin/ldapugdel
/opt/ldapux/bin/ldaphostmgr
/opt/ldapux/bin/ldaphostlist
/etc/opt/ldapux/ug_templates/
ug_passwd_std.tmpl
/etc/opt/ldapux/ug_templates/
ug_group_std.tmpl
/etc/opt/ldapux/ug_templates/
ug_passwd_ads.tmpl
/etc/opt/ldapux/ug_templates/
ug_group_ads.tmpl
The default template files are used by ldapugadd to
discover the required data models for a new user or
group entry for a standard LDAP directory server.
The default template files are used by ldapugadd to
discover the required data models for a new user or
group entry for a Windows Active Directory Server.
/etc/opt/ldapux/ldapug.conf
The ldapugadd tool uses this configuration file to
manage the default values of the uidNumber_range,
gidNubmer_range, default_gidNumber,
default_homeDirectory and
default_loginShell attributes when creating a user
or a group to an LDAP directory server.
/opt/ldapux/bin/ldapdelete
Tools to delete, modify, and search for entries in a
directory. For more information, see Section 9.4
(page 353) and the HP-UX Directory Server administrator
guide.
/opt/ldapux/bin/ldapmodify
/opt/ldapux/bin/ldapsearch
/opt/ldapux/bin/ldapentry
/opt/ldapux/bin/ldap_del_entry
/opt/ldapux/bin/ldap_new_entry
/opt/ldapux/bin/ldap_mod_entry
/opt/ldapux/bin/ldifdiff
Tool to generate LDIF change records from two input
files.
/etc/opt/ldapux/ldapclientd.conf
The ldapclientd daemon configuration file.
/opt/ldapux/bin/ldapclientd
The ldapclientd daemon binary.
/opt/ldapux/bin/ldappasswd
Tool to modify user password in a directory.
/opt/ldapux/bin/ldapschema
Tool to query and extend directory server schema. For
more information, see Section 9.5 (page 359).
/opt/ldapux/migrate
/opt/ldapux/migrate/ads
A set of scripts for migrating user, group, and other
information into a directory. For more information, see
Section 9.6 (page 383).
/opt/ldapux/share
Manpages.
/opt/ldapux/contrib/bin/perl
perl, version 5, used by migration scripts.
/opt/ldapux/ypldapd
Files for the NIS/LDAP Gateway product. Not supported
with Windows ADS. For more information, see
NIS/LDAP Gateway Administrator's Guide at the
following location:
http://www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
9.1 The LDAP-UX Client Services components 277
Table 24 LDAP-UX Client Services components (continued)
Component
Description
/opt/ldapux/contrib/bin/beq
Search tool that bypasses the name service switch and
queries the backend directly based on the specified
library.
/opt/ldapux/contrib/bin/certutil
Command-line tool that creates and modifies the
cert8.db and key3.db database files.
NOTE:
For LDAP C SDK libraries information, see “Mozilla LDAP C SDK” (page 394).
Table 25 shows LDAP-UX Client Services libraries on HP-UX 11i v2 and v3 PA-RISC machines:
Table 25 LDAP-UX Client Services libraries on the HP-UX 11i v2 or v3 PA-RISC machine
Files
Description
/usr/lib/libldap_send.1 (32-bit )
LDAP -UX Client Services libraries.
/usr/lib/libldap_util.1 (32-bit )
/usr/lib/libnss_ldap.1 (32-bit)
/usr/lib/libldapci.1 (32-bit )
/usr/lib/libldap.1 (32-bit )
/usr/lib/security/libpam_ldap.1(32-bit )
/usr/lib/security/libpam_authz.1 (32-bit)
/usr/lib/pa20_64/libldap.1 (64-bit)
/usr/lib/pa20_64/libldap_send.1 (64-bit )
/usr/lib/pa20_64/libnss_ldap.1 (64-bit )
/usr/lib/security/pa20_64/libpam_ldap.1 (64-bit)
/usr/lib/security/pa20_64/libpam_authz.1 (64-bit )
Table 26 shows LDAP-UX Client Services libraries on an HP-UX 11i v2 or v3 Integrity server machine:
Table 26 LDAP-UX Client Services libraries on an HP-UX 11i v2 or v3 Integrity server machine
Files
Description
/usr/lib/hpux32/libldap_send.so.1 (32-bit )
LDAP -UX Client Services libraries.
/usr/lib/hpux32/libldap_util.so.1 (32-bit )
/usr/lib/hpux32/libnss_ldap.so.1 (32--bit)
/usr/lib/hpux32/libldapci.so.1 (32-bit )
/usr/lib/hpux32/libldap.so.1 (32-bit )
/usr/lib/security/hpux32/libpam_ldap.so.1 (32-bit )
/usr/lib/security/hpux32/libpam_authz.so.1 (32-bit )
/usr/lib/hpux64/libldap.so.1 (64-bit)
/usr/lib/hpux64/libldap_send.so.1 (64-bit )
/usr/lib/hpux64/libnss_ldap.so.1 (64-bit )
/usr/lib/security/hpux64/libpam_ldap.so.1 (64-bit )
/usr/lib/security/hpux64/libpam_authz.so.1 (64-bit )
9.2 Client management tools
This section describes the following programs for managing client systems.
display_profile_cache
Displays the currently active profile.
create_profile_entry
Creates a new profile in the directory.
278 Command and tool reference
get_profile_entry
Downloads a profile from the directory to LDIF, and creates the
profile cache.
ldap_proxy_config
Configures a proxy user.
ldapcfinfo
Displays LDAP-UX configuration and status by examining LDAP
User and Group (UG) template files, the LDAP UG configuration
file, or the LDAP-UX configuration profile. See Section 9.3.10
(page 348) or the ldapcfinfo manpage for detailed information
about tool usage, syntax, options and arguments.
The following tools are called by the setupprogram and are not typically used separately.
create_profile_schema
Extends the schema in the directory for profiles.
create_profile_cache
Creates a new active profile from an LDIF profile. This is also
called by get_profile_entry.
9.2.1 The create_profile_entry tool
This tool, found in /opt/ldapux/config, creates a new profile entry in an LDAP directory from
information you provide interactively. The directory schema must have the DUAConfigProfile
extensions.
9.2.1.1 Syntax
create_profile_entry
9.2.2 The create_profile_cache tool
This tool, found in /opt/ldapux/config, creates a binary profile file from an LDIF profile file,
thus activating the profile for the client. (You can download a profile to LDIF from the directory
with get_profile_entry.) Typically you run the setup program instead of running this program
directly. See also Section 2.5.8 (page 111).
9.2.2.1 Syntax
create_profile_cache [-i infile] [-o outfile]
where infileis the LDIF file containing a profile, by default /etc/opt/ldapux/
ldapux_profile.ldif and outfileis the name of the binary output file, by default /etc/
opt/ldapux/ldapux_profile.bin. The LDIF file must contain an entry for the object class
DUAConfigProfile.
9.2.2.2 Examples
The following command creates the binary profile file /etc/opt/ldapux/ldapux_profile.bin from
the existing LDIF file /etc/opt/ldapux/ldapux_profile.ldif:
create_profile_cache
The following command creates the binary profile file my_profile.bin from the existing LDIF
file profile1.ldif:
create_profile_cache -i profile1.ldif -o my_profile.bin
Note that you must copy the file my_profile.bin to
/etc/opt/ldapux/ldapux_profile.bin to activate the profile.
9.2.3 create_profile_schema tool
This tool, found in /opt/ldapux/config, extends the schema of an HP-UX Directory Server with
the DUAConfigProfile object class using the information you provide interactively. Typically you
run the setup program instead of running this program directly.
9.2 Client management tools 279
9.2.3.1 Syntax
create_profile_schema
9.2.4 The display_profile_cache tool
This tool, found in /opt/ldapux/config, displays information from a binary profile (cache)
file. By default, it displays the currently active profile in /etc/opt/ldapux/
ldapux_profile.bin.
9.2.4.1 Syntax
display_profile_cache [-i infile] [-o outfile]
where infile is a binary profile file, /etc/opt/ldapux/ldapux_profile.bin by default,
and outfile is the output file, stdout by default.
NOTE: The binary profile contains mappings for all backend commands (even unused ones) all
of which are displayed by display_profile_cache. The actual client configuration can be
reviewed in the configuration profile LDIF file: /etc/opt/ldapux/ldapux_profile.ldif.
9.2.4.2 Examples
The following command displays the profile in the binary profile file /etc/opt/ldapux/
ldapux_profile.bin to stdout:
display_profile_cache
The following command displays the profile in the binary profile file my_profile.bin and writes
the output to the file profile:
display_profile_cache -i my_profile.bin -o profile
9.2.5 The get_profile_entry tool
This tool, found in /opt/ldapux/config, downloads a profile from an LDAP directory into an
LDIF file and calls create_profile_cache to create a binary profile file, thereby activating it on the
client. This tool looks in the local client configuration file /etc/opt/ldapux/
ldapux_client.conf for the profile DN.
9.2.5.1 Syntax
get_profile_entry -s service [-o outfile]
where service is the name of a supported service, typically NSS, and outfile is the name of
a file to contain the LDIF output, by default /etc/opt/ldapux_profile.ldif.
9.2.5.2 Examples
The following command downloads the profile for NSS specified in the client configuration file
/etc/opt/ldapux/ldapux_client.conf and places the LDIF in the file /etc/opt/ldapux/
ldapux_profile.ldif:
get_profile_entry -s NSS
The following command downloads the profile for the NSS specified in the client configuration file
/etc/opt/ldapux/ldapux_client.conf and places the LDIF in the file profile1.ldif:
get_profile_entry -s NSS -o profile1.ldif
9.2.6 The ldap_proxy_config tool
This tool, found in /opt/ldapux/config, configures a proxy user or an Admin Proxy user for
the client accessing the directory. The tool stores the proxy user information in the user proxy
credential file/etc/opt/ldapux/pcred; it stores the Admin Proxy user information in the
280 Command and tool reference
administrator proxy credential file /etc/opt/ldapux/acred. If you are using only anonymous
access, you do not need to use this tool. You must run this tool logged in as root. While the data
stored in the pcred and acred files are protected for root-only access and not stored in plain
text, the data is not encrypted.
The /etc/opt/ldapux/pcred file is used to contain credentials that represent all users of the
HP-UX OS to the directory server. For example, when a user wants to run the ls -l command to
see who owns a file or directory, the OS must contact the directory server to translate the owner
ID number into a name. If the directory server does not allow anonymous access, a proxy user
must be created to be used to authenticate to the directory server and represent any user requesting
such information.
The /etc/opt/ldapux/acred file is used to represent any administrative user (typically root);
this user should have additional permissions in the directory server beyond that of the nonprivileged
user. The acred file will store the credentials of a user with permissions to modify specific attributes
(as needed) based on commands that are performed on the OS. Specifically, the acred credential
allows a root user to change any user's nisPublickey and nisPrivate key attributes. Because
the chkey and newkey commands do not prompt for directory user credentials, the acred file
is required to allow the administrator to reset such attributes. The acred file is also used by the
ldapugadd, ldapugmod, ldapugdel and ldaphostmgr commands. However, those utilities
have the ability to prompt for credentials or to obtain them with other methods. So the acred file
is not required. Because a privileged credential is stored in the acred file, creation of the acred
file is recommended only for managing NIS keys in the directory server, and only if key reset is
required. In addition, access to the acred file must be restricted.
9.2.6.1 Syntax
ldap_proxy_config [options]
where options can be any of the following:
-A
Action applies to the Admin Proxy user. This option must be specified with other
option to apply the operation for the Admin Proxy user.
-e
erases the currently configured proxy user from the file /etc/opt/ldapux/
pcred. Has no effect on the proxy user information in the directory itself.
-i
uses the -i option to configure the proxy user interactively from stdin. Use -A
-ioptions to configure an Admin Proxy user.
If you use ldap_proxy_config -i to configure the proxy user using the simple
authentication, type the command with -i and then press Enter. Next type the
proxy user DN then press Enter. Finally type the proxy user's credential or password
and press Enter.
If you configure the proxy user using the SASL DIGEST-MD5 with DN authentication
(that is, using the DN to generate the DIGEST-MD5 hash), type the command with
-i then press Enter. Next type the proxy user DN then press Enter. Next type the
proxy user's credential or password and press Enter. Finally press Enter.
If you configure the proxy user using the SASL/DIGEST-MD5 with UID authentication
(that is, using the UID attribute to generate the DIGEST-MD5 hash), type the
command with -i then press Enter. Next type the proxy user DN then press Enter.
Next type the proxy user's credential or password and press Enter. Finally type
the proxy user's UID and press Enter.
When you use the ldap_proxy_config -A -i command to configure an
Admin Proxy user interactively from stdin, the configuration procedures are similar
to the procedures used by the ldap_proxy_config -i command for a proxy
user.
When configuring an Admin Proxy user, if you only enter the Admin Proxy user's
DN without password, the root's password will be used instead.
9.2 Client management tools
281
-f file
configures the proxy user from the specified file (file). The file specification
must contain two lines: the first line must be the proxy user DN, and the second
line must be the proxy user credential or password.
CAUTION: After using this option you should delete or protect the file as it could
be a security risk.
-d DN
sets the proxy user distinguished name to be DN. To use this option, the /etc/
opt/ldapux/pcred file must exist.
-c passwd
sets the proxy user credential or password to be passwd. To use this option, the
/etc/opt/ldapux/pcred file must exist.
-p
prints the distinguished name of the current proxy user.
-v
verifies the current proxy user and credential by connecting to the server.
-h
displays help on this command.
With no options, ldap_proxy_config configures the proxy user as specified in the file /etc/
opt/ldapux/pcred.
For the proxy user, if you switch the authentication method between simple and DIGEST-MD5, you
must use the ldap_proxy_config -e command to delete /etc/opt/ldapux/pcred, then
use the ldap_proxy_config -i command to reconfig the proxy user.
For the Admin Proxy user, if you switch the authentication method between simple and DIGEST-MD5,
you must use the ldap_proxy_config -A -e command to delete /etc/opt/ldapux/acred,
then use the ldap_proxy_config -A -i to reconfigure the Admin Proxy user.
9.2.6.2 Examples
The following example configures the proxy user as uid=proxyuser1,ou=special
users,o=hp.com with the password prox1pw and creates or updates the file /etc/opt/
ldapux/pcred with this information, the proxy user uses the simple authentication:
ldap_proxy_config -i
uid=proxyuser1,ou=special users,o=hp.com
prox1pw
The following example configures the proxy user as uid=proxyusr2,ou=special
users,o=hp.com with password prox2pw, and creates or updates the file /etc/opt/ldapux/
pcred with this information. The proxy user uses the SASL DIGEST-MD5 authentication and uses
the DN to generate the DIGEST-MD5 hash.
ldap_proxy_config -i
uid=proxyusr2,ou=special users,o=hp.com
prox2pw
CR>
The following example configures the proxy user as uid=proxyusr3,ou=special
users,o=hp.com, UID proxyusr3 and password prox3pw, and creates or updates the file
/etc/opt/ldapux/pcred with this information. The proxy user uses the SASL/DIGEST-MD5
authentication and uses the UID to generate the DIGEST-MD5 hash.
ldap_proxy_config -i
uid=proxyusr3,ou=special users,o=hp.com
prox3pw
proxyusr3
The following example configures the Admin Proxy user as uid=adminproxy,ou=special
users,o=hp.com with the password adminproxpw, and creates or updates the file /etc/opt/
ldapux/acred with this information. The Admin Proxy user uses the simple authentication.
ldap_proxy_config -A -i
uid=adminproxy,ou=special users,o=hp.com
adminproxpw
282 Command and tool reference
The following example configures the Admin Proxy user as uid=adminproxy2,ou=special
users,o=hp.com with password admin2pw, and creates or updates the file /etc/opt/ldapux/
acred with this information. The Admin Proxy user uses the SASL/DIGEST-MD5 authentication
and uses the DN to generate the DIGEST-MD5 hash.
ldap_proxy_config -A -i
uid=adminproxy2,ou=special users,o=hp.com
admin2pw
CR>
The following example configures the Admin Proxy as uid=adminproxy3,ou=special
users,o=hp.com, UID adminproxy3, and password admin3pw, and creates or updates the
file /etc/opt/ldapux/acred with this information. The Admin Proxy user uses the SASL/
DIGEST-MD5 authentication and uses the UID to generate the DIGEST-MD5 hash.
ldap_proxy_config -A -i
uid=adminproxy3,ou=special users,o=hp.com
admin3pw
adminproxy3
The following example displays the current proxy user:
ldap_proxy_config -p
PROXY_DN: uid=proxyuser,ou=special users,o=hp.com
The following command displays the configured proxy user information and determines whether
the client can bind to the directory as the proxy user:
ldap_proxy_config -v
File Credentials verified - valid
The following example configures the proxy user as uid=proxyuser,ou=special
users,o=hp.com with the password prox12pw, and creates or updates the file /etc/opt/
ldapux/pcred with this information:
ldap_proxy_config -d "uid=proxyuser,ou=special users,o=hp.com" -c prox12pw
The following example configures the proxy user with the contents of the file proxyfile and
creates or updates the file /etc/opt/ldapux/pcred with this information:
ldap_proxy_config -f proxyfile
The file proxyfile must contain two lines: the proxy user DN on the first line and password on
the second line.
9.3 LDAP user and group management tools
The LDAP-UX Integration product supports the following new LDAP command-line tools which enable
you to manage user accounts and groups in an LDAP directory server. These new tools exist in the
/opt/ldapux/bin directory and perform their operations based on the LDAP-UX profile
configuration. Each tool provides command options that enable you to alter these configuration
parameters. For detailed information about tool usage, syntax, options, arguments, environment
variables, template files, return codes supported by these tools, see Section 9.3 (page 283), or see
the ldapuglist(1M), ldapugadd(1M), ldapcfinfo(1M), ldapugmod(1M), and ldapugdel(1M)
manpages.
ldapuglist
Use the ldapuglist tool to display and enumerate subsets of POSIX-like account
and group entries that reside in an LDAP directory server.
ldapugadd
Use the ldapugadd tool to add new POSIX accounts or groups to an LDAP
directory server.
ldapugmod
Use the ldapugmod tool to modify existing accounts or groups in an LDAP
directory server. You can use ldapugmod with extended options to modify
arbitrary attributes for user or group entries.
9.3 LDAP user and group management tools 283
ldapugdel
Use the ldapugdel tool to remove POSIX related user or group entries from an
LDAP directory server. Use the -O option to remove POSIX related attributes and
object classes from a user or a group entry without removing entire entry itself.
ldapcfinfo
Use the ldapcfinfo tool to retrieve LDAP-UX configuration information details
about required attributes when creating new users or groups. Use this tool to
discover LDAP User and Group (UG) configuration defaults, a list of available
template files and attribute mapping information. You may also use ldapcfinfo
to ensure that the LDAP-UX product is properly configured and active.
When performing modification, creation and deletion operations on the LDAP directory server,
use these tools to input the LDAP administrator bind identity and credential interactively with a
prompt (-P) option or by specifying the LDAP_BINDDN environment variable for the administrator
identity and LDAP_BINDCRED environment variable for the administrator's credential. Values set
with a prompt (-P) option override values specified in the environment variables. If the two previously
mentioned methods have not been specified, the LDAP tool follows the bind configuration specified
in the LDAP-UX configuration profile. If the LDAP-UX profile has specified a proxy bind, the LDAP
tool reads the credential from either the /etc/opt/ldapux/acred or /etc/opt/ldapux/
pcred file. The /etc/opt/ldapux/acred file is used only by users who have sufficient
administrative privilege to read this file.
9.3.1 Environment variables
The ldapuglist, ldapugadd, ldapugmod and ldapugdel tools support the following
environment variables:
LDAP_BINDDN
Specifies the distinguished name (DN) or other appropriate identity indicator
(such as a Kerberos principle id) of a user with sufficient directory server
privilege to view, add, modify or delete users and groups in the LDAP
directory server. If LDAP_BINDDN is specified, LDAP_BINDCRED must also
be specified.
LDAP_BINDCRED
Specifies a password or other type of credential used for the LDAP user
specified by LDAP_BINDDN.
The ldapugadd and ldapugmod tools support the following environment variable:
LDAP_UGCRED
This variable specifies the new password of a user or group being created or
modified. You must use the -PW command option when you use this environment
variable, to indicate this variable has been set and is used for the current
command. If attribute mapping for the userPassword attribute has not been
defined or set to “*NULL*” in the LDAP-UX configuration profile, ldapugadd
or ldapugmod creates new passwords using the userPassword attribute.
See the -PW option of Section 9.3.5 (page 296) or Section 9.3.6 (page 313) for
additional information.
284 Command and tool reference
NOTE: To support noninteractive use of the ldapuglist, ldapugadd, ldapugmod and
ldapugdel commands, you can use the LDAP_BINDDN and LDAP_BINDCRED environment
variables to specify the LDAP administrator's identity and password. Use LDAP_UGCRED to specify
the user or group password being created or modified. To prevent exposure of these environment
variables, you must disable them after use. The shells command history log may contain copies
of the executed commands that show the setting of these variables. You must protect access to a
shell’s history file. Specification of the LDAP administrator’s credentials on the command line is not
allowed, because information about the currently running processes can be exposed externally
from the session. Using the -P command option eliminates the LDAP_BINDDN and LDAP_BINDCRED
environment variables by interactively prompting for the required administrator's credentials. Using
the -PP command option eliminates LDAP_UGCRED by interactively prompting for the required
password of the user or group being created or modified.
9.3.2 Return value formats
Upon exit, ldapuglist, ldapugadd, ldapugmod, ldapugdel or ldapcfinfo returns a 0
(zero) exit status if no errors or warnings are encountered. A nonzero exit status is returned and
one or more messages are logged to stderr if these tools encounters an error or warnings. Messages
follow this format:
ERROR:
or
WARNING:
<code>:
<message>
<code>:
<message>
Leading extra white space may be inserted to improve readability and follow 80 column screen
formatting. <code> is a programmatically parsable error key-string, while <message> is
human-readable text.
9.3.3 Common return codes
Table 27 lists common return codes used by ldapuglist, ldapugadd, ldapugmod, ldapugdel
and ldapcfinfo.
For detailed information on a list of specific return codes for each tool, see Section 9.3.4.6
(page 293), Section 9.3.5.8 (page 310), Section 9.3.6.5 (page 322), Section 9.3.7.5 (page 327), or
Section 9.3.10.3 (page 350).
Table 27 Common return codes
Return Code
Message
LDAP_INIT_FAILED
Unable to initialize LDAP-UX library backend.
GET_LDAP_CONFIG_FAILED
Cannot read the ldapux_profile.bin file.
REPLACE_PORT_FAILED
Cannot reset the port number.
INVALID_AUTH_MATHOD
The specified authentication method is invalid.
READ_INPUT_FAILED
Unable to read input from stdin for the specified command option
value.
GETENV_FAILED
The LDAP_BINDDN environment variable is set, but
LDAP_BINDCRED is not set.
BIND_PASSWORD_EXPIRED
The bind Password has expired.
BIND_INVALID_CRED
The specified bind credential is invalid.
BIND_ERR
LDAP-UX failed to bind to the LDAP directory server.
GET_PROXY_DECRYPT_FAILED
Failed to decrypt proxy and credential information.
9.3 LDAP user and group management tools 285
Table 27 Common return codes (continued)
MOD_LIMIT_REACHED
There are too many modifications to perform.
SSL_INIT_FAILED
SSL initialization failed.
LOAD_LIB_FAILED
Failed to load the specific library.
LOAD_FUNCTION_FAILED
Failed to load the specific function.
ACCESS_TEMPLATEFILE_FAILED
Unable to access specified template file.
READ_TEMPLATEFILE_FAILED
Unable to read specified template file.
MISSING_DIRECTIVE
The specified template file is missing the required directive.
INVALID_TEMPLATENAME
The template file name specified in the -T <file_name> option
is invalid.
NEED_CONFIG_PROXY
Needs to configure LDAP-UX to use proxy credential level.
NEED_ADMIN_CRED
Requires administrator credentials in order to perform privilege user
management operations. Specification of the -P option or the
LDAP_BINDDN and LDAP_BINDCRED environment variables are
required.
NO_PROXY_FILE
LDAP-UX proxy has been configured, but the /etc/opt/ldapux/
pcred file does not exist.
BUFFER_OVERFLOW
Buffer overflowed when processing a specific operation.
CHOWN_FAILED
Failed to change the ownership of the files.
CHOWN_FAILED
Cannot modify the specified home directory.
HOMEDIR_CREATE_FAILED
Failed to create the specified home directory.
INVALID_DIR
The specified directory is not a valid directory.
HOMEDIR_EXISTS
The specified home directory already exists.
ACCOUNT_DOESNOT_EXIST
The specified account does not exist in the directory server.
COMMANDLINE_ERR
The valid type of the -t <type> option should be either passwd
or group.
COMMANDLINE_ERR
Need to specify a value for the specified option.
COMMANDLINE_ERR
User name has not been specified.
COMMANDLINE_ERR
Group name has not been specified.
COMMANDLINE_ERR
Invalid <attr>=<value> pair specified in the command line.
PASSWD_INCONSISTENT
Entered inconsistent password.
CANNOT_GET_PASSWD
Cannot read password.
ZERO_LENGTH_PASSWD
Password entered is 0 length.
ENV_VAR_NOT_SET
The specific environment variable is not set.
INVALID_SEARCH_SCOPE
The input search scope must be base, one, or sub.
GROUP_DOESNOT_EXIST
The specified group does not exist in the LDAP directory server.
LOGIN_SHELL_DOESNOT_EXIST
The specified login shell does not exist.
HOMEDIR_DOESNOT_EXIST
The specified home directory does not exist.
LOGIN_SHELL_NOT_EXECUTE
The specified login shell is not executable.
286 Command and tool reference
Table 27 Common return codes (continued)
ADD_GR_MEMBER_FAILED
MemberUid is mapped to only dynamic group attributes, the add
operation fails.
ENTRY_NOT_FOUND
The LDAP search returns no entries.
EXPLODE_DN_FAILED
Cannot convert the specified distinguished name (DN) to its
component parts.
EXPLODE_RDN_FAILED
Cannot convert the specified RDN to its component parts.
MODIFY_FAILED
The modification operation failed.
9.3.4 The ldapuglist tool
You can use the ldapuglist tool to display and enumerate POSIX-like account and group entries
stored in an LDAP directory server, without requiring extensive knowledge of the methods used to
retrieve and evaluate that information in the LDAP directory server.
The ldapuglist tool uses the LDAP-UX profile configuration, requiring minimal command line
options to discover where to search for user or group information, such as the LDAP directory server
host and proper search filters for finding users and groups. This tool provides command options
that enable you to alter these configuration parameters.
The ldapuglist tool supports the followings:
•
ldapuglist uses the existing LDAP-UX authentication configuration to determine how to
bind to the LDAP directory server.
•
ldapuglist performs attribute value translation to POSIX-like syntaxes. For example, if group
membership is defined using X.500-style DN strings, ldapuglist converts those string to
simple member ids.
•
ldapuglist supports attribute mappings as specified in the LDAP-UX configuration profile.
The mapped attributes and values can be displayed. The output format of ldapuglist is
similar to an LDIF format (RFC 2849). It is not LDIF. Major differences include:
◦
ldapuglist does not display object classes.
◦
By default, ldapuglist only displays POSIX-related attributes, unless you specifically
request an attribute list with the <attr> option on the command line.
◦
Output lines are not broken after 80 columns.
9.3.4.1 Synopsis
ldapuglist [options] [-t <type>] [-h <hostname>] [-p <port>] [-n <name>]
[-f|F <filter>] [-b <base>] [-s <scope> [-N <maxcount>] [<attr>...]
9.3.4.2 Options
The ldapuglist tool supports the following command options:
-m
Displays the names of the mapped attributes when returning results. Without the -m option,
ldapuglist displays results as follows:
fieldname: value
Where fieldname is one of the predefined RFC 2307 attribute names, and value is
the value for that field.
With the -m option, the ldapuglist tool displays the actual attribute mapping name as
follows:
fieldname[mapped attributename]: value
9.3 LDAP user and group management tools 287
In the following example, if the RFC 2307 attribute gecos has been mapped to the cn,
l (location) and telephoneNumber attributes. Without the -m option, the output of the
gecos field is:
gecos: Bill Wan,Building 45,1-555-555-5431
When the -m option is specified, the output representing the gecos field is as follows:
gecos[cn]: Bill Wang
gecos[l]: Building 45
gecos[telephoneNumber]: 1-555-555-5431
When a field has been mapped to multiple attributes, those attributes will appear in the
order as defined in the LDAP-UX configuration profile.
Another example, if the RFC 2307 attribute uidNumber has been mapped to the
employeeNumber attribute. Without the -m option, the output of the uidNumber field
is:
uidNumber: 520
When the -m option is specified, the output representing the uidNumber field is as follows:
uidNumber[employeeNumber]: 520
The ldapuglist tool ignores the -m option if the -L option is specified.
-L
Displays output following /etc/passwd or /etc/group format.
The output format for a user entry is as follows:
uid:userPassword:uidNumber:gidNumber:gecos:homeDirectory:loginShell
The output format for a group entry is as follows:
cn:userPassword:memberUid,memberUid,…
For example, run the following command to display the user entry that contains
uid=mscott:
ldapuglist -t passwd -L -n mscott
The output of the command is as follows:
mscott:x:200:250:mscott:/home/mscott:/usr/bin/sh
The ldapuglist tool ignores the -m option if the -L option is specified. The <attr>
parameter list is invalid if the -L option is specified.
-P
Prompts for the bind identity (typically LDAP DN or Kerberos principal) and bind password.
Without the -P option, ldapuglist attempts to get the bind identity and password from
the environment variables LDAP_BINDDN and LDAP_BINDCRED. If you do not specify
the LDAP_BINDDN or LDAP_BINDCRED environment variables, ldapuglist gets
information from the bind configuration specified in the LDAP-UX configuration profile. If
the LDAP-UX configuration profile has specified the “proxy” bind, ldapuglist reads the
bind credential from either the /etc/opt/ldapux/acred or /etc/opt/ldapux/
pcred file. The /etc/opt/ldapux/acred file is only used by users who have sufficient
administrative privilege to read that file.
-Z
Requires an SSL connection to the LDAP directory server, even if the LDAP-UX configuration
profile does not specify the use of SSL. Using the -Z option requires that either a valid
directory server or CA certificate is defined in the /etc/opt/ldapux/cert8.db file.
An error occurs if the SSL connection cannot be established.
-ZZ
Attempts a TLS connection to the directory server, even if the LDAP-UX configuration profile
does not specify the use of TLS. If a TLS connection cannot be established, a nonTLS and
nonSSL connection will be established. HP does not recommend you to use -ZZ unless
alternative methods are used to protect against network eavesdropping. Use of -ZZ requires
that you define a valid LDAP directory server or CA certificate in the /etc/opt/ldapux/
cert8.db file.
288 Command and tool reference
-ZZZ
Requires a TLS connection to the LDAP directory server, even if the LDAP-UX configuration
profile does not specify the use of TLS. Using the -ZZZ option requires that you define a
valid directory server or CA certificate in the /etc/opt/ldapux/cert8.db file. An
error will occur if the TLS connection can not be established.
9.3.4.3 Arguments
The following describes command arguments:
-t <type>
Specifies the type of entry the ldapuglist tool needs to discover and
process. The valid types of this option are passwd and group. The passwd
type indicates posixAccount-type entries. The group type indicates
posixGroup-type entries. Specification of the <type> parameter tells
ldapuglist how to handle processing of search filters and attribute
mappings. If you do not specify the -t option, ldapuglist assumes the
passwd type. For example, - t group.
-h <hostname>
Specifies the host name and optional port number (hostname:port) of the
LDAP directory server. This option overrides the server list configured in the
LDAP-UX configuration profile. This field supports specification of IPv4 and
IPv6 addresses. Note that when you specify a port for an IPv6 address, you
must specify the IPv6 address in square-bracketed form. If the optional port
is unspecified, the port number is assumed to be 389 or 636 for SSL
connections (with the -Z option). For example, -h ldapsrvA.
-p <port>
Specifies the port number of the LDAP directory server to contact. The
ldapuglist tool ignores this option if you specify the port number in the
<hostname> as part of the -h option.
-n <name>
Provides a simplified method for discovering a single account or group. Use
of -n is the same as -f “(uid=<name>)” for accounts and -f
“(cn=<cname>)” for groups. Do not specify -f and -F on the command
line if you use -n. For example, the following command displays an account
entry for the user, mlee:
ldapuglist -t passwd -n mlee
The output from the preceding command is as follows:
dn: cn=Mike Lee,ou=people,dc=example,dc=com
cn: Mike Lee
uid: mlee
uidNumber: 900
gidNumber: 2010
loginShell: /usr/bin/sh
homeDirectory: /home/mlee
gecos: mlee,Building-5,555-555-5555
-f <filter>
Specifies an LDAP-style search filter, <filter>, used to select specific entries
from the LDAP directory. When you use the -f option, the filter specified by
<filter> applies to Posix-style users or groups (depending on whether you
specify the -t passwd or -t group option).
The filter specified with -f is amended with the default LDAP-UX search filter
for either the user or group object types. In addition, when you use -f, if a
known attribute for the particular service has been mapped as defined in
the LDAP-UX configuration profile, then the mapped attribute name is
substituted in the search filter.
For example, if the uidNumber attribute has been mapped to the
employeeNumber attribute, the following command lists a POSIX account
that has uidNumber=51552:
9.3 LDAP user and group management tools 289
ldapuglist -t passwd -f “(uidNumber=51552)”
For the preceding example, the mapped attribute name is substituted in the
search filter, and the resulting search filter used by LDAP-UX is as follows:
(&(objectclass=posixAccount)(employeeNumber=51552))
The -f option also supports generation of search filters for the multi-mapped
attributes, gecos and memberUid. In the case of gecos, each mapped
attribute is used in the search filter using the LDAP and operation (&). In the
case of memberUid, each mapped attribute is used in the search filter using
the LDAP or operation (|).
In the following example, the gecos attribute has been mapped to cn, l
and telephoneNumber. If the argument to -f is “(gecos=Jane
Smith,BLD-5D,555-1212)”, then the resulting search filter presented to
the LDAP directory server is as follows:
(&(objectclass=posixAccount)(&(cn=Jane Smith)
(l=BLD-5D)(telephoneNumber=555-1212)))
As another example using memberUid, if memberUid has been mapped
to member and memberUid. If the argument to -f is
“(memberUid=jsmith)”, then the resulting search filter presented to the
LDAP directory server is:
(&(objectclass=posixGroup)(|(member= cn=Jane
Smith,ou=people,ou=myorg,dc=com) (memberUid=jsmith)))
NOTE:
-F <filter>
•
When you use -f and any of the attributes specified in the search filter
have been mapped to “*NULL*”, ldapuglist will return an error.
•
Attributes that are not part of the LDAP-UX configuration profile mapping
are not modified. For the list of attributes that may be mapped, see RFC
2307: An Approach for Using LDAP as a Network Information Service.
•
Do not specify -n and -f on the same command line. Doing so causes
an error.
Similar to -f, except that the specified <filter> is immutable. The LDAP-UX
user or group search filter defined in the configuration profile is not amended
to the specified filter, and attribute mapping does not apply to the <filter>.
For example, the following command lists an account entry with
“(uid=EricB)”:
ldapuglist -t passwd -F "(uid=EricB)"
NOTE:
-b <base>
290 Command and tool reference
•
When you use -F, the specified filter must apply to either user or group
entries and matches the -t passwd or -t group option. The
ldapuglist tool generates unpredictable results if the search filter
specified with -F discovers group entries, but the -t passwd option
was specified.
•
Do not specify -n and -F on the same command line. Doing so causes
an error.
This option overrides the search base as defined in the LDAP-UX configuration
profile. Specifies the DN of the search base that defines where ldapuglist
starts the search in an LDAP directory server. If unspecified, ldapuglist
uses the defaultSearchBase as defined in the LDAP-UX configuration profile.
-s <scope>
This option overrides the search scope as defined in the LDAP-UX
configuration profile. Specifies how deep in the directory tree to perform the
search. The <scope> argument can be one of the following:
•
base: Search only the entry specified in the -b option.
•
one: Search only the immediate children of the entry specified in the
-b option.
•
sub: Perform a sub-tree search starting at the point identified in the -b
option.
-N <maxcount>
Specifies the maximum number of entries to be returned. If you do not specify
this option, the maximum number of entries to be returned is 200 by default.
Some LDAP directory servers will limit the number of entries returned for a
particular search request, regardless of how many entries are requested. If
the <maxcount> limit is set too high, it might not be possible to determine
if a search has returned complete results, because the directory server might
have truncated the number of returned entries before reaching the requested
maximum count. Although some LDAP directory servers indicate when a
specified search exceeds an enumeration limit. If the <maxcount> limit is
above the directory server's internal configured limit, it is not always possible
to determine if all results have been returned. However, a reasonable
assumption is that if maximum number of entries have been returned,
additional entries are likely still available to display that match the search
criteria than just those displayed. For example, -N 150.
<attr>
Specifies additional LDAP attributes to display aside from the predefined
RFC 2307 attributes for users or groups. The <attr> argument may not be
used if the -L option is specified. Attributes specified in the <attr> list are
assumed to not be part of RFC 2307 and thus are not be mapped. When
you specify the -m option, the output format for a value specified by an
<attr> name is always in the following form:
attributename[attributename]: value
NOTE: The ldapuglist tool does not allow you to use the <attr>
parameter when ldapuglist binds to the directory server using the LDAP-UX
proxy user. This limitation prevents regular HP-UX users from discovering
LDAP data that was previously not displayed by LDAP-UX. Use of the <attr>
parameter requires that the user has the rights to use the LDAP-UX
administrator credential (/etc/opt/ldapux/acred) or the user running
ldapuglist has specified an identity using the -P option or the
LDAP_BINDDN and LDAP_BINDCRED environment variables.
9.3.4.4 Output format
Output from ldapuglist follows a consistent format, regardless of which attributes you use to
define information in an LDAP directory. The output format is as follows:
dn: dn1
field1: value1
field2: value2
field3:: base64-encodeded-value3
...
dn: dn2
field1: value1
9.3 LDAP user and group management tools
291
field2: value2
...
Each entry is preceded by a DN, followed by one or more field-value pairs. The DN and each
field-value pair are on a separate line, separated by a carriage-return and line-feed character. The
field and value are separated by a colon and a space character. Each entry is separated by a
blank line. If an unencodable character is encountered (carriage-return or line-feed for example)
in a value string, the whole value is base64 encoded and the field-value separator is changed to
two colons and a space character.
When you specify the -t passwd option, ldapuglist displays the following fields for a user
entry:
•
cn
•
uid
•
userPassword
•
uidNumber
•
gidNumber
•
homeDirectory
•
loginShell
•
gecos
When you specify the -t group option, ldapuglist displays the following fields for a group
entry:
•
cn
•
userPassword
•
gidNumber
•
memberUid
When you specify the -m option, the output format for both users and groups is changed to the
following:
dn: dn1
field1[attribute1]: value1
field2[attribute2]: value2
field3[attribute3]:: base64-encodeded-value3
...
9.3.4.5 Special considerations for output format
This section describes special considerations for the output format from ldapuglist.
9.3.4.5.1 Multi-values attributes
Although some of the attributes used in LDAP directory servers are multi-valued attributes, the
ldapuglist tool displays only the first value discovered for each RFC 2307 attribute for each
entry, because these fields appear only once in a POSIX account or group. For nonRFC 2307
attributes (those specified via the <attr> argument list), if the attribute is multi-valued, ldapuglist
displays multiple values. This rule does not apply to the memberUid field because POSIX groups
can have multiple members.
Because the gecos attribute can be mapped to multiple attributes, the gecos field can appear
multiple times in an entry if you use the -m option, once for each mapped attribute. For example,
if the gecos attribute is mapped to cn, l and telephoneNumber, ldapuglist displays once
for each mapped attribute as follows:
292 Command and tool reference
gecos[cn]: Bill Hu
gecos[l]: Building 6A
gecos[telephoneNUmber]: +1-555-555-4321
9.3.4.5.2 NonPOSIX accounts and groups
If you use ldapuglist with the -F option, ldapuglist displays users and groups that are not
posixAccounts or posixGroups. Thus, these entries might not contain the required fields that store
POSIX account and group information (such as the uidNumber attribute). When displaying these
entries, the specified fields are missing from the output. As nonPOSIX accounts and groups are not
required to contain POSIX attributes, use of the -L option might result in unexpected output. Data
between the “:” characters may be empty, such as ”::x:::”.
9.3.4.5.3 Encoding of the DN
ldapuglist displays DN strings according to the encoding rules defined in RFC4514. The escape
character “\” precedes special characters, which may be the character itself or a 2-digit hex
representation of the character.
9.3.4.5.4 Passwords
In some cases, ldapuglist cannot access the user or group password fields. This can occur in
the following cases:
•
The ldapuglist tool has insufficient privilege to access the password field.
•
The passwords are not used to authenticate users (such as when X.500 certificates are used).
•
The password is not stored in the LDAP directory server. The password might be stored in a
third-party repository such as a Kerberos Key Domain Controller.
•
The password is stored in a format that cannot be parsed by HP-UX (such as {SSHA}, the
Salted Secure Hash Algorithm).
If the password is not available to ldapuglist, ldapuglist does not display the
userPassword field. If you specify the -L option, the password field will contain the “x” character.
9.3.4.6 Specific return codes for ldapuglist
The ldapuglist tool returns a list of return codes shown in Table 28.
Table 28 Return codes for ldapuglist
Return Code
Message
LST_SEARCH_FAILED
Search operation failed.
LST_COMMANDLINE_ERR
The <attr> parameter may not be used when the -L
option is specified.
LST_COMMANDLINE_ERR
The requested input options cannot be specified at the
same time.
LST_COMMANDLINE_ERR
The “maxcount” value must be greater than 0.
LST_SEARCH_BASE_TOO_LONG
The specified search base is too long.
LST_SEARCH_FILTER_TOO_LONG
The specified search filter is too long.
LST_ATTR_MAP_EMPTY
The attribute mapping evaluates to an empty search filter.
For example,
ldapuglist -t passwd -f "(gecos=)"
The output of the command displays the
“LST_ATTR_MAP_EMPTY” error because the gecos values
are not specified in the command line, ldapuglist
evaluates the gecos attribute to an empty search filter.
9.3 LDAP user and group management tools 293
Table 28 Return codes for ldapuglist (continued)
LST_ATTR_MAP_NULL
One or more of the attributes specified in the search filter
is not mapped or mapped to *NULL*, cannot create search
filter. For example,
ldapuglist -t passwd -f “(userpassword=userp)”
The output of the preceding command displays the
“LST_ATTR_MAP_NULL” error because the
userpassword attribute is mapped to *NULL* in the
LDAP-UX configuration profile.
LST_ATTR_NOT_ALLOWD
The attribute is not allowed when bind to the directory
server with the LDAP-UX proxy user.
9.3.4.7 Limitations
The ldapuglist tool has the following limitations:
•
The ldapuglist tool does not support enumeration of members of a dynamic group, such
as those defined by the dynamic group attributes, memberURL or msDS-AzLDAPQuery.
•
The ldapuglist tool does not perform conversion of the locale character set to and from
the UTF-8 character set.
9.3.4.8 Examples
This section provides examples of using ldapuglist:
While use of LDAP_BINDDN is not typically required to use ldapuglist, the LDAP_BINDDN
and LDAP_BINDCRED environment variables can be used to specify the distinguished name (DN)
and password of a user with sufficient directory server privilege to display protected attributes.
Setting the LDAP_BINDDN and LDAP_BINDCRED environment variables is optional when using
ldapuglist.
The following commands specify the LDAP_BINDDN and LDAP_BINDCRED environment variables:
export LDAP_BINDDN = "cn=Jane Admin,ou=admins,dc=example,dc=com"
export LDAP_BINDDN = "Jane_password"
Run the following command to go to the /opt/ldapux/bin directory where ldapuglist
resides:
cd /opt/ldapux/bin
Run the following command to display the account entry for the user name, ascott:
./ldapuglist -t passwd -L -n ascott
The output of the preceding command displays the /etc/passwd format as follows:
ascott:x:125:250:ascott:/home/ascott:/usr/bin/sh
Run the following command to list an account entry that contains uid=mlee:
./ldapuglist -t passwd -f "(uid=mlee)"
The output is as follows:
dn: cn=Michael Lee,ou=people,dc=example,dc=com
cn: Michael Lee
uid: mlee
uidNumber: 2201
gidNumber: 318
homeDirectory: /home/mlee
loginShell: /usr/bin/ksh
gecos: mlee,San Francisco,555-555-5555
Run the following command to list an account entry that contains uid=jscott:
294 Command and tool reference
./ldapuglist -t passwd -m -f "(uid=jscott)"
The output is as follows. Assume that the gecos attribute has been mapped to cn, l, and
telephoneNumber. With the -m option, the ldapuglist tool displays the mapped attribute
names as well.
dn: cn=John Scott,ou=people,dc=example,dc=com
cn[cn]: John Scott
uid[uid]: jscott
uidNumber[uidNumber]: 2225
gidNumber[gidNumber]: 252
homeDirectory[homeDirectory]: /home/mlee
loginShell[loginShell]: /usr/bin/ksh
gecos[cn]: jscott
gecos[l]: San Jose
gecos[telephoneNumber]: 555-555-9999
Run the following command to list an account entry having the mfreise account name that does
not contain POSIX attributes:
./ldapuglist -t passwd -m -F "(uid=mfreise)"
The output is as follows:
dn: cn=Michael Freise,ou=people,dc=example,dc=com
cn[cn]: Michael Freise
uid[uid]: mlee
gecos[cn]: Michael Freise
gecos[l]: San Jose
gecos[telephoneNumber]: 555-555-5555
Use the following command to list all posixGroup entries that Mike Lou belongs to:
./ldapuglist -t group -f "(memberUid=mlou)"
The output is as follows:
dn: cn=group1,ou=groups,dc=example,dc=com
cn: group1
gidNumber: 550
memberUid: mlou
memberUid: apierce
memberUid: bjones
dn: cn=group2,ou=groups,dc=example,dc=com
cn: group2
gidNumber: 550
memberUid: vtam
memberUid: ajones
memberUid: mlou
Run the following command to list a regular posixGroup entry for the group name, groupA:
./ldapuglist -t group -f "(cn=groupA)"
The output is as follows:
dn: cn=groupA,ou=groups,dc=example,dc=com
cn: groupA
gidNumber: 620
memberUid: user1
memberUid: user3
memberUid: user5
Run the following command to list a group entry that does not require posixGroup attributes. This
command uses ((cn=groupA)(objectclass=groupOfUniqueNames)) as the search filter:
./ldapuglist -t group -F “(&(cn=groupA)(objectclass=groupOfUniqueNames))”
The output is as follows:
9.3 LDAP user and group management tools 295
dn: cn=groupA,ou=groups,dc=example,dc=com
cn: groupA
Run the following commands to unset the LDAP_BINDDN and LDAP_BINDCRED environment
variables.
unset LDAP_BINDDN
unset LDAP_BINDCRED
9.3.5 The ldapugadd tool
You can use the ldapugadd tool to add new POSIX accounts and groups to an LDAP directory
server (as noted by the first and second syntaxes in Section 9.3.5.2 (page 297)). You can use
ldapugadd to modify the /etc/opt/ldapux/ldapug.conf file to set defaults for creation of
new users or groups (as noted by the third syntax, Section 9.3.5.2 (page 297)).
The ldapugadd tool uses user and group template files that enable it to conform to the information
model used for the types of entries being created. To use ldapugadd, you must provide LDAP
administrator credentials that have sufficient privilege to perform the user or group add operation
in the LDAP directory server.
This tool provides command-line options that enable you to add the following information to the
user or group entry:
For POSIX accounts
•
User's full name
•
User ID (account name)
•
User ID number
•
User password
•
Primary group membership
•
Home directory
•
Login shell
•
Gecos
•
Comments
For POSIX groups
•
Group ID (group name)
•
Group ID number
•
Group members
LDAP-UX supports a local LDAP User and Group (UG) configuration file,
/etc/opt/ldapux/ldapug.conf. The ldapugadd tool uses the ldapug.conf file to manage
the default values for the configuration parameters, uidNumber_range, gidNumber_range,
user_gidNumber, default_homeDirectory and default_loginShell. The ldapugadd
tool uses these values when creating new user and group entries in an LDAP directory server if a
command-line option is not provided for that specific value. You can use the ldapugadd -D
command to change the value defined in the ldapug.conf file. See Section 9.3.5.5 (page 305)
for more information.
Template files are required by the ldapugadd tool. These template files define the data required
to create new user and group entries and enable ldapugadd to discover required attributes.
Because each organization might have different required data models for user and group entries
(LDAP directory servers allow for a variety of attributes to be stored in user and group entries),
these templates may define arbitrary data models beyond just the required POSIX attributes. Before
creating new entries, applications can use the ldapcfinfo tool to discover the attributes required
296 Command and tool reference
by the templates that are not part of the standard POSIX data model. For more information, see
Section 9.3.5.6 (page 306) .
9.3.5.1 Syntax translation
LDAP-UX supports syntax translation for the memberUid and gecos attributes. This translation
enables storage of this information in a format more interoperable with other directory-enabled
applications. The LDAP user and group tools enable creation and modification of these attributes
in the LDAP-native syntaxes, even when specified using POSIX syntaxes.
For example, if the LDAP-UX configuration profile indicates the gecos attribute has been mapped
to cn, l and telephoneNumber attributes, then when you specify the GECOS values separated
by a comma for each mapped attribute in the ldapugadd command, the comma-separated list
is parsed and each comma-separated component is placed in the cn, l and telephoneNumber
attributes. If the memberUid attribute has been mapped to the member attribute (where the member
ID syntax is defined using a distinguished name [DN]), then ldapugadd translates the memberUid
account name to a DN before placing the member attribute. If the memberUid attribute has been
mapped to more than one attribute type, ldapugadd uses the first attribute defined by the mapping.
9.3.5.2 Synopsis
ldapugadd [-t passwd] [options] <uid_name>
[-h <hostname>] [-p <port>] [-b <base>] [-u <uid_number>]
[-g <group/gid>] [-f <full_name>] [-x <domain>] [-G <group/gid>[,...]]
[-s <login_shell>] [-d <home_directory>] [-I <gecos>][-c <comment>]
[-m [-k <skel_dir> [-T <template_file> [[<attr>=<value>][...]]
ldapugadd -t group [options] [-h <hostname>] [-p <port>]
[-b <base>] [-g <gidNumber>], [-x <domain>] [-M <member>[,...]]
[-c <comment>] [-T <template_file>] <group_name>
[[<attr>=<value>][...]]
ldapugadd -D [-g <default_gid>] [-d <default_home>] [-s <defult_shell>]
[-u <min_uid>:<max_uid>] [-g <min_gid>:<max_gid>]
9.3.5.3 Options
The ldapugadd tool supports the following command options:
-P
Prompts for the administrator bind identity (typically LDAP DN or Kerberos principal) and
bind password. If you do not specify the -P option, ldapugadd discovers the bind identity
and password from the environment variables LDAP_BINDDN and LDAP_BINDCRED.
Values set with a prompt (-P) option override values specified in the environment variable.
If the LDAP_BINDDN and LDAP_BINDCRED environment variables have not been specified,
ldapugadd uses the bind configuration specified in the LDAP-UX configuration profile. If
the LDAP-UX configuration profile has specified the “proxy” bind, ldapugadd reads the
bind credential from either the /etc/opt/ldapux/acred or /etc/opt/ldapux/
pcred file. The /etc/opt/ldapux/acred file is only used by users that have sufficient
administrative privilege to read this file.
-PP
Prompts for the password of the user or group being created. If attribute mapping for the
userPassword attribute in the LDAP-UX configuration profile has not been defined or
set to *NULL*, ldapugadd creates anew password in the userPassword attribute. To
ensure accuracy, the user is prompted twice for the password. The ldapugadd tool relies
on the LDAP directory server for setting of password policy, such as
user-must-change-password-at-first-login.
-PW
Sets the user or group password attribute. If attribute mapping for the userPassword
attribute in the LDAP-UX configuration profile has not been defined or set to *NULL*,
ldapugadd creates a new password in the userPassword attribute. If you specify -PW,
you must specify either the LDAP-UGCRED environment variable or the -PP option.
9.3 LDAP user and group management tools 297
-Z
Requires an SSL connection to the LDAP directory server, even if the LDAP-UX configuration
profile does not specify the use of SSL. Using the -Z option requires that you define either
a valid LDAP directory server or CA certificate in the /etc/opt/ldapux/cert8.db
file. An error occurs if the SSL connection cannot be established.
-ZZ
Attempts a TLS connection to the directory server, even if the LDAP-UX configuration profile
does not specify the use of TLS. If a TLS connection cannot be established, a nonTLS and
nonSSL connection will be established. HP recommends that you do not use -ZZ unless
alternative methods are used to protect from network eavesdropping. Use of -ZZ requires
that you define either a valid LDAP directory server or CA certificate in the /etc/opt/
ldapux/cert8.db file.
-ZZZ
Requires a TLS connection to the LDAP directory server, even if the LDAP-UX configuration
profile does not specify the use of TLS. Using the -ZZZ option requires that you define
either a valid directory server or CA certificate in the /etc/opt/ldapux/cert8.db
file. An error will occur if the TLS connection can not be established.
-F
Forces creation of new user or group entries even if the following error conditions occur:
•
The user name or group name already exists in the directory server.
•
The user ID or group ID number already exists in the directory server.
•
The shell specified with the -s option does not exist on the local system or is not an
executable.
•
You attempt to add a member to a group when that member is not defined in the
LDAP directory server.
Some directory servers perform their own attribute uniqueness checks. In this case, even
if you specify the -F option, ldapugadd is unable to add the new entry.
-S
Displays the distinguished name (DN) of the newly created entry.
9.3.5.4 Arguments
The following describes command arguments:
-h <hostname>
Specifies the host name and optional port number (hostname:port) of the
LDAP directory server. This option overrides the server list specified by the
LDAP-UX configuration profile. The <hostname> field supports specification
of IPv4 and IPv6 addresses. If you specify a port for an IPv6 address, you
must specify the IPv6 address in square-bracketed form. If the optional port
is unspecified, the port number defaults to 389 or 636 for SSL connections
(-Z).
-p <port>
Specifies the port number of the LDAP directory server to contact. The
ldapugadd tool ignores this option if the port number is specified in the
<hostname> parameter as part of the -h option.
-b <base>
This option overrides the value of the ${basedn} substitution construct used
in the respective template file. Instead of discovering the ${basedn} value
from the LDAP-UX configuration profile, the tool uses the value defined in the
<base> argument. See Section 9.3.5.6 (page 306) for additional information.
The <base> value is an LDAP distinguished name.
-t <type>
Specifies the service type of entry the ldapadd tool operates. The valid
service types of this argument are passwd and group. The passwd type
represents LDAP user entries that contain POSIX account-related information.
The group type represents LDAP group entries that contain POSIX
298 Command and tool reference
group-related information. If you do not specify this argument, ldapugadd
defaults to passwd.
The command line arguments that are applicable depend on the service
specified.
9.3.5.4.1 Arguments applicable to -D
Use the ldapugadd -D command to change local host default values for the UG tool configuration
parameters, uidNumber_range, gidNumber_range, user_gidnumber,
default_homeDirectroy and default_loginShell, in /etc/opt/ldapux/ldapug.conf
file.
The following is a list of valid arguments:
-D
Uses this option to permanently alter local host defaults in the
/etc/opt/ldapux/ldapug.conf file. The ldapugadd
tool uses these defaults when creating new user or group entries
in an LDAP directory server. Configuration changes using the
-D options change the default values in the LDAP UG tool
configuration file, /etc/opt/ldapux/ldapug.conf.
-u <min_uid>:<max_uid>
Sets new default minimum and maximum ranges that
ldapugadd uses when provisioning an UID number for newly
created user entries. The UID range is inclusive of the specified
end values.
-g <default_gid>
Specifies the default group ID number used when creating new
user entries. To avoid ldapugadd from displaying warning
messages, you must specify this group ID which represents a
POSIX-style group stored in the LDAP directory. If this group ID
is not defined in the LDAP directory, ldapugadd displays a
warning message every time it adds a new user using this
default group ID, because ldapugadd cannot add the user
as a member of that group.
-g <min_gid>:<max_gid>
Sets new default minimum and maximum ranges that
ldapugadd uses when provisioning a GID number for newly
created group entries. The GID range is inclusive of the
specified end values. Use the colon character to indicate that
a range has been specified.
-s <default_shell>
Specifies the default login shell to use when creating new user
entries.
-d <default_home>
Specifies the default parent home directory to use when creating
new user home directories.
9.3.5.4.2 Arguments applicable to -t passwd
The following is a list of valid arguments for -t passwd:
<uid_name>
Required. Specifies the POSIX style login name for the new user
entry. This user name must conform to HP-UX login name
requirements. For more information about login name requirements,
see passwd(4) manpage. The <uid_name> argument is a required
parameter. This argument must follow all command-line options
and must precede the <attr>=<value> parameters (if provided).
-f <full_name>
Optional. This option is required only for the passwd service and
is used to specify the user’s full name. If you do not specify this
argument, the user's full name defaults to the account name.
9.3 LDAP user and group management tools 299
-u <uid_number>
Optional. Specifies the user’s numeric ID number. If the specified
uidNumber value already exists in the directory server,
ldapugadd does not add the new entry and returns an error
status, unless you specify the -F option.
If this argument is not specified, ldapugadd randomly selects a
new user ID number from the uidNumber range specified by the
ldapugadd -D -u command. If you do not specify the
uidNumber range with the ldapugadd -D -u command,
ldapugadd randomly selects a value from default UID range
specified in the /etc/opt/lapux/ldapug.conf file. If
ldapugadd randomly selects a uidNumber that is already in use
on the directory server, ldapugadd then randomly selects another
uidNumber and tries again until it finds an unused uidNumber or
exhausts retry attempts. Retry attempts are limited to 90% of the
range of available uidNumbers (specified with -D -u
<min_uid>:<max_uid>).
-g <group/gid>
Optional. Specifies the user's primary login group name or ID
number. After creating the user entry, ldapugadd attempts to
add the user as a member of the specified group using the
ldapugmod -t group command.
To support numeric group names, ldapugadd always attempts
to resolve the specified argument as a group name (even if it is a
numeric string). If the specified argument is not found as a group
name, ldapugadd determines whether the argument is a numeric
string and if so, uses that as the group ID number. If that numeric
group cannot be found in any active name service repository,
ldapugadd issues an ERROR message. If the specific argument
is not numeric and can not be found in an active name service
repository, ldapugadd exits with an ERROR and does not create
the new entry.
If you do not specify this argument, the user becomes a member
of the default login group as specified by the ldapugadd -D
-g <default_gid> command.
-G <group/gid>[,...]
300 Command and tool reference
Optional. Specifies the user's alternate group memberships.
<group/gid> is the POSIX group name or the group ID number.
The specified <group> name must exist in the directory server (not
in the /etc/group file). If the specified group name is invalid
or does not exist in the directory server, ldapugadd issues a
warning message for each invalid group. To support numeric
group names, ldapugadd always attempts to resolve the specified
argument as a group name (even if it is a numeric string). If the
specified argument is not found as a group name, ldapugadd
determines whether the argument is a numeric string and if so,
use that as the group ID number. Only if the user entry is
successfully created , ldapuguadd will call the ldapugmod -t
group for each <group> specified to add the user to listed groups.
If you specify more than one group, you must separate each group
by a comma. No white space is allowed between or within group
names. If ldapugadd fails to add the user as a member of a
particular group, ldapugadd issues a warning message and
continues to add the user to the remaining groups specified.
If you do not specify this argument, ldapugadd does not add
the user to alternate groups.
-s <login_shell>
Optional. Specifies the full path name to the executable that is
used to handle login sessions for this user.
If this argument is not specified, the default, as configured by the
ldapugadd -D -s <default_shell> command, is used.
-d <home_directory>
Optional. Specifies the full path name (including the user name)
of the user’s home directory.
If you do not specify this argument, the combination of the default
base directory as configured by ldapugadd -D -d
<home_directory> and the user’s account name is used. If you
want to create the home directory on this system, you must specify
the -m option.
-I <gecos>
Optional. Specifies GECOS fields for the user. Typically the GECOS
argument contains the following four fields which represent (in
order):
•
The user’s full name
•
The user’s work location
•
The user’s work telephone number
•
The user’s home telephone number (often omitted)
You must separate each field in the <gecos> argument by a
comma. If the data within the <gecos> argument contains any
white space or other characters that may be parsed by the shell,
you must protect the entire string by enclosing quotes. White space
cannot be used between the each field and the separating
commas.
LDAP-UX supports attribute mapping of the gecos attribute to
multiple attributes. If attribute mapping has been specified in the
LDAP-UX configuration profile, each field is mapped to its
representative attribute, in the order specified.
9.3 LDAP user and group management tools 301
If you do not specify the -I option, ldapugadd does not add
the <gecos> attribute to the user entry.
WARNING!
If you specify the -I option and you have defined
attribute mapping for the gecos attribute, be careful not to specify
the same attributes in the command line that are also used in the
gecos map. In the following example, if the gecos attribute has
been mapped to cn, l, and telephoneNumber. Because -f
represents the cn attribute when creating new user account entry,
the following command can produce unpredictable results because
cn is specified by both -f and the gecos mapping.
ldapugadd -f “Jim Bailey” -I “Jim
Bailey,Boston,555-1234” jbailey \
“sn=Bailey” “telePhoneNumber=555-1234”
In this example, because of the gecos attribute mapping, the cn
and telephoneNumber attributes are specified twice. The
ldapugadd tool results an error when the same attribute and
value are added to the directory server.
Use the ldapcfinfo tool to determine gecos attribute mapping
configuration.
NOTE: Because the gecos attribute may be mapped to one or
more attributes, the number of values specified with -I (between
the commas) should, but is not required to, match the number of
mapped attributes. If there are more mapped attributes than
specified values in -I, then trailing mapped attributes are not
added to the directory server. If more values than mapped
attributes exist, extra values are combined in the last mapped
attribute.
-c <comment>
Optional. Specifies a comment that will be stored in the
description attribute as defined by RFC 2307. LDAP-UX does
not support attribute mappings for the description attribute. If
you do not specify this option, the description attribute is not
added to the user entry. Because the field often contains white
spaces, you must protect it from shell parsing by enclosing it in
quote characters. For example:
-c “example description”
-T <template_file>
Optional. Specifies the LDIF template file to be used to create new
user entries. The <template_file> parameter may be a full or
relative path name or a short name. A short name is defined as
the distinguishing portion of the template file name. For example,
for the passwd service, if the short name “operator” is specified,
the resulting template file is /etc/opt/ldapux/
ug_templates/ug_passwd_operator.tmpl. All LDAP-UX
default template files are stored in the /etc/opt/ldapux/
ug_templates directory. A full or relative path name must begin
with a slash (/) or a period (.) character.
If you do not specify this argument, ldapugadd uses the default
template file /etc/opt/ldapux/ug_templates/
ug_passwd_default.tmpl.
302 Command and tool reference
-x <domain>
Optional. Specifies the user’s domain name. Use this option to
specify the ${domain} value that can be used in the template
file. If you do not specify this value, the domain name is created
by using the first dc component of the new user’s distinguished
name. If the distinguished name does not contain any dc
components, and the ${domain} variable is specified in the
template file, ldapugadd generates an error.
-m
Optional. Creates a new home directory for the defined user. User
and group ownership of the newly created directory is assigned
to the user and his/her primary login group.
If the -k option is specified, the files and sub-directories found in
<skel_dir> are copied to the user’s home directory, and user
and group ownership permissions are altered as specified
previously. If the -k option is not specified, skeleton files are
copied from /etc/skel.
The -m option requires the user has sufficient privilege to create
the new home directory, copy skeleton files and change ownership
of those files and directories. The ldapugadd tool creates a user’s
home directory only after successfully adding the user entry to the
directory server and adding the user to the primary and secondary
groups. If ldapugadd is unable to properly create the user’s home
directory using the previously-described process, the newly created
changes in the directory server are not removed. For more
information, see Section 9.3.5.7 (page 309).
-k <skel_dir>
Optional. The ldapugadd tool ignores the -k option unless you
specify the -m option. The <skel_dir> argument specifies a
directory which contains skeleton files and directories that need
to be copied into newly created user home directories. Also see
-m.
<attr>=<value>[...]
Optional. Enables specification of arbitrary LDAP attributes and
values. Because of potential object class requirements, you might
need to specify additional information beyond the basic POSIX
account and group data to create new entries in the LDAP directory
server. For example, if the person object class is used as a
structural class for posixAccounts, then the sn (surname)
attribute must be specified to properly create a new entry. This
attribute needs to be defined in the template file, and
attribute/value pair needs to be specified at the end of the
ldapugadd command line.
The<attr>=<value> parameter is used to specify attributes
required by the template file. However, if an attribute is specified
which is not defined in the defined template file, that
attribute/value pair is considered as an optional attribute/value
which will be added to the entry exactly as specified.
<attr>=<value> parameters are optional, but you must specify
them as the last parameters on the command line.
9.3.5.4.3 Arguments applicable to -t group
The following is a list of valid arguments for -t group:
<group_name>
Required argument. Specifies the POSIX textual style group name for
the new group entry. <group_name> is a required argument. It must
9.3 LDAP user and group management tools 303
follow all command line options and must precede the
<atr>=<value> parameters if provided. This group name must
conform to HP-UX group name requirements. For more information
about group name requirements, see the group(4) manpage.
-g <gidNumber>
Optional. Specifies the group ID number. If the specified gidNumber
already exists in the directory server, ldapugadd does not add the
new entry and return an error status, unless the -F option is specified.
If you do not specify this argument, ldapugadd provisions a new
group ID number by randomly selecting a value from the gidNumber
range specified by the ldapugadd -D -g
<min_gid>:<max_gid> command. If ldapugadd randomly selects
a gidNumber that is already in use on the LDAP directory server,
ldapugadd randomly selects another gidNumber and tries again
until it finds an unused gidNumber or exhausts retry attempts. Retry
attempts are limited to 90% of the range of available gidNumbers
(specified with -D -g <min_gid>:<max_gid>).
-x <domain>
Optional. Specifies the group's domain name. Use this option to
specify the ${domain} value that can be used in the template file.
If you do not specify this value, the domain name is created by using
the first dc component of the new group's distinguished name. If the
distinguished name does not contain any dc components, and the
${domain} variable is specified in the template file, ldapugadd
generates an error.
-M <member>
Optional. Defines initial group membership by adding the specified
user accounts as members. If you specify more than one member,
you must separate each account name by a comma. No white space
is allowed between or within account names. Use of -M requires that
the specified user’s account is already defined in the LDAP directory
server, unless the -F option is specified. When you use the -F
option, the user's group membership is defined using the memberUid
attribute, regardless of the attribute mapping configuration defined
by the LDAP-UX configuration profile. Use of the -F option is not
recommended, and will not succeed if the directory server does not
support the memberUid attribute.
The ldapugadd tool follows the same membership syntax as defined
by the LDAP_UX configuration profile attribute mapping. Specifically,
if the LDAP-UX has mapped the RFC 2307 group membership
attribute, memberUid, to a DN-based membership attribute such as
member or uniqueMember, then ldapugadd defines membership
using the DN of the specified user. If the memberUid attribute has
been mapped to more than one attribute type, ldapugadd uses the
first attribute defined by the mapping.
NOTE: If the ldapugadd tool can only add members that follow
a static membership syntax (such as memberUid, member and
uniqueMember) to a group. The ldapugadd tool will fail if the only
mapping defined by the LDAP-UX configuration profile uses a dynamic
group membership syntax (such as memberURL).
-c <comment>
304 Command and tool reference
Optional. Specifies a comment that is stored in the description
attribute as defined by RFC 2307. LDAP-UX does not support attribute
mappings for the description attribute. If you do not specify this
option, the description attribute is not added to the group entry.
-T <template_file>
Optional. Specifies the LDIF template file that is used to create new
group entries. If you do not specify the -T option, ldapugadd uses
the default template file either /etc/opt/ldapux/ug_templates/
ug_passwd_default.tmpl or /etc/opt/ldapux/
ug_templates/ug_group_default.tmpl depending on the
service type you specify (-t passwd or -t group).
The <template_file> parameter can be either a full or relative
path name or a short name. For more information, see
Section 9.3.5.6 (page 306).
<attr>=<value>
Optional. Enables specification of arbitrary LDAP attributes and
values. Because of potential object class requirements, you might
need to specify additional information beyond the basic POSIX
account and group data to create new entries in the LDAP directory
server. For example, if the person object class is used as a structural
class for posixAccounts, then the sn (surname) attribute must be
specified in order to properly create a new entry.
This attribute needs to be defined in the template file, and
attribute/value pair needs to be specified on the ldapugadd
command line. The <attr>=<value> parameter is used to specify
attributes required by the template file. However, if you specify an
attribute that is not defined in the defined template file, that
attribute/value pair is considered as an optional attribute/value and
will be added to the entry exactly as specified.
<attr>=<value> parameters are optional, but you must specify
them as the last parameters on the command line.
9.3.5.5 LDAP User and Group (UG) tool configuration file
The local configuration file /etc/opt/ldapux/ldapug.conf is used by the ldapugadd tool
to manage the following default values when creating new user and group entries in an LDAP
directory server:
•
A default group ID for new users.
•
The valid UID number range for new users.
•
The valid GID number range for new groups.
•
The base path for a new user's home directory. By default, LDAP-UX appends the user's account
name to the base path to create the full path name.
•
The default login shell for new users.
LDAP-UX provides the default ldapug.conf file as follows:
#
# This file is used by the ldapugadd tool for management
# of default values for creating new user and group entries.
# This file can not be modified directly, but instead through
# the ldapugadd -D command.
#
uidNumber_range=100:20000
gidNumber_range=100:2000
default_gidNumber=20
default_homeDirectory=/home
default_loginShell=/usr/bin/sh
9.3 LDAP user and group management tools 305
NOTE: You can not modify the ldapug.conf file directly. To change the local host default
values defined in the /etc/opt/ldapux/ldapug.conf, you must use the ldapugadd -D
command with applicable command options to alter them. For more information about this command
option, see Section 9.3.5.4.1 (page 299).
9.3.5.6 Template files
Template files define user and group entries that enable ldapugadd to discover the required data
models for new user and group entries. Template files define the object classes and attributes
required to create new user and group entries and enable ldapugadd to discover required
attributes and data elements before creating the entries. LDAP-UX provides customers the flexibility
that enables each directory deployment to define unique data models for users and groups when
adding new entries to an LDAP directory server.
9.3.5.6.1 Template file naming
The ldapugadd tool supports multiple template files per name service. LDAP-UX only supports the
passwd and group services. All template files are stored in the /etc/opt/ldapux/
ug_templates directory. Define the template file name using the following format:
ug_serviceName_Name.tmpl
Where
serviceName
Name
Is the name of the supported service, either passwd or group.
Is the arbitrary name of the specific template file. The name, default, is
reserved as the default template name and is used when a specific template
name is not specified.
For example, ug_passwd_default.tmpl is the default template file for the passwd name
service and ug_group_default.tmpl is the default template file for the group name service.
ug_passwd_vpn_user.tmpl may be used when creating new users of “VPN” type. Template
files stored outside of the ug_templates directory do not need to follow any specific format
described previously.
When specifying the name of a template file as part of the -T option on the command line, either
the exact file name or a short name may be used. The file name can be either a full or a relative
path name, but it must begin with a slash (/) or a period (.) character. That file name can exist
anywhere in the file system.
When specifying a short name, the file must exist under the /etc/opt/ldapux/ug_templates
directory and must follow the format specified previously. A short name is defined as the
distinguishing portion of the template file name. For example, if you define the short name “operator”
for the passwd service, the template file can be /etc/opt/ldapux/ug_templates/
ug_passwd_operator.tmpl. All LDAP-UX default template files are stored in the /etc/opt/
ldapux/ug_templates directory. A full or relative path name must begin with a slash (/) or a
period (.) character.
If you do not specify the -T option, ldapugadd uses the default template file either /etc/opt/
ldapux/ug_templates/ug_passwd_default.tmpl or /etc/opt/ldapux/
ug_templates/ug_group_default.tmpl, depending on the service type you specify (-t
passwd or -t group).
9.3.5.6.2 Default template files
The LDAP-UX Integration product provides two default template files for a standard directory server
for a passwd and group service entry.
Default template files for a standard directory server
The following is a default template file for the passwd name service.
306 Command and tool reference
NOTE: The template file used by the guided installation (autosetup) differs from this one: its
template file excludes ou=people from the first line because that subtree is directly registered in
the configuration profile.
dn: uid=${uid},ou=people,${basedn}
objectclass: inetOrgPerson
objectclass: posixAccount
sn: ${surname}
${posixProfile}
The following is a default template for the group name service:
NOTE: The template file used by the guided installation (autosetup) differs from this one: its
template file excludes ou=groups from the first line because that subtree is directly registered in
the configuration profile.
dn: cn=${cn},ou=groups,${basedn}
objectclass: groupOfNames
objectclass: posixGroup
${posixProfile}
Default template files for a Windows ADS
The following is a default template for the passwd name service:
NOTE: The template files used by the guided installation (autosetup) differ from these two: its
template files exclude cn=users from the first line because that subtree is directly registered in
the configuration profile.
dn: cn=${cn},cn=users,${basedn}
objectclass: user
${posixProfile}
sAMAccountName: ${uid}
msSFU30NisDomain: ${domain}
#By default, ldapugadd creates disabled accounts.
#Change below to 544 to enable accounts by default.
userAccountControl: 546
The following is a default template for the group name service:
dn: cn=${cn},cn=users,${basedn}
objectclass: group
${posixProfile}
sAMAccountName: ${cn}
msSFU30NisDomain: ${domain}
LDAP-UX provides two default templates file (for user and group entries) for a standard LDAP
directory server, along with two default template files for Windows Active Directory Server under
the /etc/opt/ldapux/ug_templates directory. By default, LDAP-UX creates the symbolic
links for two default template files, /etc/opt/ldapux/ug_templates/
ug_passwd_default.tmpl that points to /etc/opt/ldapux/ug_templates/
ug_passwd_std.tmpl and /etc/opt/ldapux/ug_templates/ug_group_default.tmpl
that points to /etc/opt/ldapux/ug_templates/ug_group_std.tmpl for a standard LDAP
directory server.
For detailed information on how to use the correct format to define template files, see
Section 9.3.5.6.3 (page 308).
9.3 LDAP user and group management tools 307
9.3.5.6.3 Defining template files
Defined substitution constructs
Each template file must follow the LDIF data format and also permit substitution of values from the
ldapugadd command. Each template file can be built using custom RFC 2307–type attributes
and values. Customized attribute values are defined using the ${<name>} construct. The LDAP-UX
supports several predefined substitution constructs, ${<name>}, where <name> represents:
posixProfile
Represents all RFC 2307-type attributes and values for the particular name
service (either passwd or group). If LDAP-UX configuration has defined attribute
mapping for particular attributes, the mapped attributes are substituted in its
place. When you use the posixProfile construct for posixAccount-type
entries, LDAP-UX will add the following attributes and values to the new user
entry:
•
cn
•
uid
•
userPassword
•
uidNumber
•
gidNumber
•
gecos
•
homeDirectory
•
loginShell
When you use the posixProfile construct with posixGroup-type entries,
LDAP-UX will add the following attributes and values to the new group entry:
•
cn
•
userPassword
•
gidNumber
•
memberUid
NOTE: Because use of posixProfile supports attribute mapping, if the
preceding attributes have been mapped as configured in the LDAP-UX
configuration profile, the mapped attributes and values are added to the entry
instead of the RFC 2307–defined attributes. For example, if the posixAccount
attribute gecos has been mapped to cn, l and telephoneNumber then
LDAP-UX adds cn, l and telephoneNumber information to the entry instead
of gecos. If the posixGroup attribute memberUid has been mapped to
uniqueMember, then LDAP-UX adds uniqueMember information to the entry
instead of memberUid.
basedn
Represents the substitution of the distinguished name of the default search base
(defaultSearchBase) as defined in the LDAP-UX configuration profile.
uid
Represents the user’s account name when used in a passwd template file.
uidNumber
Represents the user’s account ID number when you define it in a passwd
template file for the new user entry.
cn
Represents the users’s full name when you define it in a passwd template file.
Represents the group name when you define it in a group template file.
gidNumber
Represents the group ID number when you specify it in a group template file
for the new group entry.
308 Command and tool reference
In addition, comments are allowed. Comments are on a separate line and the first character is the
# (hash) character.
Guidelines for template files
Use the following guidelines when creating template files:
•
Use the first line of the template file to define the distinguished name (DN) of the new entry.
Because each DN is unique, the first component of the DN (the relative distinguished name
or RDN) must be able to construct a unique value for each new entry. Define the RDN using
a ${<name>} construct. Typically, you can use the cn or uid attribute in the RDN for new
user entries and the cn attribute for new group entries.
•
Define each template file for only one entry in the LDAP directory server.
•
Each template file can be built using custom attributes and values. Customized attribute values
are defined using the ${<name>} construct. However, for each nonRFC 2307 attribute used,
you must specify each of those attributes on the command line with an “<attr>=<value>”
pair argument when using ldapugadd to create a new entry.
For example, the following command adds the nonRFC 2307 addtribute and value pair,
sn=Michael, with the UID name Mhu to a new user entry based on the default template file,
ug_passwd_default.tmpl:
ldapugadd -t passwd -f "Michael Hu" Mhu -c "an example user entry" "sn=Michael"
•
Each template file can contain comment lines. Each comment line must begin with the “#”
character.
•
Do not specify the userPassword attribute in the template file. Use the -PP option or the
LDAP_UGCRED environment variable to specify an initial password of the user or group being
created.
•
You cannot specify the memberUid attribute in the template file, because the number of
eventual members of a group can not be statically defined when the group is newly created.
The ldapugadd tool ignores the memberUid attribute if specified in the template file.
9.3.5.6.4 Multi-valued attributes in template files
LDAP-UX supports multi-valued attributes defined in a template file. This means that the same attribute
name or value may be specified more than once in the template file.
For example, in the following template file, secondaryTeams is a multi-valued attribute that may
be specified twice for each new posixAccount entry created. In this case, ldapugadd will fill each
attribute value in order specified in the template file based on the order that those attributes are
specified on the command line. If not enough attribute values are specified on the command line
to fill the attribute values used in the template file, ldapugadd returns an error.
dn: uid=${uid},ou=people,${basedn}
objectclass: person
objectclass: myOrg
objectclass: posixAccount
sn: ${sn}
primaryTeam: ${primaryTeam}
secondaryTeams: ${secondaryTeams}
secondaryTeams: ${secondaryTeams}
${posixProfile}
9.3.5.7 Security considerations
The following are security considerations when using ldapugadd:
•
Use of ldapugadd requires permissions of an LDAP administrator when it performs its
operations on the directory server. The rights for creation of new LDAP directory entries under
9.3 LDAP user and group management tools 309
the requested subtree, along with creation of the required attributes in that entry must be
granted to the LDAP administrator identity when executing ldapugadd.
•
As with any POSIX-type identity, the HP-UX operating system uses the specified user and group
ID number to determine rights and capabilities in the OS and in the file system. For example,
the root user ID 0, typically has unlimited OS administration and file access rights. Before
creating a new entry, you must be aware of the selected user and group ID number and any
policy that might be associated with that ID.
•
If you use ldapugadd to randomly assign a user or group ID number, it only searches for ID
collisions found in the LDAP directory server, and not other policy repositories. When you set
user and group ID number ranges by using the -D -u or -D -g option, you must set a range
that is not used by other user or group ID repositories, and ensure that collisions will not occur
with existing users or groups that exist in other repositories.
•
Modification of this identity repository will likely have impacts as defined by the organization’s
security policy. Users of ldapugadd are expected to have full knowledge of the impact to
the organization’s security policy when adding new identity information to that identity
repository.
9.3.5.8 Specific return codes for ldapugadd
The ldapugadd tool returns a list of return codes shown in Table 29.
Table 29 Return codes for ldapugadd
Return Code
Message
ADD_USER_TO_GRP_FAILED
Failed to add a user to the group.
ADD_SKELDIR_DOESNOT_EXIST
Specified Skeleton directory does not exist.
ADD_SETENV_FAILED
The ldapugadd tool failed the internal putenv function
call with the specified bind environment variable, it returns
this error.
ADD_INFO_MISSING
Information is missing. For examples, UID number is
missing, group number is missing.
ADD_GETNUM_FAILED
Failed to get a valid gid number or UID number when
creating a new user or group entry.
ADD_SYNTAX_ERR
A syntax error exists in the specified template file.
ADD_ATTR_REQUIRED
Attribute is required. For examples, attribute “sn” is
required, attribute “telephonenumber” is required.
ADD_NUM_RANGE_ERR
Specified option has invalid range value. For example,
option -u has invalid range value.
ADD_WRONG_G_OPT
Option -g <default_gid> or -g
<min_gid>:<max_gid> has been specified more than
once.
ADD_NOT_PERMIT
You do not have the permission to alter
/etc/opt/ldapux/ldapug.conf.
ADD_INVALID_KEYWORD
The specified keyword value is invalid, ldapugadd
ignored the keyword. For example, if /usr/bin/jsh
does not exist in the system, the ldapugadd -D -s
/usr/bin/jsh command displays the following warnings:
WARNING: LOGIN_SHELL_DOESNOT_EXIST:
Login shell /usr/bin/jsh' does not exist.
WARNING: ADD_INVALID_KEY
Invalid keyword (default_loginShell),
ignored.
310
Command and tool reference
Table 29 Return codes for ldapugadd (continued)
ADD_RENAME_FAILED
Failed to rename the internal temporary file to /etc/opt/
ldapux/ldapug.conf.
ADD_UPDATE_OK
A specific operation has been updated successfully. For
example, “uidnumber_range” defined in ldapug.conf
has been updated successfully.
ADD_K_IGNORED
Option -m is not specified, therefore, -k ignored when
adding a new account.
ADD_TWO_DN_ERR
DN has been specified more than once.
ADD_GID_GNAME_ERR
Options -g and -e cannot be specified at the same time.
ADD_NOT_IN_LDAP
The specified group does not exist in the LDAP directory.
Could not add a user to the specified group.
ADD_FAIL_TO_UPDATE
Failed to update the default value in /etc/opt/
ldapuux_ldapug.conf.
ADD_FAILED
The LDAP add operation failed.
9.3.5.9 Limitations
The following are limitations of ldapugadd:
•
Because LDAP directory servers require data to be stored according to the UTF-8 (RFC3629)
character encoding method, all characters passed into ldapugadd are assumed to UTF-8,
and part of the ISO-10646 character set. ldapugadd does not perform conversion of the
locale character set to and from the UTF-8 character set.
•
Because ldapugadd calls functions to discover if the group exists before adding a user to a
group, it is possible to encounter timing issues with cached information. For example, if an
administrator uses the grget command to see if a group exists, this group information is
cached by both ldapclientd (1M) and pwgrd(1M). If the group does not exist when
calling grget, and the administrator shortly creates this group with ldapugadd, the
information that the group still does not exist will still be cached. Then, when adding a new
user and specifying that this user is a member of the just created group, ldapugadd generates
an error to indicate that the user cannot be added to the group. To resolve this, you must flush
the pwgrd and ldapclientd caches.
9.3.5.10 Examples
This section provides examples of using the ldapugadd tool:
The following commands specify the LDAP_BINDDN and LDAP_BINDCRED environment variables:
export LDAP_BINDDN = "cn=Jane Admin,ou=admins,dc=example,dc=com"
export LDAP_BINDCRED = "Jane's Password"
The following command specifies the LDAP_UGCRED environment variable:
export LDAP_UGCRED = "user_password"
Run the following commands to discover what nonPOSIX attributes defined in the default template
file are required to create the new user entry:
cd /opt/ldapux/bin
./ldapcfinfo -t passwd -R
The output of the commands is as follows:
Surname
The following commands add an account entry for the user, alam, with the user's primary login
group id, 300, and the surname, Lam. The ldapugadd tool creates the password for new user,
alam, using the user password specified in the LDAP_UGCRED environment variable. After creating
9.3 LDAP user and group management tools
311
the user entry, ldapugadd attempts to add this user as a member of the group number 300. The
uidNumber value is assigned dynamically from the preconfigured range.
cd /opt/ldapux/bin
./ldapugadd -t passwd -PW -f "Adrian Lam" -g 300 alam surname="Lam"
Run the following command to display the new user entry, alam:
./ldapuglist -t passwd -n alam sn
The following is the user entry:
dn: cn=Adrian Lam,ou=people,dc=example,dc=com
cn: Adrian Lam
uid: alam
uidNumber: 2200
gidNumber: 300
homeDirectory: /home/alam
loginShell: /usr/bin/ksh
sn: Lam
The following command adds an account entry for the user, mscott, with the user's primary login
group id, 200, and gecos field information. In this example, the gecos attribute has been mapped
to cn, l and telephoneNumber in the LDAP-UX configuration profile. ldapugadd creates the
password for new user, mscott, using the password specified in the LDAP_UGCRED environment
variable. After creating the user entry, ldapugadd attempts to add this user as a member of the
group number 200.
./ldapugadd -t passwd -PW -g 200 \
-I "Mike Scott,Building-3A,555-555-5555" mscott surname="Scott"
Use the following command to display the new user entry, mscott, with mapped attribute
information:
./ldapuglist -t passwd -m -n mscott
The following is the user entry:
dn: cn=Mike Scott,ou=people,dc=example,dc=com
cn[cn]: Mike Scott
uid[uid]: mscott
uidNumber[uidnumber]: 2200
gidNumber[gidnumber]: 200
homeDirectory[homedirectory]: /home/mscott
loginShell[loginshell]: /usr/bin/sh
gecos[cn]: Mike Scott
gecos[l]: Building-3A
gecos[telephoneNumber]: 555-555-5555
The following command adds an account entry for the user, mwang, with the user's primary login
group id, 350. In this example, ldapugadd creates the user home directory /home/wang and
assigns user and group ownership of the newly created directory to the user mwang and his primary
login group after successfully adding the user entry to the directory server and adding the user to
the primary login group. ldapugadd uses the password specified in the LDAP_UGCRED environment
variable to create the password for the new user, mwang.
./ldapugadd -t passwd -PW -f "Mike Wang" -g 350 \
-m -d "/home/wang" mwang surname="Wang"
Use the following command to display the new user entry, mwang:
./ldapuglist -t passwd -n mwang sn
The output of the user entry is as follows:
dn: cn=Mike Wang,ou=people,dc=example,dc=com
cn: Mike Wang
uid: mwang
uidNumber: 2255
gidNumber: 350
312
Command and tool reference
homeDirectory: /home/wang
loginShell: /usr/bin/sh
sn: Wang
The following command adds a new group entry for the group name, groupA. In this example,
ldapugadd creates the new group, groupA, and defines the initial group membership by adding
the user account, mwang, as a member.
./ldapugadd -t group -M mwang groupA
Use the following command to display the new group entry, groupA:
./ldapuglist -t group -f "(cn=groupA)"
The output of the group entry is as follows:
dn: cn=groupA,ou=Group,dc=example,dc=com
cn: groupA
gidNumber: 550
memberUid: mwang
The following command sets new default minimum and maximum ranges of UID numbers in the
local configuration file, /etc/opt/ldapux/ldapug.conf. When creating a new user account,
the ldapugadd tool randomly selects a new ID from this range if an account number has not been
specified.
./ldapugadd -D -t passwd -u 200:5000
The following command sets new default minimum and maximum ranges of GID numbers in the
local configuration file, /etc/opt/ldapux/ldapug.conf. When creating a new group, the
ldapugadd tool randomly selects a new ID from this range if a group number has not been
specified.
./ldapugadd -D -t group -g 300:3000
The following command sets the new default group ID number in the local configuration file, /etc/
opt/ldapux/ldapug.conf. The ldapugadd tool uses this value when creating a new user
entry in an LDAP directory server.
./ldapugadd -D -t passwd -g 500
The following command sets the new default login shell in the local configuration file, /etc/opt/
ldapux/ldapug.conf. The ldapugadd tool uses this login shell when creating a new user
entry in an LDAP directory server.
./ldapugadd -D -t passwd -s /usr/net/bin/sh
Run the following commands to unset the LDAP_BINDDN, LDAP_BINDCRED and LDAP_UGCRED
environment variables:
unset LDAP_BIND
unset LDAP_BINDCRED
unset LDAP_UGCRED
9.3.6 The ldapugmod tool
The ldapugmod tool enables HP-UX administrators to modify existing POSIX accounts or groups
in an LDAP directory server. When using extended options, you can use ldapugmod to modify
arbitrary attributes for user or group entries or you can extend existing user or group entries with
the POSIX data model. To use ldapugmod, you must provide LDAP administrator credentials that
have sufficient privilege to perform the user or group modification operations in the LDAP directory
server.
9.3.6.1 Synopsis
ldapugmod [-t passwd] [options] [-h <hostname>] [-p <port>]
[-f <full_name>] [-n <new_name>] [-u <uid_number>] [-g <group/gid>]
[-s <login_shell] [-d <home_directory>[-m]] [-c <comment>] [-I <gecos>]
[[-A <attrval>][...]]
9.3 LDAP user and group management tools
313
[[-R <attrval>][...]] [-D <DN>|<uid_name>]
[[<attr>=<value>][...]]
ldapugmod -t group [options] [-h <hostname>] [-p <port>]
[-n new_name>] [-g <gid_number>] [-a <member>[,...]] [-r <member>[,...]]
[-c <comment>] [[-A <attrval>][...]][[-R <attrval>][...]]
[-D <DN>|<group_name>] [[<attr>=<value>][...]]
9.3.6.2 Options
The ldapugmod tool supports the following command options:
314
-P
Prompts for the administrator's bind identity (typically LDAP DN or Kerberos principal) and
bind password. If you do not specify the -P option, ldapugmod discovers the bind identity
and password from the environment variables LDAP_BINDDN and LDAP_BINDCRED. If
the LDAP_BINDDN and LDAP_BINDCRED environment variables have not been specified,
ldapugmod uses the bind configuration specified in the LDAP-UX configuration profile. If
the LDAP-UX configuration profile has specified the “proxy” bind, ldapugmod reads the
bind credential from either the /etc/opt/ldapux/acred or the /etc/opt/ldapux/
pcred file. The /etc/opt/ldapux/acred file is only used by users who have sufficient
administrative privilege to read this file.
-PP
Prompts for the password of the user or group being modified. If you do not specify the
-PP option, the ldapugmod tool retrieves the password for the modified user or group
from the LDAP_UGCRED environment variable if the -PW option is specified. Use of -PP
implies the use of -PW.
-PW
Changes the user or group password attribute. If attribute mapping for the userPassword
attribute in the LDAP-UX configuration profile has not been defined or set to *NULL*,
ldapugmod creates new passwords in the userPassword attribute. If you specify the
-PW option, you must also specify either the LDAP_UGCRED environment variable or the
-PP option.
-O
With ldapugmod, you can add posixAccount and posixGroup attributes to a user
or group entry that does not already contain the posixAccount or posixGroup object
class. This ability requires use of the -D option. With the -O option, ldapugmod attempts
to add the posixAccount or posixGroup object class and respective attributes
(depending on if the -t passwd or -t group option is specified) to the entry being
modified. When used with Microsoft Windows Active Directory service, if the user or
group entry is build using the abstract “User” or “Group” class, ldapugmod assumes that
the abstract class already includes the required Microsoft SFU attributes, and thus does
not add the posixAccount or posixGroup object class to the entry.
-Z
Requires an SSL connection to the LDAP directory server, even if the LDAP-UX configuration
profile does not specify the use of SSL. If you use the -Z option, you must define either a
valid directory server or CA certificate in the /etc/opt/ldapux/cert8.db file. An
error occurs if the SSL connection can not be established.
-ZZ
Attempts a TLS connection to the directory server, even if the LDAP-UX configuration does
not require the use of TLS. If a TLS connection cannot be established, a nonTLS and nonSSL
connection will be established. Do not use -ZZ unless alternative methods are used to
protect against network eavesdropping. Use of -ZZ requires that you define a valid server
or a CA certificate in the /etc/opt/ldapux/cert8.db file.
-ZZZ
Requires a TLS connection to the LDAP directory server, even if the LDAP-UX configuration
profile does not specify the use of TLS. Using the -ZZZ option requires that you define a
valid directory server or a CA certificate in the /etc/opt/ldapux/cert8.db file. An
error occurs if the TLS connection cannot be established.
-N
Allows you to rename the relative distinguished name (RDN) of an LDAP directory server.
In some cases, when an attribute is modified, it might be the same attribute that is used
Command and tool reference
in the RDN portion of the entry’s distinguished name. Changing the attribute and value
that is used in the RDN requires changing the RDN.
For example, an entry in the directory server is named “cn=Robert
Smith,ou=IT,dc=example,dc=com”. If the cn attribute is changed to “cn=Bob
Smith”, then the entry DN also needs to change to “cn=Bob
Smith,ou=IT,dc=example,dc=com”
Modification of an RDN is generally discouraged because the DN is often used as a
unique way to identify the entry in the directory server. Often DN is used to define
membership in a group. To prevent accidental changes to the DN, you must specify the
-N option to allow changes to the RDN. When the DN of an entry changes, the group
membership information for this entry might be inconsistent. Most directory servers have
the inherent ability to update all entries that refer to the updated DN of a changed entry.
Therefore, ldapugmod does not attempt to perform modifications to other entries in the
directory server that refer to this entry by its DN.
NOTE: The ldapugmod tool does not allow you to rename multi-valued RDNs. For
example, an RDN of “cn=test1+cn=test2” is not supported
-F
-S
Forces ldapugmod to modify the user or group entry in an LDAP directory server even if
particular error conditions occur. Those error conditions that can be overwritten are as
follows:
•
The changed user name or group name already exists in the directory server.
•
The changed user ID or group ID number already exists in the directory server.
•
An attempt is made to modify the group of a user with a group ID that cannot be
found in any name service repository. In this case, the group ID number must be
specified.
•
An attempt is made to force ldapugmod to add a member to a group when that
member is not defined in the LDAP directory server. In this case, membership is always
defined using the memberUid attribute, regardless of attribute mapping defined for
group membership.
Displays the Distinguish Name (DN) of the deleted or updated entry when the operation
successfully completes.
9.3.6.3 Arguments
The following describes command arguments:
-t <type>
Specifies whether the command-line arguments are applicable to modify the
user or group entry. The valid types of this argument are passwd and group.
If you do not specify this argument, ldapugmod defaults to passwd. The
passwd type represents LDAP user entries that contain POSIX account-related
information. The group type represents LDAP group entries that contain
POSIX group-related information.
-h <hostname>
Specifies the host name and optional port number (hostname:port) of the
LDAP directory server. This option overrides the server list specified by the
LDAP-UX configuration profile. This field supports specification of IPv4 and
IPv6 addresses. If you specify a port for an IPv6 address, you must specify
the IPv6 address in square-bracketed form. If you do not specify the optional
port, the port number defaults to 389 or 636 for SSL connections (-Z ).
-p <port>
Specifies the port number of the LDAP directory server to contact. The
ldapugadd tool ignores this option if you specify the port number in the
<hostname> parameter as part of the -h option.
9.3 LDAP user and group management tools
315
-D <DN>
The ldapugmod tool searches for the named user or group using the search
rules defined by the service search descriptor in the LDAP-UX configuration
profile. You can use the -D option to specify the exact distinguished name
(DN) of the entry being modified. If you specify the -D option, you do not
need to specify the <uid_name> or <group_name> parameter.
-A <attrval>
Specifies an attribute and value to be added to an entry. The format of
<attrval> is “attribute=value”, where attribute is the name of
the attribute to add, and value is the specific instance of that attribute.
When working with multi-valued attributes, you can use the -A option to add
a new value for a multi-valued attribute, without removing already existing
values for that attribute. The use of the -A parameter interacts with the
optional <attr>=<value> parameters. You may specify the -A option
more than once per command line. The value portion of the <attrval>
may be an empty string.
For example, if an entry in an LDAP directory is as follows:
dn: uid=mLee,ou=people,dc=example,dc=com
cn: Mark Lee
cn: Michael Lee
uid: mLee
uidNumber: 2200
gidNumber: 212
homeDirectory: /home/mLee
loginShell: /usr/bin/ksh
gecos: Mark Lee,San Jose,+1 555-555-5555
Perform the following ldapugmod command for the user entry, mLee:
ldapugmod -t passwd -A "cn=Mackey Lee" mLee
The preceding command adds an instance of the cn attribute, cn=Mackey
Lee to the entry. The following is the result of the mLee entry:
dn: uid=mLee,ou=people,ou=IT,dc=example,dc=com
cn: Mark Lee
cn: Michael Lee
cn: Mackey Lee
uid: mLee
uidNumber: 2200
gidNumber: 212
homeDirectory: /home/mLee
loginShell: /usr/bin/ksh gecos: Mark Lee,San Jose, +1
555-555-5072
316
-R <attrval>
Specifies an attribute or specific values of an attribute to be removed from
the entry. The format of <attrval> is attribute=value, where attribute
is the name of the attribute to remove, and value is a specific instance of
that attribute if the attribute is multi-valued. The use of the -R option interacts
with the optional <attr>=<value> parameters. For more information, see
the discussion of the <attr>=<value> option in Section 9.3.6.3.1
(page 317) and Section 9.3.6.3.2 (page 319). You may specify the -R option
more than once per command line.
-n <new_name>
Specifies the new name of the user or group. This option replaces the uid
attribute for user entries or the cn attribute for group entries with the new
name, or the mapped attribute if attribute mapping has been specified for
that attribute. The <new_name> argument specifies the new name of the
user or group. Using -n is the same as replacing the corresponding attribute.
For example, the following two commands perform the same operation,
replacing the old UID with new UID for a user entry (assuming no attribute
mapping) :
Command and tool reference
ldapugmod -t passwd -n newuid olduid
Is the same as:
ldapugmod -t passwd olduid "uid=newuid"
9.3.6.3.1 Options applicable to -t passwd
The following is a list of valid options for -t passwd:
<uid_name>
Required. Specifies the POSIX style login name of the user entry to
modify. You must specify the <uid_name> parameter unless you
specify the -D option. This user name must conform to HP-UX login
name requirements. For more information about login name
requirements, see the passwd(4) manpage.
-f <full_name>
Replaces the user’s full name. If is an empty string (a pair of double
quotes: ""), ldapugmod removes the cn (or mapped) attribute. For
information about impacts when using this option, see
Section 9.3.6.4 (page 320).
-u <uidNumber>
Replaces the user’s numeric ID number. If uidNumber is an empty
string (a pair of double quotes: ""), ldapugmod removes the
uidNumber or mapped attribute. If the specified uidNumber value
already exists in the directory server, ldapugmod does not modify
the entry and returns an error exit status, unless you specify the -F
option.
-g <group/gid>
Replaces the user's primary login group ID number. If
<group/gid> is an empty string (a pair of double quotes: ""),
ldapugmod will remove the gidNumber or mapped attribute. In
order to support numeric group names, ldapugmod treats the -g
argument as a group name. If ldapugmod cannot find a matched
numeric group name in the directory server, it determines whether
the value is numeric and then verifies that the specified group ID
number exists. If it does not exist, ldapugmod exits with an error,
unless you specify the -F option.
NOTE: The dapugmod tool does not modify the user’s group
membership when chaining the primary group ID. Adding the user
as a member of the new group and possibly removing the member
from the previous group must be done with separate ldapudmod
operations.
-s <login_shell>
Replaces the full path name to the executable that is used to handle
login sessions for this user.
If the <login_shell> argument is an empty string (a pair of
double quotes: ""), ldapugmod removes the loginShell or
mapped attribute.
The ldapudmod tool issues a WARNING if the specified login shell
does not exist on the local system. For information about impacts
when using this option, see Section 9.3.6.4 (page 320).
-d <home_directory>
Replaces the full path name (including the user name) of the user’s
home directory. If the <home_directory> argument is an empty
string (a pair of double quotes: ""), ldapugmod removes the
homeDirectory or mapped attribute.
-m
Move the user’s home directory to the location specified with the
-d option. -m requires that you also specify the -d option. If the
9.3 LDAP user and group management tools
317
specified <home_directory> already exists, the user’s current
home directory does not exist or the user running ldapugmod does
not have sufficient permissions to move the directory, ldapugmod
returns an error.
-I <gecos>
Replaces gecos fields for the user. If <gecos> is an empty string,
ldapugmod removes the gecos or mapped attributes.
Typically the gecos argument contains four fields which represent
in the following order:
•
The user’s full name
•
The user’s work location
•
The user’s work telephone number
•
The user’s home telephone number (often omitted)
Each field in the <gecos> argument must be separated by a
comma. Although the fields specified within the <gecos> argument
can contain white space (such as “Bill Smith,Building 6,555-1234”).
White space cannot be used between each field and the separating
commas.
LDAP-UX supports attribute mapping of the gecos field to multiple
attributes. If attribute mapping has been specified in the LDAP-UX
configuration profile, each field is mapped to its representative
attribute, in the order specified.
WARNING! If you specify the -I option and you have defined
attribute mapping for the gecos attribute, be careful not to specify
the same attributes in the command line that are also used in the
gecos map. In the following example, the gecos attribute has
been mapped to cn, l, and telephoneNumber attributes. The
following command can produce unpredictable results:
ldapugmod -I “lisa Hu,Austine,222-1234” lhu "cn=lisa
Hu” “sn=Hu”\
“telePhoneNumber=222-1234”
In the preceding example, because of the gecos attribute mapping,
the cn and telephoneNumber are specified twice, it results an
error when the same attribute and value are added to the directory
server. Use the ldapcfinfo tool to verify the gecos attribute
mapping configuration.
If the <gecos> argument is an empty string, ldapugmod removes
the gecos or mapped attributes. HP does not recommend that you
use the -I option, because the gecos attribute is often mapped to
required attributes. For information about impacts when using this
option, see Section 9.3.6.4 (page 320).
318
-c <comment>
Replaces a comment that will be stored in the description
attribute as defined by RFC 2307. LDAP-UX does not support
attribute mappings for the description attribute.
<attr>=<value>
Enables modification of arbitrary LDAP attributes and values. The
<value> parameter may be an empty string. However this usage
does not remove attributes and their values from the directory server.
Instead use the -R option to remove arbitrary attributes. For
Command and tool reference
information about impacts when using this option, see
Section 9.3.6.4 (page 320).
9.3.6.3.2 Options applicable to -t group
The following is a list of valid options for -t group:
<group_name>
Required. Specifies the POSIX style textual group name for the group
entry to modify. You must specify the group name if you do not specify
the -D option. This group name must conform to HP-UX group name
requirements. For more information about group name requirements,
see the group(4)manpage.
-g <gidNumber>
Replaces the group’s numeric ID number. If the specified gidNumber
value already exists in the directory server, ldapugmod does not
modify the group entry and return an error status, unless you specify
the -F option.
-a <member>[,...]
Adds one or more members to the specified group.
The ldapugmod tool follows the same membership syntax defined by
the LDAP-UX configuration profile attribute mapping. Specifically, if
LDAP-UX has mapped the RFC 2307 group membership attribute,
memberUid, to a DN-based membership attribute such as member
or uniqueMember, then ldapugmod defines membership using the
DN of the specified user. When specifying a list of members, you must
use a comma with no white space to separate each member. If the
memberUid attribute has been mapped to more than one attribute
type, ldapugmod uses the first attribute defined by the mapping. If
the specified <member> does not exist in the LDAP directory, you must
use -F to define the member, and only use the memberUid attribute
syntax.
NOTE: The ldapugmod tool can add members only to a group that
follow a static membership syntax (such as memberUid, member and
uniqueMember). If the only membership mapping defined in the
LDAP-UX configuration profile uses a dynamic group membership
syntax (such as memberURL), ldapugmod fails to add a member to
a group.
-r <member>[,...]
Removes one or more members from the specified group.
The ldapugmod tool searches for membership in the group using the
memberUid, member, uniqueMember, and msSFU30posixMember
attributes and removes all values that represent the specified user (either
DN or UID name). The ldapugmod tool consults the LDAP-UX
configuration profile for attribute mappings to determine which
attributes need to be modified to remove the user membership. When
specifying a list of members, you must use a comma with no white
space to separate each member.
-c <comment>
Replaces a comment that is stored in the description attribute as
defined by RFC 2307. LDAP-UX does not support attribute mappings
for the description attribute. If <comment> is an empty string,
ldapugmod removes the description or mapped attribute.
<attr>=<value>>
Enables modification of arbitrary LDAP attributes and values. The
<value> parameter may be an empty string. However this usage
does not remove attributes and their values from the directory server.
9.3 LDAP user and group management tools
319
Instead, use the -R option to remove arbitrary attributes. For information
about impacts when using this option, see Section 9.3.6.4 (page 320).
9.3.6.4 Warnings
Under common usage, ldapugmod uses the LDAP replace operation when changing values of an
attribute in an entry. This feature might impact attributes that have multiple values, by removing all
occurrences of an attribute value and replacing it with the one specified on the ldapugmod
command line. For example, if the -n argument is used to specify a new name for a posixGroup,
all occurances of the cn attribute are replaced by the value specified for the -n argument. This
mode of operation applies to all command argument specified values, including -u, -g, -s, -d,
-I and -c.
When you use the <attr>=<value> parameter to modify an existing attribute, the ldapugmod
command also uses the LDAP replace operation. The replace operation removes all occurrences
of the specified attribute for an entry and replaces it with the value specified. If there are multiple
values for a single attribute in an entry, the use of a single <attr>=<value> parameter will
replace all values with the single value specified on the command line. You may specify more than
one occurrence of the same attribute on the command line, if that attribute is multi-valued. In that
case, both values are created in the entry.
Use of -A or -R changes this behavior (for both the previously-listed command arguments and the
<attr>=<value> parameter). Any attribute specified as an argument to the -A or -R causes
ldapugmod to perform an LDAP add operation instead of an LDAP replace operation.
NOTE: The ldapugmod tool does not allow you to use the same attribute and value pair more
than once, either as part of <attr>=<value>, -R or -A, or with other command line options.
The ldapugmod tool exits with error status before sending any conflict modification request to the
LDAP directory server.
Example 1
In this example, an entry in an LDAP directory is as follows:
dn: uid=mLee,ou=people,dc=example,dc=com
cn: Mark Lee
cn: Michael Lee
uid: mlee
uidNumber: 2200
gidNumber: 212
homeDirectory: /home/mlee
loginShell: /usr/bin/ksh
gecos: Mark Lee,New York,555-666-6000
description: test user entry
description: multi-valued attribute entry
Perform the following ldapugmod command for the user entry, mlee:
cd /opt/ldapux/bin
./ldapugmod -t passwd mlee "cn=Mackey Lee"
The preceding commands replace all instances of cn with the single value, Mackey Lee. The
resulting mlee entry is as follows:
dn: uid=mLou,ou=people,dc=example,dc=com
cn: Mackey Lee
uid: mlee
uidNumber: 2200
gidNumber: 212
homeDirectory: /home/mlee
loginShell: /usr/bin/ksh
gecos: Mark Lee,New York,555-666-6000
description: test user entry
description: multi-valued attribute entry
320 Command and tool reference
Perform the following ldapugmod command for the user entry, mlee:
./ldapugmod -t passwd -c "Mackey user entry" mlee
This command replaces all instances of description with the single comment, Mackey user
entry. The result of the mlee entry is as follows:
dn: uid=mLou,ou=people,dc=example,dc=com
cn: Mackey Lee
uid: mlee
uidNumber: 2200
gidNumber: 212
homeDirectory: /home/mlee
loginShell: /usr/bin/ksh
gecos: Mark Lee,New York,555-666-6000
description: Mackey user entry
Example 2
In this example, the entry in an LDAP directory is as follows:
dn: uid=slou,ou=people,dc=example,dc=com
cn: Smith Lou
cn: Smitta Lou
uid: slou
uidNumber: 2500
gidNumber: 120
homeDirectory: /home/slou
loginShell: /usr/bin/ksh
gecos: Smith Lou,San Jose,+1 555-510-5000
Perform the following ldapugmod command for the user entry, slou:
./ldapugmod -t passwd -R "cn=Smitta Lou" slou "cn=Smitty Lou"
The preceding command removes the instance of Smitta Lou and replaces it with the value,
Smitty Lou. The resulting slou entry is as follows:
dn: uid=slou,ou=people,dc=example,dc=com
cn: Smith Lou
cn: Smitty Lou
uid: slou
uidNumber: 2500
gidNumber: 120
homeDirectory: /home/slou
loginShell: /usr/bin/ksh
gecos: Smith Lou,San Jose,+1 555-510-5000
Example 3
In this example, the entry in an LDAP directory is as follows:
dn: uid=jscott,ou=people,dc=example,dc=com
cn: John Scott
cn: Joe Scott
uid: jscott
uidNumber: 2500
gidNumber: 120
homeDirectory: /home/jscott
loginShell: /usr/bin/ksh
gecos: John Scott,San Jose,+1 555-555-5555
Perform the following ldapugmod command for the user entry, jscott:
./ldapugmod -t passwd -A "cn=Joesh Scott" jscott
This command adds an instance of the cn attribute, cn=Joesh Scott to the entry. The result of
the user entry is as follows:
dn: uid=jscott,ou=people,dc=example,dc=com
cn: John Scott
cn: Joe Scott
9.3 LDAP user and group management tools
321
cn: Joesh Scott
uid: jscott
uidNumber: 2500
gidNumber: 120
homeDirectory: /home/jscott
loginShell: /usr/bin/ksh
gecos: John Scott,San Jose,+1 555-555-5555
9.3.6.5 Specific return codes for ldapugmod
The ldapugmod tool returns a list of return codes shown in Table 30.
Table 30 Return codes for ldapugmod
Return Code
Message
MOD_CANNOT_GET_USER_HOMEDIR
Cannot discover user's home directory information.
MOD_COMMANDLINE_ERR
Members need to be specified for the specified option. For
exmaple,
ldapugmod -t group -r ""
The output of the command is as follows:
ERROR: MOD_COMMANDLINE_ERR:
member(s) need to be specified for -r
option.
ldapugmod -t group -a ""
The output of the command is as follows:
ERROR: MOD_COMMANDLINE_ERR:
member(s) need to be specified for -a
option.
MOD_MEMBER_SKIPPED
Cannot remove user account from the specified group, will
be skipped.
MOD_DUP_REQUEST
Duplicate modification requests are found in the command
options. For example,
ldapugmod -A "cn=Mike Lee" -A "cn=Mike Lee”
mlee
After running the preceding command, ldapugmod exits
with the MOD_DUP_REQUEST error status because duplicate
modification requests are specified.
MOD_CONFLICT_REQUEST
Conflict modification requests are found in the command
options.
MOD_RENAME_RDN_FAILED
Renaming the entry RDN failed.
MOD_NEW_RDN_NEEDED
The specified command deletes the existing value in the
RDN, but no new value for the RDN has been provided.
MOD_MEMBER_EXIST
The account entry being added is already a member of
the specified group.
MOD_HOMEDIR_DOESNOT_EXIST
The user's home directory does not exist.
MOD_MISSING_INFORMATION
Cannot move user's home directory, missing information.
9.3.6.6 Security considerations
Be aware of the following security considerations when you use ldapugmod:
•
The ldapugmod tool requires an LDAP administrator permissions when it performs operations
on the directory server. The rights to modify existing LDAP directory entries under the requested
subtree, and to create, modify and remove the required attributes in that entry must be granted
to the administrator identity that you specify when executing ldapugmod.
322 Command and tool reference
•
With any POSIX-type identity, the user and group ID numbers are used by the HP-UX operating
system to determine rights and capabilities in the OS and in the file system. For example, a
root user ID 0 has unlimited OS administration and file access rights. Before modifying an
entry, you must be aware of the selected user and group ID number and any policy that may
be associated with that ID.
•
Modification (renaming) of a POSIX account does not automatically modify that account’s
membership in groups, unless the LDAP directory server intrinsically provides that capability.
Some LDAP directory servers have a feature known as “referential integrity”, which performs
modification or removal of DN-type attributes if the specified DN is either changed or removed
•
As may occur in any identity repository, modifying this repository can open exposure to risks.
The impact of such changes depends on the organization security policy. When using
ldapugmod, you are expected to have full knowledge of the organization security policy and
the impact of modifying identity information in that identity repository.
9.3.6.7 Limitations
Because LDAP directories require data be stored according to the UTF-8 (RFC3629) character
encoding method, all characters displayed by ldapugmod are UTF-8, and assumed to be part of
the ISO-10646 character set. The ldapugmod tool does not perform conversion of the locale
character set to or from the UTF-8 character set.
9.3.6.8 Examples
The following commands set the LDAP_BINDDN and LDAP_BINDCRED environment variables:
export LDAP_BINDDN = "cn=Jane Admin,ou=admins,dc=example,dc=com"
export LDAP_BINDCRED = "Jane_Password"
Run the following command to go to the /opt/ldapux/bin directory where ldapugmod resides:
cd /opt/ldapux/bin
The following commands are used to change the password of the user, mlee, using the new user
password defined in LDAP_UGCRED:
export LDAP_UGCRED = "mlee's new Password"
./ldapugmod -t passwd -PW mlee
The following command replaces the uidNumber value for the user entry, mMackey:
./ldapugmod -t passwd -u 300 mMackey
The following command replaces the sn value for the user entry, mLou:
./ldapugmod -t passwd mLou "sn=Lou"
The following command replaces the gecos fields for the user entry, mLou:
./ldapugmod -t passwd -I "Mike Lou,Building-6,222-2222" mLou
The following command adds the description attribute and value to the user entry, atam:
./ldapugmod -t passwd -A "description=test user entry" atam
The following command extends the existing user entry,
userid=212,ou=users,dc=example,dc=com, with the POSIX attributes and values for
homeDirectory, uid, and gidNumber. The ldapugmod tool adds the PosixAccount object
class to the entry.
./ldapugmod -t passwd -D "userid=212,ou=users,dc=example,dc=com"
-O -A "homeDirectory=/home/testusr" -A "gidNumber=200" -A "uid=testusr"
The following command adds the three members, atam, mlou, mscott, to the group entry,
groupA:
./ldapugmod -t group -a atam,mlou,mscott GroupA
The following command removes one member, atam from the group entry, groupB:
9.3 LDAP user and group management tools 323
./ldapugmod -t group -r atam GroupB
The following command replaces all instances of the description attribute with value “Group
C Entry” for the group entry, GroupC:
./ldapugmod -t group GroupC "description=Group C Entry"
9.3.7 The ldapugdel tool
Use the ldapugdel tool to remove POSIX-related user or group entries from an LDAP directory
server. If you use ldapugdel with the -O option, ldapugdel removes the POSIX related attributes
and object classes from user or group entries, without removing the entire entry itself.
9.3.7.1 Removing attributes only
You can use ldapugdel to remove POSIX user and group entire entries from an LDAP directory
server. With the -O option, ldapugdel enables you to remove only POSIX related attributes and
object classes from user or group entries, without removing entire entries.
Because mapped attributes are attributes that are often shared with other LDAP-enabled applications,
ldapugdel does not support attribute mapping. For example, if the uidNumber attribute has
been mapped to the employeeNumber attribute, ldapugdel attempts to remove uidNumber
and not employeeNumber.
The usePassword, uid, cn, and description attributes are commonly used by most other
user and group schemas. With the -O option, the ldapugdel tool does not attempt to remove
these attributes. The uidNumber, gidNUmber, loginShell, homeDirectory, gecos, and
memberUid attributes are more unique to the POSIX schema, and are removed when the -O option
is specified. Use the ldapugdel -t passwd -O command, ldapugdel removes the
posixAccount object class and attributes, uidNumber, gidNumber, homeDirecotry,
loginShell, and gecos. Use the ldapugdel -t group -O command, ldapugdel removes
the posixGroup object class and the gidNumber, memberUId, and userPassword attributes.
The ldapugdel tool also supports a <protAttr> list with the -O option that enables you to tell
ldapugdel not to remove specific attributes defined in the <protoAttr> list.
Using the -O -x -t option forces ldapugdel to remove the additional attributes, cn, uid, or
description. Removal of these attributes only occurs if allowed by the remaining object classes
for that entry.
For detailed information, see the description of the -O, -x and -y arguments that follow.
9.3.7.2 Synopsis
ldapugdel [options] [-t <type>] [-h <hostname>] [-p <port>]
[-O [<protAttr>[,...]]] <-D <DN>>|<uid_name>|<group_name>
9.3.7.3 Options
The ldapugdel tool supports the following command options:
-P
Prompts for the administrator's bind identity (typically LDAP DN or Kerberos principal) and
bind password. If you do not specify the -P option, ldapugdel discovers the bind identity
and password from the environment variables LDAP_BINDDN and LDAP_BINDCRED. If
you do not specify the LDAP_BINDDN and LDAP_BINDCRED environment variables,
ldapugdel uses the bind configuration specified in the LDAP-UX configuration profile. If
the LDAP-UX configuration profile specifies the “proxy” bind, ldapugdel reads the bind
credential from either the /etc/opt/ldapux/acred or the /etc/opt/ldapux/pcred
file. The /etc/opt/ldapux/acred file is only used by users who have sufficient
administrative privilege to read this file.
-x
Uses this option only with the -O option. Use -O -x -t passwd to force the ldapugdel
tool to remove the common uid, cn, and description attributes from a user entry. Use
-O -x -t group to force the ldapugdel tool to remove the cn and description
324 Command and tool reference
attributes from a group entry. Because use of -x removes common attributes typically used
by other LDAP-enabled applications, HP rarely recommends you to use the -x option when
removing posixAccount or posixGroup related attributes. If removal of the uid, cn, or
description causes an object class violation, ldapugdel generates a warning message.
With the -x option, LDAP-UX tries to remove as many attributes as allowed by the directory
server.
-y
Uses this option only with the -O and -t passwd options. This option forces ldapugdel
to remove the userPassword attribute from the user entry. HP does not recommend you
to use the -y option when removing posixAccount related attributes.
-Z
Requires an SSL connection to the LDAP directory server, even if the LDAP-UX configuration
does not require the use of SSL. Using the -Z option requires that either a valid directory
server or a CA certificate is defined in the /etc/opt/ldapux/cert8.db file. An error
occurs if the SSL connection cannot be established.
-ZZ
Attempts a TLS connection to the directory server, even if the LDAP-UX configuration does
not require the use of TLS. If a TLS connection cannot be established, a nonTLS and nonSSL
connection will be established. Do not use -ZZ unless alternative methods are used to
protect against network eavesdropping. Use of -ZZ requires that either a valid directory
server or a CA certificate is defined in the /etc/opt/ldapux/cert8.db file.
-ZZZ
Requires a TLS connection to the LDAP directory server, even if the LDAP-UX configuration
does not require the use of TLS. Using the -ZZZ option requires that either a valid directory
server or a CA certificate is defined in the /etc/opt/ldapux/cert8.db file. An error
occurs if the TLS connection cannot be established.
-S
Displays the Distinguish Name (DN) of the deleted or updated entry when the operation
successfully completes.
9.3.7.4 Arguments
The following describes command arguments:
-h <hostname>
Specifies the host name and optional port number
(hostname:port) of the LDAP directory server. This option
overrides the server list defined by LDAP-UX configuration profile.
This field supports specification of IPv4 and IPv6 addresses. If
you specify a port for an IPv6 address, you must specify the IPv6
address in a square-bracketed form. If you do not specify the
optional port, the port number defaults to 389 or 636 for SSL
connection (-Z). For example, -h ldapsrvA:389.
-p <port>
Specifies the port number of the LDAP directory server to contact.
The ldapugdel tool ignores this option if you specify the port
number in the <hostname> field as part of the -h option.
-t <type>
Specifies the type of entry the ldapdel tool needs to delete.
The valid types of this argument are passwd and group. If you
do not specify this argument, ldapugdel defaults to passwd.
The passwd type represents LDAP user entries containing POSIX
account-related information. The group type represents LDAP
group entries containing POSIX group-related information. For
example, -t passwd.
-D <DN>
The ldapugdel tool searches for the named user or group using
the search rules defined by the service search descriptor in the
LDAP-UX configuration profile. You can use the -D option to
specify the exact distinguished name (DN) of the entry being
deleted. You may specify only one of -D, <uid_name> or
<group_name> parameter on the command line.
9.3 LDAP user and group management tools 325
<uid_name>
Specifies the name of the user entry that you want to delete.
ldapugdel uses the configured LDAP search filter to discover
the entry to be removed, such as
(&(objectclass=posixAccount)(uid=name)). If more
than one entry matches this search filter, only the first discovered
entry is removed. You may specify only one of -D, <uid_name>
or <group_name> parameter on the command line.
<group_name>
Specifies the name of the group entry that you want to delete.
The ldapugdel tool uses the configured LDAP search filter to
discover the entry to be removed, such as
(&(objectclass=posixGroup)(cn=name)). If more than
one entry matches this search filter, ldapugdel removes only
the first discovered entry. You may specify only one of -D,
<uid_name> or <group_name> parameter on the command
line.
-O [<protAttr>[,...]]
Enables the ldapugdel tool to delete only the posixAccount or
posixGroup object class and associated attributes, without
deleting the entire user or group entry. With the -t passwd
option, the ldapugdel tool removes the posixAccount object
class and the following attributes:
•
uidNumber
•
gidNumber
•
homeDirectory
•
loginShell
•
gecos
With the -t group option, the ldapugdel tool removes the
posixGroup object class and the following attributes:
•
gidNumber
•
memberUid
•
userPassword
The <protAttr> list consists of one or more of the previous
attribute names separated by commas with no white space. If
you specify the <portAttr> list, ldapugdel will not remove
the specified attributes.
326 Command and tool reference
NOTE: Keep the following considerations in mind when using
the -O option:
•
The ldapugdel tool does not support attribute mappings.
For example, if the uidNumber attribute has been mapped
to the employeeNumber attribute, ldapugdel will attempt
to remove uidNumber attribute and not employeeNumber.
•
Because the uid, cn and description attributes are
commonly used by other user or group object classes,
ldapugdel does not attempt to remove uid and
description attributes for a user entry or cn and
description attributes for a group entry, unless failure
to remove those attributes can cause an object class violation
(because the remaining object classes for that entry do not
define them as their attributes). Use of the -O -x option
forces ldapugdel to remove those attributes if allowed by
the remaining object classes for that entry.
•
Because the userPassword attribute is often used by other
user-related object classes, ldapugdel does not attempt
to remove the userPassword attribute when removing
user entries. Use of the -O -y -t passwd options forces
ldapugdel to remove this attribute if allowed by the
remaining object classes in that entry.
•
The ldapugdel tool attempts to remove the
posixAccount and posixGroup object classes only if
they are present. In some cases, when a user or group entry
is built using an abstract class, the posixAccount and
posixGroup object classes might not be present in the
entry.
•
If ldapugdel determines that the entry being deleted is
stored on a Windows ADS directory server, ldapugdel
does not remove the homeDirectory attribute. The
Window user entry contains the User object class and the
homeDirecotroy attribute is part of the User object class.
•
The Microsoft Services for UNIX (SFU) schema does not use
RFC 2307 standard attributes. Also ldapugdel does not
support attribute mapping as defined by the LDAP-UX
configuration profile when the tool is used to access a
Windows ADS with msSFU 2.0 or msSFU3.0/3.5 schema
installed. When the -O option is specified and ldapugdel
determines that it is connected to a Windows ADS with
these schema installed, ldapugdel does not remove the
mapped POSIX object class and attributes (msSFU30xxx or
msSFU20xxx) for the specified user or group entry.
•
The -O option functions properly with Windows Server
2003 R2 or 2008 ADS, because it uses standard RFC 2307
attributes, with the exception of the homeDirectory
attribute.
9.3.7.5 Specific return codes for ldapugdel
The ldapugdel tool returns a list of return codes shown in Table 31 (page 328).
9.3 LDAP user and group management tools 327
Table 31 Return codes for ldapugdel
Return Codes
Message
DEL_COMMANDLINE_ERR
Invalid POSIX attributes.
DEL_MULTIPLE_ENTRY_FOUND
Multiple entries found that match the same name. Please
use a DN to specify a specific entry.
DEL_DELETE_FAILED
The LDAP deletion operation failed.
DEL_SEARCH_FAILED
The LDAP search for subSchemaSubEntry, attributeTypes
or objectClasses failed.
DEL_PARSE_ERROR
Unable to analyze LDAP directory server’s schema. This
operation is required in order to determine which attributes
may be legally removed.
9.3.7.6 Security considerations
Be aware of the following security considerations when you use ldapugdel:
•
Use of ldapugdel requires permissions of an LDAP administrator when it performs its
operations on the directory server. The rights to delete or modify existing LDAP directory entries
under the requested subtree and to remove the required attributes in that entry must be granted
to the administrator identity that you specify when you execute ldapugdel.
•
Removal of a POSIX account does not automatically remove that account’s membership in
groups, unless the LDAP directory server provides that capability. Some LDAP directory servers
have a feature called “referential integrity”, which performs modification or removal of DN-type
attributes if the specified DN is either changed or removed.
•
As may occur in any identity repository, modifying this repository can open exposure to risks.
The impact of such changes depends on the organization security policy. When using
ldapugdel, you are expected to have full knowledge of the organization security policy and
the impact of deleting identity information from that identity repository.
•
Do not use ldapugdel as part of a modification process on a user or group entry (deleting
and readding the entry as a way to modify that entry.) User and group entries in an LDAP
directory often contain information about the user or group that is outside the POSIX information
model. Deleting an entry will delete all information about the user or group. When the entry
is readded, recovery of the nonPOSIX information might not be possible.
9.3.7.7 Limitations
Because LDAP directory servers require data to be stored according to the UTF-8 (RFC3629)
character encoding method, all characters provided to ldapugdel are assumed to be UTF-8 and
part of the ISO-10646 character set. The ldapugdel tool does not perform conversion of the
locale character set to or from the UTF-8 character set.
9.3.7.8 Examples
The section provides examples of using ldapugdel:
Run the following commands to specify the LDAP_BINDDN and LDAP_BINDCRED environment
variables:
export LDAP_BINDDN = "cn=Jane Admin,ou=admins,dc=exampe,dc=com"
export LDAP_BINDCRED = "Jane's password"
Run the following command to go to the /opt/ldapux/bin directory where ldapugdel resides:
cd /opt/ldapux/bin
328 Command and tool reference
Run the following command to delete the entire user account entry, astein, on the LDAP directory
server, ldapsrvA. The -h option overrides the server list defined by the LDAP-UX configuration
profile.
./ldapugdel -t passwd -h ldapsrvA:389 astein
Run the following command to delete the entire user account entry, msmart:
./ldapugdel -t passwd msmart
Run the following command to delete the entire group entry with the distinguished name,
“cn=group1,ou=groups,dc=example,dc=com":
./ldapugdel -t group -D "cn=group1,ou=groups,dc=example,dc=com"
Run the following command to delete only the posixAccount object class and associated attributes,
uidnumber, gidNumber, homeDirectory, loginShell and gecos, without delete the entire
user entry, msmith:
./ldapugdel -t passwd -O msmith
Run the following command to delete only the posixAccount object class and associated attributes,
uidnumber, gidNumber and gecos, without delete the entire user entry, mlee:
./ldapugdel -t passwd -O "homeDirectory,l