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

Constructing an Access Rule in pam_authz.policy
In the policy file, /etc/opt/ldapux/pam_authz.policy, an access rule consists of three
fields as follows:
<action>:<type>:<object>
All fields are mandatory except for the <object> field when 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
Fields in an Access Rule
Table 5-1 shows a summary on all possible values and syntax of an access rule:
Table 7-1 Field Syntax in an Access Rule
<object><type><action>
A list of user name. 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
unix_userdeny, allow, <pam_code>
No value is required.
unix_local_userdeny, allow, <pam_code>
A list of group name. 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
unix_groupdeny, allow, <pam_code>
A list of netgroup name. 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
netgroupdeny, allow, <pam_code>
It is the Distinguished name of a ldap group with
groupofnames objectclass or groupofuniquenames
objectclass. 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
ldap_groupdeny, allow, <pam_code>
It is 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_filterdeny, allow, <pam_code>
PAM_AUTHZ Login Authorization 111