TAM Admin Guide
418
Tivoli ® Access Manager for Operating Systems Administration Guide Version 6.0 SC32-1709-00
Transcript of TAM Admin Guide
Tivoli® Access Manager for Operating Systems
Administration Guide
Version 6.0
SC32-1709-00
���
Tivoli® Access Manager for Operating Systems
Administration Guide
Version 6.0
SC32-1709-00
���
Note
Before using this information and the product it supports, read the information in Appendix F, “Notices,” on page 393.
First Edition (April 2006)
This edition applies to version 6 release 0 modification 0 of IBM Tivoli Access Manager for Operating Systems
(product number 5698-PDO) and to all subsequent releases and modifications until otherwise indicated in new
editions.
© Copyright International Business Machines Corporation 2000, 2005. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Preface . . . . . . . . . . . . . . vii
Who should read this book . . . . . . . . . vii
What this book contains . . . . . . . . . . vii
Publications . . . . . . . . . . . . . . viii
IBM Tivoli Access Manager for Operating
Systems library . . . . . . . . . . . . viii
Related products and publications . . . . . . ix
Accessing publications online . . . . . . . . x
Accessing terminology online . . . . . . . . x
Accessibility . . . . . . . . . . . . . . x
Tivoli software training . . . . . . . . . . . x
Support information . . . . . . . . . . . . x
Conventions used in this book . . . . . . . . xi
Typeface conventions . . . . . . . . . . xi
Operating system differences . . . . . . . . xi
Chapter 1. Introduction . . . . . . . . 1
Environment . . . . . . . . . . . . . . 1
Authentication model . . . . . . . . . . . 2
Authorization model . . . . . . . . . . . . 2
The UNIX identity and its relationship to the Tivoli
Access Manager user identity . . . . . . . . . 3
Authorization policy . . . . . . . . . . . . 4
Chapter 2. Policy . . . . . . . . . . . 7
Policy administration . . . . . . . . . . . 7
Protected object name structure . . . . . . . . 8
Object space root . . . . . . . . . . . . 9
Policy branch . . . . . . . . . . . . . 9
Resource types . . . . . . . . . . . . 10
Object name . . . . . . . . . . . . . 10
Wildcards . . . . . . . . . . . . . . 10
Access controls . . . . . . . . . . . . . 13
Access control lists . . . . . . . . . . . 14
Access restrictions . . . . . . . . . . . 17
Types of restrictions that can be defined . . . . 19
Access restriction evaluation . . . . . . . . 20
Examples of access restrictions . . . . . . . 22
Inheritance and traversal . . . . . . . . . 23
Protected object policies . . . . . . . . . . 25
Warning-mode attribute . . . . . . . . . 25
Audit-level attribute . . . . . . . . . . 26
Time-of-day attribute . . . . . . . . . . 27
Protected system resources . . . . . . . . . 27
File policy . . . . . . . . . . . . . . 27
File resources . . . . . . . . . . . . . 28
Trusted Computing Base resources . . . . . 36
Network policy . . . . . . . . . . . . 44
Network resource access control . . . . . . 49
Login policy . . . . . . . . . . . . . 50
Password management policy . . . . . . . 58
Surrogate policy . . . . . . . . . . . . 62
Sudo Policy . . . . . . . . . . . . . 64
The pdossudo command . . . . . . . . . 68
Audit resources . . . . . . . . . . . . . 70
Audit authorization resources . . . . . . . 70
Audit trace resources . . . . . . . . . . 72
Multiple policy branches . . . . . . . . . . 74
Definition of additional policy branches . . . . 74
Configuration of additional policy branches . . 75
Conflicting policy . . . . . . . . . . . 75
File policy . . . . . . . . . . . . . . 77
TCB policy . . . . . . . . . . . . . 78
Login Holiday policy . . . . . . . . . . 79
Login location policy . . . . . . . . . . 80
Login activity policy . . . . . . . . . . 81
Password management policy . . . . . . . 82
Surrogate policy . . . . . . . . . . . . 83
Network policy . . . . . . . . . . . . 84
Sudo policy . . . . . . . . . . . . . 85
Audit resource policy . . . . . . . . . . 86
Chapter 3. Runtime . . . . . . . . . 89
Daemons . . . . . . . . . . . . . . . 89
The pdosd authorization daemon . . . . . . . 90
Credential acquisition . . . . . . . . . . 90
Authorization decision process . . . . . . . 95
TCB monitoring . . . . . . . . . . . . 97
The pdosd log configuration . . . . . . . . 99
The pdosauditd audit daemon . . . . . . . . 100
The pdosauditd configuration . . . . . . . 101
The pdoswdd watchdog daemon . . . . . . . 102
The pdoswdd configuration . . . . . . . 103
The pdostecd Tivoli Enterprise Console daemon 104
The pdostecd configuration . . . . . . . . 104
Periodic log maintenance . . . . . . . . 105
The pdoslpmd login policy and password
management daemon . . . . . . . . . . . 105
The pdoslpmd configuration . . . . . . . 106
The pdoslrd log router daemon . . . . . . . 107
The pdoslrd configuration . . . . . . . . 107
Users and groups . . . . . . . . . . . . 108
osseal-admin group . . . . . . . . . . 108
osseal group . . . . . . . . . . . . . 109
osseal user . . . . . . . . . . . . . 109
root user . . . . . . . . . . . . . . 109
osseal-auditors group . . . . . . . . . . 110
ossaudit group . . . . . . . . . . . . 110
osseal-unauth user . . . . . . . . . . . 110
pdosd-hostname user . . . . . . . . . . 110
Group for critical users . . . . . . . . . 111
Files and directories . . . . . . . . . . . 111
Initial policy . . . . . . . . . . . . . . 114
osseal-audit . . . . . . . . . . . . . 115
osseal-audit-exec . . . . . . . . . . . 115
osseal-credentials . . . . . . . . . . . 115
osseal-default . . . . . . . . . . . . 115
osseal-default-file . . . . . . . . . . . 115
osseal-default-login . . . . . . . . . . 115
osseal-default-net-incoming . . . . . . . . 115
© Copyright IBM Corp. 2000, 2005 iii
osseal-default-net-outgoing . . . . . . . . 115
osseal-default-sudo . . . . . . . . . . 116
osseal-default-surrogate . . . . . . . . . 116
osseal-exec-open . . . . . . . . . . . 116
osseal-exec-root . . . . . . . . . . . . 116
osseal-hla . . . . . . . . . . . . . . 116
osseal-kazndrv . . . . . . . . . . . . 116
osseal-logs . . . . . . . . . . . . . 116
osseal-open . . . . . . . . . . . . . 117
osseal-privileged-user . . . . . . . . . . 117
osseal-restricted . . . . . . . . . . . 117
osseal-restricted-read . . . . . . . . . . 117
osseal-tcb . . . . . . . . . . . . . . 117
osseal-umsg . . . . . . . . . . . . . 117
osseal-var-lpm . . . . . . . . . . . . 117
Isolated operation . . . . . . . . . . . . 118
Isolation from the Tivoli Access Manager policy
server . . . . . . . . . . . . . . . 118
Isolation from the Tivoli Access Manager user
registry . . . . . . . . . . . . . . 118
Isolation from non-local UNIX user registry . . 119
Isolation from the host name resolution server 120
Chapter 4. The log router daemon . . 121
Log router control file . . . . . . . . . . 121
Log router control file example . . . . . . . 121
Log router control file elements . . . . . . . 122
XML header . . . . . . . . . . . . . 122
Server element . . . . . . . . . . . . 122
Router element . . . . . . . . . . . . 122
Channel element . . . . . . . . . . . 123
Filters element . . . . . . . . . . . . 126
Filter element . . . . . . . . . . . . 126
Conditional element . . . . . . . . . . 127
Field element . . . . . . . . . . . . 128
Filter definitions . . . . . . . . . . . 129
Channels . . . . . . . . . . . . . . . 130
LRD_AuditInput . . . . . . . . . . . 130
LRD_FileOutput . . . . . . . . . . . 131
LRD_EmailOutput . . . . . . . . . . . 131
LRD_NetOutput . . . . . . . . . . . 132
Log router audit record fields . . . . . . . . 133
Supported fields . . . . . . . . . . . 133
Supported field values . . . . . . . . . 133
Supported formats . . . . . . . . . . 133
Field table . . . . . . . . . . . . . 133
Encoded field values . . . . . . . . . . 135
Log router output formats . . . . . . . . . 137
Local file output—LRD_FileOutput . . . . . 137
E-mail output—LRD_EmailOutput . . . . . 137
Network output—LRD_NetOutput . . . . . 138
File rollover . . . . . . . . . . . . . 138
Output compression . . . . . . . . . . 139
Chapter 5. Administrative tasks . . . 141
Defining runtime administrators and auditors . . 141
Establishing a consistent user name space . . . . 142
Identifying users and groups . . . . . . . 143
Identifying duplicate user names . . . . . . 143
Using pdosrgyimp . . . . . . . . . . . 144
Configuring additional branches . . . . . . . 145
Adding branches . . . . . . . . . . . 145
Listing branches and precedence . . . . . . 145
Changing precedence order . . . . . . . . 145
Deleting branches . . . . . . . . . . . 145
Tuning the configuration . . . . . . . . . 146
Limiting ACL inheritance for a network policy . . 148
Obtaining membership reports . . . . . . . 148
Listing machines in a policy branch . . . . . 149
Listing policy branches for a machine . . . . 149
Managing processes . . . . . . . . . . . 149
Starting Tivoli Access Manager for Operating
Systems . . . . . . . . . . . . . . 149
Stopping Tivoli Access Manager for Operating
Systems . . . . . . . . . . . . . . 150
Checking daemon status . . . . . . . . . 151
Daemon log files . . . . . . . . . . . 151
Verifying policy . . . . . . . . . . . . 152
Using warning mode to verify policy . . . . 152
Using auditing to verify policy . . . . . . 153
Managing the Trusted Computing Base . . . . . 156
Tuning monitoring for the Trusted Computing
Base . . . . . . . . . . . . . . . 156
Managing the object signature database . . . 157
Restricting elements for signature checks . . . 157
Managing scheduled upgrades to registered files
in the Trusted Computing Base . . . . . . 158
Managing operating system upgrades . . . . . 159
Managing login activity and password
management policy enforcement . . . . . . . 160
Viewing account records . . . . . . . . . 160
Locking and unlocking accounts . . . . . . 161
Password change date for user accounts . . . 161
Creation of local user accounts with minimum
password age policy . . . . . . . . . . 161
Configuring NIS for login activity policy . . . 162
Displaying password expiration and grace
logins . . . . . . . . . . . . . . . 162
Managing credentials . . . . . . . . . . . 163
Tuning the credentials cache . . . . . . . 163
Explicitly refreshing credentials . . . . . . 164
Explicitly destroying credentials . . . . . . 164
Determining accessor identity . . . . . . . . 165
Determining accessor identity for users . . . . 165
Determining accessor identity for processes . . 165
Examples of pdoswhoami and pdoswhois . . . 165
Configuring and managing the host name
lookaside database . . . . . . . . . . . 167
Configuring the database . . . . . . . . 167
Managing the database . . . . . . . . . 167
Backing up and restoring configuration files and
databases . . . . . . . . . . . . . . . 168
Backing up configuration files and databases 168
Restoring Tivoli Access Manager for Operating
Systems . . . . . . . . . . . . . . 169
Obtaining entitlement report . . . . . . . . 169
Parts of the entitlement report . . . . . . . 169
Object space output . . . . . . . . . . 171
Viewing policy . . . . . . . . . . . . 172
iv Administration Guide
Chapter 6. Using the Tivoli desktop to
perform management tasks . . . . . 175
Task overview . . . . . . . . . . . . . 175
Running tasks as users other than root . . . . . 177
General information about wrunjob and wruntask 178
Add and remove PDOS auditors and
administrators . . . . . . . . . . . . . 178
Backup PDOS database . . . . . . . . . . 180
Branch configuration . . . . . . . . . . . 182
Certificate transfer utility . . . . . . . . . 183
Configure audit health . . . . . . . . . . 185
Configure PDOS auditing . . . . . . . . . 187
Configure PDOS caching . . . . . . . . . 188
Configure PDOS logging . . . . . . . . . 190
Configure PDOS login and password policy . . . 193
Configure PDOS server . . . . . . . . . . 195
Configure PDOS TCB . . . . . . . . . . 199
Display PDOS host name cache . . . . . . . 201
Distribute log router daemon control file . . . . 202
Import UNIX TCB . . . . . . . . . . . . 203
Import UNIX users and groups . . . . . . . 205
Manage PDOS credential cache . . . . . . . 208
Manage PDOS server state . . . . . . . . . 209
Manage PDOS TCB . . . . . . . . . . . 211
Purge PDOS host name cache . . . . . . . . 212
Query branch membership . . . . . . . . . 213
Query PDOS login and password policy . . . . 215
Query PDOS server state . . . . . . . . . 216
Query PDOS TCB . . . . . . . . . . . . 218
Restore PDOS database . . . . . . . . . . 219
Set PDOS server audit level . . . . . . . . 220
Set PDOS server trace level . . . . . . . . . 223
Setup TEC event server for PDOS . . . . . . 225
Show PDOS auditing configuration . . . . . . 228
Show PDOS auditors and administrators . . . . 229
Show PDOS caching configuration . . . . . . 230
Show PDOS logging configuration . . . . . . 231
Show PDOS server audit level . . . . . . . . 231
Show PDOS server configuration . . . . . . . 232
Show PDOS TCB configuration . . . . . . . 232
Start PDOS TEC adapter . . . . . . . . . 233
Stop PDOS TEC adapter . . . . . . . . . . 233
Subscribe PDOS endpoints . . . . . . . . . 233
Update PDOS host name cache . . . . . . . 234
Chapter 7. Auditing . . . . . . . . . 237
Auditing authorization decisions . . . . . . . 237
Auditing administrative activity . . . . . . . 239
Auditing trace events . . . . . . . . . . . 239
Enabling auditing . . . . . . . . . . . . 241
Global auditing . . . . . . . . . . . . 241
Resource-level auditing . . . . . . . . . 244
User-level auditing . . . . . . . . . . 246
Health auditing . . . . . . . . . . . . 248
Enabling health auditing . . . . . . . . 249
Controlling certificate lifetime audit records . . 250
Controlling heartbeat audit records . . . . . 250
Warning mode . . . . . . . . . . . . . 250
Enabling, disabling, and querying global
warning mode . . . . . . . . . . . . 250
Enabling, disabling, and querying resource
warning mode . . . . . . . . . . . . 251
The audit log file . . . . . . . . . . . . 251
Audit log consolidation . . . . . . . . . . 252
Viewing audit logs . . . . . . . . . . . 253
Audit log formats . . . . . . . . . . . . 253
Concise format . . . . . . . . . . . . 254
Key-value format . . . . . . . . . . . 254
Verbose format . . . . . . . . . . . . 255
Audit log record types . . . . . . . . . . 257
General audit event record type . . . . . . 257
Trace audit event record type . . . . . . . 265
Logout audit event record type . . . . . . 267
Chapter 8. Commands . . . . . . . 269
pdosaudview . . . . . . . . . . . . . 270
pdosbkup . . . . . . . . . . . . . . 275
pdosbranchcfg . . . . . . . . . . . . . 277
pdoscfg . . . . . . . . . . . . . . . 280
pdoscollview . . . . . . . . . . . . . 292
pdosctl . . . . . . . . . . . . . . . 297
pdosdestroy . . . . . . . . . . . . . . 302
pdosent . . . . . . . . . . . . . . . 303
pdosexempt . . . . . . . . . . . . . . 306
pdoshla . . . . . . . . . . . . . . . 308
pdoslpinf . . . . . . . . . . . . . . . 311
pdoslpadm . . . . . . . . . . . . . . 313
pdoslradm . . . . . . . . . . . . . . 318
pdosobjsig . . . . . . . . . . . . . . 319
pdosrefresh . . . . . . . . . . . . . . 322
pdosrespolicy . . . . . . . . . . . . . 324
pdosrevoke . . . . . . . . . . . . . . 326
pdosrgyimp . . . . . . . . . . . . . . 328
pdosrstr . . . . . . . . . . . . . . . 333
pdosshowuser . . . . . . . . . . . . . 334
pdossudo . . . . . . . . . . . . . . . 337
pdosteccfg . . . . . . . . . . . . . . 338
pdostecucfg . . . . . . . . . . . . . . 341
pdosucfg . . . . . . . . . . . . . . . 343
pdosuidprog . . . . . . . . . . . . . 345
pdosunauth . . . . . . . . . . . . . . 348
pdosversion . . . . . . . . . . . . . . 349
pdoswhoami . . . . . . . . . . . . . 350
pdoswhois . . . . . . . . . . . . . . 352
policyview . . . . . . . . . . . . . . 354
Chapter 9. Integrating with Tivoli
Enterprise Console . . . . . . . . . 357
Overview . . . . . . . . . . . . . . . 357
Installing and configuring the logfile adapter . . . 358
Chapter 10. Integrating with Tivoli
Risk Manager . . . . . . . . . . . 361
Overview . . . . . . . . . . . . . . . 361
Installing and configuring the logfile adapter to
integrate with Tivoli Risk Manager . . . . . . 362
Integrating with Tivoli Data Warehouse . . . . 363
Appendix A. Policy quick reference 365
Contents v
Appendix B. Wildcard character set
expressions . . . . . . . . . . . . 367
Appendix C. Tivoli Enterprise Console
and Tivoli Risk Manager events . . . 369
Tivoli Enterprise Console events . . . . . . . 370
Process events . . . . . . . . . . . . 370
File events . . . . . . . . . . . . . 372
Network events . . . . . . . . . . . 372
Sudo events . . . . . . . . . . . . . 373
User set events . . . . . . . . . . . . 373
Group set events . . . . . . . . . . . 373
TCB events . . . . . . . . . . . . . 373
Policy events . . . . . . . . . . . . 374
Login events . . . . . . . . . . . . 375
Credential events . . . . . . . . . . . 376
Password strength events . . . . . . . . 376
Tivoli Risk Manager events . . . . . . . . . 376
Process events . . . . . . . . . . . . 377
File events . . . . . . . . . . . . . 378
Network events . . . . . . . . . . . 379
Sudo events . . . . . . . . . . . . . 379
User set events . . . . . . . . . . . . 380
Group set events . . . . . . . . . . . 380
TCB events . . . . . . . . . . . . . 380
Policy events . . . . . . . . . . . . 381
Login events . . . . . . . . . . . . 382
Credential events . . . . . . . . . . . 382
Password strength events . . . . . . . . 383
Appendix D. Accessibility . . . . . . 385
Appendix E. Support information . . . 387
Searching knowledge bases . . . . . . . . . 387
Searching information centers . . . . . . . 387
Searching the Internet . . . . . . . . . 387
Obtaining fixes . . . . . . . . . . . . . 387
Registering with IBM Software Support . . . . 388
Receiving weekly software updates . . . . . . 388
Contacting IBM Software Support . . . . . . 389
Determining the business impact . . . . . . 389
Describing problems and gathering information 390
Submitting problems . . . . . . . . . . 390
Appendix F. Notices . . . . . . . . 393
Trademarks . . . . . . . . . . . . . . 394
Index . . . . . . . . . . . . . . . 397
vi Administration Guide
Preface
IBM® Tivoli® Access Manager for Operating Systems is application software that
provides a layer of authorization policy enforcement on UNIX® and Linux®
operating systems in addition to that provided by the native operating system.
The IBM Tivoli Access Manager for Operating Systems: Administration Guide provides
a comprehensive set of procedures and reference information for managing Tivoli
Access Manager for Operating Systems. This book also provides background and
conceptual information about the wide range of Tivoli Access Manager for
Operating Systems functionality, the environment, and the authorization model.
Who should read this book
This guide is for administrators and system programmers who have some
knowledge of these topics:
v UNIX and Linux operating systems
v Internet protocols, including HTTP, TCP/IP, FTP, Telnet, and SSL
v Security management
v Authentication and authorization
v Lightweight Directory Access Protocol (LDAP) and directory services
v IBM Tivoli Access Manager
Supplementary information that system administrators might find useful includes
knowledge of the following products:
v IBM Tivoli Directory Server
v Tivoli Management Framework
v IBM Tivoli Enterprise Console®
v IBM Tivoli Risk Manager
v Tivoli Data Warehouse
v IBM Tivoli Common Auditing and Report Service
v Crystal Enterprise
What this book contains
This book contains the following sections:
v Chapter 1, “Introduction,” on page 1
Provides an introduction to Tivoli Access Manager for Operating Systems and its
functions.
v Chapter 2, “Policy,” on page 7
Describes the resources for which Tivoli Access Manager for Operating Systems
provides protection, which can help you plan your protection requirements.
v Chapter 3, “Runtime,” on page 89
Describes the Tivoli Access Manager for Operating Systems runtime components
and the environment.
v Chapter 4, “The log router daemon,” on page 121
© Copyright IBM Corp. 2000, 2005 vii
Describes the audit log consolidation function provided through the log router
daemon.
v Chapter 5, “Administrative tasks,” on page 141
Explains the administrative tasks that can be used to manage Tivoli Access
Manager for Operating Systems.
v Chapter 6, “Using the Tivoli desktop to perform management tasks,” on page
175
Describes the tasks to manage Tivoli Access Manager for Operating Systems
from the Tivoli desktop.
v Chapter 7, “Auditing,” on page 237
Explains how to use the auditing functions to track access to protected functions
and monitor activity.
v Chapter 8, “Commands,” on page 269
Provides detailed reference information about the Tivoli Access Manager for
Operating Systems commands.
v Chapter 9, “Integrating with Tivoli Enterprise Console,” on page 357
Describes how Tivoli Access Manager for Operating Systems can be integrated
with the Tivoli Enterprise Console.
v Chapter 10, “Integrating with Tivoli Risk Manager,” on page 361
Describes how Tivoli Access Manager for Operating Systems can be integrated
with Tivoli Risk Manager.
v Appendix A, “Policy quick reference,” on page 365
Provides a quick reference to the policy resources and permissions.
v Appendix B, “Wildcard character set expressions,” on page 367
Lists and defines wildcard expressions.
v Appendix C, “Tivoli Enterprise Console and Tivoli Risk Manager events,” on
page 369
Describes the Tivoli Enterprise Console and Tivoli Risk Manager events that can
be sent to the Tivoli Enterprise Console event console.
v Appendix D, “Accessibility,” on page 385
Describes the accessibility features that make Tivoli Access Manager for
Operating Systems available to users with physical disabilities.
v Appendix E, “Support information,” on page 387
Describes how to obtain support for IBM products.
Publications
Read the descriptions of the Tivoli Access Manager for Operating Systems library,
the prerequisite publications, and the related publications to determine which
publications might be helpful.
IBM Tivoli Access Manager for Operating Systems library
The following publications are in the IBM Tivoli Access Manager for Operating
Systems library:
v IBM Tivoli Access Manager for Operating Systems: Read This First, GI11-4614-00
Provides information for installing and getting started using Tivoli Access
Manager for Operating Systems.
v IBM Tivoli Access Manager for Operating Systems: Release Notes, GI11-4615-00
viii Administration Guide
Provides information about system requirements, known installation and
configuration problems, and problem workarounds.
v IBM Tivoli Access Manager for Operating Systems: Installation Guide, SC32-1710-00
Explains how to install, configure, upgrade, and uninstall Tivoli Access Manager
for Operating Systems.
v IBM Tivoli Access Manager for Operating Systems: Administration Guide,
SC32-1709-00
Describes the concepts and procedures for using Tivoli Access Manager for
Operating Systems. Provides instructions for performing administrative tasks,
auditing, and integrating with Tivoli Enterprise Console and Tivoli Risk
Manager.
v IBM Tivoli Access Manager for Operating Systems: Problem Determination Guide,
SC32-1711-00
Provides information about troubleshooting, logging, and diagnostic information
about Tivoli Access Manager for Operating Systems.
Related products and publications
To use the information in this book effectively, you must have some prerequisite
knowledge, You can obtain this knowledge from the following publications:
v IBM Tivoli Access Manager for e-business: Release Notes, GI11-4156-00
Provides information about system requirements, known installation and
configuration problems, and problem workarounds.
v IBM Tivoli Access Manager: Administration Guide, GC23-1360-00
Describes the concepts and procedures for using Tivoli Access Manager. Provides
instructions for performing tasks from the Web Portal Manager interface and
with the pdadmin utility.
v IBM Tivoli Access Manager for e-business: Auditing Guide, SC32-2202-00
Provides information about configuring and managing audit events using the
native Tivoli Access Manager approach and the Common Auditing and
Reporting Service.
Related publications
Additional information related to Tivoli Access Manager for Operating Systems is
available in the following publications:
v IBM Tivoli Access Manager for e-business: Command Reference, SC32-1354-00
Provides reference information about the commands, utilities, and scripts that
are provided with Tivoli Access Manager.
v IBM Tivoli Access Manager for e-business: Error Message Reference, SC32-1353-00
Provides explanations and recommended actions for the messages and return
codes that are produced by IBM Tivoli Access Manager for e-business, Tivoli
Access Manager for Operating Systems, IBM Global Security Kit, and the
Common Auditing and Reporting Service.
v IBM Tivoli Access Manager for e-business: Problem Determination Guide,
SC32-1352-00
Provides problem determination information for IBM Tivoli Access Manager for
e-business.
v IBM Tivoli Access Manager for e-business: Performance Tuning Guide, SC32-1351-00
Provides performance tuning information for an environment consisting of Tivoli
Access Manager with the IBM Tivoli Directory Server as the user registry.
v Tivoli Management Framework: User’s Guide, GC32-0805
Preface ix
v Tivoli Management Framework: Reference Manual, GC32-0806
Accessing publications online
The Tivoli Software Library provides a variety of Tivoli publications such as white
papers, data sheets, demonstrations, Redbooks™, and announcement letters. The
publications for this product and many other Tivoli products are available online
in Portable Document Format (PDF) or Hypertext Markup Language (HTML)
format, or both in the Tivoli software library at the following Web address:
http://publib.boulder.ibm.com/tividd/td/tdprodlist.html
To locate product publications in the library, click the first letter of the product
name or scroll until you find the product name. Then click the name of the
product. Product publications include release notes, installation guides, user’s
guides, administrator’s guides, and developer’s references.
Note: To ensure proper printing of PDF publications, select the Fit to page check
box in the Adobe Acrobat Print window (which is available when you click
File → Print).
Accessing terminology online
The IBM Terminology Web site consolidates the terminology from many IBM
products in one convenient location. You can access the Terminology Web site at
the following Web address:
http://www.ibm.com/ibm/terminology
Accessibility
Accessibility features help a user who has a physical disability, such as restricted
mobility or limited vision, to use software products successfully. With this product,
you can use assistive technologies to hear and navigate the interface. You also can
use the keyboard instead of the mouse to operate all features of the graphical user
interface.
For additional information, see Appendix D, “Accessibility,” on page 385.
Tivoli software training
For Tivoli software training information, refer to the IBM Tivoli Education Web site
at the following Web address:
http://www.ibm.com/software/tivoli/education
Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM
provides the following ways for you to obtain the support you need:
Searching knowledge bases
You can search across a large collection of known problems and
workarounds, Technotes, and other information.
Obtaining fixes
You can locate the latest fixes that are already available for your product.
x Administration Guide
Contacting IBM Software Support
If you still cannot solve your problem, and you need to work with
someone from IBM, you can use a variety of ways to contact IBM Software
Support.
For more information about these three ways of resolving problems, see
Appendix E, “Support information,” on page 387.
Conventions used in this book
This book uses several conventions for special terms and actions and for operating
system-dependent commands and paths.
Typeface conventions
The following typeface conventions are used in this book:
Bold Lowercase commands or mixed case commands that are difficult to
distinguish from surrounding text, keywords, parameters, options, names
of Java classes, and objects are in bold.
Italic Variables, titles of publications, and special words or phrases that are
emphasized are in italic.
Monospace
Code examples, command lines, screen output, file and directory names
that are difficult to distinguish from surrounding text, system messages,
text that the user must type, and values for arguments or command
options are in monospace.
Operating system differences
This book uses the UNIX convention for specifying environment variables and for
directory notation. When using the Windows® command line, replace $variable
with %variable% for environment variables and replace each forward slash (/) with
a backward slash (\) in directory paths. If you are using the bash shell on a
Windows system, you can use the UNIX conventions.
Preface xi
xii Administration Guide
Chapter 1. Introduction
Tivoli Access Manager for Operating Systems provides a layer of authorization
policy enforcement in addition to that provided by the native operating system. An
administrator defines additional authorization policy by applying fine-grained
access controls that restrict or permit access to system resources. Controls are based
on user identity, group membership, the type of operation, time of the day or day
of the week, and the accessing application.
An administrator can control access to specific files, login and network services,
and changes of identity. These controls can be used to manage administrative
procedures and to limit administrative capabilities on a per user basis. In addition
to authorization policy enforcement, mechanisms are provided to verify the
defined policy and audit authorization decisions.
Environment
Tivoli Access Manager is a network-based authorization framework that provides a
backbone for defining, managing, and enforcing the authorization policy. Tivoli
Access Manager is administered through a centralized policy server that all
resource managers can access. A centralized policy server allows an administrator
to control the policy for a large number of similar machines from a central location.
Multiple resource managers can use this framework. Tivoli Access Manager for
Operating Systems is one of the resource managers that uses the authorization
service provided by Tivoli Access Manager.
Tivoli Access Manager for Operating Systems functions in a Tivoli Access Manager
environment. The Tivoli Access Manager environment includes two main databases
used by the resource managers.
v The first database, the Tivoli Access Manager user registry, stores the user and
group definitions and is used for managing and identifying users in the Tivoli
Access Manager environment. The Tivoli Access Manager environment must be
set up to use either LDAP or Microsoft® Active Directory as the user registry. If
Active Directory is used, all user and group definitions must be stored in the
same Active Directory domain.
v The second database, the Tivoli Access Manager policy database, stores all of the
policy defined for each resource manager to enforce security. The policy
database stores access controls.
Resource managers access these two databases over a network using TCP, secured
by Secure Socket Layers (SSL) or Transport Layer Security (TLS). However, Tivoli
Access Manager for Operating Systems does not support TLS. In addition to the
databases, Tivoli Access Manager provides a standardized authorization API by
which all authorization decisions are made.
This environment is shown in Figure 1 on page 2.
© Copyright IBM Corp. 2000, 2005 1
Tivoli Access Manager for Operating Systems is installed on each machine that you
want to protect. Although Tivoli Access Manager for Operating Systems relies on
the information in these central databases, the information required to make
authorization decisions is replicated and cached to enable the authorization policy
to continue to be enforced if the policy server or the directory server becomes
inaccessible. See Chapter 3, “Runtime,” on page 89 for a discussion of these topics.
Authentication model
During authentication, a user identity is validated. For Tivoli Access Manager for
Operating Systems, the authentication process is dependent on the specific
requirements for authenticating to the operating system. For example if your
environment uses LDAP, NIS, or Kerberos, account information is stored remotely
on a server, but the users who log in to these machines are authenticated locally.
Authorization model
Tivoli Access Manager for Operating Systems operates in the user-level application
space and operates in the operating system kernel. The Tivoli Access Manager for
Operating Systems kernel extension and user-level components interact in a tightly
integrated secure manner to provide an extended layer of authorization
enforcement. An application accesses system resources through system-provided
APIs, which eventually arrive in the UNIX kernel through a variety of
mechanisms.
Figure 1. An overview of Tivoli Access Manager for Operating Systems
2 Administration Guide
Note: When account information is stored remotely and the user is authenticated
locally, some account data may not be locally accessible for the enforcement
of login and password policy. When using NIS for remote authentication,
Tivoli Access Manager for Operating Systems can enforce login and
password policy. However for other remote authentication processes or
applications, Tivoli Access Manager for Operating Systems cannot fully
enforce this policy.
On a system that is not protected by Tivoli Access Manager for Operating Systems,
the native security for the operating system verifies whether the native identity of
the accessing user has the authorization to perform the requested action. This
native security either carries out the operation or denies it.
The primary function of the Tivoli Access Manager for Operating Systems kernel
extension is to intervene in accesses to resources that are subject to the
authorization policy. The kernel extension uses the Tivoli Access Manager for
Operating Systems authorization daemon process to obtain an authorization
decision and then enforces that decision. If the policy permits access to the
resource, the operation continues and is then subject to native system security.
Otherwise the resource access is denied.
The Tivoli Access Manager for Operating Systems authorization daemon maps
native system identities to Tivoli Access Manager credentials that describe users
and their group memberships from a Tivoli Access Manager point-of-view. This
daemon then uses the Tivoli Access Manager authorization API to obtain
authorization decisions. When protected resources are accessed, Tivoli Access
Manager for Operating Systems performs an authorization check based on the
following criteria to determine whether access should be permitted or denied:
v The identity (credentials) of the accessing user
v The requested action
v The resource being accessed
v The access controls associated with the resource
The UNIX identity and its relationship to the Tivoli Access Manager
user identity
To acquire the credentials needed to make an authorization decision, the accessing
user’s native numerical UNIX ID must be mapped to a Tivoli Access Manager user.
The user’s UNIX user name is obtained from the system’s native user registry
using the numerical ID. This user name is mapped one-to-one to a Tivoli Access
Manager user of the same name to retrieve credentials from the Tivoli Access
Manager user registry. These credentials define the user’s identity and group
membership. If there is no Tivoli Access Manager user that corresponds to the
user’s native user name, the user is treated as unauthenticated when making
authorization decisions. Users with disabled accounts are also treated as
unauthenticated.
The mapping of UNIX user names to Tivoli Access Manager user names is more
complicated when the Tivoli Access Manager user registry is configured to
multiple Active Directory domains. In this case, Tivoli Access Manager requires
that user names contain the domain name. To map the UNIX user name to the
Tivoli Access Manager user name, the domain to which Tivoli Access Manager for
Operating Systems is configured is appended to the UNIX user name. For example,
when Tivoli Access Manager for Operating Systems is configured to use the
Chapter 1. Introduction 3
domain1.com Active Directory domain, mapping UNIX user name marc to the Tivoli
Access Manager user name becomes [email protected].
Table 1 shows the mapping of UNIX user names to Tivoli Access Manager user
names to various registries. To illustrate the mapping for multiple domain Active
Directory, Table 1 assumes that Tivoli Access Manager for Operating Systems is
configured to the domain1.com Active Directory domain.
Table 1. Mapping of names in the native user registry to the Tivoli Access Manager user
registry
UNIX user name
Tivoli Access
Manager user name
in LDAP
Tivoli Access
Manager user name
in single domain
Active Directory
Tivoli Access
Manager user name
in multiple domain
Active Directory
riley riley riley [email protected]
moose moose moose [email protected]
mandy mandy mandy [email protected]
All systems that share the same Tivoli Access Manager environment should use a
consistent and distinct native user name for each real user in the environment. For
example, assume that Sally Smith has the user name sally on machine A and the
user name ssmith on machine B. She will be mapped to two different Tivoli Access
Manager users depending on which machine she logs in to; this might affect the
resources she can access. Conversely, assume that Sally Smith has the user name
sally on machine A and that Sally Doe has the user name sally on machine C.
Both Sally Smith and Sally Doe will get mapped to the same Tivoli Access
Manager user. Either of these situations might compromise your security policy.
Credentials are initially retrieved or refreshed from the Tivoli Access Manager user
registry when a user logs into a UNIX system using a Tivoli Access Manager for
Operating Systems supported and defined login program while Tivoli Access
Manager for Operating Systems is running. All authorization decisions made for
operations performed by processes subsequently run by this user are made using
these credentials. This is true even for processes that change their effective user ID,
for example, programs that perform setuid() calls or programs run after
successfully performing an su command.
Authorization policy
Setting up the authorization policy involves identifying the system resources to
protect and the degree of protection that each resource needs. A security policy is
successful when the appropriate access controls are applied to the resources that
require protection.
The term access controls is used throughout the documentation to refer to the
various kinds of authorization policies that can be used to protect system
resources. Access controls include:
Access Control List (ACL) policy
Identifies specific users, groups of users, and types of users who can be
considered for access and specifies the operations permitted on the
resource.
4 Administration Guide
Protected Object Policy (POP)
Specifies conditions on access to the protected objects, such as auditing,
warning mode, and time-of-day access. POPs apply to all users.
Authorization rules (AuthzRules)
Specifies user-defined conditions that must be met before access to a
protected object is permitted.
Extended Attributes
Additional values placed on an object, ACL, or POP that further restrict the
access such as limiting what programs can be used to access a resource.
To establish an effective authorization policy, you should do the following:
v Understand your systems resources
v Identify the key resources that need to be protected
v Identify the types of users requiring access to these resources
v Understand the available Tivoli Access Manager for Operating Systems options
for securing the resources
Chapter 1. Introduction 5
6 Administration Guide
Chapter 2. Policy
Tivoli Access Manager for Operating Systems protects system resources by
enforcing the authorization policy that is defined in terms of Tivoli Access
Manager access controls. Access to the following types of system resources can be
controlled:
v File system resources
v Remote network services
v Local network services
v Login services
v Changes of user and group identity
v Sudo commands
v Password management services
These resources are identified by Tivoli Access Manager object names. They are
protected by associating Tivoli Access Manager access controls with the object
name. Tivoli Access Manager access controls and object names are used to specify
resource-level and user-level audit policy.
The following sections discuss how Tivoli Access Manager object names and access
controls are used to define the authorization policy for the system resources that
Tivoli Access Manager for Operating Systems protects as well as resource-level and
user-level audit policy.
Policy administration
A Tivoli Access Manager security administrator can use either Web Portal Manager
or the pdadmin utility to manage users, groups, and authorization policy in a
secure domain.
Tivoli Access Manager supports the capability to create and maintain multiple,
secure domains when using an LDAP user registry. (When using Active Directory,
Tivoli Access Manager supports only one secure domain.) The initial domain is
created when the Tivoli Access Manager policy server is configured. This initial
domain is referred to as the management domain. An administrator can create
additional domains using the Tivoli Access Manager administrative tools. Each
additional domain has a unique name defined by the administrator when the
domain is created. Domains are independent of each other. Users, groups, and
resources defined within a domain are not associated with any other domain and
authorization control over resources within a domain does not extend to any other
secure domain. A user or group continues to be identified by a name created
within the domain, but, because multiple domains are supported, a given Tivoli
Access Manager user or group might have a different identity within each domain.
The Tivoli Access Manager user or group identity is only unique within a specific
domain.
There are two primary advantages to maintaining multiple domains. The first is
that each domain has its own policy database. Tivoli Access Manager for Operating
Systems replicates the database on each client every time that a change is made to
the policy database. This replication can result in a considerable amount of
network traffic. Each client only needs the portion of the policy database that
© Copyright IBM Corp. 2000, 2005 7
contains the policy for the branches to which it is configured. In an environment
where multiple policy branches are required, the size of the replicated database can
be significantly reduced by organizing related branches into separate domains.
Suppose you configured your environment to have the server_branch in one
domain (server_domain) and the client_branch in another domain
(client_domain). Each domain has its own policy database, independent of the
other. Multiple clients can be configured to each branch. Changes made to the
policy of one of the branches, for example, client_branch will cause the policy
updates to be sent only to those clients configured to client_domain.
The second advantage is that users and groups can be completely separate from
one domain to another. For example, the group osseal-admin could be defined in
one domain to have users root, osseal, liz, and anne as members and defined in
another domain to have users root, osseal, bill, and rusty defined as members. The
same users or groups could also be shared across multiple domains by importing
them into each domain.
Note: If more than one domain is being used, a security administrator must log in
to a specific domain to administer the policy in that domain.
System administrators should carefully consider the use of multiple domains when
defining their security policy. Thought should be given to disk space of the
replicated policy database, network speed, common users, common groups, and
policies.
Web Portal Manager is an optional component, packaged separately on
platform-specific CDs, that are included with the Tivoli Access Manager for
Operating Systems product package. For installation and usage information, see
the IBM Tivoli Access Manager for Operating Systems: Installation Guide and the IBM
Tivoli Access Manager: Administration Guide.
The pdadmin utility is installed as part of the Tivoli Access Manager Runtime
component. For more information about the pdadmin utility, see the IBM Tivoli
Access Manager for e-business: Command Reference.
Examples of establishing the policy in this guide are illustrated using the pdadmin
utility. These examples are always prefaced with the following prompt:
pdadmin>
Protected object name structure
Each resource has an object name that identifies the resource to Tivoli Access
Manager. After defining the object name, you can assign access controls to it.
Protected object names are comprised of the following main parts:
v Object space root
v Policy branch
v Resource type
v Object name
8 Administration Guide
Object space root
Every resource manager under Tivoli Access Manager has a object space where all
resource definitions are rooted. The object space for Tivoli Access Manager for
Operating Systems is OSSEAL. All protected machines or nodes use OSSEAL. The
OSSEAL object space is /OSSEAL.
Policy branch
Your environment probably has machines that require the same or similar
authorization policy because they are used for the same or similar purposes. With
Tivoli Access Manager for Operating Systems, you can group the policy for similar
machines under user-defined policy branches. Machines are configured to
subscribe to a particular policy branch during initial configuration. That policy
branch is referred to throughout the remainder of the documentation as the initial
policy branch.
The initial policy branch contains the policy that is required to protect Tivoli
Access Manager for Operating Systems. After initial configuration, each machine
can subscribe to additional policy branches using the pdosbranchcfg command. All
machines that subscribe to the same policy branches are subject to the same
authorization policy.
A policy branch is specified by the element of the object name immediately
following the /OSSEAL root. The administrator determines the name of the policy
branches. When referred to generically in the documentation, the policy branch is
referred to as /OSSEAL/policy-branch.
Assume that you have three classes of systems (servers, workstations, and test
machines). Because each class of systems has different security requirements, you
could define the following policy branches:
/OSSEAL/Servers
/OSSEAL/Workstations
/OSSEAL/Test
When you define a policy branch, a group identity is created in the user registry.
The name of the user registry group uses all lowercase alphabetic characters.
NetOutgoing
Login
RootDir Surrogate Password
File NetIncoming Sudo AuditAuth TCB
AuditTrace
OSSEAL
policy-branch policy-branch policy-branch
/ (root)
. . .. . .
. . . . . .
Figure 2. Tivoli Access Manager for Operating Systems object space
Chapter 2. Policy 9
Therefore when you create policy branches, ensure that its name is unique in the
Tivoli Access Manager environment regardless of alphabetic case.
If you create the policy branch /OSSEAL/Servers and the policy branch
/OSSEAL/SERVERS, only the first policy branch that was created would be added as
a group identity in the user registry as pdosd-branch/servers. Machines that are
subscribed to either the /OSSEAL/Servers policy branch or /OSSEAL/SERVERS policy
branch becomes members of the pdosd-branch/servers user registry group.
Although there is only one user registry group, there would still be a protected
object in the object space for each policy branch. The problem that you would
encounter in this situation is that you would be unable to determine group
membership for the policy branches.
For additional information, see “Obtaining membership reports” on page 148.
Resource types
Beneath a policy branch lie all the resource types that can be protected. Resource
types include system resources such as files and directories or other resources such
as Sudo commands, Surrogate actions, Network resources, and Audit resources.
The resource type specifies what kind of resource is being protected. For example,
the protected object name for all protected file system resources starts as follows:
/OSSEAL/policy-branch/File
.
Similarly, the protected object name for all Trusted Computing Base (TCB) secure
files starts as follows:
/OSSEAL/policy-branch/TCB/Secure-Files
Object name
Beneath the resource type are the actual resources themselves. Each resource type
has specific objects that can be protected. For example, file resources protect files
and directories. This is the lowest level of a protected object name because it
defines a single resource.
For file system resources, the object name is the file or directory name. For
network resources, the object name is the specified host and service information.
Each of the resource types specifies the information that identifies specific
instances of that resource in this part of the object name.
Many of the object names can represent system resources with names matching a
wildcard pattern. The basic elements of the wildcard patterns are described in
“Wildcards.” Each resource that makes use of wildcard patterns does so in
different ways. “Protected system resources” on page 27 describes how each
specific resource makes use of wildcards.
Wildcards
You can use wildcards to collectively protect resources that are not contained in a
hierarchy; for example, you could protect all files ending in .log or all host names
beginning with www. Table 2 on page 11 describes the basic elements that make up a
wildcard pattern.
10 Administration Guide
Table 2. Wildcard elements
Wildcard element Description
* Matches a string of any length of characters, including slash (/)
characters.
? Matches any single character.
+ Matches one or more occurrences of the previous element.
[set of characters] Matches a single character that is one of the set of characters.
The set of characters is specified according to the POSIX
wildcard expansion rules. For example, [a–z] matches any
ASCII character in the range from a to z.
a character Matches the exact character specified.
Use a backslash (\) character to inhibit the special significance of the character that
follows it. You can use two backslash (\\) characters when you need to match a
single backslash. Table 3 shows some wildcard patterns that match and some that
do not match.
Table 3. Wildcard matching examples
Pattern Matching strings Nonmatching strings
a* a
aa
a quick brown fox
ba
q a
over the dog
a\* a* ab
a? aa
al
a
aaa
/usr/local/*.log /usr/local/x.log
/usr/local/app/x.log
/usr/local/x.log.1
*.charity.org www.charity.org
ftp.charity.org
www.charity.org.com
[[:alpha:]]+ abcd
ABCD
/abcd
tty0
* *
(There is a space
between the asterisks)
a b
abcde ghijk lmnop
abcd
An empty string
Wildcard precedence
For each kind of resource that makes use of wildcard patterns, Tivoli Access
Manager for Operating Systems must determine which wildcard pattern to apply.
For example, assume that there are two patterns:
/usr/local/*.log
/usr/local/user1/*.log
The string /usr/local/user1/x.log matches both of these patterns.
To resolve this ambiguity, precedence rules are applied. The more specific a
pattern, the higher its precedence. According to this principal /usr/local/user1/x.log is matched against the /usr/local/user1/*.log pattern before the
/usr/local/*.log pattern. Because a match is found, any policy applicable to
objects matching this pattern will apply.
Chapter 2. Policy 11
Table 4 shows the precedence of wildcard elements. Elements higher in the table
have precedence over elements lower in the table.
Table 4. Wildcard element precedence rules
Precedence Element Example
1 Exact character a, \*, \\
2 Character range [Aa], [[:digit:]]
3 Arbitrary character ?
4 Repeated exact characters a+
5 Repeated character range [Aa]+, [[:digit:]]+
6 Repeated arbitrary character ?+
7 Arbitrary string *
Depending on the kind of resource, the precedence is determined by comparing
the patterns, element by element, from beginning to end or in reverse. Patterns for
matching file names are compared from beginning to end. Patterns for matching
host names are compared from end to beginning.
For two patterns otherwise considered equal, the longer pattern is considered more
specific than the shorter pattern unless the longer string is longer because of an
asterisk (*).
Examples of wildcard precedence
Table 5 shows file name and host name wildcard patterns arranged from highest
precedence to lowest. For the table, consider the case where the log/01/error.1
file or the www.help.atv.com host name is being accessed.
Table 5. Wildcard pattern precedence examples
Precedence File name pattern Host name pattern
1 log/0[0–9]/error.1 www.help.[a–z]tv.com
2 log/0?/error.1 www.help.?tv.com
3 log/0*/error.1 www.help.*tv.com
4 log/[0–9]+/error.1 www.help.[a–z]+v.com
5 log/*/error.1 www.help.*v.com
6 log*/error.1 www.help.*.com
7 log*/error.? www.*.com
8 log*/error* *www.*.com
9 log* *.com
10 * *
When the only difference between two patterns is the characters specified in a
character set, precedence is determined by lexically comparing the two strings
containing the patterns. This precedence must be taken into account only if the
character sets to be matched have some of the same characters. If there are no
common characters between the two sets, any given string can match, at most, one
of the patterns.
12 Administration Guide
Access controls
Tivoli Access Manager provides the following kinds of access controls:
Access Control Lists
Access control lists (ACLs) define access controls based on a user’s identity
and action performed or attempted.
Protected Object Policies
Protected object policies (POPs) define access controls based on other
information, such as the time an access is occurring, and control aspects of
an authorization decision such as whether or not the decision should be
audited.
Authorization Rules
Authorization rules (AuthzRules) define access controls based on the
attributes of a person or object and the context and environment
surrounding the access decision.
Access controls are applied by defining ACLs, POPs, and AuthzRules and then
attaching them to objects. The name of the object (the protected object name)
represents the resource being protected.
Tivoli Access Manager provides two ways of defining the set of objects that can be
protected:
v Dynamically by a resource discovery mechanism
v Statically by explicitly creating the objects in the policy database
Tivoli Access Manager for Operating Systems uses the static mode. Every object to
be protected, that is, every object that is to have an ACL or a POP attached, must
be explicitly created. For example, the following pdadmin command creates a
Tivoli Access Manager for Operating Systems File resource in the Servers policy
branch that represents the /etc/passwd file with a description of "Password file",
a type of 3 (meaning File resource), and ispolicyattachable yes (meaning policy
can be attached to the object):
pdadmin> object create /OSSEAL/Servers/File/etc/passwd "Password file" \
3 ispolicyattachable yes
Refer to the IBM Tivoli Access Manager for e-business: Command Reference for details
about the object create command and other pdadmin commands.
Tivoli Access Manager provides resource managers with the capability to extend,
in an application-specific way, the information contained in the policy database.
Application-specific extended attributes are used to extend the meaning of the
objects, ACLs, and POPs defined in the policy database. Tivoli Access Manager for
Operating Systems defines an extended ACL attribute, Access-Restrictions, to
implement access control based on the program being used to perform an action. It
defines two extended POP attributes, audit_permit_actions and
audit_deny_actions, to enable more granular per-resource-level auditing for
authorization decisions based on the action being performed against the protected
resource. For additional information, see “Audit-level attribute” on page 26.
It also defines extended object attributes to implement the Holidays, Login
Activity, Password Management, and Sudo resources. “Login policy” on page 50
and “Sudo Policy” on page 64 describe these extended attributes. The remainder of
this section describes each type of access controls and how Tivoli Access Manager
for Operating Systems uses them.
Chapter 2. Policy 13
Access control lists
An Access Control List (ACL) in the Tivoli Access Manager environment follows
the discretionary access control model. Access to resources is controlled based on
the identity of the user and the action that the user is performing.
ACLs consist of a list of ACL entries. Each ACL entry has an accessor and a
permission set. These components are denoted by the notation in the following
examples:
accessor : permission-set
A permission is represented by a single character that represents actions that can
be performed on objects to which an ACL is attached. For example the x
permission might represent permission to execute a program. The full set of
permissions used by Tivoli Access Manager for Operating Systems is described in
the Table 6 on page 15. The accessor describes the users that the ACL entry is to
apply to. The types of accessors are:
user This accessor type defines an ACL entry that controls access to a resource
for a particular user. The user’s name is also specified in an accessor of this
type. This user name must identify an existing Tivoli Access Manager user.
When Tivoli Access Manager is configured to multiple Active Directory
domains, specify the full user name in the ACL. A full user name includes
the name of the Active Directory domain.
The following ACL entry grants the x permission to the root user.
user root : x
This kind of ACL entry has the highest precedence. If the root user was a
member of a group that was denied the x permission, this ACL entry
would override that. Conversely, if the root user was a member of a group
that granted y permission, this ACL entry would have precedence and
deny root y permission on resources protected by this ACL. The user name
component of a user accessor in an ACL entry must be unique so that each
user has only one user entry in an ACL.
group This accessor type defines an ACL entry that controls access to a resource
based on group membership. The group’s name is also specified in an
accessor of this type. This group name must identify an existing Tivoli
Access Manager group.
When Tivoli Access Manager is configured to multiple Active Directory
domains, specify the full group name in the ACL. A full group name
includes the name of the Active Directory domain.
The following ACL entry grants the y permission to the users group:
group users : y
Users are granted permissions based on group membership, which is
indicated by all the permissions in group ACL entries for groups in which
they are members. For example, if the user kevin is a member of the
groups users and sys-admin, but not net-admin, then the following ACL
entries grant kevin a and b permission but not c:
group users : a
group sys-admin : b
group net-admin : c
14 Administration Guide
The group name component of a group accessor in an ACL entry must be
unique so that each group has only one group entry in an ACL.
any-other
The any-other ACL entry grants permissions to any authenticated user that
is not explicitly listed in a user entry within the ACL and is not a member
of any groups listed in group entries within the ACL. An entry of this type
allows definition of default permissions for authenticated users. The
following entry grants q permission to any authenticated user not covered
by a user or group entry in the ACL:
any-other : q
Only one any-other ACL entry can be in an ACL.
unauthenticated
The unauthenticated ACL entry grants permissions to unauthenticated
users. “The UNIX identity and its relationship to the Tivoli Access
Manager user identity” on page 3 explains the meaning of unauthenticated
users in Tivoli Access Manager for Operating Systems. Unauthenticated
users, by definition, have no Tivoli Access Manager user name nor can
they be members of Tivoli Access Manager groups. The following entry
grants p permission to unauthenticated users:
unauthenticated : p
Only one unauthenticated ACL entry can be in an ACL. Unauthenticated
users cannot be granted permissions that authenticated users do not have.
This means that any permissions granted by an unauthenticated ACL entry
that are not granted by the any-other ACL entry are ignored. In the above
example unauthenticated users would be granted p permission only if the
ACL also has an any-other entry that grants the p permission.
Permissions describe actions that can be performed on resources protected by
Tivoli Access Manager. The set of permissions specified in an ACL entry is the full
set of permissions granted to users that match the accessor of that ACL entry. A
user trying to perform an action not present in the permission set will be denied
access to any resources the ACL is protecting.
Permissions are defined by Tivoli Access Manager actions. An action defines a
single-letter mnemonic representing the permission, the name of the permission,
the kind of the resource it applies to, and the action group of which it is a part. An
action group is a collection of related actions. All Tivoli Access Manager for
Operating Systems actions are defined as members of the OSSEAL action group.
Actions in the OSSEAL action group represent operations that can be performed on
the resources that Tivoli Access Manager for Operating Systems protects. Table 6
defines all of the actions used by Tivoli Access Manager for Operating Systems.
Each permission is defined when it appears in this guide.
Table 6. Permissions defined in the OSSEAL action group
Action Description Resource Type
C Connect NetIncoming and NetOutgoing
D Change directory File
G Surrogate Surrogate
K Kill program File
L Login Login
Chapter 2. Policy 15
Table 6. Permissions defined in the OSSEAL action group (continued)
Action Description Resource Type
N Create File
R Rename File
U Update timestamp File
d Delete File
l List directory File
o Change ownership File
p Change permission File
r Read File
w Write File
x Execute File and Sudo
Tivoli Access Manager defines actions that control access to policy management
functions. Tivoli Access Manager uses these actions to control who can modify the
policy. These actions are all members of the primary action group. Policy
management uses the primary actions in Table 7.
Table 7. Tivoli Access Manager primary actions used for policy management
Action Description
a Attach an ACL or POP
b Browse object space and see object names
c Control or modify an ACL
d Delete an object
m Modify an object’s attributes
v View the attributes of an object
The full meaning of these permissions is explained in the IBM Tivoli Access
Manager: Administration Guide.
Table 8 lists the two other primary Tivoli Access Manager actions that affect the
way authorization decisions are made.
Table 8. Tivoli Access Manager primary actions used for policy decisions
Action Description
B Bypass protected object policy (POP)
T Traverse
R Bypass check for authorization rules
Setting the B permission causes any POP policy associated with the object to be
overridden, for example, any time-of-day restriction applicable is not applied.
Policy administrators need this permission to administer the policies on objects
that are subject to time-of-day access restrictions or have warning audit level
enabled. See “Protected object policies” on page 25 for an explanation of POP
attributes used for access control.
16 Administration Guide
The T, or Traverse, permission lets you control access to whole branches of
resources efficiently. See “Inheritance and traversal” on page 23 for details.
Setting the R permission causes the check for authorization rules to be bypassed.
See the Tivoli Access Manager base documentation for more information about
authorization rules.
When included in a permission set, all actions are prefixed by their action group
name. For actions in the primary action group this is optional. An ACL entry for
Tivoli Access Manager for Operating Systems typically looks like:
user root: T[OSSEAL]rwx
This indicates that the root user has the Tivoli Access Manager for Operating
Systems read, write, and execute permissions plus the Traverse permission. Other
resource managers can define actions with mnemonic names similar to those used
by Tivoli Access Manager for Operating Systems. For example the Tivoli Access
Manager WebSEAL uses r to grant permission to read a Web page protected by
WebSEAL. These permissions, despite having the same mnemonic, are entirely
separate and should not be confused. An ACL entry with the permission set
Br[OSSEAL]wx does not grant Tivoli Access Manager for Operating Systems users
read access to files that the ACL for this entry might be protecting.
Access restrictions
Tivoli Access Manager for Operating Systems defines an extended attribute on an
ACL that lets you control what programs users can use to perform particular
actions. The name of the attribute is Access-Restrictions. Access to resources is
controlled based on the identity of the user, the action that the user is performing,
and the current program being used to perform the action. This restriction is in
addition to the access control enforced by the base ACL that the attribute is
associated with. Before an access restriction is applied the user must first have
been granted access by the base ACL entries.
Entries for the Access-Restrictions attribute fall into two categories, permit entries
and deny entries.
Permit entries allow you to define the policy that grants the accessor access to the
protected resource for the specified actions if, and only if, the currently running
program used to perform the action matches one of the programs listed in the
program set. If a permit entry applies to a given access and the currently running
program does not match one of the programs listed in the entry’s program set,
access is denied.
Deny entries allow you to define the policy that denies the accessor access to the
protected resource for the specified actions if the currently running program used
to perform the action matches one of the programs listed in the program set. Only
access using one of the programs listed in the entry’s program set is restricted. A
deny entry has no effect on accesses if the currently running program used to
perform the action is not listed in the program set.
Note: Using specific running program names in the specification of a deny entry is
not a secure policy specification if the specified program resource does not
have a restrictive file policy on it. If a user who is denied access to resource
ResourceA when using program ProgramA can rename, copy to a new
location, or create a link to ProgramA with a different name, then the user
can use these methods to bypass the specified deny rule.
Chapter 2. Policy 17
Within entries of the same accessor type, deny entries have a higher precedence
then permit entries.
The Access-Restrictions attribute can be defined for ACL entries that are applied
to any of the following resources:
v File
v NetIncoming
v NetOutgoing
v Login
v Surrogate
It is meaningless to define an Access-Restrictions attribute for Sudo resources,
because the accessing program is always the pdossudo command. See “Sudo
Policy” on page 64 for a description of Sudo policy and the pdossudo command.
The format for an extended attribute Access-Restrictions entry is:
rule : accessor : permission-set : program-set
The rule value specifies what type of entry this is. Valid values are permit or deny.
Specifying a rule value is optional. Attribute entries that do not contain a rule
element will be enforced as a permit rule.
The accessor describes the users that the extended attribute entry is to apply to.
The types of accessors are the same as the accessor component of an ACL entry:
v user
v group
v any-other
v unauthenticated
If the accessor type is user or group, the name that follows the accessor type is the
name in the Tivoli Access Manager user registry. When Tivoli Access Manager is
configured to multiple Active Directory domains, the user or group name is the
full name, which includes the name of the Active Directory domain.
The permission set is defined in the same way as in an ACL entry except that,
because this extended attribute applies only to Tivoli Access Manager for
Operating Systems actions, you can omit the [OSSEAL] action group qualifier. It is
important to group actions in the permission set. Only the attribute entries whose
permission set contains all of the permissions associated with the actions being
performed against the protected resource are evaluated to see if they apply to the
current access decision. For example, if read and write access is requested, then
only entries with both the r and w permissions (and possibly others) are
considered. You can use the special permission set * to indicate that this entry
applies to all possible actions in the OSSEAL action group.
The program set is a space-separated list of programs.
In a permit entry (the rule value is either permit or not specified), the program set
is the complete list of programs that the accessor is allowed to use to perform the
actions specified in the permission set on the protected resource. The accessor is
granted access to the protected resource for the specified actions if, and only if, the
currently running program used to perform the action matches one of the
programs listed in the program set. Access using a program not listed in the
program set is denied. It is important that the program set contain a complete list
of the programs that the accessor is allowed to use. Programs listed in a permit
entry’s program set are trusted to access the resource protected by the ACL. These
18 Administration Guide
programs are, therefore, included in the Trusted Computing Base. See “Trusted
Computing Base resources” on page 36 for information about the Trusted
Computing Base. The special program set * means that any program can be used
to perform the actions.
In a deny entry (the rule value is deny), the program set is the list of programs that
the accessor is not allowed to use to perform the actions specified in the
permission set on the protected resource. The accessor is denied access to the
protected resource for the specified actions if the current running program matches
one of the programs listed in the program set. A deny entry has no effect on access
if the currently running program used to perform the action is not listed in the
program set. The special program set * means that no program can be used to
perform the actions. Programs listed in a deny entry’s program set are not
included in the Trusted Computing Base.
Within entries of the same accessor type, deny entries have a higher precedence
then permit entries.
Types of restrictions that can be defined
The Access-Restrictions extended attribute allows access to resources to be
controlled based on the identity of the user, the action that the user is performing,
and the current program being used to perform the action. The following types of
restrictions can be expressed for accesses to the resource protected by the ACL with
the Access-Restrictions attribute:
v The programs specified in the program set cannot be used by the accessor to
perform the actions specified in the permission set:
deny : accessor : permission-set : program-set
v Only the programs specified in the program set can be used by the accessor to
perform the actions specified in the permission set:
permit : accessor : permission-set : program-set
accessor : permission-set : program-set
v The programs specified in the program set cannot be used by the accessor to
access the protected resource regardless of the action:
deny : accessor : * : program-set
v Only the programs specified in the program set can be used by the accessor to
access the protected resource regardless of the action:
permit : accessor : * : program-set
accessor : * : program-set
v No program can be used by the accessor to perform the actions specified in the
permission set:
deny : accessor : permission-set : *
v Any program can be used by the accessor to perform the actions specified in the
permission set:
permit : accessor : permission-set : *
accessor : permission-set : *
v No program can be used by the accessor to access the protected resource
regardless of the action:
deny : accessor : * : *
v Any program can be used by the accessor to access the protected resource
regardless of the action:
permit : accessor : * : *
accessor : * : *
Chapter 2. Policy 19
Access restriction evaluation
When making an access decision, the base ACL entries are evaluated first.
Access-Restrictions attribute entries associated with the base ACL controlling
access to a protected resource are only evaluated if the base ACL granted the
accessing user access to perform the specified action against the protected resource.
When Access-Restrictions attribute entries are evaluated, the following rules are
used to determine which, if any, entries apply to this access request. The term
user’s program refers to the currently running program being used to access the
protected object. If no attribute entries apply that deny access, the access granted
by the base ACL still applies and access is granted.
If the user is authenticated, entries with accessor values of user, group, and
any-other apply. Only the attribute entries whose permission set contains all of the
permissions associated with the actions being performed against the protected
resource are evaluated to see if they apply to the current access decision. For
example, if read and write access is requested, then only entries with both the r
and w permissions (and possibly others) are considered. Entries with a permission
set value of * match all access requests regardless of the action being performed.
v Entries with the accessor type user have the highest precedence during
evaluation:
– If a deny rule entry is found with a user accessor type and the specified name
matches the accessing user’s name and the user’s program or * is included in
its program set, access is denied.
– If a permit rule entry is found with a user accessor type and the specified
name matches the accessing user’s name and the user’s program or * is
included in the entry’s program set, access is granted.
– If access has not been granted by other user accessor type entries and if a
permit rule entry is found with a user accessor type and if the specified name
matches the accessing user’s name and if the user’s program or * is not
included in the entry’s program set, access is denied.v If no matching user accessor entries are found, entries with the group accessor
type are evaluated:
– If a deny rule entry is found with a group accessor type and the specified
name matches a group the accessing user is a member of and the user’s
program or * is included in its program set, access is denied.
– If a permit rule entry is found with a group accessor type and the specified
name matches a group the accessing user is a member of and the user’s
program or * is included in its program set, access is granted.
– If access has not been granted by other group accessor type entries and if a
permit rule entry is found with a group accessor type and if the specified
name matches a group to which the accessor is a member and if the user’s
program or * is not included in the entry’s program set, access is denied.v If no matching user or group accessor entries are found, entries with the
any-other accessor type are evaluated:
– If a deny rule entry is found with an any-other accessor type and the user’s
program or * is included in its program set, access is denied.
– If a permit rule entry is found with an any-other accessor type and the user’s
program or * is included in its program set, access is granted.
– If access has not been granted by other any-other accessor type entries and if
a permit rule entry is found with an any-other accessor type and if the user’s
program or * is not included in the entry’s program set, access is denied.
20 Administration Guide
If the user is unauthenticated, only entries with accessor value unauthenticated
apply. As with authenticated users, only the attribute entries whose permission set
contains all of the permissions associated with the actions being performed against
the protected resource are evaluated to see if they apply to the current access
decision:
v If a deny rule entry is found with an unauthenticated accessor type and the
user’s program or * is included in its program set, access is denied.
v If a permit rule entry is found with an unauthenticated accessor type and the
user’s program or * is included in the entry’s program set, access is granted.
v If access has not been granted by other unauthenticated accessor type entries
and if a permit rule entry is found with an unauthenticated accessor type and
the user’s program or * is not included in the entry’s program set, access is
denied.
v If no Access-Restrictions attribute entry applies that deny access, the access
granted by the base ACL still applies and access is granted.
For example, assume that the following Access-Restrictions attribute values are
defined. The base ACL grants the necessary access so that these entries will be
evaluated and the ACL is attached to a File resource.
permit : user root : r : *
permit : group MgmtB : * : *
permit : group ProjectB : rw : /opt/projectB/bin/applicationY
deny : group RestrictAccess : * : *
deny : any-other : * : *
Please note that the entries shown are simply to facilitate explaining how
evaluation works. It might be necessary to include other permissions in the
permission set depending upon the resources being protected and the actions that
need to be performed on them.
If the root user attempts read access to the protected resource, the access will be
allowed because the permit entry for accessor user root allows it. The user root
would not be allowed to do other actions, such as write to the protected file,
because the deny entry for accessor any-other denies it. The user root entry would
not apply in this case because the permission set value, r, does not contain the
permission associated with the write action being performed, w.
If a user, who is a member of both the RestrictAccess and ProjectB groups,
attempts to access the protected resource for read and/or write using the program
/opt/projectB/bin/applicationY, the access will be denied. This is because the
deny entry for group RestrictAccess has higher precedence over the permit entry
for group ProjectB.
Users who are members of the group ProjectB and are not members the group
RestrictAccess are allowed read and/or write access to the protected resource
using the program /opt/projectB/bin/applicationY. They would not be allowed
to do other actions such as change the ownership of a protected file because the
deny entry for accessor any-other denies it. The group ProjectB entry would not
apply in this case because the permission set value, r, does not contain the
permission associated with the change ownership action being performed, o.
Users who are members of the group MgmtB and are not members the group
RestrictAccess are allowed to use any program to perform any action against the
protected resource.
Chapter 2. Policy 21
All other authenticated users are denied access to the protected resource for all
actions regardless of the program being used. An any-other entry like this is useful
to ensure that access is not granted to a user unintentionally. For example, the
Access-Restrictions attribute entries do not explicitly restrict other actions for the
root user. Without the any-other Access-Restrictions entry, root would be allowed
to perform any other action granted by the ACL. Access involving actions other
than read would be controlled only by an entry such as this one or by the ACL
entries in the base ACL to which these Access-Restrictions attribute entries have
been applied. To ensure that the root user cannot perform actions other than read,
this type of entry should be defined or the base ACL entries should only allow
read access for the user root. If the base ACL entries grant access other than read
and this entry did not exist, the user root can use any program to perform the
other actions.
Examples of access restrictions
In the following examples, assume that the platform is AIX and Tivoli Access
Manager for Operating Systems is configured to use the policy-branch name
Servers.
Example 1
This example uses permit entries to allow all users read access to the
/etc/passwd file, and to restrict any user who is not a member of the
sys-admin group to only using the /usr/bin/passwd command to write to
the file.
1. Create the base ACL that allows all authenticated users (any-other) and
unauthenticated users rw access:
pdadmin> acl create passwd
pdadmin> acl modify passwd set any-other T[OSSEAL]rw
pdadmin> acl modify passwd set unauthenticated T[OSSEAL]rw
2. Define Access-Restrictions extended attribute entries associated with
this ACL to further control read and write access.
a. Define a permit entry that allows users who are members of the
group sys-admin read and write access using any program:
pdadmin> acl modify passwd set attribute \
Access-Restrictions "group sys-admin:rw:*"
b. Define permit entries that allow all other authenticated users
(any-other) and unauthenticated users read access using any
program:
pdadmin> acl modify passwd set attribute \
Access-Restrictions "any-other : r : *"
pdadmin> acl modify passwd set attribute \
Access-Restrictions "unauthenticated : r : *"
c. Define permit entries that allow all other authenticated users
(any-other) and unauthenticated users write access only when using
the program /usr/bin/passwd:
pdadmin> acl modify passwd set attribute \
Access-Restrictions "any-other : rw : /usr/bin/passwd"
pdadmin> acl modify passwd set attribute \
Access-Restrictions "unauthenticated : rw : /usr/bin/passwd"
3. Create a protected object name to control access to the /etc/passwd file
and attach the passwd ACL:
pdadmin> object create /OSSEAL/Servers/File/etc/passwd "passwd file" 3 \
ispolicyattachable yes
pdadmin> acl attach /OSSEAL/Servers/File/etc/passwd passwd
22 Administration Guide
Example 2
This example uses both permit and deny entries to set up login restrictions
that do the following:
v Allows members of the group sys-admin to login from any remote
terminal using any program
v Allows members of app-admin to login from any remote terminal using
any program except by connecting to ftpd
v Allows all other authenticated users to login from any remote terminal
only by connecting to telnetd
v Denies unauthenticated users login access from remote terminals1. First create the base ACL that allows all authenticated users (any-other)
login access (L) and denies unauthenticated users login access:
pdadmin> acl create remote-login
pdadmin> acl modify remote-login set any-other T[OSSEAL]L
pdadmin> acl modify remote-login set unauthenticated T[OSSEAL]
2. Define Access-Restrictions extended attribute entries associated with
this ACL to further control how authenticated users can log in based on
their group membership and the program being used.
a. Define a permit entry that allows users who are members of the
group sys-admin to log in using any program:
pdadmin> acl modify remote-login set attribute \
Access-Restrictions "permit : group sys-admin : L : *"
b. Define a deny entry that restricts users who are members of
app-admin from login using the /usr/sbin/ftpd daemon. Login
through other programs is not restricted:
pdadmin> acl modify remote-login set attribute \
Access-Restrictions "deny : group app-admin : L : /usr/sbin/ftpd"
c. Define a permit entry that allows all other authenticated users
(any-other) to log in from any remote terminal only when
connecting to the /usr/sbin/telnetd daemon:
pdadmin> acl modify remote-login set attribute \
Access-Restrictions "permit : any-other : L : /usr/sbin/telnetd"
3. Create a protected object name to control access from remote terminals
and attach the remote-login ACL:
pdadmin> object create /OSSEAL/Servers/Login/Terminal/Remote \
"remote login" 3 ispolicyattachable yes
pdadmin> acl attach /OSSEAL/Servers/Login/Terminal/Remote remote-login
Inheritance and traversal
In the Tivoli Access Manager environment, resources can inherit ACLs from other
resources.
Examining the protections of file resources is an example of inheritance. For
example, the project01 directory contains all files for this project, and the
protected object name of this directory is /OSSEAL/default/File/project01. By
placing an ACL on the protected object name for the /project01 directory, all
subdirectories and files in this directory inherit that ACL from project01.
Inheritance lets you apply the access controls (ACLs, POPs, and authorization
rules) to a number of resources by attaching those access controls high up in the
protected object hierarchy.
Chapter 2. Policy 23
Inheritance applies to all resources. If a resource does not have access controls
attached to it, Tivoli Access Manager traverses up the protected object hierarchy
until it finds an attached access control. This rule has the following exceptions:
v When protecting file system resources, assumes that a permissive ACL, that is an
ACL that grants all accesses, is attached to the root of the file system. This
permissive ACL ensures that a system remains functional when Tivoli Access
Manager for Operating Systems is protecting it and also ensures that Tivoli
Access Manager for Operating Systems can make efficient authorization
decisions when file system resources are accessed.
v Tivoli Access Manager for Operating Systems can be configured to assume that
permissive ACLs are attached at the /OSSEAL/branch/NetIncoming and
/OSSEAL/branch/NetOutgoing points in the object hierarchy, using the
–net_ACL_limited option (see “Limiting ACL inheritance for a network policy”
on page 148). These permissive ACLs allow Tivoli Access Manager for Operating
Systems to make more efficient authorization decisions for network accesses,
only generating authorization checks for network resources that are explicitly
protected by an ACL.
For example, assume that the client is configured to the default policy branch and
that a user is trying to access a network resource with a protected object name of
/OSSEAL/default/NetIncoming/tcp/telnet/www.company.com. If that protected object
does not have access controls attached to it, Tivoli Access Manager looks to see if
/OSSEAL/default/NetIncoming/tcp/telnet has access controls attached to it. If this
level does not have access controls attached to it, Tivoli Access Manager looks to
see if /OSSEAL/default/NetIncoming/tcp has access controls attached to it. Tivoli
Access Manager traverses up the hierarchy in this manner until it finds an access
control that it can use to make a decision, or until it reaches a point where there is
an implicit permissive ACL (/OSSEAL/default/NetIncoming) if limited network ACL
inheritance is configured.
When a machine is configured to multiple branches, inheritance depends upon the
precedence order of the configured branches. The most precise definition of a
resource will always apply. However, if the most precise definition of a resource is
the same in multiple policy branches, then the policy from the branch of the
highest precedence is applied. All ACLs, POPs, and authorization rules are
inherited from the same branch.
For example, assume that a client is configured to the default and AppA policy
branches with the following precedence order:
1. default
2. AppA
Also assume that a user is trying to access a network resource with a protected
object name of NetIncoming/tcp/telnet/www.company.com. Tivoli Access Manager
checks the following sequence of locations until it finds the attached access
controls:
1. /OSSEAL/default/NetIncoming/tcp/telnet/www.company.com
2. /OSSEAL/AppA/NetIncoming/tcp/telnet/www.company.com
3. /OSSEAL/default/NetIncoming/tcp/telnet
4. /OSSEAL/AppA/NetIncoming/tcp/telnet
5. /OSSEAL/default/NetIncoming/tcp
6. /OSSEAL/AppA/NetIncoming/tcp
24 Administration Guide
Tivoli Access Manager continues up the hierarchy until it finds an access control
that it can use to make a policy decision or until it reaches a point where there is
an implicit, permissive ACL (/OSSEAL/default/NetIncoming), if limited network
ACL inheritance is configured.
When making a policy decision, Tivoli Access Manager for Operating Systems uses
the ACL lowest in the hierarchy. This lower-level ACL completely overrides any
higher-level ACL. For example, assume the following:
v Assume that you have a file resource with a protected object name of
/OSSEAL/servers/File/usr/games/solitaire. The solitaire game is a file, and
/usr and /games are directories.
v You have one ACL on the usr directory that gives everyone full access and
another ACL on solitaire that gives only the administrator full access.
v By inheritance, the /games directory under /usr is accessible to everyone, but
solitaire is accessible only by the administrator, no matter what ACL entries
are present in the ACL at the /usr directory.
The only exception to the rule that an ACL lower in the hierarchy entirely
overrides a higher one is the behavior of the primary Tivoli Access Manager
Traverse permission (T). For a user to access a resource, that user must be granted
Traverse permission in every ACL higher in the hierarchy than the object being
accessed. Traverse permission is not required to access the object itself. In the
previous example, the administrator needs Traverse permission in the ACL
attached at /usr but not in the ACL attached at solitaire. If an ACL were placed
at /games, the administrator would also require Traverse permission be granted by
that ACL.
Protected object policies
Tivoli Access Manager provides a form of access control called a protected object
policy (POP). POPs define access controls that are not based on user identity or the
action the user is performing; they also control other details about how an
authorization decision is made. POPs, like ACLs, are defined by the administrator
and are attached to objects in the Tivoli Access Manager database that represent
the resources being protected. POPs obey the same inheritance rules as ACLs.
POPs and ACLs are inherited independently; you do not need to attach them at
the same point in the object hierarchy. Any given object might inherit access
controls from an ACL attached at one point in the hierarchy and from a POP at
another. In the preceding solitaire example, assume that a POP restricting
time-of-day access at the games directory is defined. Access is controlled to
solitaire by the ACL attached directly to it and, by inheritance, the POP attached
above it at games.
You can define various attributes within a POP. Tivoli Access Manager for
Operating Systems uses the warning mode, audit level, and time-of-day attributes.
Tivoli Access Manager for Operating Systems does not use the Quality of
Protection or IP endpoint authentication method policy attributes.
POPs provide several attributes that you can use to implement specific policies.
Warning-mode attribute
The access control warning-mode attribute enables you to implement a trial policy.
A protected object protected by a POP with warning set to yes has warning mode
enabled. When an ACL denies access to an object with warning mode enabled,
Chapter 2. Policy 25
instead of the access being denied, it is granted and an audit record is generated.
You can try a policy by applying ACLs where you believe they should go and then
examining the audit trail to verify that accesses that should be denied are denied
and accesses that should be granted are granted. Audit records are generated
regardless of the audit level setting in the POP when warning mode is enabled. See
“Enabling, disabling, and querying resource warning mode” on page 251 for
examples of the warning mode attribute.
By default, warning mode is disabled.
Audit-level attribute
The audit-level access control specifies under what circumstances an access to an
object generates an audit record. The audit level is set to one or more of the
following levels:
permit
If enabled, an audit event is generated when access to the resource is
granted
deny If enabled, an audit event is generated when access to the resources is
denied
admin Does not apply to Tivoli Access Manager for Operating Systems resources
error Does not apply to Tivoli Access Manager for Operating Systems resources
all All of the defined audit levels are enabled
none None of the defined audit levels are enabled. This is the default.
To enable auditing based on the action being performed against the protected
resource, extended attributes specifying the accessing permissions can be set on a
POP in conjunction with the audit-level attribute.
The names of the extended attributes are audit_permit_actions and
audit_deny_actions. Their formats are:
audit_permit_actions permission-set
audit_deny_actions permission-set
The permission-set is defined in the same way as in an ACL entry. These extended
attributes apply only to Tivoli Access Manager for Operating Systems actions. The
[OSSEAL] qualifier must be specified in front of the actions.
The audit_permit_actions and audit_deny_actions extended POP attributes only
take effect if the corresponding audit level is enabled by the audit-level attribute.
If permit is enabled in the audit-level attribute and the extended attribute
audit_permit_actions is defined in the POP, an audit record is generated when
access to the resource is granted for the actions specified in the permission-set.
Audit records are not generated when access to the resource is granted for actions
not specified in the permission-set.
If deny is enabled in the audit-level attribute and the extended attribute
audit_deny_actions is defined in the POP, an audit record is generated when
access to the resource is denied for the actions specified in the permission-set.
Audit records are not generated when access to the resource is denied for actions
not specified in the permission-set.
26 Administration Guide
See “Setting and querying the resource audit level” on page 244 for examples of
setting the resource audit level. Further details about the audit levels are in the
Tivoli Access Manager documentation.
Time-of-day attribute
The time-of-day access control specifies days of the week and the times of the day
that a resource can be accessed. The time-of-day access control specification is of
the form:
day-range : time-range [:utc|:local]
where:
day-range
Either anyday, weekday, or a comma-separated list of sun, mon, tue, wed, thu,
fri, or sat. The anyday option indicates that the user is permitted access
on any day of the week. The weekday option specifies that the user is
permitted access on any day except for Saturday and Sunday. A list of days
indicates that the user is permitted to access the resource only on the
specified days.
time-range
Either anytime or a start time and end time. The anytime option indicates
that the user is permitted to access the resource at any time on the days of
the specified by the day-range. If time is specified in the form
start_hhmm-end_hhmm, the start_hhmm specifies an hour followed by
minutes past the hour, and the end_hhmm specifies the end time. Specify
the hour in 24-hour format.
utc Specifies that the time-of-day restriction should be applied according to
Universal Coordinated Time (UTC).
local Specifies that the time-of-day restriction should be applied according to the
local time on the machine the user is logging in on. This is the default.
By default, access is permitted on all days at all times.
Protected system resources
This section describes protected system resources as they are defined in the Tivoli
Access Manager for Operating Systems environment. It specifies what resources
can be protected, how the resources are defined in the policy object space, and
what actions can be defined for a resource. It also describes how resources are
defined in the Trusted Computing Base (TCB) and how TCB resources are treated.
File policy
Tivoli Access Manager for Operating Systems provides the ability to control access
to file system resources. File system resources consist of:
v Files
v Directories
v Soft links
v Hard links
v Device files
This section describes how access to each of these resources is affected when the
authorization policy is applied to them. File system resources are protected in the
following ways:
Chapter 2. Policy 27
v Access controls protect file system resources based on the identity of the user
attempting the access and the action the user is trying to perform. They are
applied to resources of type File.
v Membership in the TCB protects file system resources by monitoring the
members’ contents and attributes for change. The membership of the TCB is
defined by resources of type TCB or file being in the permit list of an
Access-Restrictions.
File resources
File system resources are represented in the Tivoli Access Manager object space by
defining an object name with resource type File and specifying the name of the file
system resource to be protected:
/OSSEAL/policy-branch/File/filespec
Table 9 details the file system objects.
Table 9. File system objects
Object name Description Type
filespec An object name that represents a
file system resource. The string
specifies the full path name of the
file resource being protected. The
path name can contain wildcards.
String conforming to the UNIX
file-naming rules.
Example File System Resources
Some example file system resource specifications are:
/OSSEAL/Default/File/etc/passwd
/OSSEAL/Default/File/usr/local/*/*.log
/OSSEAL/Default/File/usr/sbin/httpd
The following restrictions apply when naming File resources:
v Access controls cannot be attached to the root directory, /. Tivoli Access
Manager for Operating Systems always assumes that permissive access controls
are attached at /OSSEAL/policy-branch/File. An explicit access control (ACL,
POP, or AuthzRule) that is attached to the File object or higher is ignored for
both access to the file system root directory (/) and for purposes of ACL
inheritance.
v The first element of a file specification cannot contain wildcard elements (for
example, /*.log or /*/tmp). Specific resources in the root directory can have
access controls.
These restrictions ensure that authorization decisions can be made efficiently.
Access control on File resources
Tivoli Access Manager ACLs can be placed at any point in a file system resource
representation in the object space. Normal Tivoli Access Manager ACL inheritance
rules apply to file system resources. This includes object space traversal (T)
permissions.
An exception to the normal ACL inheritance model is the root of the file system
object space, for example, /OSSEAL/policy-branch/File. Tivoli Access Manager for
Operating Systems assumes that there is always an ACL at that point that permits
access (and traversal) to everyone. Thus, for the purposes of ACL inheritance, the
effective root of the object space is at this position. In other words, an explicit ACL
28 Administration Guide
attached to the File object or higher is ignored for both access to the file system
root directory (/) and for the purposes of inheritance.
To define the access control policy for the root directory, create a resource
/OSSEAL/policy-branch/RootDir and attach the access control policy (ACLs and
POPs). See“Access control on the root directory” on page 30 for more information.
Table 10 details the valid ACL permissions that can be associated with File system
resources.
Table 10. File permissions
Permission name Permission granted
Read (r) Access a file system resource for reading.
Write (w) Access a file system resource for writing.
Create (N) Create a particular file system resource.
Execute (x) Execute a file system resource.
Chown (o) Change the ownership of a file system resource.
Chmod (p) Change the native UNIX file system permissions associated with
a file system resource. This applies to both operations that
modify UNIX mode bits and to operations that alter a resource’s
native ACL for applicable platforms.
Chdir (D) Change directory into a file system directory resource
(directories only).
Rename (R) Move (or rename) a file system resource.
Delete (d) Remove a file system resource.
Utime (U) Modify the file access and modification times associated with a
file system resource.
Kill (K) Terminate a process that was executed from a file system
resource.
List (l) List the contents of a directory.
Many of the permissions have special behaviors or, where an equivalent UNIX
permission exists, slightly different behavior. These behaviors are as follows:
v The Kill (K) permission can be applied to the special File resource
/OSSEAL/policy-branch/File/unix to control the ability to shut down or reboot
the system.
v The Rename (R) permission interacts with the Create and Delete permissions.
When renaming a file, in addition to Rename permission on the source file, the
user must have create permission on the target. If the target exists the user must
additionally have permission to delete it. For example, if a directory has the
contents:
log.1 log.bak
then a user issuing the command:
$ mv log.1 log.2
in the directory must have Rename permission on the file log.1 and Create
permission on log.2. If the command:
$ mv log.1 log.bak
Chapter 2. Policy 29
were issued, the user would need both Create and Delete permission on the file
log.bak.
v The Chmod permission (p) permission also controls the ability to modify UNIX
ACLs in addition to file permission. This applies only on systems that support
this facility.
v The Execute (x) permission applies only to files. The UNIX execute (x) file
permission also controls the ability to navigate a directory hierarchy. The Tivoli
Access Manager for Operating Systems Change directory permission (D) and
primary Traverse (T) permission can be used together to control a user’s ability
to navigate file systems directories.
Access control on the root directory
Access control on the root directory (/) and its contents is accomplished using this
special File resource, /OSSEAL/policy-branch/RootDir.
To define the access control policy for the root directory (/), create the object
/OSSEAL/policy-branch/RootDir and attach the access control policy (ACLs and
POPs). ACLs and POPs attached to the RootDir object apply to the root directory
itself and files and directories residing in the root directory that are not governed
by the policy defined under the File resource. The policy defined under the File
resource takes precedence over the policy defined for the RootDir object. When
defining the access control policy for the root directory, you should consider
following:
v The policy governing the RootDir object applies both to the root directory itself
and its immediate content. The policy governing RootDir applies to all files and
directories residing in the root directory that are not governed by the policy
defined under the File resource. For example, defining the policy that is too
restrictive can prevent users from accessing directories commonly used by users
and applications, such as /tmp and /home.
v No objects should be defined under the RootDir object. An error will be logged
in /var/pdos/log/msg__pdosd.log if an object is defined under the
/OSSEAL/policy-branch/RootDir object.
v Unlike objects defined as File resources, ACLs and POPs attached to the RootDir
object are not inherited.
An example of the access control policy for the root directory (/) follows. The
security administrator wants to protect the root directory and its contents that are
not governed by the policy defined under the File resource. The administrator
wants to define the policy that gives all unauthenticated and authenticated users
(any-other) read-only access to files and directories that reside in the root directory
and allows them to change directory into directories that reside in the root
directory, but does not allow them to create files or modify the contents of any files
and directories residing in the root directory. The policy should also give members
of the admin group full access to the root directory and the files and directories
residing in the root directory. In addition, all users should have full access to the
/tmp directory and its contents. For this example, the branch name is called system:
pdadmin> object create /OSSEAL/system/RootDir "root dir" 0 \
ispolicyattachable yes
pdadmin> acl create rootdir_acl
pdadmin> acl modify rootdir_acl set unauthenticated T[OSSEAL]Dlr
pdadmin> acl modify rootdir_acl set any-other T[OSSEAL]Dlr
pdadmin> acl modify rootdir_acl set group admin T[OSSEAL]DKNRUdloprwx
pdadmin> acl attach /OSSEAL/system/RootDir rootdir_acl
pdadmin> object create /OSSEAL/system/File/tmp "tmp dir" 0 \
ispolicyattachable yes
pdadmin> acl create tmpdir_acl
30 Administration Guide
pdadmin> acl modify tmpdir_acl set unauthenticated T[OSSEAL]DNRUdloprwx
pdadmin> acl modify tmpdir_acl set any-other T[OSSEAL]DNRUdloprwx
pdadmin> acl attach /OSSEAL/system/File/tmp tmpdir_acl
File system aliases
The file system provides the ability to define alias names for resources. When a
resource is accessed by an alias, Tivoli Access Manager for Operating Systems
ensures that the underlying resource is protected. The following types of file
system aliases are available:
v Symbolic links
v Hard links
v Device files
The following sections describe how Tivoli Access Manager for Operating Systems
enforces the authorization policy when protected resources are accessed through
the different kinds of alias and when the authorization policy is associated with an
alias rather than the real resource.
The major principles that define the way Tivoli Access Manager for Operating
Systems handles access controls in conjunction with alias names are as follows:
v Access controls that are applied to an alias should protect the real resource and
the alias.
v The creation of a new alias should not be allowed to bypass access controls that
are already applied to the real resource.
Symbolic links
Consider how symbolic links affect the way the policy is evaluated when access
controls are not inherited. There are three possibilities:
v The target has access controls applied to it. When the target of the symbolic link
has an access control applied but the symbolic link does not, accesses to the
resource by either name are controlled by the policy that is attached to the
target. A symbolic link cannot be used to sidestep the authorization policy.
v The symbolic link has access controls applied to it. When the symbolic link has
access control applied but the target does not, accesses to the resource by either
name are controlled by the policy that is attached to the symbolic link.
v Both the target and the symbolic link have access controls applied. When access
controls are applied to both the symbolic link and its target, accesses to the
target directly are controlled only by the access control that is directly applied.
Accesses via the symbolic link are controlled by both sets of access controls and
access is granted to the resource only if the accessor is permitted by both sets of
access controls.
v On Linux platforms that are running with a 2.6 kernel, some ACLs cannot be
enforced when they are applied to a symbolic link. For additional information,
see “Symbolic links on Linux running a 2.6 kernel” on page 32.
Protection of file resources where path contains a symbolic link: When defining
policy on a file and any part of the path is a symbolic link, the policy will not be
enforced on the file as might be expected. For example consider policy to protect
the /opt/dir/executable file and the /usr/link directory is a symbolic link to the
/opt/dir directory, assume that policy is defined on the /usr/link/executable file
using the following commands:
Chapter 2. Policy 31
pdadmin> object create /OSSEAL/branch/File/usr/link/executable "test" \
3 ispolicyattachable yes
pdadmin> acl create testacl
pdadmin> acl modify testacl set any-other T[OSSEAL]lrw
pdadmin> acl attach /OSSEAL/branch/File/usr/link/executable testacl
When you attempt to run the executable file, it runs when you might expect that
it would not run. The symbolic link to the /opt/dir directory is not a protected
container object. The defined policy cannot be enforced, because the directory path
contains a symbolic link. The /usr/link/executable path actually identifies the
/opt/dir/executable file system resource. When you run the executable file, Tivoli
Access Manager for Operating Systems identifies that the /opt/dir/executable
resource is being run even when you specify /usr/link/executable as the path.
The authorization check is then done for the /opt/dir/executable resource so that
the specified policy will not apply.
To correctly protect file resources that contain symbolic links in the path, you need
to define policy for the actual file resource with the full path with no symbolic
links. Using the previous example, create the policy for the /opt/dir/executable
file with the following commands:
pdadmin> object create /OSSEAL/branch/File/opt/dir/executable "test1" \
14 ispolicyattachable yes
pdadmin> acl create testacl1
pdadmin> acl modify testacl1 set any-other T[OSSEAL]lrw
pdadmin> acl attach /OSSEAL/branch/File/opt/dir/executable testacl1
When you attempt to run the executable file using either /opt/dir/executable or
/opt/link/executable, it will not run.
Symbolic links on Linux running a 2.6 kernel: On Linux platforms that are
running with a 2.6 kernel, some ACLs cannot be enforced when they are applied to
a symbolic link. Specifically, if any of the following ACLS are applied to a symbolic
link, access will not be denied:
v o (chown)
v p (chmod)
v U (utime)
v w (write)
v D (chdir)
v l (directory list)
If the target does not have ACLs applied or has an ACL that is not set to deny one
of these specific ACLs, the associated action will not be denied.
The following ACLs on symbolic links are enforced correctly, because they act on
the symbolic link, not the target:
v N (create)
v R (rename)
v d (delete)
The following ACLs on symbolic links are enforced correctly, as per the previous
regular examples:
v r (read)
v x (execute)
The r (read) ACL also has the result of not allowing the target of the symbolic link
to be determined.
32 Administration Guide
To work around this situation and protect the target resource, apply the policy to
the target as well. Alternatively, ensure that the r (read) ACL is set in addition to
any of the special ACLs previously listed. When read actions are denied, the target
cannot be determined. Therefore, the other action cannot occur.
Examples of symbolic link aliases: The following are examples of the effect of
the policy on symbolic links.
Example 1
Assume that you have the file /usr/bin/vi with an ACL attached to it. The
file /usr/local/bin/vi is a symbolic link to /usr/bin/vi. When a user
attempts to run vi by either name an authorization decision is made using
the ACL attached to /usr/bin/vi. If, instead, the ACL was attached to
/usr/local/bin/vi, it would still protect vi no matter which of the names
was used to access it. The protected object would be /usr/local/bin/vi.
If an ACL were attached to both /usr/bin/vi and /usr/local/bin/vi then
accesses using the name /usr/bin/vi are protected by the ACL attached to
/usr/bin/vi. Accesses via the name /usr/local/bin/vi are protected by
both ACLs.
Example 2
Suppose /home/joe/data is a file with no access controls applied.
/home/joe/data.link is a symbolic link to /home/joe/data with an ACL
attached. /tmp/data/joe_data is a symbolic link to /home/joe/data also
with an ACL attached.
The following conditions affect the access to this resource.
v If the file is accessed directly using the name /home/joe/data, both ACLs
must be passed before access is granted.
v If the file is accessed using either of the symbolic links, then both ACLs
will also apply.
v If an ACL were to be attached directly to /home/joe/data, then when the
file is accessed directly as /home/joe/data, only this ACL would apply.
v If the file is accessed by either of the symbolic links, then this ACL, plus
the ACL on the two symbolic links, would apply.
v If the symbolic link is to a directory name rather than a file name, the
same rules described above for files apply in this case as well with the
resulting policy being inherited by the contents of the target directory.
Example 3
The next case to consider is when either the target resource or the symbolic
link is protected by inherited access controls rather than having access
controls applied directly. When a symbolic link has no access control
directly applied to it, the target of the symbolic link is protected only by
access controls that the symbolic link inherits when the target is accessed
via the symbolic link. When the target of a symbolic link has no access
control directly applied to it, access controls inherited by the target are
always applied whether the target is accessed directly or via the symbolic
link.
Suppose that /home/joe/data is a file with ACL attached directly to it and
that /tmp/data/joe_data is a symbolic link to /home/joe/data also with an
ACL attached at /tmp/data.
v When the file is accessed directly, only the ACL attached directly is
applied.
Chapter 2. Policy 33
v When the file is accessed with the name /tmp/data/joe_data both ACLs
are applied.
Example 4
Suppose that /home/joe/data is a file this time with an ACL attached only
at /home and that /tmp/data/joe_data is a symbolic link to /home/joe/data
this time with an ACL attached directly to /tmp/data/joe_data.
In this case, both ACLs are applied when the file is accessed by either
name.
Propagating access controls through symbolic links allows
platform-independent policies to be established more easily, particularly in
cases where file layouts differ only by which name for a resource is the
real file and which is the symbolic link. Even so, care must be taken to
understand the effects of applying Tivoli Access Manager for Operating
Systems authorization to a system to ensure that the enforcement of the
policy you define is as you intend.
When a symbolic link is created or deleted, the only access controls that
apply are those that apply directly to the symbolic link or that the
symbolic link inherits.
Hard links
You can define hard links to create multiple directory entries for a file. Each of
these directory entries must reside in the same file system. Accesses to files system
resources that have multiple hard links are controlled similarly to resources with
symbolic links. However, after hard links are created, there is no one hard link that
can be considered the target or real resource. The following rules summarize the
behavior:
v When accessing a hard link that has access controls directly applied, only those
access controls are applied.
v When accessing a resource that does not have any access controls applied, but
has other hard links that do have access controls directly applied, all of the other
access controls must be passed to gain access to the resource.
v Only if no hard links of the resource have access controls directly applied will
access controls inherited by the accessed resource be applied.
Examples of hard link aliases: The following are examples of the effect of a
policy on hard links.
Example 1
Assume that /home/joe/data is a file with an ACL attached directly to it
and that /home/data/joe_data is a hard link to /home/joe/data with no
ACL attached to /home/data
Accesses to /home/joe/data are subject only to the ACL attached directly to
/home/joe/data.
Accesses to /home/data/joe_data are also subject only to the ACL attached
directly to /home/joe/data.
Example 2
Assume that /home/joe/data is a file with no ACL attached to it and that
/home/data/joe_data.1 and /home/data/joe_data.2 are both hard links to
/home/joe/data each with their own ACL attached.
Accesses to /home/joe/data are subject to both ACLs.
34 Administration Guide
Accesses to either /home/data/joe_data.1 or /home/data/joe_data.2 are
each subject only to the ACL directly applied to them.
Because different hard links to a file can have different UNIX file
permissions, Tivoli Access Manager for Operating Systems controls the
creation of a new hard link in a special way. When creating a new hard
link the user needs the following permissions:
N Create permission on the name of the new hard link.
R Rename permission on the target of the new hard link.
r Read permission on the target of the new hard link.
w Write permission on the target of the new hard link.
When a hard link is deleted, only those access controls that apply to that
hard link are enforced.
Device files
Device files represent an underlying resource of the system, for example, a printer
or a disk device. You can create a device file that represents the same device as an
existing device file. The creation of new alias files should not be used to bypass
access controls that are applied to a device. The same rules that apply to hard links
apply to device files.
v When accessing a device file that has access controls directly applied, only those
access controls are applied.
v When accessing a device file that does not have any access controls applied, and
there are other device files representing the same device that do have access
controls directly applied, all of the other access controls must be passed to gain
access to the resource.
v Only if no device files representing the device have access controls directly
applied will access controls inherited by the accessed resource be applied.
Files accessed from NFS clients
Tivoli Access Manager for Operating Systems policy can be placed on file system
resources that are accessed by NFS clients. The access controls are defined based
on the path that the NFS client would use to access the file.
For instance, assume that there is a directory on an NFS server called
/usr/shared/hrtools/bin that is available to NFS clients through a mount point of
/usr/tools/bin. Access controls can be applied to the file resource
/usr/tools/bin/payroll to restrict access to the payroll executable file by the NFS
clients. This policy would be applied to any file with an identical access path on
any Tivoli Access Manager for Operating Systems system, whether it is an NFS
mount point or not. However, these access controls would not apply to the direct
access of the file on the NFS server itself. Similarly, access controls on the NFS
server path of /usr/shared/hrtools/bin/payroll would have no effect on the NFS
clients accessing the file through the NFS mount.
Because NFS is a stateless file access protocol, operations performed from one NFS
client might not be immediately visible at other NFS clients accessing the same file
system resources. As a result, a Tivoli Access Manager for Operating Systems
policy might not be immediately enforced on an NFS client when the file is
created, deleted, or renamed by another NFS client or on the NFS server itself. For
this reason, it is recommended that access controls on file resources accessed
through NFS client-mounted paths be placed only on files that already exist and
Chapter 2. Policy 35
that are infrequently deleted or renamed. Directories and read-only files, such as
executable files, are good candidates for such access controls.
Trusted Computing Base resources
Tivoli Access Manager for Operating Systems provides the ability to define files on
a system as being part of a trusted computing base. Files that are members of the
trusted computing base are monitored for changes in ownership, UNIX file
permissions, creation and modification timestamps, presence or absence on a
system, content of the file, and the device on which the file resides. These
attributes are collectively referred to as the file’s signature.
Tivoli Access Manager for Operating Systems lets you grant special privileges to
programs by defining them in the Trusted Computing Base (TCB). If the integrity
of a program defined in the Trusted Computing Base is compromised, it should no
longer be trusted with special privileges. Tivoli Access Manager for Operating
Systems detects changes that comprise the integrity of a registered program. When
a change is detected, Tivoli Access Manager for Operating Systems records that the
program is untrusted and does not allow an untrusted program to be executed
until an administrator uses the pdosobjsig command to retrust it.
Special privileges are granted to programs by defining them in one of the
following classes of TCB resources:
v Secure-Files
v Secure-Programs
v Login-Programs
v Impersonator-Programs
v Immune-Programs
v Immune-Surrogate-Programs
A file might be classified as more than one type of Trusted Computing Base
resource. The special privileges conveyed by these categories are detailed below.
Files are created in the Trusted Computing Base by explicitly creating a Tivoli
Access Manager policy object of the appropriate name. Tivoli Access Manager for
Operating Systems enforces no authorization policy based on access controls
applied on or beneath the /OSSEAL/policy-branch/TCB resource tree. Access
controls are applied to files that are members of the Trusted Computing Base by
attaching access controls to objects in the File resource tree. For example, to add
the file /etc/hosts.equiv as a Secure-File while permitting access only to the root
user, use the following pdadmin commands:
1. Add hosts.equiv to the TCB:
pdadmin> object create /OSSEAL/Workstations/TCB/Secure-Files/etc/hosts.equiv \
"Host equivalents" 0 ispolicyattachable yes
2. Allow only the root user to access hosts.equiv
pdadmin> acl create hosts-equiv
pdadmin> acl modify hosts-equiv set user root T[OSSEAL]NRUdoprw
pdadmin> object create /OSSEAL/Workstations/File/etc/hosts.equiv \
"hosts equiv file" 3 ispolicyattachable yes
pdadmin> acl attach /OSSEAL/Workstations/File/etc/hosts.equiv hosts-equiv
Programs listed in any Access-Restrictions attribute entries with a rule type of
permit or with no rule type specified are trusted to access the resource protected
36 Administration Guide
by the ACL. These programs are, therefore, included in the Trusted Computing
Base, whether or not they are explicitly defined as Trusted Computing Base
resources.
All files in the Trusted Computing Base, regardless of the class they are specified
in, are monitored for change. When a change is detected, the file becomes
untrusted. The trust state of a file is recorded on a per-system basis. Access to
untrusted files, in addition to any access controls applied to the file as a File
resource, is further controlled as follows:
v When a file is initially added to the Trusted Computing Base by issuing the
appropriate object create command in pdadmin, it is marked as trusted and its
initial signature is recorded.
v An administrative audit event is generated when the file’s signature is detected
to have changed.
v An untrusted file cannot be executed, regardless of any access controls.
v Other accesses permitted by access controls, to an untrusted file (such as read),
generate an administrative audit event.
v If a file is recorded as a Trusted Computing Base file but does not exist on a
system, that file is immediately untrusted on that system if it is created.
v If a file is recorded as a Trusted Computing Base file and is deleted, that file is
marked untrusted and remains untrusted if recreated.
v A file, after it is marked untrusted, can become trusted again only by an explicit
action from the administrator. Use the pdosobjsig command to retrust a file. See
“pdosobjsig” on page 319.
Login-Programs
UNIX systems have no specific action that can be classified as a login. Tivoli
Access Manager for Operating Systems detects a user’s login from the execution of
various Surrogate operations by specific programs. The specific programs are
defined by their membership in the Login-Programs class of Trusted Computing
Base files. Only certain programs have been certified to work as Login-Programs in
the Tivoli Access Manager for Operating Systems environment. These are the
programs that are involved in UNIX logins from locally attached terminals,
graphical desktop environments, and common network protocols (FTP, RLOGIN,
Telnet, REXEC, RSH, SSH).
Other programs might work and can be added to the Login-Programs class, but
only the programs, as distributed by the operating system vendor, listed in Table 11
on page 38 have been certified to perform logins in a manner that can be detected
by Tivoli Access Manager for Operating Systems. None of the programs defined as
Login-Programs by default should be removed from the set unless the
corresponding files are removed from the systems being protected by Tivoli Access
Manager for Operating Systems. Doing so can compromise system security.
Chapter 2. Policy 37
Table 11. Login programs certified for Tivoli Access Manager for Operating Systems
Platform Login programs
AIX /usr/dt/bin/dtlogin
/usr/sbin/ftpd
/usr/sbin/getty
/usr/sbin/login
/usr/sbin/rexecd
/usr/sbin/rlogind
/usr/sbin/rshd
/usr/sbin/sshd
/usr/sbin/telnetd
/usr/sbin/tsm
HP-UX /opt/ssh/sbin/sshd
/usr/bin/login
/usr/bin/tsm
/usr/dt/bin/dtlogin
/usr/lbin/ftpd
/usr/lbin/remshd
/usr/lbin/rexecd
/usr/lbin/rlogind
/usr/lbin/telnetd
/usr/sbin/getty
/usr/sbin/tsm
Solaris /usr/bin/login
/usr/dt/bin/dtlogin
/usr/lib/saf/ttymon
/usr/lib/ssh/sshd (Solaris)
/usr/local/sbin/sshd (freeware)
/usr/sbin/in.ftpd
/usr/sbin/in.rexecd
/usr/sbin/in.rlogind
/usr/sbin/in.rshd
/usr/sbin/in.telnetd
Linux /bin/login
/opt/gnome/bin/gdm
/opt/gnome2/bin/gdm
/opt/kde2/bin/kdm
/opt/kde3/bin/kdm
/sbin/getty
/sbin/mingetty
/usr/bin/gdm
/usr/bin/gdm-binary
/usr/bin/gdmlogin
/usr/bin/kdm
/usr/sbin/in.ftpd
/usr/sbin/in.rexecd
/usr/sbin/in.rlogind
/usr/sbin/in.rshd
/usr/sbin/in.telnetd
/usr/sbin/in.tftpd
/usr/sbin/in.wuftpd
/usr/sbin/pure-ftpd
/usr/sbin/sshd
/usr/sbin/vsftpd
/usr/sbin/wu.ftpd
/usr/X11R6/bin/xdm
38 Administration Guide
If the actual location of sshd is not one of the paths listed in Table 11 on page 38
and the administrator wants to support sshd as an Tivoli Access Manager for
Operating Systems login program, the administrator must perform one of the
following tasks:
v Create a link from one of the expected paths to the actual path of sshd and
retrust sshd using pdosobjsig command:
# ln -sf /expected_path/sshd /actual_path/sshd
# pdosobjsig -u /expected_path/sshd -s trusted
v Define a new login program resource with the correct actual path to sshd using
the pdadmin utility to create the resource in the OSSEAL object space:
# pdadmin -a sec_master -p password
# pdadmin sec_master> object create \
/OSSEAL/policy-branch/TCB/Login-Programs/actual_path/sshd \
"sshd-daemon" 2 i yes
On platforms that support PAM (Pluggable Authentication Modules), which
include Linux, Solaris, and HP-UX, the sshd daemon must also have been
compiled with support for PAM. This support can be checked by running the ldd
command against the sshd executable and checking that it links with the libpam
shared library.
Support of sshd as a login program requires that Tivoli Access Manager for
Operating Systems login policy be configured. You can determine the current
configuration by checking the pdosd.conf configuration file. If login policy
enforcement is off, you can enable it by using pdoscfg:
# grep "login login-policy = off" /opt/pdos/etc/pdosd.conf
# pdoscfg -login_policy on
Secure-Files
Secure files are granted no special privileges. They are simply monitored for
changes in their signature. Tivoli Access Manager for Operating Systems defines
some Tivoli Access Manager for Operating Systems files as Secure-Files when
initially configured.
Only the /opt/pdos/etc/pdoslrd.dtd Tivoli Access Manager for Operating Systems
file is defined as a secure file.
Secure-Programs
Many UNIX programs require UNIX privileges that are different from the UNIX
permissions of the users who can run them. Such programs are marked with the
set user ID or set group ID permissions and might include commands such as su,
mail, or telnet. Without any special action, the change of UNIX identity that occurs
when such programs are executed would require the invoking user to have the
Tivoli Access Manager for Operating Systems authority to Surrogate to the target
user and group indicated by the ownership attributes of the program. For example,
on systems where the mail program is set UID root, every user should probably be
able to run the mail program. However, every user should likely not be authorized
to Surrogate to root. See “Surrogate policy” on page 62 for more information.
Programs defined in the Secure-Programs class of Trusted Computing Base files are
treated as exempt from the Surrogate policy when the initial UNIX identity
changes are performed as the program is executed. If, while the program is
executing, it changes UNIX user or group identity again, this subsequent change is
subject to the Surrogate policy. Subsequent surrogate operations performed by the
program after the initial UNIX identity changes are subject to the Surrogate
Chapter 2. Policy 39
authorization policy. A Tivoli Access Manager for Operating Systems policy
governing the execute action itself would still be enforced.
The only system program defined as a Secure-Program by Tivoli Access Manager
for Operating Systems when initially configured is the su program. If you want to
establish a restrictive Surrogate policy, you need to determine which set UID and
set GID files you need to add to the Secure-Programs class of TCB files to allow
them to continue to be used by ordinary users who would otherwise be restricted
from performing the required Surrogate operation. The pdosuidprog command
described in“pdosuidprog” on page 345 locates setuid and setgid programs on
your system.
The following Tivoli Access Manager for Operating Systems programs are defined
as Secure-Programs:
v /opt/pdos/bin/pdosdestroy
v /opt/pdos/bin/pdoslpadm
v /opt/pdos/bin/pdoslpinf
v /opt/pdos/bin/pdosrefresh
v /opt/pdos/bin/pdosshowuser
v /opt/pdos/bin/pdossudo
v /opt/pdos/bin/pdosunauth
v /opt/pdos/bin/pdoswhoami
v /opt/pdos/bin/pdoswhois
v /opt/pdos/bin/rc.lpm
v /opt/pdos/sbin/kosserrs
The following system files are defined as Secure-Programs:
v /bin/su
v /usr/bin/su
Immune-Surrogate-Programs
The Immune-Surrogate-Programs class provides the ability to define a program as
being immune to all surrogate policies. Programs registered under this class are
immune to all surrogate policies regardless of whether or not the surrogate
operation was performed at execution time (because the program was a set UID or
set GID program) or during runtime (due to the use of setuid() and setgid()
system calls). A Tivoli Access Manager for Operating Systems policy governing the
execute action itself would still be enforced.
The Immune-Surrogate-Programs class is an extension of the Secure-Programs class
to cover situations where registering a program in the Secure-Programs class is not
sufficient. For example, some set UID root programs perform subsequent surrogate
operations following the initial UNIX identity change done at execution. In an
environment where restrictive Surrogate-to-root policy is established, it might be
desirable to allow an ordinary user to use such a program without the subsequent
surrogate operations being subject to the restrictive Surrogate-to-root policy.
Registering such a program in the Secure-Programs class is not sufficient because
only the initial UNIX identity is exempt from surrogate policy enforcement. No
programs are predefined as Immune-Surrogate-Programs.
Impersonator-Programs
UNIX systems generally provide a mechanism for users to schedule jobs to be run
as batch operations while they are not logged in to the system (for example, cron).
Such programs typically run as the root user and, when performing a task, change
identity to the user who scheduled the task. That change of identity is viewed as a
surrogate operation and without special action would run with the Tivoli Access
40 Administration Guide
Manager for Operating Systems credentials of the root user, not the user
credentials, because surrogate operations do not change the Tivoli Access Manager
for Operating Systems accessor ID of a process.
Program membership in the Impersonator-Programs class of the Trusted
Computing Base instructs Tivoli Access Manager for Operating Systems to change
the accessor ID of a process running the program when the process changes its
effective UNIX user ID. If you have a restrictive Surrogate policy you might need,
for example with cron, to permit root to Surrogate to otherwise restricted users. Do
this by specifying an Access-Restrictions attribute that allows the surrogate
operation only when using the cron utility
The following Impersonator-Programs are defined by Tivoli Access Manager for
Operating Systems when initially configured:
v /usr/sbin/atd
v /usr/sbin/cron
v /usr/sbin/crond
Immune-Programs
A program might be integrated so tightly to a system that if a process running that
program was subject to an authorization policy as enforced by Tivoli Access
Manager for Operating Systems, the system would cease to function. You can mark
such programs as immune from all Tivoli Access Manager for Operating Systems
policies by making them a member of the Immune-Programs class of the Trusted
Computing Base. Execution of immune programs is subject to authorization as for
any other program but when it is running the program is immune to all Tivoli
Access Manager for Operating Systems authorization policy. This immunity
includes auditing; no operations that a running immune program performs are
audited.
A process’s immunity is not inherited by any child programs spawned by that
process. Tivoli Access Manager for Operating Systems defines the system programs
listed in Table 12 as immune in the default policy. They represent system processes
involved in file system operations, user identity mapping, and error logging.
Table 12. System programs defined as Immune-Programs in the default policy
Platform Immune programs
AIX /usr/bin/AIXPowerMgtDaemon
/usr/ccs/bin/shlap
/usr/ccs/bin/shlap64
/usr/lib/errdemon
/usr/lpp/diagnostics/diagd
/usr/sbin/automountd
/usr/sbin/biod
/usr/sbin/nfsd
/usr/sbin/rpc.lockd
/usr/sbin/rpc.statd
/usr/sbin/syncd
/usr/sbin/syslogd
HP-UX /usr/lib/netsvc/fs/autofs/automountd
/usr/lib/netsvc/fs/automount/automount
/usr/sbin/biod
/usr/sbin/nfsd
/usr/sbin/pwgrd
/usr/sbin/rpc.lockd
/usr/sbin/rpc.statd
/usr/sbin/syncer
Chapter 2. Policy 41
Table 12. System programs defined as Immune-Programs in the default policy (continued)
Platform Immune programs
Solaris /usr/lib/autofs/automountd
/usr/lib/nfs/lockd
/usr/lib/nfs/nfsd
/usr/lib/nfs/statd
/usr/sbin/rpcbind
/usr/sbin/syslogd
Linux /sbin/klogd
/sbin/portmap
/sbin/rpc.lockd
/sbin/rpc.statd
/sbin/syslogd
/usr/sbin/apmd
/usr/sbin/automount
/usr/sbin/rpc.quotad
/usr/sbin/rpc.mountd
/usr/sbin/rpc.nfsd
In addition to the system programs listed in Table 12 on page 41, the following
Tivoli Access Manager for Operating Systems programs are defined as
Immune-Programs on all platforms:
v /opt/pdos/bin/pdosauditd
v /opt/pdos/bin/pdosaudview
v /opt/pdos/bin/pdosbkup
v /opt/pdos/bin/pdosbranchcfg
v /opt/pdos/bin/pdoscfg
v /opt/pdos/bin/pdosctl
v /opt/pdos/bin/pdosd
v /opt/pdos/bin/pdosexempt
v /opt/pdos/bin/pdoslpmd
v /opt/pdos/bin/pdosobjsig
v /opt/pdos/bin/pdosrevoke
v /opt/pdos/bin/pdosteccfg
v /opt/pdos/bin/pdostecucfg
v /opt/pdos/bin/pdoswdd
v /opt/pdos/bin/pdoslrd
v /opt/pdos/bin/pdoslrdadm
The following Tivoli Access Manager for Operating Systems kernel files are also
defined as Immune-Programs:
v /opt/pdos/kernel/kossctl
v /opt/pdos/kernel/kossd
v /opt/pdos/sbin/kazntrace
v /opt/pdos/sbin/kossdump.sh
v /opt/pdos/sbin/kosserrs
v /opt/pdos/sbin/kossinfo
v /opt/pdos/sbin/ossdump.sh
Differences among immune, secure, and immune-surrogate
programs
It is important to understand the differences among the Immune-Programs,
Secure-Programs, and Immune-Surrogate-Programs classes:
v Programs defined in the Immune-Programs class are immune from all Tivoli
Access Manager for Operating Systems policy enforcement after they are up and
42 Administration Guide
running. A Tivoli Access Manager for Operating Systems policy governing the
execute action itself would still be performed.
v Programs defined in the Secure-Programs class are treated as exempt from
Surrogate policy enforcement for the initial UNIX identity changes performed as
the program is executed. A Tivoli Access Manager for Operating Systems policy
governing the execute action itself would still be enforced. If such a program
performs subsequent surrogate operations after the program has been executed,
then these operations are subject to the Surrogate authorization policy.
v Programs defined in the Immune-Surrogate-Programs class are treated as exempt
from the Surrogate policy enforcement for the initial UNIX identity change that
happens as the program is executed and any subsequent surrogate operations
after the program is running. A Tivoli Access Manager for Operating Systems
policy governing the execute action itself would still be performed.
Providing all three classes allows for granular control of programs that might
require special privileges to function properly in a highly secure environment.
Deciding which classification is appropriate for any given program requires careful
study of what protected resources the program needs access to while running. For
example, determining if a program needs to be registered in either the
Secure-Programs or Immune-Surrogate-Programs class requires careful study of the
surrogate operations that the program performs and a determination of whether
the target users are protected by a restrictive surrogate policy.
It is possible to classify a program under more than one class. This should be done
carefully, with a full understanding of the program’s behavior. For cases where the
special privileges overlap, registering a program in more than one class is
redundant and unnecessary. For example, registering a program in the
Immune-Surrogate-Programs class provides a superset of the privileges granted to
programs registered in the Secure-Programs class. While it is possible to register
the same program in both of these classes, it is unnecessary.
TCB extended attributes
An administrator might want to allow a file to remain trusted event after its
signature has changed. You can define the extended attributes listed in Table 13 to
specify which elements in the signature to ignore.
Table 13. Available extended attributed for signature elements of TCB resources
Attribute name Description Valid values
Set-CRCMaxFileSize Sets the maximum number
of bytes that are considered
significant in the calculation
of the checksum for the file.
A non-negative integer
Ignore-CRC Do not calculate or include
the CRC sum in any
signature check.
Any
Ignore-CRCExec Do not calculate or include
the CRC sum in signature
checks that occur when a
program is run.
Any
Ignore-Owner Do not include the user
ownership of the file in the
signature check.
Any
Ignore-Group Do not include the group
ownership of the file in the
signature check.
Any
Chapter 2. Policy 43
Table 13. Available extended attributed for signature elements of TCB
resources (continued)
Attribute name Description Valid values
Ignore-Size Do not include the file size
in the signature check.
Any
Ignore-ctime Do not include the file
creation time in the signature
check.
Any
Ignore-mtime Do not include the
last-modified time in the
signature check.
Any
Ignore-mode Do not include the file
permission in the signature
check.
Any
Ignore-inode Do not include the inode of
the file in the signature
check.
Any
Ignore-nlink Do not include the hard links
to the file in the signature
check.
Any
Ignore-rdevno Do not include the device ID
of the file in the signature
check.
Any
Ignore-devno Do not include the device
number of the file in the
signature check.
Any
Ignore-Missing Do not perform a signature
check when the file is not
found.
Any
Ignore–All Do not perform signature
checking.
Any
For extended attributes that support any value, the existence of a value is sufficient
to cause the element to be ignored during the signature check.
For additional information about using TCB extended attributes, see “Managing
the Trusted Computing Base” on page 156.
Network policy
Tivoli Access Manager provides the ability to control access to remote network
services from a local machine and to control access to local network services from
remote locations. These types of network access are controlled separately. To
control access from a local machine, use NetOutgoing objects. To control access to a
local machine from remote location, use NetIncoming objects.
The inheritance of access controls beyond /NetIncoming and /NetOutgoing in the
object space limits the performance of network authorization decisions. You do not
need to place a restrictive ACL at or above these container objects in the object
space. The performance of network authorization decisions can be improved by
limiting the inheritance below these container objects in the object space. To limit
inheritance, use the –net_ACL_limited option to pdoscfg, For more information
about this option, see “pdoscfg” on page 280.
44 Administration Guide
When this limitation is enabled, it is assumed that the access control at these points
in the object space is permissive (as is done with the root of the File object space,
/OSSEAL/policy-branch/File), and that authorization decisions can be made more
efficiently when network resources are accessed.
Naming of network resources
The NetIncoming and NetOutgoing resources are represented in the object space as
follows:
/OSSEAL/policy-branch/NetIncoming/protocol[/service[/host]]
/OSSEAL/policy-branch/NetOutgoing[/host[/protocol[/service]]]
In these resources, the elements have the following meaning:
protocol
A representation of a network protocol name. The only supported protocol
is TCP over IP.
Define this protocol using the case-sensitive string tcp.
service A description of the set of services that are represented by this resource.
For NetIncoming resources, this service represents the service on the local
machine to which an incoming connection are addressed. For NetOutgoing
resources, this service represents the service on the remote machine to
which a connection attempt is being made.
This value is a comma-separated list of ports and port ranges. Ports can be
specified explicitly by number or by name. Port names are mapped to port
numbers according to the mapping defined in the /etc/services file on
the machine where the network policy is being enforced. The special port
range ’*’ is equivalent to the range 1–65535. Only one of ’*’ or ’1-65535’
can be present in your policy.
host A description of the set of hosts represented by this resource. For
NetIncoming resources, this represents remote hosts from which an
incoming connection is attempted. For NetOutgoing resources, this
represents the remote host to which an outgoing connection is being
attempted.
The host specification can be in one of the following formats:
v ipv4_address
v ipv4_address:number_of_bits
v host_name
v ipv6_address
v ipv6_address:ipv6_netmask
where:
ipv4_address
A string that represents the dotted notation of an IP version 4
(IPv4) address. 192.168.1.42 is an example of a valid IPv4 address.
number_of_bits
The number of bits that are considered significant in an IPv4
address. Bits are counted from left to right. 0 indicates that no bits
are significant, and 32 indicates that all bits are significant. If you
do not specify this portion of the host specification, the value
defaults to 32.
Specify a number in the range 0 to 32.
Chapter 2. Policy 45
host_name
A wildcard string that matches the names of the hosts represented
by this resource. This host name is case-sensitive and must be
defined using characters that are valid for the local code set.
ipv6_address
A string that represents a colon-delimited 128-bit IPv6 address. The
IP address must be enclosed in square brackets ([]).
[1080:0:0:0:8:800:200C:417A] is an example of a valid 128-bit
IPv6 address.
ipv6_netmask
A string that represents a colon-delimited 128-bit IPv6 address
netmask. The IP address netmask must be enclosed in square
brackets ([]). [FFFF:0:0:0:FF:F00:F00F:FFFF] is an example of a
valid 128-bit IPv6 address netmask. If you do not specify this
portion of the host specification, the value defaults to
[FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF].
IP addresses in network resource policies
While the policy for an IP address can be specified for both IPv4 and IPv6
addresses, IPv4-specified policy has precedence over IPv6-specified policy when
using IPv4 IP addresses.
IPv6 provides the following ways of embedding IPv4 addresses:
IPv4-compatible addresses
To form an IPv4-compatible IPv6 address, prefix the 32-bit IPv4 address
with 96 bits of 0. Assuming that 128.128.128.128 is the IPv4 address, you
can represent this address in one of the following ways:
v 0000:0000:0000:0000:0000:0000:0000:128.128.128.128
v 0:0:0:0:0:0:0:128.128.128.128
v ::128.128.128.128
IPv4-mapped addresses
To form an IPv4-mapped IPv6 address, prefix the 32-bit IPv4 address with
80 bits of 0 followed by 16 bits of 1. Assuming that 128.128.128.128 is the
IPv4 address, you can represent this address in one of the following ways:
v 0000:0000:0000:0000:0000:0000:FFFF:128.128.128.128
v 0:0:0:0:0:0:FFFF:128.128.128.128
v ::FFFF:128.128.128.128
If an IPv6 address is one of the previous formats, that address is treated as an IPv4
address and IPv4-specified address policy would be applied with precedence over
IPv6-specified address policy. Assume that the following NetOutgoing policy rules
were created:
/OSSEAL/Default/NetOutgoing/128.128.128.128
/OSSEAL/Default/NetOutgoing/[0:0:0:0:0:0:0:8888]
/OSSEAL/Default/NetOutgoing/[0:0:0:0:0:0:ffff:8888]
Only the first policy rule, with the IPv4 address specification, would ever apply.
The second and third policy rules, with the IPv6 address specification, would be
lower precedence policy specifications of the same resource and would not apply.
46 Administration Guide
Permissions for network resources
For both NetIncoming and NetOutgoing resources, the only permission that can be
used in ACLs is the Connect (C) permission.
Table 14. Valid permission for NetIncoming and NetOutgoing resources
Permission name Description
Connect (C) Permission to establish an incoming or outgoing connection to a
network resource.
Examples of network resources
/OSSEAL/policy-branch/NetIncoming/protocol[/service[/host]]
/OSSEAL/policy-branch/NetOutgoing[/host[/protocol[/service]]]
The following representation shows a NetIncoming resource in the Default policy
branch that controls access from remote locations for service port 80:
/OSSEAL/Default/NetIncoming/tcp/80
The following representation shows a NetIncoming resource in the Default policy
branch that controls access from hosts in the dev.company.com domain for the
Telnet service (telnet):
/OSSEAL/Default/NetIncoming/tcp/telnet/*.dev.company.com
The following representation shows a NetOutgoing resource in the Default policy
branch that controls access from the local machine to the host defined by the
10.0.151.0 IPv4 address (where the first 23 bits of the address are significant) for
service port 23:
/OSSEAL/Default/NetOutgoing/10.0.151.0:24/tcp/23
The following representation shows a NetOutgoing resource in the Default policy
branch that controls access from the local machine to the host defined by the
10.1.24.12 IPv4 address where all 32 bits of the address are significant:
/OSSEAL/Default/NetOutgoing/10.1.34.12
The following representation shows a NetOutgoing resource in the Default policy
branch that controls access from the local machine to the host defined by the
1080:0:0:0:8:800:200C:417A IPv6 address:
/OSSEAL/Default/NetOutgoing/[1080:0:0:0:8:800:200C:417A]
The following representation shows a NetOutgoing resource in the Default policy
branch that controls access from the local machine to the host defined by the
FF01:BA98:7654:0:8:800:200C:101 IPv6 address and FFFF:FFFF:0:0:0:0:FFFF:FFFF
IPv6 address netmask:
/OSSEAL/Default/NetOutgoing/[FF01:BA98:7654:0:8:800:200C:101]:
[FFFF:FFFF:0:0:0:0:FFFF:FFFF]
Network service and host pattern precedence
When a network access is attempted, Tivoli Access Manager for Operating Systems
must determine which protected object name represents that access. The access
probably matches more than one of the configured object names. For example, the
host name www.ibm.tivoli.com matches both www.*.com and www.*.tivoli.com.
Similarly, the Telnet service (port 23) matches the port range ″23,513″ and the
range ″*″. By matching against the most specific pattern first, Tivoli Access
Manager for Operating Systems lets you first establish a broad policy and then
define exceptions.
Chapter 2. Policy 47
The structure of object names is also important when determining their
precedence. For each of NetIncoming and NetOutgoing, the higher object name
components have higher precedence than the lower components. For example,
with the two objects:
NetOutgoing/www.ibm.tivoli.com/tcp/*
NetOutgoing/www.*.com/tcp/http
An outgoing HTTP connection to www.ibm.tivoli.com is protected by the policy
attached to the first object because the host component of the object name has the
highest precedence.
In the NetIncoming case with the two objects:
NetIncoming/tcp/*/server.ibm.net
NetIncoming/tcp/ftp/*
an incoming FTP request from server.ibm.net to the protected system is
authorized based on the policy applied to the second object name, not the first.
The precedence rules for determining which service pattern is used are the same
for both NetIncoming and NetOutgoing. The precedence rules for determining
which host pattern is used is also the same. “Host pattern precedence” describes
the precise rules.
Service pattern precedence
Service pattern precedence is determined by the following rules:
v Patterns representing a smaller number of distinct ports have higher precedence
than those representing more.
v If two service patterns represent the same number of ports, then the one with
the lowest port number has higher precedence.
v If two service patterns represent exactly the same ports, but are not represented
identically in the object space, then they are considered ambiguous. One of them
will be arbitrarily rejected from the policy, and the pdosd daemon generates
warnings in its error log and administrative audit events warning that the
ambiguous policy was rejected.
Consider the following examples:
v The pattern telnet has higher precedence than 20–25, because telnet represents
just one port while ″20–25″ represents six.
v The pattern 20–25 has higher precedence than 21–26, because although both
patterns represent six ports, 20 is less than 21.
v The pattern 20–25,50–60 has higher precedence than 20–25,60–70, because
although both patterns represent 17 ports, 50 is less than 60.
v The patterns 1–10,23–30 and 1,2,3,4–9,10,telnet,24–30 are ambiguous because
they represent exactly the same set of ports.
Host pattern precedence
Host pattern precedence is determined by the following rules:
v Host patterns specified as IP addresses always have higher precedence than
patterns specified as host names.
v If the same IPv4 address is present twice with one specifying 32 significant bits
and the other assuming the default of 32 significant bits, the policy is considered
ambiguous. One of the objects is arbitrarily rejected and the pdosd daemon
generates warnings in its error log and administrative audit events that indicate
the rejection of the ambiguous policy.
48 Administration Guide
v IPv4 addresses with more significant bits have higher precedence than IPv4
addresses with fewer significant bits.
v IPv4 address specifications of policy have higher precedence than IPv6 address
specifications of IPv4-compatible or IPv4-mapped network resources.
v If the same IPv6 address is present twice with one specifying a address netmask
of FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF and the other assuming the
default of FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, the policy is considered
ambiguous. One of the objects is arbitrarily rejected and the pdosd daemon
generates warnings in its error log and administrative audit events that indicate
the rejection of the ambiguous policy.
v IPv6 addresses with more specific netmask bits (more bits set) have higher
precedence than IPv6 addresses with fewer netmask bits set. If two masks have
the same number of bits set, one of the objects is arbitrarily rejected and the
pdosd daemon generates warnings in its error log and administrative audit
events that indicate the rejection of the ambiguous policy.
v Host patterns specified as possibly wildcard host names have precedence
according to the wildcard element precedence. Host patterns are compared from
end to beginning. For information about wildcard pattern precedence, see
“Wildcards” on page 10.
Consider the following examples:
v The pattern 10.1.2.3:32 has higher precedence than the pattern 10.1.2.3:24.
v The pattern [1080:0:0:0:0:800:200C:417A] has higher precedence than
[1080:0:0:0:0:800:200C:417A]:[FFFF:FFFF:0:0:0:0:FFFF:FFFF], which has
higher precedence than [1080:0:0:0:0:800:200C:417A]:[FFFF:0:0:0:0:0:0:FF].
v If www.ibm.tivoli.com has the IP address 10.1.2.3, the pattern 10.1.2.3:32 has
higher precedence than www.ibm.tivoli.com. This policy is not considered
ambiguous, because the IP address-pattern always has higher precedence.
v If www.ibm.tivoli.com has the IPv6 address 1080:0:0:0:8:800:200C:417A, the
pattern [1080:0:0:0:8:800:200C:417A] has higher precedence than www.ibm.com.
This policy is not considered ambiguous, because the IP address-pattern always
has higher precedence.
v If www.ibm.tivoli.com has IP address 10.1.2.3, the pattern 10.1.0.0:16 has
higher precedence than the pattern www.ibm.tivoli.com. The IP address-pattern
always has higher precedence than host name patterns.
v The pattern www.*.tivoli.com has higher precedence than www.ibm.*.com,
because host name patterns are compared from end to beginning.
Network resource access control
Authorization decisions made when an outgoing network connection is attempted
answer the question, “Is the accessing user allowed to connect to the requested
service on the specified remote host?” Authorization decisions made when an
incoming network connection arrives at a host answer a slightly different question.
Tivoli Access Manager for Operating Systems has no knowledge of the remote user
making the incoming network connection request. The accessor is considered to be
the accessor ID of the process accepting the incoming connection. The question
being answered when making the authorization decision for NetIncoming
resources is:
Is the user allowed to accept incoming connections for the requested service
from a particular remote machine?
Chapter 2. Policy 49
The user that must be given access by any ACL placed on NetIncoming resources,
therefore, is typically the root user because the processes that run on a machine
that accepts incoming connections to system services typically run as the root user.
Application services that are accessible over the network often run as a user other
than the root user. For these services, it is that user who must be granted access by
any ACL that protects the NetIncoming resource.
Login policy
Tivoli Access Manager for Operating Systems lets you control when and from
where a user can log in to a system. The basic mechanisms for controlling user
access are:
v Defining time-of-day login restrictions for users independent of where they log
in from
v Defining access controls on local and remote terminals
Tivoli Access Manager for Operating Systems also provides the ability to enforce
login-activity-related policy such as password expiry, automatically disabling
accounts after a number of failed logins, and automatically disabling inactive
accounts.
Note: When using NIS for remote authentication, Tivoli Access Manager for
Operating Systems can enforce login policy. However for other remote
authentication processes or applications, Tivoli Access Manager for
Operating Systems cannot fully enforce this policy.
Time-of-day login restrictions
Time-of-day login restrictions are defined by specific policy attributes in the Tivoli
Access Manager user registry. They can be specified globally, on a per user basis,
or specifically for unauthenticated users.
Time-of-day restrictions define hours of the day and days of the week during
which users are permitted to log in. For users defined in the Tivoli Access Manager
user registry, any user-specific policy overrides any global policy. For users not
defined in the Tivoli Access Manager user registry, and, therefore, treated as
unauthenticated by Tivoli Access Manager for Operating Systems, the per user
policy associated with the special osseal-unauth user overrides any global policy.
A time-of-day restriction is defined by a string of the following format:
day-range:time-range[:utc|:local]
where:
day-range
Either anyday, weekday, or a comma-separated list of sun, mon, tue, wed, thu,
fri, or sat. The anyday option indicates that the user is permitted to log in
on any day of the week. The weekday option specifies that the user is
permitted to log in on any day except for Saturday and Sunday. A list of
days indicates that the user is permitted to log in only on the specified
days.
time-range
Either anytime or a start time and end time. The anytime option indicates
that the user is permitted to log in at any time on the specified days of the
50 Administration Guide
week. If time is specified in the form start_hhmm-end_hhmm, the start_hhmm
specifies the hour followed by minutes past the hour for the start time, and
the end_hhmm specifies the end time.
utc Specifies that the time-of-day restriction should be applied according to
Universal Coordinated Time (UTC).
local Specifies that the time-of-day restriction should be applied according to the
local time on the system being logged on to. This is the default.
Use the Tivoli Access Manager administration command pdadmin to set
time-of-day restrictions. The following are examples of time-of-day login policy
usage:
v To permit all users to log in only on weekdays from 9:00 A.M. to 5:00 P.M. local
time, while permitting the root user to log in at any time, enter:
pdadmin> policy set tod-access weekday:0900-1700:local
pdadmin> policy set tod-access anyday:anytime -user root
v To additionally constrain unauthenticated users to be allowed to log in only on
Mondays, enter:
pdadmin> policy set tod-access mon:0900-1700:local -user \
osseal-unauth
v To restrict logins regardless of local time zone where the logins take place, enter:
pdadmin> policy set tod-access weekday:0900-1700:utc
pdadmin> policy set tod-access anyday:anytime -user root
pdadmin> policy set tod-access mon:0900-1700:utc -user \
osseal-unauth
Setting holiday login restrictions
You can specify additional time-of-day restrictions by defining Holidays. Holidays
are protected resources that define exceptions to the regular time-of-day restrictions
defined in the user registry. The holiday policy is applied when a user logs in.
You define a holiday by creating an object with the appropriate attributes set on it.
Give the object a name that describes the holiday.
The ability of a user to log in on the holiday is controlled by the ACL attached to
the same resource. The Login (L) permission must be granted to those users
allowed to log in. The format of the value of the Holiday-Dates extended attribute
is a start time followed by an optional space and an end time. The specified time
format follows:
YYYY-MM-DD[-hh[:mm[:ss]]][Z]
Where:
YYYY Year specified as four digits.
MM Month specified as a number from 1 to 12.
DD Day of the month specified as a number from 1 to 31.
hh Hour of the day specified from 0 to 23.
mm Minute of the hour specified from 0 to 59.
ss Second of the minute specified from 0 to 59.
Z Specifies use UTC instead of local time
The following rules apply when interpreting start and end times that are only
partially specified:
Chapter 2. Policy 51
v If no end time is specified, the holiday period ends at midnight of the same day
on which it started.
v Any time component not specified with a start time defaults to zero.
v If an end time is specified with year, month, and day, but no hour, minute, or
second, the holiday period ends at midnight of the day specified.
v If an end time is specified with the hour or the hour and minute, any
unspecified components default to zero.
v If either start time or end time are specified in UTC, then their time stamps are
interpreted as UTC.
Example of holiday login: Assume that there is a three-day holiday around the
CEO’s birthday, January 18. Only system administrators are allowed to work on
January 17, 18, and 19. You could use the following commands to code the Holiday
Restriction:
pdadmin> object create /OSSEAL/Servers/Login/Holidays/CEO-Birthday-Time "Happy" \
0 ispolicyattachble yes
pdadmin> object modify /OSSEAL/Servers/Login/Holidays/CEO-Birthday-Time \
set attribute Holiday-Dates \
"2001-01-17-09:00:00 2001-01-19-17:00:00"
Then create the ACL for the holiday.
pdadmin> acl create ceo-birthday-time-acl
pdadmin> acl modify ceo-birthday-time-acl set group sys-admin \
T[OSSEAL]L
pdadmin> acl attach /OSSEAL/Servers/Login/Holidays/CEO-Birthday-Time \
ceo-birthday-time-acl
This policy permits only members of the Tivoli Access Manager group sys-admin
to log in between 9:00 A.M. January 17, 2001 and 5:00 P.M. on January 19, 2001.
Specifying recurring holidays
You can specify recurring holidays by specifying multiple values for the
Holiday-Dates extended attribute. To define the same CEO birthday policy for the
year 2002, you can add the following command:
pdadmin> object modify /OSSEAL/Servers/Login/Holidays/CEO-Birthday-Time \
set attribute Holiday-Dates "2002-01-17-09:00:00 2002-01-19-17:00:00"
You can also specify holidays that have overlapping ranges. In such cases, the
policy that is applied at any time is determined by the following rules:
v The holiday range with the shortest period, if specified, is observed.
v For holiday ranges with the same period, the holiday range with the earliest
start time is observed.
v Overlapping ranges specified as multiple values are not combined to form one
long range.
To continue the example, if even system administrators were not allowed to log in
on the actual birthday of the CEO, January 18, the following holiday policy could
be defined:
pdadmin> object create/OSSEAL/Servers/Login/Holidays/CEO-Birthday \
"VeryHappy" 0 ispolicyattachable yes
pdadmin> object modify /OSSEAL/Servers/Login/Holidays/CEO-Birthday \
set attribute Holiday-Dates "2001-01-18-09:00:00 2001-01-18-17:00:00"
52 Administration Guide
With the policy for both the CEO-Birthday holiday and the CEO-Birthday-Time
holiday in effect, when a system administrator attempts to log in after 9:00 A.M. on
January 17, the time matches the CEO-Birthday-Time holiday range and the login
is successful.
If the system administrator attempts to log in after 9:00 A.M. on January 18, the
attempt is denied. The shorter time of the CEO-Birthday holiday gives it
precedence and the login is not successful.
If you attempt to define multiple holidays with the identical Holiday-Dates
attributes, the pdosd log file warnings indicate ambiguous policy specifications.
Structure of holiday object names: The structure of the object names beneath the
Holidays resource type specifier is free form. You can structure the definition of
holiday definitions to use the ACL inheritance. If you define holidays to use ACL
inheritance, be aware that the precedence rules carry across all defined holidays
within a policy branch without regard to any user-defined hierarchy. For example,
you can define holidays named as:
/OSSEAL/policy-branch/Login/Holidays/CEO-Birthday/2001
/OSSEAL/policy-branch/Login/Holidays/CEO-Birthday/2002
/OSSEAL/policy-branch/Login/Holidays/CEO-Birthday/2003
with different date ranges specified for each year by attaching separate
Holiday-Dates attributes for each of the leaf nodes. You could then attach a single
ACL to CEO-Birthday.
Login location restrictions
You can specify where users can log in. Define protected resources under the
Terminal branch of the Login resource hierarchy to specify where users can log in.
Login locations are referred to as terminals in this document.
Local and remote terminals: Terminals are either local or remote. Terminals are
local when used for logins to a system from serial devices and graphical consoles.
Terminals are remote when used across a TCP/IP network. You can group both
kinds of terminals together and use inheritance to define access controls. The
names of terminal objects follow the format:
/OSSEAL/policy-branch/Login/Terminal/Local/terminal_group/device
/OSSEAL/policy-branch/Login/Terminal/Remote/terminal_group/host
Where:
terminal_group
A string for an administrator-definable logical grouping of terminals that
allow the application of inherited access controls. This part of the object
name must be included.
device The fully qualified UNIX file name of a terminal device on a system. For
example, /dev/console or /dev/tty/0. This file name cannot include
wildcard characters.
host The representation of a host, group of hosts, or network. One of the
following:
v A fully qualified host name from /etc/hosts, DNS, etc. The name can
include wildcard characters such as the asterisk (*) or the question mark
(?) but must always represent a fully qualified name. A simple, short
name is not allowed.
Chapter 2. Policy 53
v An IP address-netmask combination in dot notation
(IPv4_address:number_of_bits). The netmask (:number_of_bits) is optional.
The absence of a specified netmask implies a 32-bit netmask, that is, a
host address.
v An IPv6 address-address mask combination in standard IPv6 text
representation, enclosed within square brackets ([])
([ipv6_address]:[IPv6_netmask]). The address mask (:[IPv6_netmask]) is
optional. The absence of a specified IPv6 mask implies a 128-bit mask.
The following list contains examples of login resource specifications:
v /OSSEAL/policy-branch/Login/Terminal/Local/Modems/dev/tty063
v /OSSEAL/policy-branch/Login/Terminal/Remote/Development/*.dev.company.com
v /OSSEAL/policy-branch/Login/Terminal/Remote/Xterms/10.1.34.2:24
v /OSSEAL/policy-branch/Login/Terminal/Remote/IPv6Terms/[ABCD:0:0:FEDC:0:0:8813:830A]
Access control on Login objects: Attach Tivoli Access Manager access controls at
the appropriate point in the Login/Terminal object hierarchy to control resources.
For example, you can establish a default policy that controls system access from
remote locations by attaching an ACL or a POP to the /OSSEAL/policy-branch/Terminal/Remote object.
Table 15 shows the permission required.
Table 15. Valid permission to log in
Permission name Description
Login (L) Permission from the associated terminal
Uniqueness of terminal resources definitions: A terminal can appear in only one
terminal group within each policy branch. If a terminal appears in more than one
group, a warning is generated in the pdosd error log. The prevailing policy
authorization is undefined. You might not get the expected results.
Login activity policy
Tivoli Access Manager for Operating Systems provides the ability to define and
enforce the policy that is related to login activity. The policy is defined centrally by
using extended attributes of the /OSSEAL/policy-branch/Login object and controls
the following aspects of login activity:
v Password expiry
v Account suspensions due to failed login attempts
v Account lockouts due to account inactivity
The status of each user account is recorded on a per-machine basis. Accounts
become locked or suspended only on the machine on which they have been active
or on which failed login attempts have occurred. Password expiry times are
maintained on a per-machine basis. The Tivoli Access Manager for Operating
Systems login activity policy is applied in addition to any such policy provided
natively by the operating system. The more restrictive between the Tivoli Access
Manager for Operating Systems policy and the operating system policy will apply.
The use of the $HOME/.rhosts and /etc/hosts.equiv system files should not be
used when the login activity policy is configured. These system files are viewed as
insecure. The behavior of this configuration depends on the platform.
54 Administration Guide
v On AIX systems, these system files circumvent Tivoli Access Manager for
Operating Systems login activity policy with programs that use these files for
authentication (rlogin, rsh, and so forth). Other login policy (such as terminal,
time of day, holiday) is still enforced.
Note: This is a limitation of the AIX platform. The Tivoli Access Manager for
Operating Systems authentication plugin is not invoked when
authentication occurs through $HOME/.rhosts and /etc/hosts.equiv.
v On HP-UX, Linux, and Solaris systems that use the pluggable-authentication-module (PAM), Tivoli Access Manager for Operating Systems correctly enforces
login activity policy, even if the $HOME/.rhosts and /etc/hosts.equiv entries are
used during authentication by programs such as rlogin and rsh. If an account is
suspended or locked due to login activity policy enforcement, subsequent access
will be denied.
There is no integration between the password policy specified in the Tivoli Access
Manager user registry for Tivoli Access Manager users and the password expiry
implemented by Tivoli Access Manager for Operating Systems for native system
accounts. Table 16 describes the extended attributes that control login activity
policy.
Table 16. Login activity policy attributes
Login activity attribute Description Type
Login-MinPasswordDays Minimum amount of time
before a password can be
changed. If not specified, a
default value of zero is used.
A value of zero indicates the
password can be changed as
frequently as a user likes.
Non-negative integer
Login-MaxPasswordDays Maximum amount of time
before a password must be
changed. If not specified, the
default value of zero is
assumed and the passwords
will never be considered to
have expired. After a user’s
password has expired, the
user must change it on the
next login unless grace logins
are enabled. Grace logins are
enabled by setting the
Login-MaxGraceLogins
attribute to a non-zero value.
Non-negative integer
Login-MaxGraceLogins Number of times a user can
login after the user’s
password has expired. If not
specified, a default value of
zero is assumed and the user
is not permitted to login
unless the password is
changed. If the maximum
number of grace logins is
exceeded, the account will be
locked permanently.
Non-negative integer
Chapter 2. Policy 55
Table 16. Login activity policy attributes (continued)
Login activity attribute Description Type
Login-MaxConcurrent Maximum number of
terminals that can be logged
in from concurrently by a
specific user. Multiple logins
from the same terminal
count as a single login. A
terminal is defined as a
remote IP address or the
local host. If a value is set for
the default user, then the
policy is applied to all users
on a system. If not specified,
a default value of zero is
used indicating that there is
no limit to the number of
terminals from which a user
can login.
Non-negative integer
Login-MaxInactiveDays The number of days before
an inactive account is locked
permanently. An account is
considered inactive from the
last time a successful login
occurred to that account. If
not specified, the default
value of zero is assumed and
inactive accounts are never
locked.
Non-negative integer
Login-MaxFailedLogins Number of failed login
attempts on an account
before that account is
suspended. The account is
suspended for a period of
time as determined by the
value of the
Login-LockMinutes attribute.
The period of time over
which the failed login
attempts are counted is
determined by the
Login-LoginMinutes
attribute. If the
Login-MaxFailedLogins
attribute is not specified, the
default value of zero is
assumed and the account
will never be suspended due
to failed login attempts.
Non-negative integer
56 Administration Guide
Table 16. Login activity policy attributes (continued)
Login activity attribute Description Type
Login-LockMinutes The period of time in
minutes to suspend an
account when the maximum
number of failed logins is
reached, as determined by
the Login-MaxFailedLogins
attribute. If the
Login-LockMinutes attribute
is not specified, the default
value of zero is assumed
indicating the account will
remain permanently
suspended.
Non-negative integer
Login-LoginMinutes The period of time in
minutes over which failed
login attempts are counted
towards the maximum
number of failed login
attempts as set in the
Login-MaxFailedLogins
attribute. If the
Login-LoginMinutes attribute
is not specified, the default
value of zero is assumed
indicating there is no time
limit. All invalid login
attempts while the account is
not locked or suspended
count towards the maximum
number of failures.
Non-negative integer
Login-PolicyDisabled Used to disable all login
activity policy. If this
attribute is present and the
value is a non-empty string,
then none of the defined
login activity policy is
enforced.
Non-empty string
Examples of login activity policy: The following are examples of setting login
activity policy.
v To set accounts to be locked after 30 days of inactivity, use the following
pdadmin command:
pdadmin> object modify /OSSEAL/Servers/Login \
set attribute Login-MaxInactiveDays 30
v To allow only three failed login attempts in any one hour before suspending an
account for 30 minutes, use the following pdadmin commands:
pdadmin> object modify /OSSEAL/Servers/Login \
set attribute Login-MaxFailedLogins 3
pdadmin> object modify /OSSEAL/Servers/Login \
set attribute Login-LockMinutes 30
pdadmin> object modify /OSSEAL/Servers/Login \
set attribute Login-LoginMinutes 60
Chapter 2. Policy 57
v The login activity policy attributes all use single values. When modifying an
attribute, you must first remove the existing attribute value. For example, to
change the Login-MaxFailedLogins attribute to 5, use the following pdadmin
commands:
pdadmin> object modify /OSSEAL/Servers/Login \
delete attribute Login-MaxFailedLogins
pdadmin> object modify /OSSEAL/Servers/Login \
set attribute Login-MaxFailedLogins 5
Use the pdoslpadm command to determine the state of an account or to unlock it.
See “pdoslpadm” on page 313 for details on performing this task.
User exception policy
The user exception policy allows you to define exceptions to the default login
activity policy for a specific UNIX name. This capability is provided strictly as a
mechanism to define exceptions to the default policy and should not be used to
define login activity policy for a large number of users.
The user exception policy is defined by setting the login activity extended
attributes on the /OSSEAL/policy-branch/Login/UserExceptions/unix_name object.
Only attributes that are explicitly set for this object apply to the user. Any login
activity extended attribute not explicitly set is given a value of zero. These
unspecified attributes do not inherit the value from the default login activity
extended attributes.
The user exception policy cannot be specified as a task from the Tivoli desktop.
Exceptions can only be made using the pdadmin command.
Examples of user exception policy
The following demonstrates how to set user exception login policy for the Default
policy branch.
1. To set the default login activity policy to have user accounts set to inactive after
30 days of inactivity and to override this default policy for user bob to have all
the login policy attributes set to 0 (disabling policy enforcement), use the
following pdadmin commands:
pdadmin> object modify /OSSEAL/Default/Login \
set attribute Login-MaxInactiveDays 30
pdadmin> object create /OSSEAL/Default/Login/UserExceptions/bob "" 2 i yes
2. Extending the previous example, to set the inactive state for bob after 90 days
of inactivity, use the following pdadmin command:
pdadmin> object modify /OSSEAL/Default/Login/UserExceptions/bob \
set attribute Login-MaxInactiveDays 90
3. All the login attribute values use single values, so to reset the inactivity period
for bob in the previous example to 70, use the following pdadmin commands:
pdadmin> object modify /OSSEAL/Default/Login/UserExceptions/bob delete \
attribute Login-MaxInactiveDays
pdadmin> object modify /OSSEAL/Default/Login/UserExceptions/bob set \
attribute Login-MaxInactiveDays 70
Password management policy
Tivoli Access Manager for Operating Systems provides the ability to define and
enforce policy related to password management. Password management prevents
users from specifying weak passwords that are vulnerable to compromise by
methods such as a dictionary attack. The policy is defined centrally by using
extended attributes of the /OSSEAL/policy-branch/Password object and controls the
following aspects of password management activity:
58 Administration Guide
v Password strength
v Password aging
Note: When using NIS for remote authentication, Tivoli Access Manager for
Operating Systems can enforce password policy. However for other remote
authentication processes or applications, Tivoli Access Manager for
Operating Systems cannot fully enforce this policy.
Tivoli Access Manager for Operating Systems password management policy is
applied in addition to any such policy that is provided natively by the operating
system. The more restrictive policy, either the Tivoli Access Manager for Operating
Systems policy or the operating system policy, will be applied. It is possible that
the password will be modified by the native operating system prior to the Tivoli
Access Manager for Operating Systems password enforcement modules seeing the
password. If this happens, the password management policy will be applied to the
modified password. For example, if the operating system truncates the password to
the number of characters it considers significant, the password management policy
is applied to the truncated password.
Note: Tivoli Access Manager for Operating Systems currently limits the maximum
number of significant bytes in a password to 34 bytes.
The status of each user account is recorded on a per-machine basis. Password
history checks only password changes that have occurred locally on the machine.
The system files $HOME/.rhosts and /etc/hosts.equiv should not be used when
password management policy is configured.
There is no integration between the password policy specified in the Tivoli Access
Manager user registry for Tivoli Access Manager users and the password expiry
implemented by Tivoli Access Manager for Operating Systems for native system
accounts. Table 17 describes the extended attributes that control password
management policy.
Note: An administrator is not subject to the MinPasswordDays check when changing
another user’s password. In addition, after an administrator changes the
password for a user, the user can change the password once without the
MinPasswordDays check being enforced.
Table 17. Password management policy attributes
Login activity attribute Description Type
Password-MinPasswordLen Minimum allowed length of
a password. If not specified,
a default value of zero is
used, indicating that there is
no restriction.
Non-negative integer
Password-MinPasswordAlpha
Minimum number of
alphabetic characters
required in a password. If
not specified, a default value
of zero is used, indicating
that there is no restriction.
Non-negative integer
Chapter 2. Policy 59
Table 17. Password management policy attributes (continued)
Login activity attribute Description Type
Password-MinPasswordAlphaNum
Minimum number of
alphanumeric characters
required in a password. If
not specified, a default value
of zero is used, indicating
that there is no restriction.
Non-negative integer
Password-MinPasswordNumeric
Minimum number of
numeric characters required
in a password. If not
specified, a default value of
zero is used, indicating that
there is no restriction.
Non-negative integer
Password-MinPasswordLower
Minimum number of lower
case characters required in a
password. If not specified, a
default value of zero is used,
indicating that there is no
restriction.
Non-negative integer
Password-MinPasswordUpper
Minimum number of upper
case characters required in a
password. If not specified, a
default value of zero is used,
indicating that there is no
restriction.
Non-negative integer
Password-MinPasswordSpecial
Minimum number of special
characters required in a
password. If not specified, a
default value of zero is used,
indicating that there is no
restriction.
Non-negative integer
Password-MinPasswordDays Minimum amount of time
before a password can be
changed. If a not specified, a
default value of zero is used,
indicating that the password
can be changed as frequently
as a user wants.
Non-negative integer
Password-MaxPasswordRepeat
Maximum number of times a
character can be repeated
consecutively in a password.
If not specified, a default
value of zero is used,
indicating that there is no
restriction.
Non-negative integer
Password-PasswordNameCheck
Check that the password is
not contained in and does
not contain the user ID. If
not specified, a default value
of zero is used, indicating
that the user ID can be used
in the password.
0 or 1
60 Administration Guide
Table 17. Password management policy attributes (continued)
Login activity attribute Description Type
Password-PasswordHistory The number of passwords to
store as a history. When a
new password is set, it
cannot be one of these
previous passwords. A
limited number of history
elements will be supported.
The maximum value of the
password history is 10. If not
specified, a default value of
zero is used, indicating that
there is no restriction.
Non-negative integer
Password-PasswordOldPwdCheck
Compares the new password
with the old one and verifies
that the new password is not
contained in and does not
contain the previous
password.
0 or 1
Password-PasswordMaxConsPrev
If set, this value is the
maximum number of
consecutive characters that
can be in common between
the new password and the
old password.
Non-negative integer
Password-PasswordNonNumFirstLast
If set, this attribute checks
that the first and last
characters of the password
are non-numeric.
0 or 1
Examples of password management policy
The following are examples of setting password management policy.
v To deny a password change if the password contained fewer than seven
characters, use the following pdadmin command:
pdadmin> object modify /OSSEAL/Servers/Password \
set attribute Password-MinPasswordLen 7
v To allow no repeated characters in a password, use the following pdadmin
command:
pdadmin> object modify /OSSEAL/Servers/Password \
set attribute Password-MaxPasswordRepeat 1
v The password management policy attributes all use single values. When
modifying an attribute, you must first remove the existing attribute value. For
example, to change the Password-PasswordHistory attribute to 5, use the
following pdadmin commands:
pdadmin> object modify /OSSEAL/Servers/Password \
delete attribute Password-PasswordHistory
pdadmin> object modify /OSSEAL/Servers/Password \
set attribute Password-PasswordHistory 5
Examples of user exception policy
The following demonstrates how to set user exception password policy for the
Default policy-branch. The UNIX user name must be specified in the object name.
1. To set the default password policy to have user password changes denied
because the passwords were fewer than 10 characters long and to override this
Chapter 2. Policy 61
default policy for user bob to have all the password policy attributes set to 0
(disabling policy enforcement), use the following pdadmin commands:
pdadmin> object modify /OSSEAL/Default/Password \
set attribute Password-MinPasswordLen 10
pdadmin> object create /OSSEAL/Default/Password/UserExceptions/bob \
"" 2 i yes
2. Extending the previous example, to set the account for bob to deny passwords
fewer than 5 characters long, you could use the following pdadmin command:
pdadmin> object modify /OSSEAL/Default/Password/UserExceptions/bob \
set attribute Password-MinPasswordLen 5
3. All the login attribute values use single values, so to reset the minimum
password character length for bob in the above example to 8, use the following
pdadmin commands:
pdadmin> object modify /OSSEAL/Default/Password/UserExceptions/bob \
delete attribute Password-MinPasswordLen
pdadmin> object modify /OSSEAL/Default/Password/UserExceptions/bob \
set attribute Password-MinPasswordLen 8
Surrogate policy
Tivoli Access Manager for Operating Systems provides the ability to control
operations that can change the UNIX identity of a process. Such operations are
referred to as surrogate operations and are controlled by resources of type
Surrogate. Surrogate operations can change the user identity or group identity of a
process. Access control of each of these kinds of surrogate operations is established
by applying authorization policy to the User and Group subtypes of the Surrogate
resource type. The object names identify the potential targets of surrogate
operations and control the ability, for example, to surrogate to the root user or the
system group. Surrogate resource names follow the form:
/OSSEAL/policy-branch/Surrogate/User/user-name
/OSSEAL/policy-branch/Surrogate/Group/group-name
Table 18 details the surrogate objects presented above.
Table 18. Surrogate object naming
Object name Description Type
user-name A UNIX user name. Attempts to
change identity to this user are
protected by the access controls
applied to this object.
String representing the UNIX
user name. Numeric user IDs are
not accepted.
group-name A UNIX group name. Attempts to
change identity to this group are
protected by the access controls
applied to this object.
String representing the UNIX
group name. Numeric group IDs
are not accepted.
Example surrogate resources
Some example surrogate resource specifications are given below:
/OSSEAL/Default/Surrogate/User/root
/OSSEAL/Default/Surrogate/User/joe
/OSSEAL/Default/Surrogate/Group/admin
Note: The application of access controls to the /OSSEAL/policy-branch/Surrogate/User, the /OSSEAL/policy-branch/Surrogate/Group objects, or the containing
/OSSEAL/policy-branch/Surrogate object itself allows the definition of
62 Administration Guide
default Surrogate policy. See the “Considerations for establishing surrogate
policy” for warnings about the implications of establishing Surrogate policy
that is restrictive.
No wildcard can be used for Surrogate resources.
The only permission used to control access to Surrogate resources is the Surrogate
(G) permission as shown in Table 19.
Table 19. Surrogate operation permission
Permission Name Description
G Surrogate Permission to perform a user or group surrogate
operation.
Considerations for establishing surrogate policy
Surrogate operations occur in two fundamentally different ways:
v A running program, in the course of its execution, might change user or group
identity.
v A program with either or both of the set user ID or set group ID UNIX file
permissions set will change identity on execution.
The distinction is important. Programs that have the set user ID or set group ID
permission set are generally intended to be run by unprivileged users who need to
perform tasks that temporarily require more privileges than users would normally
have. Such programs are trusted to perform only prescribed operations while
running with this elevated privilege. Typical examples, depending on the platform,
include programs like /usr/bin/mail, /usr/bin/telnet, and /usr/bin/ps.
Assume these programs are all setuid root. If you restrict the ability of general
users to surrogate to root, then they will no longer be able to run these programs.
These programs are trusted to perform a limited set of operations while they are
executing with elevated privilege. Tivoli Access Manager for Operating Systems
lets you define them as part of a Trusted Computing Base so that surrogate
operations performed when a program is executed occur without requiring an
authorization decision.
Programs defined as Secure-Programs under the Trusted Computing Base resource
type are permitted to change their user or group identity on execution without
being subject to Surrogate authorization policy. See“Trusted Computing Base
resources” on page 36. If such a program performs subsequent surrogate
operations after the program has been executed, then these operations are subject
to Surrogate authorization policy.
Consider the /usr/bin/su command. This command lets a user who knows the
password of another user, explicitly change to that user’s identity. UNIX security
requires that only the root user is allowed to change user identity, therefore, the su
command is set up on all UNIX systems as a setuid root program. If the su
command were not made a Secure-Program in the Tivoli Access Manager for
Operating Systems Trusted Computing Base, then even users who are authorized
to surrogate to other non-root users would require the ability to surrogate to root
as well as the user they really want to surrogate to. With the command configured
as a Secure-Program, the only Tivoli Access Manager for Operating Systems
Surrogate authorization policy that is enforced is the one that protects the target
user of su.
Chapter 2. Policy 63
For example, assume user fred is authorized to change identity to the sysop user.
When fred runs the su command, as follows, two surrogate operations occur:
fred$ su sysop
The first is a surrogate operation to root as su is a setuid root program. The
second occurs when fred correctly enters the password for the sysop account and
the su command explicitly changes identity to the sysop user. With the su
command configured as a Secure-Program, fred does not need Tivoli Access
Manager for Operating Systems authority to surrogate to root, only to sysop.
The su command is the only standard UNIX command configured as a
Secure-Program by default. Tivoli Access Manager for Operating Systems provides
the pdosuidprog command to help you locate other setuid and setgid programs
that you might want to add as Secure-Programs if you establish restrictive
Surrogate policy. See “pdosuidprog” on page 345 for details of running this
command.
If you establish restrictive Surrogate policy and add appropriate setuid and setgid
programs as Secure-Programs in the Trusted Computing Base you might find that
users running these programs still require Surrogate authority to users or groups
you did not anticipate. The programs might be performing surrogate operations
after they are executed. If this is the case and you do not wish to provide open
access to these restricted user and group identities, then you can use the
Access-Restrictions attribute to permit users to execute these surrogate operations
only when running particular programs. “Access restrictions” on page 17 explains
how such a policy can be defined.
When a UNIX user successfully executes a surrogate operation, the accessor
identity that applies to Tivoli Access Manager for Operating Systems authorization
decisions does not change. A surrogate operation cannot be used by a user to
change the user’s identity. A second class of Trusted Computing Base programs,
Impersonator-Programs, allows surrogate operations to change the Tivoli Access
Manager for Operating Systems accessor identity as well as the UNIX user identity
of the process. See “Trusted Computing Base resources” on page 36 for more
information about the Impersonator-Programs class of TCB resources
Access Control on Surrogate Resources: The authorization policy associated with
surrogate resources is expressed by attaching Tivoli Access Manager ACLs to the
user name or group name objects. In addition, default surrogate policy for users
and groups can be defined by attaching Tivoli Access Manager ACLs to the User
or Group container objects and employing ACL inheritance. Also, attaching an
ACL to the Surrogate container object imposes default surrogate permissions for all
users and groups (assuming the user and group containers do not have explicitly
attached ACLs). The Tivoli Access Manager traverse (T) permission is also
employed as part of the access control decision. Table 19 on page 63 details the
valid ACL permissions that can be associated with surrogate resources.
Sudo Policy
Sudo resources describe commands that require more stringent access control than
whether or not a particular program can be executed. Sudo commands allow
access control based not only on a command but also on the parameters passed to
that command. You can use Sudo commands to remove the requirement for a user
to become the root user on a system to perform administrative tasks. Sudo does
this by providing the capability to execute a command as a UNIX user other than
that of the invoker.
64 Administration Guide
Sudo resources are identified in the Tivoli Access Manager object space in the
following way:
/OSSEAL/policy-branch/Sudo/sudo-command[/sudo-argclass]
The attributes of the Sudo command are listed in Table 20.
Table 20. Sudo objects
Object name Description Type
sudo-command The name of the Sudo
command. This is the object
with which parameters
describing the actual
program, UNIX user identity,
and password are associated.
You specify this name.
String representing a Sudo
command.
sudo-argclass The name of a class of
command arguments. The
administrator chooses this
name.
String representing a Sudo
argument class.
Define the attributes of a Sudo command by creating an object that identifies the
Sudo command. Set the Sudo command extended attributes on the object to the
appropriate values. Table 21 lists the command attributes.
Table 21. Sudo command attributes
Extended attribute Description Type
Sudo-Command The program to run when
access to the Sudo command
is granted. This parameter
must be specified for Tivoli
Access Manager for
Operating Systems to
consider the Sudo object as
valid. This attribute uses a
single value.
A fully qualified UNIX file
name specifying the
program. The string can be a
simple UNIX file name, such
as /usr/bin/mount, or
contain a fixed set of
arguments, for example,
/usr/bin/rm -i. The
arguments specified must be
separated by a space and
cannot contain any quotation
marks.
Sudo-Target-User The UNIX user name under
which the program specified
by the Sudo-Command is
run. This UNIX user must
exist on every system on
which the Sudo command
needs to run. This attribute is
optional. The default value is
root. This attribute uses a
single value.
A string representing the
name of the UNIX user.
Sudo-Invoker-Password This attribute indicates that
the invoker of the Sudo
command must enter a
password before the
command can be executed.
The default is to not require
the invoker’s password. This
attribute uses a single value.
The value must be a
non-empty string.
Chapter 2. Policy 65
Table 21. Sudo command attributes (continued)
Extended attribute Description Type
Sudo-Target-Password This attribute indicates that
the invoker of the Sudo
command must enter the
password of the target user
specified by the
Sudo-Target-User attribute
before the command can be
executed. The default is to
not require the invoker to
supply the target user’s
password. This attribute uses
a single valued.
The value must be a
non-empty string.
The execute (x) permission is required to execute a Sudo command as shown in
Table 22.
Table 22. Permission required for Sudo
Permission
code
Permission name Permission granted
x Execute Execute the Sudo command
An example of Sudo usage
To define a Sudo command that allows only members of the sys-admin group to
use the /usr/sbin/mount system program and that requires the invoker to enter a
password when running the command, you can use the following pdadmin
commands:
pdadmin> object create /OSSEAL/Servers/Sudo/mount "mount" 2 \
ispolicyattachable yes
pdadmin> object modify /OSSEAL/Servers/Sudo/mount set attribute \
Sudo-Command /usr/sbin/mount
pdadmin> object modify /OSSEAL/Servers/Sudo/mount set attribute \
Sudo-Invoker-Password "required"
pdadmin> acl create sudo-mount
pdadmin> acl modify sudo-mount set group sys-admin T[OSSEAL]x
pdadmin> acl attach /OSSEAL/Servers/Sudo/mount sudo-mount
You can control what arguments might be provided by defining a Sudo argument
class object subordinate to the Sudo command object. Sudo argument class objects
are defined in a similar manner to Sudo command objects by defining extended
attributes of the Sudo argument class object. The extended attribute that is used to
define a Sudo argument class is defined in Table 23.
Table 23. Extended Sudo attributes for fine-grained control
Extended attribute Description Type
Sudo-Arguments A wildcard string used to match
command line arguments. This
attribute is multi-valued allowing
multiple patterns to describe a single
argument class. There is no default
value.
A wildcard string used to
match command line
arguments.
66 Administration Guide
To continue the example, to allow members of the group net-admin to mount NFS
file systems and only members of the group sys-admin to mount local file systems
use the following pdadmin commands in addition to the ones above:
pdadmin> object create /OSSEAL/Servers/Sudo/mount/remote \
"Remote mount argument patterns" 0 ispolicyattachable yes
pdadmin> object modify /OSSEAL/Servers/Sudo/mount/remote set attribute \
Sudo-Arguments "[-]F nfs"
pdadmin> acl create sudo-net-mount
pdadmin> acl modify sudo-net-mount set group net-admin T[OSSEAL]x
pdadmin> acl attach /OSSEAL/Servers/Sudo/mount/remote sudo-net-mount
pdadmin> object create /OSSEAL/Servers/Sudo/mount/local \
"Local mount argument patterns" 0 ispolicyattachable yes
pdadmin> object modify /OSSEAL/Servers/Sudo/mount/local set \
attribute Sudo-Arguments "[-]F *"
pdadmin> acl create sudo-local-mount
pdadmin> acl modify sudo-local-mount set group sys-admin T[OSSEAL]x
pdadmin> acl attach /OSSEAL/Servers/Sudo/mount/local sudo-local-mount
pdadmin> acl modify sudo-mount set group sys-admin ""
The following notes help explain this example:
v When setting an attribute value in pdadmin, the value cannot start with a dash
character. The dash is represented as [–], a character range containing only a
hyphen (-)
v The policy above relies on the precedence of the wildcard patterns. The ’[-]F
nfs’ pattern is more specific than the ’[-]F *’ pattern.
v The sys-admin group entry in the sudo-mount ACL attached to
/OSSEAL/Servers/Sudo/mount was cleared. This prevents users from accessing
the mount Sudo command unless they specify a –F parameter as the first option.
v To accommodate the slightly different syntaxes of the mount command on
different platforms, you can make the wildcard expressions more complex. For
example, mount might expect the –t option instead of the –F option to specify
the file system type, or NFS might be accepted in place of nfs. To accommodate
two cases, the value of the Sudo-Arguments attribute of the /OSSEAL/Servers/Sudo/mount/remote object can be replaced with [-][tF] [Nn][Ff][Ss].
v If the same pattern appears in two different Sudo argument classes of the same
Sudo command, warning messages identifying the ambiguous policy are
generated in the pdosd daemon log file and an administrative audit event is
generated. The messages do not define which, if any, of the ambiguous policies
is applied.
This syntax of UNIX commands can be very complex, allowing specification of
command line options and parameters in any order and combination. This can
make it difficult to define argument patterns that cover all possibilities. By defining
a default behavior that denies access to the Sudo command, the combinations and
order of command-line options can be restricted to a manageable set.
Wildcards in Sudo arguments
The Sudo-Arguments attribute uses Tivoli Access Manager for Operating Systems
wildcards in a manner similar to the other resource types. The basic elements of
the Sudo-Arguments wildcard strings are the same as the other wildcards with the
following exceptions:
v The wildcard asterisk (*) matches a sequence of non-white space characters
rather than a sequence of any characters. The asterisk matches an entire
command line argument rather than the entire command line. For example, the
following pattern matches an arbitrary string as the first argument followed by
the string root as the second argument:
* root
Chapter 2. Policy 67
If the second argument is not root, this pattern does not match.
v A single-space character in the pattern matches any sequence of white-space
characters in the string being matched. The special meaning of the space
character can be escaped with a backslash character (\), in which case it matches
only one space.
v If the Sudo-Arguments attribute has the value ″″, then this matches the empty
string and allows the definition of a pattern that matches when no arguments
are passed to the Sudo command.
v The pattern matches a string even if there are trailing arguments that were not
matched by the pattern, as long as the preceding arguments matched the entire
pattern. For example the pattern:
* root
Matches both of the strings:
show root
add root system
The pdossudo command
Invoke Sudo commands by entering the pdossudo command and specifying the
Sudo command name and any arguments. In “An example of Sudo usage” on
page 66, the mount Sudo command would be invoked as follows:
$ pdossudo mount –F nfs host:/shared/directory /local
The authorization process of a Sudo command proceeds in this order:
1. Determining whether the invoking user has execute permission on the
requested Sudo command, or Sudo argument class if the arguments specified
on the command line match an argument.
2. If they match, the invoking user is prompted for the required passwords, if any.
3. If all required passwords are entered correctly, then the effective UNIX user ID
of the process is changed to that of the target user. This identity change is
subject to Surrogate policy so the invoking user must have authority to
Surrogate to the target user (this Surrogate authority can be restricted by using
an Access-Restrictions attribute to only permit users to Surrogate when
invoking the pdossudo command). Such Surrogate policy should be applied
with care as it will affect all Surrogate authorization decisions.
4. The Sudo command is executed only after all of these operations have
completed successfully with the specified arguments.
You might also want to establish an Access-Restrictions attribute on the program
specified in the Sudo-Command attribute, restricting execution of this program to
the pdossudo command.
The following pdadmin commands show how these Access-Restrictions attributes
might be established:
pdadmin> object create /OSSEAL/Servers/Surrogate/User/root \
"surrogate root" 14 ispolicyattachable yes
pdadmin> acl create root-user
pdadmin> acl modify root-user set any-other T[OSSEAL]G
pdadmin> acl modify root-user set unauthenticated T[OSSEAL]G
pdadmin> acl modify root-user set attribute \
Access-Restrictions any-other:G:/opt/pdos/bin/pdossudo
pdadmin> acl modify root-user set attribute \
Access-Restrictions unauthenticated:G:/opt/pdos/bin/pdossudo
pdadmin> acl attach /OSSEAL/Servers/Surrogate/User/root root-user
pdadmin> object create /OSSEAL/Servers/File/usr/bin/mount \
68 Administration Guide
"mount command" 3 ispolicyattachable yes
pdadmin> acl create mount-program
pdadmin> acl modify mount-program set any-other T[OSSEAL]x
pdadmin> acl modify mount-program set unauthenticated T[OSSEAL]x
pdadmin> acl modify mount-program set attribute \
Access-Restrictions any-other:x:/opt/pdos/bin/pdossudo
pdadmin> acl modify mount-program set attribute \
Access-Restrictions unauthenticated:x:/opt/pdos/bin/pdossudo
pdadmin> acl attach /OSSEAL/Servers/File/usr/bin/mount mount-program
The pdossudo command is the only way to change identity to the root user with
this policy in place and the only way to execute the mount command.
To protect Sudo commands from being tricked when a user sets environment
variables with the privilege of another UNIX user, the environment visible to the
executed Sudo program is tightly controlled. An example of such a trick attempt is
to change the PATH to values that would allow execution of inappropriate
programs. Table 24 shows the environment variables that are stripped from the
user’s environment before the Sudo command is executed:
Table 24. Environment variables stripped by Sudo
Environment variable Notes
PATH The command location path
LD_* All shared library search path environment variables
beginning with LD_
_RLD_* All runtime linker environment variables beginning with
_RLD_
SHLIB_PATH HP-UX only, the shared library search path
LIBPATH AIX only, the shared library search path
IFS The input field separator
ENV Environment file location
BASH_ENV Bash environment file location
KRB_CONF Kerberos 4 configuration file location
KRB5_CONFIG Kerberos 5 configuration file location
LOCALDOMAIN Override for domain name in /etc/resolv.conf
RES_OPTIONS Options for host name resolution
HOSTALIASES Override for location of host alias specification file
Specify the values for these or other environment variables by defining them in the
pdossudo configuration file, /opt/pdos/etc/pdossudo.conf. Environment variables
are specified by defining them in the [environment] stanza of the file (this is the
only stanza in the file). For example, a suitable pdossudo.conf configuration value
for including an application’s commands and shared libraries in the appropriate
search path might be:
[environment]
PATH=/usr/bin:/usr/sbin:/usr/application/bin
LD_LIBRARY_PATH=/usr/lib:/usr/application/lib
When the Sudo command is executed, the PATH and LD_LIBRARY_PATH
environment variables will be set according those specified in the pdossudo.conf
configuration file.
Chapter 2. Policy 69
The pdossudo command also sets environment variables to permit scripts to
identify the invoker of the command. They are defined in Table 25.
Table 25. Environment variables set by Sudo
Environment variable Description
PDOS_SUDO_ACCESSOR_NAME The user name corresponding to the Tivoli
Access Manager accessor ID of the user
invoking the Sudo command.
PDOS_SUDO_ACCESSOR_ID The numeric ID corresponding to the Tivoli
Access Manager accessor ID of the user
invoking the Sudo command.
PDOS_SUDO_INVOKER_NAME The user name corresponding to the UNIX
user that invoked the pdossudo command.
This might differ from the accessor ID if an
identity change occurred after login, for
example, if the user executed the su
command.
PDOS_SUDO_INVOKER_ID The numeric ID corresponding to the UNIX
user that invoked the pdossudo command.
This might differ from the accessor ID if an
identity change occurred after login, for
example, if the user executed the su
command.
Audit resources
This section describes the user-level audit policy resources as they are defined in
the Tivoli Access Manager for Operating Systems environment. It describes how to
set user-level audit policy for authorization decisions and trace.
Audit authorization resources
Tivoli Access Manager for Operating Systems provides the ability to control which
UNIX users or Tivoli Access Manager group members generate audit records for
authorization decisions. A special case is allowed to specify policy for those UNIX
users who are unauthenticated in the Tivoli Access Manager user registry.
User-level audit policy specifies additional audit policy besides that which is
already provided through global auditing or resource level auditing. It also
provides the ability to turn off auditing for specific users or groups.
User-level audit authorization resources are represented in the Tivoli Access
Manager object space by defining an object name with a resource type of
AuditAuth. Attaching an ACL or POP to these resources has no effect. They are
represented as:
/OSSEAL/policy-branch/AuditAuth/Unauth/audit-level
/OSSEAL/policy-branch/AuditAuth/User/user-name/audit-level
/OSSEAL/policy-branch/AuditAuth/Group/group-name/audit-level
Table 26. User-level audit authorization objects
Object name Description Type
user-name A UNIX user name. String representing the UNIX user
name.
group-name A Tivoli Access Manager
group name.
String representing the group in the
Tivoli Access Manager User Registry.
70 Administration Guide
Table 26. User-level audit authorization objects (continued)
Object name Description Type
audit-level The audit level for the
specified user or group.
String value must be one the following:
permit Audit all authorization
decisions that permit access to
a protected resource by this
user.
deny Audit all authorization
decisions that deny access to a
protected resource by this
user.
loginpermit
Audit all login authorization
decisions that permit the login
by the user.
logindeny
Audit all login authorization
decisions that deny the login
by this user.
all Audit all authorization
decisions for this user. (permit,
deny, loginpermit, and
logindeny)
none Do not audit any
authorization decisions for this
user. This overrides all global
audit or resource audit
settings for this user. This also
overrides any other audit-level
specifications that apply to
this user.
There can be more than one resource specification for a user or group. The
following rules apply:
1. User resource definitions always override the Unauth resource definition and
any group resource definitions that apply to the user. If one or more user
resource definitions exist for a specific user, only those definitions apply to that
user. Any group definitions for groups that the user is a member of are
ignored.
2. If a user resource definition specifies a level of none, this overrides any other
entries for the user.
3. If a user is a member of more than one group with group resource definitions,
the policy that is applied will be the union of the group entries.
4. If a user is a member of a group where a resource definition specifies a level of
none, this overrides any other group entries that apply to the user.
Example audit authorization resources
/OSSEAL/Default/AuditAuth/User/root/all
/OSSEAL/Default/AuditAuth/Unauth/all
/OSSEAL/Default/AuditAuth/Group/osseal-admin/permit
/OSSEAL/Default/AuditAuth/Group/[email protected]/permit
/OSSEAL/Default/AuditAuth/Group/osseal-admin/deny
/OSSEAL/Default/AuditAuth/Group/[email protected]/deny
/OSSEAL/Default/AuditAuth/User/admin1/loginpermit
Chapter 2. Policy 71
Examples of audit authorization usage
To set up policy so that all authorization decisions made on behalf of members of
the osseal-admin group are audited for the policy-branch Servers, use the
following pdadmin command:
pdadmin> object create /OSSEAL/Servers/AuditAuth/Group/osseal-admin/all \
"AuditAuth" 11 ispolicyattachable no
To set up policy so that all login decisions made on behalf of the root user are
audited, use the following pdadmin commands:
pdadmin> object create /OSSEAL/Servers/AuditAuth/User/root/loginpermit \
"AuditAuth" 11 ispolicyattachable no
pdadmin> object create /OSSEAL/Servers/AuditAuth/User/root/logindeny \
"AuditAuth" 11 ispolicyattachable no
To set up policy so that all authorization decisions made on behalf of members of
the osseal-admin group, except the root user, are audited, use the following
pdadmin commands:
pdadmin> object create /OSSEAL/Servers/AuditAuth/Group/osseal-admin/all \
"AuditAuth" 11 ispolicyattachable no
pdadmin> object create /OSSEAL/Servers/AuditAuth/User/root/none \
"AuditAuth" 11 ispolicyattachable no
To set up policy so that all authorization decisions that permit access to protected
resources are audited and any authorization decisions that deny access by the root
user are audited, turn on global auditing and use the following pdadmin
command:
pdoscfg –audit_level permit
pdadmin> object create /OSSEAL/Servers/AuditAuth/User/root/deny \
"AuditAuth" 11 ispolicyattachable no
Audit trace resources
Tivoli Access Manager for Operating Systems provides the ability to control which
UNIX users generate trace records. User-level audit trace policy specifies additional
audit policy besides that which is already provided through global auditing. It also
provides the ability to turn off tracing for specific users.
User-level audit trace resources are represented in the Tivoli Access Manager object
space by defining an object name with a resource type of AuditTrace. Attaching an
ACL or POP to these resources has no effect. They are represented as follows:
/OSSEAL/policy-branch/AuditTrace/User/user-name/trace-level
Table 27. User-level audit trace objects
Object name Description Type
user-name A UNIX user name. String representing the UNIX user name.
72 Administration Guide
Table 27. User-level audit trace objects (continued)
Object name Description Type
trace-level The trace level for the
specified user.
String value must be one of the following:
exec Trace all program invocations
initiated by exec() that occur in
processes that descend from a login
event that was detected by Tivoli
Access Manager for Operating
Systems for this user.
exec_l Trace all program invocations
initiated by exec() that occur in
processes that descend from a login
event that was detected by Tivoli
Access Manager for Operating
Systems for this user when the
accessing user’s identity is different
than the user’s effective user identity
(which typically happens when a
user surrogates to another user).
file Traces all accesses to protected files
by this user. Tracing only occurs for
those processes that descend from a
login event that was detected by
Tivoli Access Manager for Operating
Systems.
all Trace all exec, exec_1, and file for
this user.
none Do not trace anything for this user.
This overrides the global audit
setting. This also overrides any other
trace-level specification that applies
to this user.
A maximum of 1024 AuditTrace users are allowed. AuditTrace policy for additional
users will not be enforced.
/OSSEAL/Default/AuditTrace/User/root/exec_l
/OSSEAL/Default/AuditTrace/User/admin1/exec
/OSSEAL/Default/AuditTrace/User/admin2/exec
Example audit trace resources
To set up policy so that trace exec audit records are generated when the accessor
ID is root for the Servers policy branch, use the following pdadmin command:
pdadmin> object create /OSSEAL/Servers/AuditTrace/User/root/exec "AuditTrace" 11 \
ispolicyattachable no
To set up policy to generate trace exec audit records when the accessor ID is root
but the effective ID is something different, use the following pdadmin command:
pdadmin> object create /OSSEAL/Servers/AuditTrace/User/root/exec_l "AuditTrace" 11 \
ispolicyattachable no
To set up policy to generate trace file records when the accessor ID is root, use
the following pdadmin command:
pdadmin> object create /OSSEAL/Servers/AuditTrace/User/root/file "AuditTrace" 11 \
ispolicyattachable no
To set up policy so that trace exec audit records are generated when the accessor
ID is admin1, admin2 or admin3, use the following pdadmin commands:
Chapter 2. Policy 73
pdadmin> object create /OSSEAL/Servers/AuditTrace/User/admin1/exec "AuditTrace" 11 \
ispolicyattachable no
pdadmin> object create /OSSEAL/Servers/AuditTrace/User/admin2/exec "AuditTrace" 11 \
ispolicyattachable no
pdadmin> object create /OSSEAL/Servers/AuditTrace/User/admin3/exec "AuditTrace" 11 \
ispolicyattachable no
Multiple policy branches
Each Tivoli Access Manager for Operating Systems machine is configured to an
initial policy branch during its initial configuration. The initial policy branch is
created and populated with the Tivoli Access Manager for Operating Systems
default policy during the initial configuration, if it does not already exist. The
branch that is specified as the initial branch should never be a branch that was
created by any means other than Tivoli Access Manager for Operating Systems
configuration. Doing so could render the machine inoperable. A Tivoli Access
Manager administrator can add additional policy to the initial policy branch;
however, it is strongly advised that the Tivoli Access Manager for Operating
Systems default policy not be modified. Multiple machines can subscribe to the
same initial policy branch. This allows an administrator to define the policy for a
specific class of machines once and have it apply to all machines that are in that
class. If all machines in that class can use the same policy, then any additional
policy should be added to the initial policy branch. This is a single branch
configuration, which is the easiest type of configuration to understand and
maintain.
In some situations, it might be useful to define additional policy in policy branches
other than the initial policy branch. One situation where this might apply is where
there are multiple classes of machines and the machines of each class are
configured to a class-specific initial policy branch. In addition, there is an
application, A, that runs on all classes of machines. Rather than having to define
the policy for application A in each of the class-specific initial policy branches, the
policy for application A can be defined in its own branch. Then each machine that
runs application A can subscribe to its policy branch in addition to the initial policy
branch to which it is subscribed.
The complexity of understanding the policy that applies to a given machine
increases with each additional branch that is configured. It is recommended that
the number of configured branches be kept to a minimum.
Definition of additional policy branches
A Tivoli Access Manager administrator can create her or his own additional policy
branches. A policy branch is identified by the element of the object name
immediately following the /OSSEAL root. Therefore, each additional policy branch
must be created in the Tivoli Access Manager object space immediately following
the /OSSEAL root. It is recommended that the root of each policy branch be created
as a Tivoli Access Manager object space to simplify future cleanup of the branch.
For example, to create the root of the appA branch, you would issue the following
pdadmin command:
pdadmin> objectspace create /OSSEAL/appA "application A policy" 3
After the policy branch is created, policy can be created within it in the same
manner as in any other policy branch.
If later, the branch is no longer needed, the entire branch can be deleted by issuing
the following pdadmin command:
74 Administration Guide
pdadmin> objectspace delete /OSSEAL/appA
Configuration of additional policy branches
Use the pdosbranchcfg command to configure a machine to additional policy
branches. When additional policy branches are configured, the precedence order of
them is established. The precedence order is necessary to resolve conflicting policy
between branches. In general, it is best to configure the initial branch as having the
highest precedence to ensure that the default policy protecting Tivoli Access
Manager for Operating Systems is enforced. The configured additional branches
and their precedence order can be changed at any time following the initial
configuration; however, the changes will not take effect until the next restart of the
Tivoli Access Manager for Operating Systems daemons.
For example, if the machine is configured to the /OSSEAL/Servers policy branch
during initial configuration and you want to configure it to the /OSSEAL/appA and
the /OSSEAL/appB policy branches, enter the following pdosbranchcfg commands:
pdosbranchcfg -add appA -admin_name admin -admin_pwd passwd
pdosbranchcfg -add appB -pos 2 -admin_name admin -admin_pwd passwd
After these commands have run, the machine is configured to three branches with
policy enforced in the following precedence order:
1. Servers
2. appB
3. appA
The configuration of the branches can be viewed with the following
pdosbranchcfg command:
pdosbranchcfg -list
The following output is the results of the command:
1-Servers, 2-appB, 3-appA
For more information on configuring multiple branches, see “Configuring
additional branches” on page 145 and “pdosbranchcfg” on page 277.
Conflicting policy
When a machine is subscribed to multiple branches, it is possible that conflicting
policy will be defined within those branches. It is strongly recommended that the
definition of conflicting policy between policy branches be avoided.
Each initial policy branch that is created during the initial configuration of a Tivoli
Access Manager for Operating Systems machine contains the same default policy.
It is strongly recommended that each Tivoli Access Manager for Operating Systems
machine subscribe to only one of those initial policy branches to avoid duplicate
policy. For example, assume that the policy space contains two policy branches. All
server machines running application A subscribe to the /OSSEAL/AServers initial
policy branch and all server machines running application B subscribe to the
/OSSEAL/BServers initial policy branch. Both of those policy branches were created
during the initial configuration of a Tivoli Access Manager for Operating Systems
machine, which means that they contain the same initial policy. Additional policy
was added to the /OSSEAL/AServers policy branch to protect application A and to
the /OSSEAL/BServers policy branch to protect application B. Suppose that you
have several machines that you want to run both application A and application B
on. You could configure them to the /OSSEAL/AServers initial policy branch and to
an additional policy branch of /OSSEAL/BServers. This is strongly discouraged
Chapter 2. Policy 75
because it will define a large amount of duplicate policy for those machines. As an
alternative, you could create an additional policy branch that contains the policy
for application A, /OSSEAL/appA, and another additional policy branch that contains
the policy for application B, /OSSEAL/appB. You could then subscribe all machines
to the same initial policy branch, /OSSEAL/Servers, and subscribe each machine to
the additional branches that it requires.
In some instances, conflicting policy might be unavoidable and conflict resolution
is described below. Tivoli Access Manager for Operating Systems constructs the
protected object name for a resource based on the policy in the configured
branches. The protected object name is constructed using the most precise
definition of the resource in the configured policy branches. The most precise
definition of the resource might have an ACL, POP, or authorization rule
(AuthzRule) attached. The same protected object name is used when applying
ACLs, POPs, and AuthzRules. Conflicting policy occurs when the most precise
definition of a resource is the same in more than one policy branch. Tivoli Access
Manager for Operating Systems determines which policy branch to use when
constructing the protected object name based on the precedence of the configured
policy branches.
In some instances, conflicting policy is obvious, while in other cases conflicting
policy occurs due to inheritance. For example, consider a machine configured to
the /OSSEAL/Servers and /OSSEAL/appA policy branches with the following policy
definitions:
v /OSSEAL/Servers/File/etc/passwd with ACL-A attached
v /OSSEAL/appA/File/etc/passwd with ACL-B attached
v /OSSEAL/Servers/File/usr/ccs/bin with ACL-A attached
v /OSSEAL/appA/File/usr/ccs/bin/appA with ACL-B attached
v /OSSEAL/Servers/File/usr/ccs with ACL-A attached
v /OSSEAL/appA/File/usr/ccs with ACL-B attached
There is conflicting policy when the /etc/passwd file is accessed. The most precise
definition of policy in both policy branches is on File/etc/passwd. The policy
(ACL-A or ACL-B) that is actually applied when the /etc/passwd file is accessed
depends on the precedence order of the branches (Servers and appA). If the
Servers policy branch is of highest precedence, then the protected object name will
be /OSSEAL/Servers/File/etc/password and ACL-A will be applied. If the appA
policy branch is of highest precedence, then the protected object name will be
/OSSEAL/appA/File/etc/passwd and ACL-B will be applied.
There is no conflict when the /usr/ccs/bin/appA file is accessed. Because the most
precise definition of policy is on File/usr/ccs/bin/appA in the appA branch, that
policy (ACL-B) will always be applied when accessing the /usr/ccs/bin/appA file
no matter what the precedence order is. In this case, the protected object name will
always be /OSSEAL/appA/File/usr/ccs/bin/appA.
There is conflicting policy (through inheritance) when the /usr/ccs/lib/mylib.a
file is accessed. The most precise definition of policy in both policy branches is on
File/usr/ccs. The policy (ACL-A or ACL-B) that is actually applied when the
/usr/ccs/lib/mylib.a file is accessed depends on the precedence order of the
branches (Servers and appA). If the Servers policy branch is of highest precedence,
then the protected object name will be /OSSEAL/Servers/File/usr/ccs and ACL-A
76 Administration Guide
will be applied. If the appA policy branch is of highest precedence, then the
protected object name will be /OSSEAL/appA/File/usr/ccs and ACL-B will be
applied.
The pdosrespolicy command is provided to help in understanding conflicting
policy and determining which policy will actually be applied to a given resource.
For more information on this command, see “pdosrespolicy” on page 324.
The remainder of this section provides examples of resolution of conflicting policy
for each type of policy resource that is supported by Tivoli Access Manager for
Operating Systems. Note that in these examples, the policy (ACL, POP, or
AuthzRule) that is attached to the most precise definition of a resource is used to
construct the protected object name. That policy and any additional policy that is
inherited because it is attached higher up in the protected object name hierarchy
apply. Because the protected object name includes the policy branch name, any
inherited policy is derived from the policy branch that is included in the protected
object name. For additional information, see “Inheritance and traversal” on page
23.
File policy
Resolution of conflicts in File policy is easy to understand. Consider the following
policy definitions:
v /OSSEAL/Servers/File/opt with ACL-C and AuthzRule-A attached
v /OSSEAL/Servers/File/opt/ccs/bin with ACL-A attached
v /OSSEAL/appA/File/opt with ACL-B attached
v /OSSEAL/appA/File/opt/ccs with POP-A attached
Using these policy definitions, the following tables show the policy that is applied
when accessing several files given different precedence ordering.
Table 28. Applied file policy - precedence order of appA, Servers
System resource name
(Protected object name) ACL POP AuthzRule
/opt/ccs/bin/dbedit
(/OSSEAL/Servers/File/opt/ccs/bin)
ACL-A None AuthzRule-A
/opt/ccs/lib/libmz.a
(/OSSEAL/appA/File/opt/ccs)
ACL-B POP-A None
/opt/db2/bin
(/OSSEAL/appA/File/opt)
ACL-B None None
Table 29. Applied file policy - Precedence order of Servers, appA
System resource name
(Protected object name) ACL POP AuthzRule
/opt/ccs/bin/dbedit
(/OSSEAL/Servers/File/opt/ccs/bin)
ACL-A None AuthzRule-A
/opt/ccs/lib/libmz.a
(/OSSEAL/appA/File/opt/ccs)
ACL-B POP-A None
/opt/db2/bin
(/OSSEAL/Servers/File/opt)
ACL-C None AuthzRule-A
Chapter 2. Policy 77
TCB policy
Trusted Computing Base (TCB) resources do not have any policy (ACLs, POPs, or
AuthzRules) associated with them. However, they might have attached attributes
that restrict the processing that is done during the signature check. The same file
can be defined as both a File resource and a TCB resource. The policy of the File
resource from one policy branch can be applied while the definition of the TCB
resource might come from a different policy branch. Consider the following policy
definitions:
v /OSSEAL/AServers/TCB/Login-Programs/usr/bin/login without access controls
attached
v /OSSEAL/BServers/File/usr/bin/login with ACL-A attached
If the /usr/bin/login file is accessed, ACL-A will be evaluated and the TCB will be
checked for changes in the signature of /usr/bin/login.
Conflicting TCB policy occurs when multiple policy branches define the same
resource name. The branch precedence order determines which TCB resource is
used. Consider the following policy definitions:
v /OSSEAL/AServers/TCB/Login-Programs/usr/bin/login with the Ignore-CRC
attribute applied
v /OSSEAL/BServers/TCB/Login-Programs/usr/bin/login with the Ignore-ctime
attribute applied
If the /OSSEAL/AServers policy branch is of highest precedence, then the first
definition is used and the CRC will be ignored when the signature of the
/usr/bin/login file is checked. If the /OSSEAL/BServers policy branch is of the
highest precedence, then the second definition is used and the ctime will be
ignored when the signature of the /usr/bin/login is checked.
The same file can be defined as more than one type of TCB resource with different
signature-checking attributes attached. The branch precedence order determines
which TCB resource of each TCB resource type is used. The signature-checking
attributes attached to the resulting TCB resources are combined. Consider the
following TCB policy definitions:
v /OSSEAL/AServers/TCB/Login-Programs/usr/bin/login with the Ignore-inode
attribute applied
v /OSSEAL/AServers/TCB/Secure-Programs/usr/bin/login with the Ignore-ctime
attribute applied
v /OSSEAL/BServers/TCB/Login-Programs/usr/bin/login with the Ignore-mtime
attribute applied
v /OSSEAL/BServers/TCB/Immune-Programs/usr/bin/login with the Ignore-Owner
attribute applied
v /OSSEAL/BServers/TCB/Secure-Programs/usr/bin/login with the Ignore-Group
attribute applied
Using these policy definitions, the following table shows the TCB policy that is
applied for the /usr/bin/login file given different precedence ordering.
78 Administration Guide
Table 30. Applied TCB policy
Precedence Protected object names
Applied
attributes
AServers,
BServers
/OSSEAL/AServers/TCB/Login-Programs/usr/bin/login
/OSSEAL/BServers/TCB/Immune-Programs/usr/bin/login
/OSSEAL/AServers/TCB/Secure-Programs/usr/bin/login
Ignore-inode,
Ignore-Owner,
Ignore-ctime
BServers,
AServers
/OSSEAL/BServers/TCB/Login-Programs/usr/bin/login
/OSSEAL/BServers/TCB/Immune-Programs/usr/bin/login
/OSSEAL/BServers/TCB/Secure-Programs/usr/bin/login
Ignore-mtime,
Ignore-Owner,
Ignore-Group
Login Holiday policy
Login Holiday policy follows the rule that the most precise definition of a resource
applies. Remember that the resource is the point of distinction, not the attributes
attached to the resource. Conflicting login holiday policy occurs at the resource
level when multiple policy branches define the same resource name. The branch
precedence order determines which of the duplicate resources is used. The general
rules for determining precedence with the Holiday-Dates attribute of the resources
apply. See “Setting holiday login restrictions” on page 51.
Consider the following Login Holiday policy definitions:
v /OSSEAL/IBM/Login/Holidays/Thanksgiving with the Holiday-Dates attribute set
to "2004-11-25" and with ACL-A attached
v /OSSEAL/Austin/Login/Holidays/Thanksgiving/2004 with the Holiday-Dates
attribute set to "2004-11-25 2004-11-26" and with ACL-B attached
Both of these resources apply regardless of the branch precedence order, because
the resource names are different. If the date is "2004-11-25", ACL-A, which is
attached to /OSSEAL/IBM/Login/Holidays/Thanksgiving, will always be applied,
because the holiday range with the shortest period is applied. If the date is
"2004-11-26", ACL-B, which is attached to /OSSEAL/Austin/Login/Holidays/Thanksgiving/2004, will always be applied, because the holiday range for this
resource is the only one that contains the date.
Consider the following sets of Login Holiday policy definitions:
For the IBM branch
v /OSSEAL/IBM/Login/Holidays with POP-A attached
v /OSSEAL/IBM/Login/Holidays/NewYears with the Holiday-Dates attribute
set to "2004-01-01 and with ACL-A attached
v /OSSEAL/IBM/Login/Holidays/Thanksgiving with the Holiday-Dates
attribute set to "2004-11-25" and with ACL-A attached
v /OSSEAL/IBM/Login/Holidays/Christmas with ACL-A attached
v /OSSEAL/IBM/Login/Holidays/Christmas/2004 with the Holiday-Dates
attribute set to "2004-12-24" but without access controls attached
v /OSSEAL/IBM/Login/Holidays/Christmas/2005 with the Holiday-Dates
attribute set to "2005-12-26" but without access controls attached
For the Austin branch
v /OSSEAL/Austin/Login/Holidays/NewYears with the Holiday-Dates
attribute set to "2004-01-01 2004-01-02" and with ACL-B attached
v /OSSEAL/Austin/Login/Holidays/Thanksgiving/2004 with the
Holiday-Dates attribute set to "2004-11-25 2004-11-26" and with ACL-B
attached
Chapter 2. Policy 79
v /OSSEAL/Austin/Login/Holidays/Christmas with one Holiday-Dates
attribute set to "2004-12-24 2004-12-25", with another Holiday-Dates
attribute set to "2005-12-26", and with ACL-B attached
Using these policy definitions, the following tables show the policy that is applied
when a login occurs on several dates given different precedence ordering.
Table 31. Applied login holiday policy - precedence order of IBM, Austin
Date Applicable policy ACL POP
01/01/2004 /OSSEAL/IBM/Login/Holidays/NewYears
attribute Holiday-Dates "2004-01-01"
ACL-A POP-A
01/02/2004 Not a holiday None None
11/25/2004 /OSSEAL/IBM/Login/Holidays/Thanksgiving
attribute Holiday-Dates "2004-11-25"
ACL-A POP-A
11/26/2004 /OSSEAL/Austin/Login/Holidays/Thanksgiving/2004
attribute Holiday-Dates "2004-11-25 2004-11-26"
ACL-B None
12/24/2004 /OSSEAL/IBM/Login/Holidays/Christmas/2004
attribute Holiday-Dates "2004-12-24"
ACL-A POP-A
12/25/2004 Not a holiday None None
12/26/2005 /OSSEAL/IBM/Login/Holidays/Christmas/2005
attribute Holiday-Dates "2005-12-26"
ACL-A POP-A
Table 32. Applied login holiday policy - precedence order of Austin, IBM
Date Applicable policy ACL POP
01/01/2004 /OSSEAL/Austin/Login/Holidays/NewYears
attribute Holiday-Dates "2004-01-01 2004-01-02"
ACL-B None
01/02/2004 /OSSEAL/Austin/Login/Holidays/NewYears
attribute Holiday-Dates "2004-01-01 2004-01-02"
ACL-B None
11/25/2004 /OSSEAL/IBM/Login/Holidays/Thanksgiving
attribute Holiday-Dates "2004-11-25"
ACL-A POP-A
11/26/2004 /OSSEAL/Austin/Login/Holidays/Thanksgiving/2004
attribute Holiday-Dates "2004-11-25 2004-11-26"
ACL-B None
12/24/2004 /OSSEAL/IBM/Login/Holidays/Christmas/2004
attribute Holiday-Dates "2004-12-24"
ACL-A POP-A
12/25/2004 /OSSEAL/Austin/Login/Holidays/Christmas
attribute Holiday-Dates "2004-12-24 2004-12-25"
attribute Holiday-Dates "2005-12-26"
ACL-B None
Login location policy
When using multiple branches with Login location policy, you must keep in mind
that a terminal can appear in only one terminal group in all configured branches.
Conflicting policy can occur due to duplicate resource definitions. Conflicting
policy can also occur due to a terminal appearing in more than one terminal
group. Consider the following pairs of conflicting Login location policy definitions:
First pair
v /OSSEAL/AServers/Login/Terminal/Local/Modems/dev/tty063 with ACL-A
attached
v /OSSEAL/AServers/Login/Terminal/Local/ttyModems/dev/tty063 with
ACL-B attached
Second pair
80 Administration Guide
v /OSSEAL/AServers/Login/Terminal/Remote/Devel/*.dev.ibm.com with
ACL-A attached
v /OSSEAL/BServers/Login/Terminal/Remote/Dev/*.dev.ibm.com with
ACL-B attached
Third pair
v /OSSEAL/AServers/Login/Terminal/Local/Modems/dev/tty063 with ACL-A
attached
v /OSSEAL/BServers/Login/Terminal/Local/Modems/dev/tty063 with ACL-B
attached
In the first example, both definitions of /dev/tty063 occur within the same policy
branch in two different terminal groups (Modems and ttyModems). This breaks the
rule that the same terminal must appear in only one terminal group. The resulting
policy is undefined.
In the second example, each definition of *.dev.ibm.com occurs in different
terminal groups (Devel and Dev) in two policy branches. Again, this breaks the rule
that the same terminal must appear in only one terminal group. The resulting
policy is undefined.
In the third example, each definition of /dev/tty063 occurs in the same terminal
group (Modems). Because the resource definitions are identical, the policy from the
highest precedence branch is enforced.
Login activity policy
Placing attributes on a Tivoli Access Manager resource sets login activity policy.
Login activity policy follows the rule that the most precise definition of a resource
applies. Remember that the resource is the point of distinction, not the attributes
attached to the resource. Conflicting Login activity policy occurs at the resource
level when multiple policy branches define the same resource name. The branch
precedence order determines which of the duplicate resources is used. Consider the
following login activity policy definitions:
v /OSSEAL/AServers/Login with the Login-MaxGraceLogins attribute set to 5 and
the Login-MaxConcurrent attribute set to 10
v /OSSEAL/AServers/Login/UserExceptions/root with the Login-MaxGraceLogins
attribute set to 2 and the Login-MaxConcurrent attribute set to 4
v /OSSEAL/LoginPolBr/Login with the Login-MaxConcurrent attribute set to 5
v /OSSEAL/LoginPolBr/Login/UserExceptions/root with the Login-MaxConcurrent
attribute set to 2, the Login-MaxFailedLogins attribute set to 3, and the
Login-LockMinutes attribute set to 15
v /OSSEAL/LoginPolBr/Login/UserExceptions/sam with the Login-MaxConcurrent
attribute set to 20
Using these policy definitions, the following tables show the policy that is applied
when a login occurs for several users given different precedence ordering.
Table 33. Applied login activity policy - precedence order of AServers, LoginPolBr
User name Protected object name with attributes
root /OSSEAL/AServers/Login/UserExceptions/root
attribute Login-MaxGraceLogins 2
attribute Login-MaxConcurrent 4
Chapter 2. Policy 81
Table 33. Applied login activity policy - precedence order of AServers,
LoginPolBr (continued)
User name Protected object name with attributes
jonathan /OSSEAL/AServers/Login
attribute Login-MaxGraceLogins 5
attribute Login-MaxConcurrent 10
sam /OSSEAL/LoginPolBr/Login/UserExceptions/sam
attribute Login-MaxConcurrent 20
Table 34. Applied login activity policy - precedence order of LoginPolBr, AServers
User name Protected object name with attributes
root /OSSEAL/LoginPolBr/Login/UserExceptions/root
attribute Login-MaxConcurrent 2
attribute Login-MaxFailedLogins 3
attribute Login-LockMinutes 15
jonathan /OSSEAL/LoginPolBr/Login
attribute Login-MaxConcurrent 5
sam /OSSEAL/LoginPolBr/Login/UserExceptions/sam
attribute Login-MaxConcurrent 20
Password management policy
Placing attributes on a Tivoli Access Manager resource sets password management
policy. Password management policy follows the rule that the most precise
definition of a resource applies. Remember that the resource is the point of
distinction, not the attributes attached to the resource. Conflicting password
management policy occurs at the resource level when multiple policy branches
define the same resource name. The branch precedence order determines which of
the duplicate resources is used. Consider the following password management
policy definitions:
v /OSSEAL/AServers/Password with the Password-MinPasswordLen attribute set to 6
and the Password-MinPasswordNumeric attribute set to 1
v /OSSEAL/AServers/Password/UserExceptions/root with the Password-MinPasswordLen attribute set to 8 and the Password-MinPasswordNumeric attribute
set to 2
v /OSSEAL/PWDPolBr/Password with the Password-MinPasswordLen attribute set to 8,
the Password-MinPasswordNumeric attribute set to 2, and the
Password-MaxPasswordRepeat attribute set to 2
v /OSSEAL/PWDPolBr/Password/UserExceptions/root with the Password-MinPasswordLen attribute set to 8, the Password-MinPasswordNumeric attribute set
to 2, and the Password-MaxPasswordRepeat attribute set to 1
v /OSSEAL/PWDPolBr/Password/UserExceptions/smiley with the
Password-MinPasswordLen attribute set to 6
Using these policy definitions, the following tables show the password policy that
is applied for several users given different precedence ordering.
Table 35. Applied password management policy – precedence order of PWDPolBr, AServers
User name Protected object name with attributes
root /OSSEAL/PWDPolBr/Password/UserExceptions/root
attribute Password-MinPasswordLen 8
attribute Password-MinPasswordNumeric 2
attribute Password-MaxPasswordRepeat 1
82 Administration Guide
Table 35. Applied password management policy – precedence order of PWDPolBr,
AServers (continued)
User name Protected object name with attributes
jonathan /OSSEAL/PWDPolBr/Password
attribute Password-MinPasswordLen 8
attribute Password-MinPasswordNumeric 2
attribute Password-MaxPasswordRepeat 2
smiley /OSSEAL/PWDPolBr/Password/UserExceptions/smiley
attribute Password-MinPasswordLen 6
Table 36. Applied password management policy – precedence order of AServers, PWDPolBr
User name Protected object name with attributes
root /OSSEAL/AServers/Password/UserExceptions/root
attribute Password-MinPasswordLen 8
attribute Password-MinPasswordNumeric 2
jonathan /OSSEAL/AServers/Password
attribute Password-MinPasswordLen 6
attribute Password-MinPasswordNumeric 1
smiley /OSSEAL/PWDPolBr/Password/UserExceptions/smiley
attribute Password-MinPasswordLen 6
Surrogate policy
Conflicting Surrogate policy occurs when the exact same resource definition occurs
within multiple policy branches. Consider the following Surrogate policy
definitions:
v /OSSEAL/AServers/Surrogate with ACL-A and POP-A attached
v /OSSEAL/AServers/Surrogate/User/root with ACL-B attached
v /OSSEAL/AServers/Surrogate/Group/admin with ACL-B attached
v /OSSEAL/BServers/Surrogate/User/root with ACL-C attached
v /OSSEAL/BServers/Surrogate/User/martin with ACL-C attached
v /OSSEAL/BServers/Surrogate/Group/admin with ACL-C attached
Using these policy definitions, the following tables show the Surrogate policy that
is applied for several users given different precedence ordering.
Table 37. Applied surrogate policy – precedence order of AServers, BServers
User or group
(Protected object name) ACL POP
User root
(/OSSEAL/AServers/Surrogate/User/root)
ACL-B POP-A
Group admin
(/OSSEAL/AServers/Surrogate/Group/admin)
ACL-B POP-A
User fred
(/OSSEAL/AServers/Surrogate)
ACL-A POP-A
User martin
(/OSSEAL/BServers/Surrogate/User/martin)
ACL-C None
Chapter 2. Policy 83
Table 38. Applied surrogate policy – precedence order of BServers, AServers
User or group
(Protected object name) ACL POP
User root
(OSSEAL/BServers/Surrogate/User/root)
ACL-C None
Group admin
(/OSSEAL/BServers/Surrogate/Group/admin)
ACL-C None
User fred
(/OSSEAL/AServers/Surrogate)
ACL-A POP-A
User martin
(/OSSEAL/BServers/Surrogate/User/martin)
ACL-C None
Network policy
Conflicting Network policy occurs when the exact same resource definition occurs
within multiple policy branches. Consider the following Network policy
definitions:
For NetIncoming resources
v /OSSEAL/AServers/NetIncoming with ACL-A and POP-A attached
v /OSSEAL/AServers/NetIncoming/tcp/telnet/*.ibm.com with ACL-B
attached
v /OSSEAL/AServers/NetIncoming/tcp/ftp with ACL-B attached
v /OSSEAL/BServers/NetIncoming/tcp/ftp with ACL-C attached
For NetOutgoing resources
v /OSSEAL/AServers/NetOutgoing with ACL-A and POP-A attached
v /OSSEAL/BServers/NetOutgoing with ACL-C and POP-B attached
v /OSSEAL/BServers/NetOutgoing/*.ibm.com with ACL-D attached
v /OSSEAL/BServers/NetOutgoing/*.ibm.com/tcp/telnet with ACL-E
attached
Using these policy definitions, the following tables show the Network policy that is
applied for several network resources given different precedence ordering.
Table 39. Applied network policy - precedence order of AServers, BServers
Service To or From Protected object name ACL POP
telnet From foo.ibm.com /OSSEAL/AServers/NetIncoming/tcp/telnet/*.ibm.com ACL-B POP-A
ftp From star.texas.com /OSSEAL/AServers/NetIncoming/tcp/ftp ACL-B POP-A
telnet To foo.ibm.com /OSSEAL/BServers/NetOutgoing/*.ibm.com/tcp/telnet ACL-E POP-B
telnet To star.texas.com /OSSEAL/AServers/NetOutgoing ACL-A POP-A
ftp To foo.ibm.com /OSSEAL/BServers/NetOutgoing/*.ibm.com ACL-D POP-B
ftp To star.texas.com /OSSEAL/AServers/NetOutgoing ACL-A POP-A
Table 40. Applied network policy - precedence order of BServers, AServers
Service To or From Protected object name ACL POP
telnet From foo.ibm.com /OSSEAL/AServers/NetIncoming/tcp/telnet/*.ibm.com ACL-B POP-A
ftp From star.texas.com /OSSEAL/Bservers/NetIncoming/tcp/ftp ACL-C None
telnet To foo.ibm.com /OSSEAL/BServers/NetOutgoing/*.ibm.com/tcp/telnet ACL-E POP-B
84 Administration Guide
Table 40. Applied network policy - precedence order of BServers, AServers (continued)
Service To or From Protected object name ACL POP
telnet To star.texas.com /OSSEAL/BServers/NetOutgoing ACL-C POP-B
ftp To foo.ibm.com /OSSEAL/BServers/NetOutgoing/*.ibm.com ACL-D POP-B
ftp To star.texas.com /OSSEAL/BServers/NetOutgoing ACL-C POP-B
Sudo policy
Sudo policy follows the rule that the most precise definition of a resource applies.
Conflicting Sudo policy occurs at the sudo-command level when multiple policy
branches define the same resource name for the Sudo command. If multiple policy
branches contain a sudo-command with the same name, the command from the
policy branch of highest precedence will be used. Any extended attribute for the
sudo-command or a subsequent sudo-argclass will be derived from the same
branch in which the command is defined and any attached ACL, POP, or
AuthzRule will only apply if it is also attached to the sudo-command resource in
the same policy branch. Consider the following Sudo policy definitions:
The AServers branch
v /OSSEAL/AServers/Sudo with POP-A attached
v /OSSEAL/AServers/Sudo/delete with the Sudo-Command attribute set to
/bin/rm and with ACL-A attached
v /OSSEAL/AServers/Sudo/delete/dashr with the Sudo-Arguments attribute
set to [-]r and with ACL-B attached
v /OSSEAL/AServers/Sudo/delete/dashf with the Sudo-Arguments attribute
set to [-]f and with ACL-C attached
For the appA branch
v /OSSEAL/appA/Sudo/delete with the Sudo-Command attribute set to
/usr/sbin/del, with the Sudo-Target-User attribute set to john, and with
ACL-D attached
v /OSSEAL/appA/Sudo/delete/restrict with the Sudo-Arguments attribute
set to * and with ACL-E attached
Using these policy definitions, the following tables show the Sudo policy that is
applied for several Sudo commands given different precedence ordering.
Table 41. Applied Sudo policy - precedence order of AServers, appA
Sudo-command
(Protected object name) Applicable attributes ACL POP
delete
(/OSSEAL/AServers/Sudo/delete)
attribute Sudo-Command /bin/rm ACL-A POP-A
delete –r
(/OSSEAL/AServers/Sudo/delete/dashr)
attribute Sudo-Command /bin/rm
attribute Sudo-Arguments [-]r
ACL-B POP-A
delete –f
(/OSSEAL/AServers/Sudo/delete/dashf)
attribute Sudo-Command /bin/rm
attribute Sudo-Arguments [-]f
ACL-C POP-A
delete –r –f
(/OSSEAL/AServers/Sudo/delete/dashr)
attribute Sudo-Command /bin/rm
attribute Sudo-Arguments [-]r
ACL-B POP-A
delete –f –r
(/OSSEAL/AServers/Sudo/delete/dashf)
attribute Sudo-Command /bin/rm
attribute Sudo-Arguments [-]f
ACL-C POP-A
Chapter 2. Policy 85
Table 42. Applied Sudo policy - precedence order of appA, AServers
Sudo-command
(Protected object name) Applicable attributes ACL POP
delete
(/OSSEAL/appA/Sudo/delete)
attribute Sudo-Command /usr/sbin/del
attribute Sudo-Target-User john
ACL-D None
delete –r
(/OSSEAL/appA/Sudo/delete/restrict)
attribute Sudo-Command /usr/sbin/del
attribute Sudo-Target-User john
attribute Sudo-Arguments *
ACL-E None
delete –f
(/OSSEAL/appA/Sudo/delete/restrict)
attribute Sudo-Command /usr/sbin/del
attribute Sudo-Target-User john
attribute Sudo-Arguments *
ACL-E None
delete –r –f
(/OSSEAL/appA/Sudo/delete/restrict)
attribute Sudo-Command /usr/sbin/del
attribute Sudo-Target-User john
attribute Sudo-Arguments *
ACL-E None
delete –f –r
(/OSSEAL/appA/Sudo/delete/restrict)
attribute Sudo-Command /usr/sbin/del
attribute Sudo-Target-User john
attribute Sudo-Arguments *
ACL-E None
Audit resource policy
Audit resource policy conflicts when the same AuditAuth or AuditTrace resource is
defined in multiple policy branches. Remember that a user definition is more
specific than a group definition. A specific user definition in a lower precedence
branch for a user takes precedence over any group definition for that user in a
higher precedence branch.
Remember the general rules for Audit resources:
1. User resource definitions always override the Unauth resource definition and
any Group resource definition. Group and User resource definitions are not
combined.
2. If a User resource definition specifies a level of none, this overrides any other
definition for the user.
3. If a user is a member of more than one group with Group resource definitions,
the policy that is applied will be the union of the group entries.
4. If a user is a member of a group where a resource definition specifies a level of
none, this overrides any other group entry that applies to the user.
Consider the following Audit resource policy definitions:
For the AServers branch
v /OSSEAL/AServers/AuditAuth/Unauth/permit
v /OSSEAL/AServers/AuditAuth/Unauth/deny
v /OSSEAL/AServers/AuditAuth/Group/osseal-admin/permit
v /OSSEAL/AServers/AuditAuth/Group/testers/all
v /OSSEAL/AServers/AuditAuth/User/root/none
For the AudPolBr branch
v /OSSEAL/AudPolBr/AuditAuth/Group/testers/deny
v /OSSEAL/AudPolBr/AuditAuth/User/janani/none
v /OSSEAL/AudPolBr/AuditAuth/User/root/deny
v /OSSEAL/AudPolBr/AuditAuth/User/root/permit
v /OSSEAL/AudPolBr/AuditAuth/User/smiley/all
In combination with the following group memberships:
v The osseal-admin group with members root, osseal, janani, and liz
v The testers group with members martin, connie, and george
86 Administration Guide
v Unauth users smiley and anne
Using these policy definitions, the following tables show the Audit resource policy
that is applied for several users given different precedence ordering.
Table 43. Applied audit resource policy - precedence order of AServers, AudPolBr
User name Policy
root /OSSEAL/AServers/AuditAuth/User/root/none
janani /OSSEAL/AudPolBr/AuditAuth/User/janani/none
liz /OSSEAL/AServers/AuditAuth/Group/osseal-admin/permit
george /OSSEAL/AServers/AuditAuth/Group/testers/all
smiley /OSSEAL/AudPolBr/AuditAuth/User/smiley/all
anne /OSSEAL/AServers/AuditAuth/Unauth/permit
/OSSEAL/AServers/AuditAuth/Unauth/deny
Table 44. Applied audit resource policy - precedence order of AudPolBr, AServers
User name Policy
root /OSSEAL/AudPolBr/AuditAuth/User/root/deny
/OSSEAL/AudPolBr/AuditAuth/User/root/permit
janani /OSSEAL/AudPolBr/AuditAuth/User/janani/none
liz /OSSEAL/AServers/AuditAuth/Group/osseal-admin/permit
george /OSSEAL/AudPolBr/AuditAuth/Group/testers/deny
smiley /OSSEAL/AudPolBr/AuditAuth/User/smiley/all
anne /OSSEAL/AServers/AuditAuth/Unauth/permit
/OSSEAL/AServers/AuditAuth/Unauth/deny
Chapter 2. Policy 87
88 Administration Guide
Chapter 3. Runtime
This chapter describes the major components of Tivoli Access Manager for
Operating Systems clients and their operating environment. These components
include:
v “The pdosd authorization daemon” on page 90
v “The pdosauditd audit daemon” on page 100
v “The pdoswdd watchdog daemon” on page 102
v “The pdostecd Tivoli Enterprise Console daemon” on page 104
v “The pdoslpmd login policy and password management daemon” on page 105
v “The pdoslrd log router daemon” on page 107
The following topics are also described in this chapter:
v “Users and groups” on page 108
v “Files and directories” on page 111
v “Initial policy” on page 114
v “Isolated operation” on page 118
Daemons
The daemons responsible for the major functions of Tivoli Access Manager for
Operating Systems are:
pdosd—The Authorization Daemon
Makes authorization decisions and monitors the Trusted Computing Base.
pdosauditd—The Audit Daemon
Receives audit events from other components of Tivoli Access Manager for
Operating Systems and manages the audit trail.
pdoswdd—The Watchdog Daemon
Ensures that the other daemons remain available. The other daemons also
monitor each other.
pdostecd—The Tivoli Enterprise Console Daemon
Makes many of the Tivoli Access Manager for Operating Systems audit
events available to the Tivoli Enterprise Console.
pdoslpmd—The Login Policy and Password Management Daemon
Makes authorization decisions about logins and password changes.
pdoslrd—The Log Router Daemon
Makes audit records available for transfer to multiple locations.
Each daemon maintains a log file that records significant events and error
conditions. The records written to the log files contain a UTC timestamp,
information identifying the component logging the event, the message
classification, and the message text. By default, the log files are not automatically
archived and are persistent across restarts of Tivoli Access Manager for Operating
Systems.
© Copyright IBM Corp. 2000, 2005 89
You can configure how many log entries can be written to the log file before a new
log is started. You can also configure, for each daemon, how many log files to
maintain before recycling the files.
If log file archive is enabled, when the daemon log file reaches the maximum
number of entries, the log file will be archived by appending a period and an
archive number to it. For instance, when the msg__pdosd.log file is full, it is
renamed msg__pdosd.log.1 and a new msg__pdosd.log file is created. Logging will
continue in the msg_pdosd.log file until it is full at which time it will be renamed
to msg__pdosd.log.2. When the configured number of archive log files is reached,
the archive file names will be recycled and the next time the log file is archived it
will start from one. For example, if the configured number of archives is two, the
next time the msg__pdosd.log file is archived, it will be renamed to
msg__pdosd.log.1. In addition, if log file archive is enabled, each time the daemon
is restarted, the existing log file will be archived to the next archive in the
sequence and a new log file will be created. If the number of archive log files is
zero, but the maximum number of entries is nonzero, the log itself will recycle
when it reaches the maximum number of entries or the daemon is restarted.
When the configured number of files is used, the files are reused in the order in
which they were created. File reuse also occurs when the daemon is stopped and
restarted, if rollover is enabled. When a log file is reused, the existing records are
truncated.
You can set these and other runtime options with the pdoscfg command. The
pdoscfg command modifies the configuration files. These modifications do not
take effect until the next time that Tivoli Access Manager for Operating Systems is
stopped and restarted. You can dynamically change some runtime options while
the Tivoli Access Manager for Operating Systems daemons are running by using
the pdosctl command. Changes made with the pdosctl command take effect
immediately and are not persistent when you restart. For more information, see the
following:
v “pdoscfg” on page 280 lists all the pdoscfg options.
v “Tuning the configuration” on page 146 shows the mapping between the
pdoscfg options and the configuration file attributes described in this chapter.
v “pdosctl” on page 297 lists all the pdosctl options.
The pdosd authorization daemon
The authorization daemon, pdosd, does the following:
v Handles the authorization requests generated by the Tivoli Access Manager for
Operating Systems kernel extension when it intercepts operations that are
subject to a policy
v Maps UNIX user identities to Tivoli Access Manager credentials that describe
users and their group memberships from a Tivoli Access Manager point of view
v Monitors the files that constitute the Trusted Computing Base to detect any
changes that would cause them to become untrusted
Credential acquisition
The credential acquisition service is vital to the pdosd daemon’s authorization
decision process. “The UNIX identity and its relationship to the Tivoli Access
Manager user identity” on page 3 discusses at a high level how a UNIX user’s
identity is used to obtain a Tivoli Access Manager credential required for making
an authorization decision. This section describes the lower-level aspects of this
90 Administration Guide
process. For Tivoli Access Manager to make authorization decisions efficiently and
also to ensure its ability to function in isolation from the Tivoli Access Manager
user registry, credentials are cached by the pdosd daemon as they are used. The
pdosd daemon uses an in-memory cache and a disk cache. All credentials are
represented in the disk cache. Only active users have their credentials available in
the memory cache.
There is one cached credential for each user. Credentials are cached as users log in
to the system. Each time a user logs into the system, Tivoli Access Manager for
Operating Systems retrieves a new credential from the Tivoli Access Manager user
registry and stores it in the credential cache. That user continues to use the cached
credential until a new login operation is detected for that same user. When a new
login operation is detected, Tivoli Access Manager for Operating Systems again
retrieves a new credential from the Tivoli Access Manager user registry and
replaces the cached credential with the new credential.
When the new credential has been cached, any operations performed by that user,
from any of the user’s login shells, use the newly cached credential until it is
replaced or removed from the cache.
Refreshing the credential reflects up any changes in the Tivoli Access Manager user
registry of the user’s group membership. A user’s group membership can change
by being added to groups or by being removed from groups. Changes in group
membership are not reflected until a user’s credential is refreshed.
You can use the pdosrefresh command to force a user’s credential to be refreshed
without waiting for the user to log in again. Any group membership changes are
then reflected immediately.
Each cached credential has a refresh time and a hold time associated with it:
Refresh time
When a credential’s refresh time is reached, the pdosd daemon retrieves a
new credential from the Tivoli Access Manager user registry and replaces
the cached credential with the new credential.
Hold time
When a credential’s hold time is reached, the pdosd daemon removes the
credential from the cache. A new credential is retrieved from the Tivoli
Access Manager user registry the next time it is needed by the pdosd
daemon.
Credential acquisition and user type
Tivoli Access Manager for Operating Systems users are classified as:
v General users
v Administrative users
v Critical system users
Administrative users are defined as all users who are members of the
osseal-admin Tivoli Access Manager group and the osseal UNIX group.
Administrative users have the following attributes in addition to those of general
users:
v Credentials of administrative users are never flushed from the disk cache
v Credentials of administrative users are maintained on a system even for
administrative users that have never logged on
Chapter 3. Runtime 91
v The default decision made by the pdosd daemon when making a decision under
error conditions is to grant access. For general users, the default decision is to
deny.
Critical system users are defined by the system administrator as users who are
critical to system operation. These users are members of the Tivoli Access Manager
group specified by the -critical_cred_group option to the pdoscfg command.
Critical system users have the following attributes in addition to those of general
users:
v Credentials of critical system users are never flushed from the disk cache.
v Credentials of critical system users are maintained on a system even if the users
have never logged on.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
full name of the critical system users group (defined by the -critical_cred_group
option) must be specified. The full group name includes the domain name (for
example, [email protected]). The critical system users group is optional and
does not need to be configured. It does not need to have a corresponding local
UNIX group. The members of the group must have corresponding local UNIX IDs
or they will be ignored.
Table 45 on page 93 lists the configuration attributes pertaining to the Tivoli Access
Manager for Operating Systems Credential Acquisition Service in the
/opt/pdos/etc/pdosd.conf configuration file.
92 Administration Guide
Table 45. Tivoli Access Manager for Operating Systems credential configuration attributes
Stanza Attribute Description
[credentials]
user-cred-refresh The number of minutes that user credentials can
exist in the credential cache before they are
considered due for a refresh. The interval starts
at the time the credential is cached. After the
refresh interval is exceeded, the credential is
refreshed.
admin-cred-refresh The frequency of the refresh of the credentials of
administrative users. This allows admin user
credential refresh periods to be managed
independently from those of the general user. It
is also specified in minutes.
critical-cred-refresh The frequency of the refresh of the credentials of
critical system users. This allows the critical user
credential refresh periods to be managed
independently from those of general users. It is
also specified in minutes.
cred-hold The number of minutes that general user
credentials can remain in the credential cache
beyond the time that they were last accessed.
Credentials of general users that remain cached
beyond this time will be flushed from the cache.
Administrative and critical system credentials are
never flushed from the cache. The cred-hold
interval must be at least as long as the
user-cred-refresh interval.
critical-cred-group The name of the Tivoli Access Manager group
containing all users who are to be treated as
critical system users. This group must be created
and populated by the system administrator.
Credentials for users who are members of this
group are never removed from the cache. System
administrators should use this group to specify
users who are critical to the system and
programs running on it to function properly.
Administrative users (members of the Tivoli
Access Manager osseal-admin group) do not
need to be members of this group.
cred-response-wait The minimum number of minutes that the pdosd
daemon will wait for responses to credential
requests from the Tivoli Access Manager user
registry before entering isolation mode.
If Tivoli Access Manager for Operating Systems cannot communicate with the
Tivoli Access Manager user registry when a credential is due to be refreshed, that
credential remains in the cache until communication with the user registry is
reestablished. During that time the cached credential continues to be used by Tivoli
Access Manager for Operating Systems.
Tivoli Access Manager for Operating Systems and the Tivoli
Access Manager user registry
Tivoli Access Manager for Operating Systems uses the Tivoli Access Manager
Runtime Environment configuration for locating and communicating with the user
registry. This enables Tivoli Access Manager for Operating Systems to share the
user registry configuration with other components of Tivoli Access Manager, for
Chapter 3. Runtime 93
example the location of user registry replicas. See the IBM Tivoli Access Manager:
Administration Guide for details on configuring the Tivoli Access Manager Runtime
Environment. Tivoli Access Manager for Operating Systems supports LDAP and
Active Directory as the Tivoli Access Manager user registry. However if Tivoli
Access Manager is configured to multiple Active Directory domains, Tivoli Access
Manager for Operating Systems must be configured to a single one of those
domains.
Table 46 shows the configuration attributes in the pdosd configuration file,
/opt/pdos/etc/pdosd.conf, that control the daemon’s communications with the
user registry. All non-LDAP user registries use the values in the [uraf] stanza.
These attributes are established during configuration and should not be modified.
Table 46. Configuration attributes that control the pdosd communication with the user
registry
Stanza Attribute Description
[ldap]
ldap-server-config Location of the Tivoli Access Manager runtime LDAP
configuration file.
ssl-enabled Boolean flag indicating whether or not to use SSL
communications with LDAP. This must be set to enable
SSL communications.
bind-dn The distinguished name (DN) that the pdosd daemon
uses to authenticate when accessing the LDAP user
registry. This information is stored in the obfuscated
version of the configuration file.
bind-pwd The password that the pdosd daemon uses to
authenticate when accessing the LDAP user registry. This
information is stored in the obfuscated version of the
configuration file.
[uraf]
uraf-registry-config Location of the Tivoli Access Manager runtime URAF
configuration file.
bind-id The identify that the pdosd daemon uses to authenticate
when accessing the URAF user registry.
bind-pwd The password that the pdosd daemon uses to
authenticate when accessing the URAF user registry. This
information is stored in the obfuscated version of the
configuration file.
Table 47 on page 95 shows the configuration attribute in the OSSEAL configuration
file, /opt/pdos/etc/osseal.conf, that controls the daemon communication with the
user registry. This attribute is established during configuration and should not be
modified.
94 Administration Guide
Table 47. Configuration attributes that control the daemon communication with the user
registry
Stanza Attribute Description
[registry] AD-domain The name of the Active Directory domain. If Tivoli
Access Manager is configured to multiple Active
Directory domains, this value is the name of the
domain that Tivoli Access Manager for Operating
Systems is configured to use. All Tivoli Access
Manager users and groups that are used by Tivoli
Access Manager for Operating Systems are in this
domain. If Tivoli Access Manager is not configured
to multiple Active Directory domains, this attribute
is not set.
Security considerations
The attributes you set affect the security of your system. Be careful when you set
or change the values for these attributes in the configuration files.
The use of SSL to communicate to the user registry server allows for mutual
authentication between the pdosd daemon and the user registry server. The
certificate of the Certification Authority (CA) that signed the user registry server
certificate, provided when Tivoli Access Manager for Operating Systems was
configured, enables the pdosd daemon to verify that the user registry server is the
real user registry server. Because the information provided by the user registry
server is used by the pdosd daemon, through the Tivoli Access Manager runtime,
to construct the user credentials used in making authorization decisions, this
information must be trusted. Authentication of the user registry server by the
pdosd daemon allows this level of trust. See the IBM Tivoli Access Manager for
Operating Systems: Installation Guide.
Note: To locate the sensitive information in obfuscated versions of configuration
files, such as the pdosd daemon locating the value for the bind-pwd
attribute, the non-obfuscated version of the configuration file must point to
its obfuscated version. Using the pdosd daemon configuration file as an
example, the /opt/pdos/etc/pdosd.conf configuration file must contain the
following information that points to the /opt/pdos/etc/pdosd.conf.obf
obfuscated configuration file:
[configuration-database]
file = /opt/pdos/etc/pdosd.conf.obf
Inside of obfuscated configuration files, the attributes are defined in the
same stanzas as the non-obfuscated version.
To protect the Tivoli Access Manager for Operating Systems configuration files, the
default policy established by Tivoli Access Manager for Operating Systems attaches
the osseal-restricted ACL to the /opt/pdos/etc directory that contains all Tivoli
Access Manager for Operating Systems configuration files. The osseal-restricted
ACL permits access to only administrative users, that is, members of the
osseal-admin group.
Authorization decision process
The pdosd daemon is a local-mode Tivoli Access Manager Authorization API
application. The Tivoli Access Manager documentation describes this in detail. The
pdosd daemon replicates the master Tivoli Access Manager policy database and
makes authorization decisions based on the information stored in this local replica.
Chapter 3. Runtime 95
The first step in making an authorization decision is, therefore, obtaining a replica
of the policy. The policy database is first replicated when Tivoli Access Manager
for Operating Systems is initially configured. The master policy database is
maintained by the Tivoli Access Manager policy server. If the Tivoli Access
Manager policy server is managing multiple secure domains, only the policy
database associated for the local secure domain gets replicated. Updates to a policy
are distributed to replicas by the following methods:
Active notification
When updates are made to the master policy database, the Tivoli Access
Manager policy server informs replica servers that have registered for
notification that an update has occurred. The replica servers then
download the updated database.
Polling
Replica servers periodically poll the Tivoli Access Manager policy server to
see if any updates to the master policy database have been made. If so,
they then download the updated database.
Tivoli Access Manager for Operating Systems can use either or both of these
methods. The configuration attributes, refresh-interval and ssl-listening-port,
listed in Table 48 control whether the pdosd daemon listens actively for policy
update notifications or whether it polls the Tivoli Access Manager policy server at
regular intervals. The configuration attribute, ssl-local-domain, specifies the name
of the local secure domain. This is the Tivoli Access Manager secure domain that
the pdosd daemon is configured to use. The attributes reside in the
/opt/pdos/etc/pdosd.conf configuration file.
Table 48. Authorization configuration attributes
Stanza Attribute Description
[policy] refresh-interval The interval in minutes that the Tivoli Access
Manager policy server is polled for updates. A
value of zero indicates that polling should not
occur.
[ssl] ssl-listening-port The TCP/IP port assigned to the pdosd daemon to
listen for policy update notifications from the Tivoli
Access Manager policy server. A value of zero
indicates that policy updates should not be listened
for.
ssl-local-domain The name of the local secure domain. This is Tivoli
Access Manager secure domain that the pdosd
daemon is configured to use. If the Tivoli Access
Manager policy server is managing multiple secure
domains, only the policy database associated with
this domain gets replicated.
When the Tivoli Access Manager kernel extension intercepts a system operation
that requires an authorization decision, it requests the decision from the pdosd
daemon. The information that is provided by the kernel about the operation being
performed is used to make the authorization decision. This information consists of:
v The numeric accessor identity of the user attempting the operation. This can be
different from the UID of the process performing the operation because a
process in which a surrogate operation has been performed will be running as
the surrogate user identity. The accessor identity from a Tivoli Access Manager
96 Administration Guide
for Operating Systems point of view is still the original identity of the process.
The accessor identity is typically established at login time and is the ID
corresponding to the login.
v The resource that the operation is being applied to.
v The applicable policy branch (for some resources).
v The attempted operation.
v The time that the operation is occurring.
v The program being used to perform the operation.
This information is compared by the pdosd daemon to the policy that is stored in
the local replica of the policy database. Tivoli Access Manager for Operating
Systems decides whether the operation should be permitted based on the
comparison. Only policy that is contained under the policy branches to which the
machine subscribes is used in the comparison. The initial policy branch is specified
during initial configuration. The configuration attribute listed in Table 49 specifies
the initial policy branch name and is found in the /opt/pdos/etc/osseal.conf
configuration file.
You can use the pdosbranchcfg command to subscribe to additional policy
branches. All subscribed policy branches are listed in the /opt/pdos/etc/branch.conf file in precedence order. The highest precedence policy branch is listed
first and the lowest precedence policy branch is listed last. The policy for the most
precise definition of a resource is always applied. If the same resource is defined in
multiple policy branches, the precedence order determines which policy is applied.
During this process an operational error might occur if there is a hardware failure
on the machine or if the system has insufficient virtual memory available. Tivoli
Access Manager for Operating Systems is structured to minimize the possibility of
such events impacting the authorization process. If the pdosd daemon is unable to
make a decision based on the authorization policy, it applies a default decision
based on whether the user is an administrative user or not. For an administrative
user the default decision under error conditions is to grant access.
Non-administrative users are denied access under error conditions.
Table 49. Authorization policy branch configuration attribute
Stanza Attribute Description
[policy] branch Name of the policy branch to which this machine
subscribes.
TCB monitoring
The resources that are included in the Trusted Computing Base are discussed in
“Trusted Computing Base resources” on page 36. They include the following:
v Secure-Files
v Secure-Programs
v Login-Programs
v Impersonator-Programs
v Immune-Programs
v Immune-Surrogate-Programs
In addition, programs listed in Access-Restrictions attribute entries with permit
rules are also included in the TCB, because it must be verified that the program
used to access the resource has not been corrupted. Note that programs listed in
Chapter 3. Runtime 97
Access-Restrictions attribute entries with deny rules are not included in the TCB
(unless the program is also in a permit rule or is a resource that is in the TCB, such
as Secure-Programs).
The following attributes make up a file’s signature:
v File size
v File creation time
v File modify time
v File permissions
v File ownership
v File type (such as regular file, directory, or soft-link)
v Content checksum (for regular files)
The interval over which the pdosd daemon checks all the Trusted Computing Base
files is configurable. The checking of the files is evenly distributed throughout this
interval. If the Trusted Computing Base contains a large number of files, this
interval might be too short to check every file before the interval expires. If this
situation occurs, the pdosd daemon generates warnings in its log file,
/var/pdos/log/msg__pdosd.log.
The pdosd daemon makes an explicit check of an executable file’s signature when
making an authorization decision initiated by the attempted execution of a
program defined in the Trusted Computing Base. By default, this includes checking
the CRC of the executable file. This behavior can be changed by using the
–tcb_nocrc_on_exec option.
Several configuration attributes are available to control the amount of processing
resource that the pdosd daemon should devote to Trusted Computing Base file
monitoring. Table 50 on page 99 describes the attributes specified in the
/opt/pdos/etc/pdosd.conf configuration file.
98 Administration Guide
Table 50. pdosd TCB file monitoring resource configuration attributes
Stanza Attribute Description
[tcb]
monitor-threads Controls the number of threads engaged in
Trusted Computing Base monitoring. The TCB
monitoring load is evenly distributed among the
threads. It is useful to increase this value only on
multiprocessor systems. You do not need more
monitor threads than CPUs.
interval The interval in minutes over which the entire TCB
is scanned for changes. Increasing this interval
reduces the load of the TCB monitoring system,
but increases the time in which you can expect a
change to be detected.
max-checksum-file-size Controls the number of bytes that are considered
significant in the calculation of a file’s checksum.
This provides a degree of checksum monitoring of
very large files without committing extensive
computing resources. The bytes used in
calculation of the checksum are chosen from
locations distributed throughout the file instead of
just at the beginning or end to maximize the
probability of detecting a change. The most
expensive operation performed in TCB monitoring
is checksum calculation.
ignore-ctime Causes ctime to be ignored when performing TCB
signature comparisons. When this option is
enabled, a change in ctime does not cause the
TCB resource to become untrusted.
tcb_nocrc_on_exec Causes the CRC data checksum that normally
occurs as part of the authorization check
associated with running an executable file that is
registered in the TCB to be skipped. Enable this
option if it is important to avoid performing the
CRC check on large binary files.
The trust states and signatures of TCB files are maintained on a per-machine basis
in the object signature database and are not distributed back to the central Tivoli
Access Manager policy server. This practice recognizes that the same file might
have different signatures on each machine and might be trusted or untrusted
independently on each machine. When a file becomes untrusted, it remains
untrusted until the pdosobjsig command is used to retrust it. You can also use the
pdosobjsig command to generate lists of trusted or untrusted files and for other
tasks related to maintaining and examining the state of the Trusted Computing
Base object signature database.
The pdosd log configuration
The pdosd daemon maintains a log file called /var/pdos/log/msg__pdosd.log that
records significant events and error conditions associated with the daemon itself.
Entries in this file are written in text format and consist of:
v A UTC (Universal Time Coordinated) timestamp
v Information identifying the component recording the message
v The message classification
v The message text
Chapter 3. Runtime 99
Table 51 lists the attributes that control this log file.
Table 51. pdosd log configuration attributes
Stanza Attribute Description
[pdosd]
log-entries The number of pdosd log entries to write before
archiving the pdosd log file. The default value of zero
means that the number of entries to write is unlimited
and the pdosd log file will not be archived. If
log-entries is nonzero and logs is nonzero, the pdosd
log file will be archived when the number of entries in
it reaches the number of entries specified by
log-entries or when the pdosd daemon is restarted. If
log-entries is nonzero and logs is zero, the pdosd log
file will be recycled when the number of entries in it
reaches the number specified by log-entries or when
the pdosd daemon is restarted.
logs The number of pdosd archive log files to use before
recycling the pdosd archive log files. Setting the number
of pdosd archive log files to a nonzero value has an
effect only if the log-entries is nonzero. The pdosd log
file will be archived when the number of entries in it
has reached the number of entries specified by
log-entries or when the pdosd daemon is restarted.
The default value of zero means never archive the
pdosd log file.
The pdosauditd audit daemon
The pdosauditd audit daemon manages the Tivoli Access Manager for Operating
Systems audit log. The audit daemon receives binary audit records from the
daemons, kernel extension, and the pdosobjsig command and stores them in
memory and writes them to the audit log on a regular basis. The active audit log is
/var/pdos/audit/audit.log.
The pdostecd and pdoslrd daemons use the audit.log file as input. If the file is
removed, the daemons shut down and must be manually restarted after the
audit.log file is made available again. The pdosauditd daemon must be shut
down and then restarted to make the audit.log file available.
Components generate audit records based on the audit-level settings. For
authorization decisions, the global audit level, global warning level, resource audit
level, resource warning level, and per user audit level are all considered. In the
case of a non-authorization decision, only the global audit level is used.
The global audit level is set in the /opt/pdos/etc/osseal.conf configuration file.
The format of the global audit-level attribute in this file is shown in Table 52 on
page 101. This configuration file is read by the daemons when they start. The
pdosctl command can be used to change the global audit level during system
operation.
100 Administration Guide
Table 52. Global Audit-Level Configuration Attribute
Stanza Attribute Description
[audit] level The global audit level in effect when the daemons are started.
permit_actions The global audit permit_actions in effect when the daemons
are started.
deny_actions The global audit deny_actions in effect when the daemons are
started.
The pdosauditd daemon maintains a separate log file called /var/pdos/log/msg__pdosauditd.log that records significant events and error conditions associated
with the daemon itself. Entries in this file are written in text format and consist of:
v A UTC (Universal Time Coordinated) timestamp
v Information identifying the component recording the message
v The message classification
v The message text
The pdosauditd configuration
The configuration of the pdosauditd daemon is controlled by setting attributes in
the /opt/pdos/etc/pdosauditd.conf file.
Two attributes in this file control how the audit log is managed.
v The audit-logflush attribute specifies the frequency, in seconds, at which the
pdosauditd daemon should flush audit records from memory to the audit log.
By default, the log is flushed every 5 seconds.
v The audit-logsize attribute specifies the maximum size, in bytes, that the audit
log can reach before the audit log is renamed and a new audit log is started. A
value of zero indicates there is no maximum size for the audit log. The default
size is 1000000 bytes.
When the audit log reaches the maximum size specified, the current audit log file
in the /var/pdos/audit directory is renamed using the current timestamp from
audit.log to audit.log.YYYY-MM-DD-HH-MM-SS. Logging then continues in a new
audit.log file in the same directory.
Two other attributes in the configuration file control how the pdosauditd log is
managed.
v The log-entries attribute specifies the maximum number of entries that can be
written to the log before the log is renamed and a new one started. The default
value is zero, which indicates that the log should never be rolled over.
v The logs attribute specifies the maximum number of individual log files that can
be written before the oldest one is reused. If the log-entries attribute is zero,
this value is ignored.
Table 53 on page 102 describes all of the pdosauditd configuration file attributes
for managing the audit.log file and the msg__pdosauditd.log file. These settings
also can be changed with the pdoscfg command described in “pdoscfg” on page
280.
Chapter 3. Runtime 101
Table 53. pdosauditd configuration attributes
Stanza Attribute Description
[pdosauditd]
audit-logflush Interval in seconds that the pdosauditd daemon flushes
the audit records to the audit log.
audit-logsize Maximum size in bytes to which the audit log can grow
before pdosauditd rolls over to use a new log file.
log-entries The number of pdosauditd log entries to write before
archiving the pdosauditd log file. The default value of
zero means that the number of entries to write is
unlimited and the pdosauditd log file will not be
archived. If log-entries is nonzero and logs is nonzero,
the pdosauditd log file will be archived when the
number of entries in it reaches the number of entries
specified by log-entries or when the pdosauditd
daemon is restarted. If log-entries is nonzero and logs
is zero, the pdosauditd log file will be recycled when the
number of entries in it reaches the number specified by
log-entries or when the pdosauditd daemon is
restarted.
logs The number of pdosauditd archive log files to use before
recycling the pdosauditd archive log files. Setting the
number of pdosauditd archive log files to a nonzero
value has an effect only if the log-entries is nonzero.
The pdosauditd log file will be archived when the
number of entries in it has reached the number of entries
specified by log-entries or when the pdosauditd
daemon is restarted. The default value of zero means
never archive the pdosauditd log file.
For information about enabling auditing, see “Using auditing to verify policy” on
page 153. See “Audit log formats” on page 253 for information on viewing audit
logs.
The pdoswdd watchdog daemon
The pdoswdd watchdog daemon monitors the availability of the pdosd,
pdosauditd, pdoslpmd, and pdoslrd daemons. These daemons monitor each other
in the same manner; this is the watchdog daemon’s only function. This
self-monitoring function, as implemented by each of the daemons, is the watchdog
system. The watchdog system ensures the high availability of Tivoli Access
Manager for Operating Systems services on a machine.
Note: The pdostecd daemon, described in “The pdostecd Tivoli Enterprise Console
daemon” on page 104 is not monitored by the other daemons.
When deployed, Tivoli Access Manager for Operating Systems constitutes a core
component of the system that it is protecting. Ensuring that it remains available is
vital to maintaining the integrity of the system and helps protect against attacks
that might cause the daemons to terminate abnormally.
The pdoswdd daemon maintains a log file called /var/pdos/log/msg__pdoswdd.log
that records significant events and error conditions associated with the daemon
itself. Entries in this file are written in text format and consist of:
v A UTC (Universal Time Coordinated) timestamp
v Information identifying the component recording the message
102 Administration Guide
v The message classification
v The message text
The pdoswdd configuration
Configuration of the pdoswdd daemon is done using the pdoswdd configuration
file, /opt/pdos/etc/pdoswdd.conf.
The two attributes in the configuration file control how the pdoswdd log is
managed:
v The log-entries attribute specifies the maximum number of entries that can be
written to the log before the log is renamed and a new one started. The default
value is zero, which indicates that the log should never be rolled over.
v The logs attribute specifies the maximum number of individual log files that can
be written before the oldest one is reused. If the log-entries attribute is zero,
this value is ignored.
Table 54 describes the pdoswdd configuration file attributes for managing the
msg__pdoswdd.log file.
Table 54. pdoswdd configuration attributes
Stanza Attribute Description
[pdoswdd]
log-entries The number of pdoswdd log entries to write before
archiving the pdoswdd log file. The default value of
zero means that the number of entries to write is
unlimited and the pdoswdd log file will not be
archived. If log_entries is nonzero and logs is
nonzero, the pdoswdd log file will be archived
when the number of entries in it reaches the
number of entries specified by log_entries or when
the pdoswdd daemon is restarted. If log_entries is
nonzero and logs is zero, the pdoswdd log file will
be recycled when the number of entries in it
reaches the number specified by log_entries or
when the pdoswdd daemon is restarted.
logs The number of pdoswdd archive log files to use
before recycling the pdoswdd archive log files.
Setting the number of pdoswdd archive log files to
a nonzero value has an effect only if the
log_entries is nonzero. The pdoswdd log file will
be archived when the number of entries in it has
reached the number of entries specified by
log_entries or when the pdoswdd daemon is
restarted. The default value of zero means never
archive the pdoswdd log file.
If one of the daemons terminates abnormally, the watchdog system detects this and
generates a log message in the error log of the daemon that detected the abnormal
termination. Watchdog log messages can, therefore, appear in any daemon log file:
pdosd /var/pdos/log/msg__pdosd.log
pdosauditd
/var/pdos/log/msg__pdosauditd.log
pdoswdd
/var/pdos/log/msg__pdoswdd.log
Chapter 3. Runtime 103
pdoslpmd
/var/pdos/log/msg__pdoslpmd.log
pdoslrd
/var/pdos/log/msg__pdoslrd.log
If administrative audit events are enabled, an audit event also is written to the
audit log to record the abnormal termination.
The pdostecd Tivoli Enterprise Console daemon
The pdostecd daemon makes a subset of the audit events produced by Tivoli
Access Manager for Operating Systems available to the Tivoli Enterprise Console.
The daemon reads the active log file, /var/pdos/audit/audit.log, and records
relevant audit events to a file called /var/pdos/tec/tec.log, which the Tivoli
Enterprise Console logfile adapter can monitor. A description of the events made
available can be found in Appendix C, “Tivoli Enterprise Console and Tivoli Risk
Manager events,” on page 369.
If the pdostecd daemon cannot access the /var/pdos/audit/audit.log file, the
daemon shuts down. The daemon must be manually restarted after the audit.log
file becomes available again.
The tec.log file grows unbounded and must be cleared periodically to keep the
/var file system from becoming full. See “Periodic log maintenance” on page 105
for details.
The pdostecd daemon maintains a log file called /var/pdos/pdostecd/msg__pdostecd.log that records significant events and error conditions associated
with the daemon itself. Entries in this file are written in text format and consist of:
v A UTC (Universal Time Coordinated) timestamp
v Information identifying the component recording the message
v The message classification
v The message text
The pdostecd configuration
Configuration of the pdostecd daemon is done using the pdostecd configuration
file, /opt/pdos/etc/pdostecd.conf.
The two attributes in the configuration file control how the pdostecd log is
managed:
v The log-entries attribute specifies the maximum number of entries that can be
written to the log before the log is renamed and a new one started. The default
value is zero, which indicates that the log should never be rolled over.
v The logs attribute specifies the maximum number of individual log files that can
be written before the oldest one is reused. If the log-entries attribute is zero,
this value is ignored.
Table 55 on page 105 describes the pdostecd configuration file attributes for
managing the /var/pdos/pdostecd/msg__pdostecd.log file.
104 Administration Guide
Table 55. pdostecd configuration attributes
Stanza Attribute Description
[pdostecd]
log-entries The number of entries that can be written to the
pdostecd daemon log file before rolling over to a
new file. The default value of zero indicates that the
log file should never be rolled over.
logs The number of log files to be written before
recycling the first one. A value of zero indicates that
log files should never be recycled. If the
log-entries attribute is zero, this value is ignored.
Periodic log maintenance
The /var/pdos/tec/tec.log grows unbounded. This file must be cleared
periodically to prevent the /var file system from running out of space. This can be
accomplished by the Tivoli Scheduler (part of Tivoli Management Framework), or
with a script using the UNIX cron utility.
The basic operation of the script is as follows.
1. Stop the pdostecd daemon. This stops new records from being written to the
log file.
/opt/pdos/bin/rc.pdostecd stop
2. Sleep for a sufficient amount of time to allow the Tivoli Enterprise Console
UNIX logfile adapter to complete the processing of the existing records in the
tec.log file. For instance, to sleep for 5 minutes:
sleep 300
3. Restart the pdostecd daemon. The daemon deletes the existing tec.log file and
creates a new one.
/opt/pdos/bin/rc.pdostecd start
This operation should be done during periods of minimal activity in the system.
The pdostecd daemon attempts to resume processing of the audit log file at the
place where it stopped. If there was a lot of audit activity while the daemon was
inactive, it is possible that the audit log file has wrapped. If the pdostecd daemon
is unable to locate its resumption point, processing resumes at the end of the
current audit log file.
The pdoslpmd login policy and password management daemon
The pdoslpmd daemon provides support for the Tivoli Access Manager for
Operating Systems login activity policy and password management enforcement.
Processes that perform logins and password changes communicate with the
pdoslpmd daemon to determine whether the operation is allowed under the
current Tivoli Access Manager for Operating Systems policy.
By default, login activity and password management policy enforcement is enabled
when Tivoli Access Manager for Operating Systems is configured. If a login policy
is not enabled on the system, the pdoslpmd daemon will not be running. If the
login policy is enabled after the initial configuration, the pdoslpmd daemon will be
started the next time Tivoli Access Manager for Operating Systems is started.
Table 56 on page 106 lists the attribute specified in the /opt/pdos/etc/pdosd.conf
configuration file that controls whether or not enforcement is enabled.
Chapter 3. Runtime 105
Table 56. pdoslpmd configuration attributes
Stanza Attribute Description
[pdoscfg]
login-policy Controls whether (on) or not (off) login activity and
password management policy enforcement is
enabled.
The pdoslpmd daemon relies on the pdosd daemon for operation. If pdoslpmd is
running, but pdosd is not, no enforcement of login or password management
policy will occur.
The pdoslpmd configuration
Configuration of the pdoslpmd daemon is done using the pdoslpmd configuration
file, /opt/pdos/etc/pdoslpmd.conf.
Table 57 describes the pdoslpmd configuration file attributes for managing its log
file.
Table 57. pdoslpmd configuration attributes
Stanza Attribute Description
[pdoslpmd]
max_pending_logins The maximum number of records to track for login
failures. Specify an integer for this value. The
default value is 100.
failure_audit_seconds The maximum amount of time that will pass before
the pdoslmpd daemon audits login failures. Specify
an integer for this value. The default value is 10.
log-entries The number of pdoslpmd log entries to write
before archiving the pdoslpmd log file. The default
value of zero means that the number of entries to
write is unlimited and the pdoslpmd log file will
not be archived. If log-entries is nonzero and logs
is nonzero, the pdoslpmd log file will be archived
when the number of entries in it reaches the
number of entries specified by log-entries or
when the pdoslpmd daemon is restarted. If
log-entries is nonzero and logs is zero, the
pdoslpmd log file will be recycled when the
number of entries in it reaches the number
specified by log-entries or when the pdoslpmd
daemon is restarted.
logs The number of pdoslpmd archive log files to use
before recycling the pdoslpmd archive log files.
Setting the number of pdoslpmd archive log files to
a nonzero value has an effect only if the
log-entries is nonzero. The pdoslpmd log file will
be archived when the number of entries in it has
reached the number of entries specified by
log-entries or when the pdoslpmd daemon is
restarted. The default value of zero means never
archive the pdoslpmd log file.
The /opt/pdos/etc/lpm.conf file is a local representation of the login activity and
password management policy for the Tivoli Access Manager for Operating Systems
host. It is maintained and updated by the Tivoli Access Manager for Operating
Systems runtime to keep the policy up-to-date with the policy that is specified in
106 Administration Guide
the object space. This file should not be updated manually. Such updates will be
lost when a new policy is processed by the Tivoli Access Manager for Operating
Systems runtime.
The pdoslrd log router daemon
The pdoslrd log router daemon reads a Tivoli Access Manager for Operating
Systems audit record from an input channel, formats the record, and then queues
the record for the output channels to process. Each output channel dequeues a
formatted audit record, applies a filter to it (if one has been specified for that
channel), and, if the record is not filtered out, formats the record into the proper
output format, and sends it to its destination. The pdoslrd daemon uses the
audit.log file as input. If the file is removed, the daemon shuts down and must be
manually restarted after the audit.log file is made available. The pdosauditd
daemon must be shut down and then restarted to make the audit.log available.
The pdoslrd configuration
There are two aspects to pdoslrd configuration: the initial configuration of the
daemon, following installation, and the specification of the control file, which
contains the parameters that are necessary to run the audit log application. Initial
configuration is described here; specification of the control file is described in
Chapter 4, “The log router daemon,” on page 121.
Chapter 3. Runtime 107
Table 58 describes the pdoslrd configuration file attributes.
Table 58. pdoslrd Configuration Attributes
Stanza Attribute Description
[pdoslrd]
state The value can be on or off. If pdoslrd has been
configured, the state is on. Otherwise, the state is
off.
log-entries The number of pdoslrd log entries to write before
archiving the pdoslrd log file. The default value of
zero means that the number of entries to write is
unlimited and the pdoslrd log file will not be
archived. If log-entries is nonzero, and logs is
nonzero, the pdoslrd log file will be archived when
the number of entries in it reaches the number of
entries specified by log-entries or when the
pdoslrd daemon is restarted. If log_entries is zero,
the pdoslrd log file will be recycled when the
number of entries in it reaches the number specified
by log-entries or when the pdoslrd daemon is
restarted.
logs The number of pdoslrd archive log files to use
before recycling the pdoslrd archive log files.
Setting the number of pdoslrd archive log files to a
nonzero value has an effect only if the log-entries
is nonzero. The pdoslrd log file will be archived
when the number of entries in it has reached the
number of entries specified by log-entries or when
the pdoslrd daemon is restarted. The default value
of zero means never archive the pdoslrd log file.
lrd-local-domain If pdoslrd has been configured to have a local
domain that is different from the one Tivoli Access
Manager for Operating Systems is configured to, it
will appear here.
lrd-admin-name The admin name used to configure pdoslrd. This
name might be different from the Tivoli Access
Manager server admin name if pdoslrd has been
configured with a local domain that is different
from the one Tivoli Access Manager for Operating
Systems is configured to.
Users and groups
Tivoli Access Manager for Operating Systems uses various Tivoli Access Manager
and UNIX users and groups. The necessary Tivoli Access Manager users and
groups are created during the initial configuration of Tivoli Access Manager for
Operating Systems. The UNIX users and groups are created on each Tivoli Access
Manager for Operating Systems system during installation.
The role of each of these users and groups is discussed in this section.
osseal-admin group
The osseal-admin group is a Tivoli Access Manager group that identifies users that
are administrative users, or administrators. The corresponding UNIX group is
called osseal. Administrators are treated slightly differently from general users,
according to the following rules.
108 Administration Guide
v Credentials of administrators are never flushed from the disk cache. The
credentials of a general user are flushed from the disk cache after the credential
hold time expires for those credentials.
v Credentials of administrators are maintained on a system even if an
administrator has never logged on to the system. It is important to allow
administrators to access a system they have never logged in to before, even if
that system is isolated from the Tivoli Access Manager user registry. General
users do not have a credential cached on a system until they have logged in to it
for the first time.
v The default decision made by the pdosd daemon when making a decision under
error conditions is to grant access for administrators. For general users the
default decision is to deny. “The pdosd authorization daemon” on page 90 has
more information about such error conditions.
When Tivoli Access Manager for Operating Systems is configured for the first time,
the membership of the osseal-admin group consists of two users, root and osseal.
Do not remove the osseal user ID from this group.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
osseal-admin group will be osseal-admin@domain_name, where domain_name is the
name of the domain to which Tivoli Access Manager for Operating Systems is
configured. If the domain is tivoli.com, this group would be [email protected].
osseal group
The osseal group is a UNIX group that identifies users that are administrative
users, or administrators on a particular system. This group corresponds to the
osseal-admin group in Tivoli Access Manager. This group is used to permit access
using the various setgid commands provided by Tivoli Access Manager for
Operating Systems to resources protected by UNIX security under the /var/pdos
directory. This group is the primary group of the osseal UNIX user ID. Do not
remove the osseal user ID from this group.
Users who are members of both the osseal-admin and osseal groups are called
Tivoli Access Manager for Operating Systems runtime administrators and are
authorized to perform the tasks associated with managing the Tivoli Access
Manager for Operating Systems runtime environment.
osseal user
The osseal user is represented in both Tivoli Access Manager and UNIX. Tivoli
Access Manager for Operating Systems treats this user in a special way on the
UNIX system. The osseal user is an identity that the Tivoli Access Manager for
Operating Systems daemons and commands adopt when they are running.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
osseal group will be osseal@domain_name, where domain_name is the name of the
domain to which Tivoli Access Manager for Operating Systems is configured. If the
domain is tivoli.com, this group would be [email protected].
root user
Configuring Tivoli Access Manager for Operating Systems initially creates a Tivoli
Access Manager user ID of root. This user corresponds to the root UNIX user to
ensure that root can never be treated as an unauthenticated user. The root user is
initially made a member of the osseal-admin group. The root user’s membership
Chapter 3. Runtime 109
in the osseal-admin group ensures that the root user’s credentials are always
available on all Tivoli Access Manager for Operating Systems systems.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
root user will be root@domain_name, where domain_name is the name of the domain
to which Tivoli Access Manager for Operating Systems is configured. If the domain
is tivoli.com, this user would be [email protected].
The root user represents the UNIX root user across all Tivoli Access Manager for
Operating Systems systems sharing the same Tivoli Access Manager user registry.
osseal-auditors group
The osseal-auditors group is a Tivoli Access Manager group that identifies users
that are auditors. The corresponding UNIX group is called ossaudit.
When Tivoli Access Manager for Operating Systems is configured for the first time,
the membership of the osseal-auditors group consists of two users, root and
ossaudit.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
osseal-auditors group will be osseal-auditors@domain_name, where domain_name is
the name of the domain to which Tivoli Access Manager for Operating Systems is
configured. If the domain is tivoli.com, this group would be [email protected].
ossaudit group
The ossaudit group is a UNIX group that identifies users that are auditors. This
group corresponds to the osseal-auditors group in Tivoli Access Manager. The
osseal user is a member of this group.
Users who are members of both the osseal-auditors and ossaudit groups are called
Tivoli Access Manager for Operating Systems auditors and are authorized to
perform the tasks associated with accessing the Tivoli Access Manager for
Operating Systems audit trail.
Do not remove the osseal user ID from this group.
osseal-unauth user
The osseal-unauth user has only a Tivoli Access Manager representation. It has no
UNIX equivalent. It controls time-of-day login restrictions for unauthenticated,
from a Tivoli Access Manager point of view, users independently from
authenticated users. This is similar to the role of the unauthenticated entry in an
ACL entry.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
osseal-unauth user will be osseal-unauth@domain_name, where domain_name is the
name of the domain to which Tivoli Access Manager for Operating Systems is
configured. If the domain is tivoli.com, this user would be [email protected].
pdosd-hostname user
The Tivoli Access Manager policy server does not allow every user to replicate the
policy database. A Tivoli Access Manager user is created during configuration for
each instance of the pdosd daemon that runs in the secure domain managed by the
110 Administration Guide
Tivoli Access Manager policy server. Because one of these users is created for each
Tivoli Access Manager for Operating Systems system, the fully qualified DNS host
name for the machine is included in the name, for example, pdosd-hostname user.
When the DNS name is not available, the host’s name is used instead. The pdosd
daemon authenticates to the Tivoli Access Manager policy server as this user to
receive policy updates. Do not modify this user and its group membership.
Group for critical users
You can use Tivoli Access Manager to define a group that identifies users that
should be considered critical to system operation. Defining this group is
configurable with the –critical_cred_group option of the pdoscfg command.
Critical users are treated slightly differently from general users, according to the
following rules:
v Credentials of critical users are never flushed from the disk cache.
v Credentials of critical users are maintained on a system even for critical users
that have never logged on. This is important to allow critical users to access a
system they have never logged on to even if the system is isolated from the
Tivoli Access Manager user registry.
Defining this group is optional and does not need to be configured. This group
does not need to have a corresponding local UNIX group. The members of the
group must have corresponding local UNIX IDs or they will be ignored.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
name of critical users group that is defined with the –critical_cred_group option of
the pdoscfg command will be in the form group_name@domain_name. In this case,
group members will be in the form group_member@domain_name, where
group_member is the UNIX user name for this member. If the domain is tivoli.com
and the critusers group contains users marc and jonathan, this group would be
[email protected] with members [email protected] and [email protected].
Files and directories
Tivoli Access Manager for Operating Systems installs itself into common locations
on all platforms. This is necessary because various components have important
implications to the security of the system and access is controlled to these
components using a Tivoli Access Manager for Operating Systems policy. A
simpler policy results if the location of common resources is consistent across
systems.
This section summarizes the role of the various files and directories used by Tivoli
Access Manager for Operating Systems.
/opt/pdos/bin
Contains all of the binary executable images that comprise the user-level
runtime.
/opt/pdos/etc
Contains configuration files for the various components that use
configuration files. This directory also contains other administrative
information, such as descriptions of the initial policy established during
configuration, the files and directories that are backed up and restored by
the pdosbkup and pdosrstr commands, and template configuration files
that provide basic descriptions of the various configuration attributes. The
particular components include:
Chapter 3. Runtime 111
/trace This directory contains the default routing files for Tivoli Access
Manager for Operating Systems daemons and commands.
branch.conf
This configuration file contains the configured policy branches in
precedence order.
osseal.conf
This general configuration file contains configuration parameters
that are common to all components.
pdosd.conf
The configuration file for the pdosd daemon.
pdosauditd.conf
The configuration file for the pdosauditd daemon.
pdoslpmd.conf
The configuration file for the pdoslpmd daemon.
pdoslrd.conf
The configuration file for the pdoslrd daemon.
pdoslrd.xml
The configuration file for the pdoslrd daemon.
pdoswdd.conf
The configuration file for the pdoswdd daemon.
pdostecd.conf
The configuration file for the pdostecd daemon.
pdossudo.conf
The configuration file for pdossudo.
lpm.conf
The login activity and password management policy enforcement
configuration file.
/opt/pdos/kernel
Contains binaries and files related to Tivoli Access Manager for Operating
Systems kernel functionality.
/opt/pdos/kernel_26
Contains binaries and files related to Tivoli Access Manager for Operating
Systems kernel functionality for Linux systems running with the 2.6 Linux
kernel.
/opt/pdos/lib
Contains the shared libraries that contain executable code shared by the
various commands.
/opt/pdos/nls
Contains language-specific files.
/opt/pdos/sbin
Contains binaries and scripts related to problem determination.
/var/pdos/audit
Contains the Tivoli Access Manager for Operating Systems audit file,
/var/pdos/audit/audit.log.
/var/pdos/azn
Contains the local replica of the Tivoli Policy Director policy database in
authzn_replica.db.
112 Administration Guide
/var/pdos/certs
Contains files that contain the certificates that the pdosd and pdoslrd
daemons use when mutually authenticating with both the Tivoli Access
Manager policy server and the LDAP user registry server.
/var/pdos/cred
Contains the cached Tivoli Access Manager credentials.
/var/pdos/ffdc
This directory is used to store data captured by the first failure data
capture tools.
/var/pdos/hla
Contains the host lookaside database that is used to cache IP-address to
host name mappings when this feature is enabled.
/var/pdos/log
Contains the log files for all of the daemons (except the pdostecd daemon)
and the configure, unconfigure, backup, and restore commands.
/var/pdos/login
Contains temporary files associated with the login activity policy.
/var/pdos/lpm
Contains the local machine information needed to enforce login account
activity and the password management policy.
/var/pdos/pdosauditd
This directory is used as the current working directory for the pdosauditd
daemon while it is running. If an error resulting in a core file occurs, this
directory is where the core file will be located.
/var/pdos/pdosbkup
This directory is used as the current working directory for the pdosbkup
and pdosrstr commands while they are running. The backup file created
by the pdosbkup command is written to this directory by default. If an
error resulting in a core file occurs during the execution of either
command, this directory is where the core file will be located.
/var/pdos/pdoscfg
This directory is used as the current working directory for the pdoscfg and
pdosucfg commands while they are running. If an error resulting in a core
file occurs, this directory is where the core file will be located.
/var/pdos/pdosd
This directory is used as the current working directory for the pdosd
daemon while it is running. If an error resulting in a core file occurs, this
directory is where the core file will be located.
/var/pdos/pdoslrd
This directory is used as the current working directory for the pdoslrd
daemon while it is running. It contains the input channel’s last input
processed (.lrp) file and the output file cache. If an error resulting in a
core file occurs, this directory is where the core file will be located.
/var/pdos/pdosteccfg
This directory is used as the current working directory for the pdosteccfg
and pdostecufg commands while they are running. If an error resulting in
a core file occurs, this directory is where the core file will be located.
/var/pdos/pdostecd
This directory is used as the current working directory for the pdostecd
Chapter 3. Runtime 113
daemon while it is running. If an error resulting in a core file occurs, this
directory is where the core file will be located. This is also the location of
the error log for the pdostecd daemon.
/var/pdos/pdoswdd
This directory is used as the current working directory for the pdoswdd
daemon while it is running. If an error resulting in a core file occurs, this
directory is where the core file will be located.
/var/pdos/tcb
Contains the information used to detect changes to the files comprising the
Trusted Computing Base.
/var/pdos/tec
Contains the file with audit events that is monitored by the Tivoli
Enterprise Console logfile adapter.
/var/pdos/tracelogs
Contains the default trace log files for Tivoli Access Manager for Operating
Systems daemons and commands.
/var/pdos/uid
Contains the cache of UIDs and GIDs to user and group names when this
feature is enabled. No management of this cached information is required.
/var/pdos/umsg
Contains files used for inter-process communication and synchronization
between components of Tivoli Access Manager for Operating Systems.
/var/pdos/watch
Contains files used by the watchdog system to detect abnormal termination
of the pdosd, pdosauditd, pdoswdd, pdoslrd, or pdoslpmd daemons.
Initial policy
The following components of the policy are established when Tivoli Access
Manager for Operating Systems is initially configured:
once-only
This policy is shared across all policy branches. It comprises the actions
used to represent Tivoli Access Manager for Operating Systems operations,
ACLs used to protect resources, the users and groups discussed previously,
and the /OSSEAL object space under which all protected objects reside.
per-policy
This policy is established for each initial policy branch. It describes the
contents of the Trusted Computing Base and attaches the ACLs and POPs
that Tivoli Access Manager for Operating Systems uses to protect itself
from being compromised.
The default policy established by Tivoli Access Manager for Operating Systems
ensures that the system functions properly and maintains a secure environment.
The existing default policy should not be modified.
The remainder of this section describes the ACLs established during policy creation
and the resources that they protect. The default policy is sufficient to protect Tivoli
Access Manager for Operating Systems without adding any additional
authorization policies to other resources on a system, except for system programs
defined as initial members of the Trusted Computing Base. See “Trusted
114 Administration Guide
Computing Base resources” on page 36 for more information about the initial
population of the Trusted Computing Base.
osseal-audit
This ACL controls access to the /var/pdos/audit directory, where the Tivoli Access
Manager for Operating Systems audit trail resides. It also controls access to
/var/pdos/pdoslrd, /var/pdos/pdostecd, and /var/pdos/tec. The ACL permits
only members of the osseal-auditors group to access the directory or, by
inheritance, its contents.
osseal-audit-exec
This ACL controls access to the pdosaudview command, /opt/pdos/bin/pdosaudview. Members of the osseal-auditors group are granted full access to this
command. All other users are restricted from using this command.
osseal-credentials
This ACL controls access to the directories that make up the Tivoli Access Manager
for Operating Systems credential cache: /var/pdos/cred and /var/pdos/uuid. It
grants all users the ability to refresh and destroy credentials, but only by using the
pdosrefresh and pdosdestroy commands. Tivoli Access Manager for Operating
Systems ensures that users are allowed to refresh and destroy only their own
credentials unless granted access by access controls to the credential cache
directories. This ACL restricts the ability to refresh or destroy any user’s credentials
to members of the osseal-admin group.
osseal-default
This is a fully permissive ACL. It is applied at object space root for Tivoli Access
Manager for Operating Systems: /OSSEAL. Its presence ensures that authorization
decisions never propagate all the way to the root of the Tivoli Access Manager
object space.
osseal-default-file
This is a fully permissive ACL that is in place as a reminder that Tivoli Access
Manager for Operating Systems File resources violate the Tivoli Access Manager
inheritance algorithm by not inheriting ACLs from those placed above File in the
tree.
osseal-default-login
This ACL defines the default Login resource policy. It permits everyone to log in.
osseal-default-net-incoming
This ACL defines the default NetIncoming resource policy. It permits incoming
connections from any host to any service to be accepted by any user. If limited
network access inheritance is enabled (–net_ACL_limited option), the ACL at the
NetIncoming resource will not actually be enforced and will serve as a reminder
that an implicit ACL is assumed, like the osseal-default-file ACL.
osseal-default-net-outgoing
This ACL defines the default NetOutgoing resource policy. It permits any user to
make outgoing connections to any host to access any remote service. If limited
network access inheritance is enabled (–net_ACL_limited option), the ACL
Chapter 3. Runtime 115
attached at the NetOutgoing resource will not actually be enforced and will serve
as a reminder that an implicit permissive ACL is assumed, like the
osseal-default-file ACL.
osseal-default-sudo
This ACL defines the default Sudo resource policy. It permits any user to execute
any Sudo command
osseal-default-surrogate
This ACL defines the default Surrogate resource policy. It permits anybody to
surrogate to any user or group.
osseal-exec-open
This ACL controls access to the /opt/pdos/lib and /opt/pdos/nls directories and
the non-administrative commands in the /opt/pdos/bin directory:
v pdosdestroy
v pdosrefresh
v pdossudo
v pdoslpinf
v pdoswhoami
This ACL permits any user access to the non-administrative commands and to the
Tivoli Access Manager for Operating Systems shared libraries used by these
commands, along with the message catalogs.
osseal-exec-root
This ACL controls access to the /opt/pdos/bin/pdoslpmd, /opt/pdos/bin/pdostecd,
/opt/pdos/bin/pdosshowmsg /opt/pdos/bin/rc.pdostecd, /opt/pdos/bin/rc.lpm,
and /opt/pdos/bin/rc.pdoslrd commands.
This ACL restricts the ability to execute these commands to root and members of
the osseal-admin group.
osseal-hla
This ACL controls access the IP address to host name cache maintained by Tivoli
Access Manager for Operating Systems in the /var/pdos/hla directory. It permits
administration of the cache by members of the osseal-admin group using the
pdoshla command
osseal-kazndrv
This ACL controls access to the Tivoli Access Manager for Operating Systems
device /dev/kazndrv. It is necessary to allow PAM-enabled programs to read and
write to the device to communicate with the Tivoli Access Manager for Operating
Systems kernel module. Only members of the osseal-admin group are allowed to
modify or remove the device.
osseal-logs
This ACL controls access to log files generated by the Tivoli Access Manager for
Operating Systems daemons and commands in the /var/pdos/log, /var/pdos/ffdc,
and /var/pdos/tracelogs directories. It restricts access to the directory to members
of the osseal-admin group.
116 Administration Guide
osseal-open
This ACL controls access to the /opt/pdos/etc/lpm.conf and /opt/pdos/etc/pdossudo.conf files. It permits any user to read the files, but not to modify them.
Members of the osseal-admin group are granted full access to resources protected
by this ACL.
osseal-privileged-user
This ACL controls the ability to surrogate to the osseal UNIX user. Access is
restricted to members of the osseal-admin group although any user can also
surrogate to osseal using the pdossudo command. This is necessary because the
pdossudo command must perform a surrogate operation to the osseal user so that
the correct authorization decision can be made when a user attempts to execute a
Sudo command. Disabling the pdossudo command’s ability to surrogate to the
osseal user also disables the function of the Sudo command.
osseal-restricted
This ACL protects the more sensitive information associated with Tivoli Access
Manager for Operating Systems. It grants full access to members of the
osseal-admin group. It permits other users to read the protected directories, but
only when using the pdoswhoami command. It is attached to the /opt/pdos/etc,
/opt/pdos/etc/trace, /var/pdos/pdosbkup, /var/pdos/pdoscfg,
/var/pdos/pdosteccfg, and /var/pdos/certs directories.
Note: The pdossudo.conf file in the /opt/pdos/etc directory has the osseal-open
ACL directly attached and is, by default, less restricted.
osseal-restricted-read
This very restrictive ACL controls the ability to start and stop the Tivoli Access
Manager for Operating Systems daemons and to execute the administrative
commands. It only grants Change Directory (D), Read (r), List Directory (l), Kill
(K), and Execute (x) permission to members of the osseal-admin group and denies
nonmembers any access at all. It protects all the directories under both /var/pdos
and /opt/pdos that maintain runtime state that do not require administrative
action.
osseal-tcb
This ACL controls access to the Trusted Computing Base object signature database
maintained by Tivoli Access Manager for Operating Systems in /var/pdos/tcb.
This ACL restricts access to this directory to members of the osseal-admin group.
They can only access resources contained in this directory by using the pdosobjsig
command.
osseal-umsg
This ACL restricts access to the /var/pdos/umsg directory that is involved with
communication between the various Tivoli Access Manager for Operating Systems
components. Access is allowed only when using a Tivoli Access Manager for
Operating Systems command that requires access to this directory.
osseal-var-lpm
This ACL controls access to the /var/pdos/lpm and /var/pdos/login directories. It
permits any user read and write access to the files below the /var/pdos/lpm
directory. This access is necessary to ensure that the Login Activity Policy
Chapter 3. Runtime 117
enforcement code can function properly. Members of the osseal-admin group and
the root user are granted full access to resources protected by this ACL.
Isolated operation
During normal operation, Tivoli Access Manager for Operating Systems relies on
the network to communicate with the Tivoli Access Manager policy server, the
Tivoli Access Manager user registry, and, in some cases, a non-local UNIX user
registry such as NIS, and a non-local host name database such as a DNS server.
Tivoli Access Manager for Operating Systems can continue to function in an
environment in which it becomes isolated from one or more of these servers,
registries, or the network itself. Isolation means the loss of ability to communicate.
This loss can occur for various reasons:
v The network itself might be down in which case Tivoli Access Manager for
Operating Systems is isolated from everything
v The Tivoli Access Manager policy server might be down
v The Tivoli Access Manager user registry might be down
v The NIS server might be down
v The DNS server might be down
The following sections discuss isolation types and how each type affects Tivoli
Access Manager for Operating Systems.
Isolation from the Tivoli Access Manager policy server
If Tivoli Access Manager for Operating Systems becomes isolated from the Tivoli
Access Manager policy server, the pdosd daemon is unable to receive updates to
the policy database. Any updates made to the policy on the master policy database
will not be propagated to Tivoli Access Manager for Operating Systems until
communication between Tivoli Access Manager for Operating Systems and the
Tivoli Access Manager policy server is reestablished. See “Authorization decision
process” on page 95 for a description of the pdosd daemon’s interaction with the
Tivoli Access Manager policy server. During normal operation of the pdosd
daemon, all policy decisions are made using the local replica of the policy database
in combination with the Trusted Computing Base. During the time that the pdosd
daemon is isolated from the Tivoli Access Manager policy server, all policy
decisions will continue to be made by using the local replica of the policy
database. When the pdosd daemon has reestablished communication with the
Tivoli Access Manager policy server, any pending updates to the policy database
are received through the specified means, active notification or polling.
Isolation from the Tivoli Access Manager user registry
If Tivoli Access Manager for Operating Systems becomes isolated from the Tivoli
Access Manager user registry, the pdosd daemon is unable to obtain new Tivoli
Access Manager credentials. This means that the pdosd daemon is unable to obtain
new credentials for users as they log in to the system and it is unable to refresh
cached credentials. See “Credential acquisition” on page 90 for a description of
how credentials are managed by the pdosd daemon in normal operation.
When the pdosd daemon detects that it has become isolated from the Tivoli Access
Manager user registry, it does not remove any credentials from the cache even if
they are overdue for a refresh or have exhausted their hold interval. This lets any
user who is currently logged in to the system to continue to function normally
using the cached credential.
118 Administration Guide
Any user with a cached credential can log in to the system while the pdosd
daemon is isolated from the Tivoli Access Manager user registry and will use their
cached credential. If a user who does not have a cached credential logs in while
the pdosd daemon is isolated from the Tivoli Access Manager user registry, that
user will run as an unauthenticated user.
Administrative and critical system users always have a cached credential. If either
type of user logs in while the pdosd daemon is isolated from the Tivoli Access
Manager user registry, that user always has a cached credential available.
When the pdosd daemon is able to communicate with the Tivoli Access Manager
user registry, it refreshes any credential that should have been refreshed during the
time of isolation from the Tivoli Access Manager user registry.
The Tivoli Access Manager per user time-of-day login restrictions are also stored in
the Tivoli Access Manager user registry. The time-of-day login restrictions are
retrieved by the pdosd daemon when a user logs in and are cached along with the
credentials. When the pdosd daemon is isolated from the Tivoli Access Manager
user registry it uses the cached time-of-day login restrictions.
Isolation from non-local UNIX user registry
Systems using a non-local UNIX user registry, such as NIS, might become isolated
from that user registry. When this happens, users might not be able to log in to the
system. Users who are logged in should be able to retrieve new Tivoli Access
Manager credentials or use existing cached credentials.
The user’s native numerical UNIX ID is converted to the user’s UNIX name using
standard UNIX operating system functions that communicate with the non-local
UNIX user NIS or NIS+ registry. “The UNIX identity and its relationship to the
Tivoli Access Manager user identity” on page 3 explains how Tivoli Access
Manager credentials are obtained.
If the Tivoli Access Manager for Operating Systems system becomes isolated from
its user registry this conversion will not succeed. Tivoli Access Manager for
Operating Systems includes a UNIX uid/gid to username/groupname cache that
can be enabled when Tivoli Access Manager for Operating Systems is configured.
When the UNIX uid/gid to username/groupname cache is enabled and the pdosd
daemon becomes isolated from its UNIX user registry, the pdosd daemon uses this
cache to map the UNIX ID to the UNIX name. After the UNIX name is known, the
pdosd daemon can retrieve the credential from the Tivoli Access Manager user
registry or the credential cache.
This cache is only ever used as a backup and is only needed when users log in or
perform Surrogate operations.
By default, the UNIX uid/gid to UNIX username/groupname cache is not enabled
because the remote UNIX registry service is likely to provide its own mechanism
for caching this information. If the remote UNIX registry service you are using
does not provide such a caching feature, you can enable the Tivoli Access Manager
for Operating Systems uid/gid cache by entering:
pdoscfg -uid on
See the IBM Tivoli Access Manager for Operating Systems: Installation Guide for details
on configuring.
Chapter 3. Runtime 119
Isolation from the host name resolution server
Tivoli Access Manager for Operating Systems can become isolated from a remote
host name resolution server such as DNS or NIS. If this happens, Tivoli Access
Manager for Operating Systems might be isolated from the Tivoli Access Manager
policy server, the Tivoli Access Manager user registry, and in some cases a
non-local UNIX user registry. The sections above describe the behavior of Tivoli
Access Manager for Operating Systems in each of these cases.
Isolation from the host name resolution server can cause additional problems. The
Tivoli Access Manager for Operating Systems network policy can be specified by
using either an IP address or a DNS host name. The pdosd daemon must be able
to convert the IP address to a DNS host name when making policy decisions for
network resources identified by host name. Tivoli Access Manager for Operating
Systems includes an IP address to host name cache to allow the pdosd daemon to
continue to perform this conversion even when isolated from a remote host name
resolution server.
By default, the IP Address to DNS host name cache is enabled. Use the pdoshla
command to manage the IP Address to DNS host name cache. You can use this
command to pre-populate entries in the cache. If your operating system provides a
local IP address to DNS host name cache, you might want to disable this feature.
Enter:
pdoscfg -dns off
To disable this feature or set the dns attribute of the [cache] stanza in the
/opt/pdos/etc/osseal.conf configuration file to off, see the IBM Tivoli Access
Manager for Operating Systems: Installation Guide for details on configuring.
The Tivoli Access Manager for Operating Systems IP address to host name cache is
always consulted first before querying a remote host name resolution service. This
is done to ensure that the authorization of network accesses is performed
efficiently. Because this cache is queried first, stale information might be used.
Tivoli Access Manager for Operating Systems caches IP address to host name
mapping for six hours after which the cache entry is refreshed on the next lookup.
If you must verify that a host’s IP address change is reflected immediately, use the
pdoshla command to immediately remove stale entries from the cache.
120 Administration Guide
Chapter 4. The log router daemon
This chapter contains information about how to modify the control file to run the
pdoslrd daemon and how to specify and use the channel types. It also provides:
v Record fields
v Field values
v Output formats
Log router control file
A control file is used to specify the various parameters necessary to run the
pdoslrd daemon. The fully qualified name of this file is /opt/pdos/etc/pdoslrd.xml. Use a text editor to modify this file. You can also use the pdoslradm
command to view and modify certain options of the Channel elements. The format
of this control file must comply with the XML 1.0 specification.
Note: The log router control file, pdoslrd.xml, is encoded in UTF-8. This means
that all the characters in the file are interpreted as UTF-8. As a result, the file
should only be edited using an editor that supports UTF-8. If your locale is
en_US, any editor that supports ASCII will suffice.
The following sections identify and define the various control options supported
by pdoslrd. The first section contains a sample control file.
Log router control file example
The following example shows a control file with an input channel and three output
channels. All audit records are sent to the Tivoli Access Manager authorization
server named serv1.ibm.com and to the Common Auditing and Reporting Service
server named serv2.ibm.com. Only login denies are sent to the LRD_EmailOutput
channel. The file-admin and the mail-admin2channels are off.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Server SYSTEM "opt/pdos/etc/pdoslrd.dtd">
<Server>
<Router name="router 1" state="on"
<Channel name="input" type="LRD_AuditInput"
path="var/pdos/audit/audit.log" state="off"/>
<Channel name="file-admin" type="LRD_FileOutput"
path="var/pdos/pdoslrd/audit.out"
format="keyvalue" state="off"/>
<Channel name="mail-admin1" type="LRD_EmailOutput"
server="mailserv.ibm.com" port="25"
address="[email protected]"
filter="login-deny" state="on"/>
<Channel name="mail-admin2" type="LRD_EmailOutput"
server="mailserv.ibm.com" port="25"
address="[email protected]"
shutdown_notify_only="yes" state="off"/>
<Channel name="netout-admin1" type="LRD_NetOtput"
destination="pdacld"
server="serv1.ibm.com" port="7136"
compress="yes" state="on"/>
<Channel name="netout-admin2" type="LRD_NetOtput"
destination="carsdb"
serverURL="https://serv2.ibm.com:9443/CommonAuditService/service/Emitter"
user_name="cars_user" state="on"/>
</Router>
© Copyright IBM Corp. 2000, 2005 121
<Filters>
<Filter name="login-deny">
<Conditional type="include">
<Field name="resource_type" value="Login"/>
<Field name="view" value="D"/>
</Conditional>
</Filter>
</Filters>
</Server>
Log router control file elements
The log router control file is comprised of the following elements:
v XML header
v Server element
v Router element
v Channel element
v Filters element
v Filter element
v Conditional element
v Field element
XML header
The XML header is required by the XML specification and should comprise the
first lines in the log router control file. These lines are as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Server SYSTEM "opt/pdos/etc/pdoslrd.dtd">
Server element
The log router control file must contain exactly one Server element. All other
elements are contained within the Server element.
Usage
<Server> Begin tag
</Server> End tag
Options
completion_action An action to be taken when the processing of an audit log
archive file has completed. By default, there is no
completion_action, which means that no action is taken. Other
possible values are "rename", which means that the suffix .lrd
will be added to the file name, and "delete", which means
that the file will be deleted.
Router element
The log router control file must contain at least one Router element. Each Router
element must contain at least one input channel and one output channel definition.
In this release, only one router element per control file is supported.
Usage
Usage
122 Administration Guide
<Router> Begin tag
</Router> End tag
Options
name The name of the router (a unique name). This is required.
state The state of the router (on or off). This is required.
hi_water The maximum number of audit records that can be queued up
for the output channels to process. When this point is reached
for any output channel, the log router will stop reading records
from the input channel until the output channel removes at
least one record from its queue. The default value is 50. If the
value zero is specified, the output channel queues can grow
unbounded, until the virtual memory of the pdoslrd process is
exhausted.
batch_mode If batch_mode is enabled, the log router will wait for a signal
from pdoslradm, and then process all the unprocessed audit
records currently in the audit log files. Any new audit records
that are generated during processing will not be processed
until the next time a signal is received from pdoslradm. This
option allows the user to control when the audit records are
processed, so that processing can be done at a convenient time,
such as a non-peak-load times. The default value is off.
For more information about this option, see the description of
the –b option of the pdoslradm command in “pdoslradm” on
page 318.
Example
<Server>
<Router name="router1" state="on" hi_water="500"
<!-- Input channel definition -->
<Channel name="audlog" type="LRD_AuditInput"
path="/var/pdos/audit/audit.log" state="on" />
<!-- Output channel -->
<Channel name="file" type="LRD_FileOutput" path="/home/sysadmin/audit.out"
format="concise" state="on"/>
</Router>
</Server>
Channel element
The Channel element is used to specify an input channel and one or more output
channels used by a particular router to process records. The input channel reads
data records from a particular source and prepares the record for processing by the
output channels. The output channels format the data record for output and apply
any filtering or formatting that has been defined. Only one filter element can be
defined per output channel, but the filter element can have multiple conditional
elements, which allow for sophisticated filtering of the records. Channels are
implemented as dynamically loaded libraries. The Channel element applies to a
particular Router and can only be used between Router elements.
Usage
Usage
<Channel.../> Channel element
Chapter 4. The log router daemon 123
Options
name The name of the channel (a unique name). This is required.
type The type of channel (such as LRD_FileOutput). This is required.
state The state of the channel (on or off). This is required.
path The directory and name of the input or output file.
filter The name of the filter to be used (output channels only). Only
one filter can be defined per output channel.
error Error Retry Timeout. The number of seconds to wait before
retrying on error. (output channels only). [default=2]
format The name of the format for this channel (LRD_FileOutput and
LRD_EmailOutput channels only). Value can be concise,
keyvalue, or verbose. [defaults: LRD_FileOutput=keyvalue;
LRD_EmailOutput=verbose]
Note: These three formats are the same as the pdosaudview
output formats.
max_files Maximum number of rollover files. When this number is
reached, the output file will grow without bound. A value of
zero means there is no maximum number of rollover files.
(LRD_FileOutput channels only). [default: 0]
rollover_size Maximum size (in bytes) of an output file. When an output file
reaches this size, a rollover is performed. A value of zero means
that the file will grow indefinitely. (LRD_FileOutput channels
only). [default=0]
delimiter Field delimiter value. This can be used to change the field
delimiter value for concise or keyvalue format (for this channel
only) from the default value of comma. (LRD_FileOutput and
LRD_EmailOutput channels only).
server The host name to send the record to (only for LRD_EmailOutput
and LRD_NetOutput channels).
port The port number on the server (only for LRD_EmailOutput and
LRD_NetOutput channels). [defaults: LRD_EmailOutput=25;
LRD_NetOutput=7136]
rebind Rebind Retry Timeout. The number of seconds to wait before
rebinding to the server after it has become unavailable (only for
LRD_EmailOutput and LRD_NetOutput channels). [defaults:
LRD_EmailOutput=60; LRD_NetOutput=300]
compress Whether to compress records (yes or no) (LRD_NetOutput
channels only). Records will be uncompressed on the server
machine. [default: no]
dn Distinguished Name of remote server (LRD_NetOutput channels
only).
124 Administration Guide
buffer
When destination is set to pdacld
The maximum sized message (in bytes) that will be
constructed by combining audit records into a large
buffer. Audit records are not split across buffers.
(LRD_NetOutput channels only). [default: 16384]
When destination is set to carsdb
The number of audit events to be sent to the Common
Auditing and Reporting Service server on each
network transfer (LRD_NetOutput channels only).
[default: 20]
flush_interval The maximum number of seconds an audit record will reside in
a buffer before being forwarded (LRD_NetOutput channels only).
A value of 0 indicates no limit. Defaults:
When destination is set to pdacld
1000
When destination is set to carsdb
2
queue_size The maximum number of audit records that can be queued
before blocking the requesting thread (LRD_NetOutput channels
only). A value of 0 indicates no limit. Defaults:
When destination is set to pdacld
1000
When destination is set to carsdb
100
hi_water Processing the input queue is scheduled regularly at the flush
interval. It is also triggered by the queue size reaching the high
water mark (LRD_NetOutput channels only). Defaults:
When destination is set to pdacld
Two-thirds of the queue size. If queue_size=0, default
is 100
When destination is set to carsdb
20
address E-mail address (LRD_EmailOutput channels only).
destination Specifies the remote destination of the audit records (pdacld or
carsdb) (LRD_NetOutput channels only) [default: pdacld]
serverURL Specifies the URL of the Common Auditing and Reporting
Service Web service that receives the audit records.
(LRD_NetOutput channels only) [default: no]
summarize Whether to summarize records (yes or no) (LRD_FileOutput
and LRD_EmailOutput, and LRD_NetOutput channels only)
[default: no]
time_interval The number of seconds within which similar audit records are
summarized (LRD_FileOutput, LRD_EmailOutput, and
LRD_NetOutput channels only) [default: 60]
shutdown_notify_only Whether to notify Tivoli Access Manager for Operating Systems
shutdown event (yes or no) (LRD_EmailOutput channel only)
[default: no]
user_name Specifies the user name to use to authenticate the client to the
Common Auditing and Reporting Service server. (LRD_NetOuput
channel only)
Chapter 4. The log router daemon 125
response_timeout Specifies the number of seconds that the client waits for a
response from the server (LRD_NetOutput channels only when
destination is set to carsdb) [default: 180]
numberEQThreads Specifies the number of event queue threads. (LRD_NetOutput
channels only when destination is set to carsdb) [default: 4]
numberCMThreads Specifies the number of cache manager threads. (LRD_NetOutput
channels only when destination is set to carsdb) [default: 4]
maxCacheFileSize Specifies the maximum cache file size (in bytes) before it is
rolled over. (LRD_NetOutput channels only when destination is
set to carsdb) [default: 5 megabytes]
maxCacheFiles Specifies the maximum number of cache files. (LRD_NetOutput
channels only when destination is set to carsdb) [default: 1000]
Examples
The following examples show an input channel and several output channels.
<!-- This is an input channel that will read using the base file specified
by the path -->
<Channel name="log_input" type="LRD_AuditInput" path="/var/pdos/audit/audit.log"
state="on" />
<!-- This is an output channel that will write data records to the directory
and file specified by the path. The format is the concise output of the
pdosaudview command.-->
<Channel name="fileout1" type="LRD_FileOutput" path="/var/pdos/pdoslrd/audit.out"
format="concise" state="on" />
<!-- This is an output channel that will write data records to e-mail. -->
<Channel name="mail1" type=LRD_EmailOutput" server="mailserv.tivoli.com"
port="25" [email protected] state="on"/>
<!-- This is an output channel that will write data records to the server
specified by server and port. The format is fixed for this destination
and cannot be changed. -->
<Channel name="netout-admin" type=LRD_NetOutput" server="toasty.ibm.com"
port="7136" state="on" />
Filters element
The log router control file can contain only one Filters element. All Filter
elements are contained within the Filters element. It has no options.
Usage
Usage
<Filters> Begin tag
</Filters> End tag
Options
None
Filter element
The Filter element is used to specify the conditions under which a particular
record will be included or excluded. A Filter element must contain at least one
Conditional element. All Filter elements are contained within the Filters
element. Only one Filter element can be defined per output channel.
126 Administration Guide
Usage
Usage
<Filter> Begin tag
</Filter> End tag
Options
name A unique filter name.
Examples
<Filters>
<!-- This is a filter with an include type Conditional element. The record will
be included if the value of the field "resource_type" is "Login" AND the value
of the field "view" is "D" (for Deny) -->
<Filter name="filter1">
<Conditional type="include">
<Field name="resource_type" value="Login" />
<Field name="view" value="D" />
</Conditional>
</Filter>
<!-- This is a filter with an exclude type Conditional element. The record will
be excluded if the value of "view" is "Trace". -->
<Filter name="filter2">
<Conditional type="exclude">
Field name="view" value="Trace" />
</Conditional>
</Filter>
</Filters>
Conditional element
A Conditional element specifies one set of conditions under which a Filter
element might be evaluated. A Filter element contains one or more Conditional
elements. The first Conditional element that evaluates as true determines whether
a record is included in the output. If a Conditional element of type include
evaluates as true, the record is included in the output. If a Conditional element of
type exclude evaluates as true, the record is excluded from the output.
For a Conditional element to evaluate as true, all of its Field elements must match
the record in question. That is, the field specified in the Field element must
contain the same value in the record as appears in the Field element.
Chapter 4. The log router daemon 127
If none of the Conditional elements in a Filter element evaluate as true, then the
disposition of the record is determined by the type of the last Conditional element
contained within the Filter element. If the type is include, the record is excluded.
If the type is exclude, the record is included.
Usage
Usage
<Conditional> Begin tag
</Conditional> End tag
Options
type "include" or "exclude"
Examples
<!-- include only records with resource_type=Login AND view=D
OR records with outcome=F -->
<Filter name="filter1>
<Conditional type="include">
<Field name="resource_type" value="Login" />
<Field name= "view" value="D" />
</Conditional>
<Conditional type="include">
<Field name="outcome" value="F" />
</Conditional>
</Filter>
Field element
The Field element is used to specify the fields to use when applying an output
filter. The name of the field is one of the log router field names listed in “Field
table” on page 133. The value of a Field element is case-sensitive. This element can
only be used between Conditional elements.
Usage
Usage
<Field.../> Field element
Options
name The name of the field. This is required.
value The value of field name which constitutes a match.
name2 The name of a second field. If the contents of field name equals
the contents of field name2, it is a match.
value_list The path name of a file containing a list of values (one per
line). If the value of the field specified by name is equal to any
of the values in the file, this is considered a match. A hashing
scheme is used to determine if there is a match.
Example
<!-- Field element used inside a Conditional element. -->
<!-- The value of a Field element is case-sensitive.-->
<!-- The record will be included if the value of field "view" is "D".-->
128 Administration Guide
<Conditional type="include">
<Field name="view" value="D"/>
</Conditional>
<!-- The record will be excluded if the value of the field "acc_name" is equal to
the value of the field "acc_eff_name". -->
<Conditional type="exclude">
<Field name="acc_name" name2="acc_eff_name" />
</Conditional>
Filter definitions
Following are several examples of log router filter definitions. The examples show
two types of Conditional elements (include and exclude), as well as the Field
elements options: value and name2. Some of these filters are contained in the set of
standard filters that is in the file /opt/pdos/etc/pdoslrd.xml.template.
Note: The audit log consolidation application supports a limited wildcard
capability on the value option of a Field element. You can use
value="*xyz", value="xyz*", or value="*xyz*", but not value="abc*xyz".
You can get the equivalent of abc*xyz by having two Field elements in the
Conditional element: one with value="abc*" and the other with
value="*xyz" You can use the question mark character (?) to match any
character, but you cannot use the question mark and asterisk (*) together.
Thus, value="a?b" matches "azb", "a1b", "aab", for example. You can have
multiple question mark characters in a single value (for example,
value="a?c?e?"). Wildcard characters are not supported on the name2 option
of a Field element. They are only supported in the value option.<!--Include only login denies -->
<Filter name="login-deny">
<Conditional type="include">
<Field name="resource_type" value="Login"/>
<Field name="view" value="D"/>
</Conditional>
</Filter>
<!--Include only logins as root -->
<Filter name="root-login>
<Conditional type="include">
<Field name="resource_type" value="Login"/>
<Field name="acc_name" value="root"/>
</Conditional>
</Filter>
<!--Include only non-root logins -->
<Filter name="non-root-login">
<Conditional type="exclude">
<Field name="acc_name" value="root"/>
</Conditional
<Conditional type="include">
<Field name="resource_type" value="Login"/>
</Conditional>
</Filter>
<!--Include only records where the accessor effective name is different from the
accessor name. This indicates a user has changed to another user at some point
in the past. This filter allows you to focus on all such activity. -->
<Filter name="su">
<Conditional type="exclude">
<Field name="acc_name" name2="acc_eff_name"/>
</Conditional>
</Filter>
Chapter 4. The log router daemon 129
<!--Include only records where an account has been locked; either following the
"three strikes and you’re out" rule or using administrative action. -->
<Filter name="account-locked">
<Conditional type="include">
<Field name="event_id" value="2"/>
</Conditional>
<Conditional type="include">
<Field name="event_id" value="3"/>
</Conditional>
</Filter>
<!--Include only file access failures in the /etc directory. -->
<Filter name="etc-file-failures">
<Conditional type="include">
<Field name="resource_type" value="File"/>
<Field name="view" value="D"/>
<Field name="sys_res_name" value="/etc/*" />
</Conditional>
</Filter>
<!--Include only records where a file has been marked untrusted. -->
<Filter name="file-untrust"
<Conditional type="include">
<Field name="event_id" value="22" />
</Conditional>
</Filter>
<!--Include only records where AMOS has entered isolation mode. -->
<Filter name="isolation"
<Conditional type="include">
<Field name="event_id" value="12" />
</Conditional>
</Filter>
<!--Include only records where a remote access attempt has failed due to Network
Incoming Policy. -->
<Filter name="incoming"
<Conditional type="include">
<Field name="resource_type" value="NetIncoming" />
<Field name="view" value="D" />
</Conditional>
</Filter>
Channels
The log router channels are specified in the log router control file
(/opt/pdos/etc/pdoslrd.xml). There is one input channel type, LRD_AuditInput,
and the following output channel types:
v LRD_FileOutput
v LRD_EmailOutput
v LRD_NetOutput
LRD_AuditInput
The LRD_AuditInput channel type reads the Tivoli Access Manager for Operating
Systems audit log and formats the audit records into a form that allows filtering to
be performed by the output channels.
There must be one and only one input channel specified in the log router control
file. The only input channel type currently supported is LRD_AuditInput. The
audit log consists of all files of the form audit.log* in the directory
/var/pdos/audit. The file audit.log is the latest file and all other files with names
130 Administration Guide
that start with audit.log are archived versions. When the audit.log file reaches a
certain size, it is rolled over or archived into a file of the form audit.log.YYYY-MM-DD-hh-mm-ss.
When the pdoslrd daemon is started, the input channel code looks for a file of the
form input_channel_name.lrp in the directory /var/pdos/pdoslrd, where
input_channel_name is the name of the input channel in the log router control file.
An example name could be input.lrp. If the file exists, it contains the timestamp
and uniqifier of the last record processed during a previous invocation of pdoslrd.
The input channel code will search the audit.log* files in /var/pdos/audit until it
finds an audit record with a timestamp and uniqifier that makes it later than the
values in the file input_channel_name.lrp. It starts reading audit records at this
record. This mechanism allows the pdoslrd daemon to be shut down and restarted
without losing its place in the audit log. If the input channel fails to find the file
input_channel_name.lrp, it starts reading the audit log at the first record of the
oldest file of the form audit.log*.
Note: The uniqifier is a Tivoli Access Manager for Operating Systems audit record
field. It is used to distinguish among audit records that have identical time
stamps. An audit record will have a nonzero uniqifier only if it was
generated during the same second as the previous audit record.
LRD_FileOutput
The LRD_FileOutput channel type performs filtering, formats records for output,
and sends records to a text file on the local host. The main use of this channel type
is to provide a real-time view of audit records. A system administrator who wants
to view the audit records as they are produced in as close to real time as is
possible can issue a tail –f command on the local file, and then view the audit
records as they are generated (with a slight delay). This is likely a practice that will
only be done temporarily to gauge the current audit output. It could be done:
v To track a particular event or group of events
v Prior to or just after making a change in the audit level
v To test the effect of various filters in the pdoslrd.xml file.
LRD_EmailOutput
The LRD_EmailOutput channel type performs filtering, formats records for output,
and sends records to the specified list of e-mail addresses. The main use of this
type of channel is to allow system administrators to monitor very specific audit
events that occur infrequently. It is expected that this type of channel be highly
filtered, meaning that only a few audit events actually get sent through e-mail. If
the channel is not highly filtered, the e-mail address might be overwhelmed with a
huge number of events, which could also slow the other output channels down.
The kind of filter used on this channel type is, therefore, very important. An
example of a filter that might be used here is one that filters out all events except
login denies, that is, audit events that were generated when a user attempted to
log in to a system and was denied access.
The following limitations apply to the LRD_EmailOutput channel type:
v When using the e-mail channel of the log router (pdoslrd) and you incorrectly
specify the e-mail delivery address in the /opt/pdos/etc/pdoslrd.xml file, the
log router daemon is unable to determine that e-mail is not deliverable to that
address. The log router daemon will start successfully and will attempt to send
e-mail to that address, but no errors will be detected. To ensure proper
Chapter 4. The log router daemon 131
operation, you should not rely on the log router to verify the address, but
should instead do a test run to verify that e-mail can be properly sent and
received.
v If the log router daemon cannot establish a connection with the mail server after
initiation, then the events sent to the specified e-mail address will be lost. It is
recommended that you turn on an additional LRD_FileOutput channel
whenever an LRD_EmailOutput channel is turned on. It is also recommended
that you specify the same set of filters for both of these channels. By doing this,
you can save the events in the event that the mail server is down.
LRD_NetOutput
The LRD_NetOutput channel type performs filtering, formats records for output,
and sends records to either the authorization server (pdacld) or to the Common
Auditing and Reporting Service database.
The LRD_NetOutput channel provides one end of the communication from the
Tivoli Access Manager for Operating Systems endpoint to the remote host is the
Tivoli Access Manager authorization server (pdacld) or the host running the
CommonAudit Web service. The audit log consolidation functionality refers to one
or more clients sending audit events to the pdacld process or Common Auditing
and Reporting Service database for archival purposes. The functionality is
performed on clients by having an LRD_AuditInput input channel and an
LRD_NetOutput output channel, which sends formatted audit records to one of the
following destinations:
v The pdacld process using the Tivoli Access Manager remote logging APIs. On
the authorization server, the collection function is performed by the Tivoli Access
Manager remote logging services available through the authorization server. This
collection requires an entry under the [aznapi-configuration] stanza in the file
/opt/PolicyDirector/etc/ivacld.conf similar to the following:
[aznapi-configuration]
logcfg = remote.channel_name:file path=/var/PolicyDirector/pdacld/amos_collection
where channel_name is the name of the LRD_NetOutput channel on the clients
(for example, netout-admin).
In general, the authorization server receives audit records from several clients
and stores them in a single collection file. There is, however, a facility for the
server to store records from each client into a separate collection file. To enable
this facility, ensure that the host name for each client is in the ivacld.conf file as
shown in the following example:
[aznapi-configuration]
logcfg = remote.channel_name.hostname1:file \
path=/var/PolicyDirector/pdacld/hostname1/amos_collection
logcfg = remote.channel_name.hostname2:file \
path=/var/PolicyDirector/pdacld/hostname2/amos_collection
In this example, records from client hostname1 will be stored in one file and
records from client hostname2 will be stored in another.
If the authorization server is being used solely to receive audit records, then the
following line should be included in the ivacld.conf file under the
[aznapi-configuration] stanza:
mode = remote
Including this line prevents the authorization server from receiving Tivoli Access
Manager database replicas.
v Common Auditing and Reporting Service
The Common Auditing and Reporting Service event server using the Common
Auditing and Reporting Service C APIs. On the event server, the collection
132 Administration Guide
function is performed by the CommonAudit Web service, which in turn routes
events through the Common Event Infrastructure framework to the XML data
store. For additional information, see the IBM Tivoli Access Manager for e-business:
Auditing Guide.
Log router audit record fields
The log router audit record fields include those fields that can be:
v Displayed when output is directed to a local file
v Written to a collection file
v Used in filter definitions
Supported fields
The log router is compatible with the current Tivoli Access Manager for Operating
Systems auditing code. The current Tivoli Access Manager for Operating Systems
audit.log format is preserved. The key-value, concise, and verbose formats of the
log router are the same as the pdosaudview formats.
The set of audit record fields supported by the log router includes the following:
v All the fields in the concise format of the pdosaudview command. These are the
same as in the key-value format. This means all the fields in the three audit
record types: general, trace, and logout are included. These record types are
described in Chapter 7, “Auditing,” on page 237.
v The host_name field. This is the name of the host that generated the audit record.
v The local domain name.
Supported field values
Several audit record fields have a verbose value and a concise value or key-value
when displayed by the pdosaudview command. For example, the verbose values
for the audit_outcome field are Success and Failure, whereas the concise value or
key-value are S and F.
All of the values needed for the concise and key-value formats are supported. All
of the verbose values are supported except for the event_id and qualifier fields,
which are in numeric form. The numeric values for these two fields are described
in Chapter 7, “Auditing,” on page 237.
Supported formats
The supported formats are as follows:
v Concise format (of the pdosaudview command).
v Key-value format (of the pdosaudview command).
v Verbose format (of the pdosaudview command).
v Network output format. This consists of the fields and values of the concise
format plus the host name field.
v E-mail output format. This is the same as the pdosaudview verbose format.
Field table
The following table shows all of the fields and values supported by the log router.
v The first column shows the field name defined in Chapter 7, “Auditing,” on
page 237.
Chapter 4. The log router daemon 133
v The second column shows the name used by the log router. The log router field
names are used in Field elements.
v The third column shows the name of the field in the key-value format. These
names can also be used in Field elements.
v The fourth column shows the formats that use the field.
C The field is used by concise (and key-value).
E The field is used by the e-mail format (Channel type = LRD_EmailOutput).
N The field is used by the network output format (Channel type =
LRD_NetOutput).
Audit record field heading Log router field name Key-value field
name
Used by
--- host_name --- E N
Local Domain local_domain LD E N
Timestamp time_stamp TS C E
Audit Event Identifier event_id E C E N
Audit View view V C N
Audit View view_verb --- E
Audit Reason reason R C N
Audit Reason reason_verb --- E
Audit Resource Type resource_type RT C E N
Accessor Name acc_name AN C E N
Accessor Effective Name acc_eff_name AEN C E N
Audit Action action A C E N
Audit Permissions permissions P C N
Audit Permissions permissions_verb --- E
Audit Qualifier qualifier Q C E N
Policy Branch Name branch_name PBN C E N
Protected Object Name prot_obj_name PON C E N
System Resource Name sys_res_name SRN C E N
Surrogate Name sname SN C E N
Network Remote Host
Identifier
net_rem_host_id NRH C E N
Network Protocol net_protocol NP C E N
Network Service net_service NS C E N
Login Location Identifier login_location_id LL C E N
Accessor Processor ID accessor_pid APID C E N
*Running Program Protected
Name
run_prog_prot_name RPPN C E N
*Running Program System
Resource Name
run_prog_sys_name RPSN C E N
Sudo Command and
Arguments
sudo_cmdargs SC C E N
Sudo User Name sudo_user SU C E N
Sudo Flags sudo_flags SF C E N
Additional Parameters param AP C E N
134 Administration Guide
Audit record field heading Log router field name Key-value field
name
Used by
TCB Changed Data Attr
Flags
chg_attr_flags CDAF C E N
Policy Epoch policy_epoch PE C E N
Policy Version Number policy_version PVN C E N
Audit Outcome outcome O C N
Audit Outcome outcome_verb --- E
Audit Fail Status fail_status FS C E N
Audit Uniqifier uniqifier UQ C E N
*Protected Resource
Specification
prot_res_spec PRS C E N
*Accessed Resource
Specification
acc_res_spec ARS C E N
* The audit record fields “Running Program Protected Name” and “Running Program
System Resource Name” are available when you are viewing general audit records; the
fields “Protected Resource Specification” and “Accessed Resource Specification” are
available when you are viewing trace audit records.
Encoded field values
Field Possible values
event_id This is a decimal number. The meaning of each number is listed in
Table 69 on page 257.
view This is a single character, which will be one of the following:
P – permit
D – deny
A – admin
I – info
T – trace
W – warning
reason This is a decimal number from 1 to 5:
1 – global audit
2 – resource audit
3 – global warning
4 – resource warning
5 – user audit
outcome This is one character:
S – success
F – failure
Chapter 4. The log router daemon 135
Field Possible values
resource_type This is one of the following strings:
Azn
Process
TCB
Cred
Policy
File
Health
Login
Logout
TraceExec
TraceFile
Password
NetIncoming
NetOutgoing
Surrogate
Sudo
action This is one of the following strings:
Add
Apply
CertLife
Change
Check Access
Delete
Disable
Enable
Heartbeat
Isolated
Login
Logout
Not Isolated
Register
Retrieve
Start
Stop
Trace
Trust
Untrust
qualifier This is a decimal number. The meaning of each number is listed in
“Audit event identifiers” on page 262.
136 Administration Guide
Field Possible values
Permissions This is a string of characters (for example, rwx).
r – read
w – write
x – execute
o – change ownership
D – change directory
p – change permission
R – rename
N – create
d – delete
U – utime
K – kill
L – login
C – connect
G – surrogate
l – readdir
T – traverse
Log router output formats
There are three log router output channels:
v Local file output: LRD__FileOutput
v E-mail Output: LRD__EmailOutput
v Network output: LRD__Output
Local file output—LRD_FileOutput
When records are routed to a local file (Channel type= LRD_FileOutput), the user
can specify the output format to be concise, keyvalue, or verbose. These are the
same as the concise, keyvalue, and verbose formats supported by the pdosaudview
command.
E-mail output—LRD_EmailOutput
When records are routed to e-mail (Channel type LRD_EmailOutput), the user can
specify the output format to be concise, key-value, or verbose. One e-mail message
is sent for each audit record. It is expected that e-mail output will be highly
filtered to reduce the number of audit records sent. For example, an administrator
might select on only denies to be sent to e-mail. The following is an example of
e-mail output:
Subject: audit record notification
The following audit record was sent by the log router daemon on host swing
in local domain Default:
Timestamp Mon 29 Oct 2001 04:35:45 PM CST
Audit Event An authorization decision was made.
Audit View Permit
Audit Reason Global Audit
Audit Resource Type File
Accessor Name root
Accessor Effective Name root
Audit Action Check access
Audit Permissions read
Audit Qualifier All resource policy checks permitted access.
Policy Branch Name bvt
Chapter 4. The log router daemon 137
Protected Object Name File/opt/pdos
Systems Resource Name /usr/lib/liblpm.so
Accessor Process ID 1233
Running Program System Resource Name /usr/sbin/in.telnetd
Audit Outcome Success
Audit Uniqifier 1
Network output—LRD_NetOutput
When records are written to a remote host, the output channel used is
LRD_NetOutput. The pdacld daemon on the server machine will write the records
it receives on the network to a collection file without modifying them in any way.
Thus, the network output record format is identical to the collection file format.
The fields of the collection file format include the host_name field, the
local_domain field, and all the fields in the pdosaudview concise format with one
exception: the timestamp field in the collection file format is in a language neutral
format, while the timestamp field of the pdosaudview concise (and key-value and
verbose) format is dependent on the local code page. All of the fields of the
network output record are converted to UTF-8 before being sent over the network.
The number of clients that a single authorization server can service depends on
many variables. The level of auditing being performed is very important. If only
login denies are being sent, then the server should be able to service a very large
number of clients. If each client is generating a very large number of audit records,
then the server might be able to handle only a few clients. Of course, a great deal
also depends on the relative power of the machines involved. It is assumed that
authorization server machines will be high-end machines when there is
considerable auditing being done or a large number of clients are being serviced.
When events are sent to the XML data store, the LRD_NetOutput channel first
sends the events to the CommonAudit Web service. The Web service forwards
these events through the Common Event Infrastructure framework to the XML
data store. For more information, see the IBM Tivoli Access Manager for e-business:
Auditing Guide.
File rollover
The Channel element has a rollover_size option. When an output file reaches this
size (in bytes), a rollover will be performed. This applies only to LRD_FileOutput
channels. A value of zero means the file will grow indefinitely. File roll overs are
performed in the same manner as the audit.log is done. That is, the file will be
renamed, and the new name will have the date and time as a suffix. For example,
an output file named auditout would be renamed to something like
auditout.2002-02-28-16-02-33.
The Channel element also has a max_files option. This option indicates the
maximum number of rollover files that will be generated. If this number is
reached, the last file is not rolled over, but grows without bound. If the max_files
option is zero, there is no limit on the number of rollover files.
Collection files can also be rolled over. This option is specified (in bytes) in the
ivacld.conf file on the authorization server, as shown in the following example:
logcfg = remote.netout.aushat12:File path = /home/amos/collection,rollover_size=
50000000
Note: This option must be entered as a single line.
138 Administration Guide
Output compression
The Channel element has a compress option. This determines whether the output
is compressed or not. This applies only to LRD_NetOutput channels that are
configured to pdacld. If the compress option is selected, the records will be
uncompressed on the authorization server before being written to the collection
file. Thus, the compress option reduces the amount of data sent over the network,
but it does not affect the contents of the collection file.
Chapter 4. The log router daemon 139
140 Administration Guide
Chapter 5. Administrative tasks
This chapter explains the administrative tasks required to manage the Tivoli Access
Manager for Operating Systems runtime and illustrates performing those tasks
using the command line. It describes:
v Establishing a consistent user name space to ensure that the appropriate
mapping exists between the native user registries and the Tivoli Access Manager
user registry
v Ongoing administration of Tivoli Access Manager for Operating Systems
including managing its processes, the Trusted Computing Base (TCB), the
credentials cache, and the host name lookaside database
v Monitoring the effect of an authorization policy on a system, and backing up
and restoring the Tivoli Access Manager for Operating Systems configuration
and database files
This chapter provides an overview of the administrative tasks. See Chapter 8,
“Commands,” on page 269 for detailed information about each command. Tivoli
Access Manager for Operating Systems administrative tasks also can be performed
from the Tivoli desktop. See Chapter 6, “Using the Tivoli desktop to perform
management tasks,” on page 175 for details.
Administering Tivoli Access Manager for Operating Systems consists of the
following tasks:
v “Defining runtime administrators and auditors”
v “Establishing a consistent user name space” on page 142
v “Configuring additional branches” on page 145
v “Tuning the configuration” on page 146
v “Obtaining membership reports” on page 148
v “Managing processes” on page 149
v “Verifying policy” on page 152
v “Managing the Trusted Computing Base” on page 156
v “Managing login activity and password management policy enforcement” on
page 160
v “Managing credentials” on page 163
v “Determining accessor identity” on page 165
v “Configuring and managing the host name lookaside database” on page 167
v “Backing up and restoring configuration files and databases” on page 168
v “Obtaining entitlement report” on page 169
v “Viewing policy” on page 172
Defining runtime administrators and auditors
A Tivoli Access Manager for Operating Systems runtime administrator is
authorized to perform administrative tasks to manage the runtime environment. To
be a runtime administrator, you must be a member of both of the following
groups:
v osseal-admin group in the Tivoli Access Manager user registry
v osseal group in UNIX
© Copyright IBM Corp. 2000, 2005 141
A Tivoli Access Manager for Operating Systems auditor is authorized to perform
audit-related tasks. To be an auditor, you must be a member of both of the
following groups:
v osseal-auditors group in the Tivoli Access Manager user registry
v ossaudit group in UNIX
Auditors are authorized to run the pdosaudview command and access the files in
the /var/pdos/audit and /var/pdos/tec directories.
It is recommended that all runtime administrators be made auditors as well.
If Tivoli Access Manager is configured to multiple Active Directory domains, the
Tivoli Access Manager for Operating Systems osseal-admin and osseal-auditors
groups will be named osseal-admin@domain_name and osseal-auditors@domain_name, respectively, where domain_name is the name of the domain
to which Tivoli Access Manager for Operating Systems is configured. For example,
if Tivoli Access Manager for Operating Systems is configured to the tivoli.com
domain, [email protected] and [email protected] would be the
group names.
Establishing a consistent user name space
When setting up a Tivoli Access Manager for Operating Systems environment, you
must understand the relationship between the native user registry used by the
UNIX operating system and the Tivoli Access Manager user registry.
If the user registry is maintained by Active Directory, all Tivoli Access Manager for
Operating Systems users and groups must be in the same Active Directory domain.
When the Tivoli Access Manager environment contains multiple Active Directory
domains, a specific Active Directory domain must be specified during the initial
configuration of Tivoli Access Manager for Operating Systems. All Tivoli Access
Manager for Operating Systems clients that are configured to the same policy
server must be configured to the same Active Directory domain.
When acquiring the credentials needed to make authorization decisions, Tivoli
Access Manager for Operating Systems maps a native user ID to a Tivoli Access
Manager user. The user’s native user name is obtained from the native user
registry using its numeric ID. The native user name is mapped directly to a Tivoli
Access Manager user of the same name. The Tivoli Access Manager user defines
the primary user information and group membership. This identity is used in
Tivoli Access Manager for Operating Systems authorization decisions.
Note: The group membership in the native user registry is not used in Tivoli
Access Manager for Operating Systems authorization decisions.
The mapping of names in the native user registry to names in the Tivoli Access
Manager user registry depends of whether the directory server is an LDAP server,
an Active Directory server using a single domain, or an Active Directory server
using multiple domains. When the directory server for the Tivoli Access Manager
user registry is an Active Directory server with multiple domains, the name in the
native user registery is mapped to a name in the Tivoli Access Manager user
registry with the name of the Active Directory domain appended. For example,
when Tivoli Access Manager for Operating Systems is configured to use the
domain1.com Active Directory domain, mapping marc from the native user registry
to the Tivoli Access Manager user registry becomes [email protected].
142 Administration Guide
Table 59 shows the mapping of names in the native user registry to the Tivoli
Access Manager user registry. Assume that Tivoli Access Manager for Operating
Systems is configured to the domain1.com Active Directory domain when using
multiple domains.
Table 59. Mapping of names in the native user registry to the Tivoli Access Manager user
registry
Name in native user
registry
Name in LDAP user
registry
Name in Active
Directory user
registry with a
single domain
Name in Active
Directory user
registry with
multiple domains
riley riley riley [email protected]
moose moose moose [email protected]
mandy mandy mandy [email protected]
If there is no Tivoli Access Manager user that corresponds to the user’s native user
name, the user is treated as unauthenticated when making authorization decisions.
Because of this relationship, all systems that share the same Tivoli Access Manager
user registry should use a consistent and distinct native user name for each user in
the environment. “The UNIX identity and its relationship to the Tivoli Access
Manager user identity” on page 3 gives an example of this relationship. The
pdosrgyimp command assists in the task of populating the Tivoli Access Manager
user registry. This task requires careful planning.
Identifying users and groups
Consider how you will define groups. Aligning groups with job functions, projects,
or roles is useful for establishing ACLs using group entries instead of individual
user entries. This helps simplify the policy definition and management. It also aids
in efficient evaluation of the policy by Tivoli Access Manager for Operating
Systems.
First, identify which UNIX users and groups should be included in the Tivoli
Access Manager user registry. This step depends on the policy decisions you make
for a particular environment. For instance, you might set up the policy in such a
way that objects are protected through access controls that restrict or allow access
based on a few specific user credentials and unauthenticated credentials for most
other users. In this case, only the specific users of interest need to have Tivoli
Access Manager entries. All other users can run with unauthenticated credentials.
Or, you might set up a more selective policy to restrict access to specific users and
groups. In this case, most, if not all, users need to have Tivoli Access Manager
entries.
Identifying duplicate user names
Set up the registry:
1. Look at all of the machines that will belong to a Tivoli Access Manager domain.
2. Identify duplicate user or group entries across multiple machines.
3. Resolve any duplicate entries. The duplicates might represent the same person
or group.
For example, user maggie on machine A might represent the person Maggie Smith
and user maggie on machine B might also represent the person Maggie Smith.
Because user maggie represents the same person on both machines, only one Tivoli
Chapter 5. Administrative tasks 143
Access Manager entry is needed. In other cases, the duplicates represent different
users or groups. For example: user riley on machine A represents the person Riley
Smith and user riley on machine B represents the person Riley Jones. Because the
user riley represents two different people, two Tivoli Access Manager entries are
needed. “The UNIX identity and its relationship to the Tivoli Access Manager user
identity” on page 3 shows another example of duplication. To resolve this
duplication, the UNIX name of one of the users must be changed.
Using pdosrgyimp
After identifying the UNIX users and groups to import, use the pdosrgyimp
command on each machine that has UNIX registry users and groups to be
imported.
The pdosrgyimp command creates user entries for all UNIX users and groups
found in the UNIX registry. Any newly created groups are also populated with the
user entries corresponding to the members of the UNIX group. The syntax is as
follows:
pdosrgyimp -S o=tivoli -l login-id
If almost all of UNIX users or groups are to be imported, you can create an
exclude file with a list of the users and groups to exclude. In this case, all UNIX
users and groups found in the UNIX registry are imported except those listed in
the exclude file. The syntax is as follows:
pdosrgyimp -S o=tivoli -l login-id -E excludefilename
If only a few UNIX users or groups are to be imported, you can create an include
file with a list of the users and groups to include. In this case only the UNIX users
and groups listed in the include file are imported. The syntax is as follows:
pdosrgyimp -S o=tivoli -l login_id -I includefilename
Use the –u or –g options to import UNIX users and groups separately. Take care
when importing groups separately from users. When groups are populated, an
attempt is made to add all non-excluded users to the group. In this case you can
specify both the include and exclude files. List the group in the include file. List
the users that are to be left out of the group in the exclude file. The syntax is as
follows:
pdosrgyimp -S o=tivoli -l login_id -I includefilename -E excludefilename
The pdosrgyimp command creates two files. The file pdosrgyimp.import contains a
list of pdadmin commands that were successfully executed. The file
pdosrgyimp.conflict contains a list of pdadmin commands that failed.
Most failures occur because an entry already exists or because the Tivoli Access
Manager server is down. The pdosrgyimp.conflict file can be used to aid in
conflict resolution. Instead of running the pdosrgyimp command again, modify the
text in the pdosrgyimp.conflict file. Then pipe it directly to the pdadmin
command:
pdadmin -a login_id -p password < pdosrgyimp.conflict
The –n option specifies that the pdosrgyimp command should generate a list of
pdadmin commands without running them. Use this option to test what actions
would be taken before you do the import. The list of pdadmin commands is saved
in the pdosrgyimp.import file.
See “pdosrgyimp” on page 328 for a description of this command.
144 Administration Guide
Configuring additional branches
After the initial configuration, use the pdosbranchcfg command to configure a
machine to policy branches in addition to the initial branch. The pdosbranchcfg
command adds branches to, deletes branches from the configuration, lists the
configured branches, and reorders the precedence of the configured branches. You
cannot delete the initial branch from the configuration, but you can change its
precedence.
The branch configuration information is stored in the branch.conf configuration
file. Do not edit this file. Manually editing this file results in an inconsistent branch
configuration. Any change to branch configuration after the initial configuration
should be done with the pdosbranchcfg command. Changes in the branch
configuration will not be reflected in the Tivoli Access Manager for Operating
Systems daemons until they are restarted.
Adding branches
For example, during the initial configuration the machine is configured to the
/OSSEAL/Servers policy branch and you want to configure it to the /OSSEAL/DB2
and the /OSSEAL/LDAP policy branches, you would enter the following commands:
pdosbranchcfg -add DB2 –admin_name sec_master –admin_pwd password
pdosbranchcfg –add LDAP –admin_name sec_master –admin_pwd password
After you run these commands, the machine is configured to three branches with
the policy enforced in the following precedence order:
1. Servers
2. DB2
3. LDAP
Listing branches and precedence
To view the configuration of the branches use the following pdosbranchcfg
command:
pdosbranchcfg –list
Which results in the following output:
1-Servers, 2-DB2, 3-LDAP
Changing precedence order
If you want to change the precedence such that the /OSSEAL/LDAP branch is of
higher precedence than the /OSSEAL/DB2 branch but still lower than the
/OSSEAL/Servers branch, you can do so using either of the following
pdosbranchcfg commands:
pdosbranchcfg –move LDAP –pos 2
pdosbranchcfg –move DB2 –pos 3
Deleting branches
If you want to unconfigure the machine from the /OSSEAL/LDAP branch, you can do
so using the following pdosbranchcfg command:
pdosbranchcfg –delete LDAP –admin_name sec_master –admin_pwd password
Any additional branch that was configured will be unconfigured when Tivoli
Access Manager for Operating Systems is unconfigured.
Chapter 5. Administrative tasks 145
Tuning the configuration
Use the pdoscfg command to reconfigure certain Tivoli Access Manager for
Operating Systems configuration attributes after the initial configuration. Changes
made using the pdoscfg command take effect the next time Tivoli Access Manager
for Operating Systems is stopped and restarted. You can enable or disable
autostart, global warning, limitation of network ACL inheritance, the use of a host
name lookaside database and ID-to-name mapping. You can tune credentials cache
management and monitor the Trusted Computing Base. You can also modify how
the Tivoli Access Manager for Operating Systems daemons handle the log files.
The global audit level can be set. You can refresh the Certification Authority (CA)
certificate of the directory server, if necessary.
You can also use the pdoscfg command to delete attributes from the configuration
files so that the daemons use default values on the next restart. You cannot change
the initial policy branch name or the suffix. To change these attributes, you must
use the pdosucfg command to unconfigure Tivoli Access Manager for Operating
Systems and then configure it again. “pdoscfg” on page 280 lists all the command
options.
Tivoli Access Manager for Operating Systems configuration information is kept in
a set of configuration files, one for each daemon. The files are named
daemon_name.conf. Another file, containing common configuration data is named
osseal.conf. The configuration files have stanzas containing sets of attribute=value
pairs. Table 60 and the following tables show which files contain which stanzas,
and how the stanza attributes map to the pdoscfg command line options. You can
enable or disable autostart, global warning, limitation of network ACL inheritance,
the use of a host name lookaside, and ID-to-name mapping. If an attribute is
missing from a stanza, the default value is used.
Table 60. Attribute equivalents of pdoscfg options in osseal.conf
Stanza Attribute Option
[audit] level –audit_level
permit_actions –audit_permit_actions
deny_actions –audit_deny_actions
[authorization] warning –warning
[cache] dns –dns
uid –uid
[policy] branch –branch
[ffdc] capture –ffdc_capture
[registry] AD-domain –AD_domain
Table 61. Attribute equivalents of pdoscfg options for pdosd.conf
Stanza Attribute Option
[ldap] ssl-certificate –ldap_ssl_cacert
[pdoscfg] autostart –autostart
login-policy –login_policy
net-acl-limited –net_ACL_limited
admin-name –admin_name
suffix –suffix
146 Administration Guide
Table 61. Attribute equivalents of pdoscfg options for pdosd.conf (continued)
Stanza Attribute Option
[pdosd] kmsg-handler-threads –kmsg_hnd_threads
log-entries –pdosd_log_entries
logs –pdosd_logs
init-wait-minutes –pdosd_init_wait
[credentials] admin-cred-refresh –admin_cred_refresh
cred-hold –cred_hold
user-cred-refresh –user_cred_refresh
critical-cred-refresh –critical_cred_refresh
cred-response-wait –cred_response_wait
critical-cred-group –critical_cred_group
[policy] refresh-interval –refresh_interval
[registry] registry-ssl-cacert –registry_ssl_cacert
[ssl] ssl-listening-port –ssl_listening_port
local-domain –local_domain
[tcb] interval –tcb_interval
max-checksum-file-size –tcb_max_file_size
monitor-threads –tcb_monitor_threads
tcb-nocrc-on-exec –tcb_nocrc_on_exec
tcb-ignore-ctime –tcb_ignore_ctime
Table 62. Attribute equivalents of pdoscfg options in pdosauditd.conf
Stanza Attribute Option
[pdosauditd] log-entries –pdosauditd_log_entries
audit-logflush –audit_logflush
logs –pdosauditd_logs
audit-logsize –audit_log_size
Table 63. Attribute equivalents of pdoscfg options in pdoswdd.conf
Stanza Attribute Option
[pdoswdd] log-entries –pdoswdd_log_entries
logs –pdoswdd_logs
Table 64. Attribute equivalents of pdoscfg options in pdoslpmd.conf
Stanza Attribute Option
[pdoslpmd] max-pending-logins –pdoslpmd_max_pending_logins
failure-audit-seconds –pdoslpmd_failure_audit_seconds
log-entries –pdoslpmd_log_entries
logs –pdoslpmd_logs
Chapter 5. Administrative tasks 147
Table 65. Attribute equivalents of pdoscfg options in pdoslrd.conf
Stanza Attribute Option
[pdoslrd] log-entries –pdoslrd_log_entries
logs –pdoslrd_logs
lrd-admin-name –lrd_admin_name
lrd-local-domain –lrd_local_domain
You can use both the pdoscfg and pdosctl commands for some configuration
actions. The pdoscfg command is used to modify the configuration files. These
modifications do not take effect until the next time Tivoli Access Manager for
Operating Systems is stopped and restarted.
The pdosctl command dynamically changes Tivoli Access Manager for Operating
Systems while it is running. The changes take effect immediately and are not
persistent when you restart. The following sections show both the pdoscfg options
and the pdosctl options where appropriate.
Limiting ACL inheritance for a network policy
The limitation of network access ACL inheritance can be enabled, allowing for
more efficient authorization decisions on network accesses. Enabling this feature
limits the inheritance of ACLs that are attached to resources in the OSSEAL object
space for network accesses, similar to file accesses. In the case of file accesses, there
is an implicit permissive ACL attached at /OSSEAL/policy-branch/File at all times.
In the case of network accesses, if the limited network access ACL inheritance is
enabled, then there are implicit permissive ACLs attached at the
/OSSEAL/policy-branch/NetIncoming and /OSSEAL/policy-branch/NetOutgoing
resources in the OSSEAL object space.
This feature can be enabled using the pdoscfg command with the
–net_ACL_limited option:
#pdoscfg –net_ACL_limited on
or disabled using the option:
#pdoscfg –net_ACL_limited off
Tivoli Access Manager for Operating Systems administrators should be aware that
enabling this feature means that any ACLs which are attached at
/OSSEAL/policy-branch/NetIncoming and /OSSEAL/policy-branch/NetOutgoing will
no longer apply to network accesses. Another effect of enabling this feature is that
network accesses to which no specific policy applies (below these points in the
OSSEAL object space) will not generate audit permit events, as they did in prior
releases due to access control inherited from /OSSEAL/policy-branch/NetIncoming
and /OSSEAL/policy-branch/NetOutgoing.
Obtaining membership reports
The Tivoli Access Manager for Operating Systems configuration includes the
creation of a unique user registry group for each new policy branch. Each
subsequent machine that is configured into a policy branch is added as a member
of the user registry group for that policy branch. If a machine is configured to
more than one policy branch, it will be included in the membership list of the
initial branch and each additional branch.
148 Administration Guide
You can obtain a branch membership report for each Tivoli Access Manager for
Operating Systems machine by using the pdadmin command or Web Portal
Manager.
Listing machines in a policy branch
To list which machines are subscribed to a specific policy branch, use the pdadmin
group show-members command. When policy branch groups are created in the
user registry, their names are not case-sensitive. These groups are used to maintain
the branch membership information (group name of pdosd-branch/policy-branch
in the user registry).
Note: Assume that there are two Tivoli Access Manager for Operating Systems
machines of the same name but different capitalization (test and Test).
Each machine is a different object in the object space (OSSEAL/test and
OSSEAL/Test, respectively) that you can use to enforce policy. Because the
group name in the user registry is not case-sensitive, there is only one group
name in the user registry (pdosd-branch/test) that maintains the
informational-only copy of branch membership.
If you attempt to list the members of the test branch, the results include
members of both the test and Test branches. To avoid this problem, ensure
that the names for all branches are unique regardless of capitalizations.
To list which machines are subscribed (members of) the Servers policy branch,
enter the following command:
pdadmin> group show-members pdosd-branch/servers
Listing policy branches for a machine
To determine the policy branches to which a specific machine is configured, enter
the following command:
pdadmin> user show-groups pdosd/hostname
In the output, look for any group called pdosd-branch/policy-branch to find the
branches.
Managing processes
This section tells how to start, stop, and monitor Tivoli Access Manager for
Operating Systems processes.
Starting Tivoli Access Manager for Operating Systems
Tivoli Access Manager for Operating Systems can be started manually from the
command line or automatically at system boot time. You should start Tivoli Access
Manager for Operating Systems automatically at system boot time to ensure proper
enforcement of an authorization policy.
By default, Tivoli Access Manager for Operating Systems is configured to start
automatically at system boot time when it is initially configured on a system. You
can disable automatic start by specifying –autostart off on the pdoscfg command
line during initial configuration.
Starting automatically at boot time
To start automatically at boot time, enter:
pdoscfg –autostart on
Chapter 5. Administrative tasks 149
When the system reboots, Tivoli Access Manager for Operating Systems starts
automatically.
Starting manually from the command line
To start Tivoli Access Manager for Operating Systems from the command line,
enter:
rc.osseal start
Note: If this is the first time that Tivoli Access Manager for Operating Systems is
started after a system reboot, this command must be run as root to ensure
that the kernel extension loads correctly.
Disabling automatic start at boot time
To disable automatic startup at boot time, enter:
pdoscfg –autostart off
When the system reboots, Tivoli Access Manager for Operating Systems will not
start automatically.
Stopping Tivoli Access Manager for Operating Systems
You can stop all Tivoli Access Manager for Operating Systems daemons or select
Tivoli Access Manager for Operating Systems daemons from the command line.
Stopping all daemons
To stop all processes and deactivate the kernel extension on all platforms except
AIX, enter:
rc.osseal stop
On all platforms other than AIX, shutdown scripts are placed in the rc*.d
directories to stop the Tivoli Access Manager for Operating Systems daemons
when the system is shut down. The scripts stop the daemons by invoking the
following command:
rc.osseal stop
The AIX implementation of the rc*.d scripts and run levels differs from the other
platforms. Tivoli Access Manager for Operating Systems cannot use these scripts to
shut down an AIX system.
On AIX, the daemons are killed in a random order when the system is shut down.
AIX administrators can either issue the rc.osseal stop command before shutting
down the system or set up an /etc/rc.shutdown script that calls rc.osseal stop.
Tivoli Access Manager for Operating Systems does not set up a /etc/rc.shutdown
script, because it is free format script. The script could be as simple as the
following sample:
#!/bin/ksh
/opt/pdos/bin/rc.osseal stop
Stopping select daemons
To stop select daemons, from the command line, use the pdosctl command with
the –k option. For example, to stop the pdosauditid daemon, enter:
pdosctl -k pdosauditd
The output is:
pdosauditd shutdown
150 Administration Guide
To restart the daemon, enter:
rc.osseal start
Checking daemon status
Use the pdosctl command to check whether the pdosd, pdosauditd, pdoswdd,
pdoslpmd, and pdoslrd daemons are running. The –s option, when specified with
no arguments, displays the status of each of the daemons. Use the –s option
followed by a daemon name to display the status of a single daemon. You can use
the –s option multiple times on a single command line.
You can use the –q option with the –s option. The –q option suppresses the
messages generated by the –s option and sets the return code to 0 on success and 1
if any of the queried daemons are down. The –q option makes it simpler to use
pdosctl in a shell script.
Enter:
pdosctl -s
The output is:
pdosd is running normally
pdoswdd is running normally
pdosauditd is running normally
pdoslpmd is running normally
pdoslrd is running normally
If the pdosd daemon is running in isolation mode, the output is:
pdosd is running under abnormal conditions
isolated from the user registry
pdoswdd is running normally
pdosauditd is running normally
pdoslpmd is running normally
pdoslrd is running normally
Note: The pdosctl command does not affect the pdostecd daemon.
Daemon log files
Each Tivoli Access Manager for Operating Systems daemon maintains a log file
that records significant events and error conditions. The records written to the log
files contain a UTC timestamp, information identifying the Tivoli Access Manager
for Operating Systems code logging the message, the message classification, and
the message text. The message classification indicates the severity of the message
and is NOTIFY, WARNING, ERROR, or FATAL. These log files are in the directory
/var/pdos/log and are named msg__daemon_name.log. The log files can be useful
for diagnostic purposes. For more information about using log files, see the IBM
Tivoli Access Manager for Operating Systems: Problem Determination Guide.
Use the pdoscfg command to tune how daemons handle their log files. For the
supported daemon (pdosd, pdosauditd, pdoswdd, pdoslpmd, and pdoslrd), you
can specify the number of entries that can be written to the log file before the log
file is archived and specify the number of archive log files to create before
recycling the first file. The default configuration is to never archive the log files.
Chapter 5. Administrative tasks 151
Table 66. pdoscfg options that control the daemon log files
Log file Options that control the log file
msg__pdosd.log –pdosd_log_entries
–pdosd_logs
msg__pdoswdd.log –pdoswdd_log_entries
–pdoswdd_logs
msg__pdosauditd.log –pdosauditd_log_entries
–pdosauditd_logs
msg__pdoslpmd.log –pdoslpmd_log_entries
–pdoslpmd_logs
msg__pdoslrd.log –pdoslrd_log_entries
–pdoslrd_logs
Note: The pdostecd daemon maintains its log file in a separate directory and the
pdoscfg command cannot be used to adjust its logging configuration.
Verifying policy
You should verify that the policies you set are effective, and verify the policy
whenever you change policy. You can use either warning mode or audit mode to
verify policy.
Using warning mode to verify policy
You can check the effects of authorization policy on a system without enabling
enforcement of the policy by enabling warning mode. If warning mode is enabled,
an audit record is generated for accesses to resources that would normally be
denied due to policy but are granted because of warning mode. View the audit log
to determine if the current authorization policy is having the desired effect. You
can enable warning mode globally for all policy or for specific protected resources.
Note: If you enable global warning, you have no enforcement in effect. Make sure
that you enable enforcement again, when required.
Enabling, disabling, and querying global warning mode
To enable global warning mode immediately, enter:
pdosctl –w on
To disable global warning mode immediately, enter:
pdosctl –w off
To enable global warning mode to take effect the next time Tivoli Access Manager
for Operating Systems is restarted, enter:
pdoscfg –warning on
To disable global warning mode to take effect at the next restart, enter:
pdoscfg –warning off
To query the current global warning mode setting, specify the –w with no
arguments:
pdosctl –w
The output is:
152 Administration Guide
The global warning mode setting is off
Enabling, disabling, and querying resource warning mode
To enable warning mode for a specific resource, set up a protected object policy
(POP) with warning mode enabled and attach it to the protected resource. Access
to a protected object that would normally be denied by access controls is granted if
a POP is attached or if inherited with warning mode enabled. An audit record is
generated regardless of the audit level setting in the POP or the global audit level.
Warning mode is disabled by default.
For example, to enable warning mode for accesses to the protected object name
/OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com, enter:
pdadmin> pop create sample_pop
pdadmin> pop modify sample_pop set warning yes
pdadmin> pop attach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com
NetIncoming accesses using Telnet from systems with host names that match the
pattern *.company.com and that would normally be denied are now permitted. An
audit record is generated that shows that access was permitted due to resource
warning mode. To disable warning mode, set the warning attribute to no or detach
the POP from the protected object name. If you are using other attributes in the
POP for the object and you want to disable only the warning mode, leaving the
other attributes intact, set warning mode to off:
pdadmin> pop modify sample_pop set warning no
Warning mode is now disabled.
If you are using this POP only for warning mode or it is also controlling other
protected objects for which you still want warning mode enabled, detach the POP
from the protected object to disable warning mode for just that object:
pdadmin> pop detach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com
To query the warning mode setting in a POP, enter:
pdadmin> pop show pop_name
Using auditing to verify policy
Use the auditing tools to monitor the effects of authorization policy on a system.
Auditing can be set globally, for a specific protected resource or on a per user
basis. This section describes how to use the global and resource-level auditing,
because they are the most useful for verifying policy. The supported global audit
levels useful for verifying policy are permit, deny, loginpermit, and logindeny. The
supported resource audit levels useful for verifying policy are permit and deny. For
global and resource-level auditing, the permit and deny levels can be further
qualified so that they are only in effect for specified OSSEAL actions, such as write.
See Chapter 7, “Auditing,” on page 237 for more information about auditing.
Use the pdosaudview command to see the results of auditing. See “pdosaudview”
on page 270 for a description of the pdosaudview command. You must be defined
as a Tivoli Access Manager for Operating Systems auditor to use the pdosaudview
command. See “Defining runtime administrators and auditors” on page 141 for
details.
Chapter 5. Administrative tasks 153
Setting and querying the global audit level
To set the global audit level that goes into effect at the next restart of Tivoli Access
Manager for Operating Systems, enter:
pdoscfg –audit_level level
where level is one of the supported global audit levels. The audit levels useful for
verifying policy are the ones that audit authorization decisions: permit, deny,
loginpermit, and logindeny.
You can use the pdosctl command to set or reset the global audit level during
runtime.
The –A option resets the current global audit level to the specified value. If
multiple –A options are specified on a single command line, the global audit level
is set to all the specified values. The –a option modifies the global audit level by
resetting just the specified audit level. Multiple –a options can be specified on a
single command line. To reset or modify the global audit level, the –a and –A
options are followed by an audit level and the keyword on or off separated by a
colon (:). If only the audit level is specified without the keyword on or off, the
value on is assumed. Valid values for audit level are:
v all
v none
v permit
v deny
v loginpermit
v logindeny
v admin
v verbose
v info
v trace_exec
v trace_exec_l
v trace_exec_root
v trace_file
To reset the current global auditing to specific levels immediately, enter:
pdosctl –A level:[on | off]
To modify global audit levels (enable new or disable existing), enter:
pdosctl –a level:[on | off]
To set the global audit level to permit and deny, enter:
pdosctl -A permit:on -A deny:on
To add the admin deny audit level to the global audit level, enter:
pdosctl -a admin deny:on
Any audit levels currently enabled are still enabled. When they are specified with
no arguments, the –a and –A options display the current global audit level of the
pdosd, pdoslpmd, pdoslrd, pdosauditd, and pdoswdd daemons.
To query the global audit level, enter:
pdosctl -a
The output is:
154 Administration Guide
pdosd has the following audit levels on: permit, deny, admin
pdoswdd has the following audit levels on: permit, deny, admin
pdoslpmd has the following audit levels on: permit, deny, admin
pdoslrd has the following audit levels on: permit, deny, admin
pdosauditd has the following audit levels on: permit, deny, admin
Setting and querying the resource audit level
To set the audit level for a specific resource, set up a POP with the audit level set
as desired and attach the POP to the protected object name. The audit level
specified controls under what circumstances an access to an object generates an
audit record. The supported resource audit levels useful for verifying policy are the
ones that audit authorization decisions:
v permit
v deny
The default is to not have an audit level set.
For example, to set an audit level of permit and deny for accesses to the protected
object name /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com using the
POP sample_pop, enter:
pdadmin> pop modify sample_pop set audit-level permit,deny
pdadmin> pop attach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com sample_pop
An audit record is generated for all NetIncoming accesses using Telnet from
systems with host names that match the pattern *.company.com. The audit record
indicates whether the access was permitted or denied. To prevent the generation of
audit records, set the audit level attribute to none or detach the POP from the
protected object name. If you are using other attributes in the POP for the object
and you only want to turn off the audit level, leaving the other attributes intact, set
the audit level to none:
pdadmin> pop modify sample_pop set audit-level none
If you are using this POP only for resource auditing or if it is also controlling other
protected objects that you still want to audit, detach the POP from the protected
object to disable warning mode for just that object:
pdadmin> pop detach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com
To query the audit level setting in a POP, enter:
pdadmin> pop show pop_name
Testing programs in an unauthenticated environment
Because administrative users usually have Tivoli Access Manager for Operating
Systems credentials, it is difficult to test policy affecting users and environments
that do not have Tivoli Access Manager for Operating Systems credentials. The
pdosunauth command spawns a shell that is treated as unauthenticated. See
“pdosunauth” on page 348 for information about the pdosunauth command. You
can use this shell to verify policy affecting unauthenticated users and
environments. If an optional command is specified, the spawned shell executes
only the specified command. The following sequence is an example of pdosunauth
usage:
1. Run the following command as root:
psdoswhoami –a
The output is:
0 root
Chapter 5. Administrative tasks 155
2. Run the pdosunauth command to spawn a shell that will be treated as
unauthenticated for Tivoli Access Manager for Operating Systems
authentication decisions:
pdosunauth
3. Run the pdoswhoami command again:
psdoswhoami –a
The output is:
Unauthenticated
Any other command that is executed in this shell is treated as unauthenticated for
the purposes of Tivoli Access Manager for Operating Systems authorization
decisions. This allows the root user to verify that the policy permits and denies
access for unauthenticated users in the expected manner.
Note: Use the pdosunauth command sparingly. Do not give access to it to many
users.
Managing the Trusted Computing Base
The set of files comprising a system’s Trusted Computing Base (TCB) is defined
under the policy branch that the system subscribes to. This set includes files
explicitly defined as TCB resources and programs listed in any of the permit
entries of the Access-Restrictions attribute for an ACL. The trust states and
signatures of TCB files are maintained on a per-machine basis in the Object
Signature Database. The pdosd daemon monitors the files in the Trusted
Computing Base for changes to a file’s signature. If the pdosd daemon detects that
the signature has changed, the file is marked untrusted in the Object Signature
Database. Authorization requests to execute an untrusted Trusted Computing Base
file are denied.
When the state of a file is set to untrusted in the Object Signature Database, it
remains untrusted until explicit administrative action is taken to re-trust that file.
You must re-trust a Trusted Computing Base file after an updated version of the
file has been installed on the system.
Tuning monitoring for the Trusted Computing Base
The pdoscfg command has options for tuning Trusted Computing Base
monitoring. The –tcb_interval option is the interval in minutes that the entire
Trusted Computing Base should be scanned for changes. Increasing this interval
reduces the load of the Trusted Computing Base monitoring system but potentially
increases the time before a change is detected.
The –tcb_max_file_size option is the maximum number of bytes considered
significant in the calculation of a file’s checksum.
The –tcb_monitor_threads option is the number of threads dedicated to
monitoring the files.
The –tcb_ignore_ctime option causes the ctime to be ignored when performing
Trusted Computing Base signature comparisons. When this option is enabled, a
change in ctime does not cause the Trusted Computing Base resource to become
untrusted.
156 Administration Guide
The –tcb_nocrc_on_exec option causes the CRC data checksum that normally
occurs as part of the authorization check associated with running an executable file
that is registered in the TCB to be skipped. Enabling this option avoids performing
the CRC check on large binary files.
The values for these options are stored in the /opt/pdos/etc/pdosd.conf file in the
[tcb] stanza when Tivoli Access Manager for Operating Systems is initially
configured. You can use the pdoscfg command to change the options. The changes
take effect the next time Tivoli Access Manager for Operating Systems is stopped
and restarted on the system. See “pdoscfg” on page 280 for more information
about the command options.
Managing the object signature database
Use the pdosobjsig command to check the current trust state of Trusted
Computing Base files in the Object Signature Database. The –l option can list all
files, all trusted files, or all untrusted files in the database. By default, this
produces a detailed list of objects. Use the –n option to cause only the names of
the objects to be listed.
Use the –g option to display the state of a specific file.
The pdosobjsig command can also modify the current trust state of a Trusted
Computing Base file. Use the –c option or the –C option to check that the
signatures of the objects found in the database have not changed. If a signature
change is detected, the object is marked untrusted. The –c option checks the
signature of a specific object. The –C option checks the signature for all objects
found in the database. Use both –u and –s together, or the –S option alone to
modify the state. The –u option sets the state of a specific file to trusted or
untrusted. The –S option sets the state of all files to either trusted or untrusted. For
example, you install a new executable, /usr/local/app/bin/examplebinaryA, that
you want to be part of the Trusted Computing Base:
1. Enter:
pdadmin> object create \
/OSSEAL/<policy-branch>/TCB/Secure-Programs/usr/local/app/bin/examplebinaryA
2. If the file exists when it is defined in the TCB, it is marked trusted. If it does
not exist at the time that it is defined, you must explicitly set the state to
trusted:
pdosobjsig –u /usr/local/app/bin/examplebinaryA –s trusted
If, in the future, you install an updated version of examplebinaryA and take no
action, then the Tivoli Access Manager for Operating Systems Trusted Computing
Base monitor will detect that the signature has changed and set the state to
untrusted. No one can run this executable. To avoid this, explicitly re-trust the
updated examplebinaryA:
pdosobjsig –u /usr/local/app/bin/examplebinaryA –s trusted
Restricting elements for signature checks
TCB extended attributes can be used to specify which elements in a file signature
should be ignored when determining whether a file should remain trusted or
become untrusted. You might want to ignore select elements in the signature for
performance reasons or because you expect the elements to change.
For example, an administrator could decide that the performance penalty of CRC
checks is not worth the added security on certain files. This administrator would
set the Ignore-CRC extended attribute on those files. If this administrator also
Chapter 5. Administrative tasks 157
decides that a remotely mounted file system should not have its contents become
untrusted after it is unmounted, this administrator would set the Ignore-Missing
extended attribute on that file.
Ignoring elements of the TCB signature results in a less secure system. Deployment
of policy that includes TCB extended attributes should only be done after
determining whether the security trade off is acceptable.
Example 1
To exclude the CRC checksum from the TCB checking that occurs when
the /sbin/portmap file is run, enter the following command to edit the TCB
definition:
pdadmin> object modify /OSSEAL/mybranch/TCB/Immune-Programs/sbin/portmap \
set attribute Ignore-CRCExec ”"
To resume checking the CRC checksum on the same file, enter the
following command:
pdadmin> object modify /OSSEAL/mybranch/TCB/Immune-Programs/sbin/portmap \
delete attribute Ignore-CRCExec
Example 2
To set the maximum number of bytes to include in the CRC checksum to
2000 for the file /data/logfile_update, enter the following command to
edit the TCB definition:
pdadmin> object modify \
/OSSEAL/mybranch/TCB/Secure-Programs/data/logfile_update \
set attribute Set-CRCMaxFileSize 2000
To resume the use of the entire file when calculating the CRC checksum on
the same file, enter the following command:
pdadmin> object modify \
/OSSEAL/mybranch/TCB/Secure-Programs/data/logfile_update \
delete attribute Set-CRCMaxFileSize
Managing scheduled upgrades to registered files in the
Trusted Computing Base
When installing an upgrade to an application or to the operating system, take care
if any files involved in the upgrade are registered in the Trusted Computing Base.
This ensures that the pdosd daemon will not unexpectedly mark a command or
program untrusted the first time it is executed after the upgrade due to a signature
change. The pdosobjsig –C command option provides a way to recheck all the
objects in the object signature database. As part of the check, a new signature is
calculated. If pdosobjsig detects that the signature has changed, the file gets
marked untrusted in the object signature database. The pdosobjsig –l untrusted
command can then be used to generate a list of all files that are marked untrusted.
By default, this produces a detailed list, which includes the reason the file was
marked untrusted. Use the –n option to have only the names of the files listed.
After an administrator verifies that the list of files now marked untrusted is
appropriate due to the upgrade, the pdosobjsig –S trusted command can be used
to mark all the files as trusted again; or the pdosobjsig –u objname –s trusted
command can be used to mark individual files as trusted.
The following example lists the steps to take when an application, whose binaries
are registered in the Trusted Computing Base, is upgraded:
1. Prior to the upgrade, check for objects already marked untrusted in the
database. If any files are listed, determine why these files have been marked
158 Administration Guide
untrusted and take the appropriate action before continuing with the upgrade
or keep the list for future reference. To obtain the current list of objects that are
marked untrusted, use the following command:
pdosobjsig -l untrusted> untrusted.output
2. Perform the application upgrade.
3. After the upgrade is complete, recheck the files in the object signature database.
This updates the signatures of any files that have changed and marks these
files as untrusted. To recheck the signatures of all the objects in the object
signature database, use the following command:
pdosobjsig -C
4. To get a list of all files that are now marked untrusted, use the following
command:
pdosobjsig -n -l untrusted > after.upgrade.untrusted.output
5. Verify that the list of untrusted files is the expected list based on what was
contained in the application upgrade. Compare this list with the list of files
produced in Step 1. When you are satisfied that detected signature changes are
legitimate due to the upgrade, re-trust all the objects marked untrusted, using
the following command:
pdosobjsig -S trusted
Managing operating system upgrades
Careful consideration must be given when upgrading the operating system on
machines that are running Tivoli Access Manager for Operating Systems, because
system files involved in the upgrade might be registered in the Trusted Computing
Base or might have been modified when login activity policy enforcement was
enabled. The following example lists the steps to take when performing an
operating system upgrade:
1. Prior to the operating system upgrade, check for objects already marked
untrusted in the database. If any files are listed, determine why these files have
been marked untrusted and take the appropriate action before continuing with
the operating system upgrade or keep the list for future reference. To obtain the
current list of objects marked untrusted, use the following command:
pdosobjsig -l untrusted
2. It is recommended that you shut down Tivoli Access Manager for Operating
Systems prior to starting the upgrade. Use the following command:
rc.osseal stop
It is also recommended that you temporarily disable login activity policy
enforcement. This will remove the Tivoli Access Manager for Operating
Systems updates to system files, just in case these files are affected by the
upgrade. Use the following command to disable login policy:
pdoscfg -login_policy off
If a system reboot will occur as part of the upgrade, disable autostart prior to
doing the upgrade. This ensures that the pdosd daemon does not mark a vital
system executable as untrusted due to a signature change caused by the
upgrade. Use the following command to disable autostart:
pdoscfg -autostart off
3. Perform the operating system upgrade.
4. After the upgrade is complete, system files that are part of the Trusted
Computing Base and were changed due to the upgrade must have their
signatures updated in the object signature database. Use the pdosobjsig –C
Chapter 5. Administrative tasks 159
command to quickly recheck the signatures of all the objects in the object
signature database. This will update the signatures of any files that have
changed and mark them as untrusted.
5. To get a list of all files that are now marked untrusted, use the following
command:
pdosobjsig -n -l untrusted> after.upgrade.untrusted.output
6. Verify that the list of untrusted files is the expected list based on what was
contained in the operating system upgrade. Compare this list with the list of
files produced in Step 1. When you are satisfied that detected signature changes
were legitimate due to the upgrade, re-trust all the objects marked untrusted,
using the following command:
pdosobjsig -S trusted
7. Re-enable login policy and autostart if you disabled them in Step 2, using the
following command:
pdoscfg -autostart on -login_policy on
8. Reboot the system to restart Tivoli Access Manager for Operating Systems.
Rebooting will ensure that the kernel drivers and the daemon will be activated
at the appropriate time during system startup.
Managing login activity and password management policy
enforcement
The Tivoli Access Manager for Operating Systems Login Activity and Password
Management Policy is enforced on a per-machine basis based on the activity of an
account that is defined on the machine. The pdoslpadm command is used to view
and manage the state of login activity and password management.
Viewing account records
As part of the login activity policy, a local database maintains records for all users
who logged in since the login activity policy was activated. These records can be
viewed using the –r option of the pdoslpadm command. To see all the records that
are currently in the database, specify the –r option with no operand.
# pdoslpadm –r
User (uid) State<: Time Locked>
----------------------------- ---------------------
gbland(1114) Unlocked
root(0) Unlocked
uduck(1118) Unlocked
Detailed information about an account can be displayed by using the –f option. To
see details about the gbland and uduck user IDs:
# pdoslpadm –r –f gbland uduck
--------------------------------------------------
Account state for gbland, id 1114:
Lock status: Unlocked
Last successful login: Sun 02 Dec 2001 05:53:01 PM CST
Current grace logins: 0
Password change date: Thu 08 Nov 2001 12:00:00 AM CST
Login failure data:
Concurrent logins(allowed): 0(0)
--------------------------------------------------
--------------------------------------------------
Account state for uduck, id 1118:
Lock status: Unlocked
Last successful login: Sun 02 Dec 2001 03:09:25 PM CST
160 Administration Guide
Current grace logins: 0
Password change date: Thu 04 Oct 2001 12:00:00 AM CDT
Login failure data:
Failure record 1:
TTY name: /dev/pts/4
rhost name: bigserv.mycomp.com
ruser name:
Failing pid: 657 (login)
Failure time: Sun 02 Dec 2001 03:04:22 PM CST
Concurrent logins(allowed): 0(10)
--------------------------------------------------
Locking and unlocking accounts
User accounts can be locked or suspended due to violations of login activity policy.
A Tivoli Access Manager for Operating Systems administrator can also explicitly
lock an account by using the –l option of the pdoslpadm command. To lock the
account associated with the bsmith user ID and prevent future logins, use the
following command:
pdoslpadm –l bsmith
To re-enable an account for login and reset any values that are causing the account
to be locked or suspended due to a past violation of login activity policy, use the
–u option:
pdoslpadm –u bsmith
Password change date for user accounts
The login activity policy attempts to use the password change date data from the
local system data. This information is often part of the shadow password data that
is stored for locally defined user accounts on UNIX systems. However, password
change date data is not available in all environments. On HP-UX systems that are
not trusted secure systems and in environments with a distributed user registry,
such as NIS, NIS+, and DCE, the password change date data is not available.
In environments where the password change date data is not available, the Tivoli
Access Manager for Operating Systems administrator can explicitly set a password
change date on a user account basis by using the –m option of the pdoslpadm
command. This should be done for all user accounts on systems that have policy
in place that relies on the password change date data, such as a grace login policy
or a minimum or maximum password lifetime policy.
Creation of local user accounts with minimum password age
policy
The specification of a minimum password age policy might cause problems when
new accounts are created for locally defined users.
When a new user account is created, the password change date is set to the current
date. When the new user attempts to login, Tivoli Access Manager for Operating
Systems does not allow a password change due to a violation of the minimum
password age policy.
An administrator should perform the following steps to ensure that a new local
user account with a password can be changed immediately by the user.
1. Create an account using the standard system tools, such as mkuser on AIX or
useradd on Solaris.
Chapter 5. Administrative tasks 161
2. Set the password change date using the pdoslpadm –m command so that the
date is sufficiently old to allow the change of the password without violating
the current minimum password age policy in effect. If no date is specified with
this option, the value that is used is the current date minus the number of days
specified in the MinPasswordDays attribute of the password policy.
This sequence permits the user to login and change the password without violating
login activity policy.
Configuring NIS for login activity policy
As previously mentioned in “Password change date for user accounts” on page
161, login activity policy in NIS environments with a distributed user registry is
complicated by the fact that password change date data is not maintained. The
pdoslpadm –m command can be used to provide the password change data for
individual accounts, but this can become an administrative burden.
Tivoli Access Manager for Operating Systems provides support that allows an
administrator to configure an NIS server to support password change dates,
assuming that the password change dates are available from the system files used
to build the NIS maps. The NIS clients also must be configured to request the
password change data from the NIS server.
To configure the NIS server to generate a new map that provides password change
dates for all user IDs, enter the following command on the NIS server:
pdoslpadm –c on –n server
This new map is generated from the same files as the passwd map that is served by
the NIS server. The NIS administrator needs to create a cron job or other
administrative task to ensure that the passwdchg map is regenerated every time the
passwd map changes.
On the NIS clients, enter the following command to have the NIS clients request
the updated passwdchg map from the NIS server:
pdoslpadm –c on –n client
To unconfigure this support on either the NIS client or the NIS server, enter the
command specifying the -c off option.
Displaying password expiration and grace logins
Normally, policy data is hidden from non-administrative users. Because it is
important for users to be able to obtain information about their own password
expirations and grace logins, Tivoli Access Manager for Operating Systems
provides the pdoslpinf command. By using this command, users can display their
password expiration date, the number of days until their password expires, and
the number of grace logins after their password expires.
System administrators can include the pdoslpinf command in a script that is run
from the login profile to warn users that their password is going to expire. The
following pseudo-script shows how to include the pdoslpinf command in a login
profile:
# Get the number of days remaining before the password expires
expdays=’pdoslpinf -r’
# If the expiration date is less than 10 days away or has expired, call
# the pdoslpinf command to display a message about the expiration and
162 Administration Guide
# grace logins. If the password has expired, call the passwd command to
# prompt for a password change.
if [ expdays < 10 >
pdoslpinf
if [expdays < 0 ]
passwd
fi
fi
Because the pdoslpinf command returns information that can be considered
sensitive, the command returns data for that specific user running the command. A
user cannot run this command or perform surrogate operations to obtain
information about other users.
Managing credentials
Credentials are cached so that Tivoli Access Manager for Operating Systems can
make authorization decisions efficiently and also to ensure that it can function
isolated from the Tivoli Access Manager user registry.
The pdosd daemon uses an in-memory cache and a disk cache.
Tuning the credentials cache
The pdoscfg command has the following options for tuning the credential cache
for the pdosd daemon:
–user_cred_refresh
The number of minutes that user credentials can exist in the credentials
cache before they are considered to be due for a refresh. The interval starts
at the time the credential is cached. When the refresh interval is exceeded,
the credential is refreshed.
–admin_cred_refresh
The refresh frequency of the credentials associated with Tivoli Access
Manager for Operating Systems administrative users. This option enables
you to manage the credentials refresh interval for administrative users
independently of the general users.
–cred_hold
The number of minutes that general user credentials can be kept in the
credentials cache beyond the time of the user’s last access. Credentials
associated with general users are flushed from the cache after this interval.
The credentials associated with administrative and critical system users are
never flushed from the cache. The –cred-hold interval must be at least as
long as the –user-cred-refresh interval.
–critical_cred_refresh
The refresh frequency for credentials associated with critical system users.
This option enables you to manage the credential refresh interval for
critical system users independently of the general users. It is specified in
minutes.
–critical_cred_group
The name of the Tivoli Access Manager group containing all users who are
to be treated as critical system users. This group must be created and
populated by the system administrator. Credentials for users who are
members of this group are never removed from the cache. System
administrators should use this group to specify users who are critical to
Chapter 5. Administrative tasks 163
the proper functioning of the system and programs running on it.
Administrative users, who are members of the Tivoli Access Manager
osseal-admin group, do not need to be members of this group.
When Tivoli Access Manager is configured to multiple Active Directory
domains, the name of the group is in the format of group_name@domain,
where domain is the name of the Active Directory domain to which Tivoli
Access Manager for Operating Systems is configured. In this case, the
group members are in the format of group_member@domain.
–cred_response_wait
The minimum number of minutes that the pdosd daemon will wait for
responses to credential requests from the Tivoli Access Manager user
registry before entering isolation mode.
The values for these options are stored in the /opt/pdos/etc/pdosd.conf file in the
[credentials] stanza when Tivoli Access Manager for Operating Systems is
initially configured. For most environments, the default values should be sufficient.
You can change the value with the pdoscfg command, but the changes do not take
effect until the next time Tivoli Access Manager for Operating Systems is stopped
and restarted on the system.
For more information, see “pdoscfg” on page 280.
Explicitly refreshing credentials
Credentials are initially retrieved or refreshed from the Tivoli Access Manager user
registry when a user logs in to a system using a supported and defined login
program while Tivoli Access Manager for Operating Systems is running. All
authorization decisions made for operations performed by processes subsequently
run by this user are made using these credentials. You can explicitly refresh the
credentials of a user already logged into the system, or users can refresh their own
credentials. The pdosrefresh command refreshes the cached credentials for the
invoking user, specified users, or the entire cache, according to the options
specified on the command line.
A user can refresh current credentials by invoking the pdosrefresh command
without options. An administrative user can refresh the credentials for another user
by specifying the UID or name of the UNIX user. In a single invocation, you can
specify multiple users. An administrative user can also refresh all of the credentials
in the cache with the –C option.
Assume that you change the group membership in the Tivoli Access Manager user
registry for the users sally and riley. To have this change take effect immediately,
the credentials associated with these users need to be refreshed.
1. To refresh the credentials of users sally and riley, enter:
pdosrefresh –n sally –n riley
2. To refresh the credentials of the invoking user, enter:
pdosrefresh
3. To refresh all the credentials of all users in the cache, enter:
pdosrefresh -C
Explicitly destroying credentials
The pdosdestroy command removes the cached credentials of the specified users.
Users can destroy their current credentials by invoking the pdosdestroy command
164 Administration Guide
without options. To remove the credentials of another user, specify the UID or
name of the UNIX user. You can specify more than one user on the command line.
To destroy the credentials of the invoking user, enter:
pdosdestroy
To destroy the credentials of users sally and riley (whose UID is 300) enter:
pdosdestroy –n sally –u 300
Determining accessor identity
You might need to explicitly check the Tivoli Access Manager for Operating
Systems accessor identity associated with the environment of a user or of a
running process.
Determining accessor identity for users
The pdoswhoami command displays the Tivoli Access Manager for Operating
Systems accessor information that is associated with the invoking user. Invoking
the command without options displays the Tivoli Access Manager user name.
For the invoking user, the –n option displays the accessor ID.
For the invoking user, the –a option displays the Tivoli Access Manager user name
and the accessor ID.
For the invoking user, the –l option displays the Tivoli Access Manager user name,
the accessor ID, Tivoli Access Manager group membership, the time the credentials
were last refreshed, the credentials refresh expiry, the time the credentials were last
accessed, and the credentials’ hold time expiry.
For additional information, see “pdoswhoami” on page 350.
Determining accessor identity for processes
The pdoswhois command displays the Tivoli Access Manager for Operating
Systems accessor information that is associated with running processes. Specify
processes by their process ID (pid). On the pdoswhois command line, specify the
list of process IDs last. For each specified process ID, the accessor ID and Tivoli
Access Manager user name are displayed. If the –l option is specified, the Tivoli
Access Manager group membership, the time the credentials were last refreshed,
the credentials refresh expiry, the time the credentials were last accessed, and the
credentials hold time expiry are also displayed.
For additional information, see “pdoswhois” on page 352.
Examples of pdoswhoami and pdoswhois
The user sally is logged into a system running Tivoli Access Manager for
Operating Systems. User sally can view her own credentials by entering the
command:
pdoswhoami –l
The output is:
106 sally
The credential is associated with the following groups:
osseal-testers
Chapter 5. Administrative tasks 165
osseal-developers
The credential was last refreshed at Sat Nov 4 14:07:21 2000
The credential refresh time expires at Sun Nov 5 02:07:21 2000
The credential was last accessed at Sat Nov 4 14:07:29 2000
The credential hold time expires at Sat Nov 11 14:07:29 2000
The user sam is logged into a system in the Tivoli Access Manager environment
that is configured to use multiple Active Directory domains and where Tivoli
Access Manager for Operating Systems is configured to use the tivoli.com
domain. User sam can view his own credentials by entering the command:
pdoswhoami -l
The output is:
The credential is associated with the following groups:
The credential was last refreshed at Sat Nov 6 14:07:21 2004
The credential refresh time expires at Sun Nov 7 02:07:21 2004
The credential was last accessed at Sat Nov 6 14:07:29 2004
The credential hold time expires at Sat Nov 13 14:07:29 2004
User root, who is a Tivoli Access Manager for Operating Systems administrator by
default, enters the command:
pdoswhoami –l
The output is:
0 root
The credential is associated with the following groups:
osseal-admin
osseal-auditors
The credential was last refreshed at Sat Nov 4 11:52:56 2000
The credential refresh time never expires.
The credential was last accessed at Sat Nov 4 14:12:56 2000
The credential hold time never expires.
You, an administrator, can determine what credentials are associated with the
running processes whose process IDs are 1756 and 1806 by entering:
pdoswhois 1756 1806
The output is:
Pid, 1756, is running under the uid = 106, user name = sally
Pid, 1806, is running under the uid = 300, user name = riley
Accessor identity and the UNIX identity differences
The Tivoli Access Manager for Operating Systems accessor identity and the UNIX
identity in effect for a user or a running process might be different. For example,
issuing a su command might change a user’s UNIX identity but does not change
the user’s Tivoli Access Manager for Operating Systems accessor identity.
Executing a setuid or setgid program might change the UNIX identity of the
process but the Tivoli Access Manager for Operating Systems accessor identity
associated with the process will still be that of the invoker.
For example, the user sally is permitted to perform a change ID operation to the
root user and runs the /bin/su command to become the root user. The Tivoli
Access Manager for Operating Systems accessor identity associated with this user
is still sally but the UNIX identity is the root user.
1. First, user sally issues the following commands:
166 Administration Guide
v id
The output is:
uid = 106(sally)
v pdoswhoami -a
The output is:
106 sally
2. Then, user sally issues the /bin/su command.
3. After issuing /bin/su, user sally issues the following commands:
v id
The output is:
uid=0(root)
v pdoswhoami -a
The output is:
106 sally
Configuring and managing the host name lookaside database
To eliminate the need to consult the native naming service for every IP address or
host name lookup, Tivoli Access Manager for Operating Systems maintains a host
name lookaside database. This database is populated at runtime as the lookups
occur. The use of this database is enabled by default when Tivoli Access Manager
for Operating Systems is initially configured on a system.
Configuring the database
Use the pdoscfg command to disable the host name lookaside database by
specifying –dns off. You can enable or disable the host name lookaside database at
any time with the pdoscfg command but the changes do not take effect until the
next time Tivoli Access Manager for Operating Systems is stopped and restarted.
To enable the host name lookaside database for the next restart, enter:
pdoscfg –dns on
To disable the host name lookaside database for the next restart, enter:
pdoscfg –dns off
Managing the database
Use the pdoshla command to manage the database. You might need to do this
when cached information becomes obsolete due to changes in the native naming
service. The pdoshla command adds, deletes, refreshes, and views entries in the
database.
The –l option lists the existing database entries. It can be qualified by specifying
all, stale, or fresh. You can add an entry for a given IP address by using the –a
option.
The native naming service is used to resolve the host name unless the –H option is
used to specify the associated host name.
The entry’s default time-to-live value is 6 hours (21600 seconds). Use the –T option
and explicitly specify the time-to-live value to override the default.
Chapter 5. Administrative tasks 167
The –F option flushes the entire database. The –f option flushes stale entries from
the database. The –r option flushes the specified entry.
Use the –u option to refresh all the database entries and cause a native name
service lookup to occur for each entry found in the database.
Examples of using pdoshla
The following are examples of using the pdoshla command.
1. To add an entry to the default database for IP address 146.84.107.11, enter:
pdoshla –a 146.84.107.11
2. To view all of the entries in the default database, enter:
pdoshla –l all
The output is:
# Internet Address Hostname
9.41.3.101 test1.austin.lab.tivoli.com
146.84.107.11 office1.tivoli.com
9.41.3.123 test3.austin.lab.tivoli.com
3. To view stale entries found in the default database, enter:
pdoshla –l stale
The output is:
# Internet Address Hostname
9.41.3.123 test3.austin.lab.tivoli.com
4. To flush stale entries from the default database, enter:
pdoshla –f
5. To refresh all entries found in the default database, enter:
pdoshla –u
Backing up and restoring configuration files and databases
The pdosbkup and pdosrstr commands back up and restore Tivoli Access Manager
for Operating Systems configuration files and databases.
Backing up configuration files and databases
You should stop Tivoli Access Manager for Operating Systems before backing it
up. If the pdosbkup command is executed while the daemons are running, the
state of some of the files can change during the backup.
The pdosbkup command backs up all files and directories in the
/opt/pdos/etc/pdosbkuplist file. If –x is specified, the files and directories listed in
the /opt/pdos/etc/pdosbkuplistx file are backed up. Subdirectories are traversed.
By default, the backup file created is placed in a file with the date and timestamp
appended to it in the form of: /var/pdos/pdosbkup/pdosbkupDDMMMYYYY.HH_MM_SS.tar. For example, a backup performed at 12:34:56 on
November 19, 2001 would be named:
/var/pdos/pdosbkup/pdosbkup19Nov2001.12_34_56.tar
Use the –p option to change the directory in which the backup file is placed. Use
the –f option to change the backup file name.
168 Administration Guide
Examples of backing Up Tivoli Access Manager for Operating
Systems
The following are examples of backing up Tivoli Access Manager for Operating
Systems:
1. To back up critical configuration files, enter:
pdosbkup
2. To do an extended backup, enter:
pdosbkup –x
Restoring Tivoli Access Manager for Operating Systems
The pdosrstr command restores Tivoli Access Manager for Operating Systems files
that were previously saved using the pdosbkup command. Files are restored from
the backup file specified by the –f option.
Example of restoring Tivoli Access Manager for Operating
Systems
To restore files saved in the pdosbkup25Oct2001.14_32_41.tar file, enter:
pdosrstr –f /var/pdos/pdosbkup/pdosbkup25Oct2001.14_32_41.tar
Obtaining entitlement report
A common question posed to security administrators is what are the resulting
access permissions for a given user or group, given the existing security policy and
branch ordering. To help security administrators answer this question, the pdosent
command provides the capability to create an entitlement report for a user or
group.
The entitlement report for a user or group contains all information stored in the
Tivoli Access Manager policy server about the user or group and all the policy
information specific to the specified branch precedence rule.
Parts of the entitlement report
The entitlement report consists of the following parts:
v A header
v The user or group information, including policy
v Information about the object space policy
Header information
The header information contains data on when the command was run and what
values were used to extract the security data. For example, output of the header
information might appear as follows:
Version: 6.0.0.0 (031023a)
Date : 2004-02-10-10:30:30
Server : amosint8
Domain: dev
Branches: unix,db2,his
User: sec_master
Exclusion-map: 0x0 0x0 0x0
User or group information
The user information is divided into two parts:
v The user-related information
v The user-specific policy as it is specified within a branch
Chapter 5. Administrative tasks 169
The user information shown depends on the state of the user:
v If the user is not found in the Tivoli Access Manager user registry, the
information is limited to the policy as it is applied to the unauthenticated user
v If the user is found in the Tivoli Access Manager user registry but the account is
not valid, the information is limited to the policy as it is applied to the
unauthenticated user
v If the user is found in the Tivoli Access Manager user registry and the account is
valid, the information is based on user identity and group memberships
Unauthenticated user example
The following example shows the output for a user who is not defined in Tivoli
Access Manager (unauthenticated):
Name : foo is an UNAUTHENTICATED user!
ToD : unset
Login :
Attribute: "Login-LoginMinutes" "20"
Attribute: "Login_LockMinutes" "30"
Password :
Attribute: "Password-MinPasswordLen" "8"
Attribute: "Password-MinAlpha" "2" (INVALID duplicate attribute)
Attribute: "Password-MinAlpha" "3" (INVALID duplicate attribute)
Only the applicable Password policy is displayed. If the /OSSEAL/policy-branch/Password/UserExceptions/user-name object exists, then the attributes attached to
that object are displayed. Otherwise, the /OSSEAL/policy-branch/Password object
and the attributes attached to it are displayed. Only the defined attributes are
displayed. If multiple attributes are attached with the same name, the policy is
considered invalid and the attribute will be marked as invalid.
Only the applicable Login policy is displayed. If the /OSSEAL/policy-branch/Login/UserExceptions/user-name object exists, then the attributes attached to that
object are displayed. Otherwise, the /OSSEAL/policy-branch/Login object and the
attributes attached to it are displayed. Only the defined attributes are displayed. If
multiple attributes are attached with the same name, the policy is considered
invalid and the attribute will be marked as invalid.
Authenticated user example
The following example shows the output for a user who is defined in Tivoli Access
Manager (normal case):
Name : dever
DN : cn=bob,ou=austin,o=ibm,c=us
CN : dever
SN : dever
Desc :
GSO : NO
Account Valid : YES
Password Valid : YES
ToD : unset
Login :
Attribute: "Login-LoginMinutes" "20"
Attribute: "Login_LockMinutes" "30"
Password :
Attribute: "Password-MinPasswordLen" "8"
Attribute: "Password-MinAlpha" "2" (INVALID duplicate attribute)
Attribute: "Password-MinAlpha" "3" (INVALID duplicate attribute)
Only the applicable Password policy is displayed. If the /OSSEAL/policy-branch/Password/UserExceptions/user-name object exists, then the attributes attached to
170 Administration Guide
that object are displayed. Otherwise, the /OSSEAL/policy-branch/Password object
and the attributes attached to it are displayed. Only the defined attributes are
displayed. If multiple attributes are attached with the same name, the policy is
considered invalid and the attribute will be marked as invalid.
Only the applicable Login policy is displayed. If the /OSSEAL/policy-branch/Login/UserExceptions/user-name object exists, then the attributes attached to that
object are displayed. Otherwise, the /OSSEAL/policy-branch/Login object and the
attributes attached to it are displayed. Only the defined attributes are displayed. If
multiple attributes are attached with the same name, the policy is considered
invalid and the attribute will be marked as invalid.
Group example
The following example shows the output for a group:
Name : osseal-admin
DN : cn=osseal-admin,ou=austin,o=ibm,c=us
CN : osseal-admin
Desc :
User: root
User: osseal
If the group is not defined in Tivoli Access Manager, the command will exit with
an error.
Object space output
A subset of the object space will be processed as shown below. Where ACL
permissions are displayed, only the appropriate permissions and access restrictions
will be displayed. In the case of the unauthenticated user, only the unauthenticated
entry will be shown. In the case of a valid user, permissions will be displayed, if a
user entry exists, or all group entries for the groups the user belongs to, or if
neither exist, the any-other entry will be shown. In the case where no permissions
apply, no permissions will be displayed. The following list of object spaces will be
displayed:
v /OSSEAL/policy-branch/File
v /OSSEAL/policy-branch/RootDir
v /OSSEAL/policy-branch/Login/Terminal
v /OSSEAL/policy-branch/Login/Holiday
v /OSSEAL/policy-branch/NetIncoming
v /OSSEAL/policy-branch/NetOutgoing
v /OSSEAL/policy-branch/Surrogate
v /OSSEAL/policy-branch/Sudo
To understand how access permission are processed, compare the output from the
policyview command for the same branch precedence.
The following example shows the output for an object in pdosent:
/opt/pdos/etc/trace
TR[OSSEAL]DKNRUdloprwx
permit:any-other:r:/opt/pdos/bin/pdoswhoami
permit:group osseal-admin:r:*
Only extended attributes that have meaning for Tivoli Access Manager for
Operating Systems are displayed, such as the Sudo, Login, and Password
attributes. If the attribute name was entered inaccurately, the attribute is not
displayed.
Chapter 5. Administrative tasks 171
Only extended attributes on the ACL that have meaning for Tivoli Access Manager
for Operating Systems are displayed, such as the Access-Restrictions attribute. If
the attribute name was entered inaccurately, the attribute is not displayed.
The pdosent command processes the object space based on the provided branch
precedence list and the Tivoli Access Manager for Operating Systems branch
structure. To allow an administrator to examine policy outside of the Tivoli Access
Manager for Operating Systems branch structure, the –r resource-name option can
be used. If the –r option has been set, and the resource name begins with a /, the
resource name represents an absolute object name and processing for the object
space will begin at that specific point without any considerations for branches.
Review the following examples:
v Show the entitlement report for user bob on this machine. Use defaults for all
settings as configured in Tivoli Access Manager for Operating Systems
pdosent -u bob
v Show the entitlement for members of the group sysadmin, if branch ordering
was changed to the list provided:
pdosent -g sysadmin -b unix,db2,his
v Show the entitlement for user anne, if the machine was configured to the prod
domain, using the default branch ordering:
pdosent -u anne -d prod -a sec_prod
v Show the entitlement for user chris to perform Tivoli Access Manager base
actions. These are the Tivoli Access Manager native permissions on the object in
the /Management object space:
pdosent -u chris -r /Management -a sec_master -p password
Viewing policy
When trying to troubleshoot access restrictions, an administrator often faces the
task of mapping a UNIX resource name to a Tivoli Access Manager protected
object name. The task is complicated by any use of wildcard patterns and the use
of multiple branch precedence. To perform this task, you can use the
pdosrespolicy command to map a UNIX resource of the type file, netincoming, or
netoutgoing to the corresponding protected objects and to display any policy
applied to the object.
The output for this command is to the screen and is similar to the output shown in
policyview for an object. For example:
OBJ: /OSSEAL/amosps4/File/opt/pdos/etc/trace
Desc : no description
Type : 3
Policy : YES
ACL : osseal-restricted
Desc :
Perm : User sec-master TcmdbsvaBRl
Perm : Group osseal-admin TR[OSSEAL]DKNRUdloprwx
Perm : any-other TR[OSSEAL]r
Perm : unauthenticated TR[OSSEAL]r
Attribute: "Access-Restrictions" "any-other:r:/opt/pdos/bin/pdoswhoami"
Attribute: "Access-Restrictions" "unauthenticated:r:/opt/pdos/bin/pdoswhoami"
Attribute: "Access-Restrictions" "osseal-admin:r:*"
POP : etc-trace
Desc : pop for etc trace
Warning : NO
172 Administration Guide
Audit : NONE
ToD : anyday:anytime:local
Attribute: "audit_permit_actions" "[OSSEAL]w"
If the same resource exists under more than one policy branch, the highest
precedence object is displayed. If the –D option is specified, the duplicate objects
from the lower precedence policy branches are displayed after the highest
precedence object, starting with the line:
Duplicate OBJ: /OSSEAL/his/File/usr/bin.
If the ACL is attached to this object, it is displayed with the ACL: prefix. If there is
no ACL attached at this point, the ACL is inherited and it is displayed with the
Effective ACL: prefix.
Only extended attributes that have meaning for Tivoli Access Manager for
Operating Systems are displayed, such as the Access-Restrictions attribute. If the
attribute name was entered inaccurately, the attribute is not displayed.
If the POP is attached to this object, it is displayed with the POP: prefix. If there is
no POP attached at this point, the POP is inherited and it is displayed with the
Effective POP: prefix.
Only extended attributes that have meaning for Tivoli Access Manager for
Operating Systems are displayed, such as the audit_permit_actions and
audit_deny_actions. If the attribute name was entered inaccurately, the attribute is
not displayed.
If the AuthzRule is attached to this object, it is displayed with the AuthzRule:
prefix. If there is no AuthzRule attached at this point, the AuthzRule is inherited
and it is displayed with the Effective AuthzRule: prefix.
Review the following examples:
v Show the policy applying to the file resource /opt/pdos/bin/pdosd:
pdosrespolicy -f /opt/pdos/bin/pdosd
v Show the effective policy applying to a netincoming operation on port 23 from a
host called test.ibm.com:
pdosrespolicy -e -i test.im.com/23
v Show the policy applying to a network outgoing operation to a machine using
IPv6 notation on the Telnet port. Also show if there are any other objects in
lower priority branches that have policy set:
pdosrespolicy -D -o [1080::8:800:200C:417A]/telnet
Chapter 5. Administrative tasks 173
174 Administration Guide
Chapter 6. Using the Tivoli desktop to perform management
tasks
The tasks and jobs described in this chapter are available only after installing the
Tivoli Access Manager for Operating Systems Management Tasks component. For
information on installing this component, see the IBM Tivoli Access Manager for
Operating Systems: Installation Guide. If you did not install the Tivoli Access
Manager for Operating Systems Management Tasks component, the information in
this section does not apply, and you should consult Chapter 5, “Administrative
tasks,” on page 141 for information on using the command line to administer
Tivoli Access Manager for Operating Systems.
When the Tivoli Access Manager for Operating Systems Management Tasks
component is installed, a PDOS Tasks task library is made available to the Tivoli
desktop that allows you to manage Tivoli Access Manager for Operating Systems
and its daemons. The PDOS Tasks task library is located in the Policy Director
Region policy region.
Note: All of the Tivoli Access Manager for Operating Systems Management Tasks
run as root on the target system. The tasks rely on the root user’s privileges
as a Tivoli Access Manager for Operating Systems runtime administrator. If
the root user ID is removed as a Tivoli Access Manager for Operating
Systems runtime administrator, the tasks must be modified to run as a
different runtime administrator.
In addition to the tasks provided with Tivoli Access Manager for Operating
Systems, you can create your own tasks and jobs. A job is a task for which the
targets and output parameters are pre-configured. See the Tivoli Management
Framework: User’s Guide for more information about task libraries, tasks, and jobs.
You can modify the default execution characteristics of a particular job, such as
where the output of a job is displayed and on which machines the job will run.
You can also specify whether a job runs serially on each machine, in parallel on all
machines, or staged in groups of machines.
Task overview
When you run a task, you must explicitly specify the nodes on which the task
runs. As a convenience, jobs have been provided for those tasks that you typically
run on all Tivoli Access Manager for Operating Systems nodes. These jobs are
configured to run on all nodes that are subscribers of the Tivoli Access Manager
for Operating Systems profile manager (PDOS), except where noted. You can use
the Subscribe PDOS Endpoints job to subscribe the Tivoli Access Manager for
Operating Systems clients (that are hosting managed nodes or endpoints) to the
PDOS profile manager.
These tasks can be modified to run on selected subscribers. You can also create
your own tasks and jobs. For example, you can create separate tasks to start and
stop Tivoli Access Manager for Operating Systems servers on specific nodes. See
the Tivoli Management Framework: User’s Guide for more information about task
libraries, tasks, and jobs, and about creating your own tasks and jobs.
© Copyright IBM Corp. 2000, 2005 175
The following table provides the authorization role information for each of the
Tivoli Access Manager for Operating Systems tasks and jobs. The context for each
authorization role is the task library.
Note: The acronym PDOS stands for “Policy Director for Operating Systems”,
which is the former name of Tivoli Access Manager for Operating Systems.
The task names use this acronym to maintain consistency with previous
versions of the Management Tasks component.
Table 67. Authorization for Tivoli Access Manager for Operating Systems tasks
Task name Authorization roles
Add/Remove PDOS Auditors/Administrators admin
Backup PDOS Database admin
Branch Configuration admin
Certificate Transfer Utility user
Configure Audit Health admin
Configure PDOS Auditing admin
Configure PDOS Caching admin
Configure PDOS Logging admin
Configure PDOS Login and Password Policy admin
Configure PDOS Server admin
Configure PDOS TCB admin
Display PDOS Hostname Cache admin
Distribute Log Router Daemon Control File user
Import UNIX TCB admin
Import UNIX Users and Groups admin
Manage PDOS Credential Cache admin
Manage PDOS Server State admin
Manage PDOS TCB admin
Purge PDOS Hostname Cache admin
Query Branch Membership admin
Query PDOS Login and Password Policy admin
Query PDOS Server State admin
Query PDOS TCB admin
Restore PDOS Database admin
Set PDOS Server Audit Level admin
Set PDOS Server Trace Level admin
Setup TEC Event Server for PDOS admin, senior, super
Show PDOS Auditing Configuration admin
Show PDOS Auditors/Administrators admin
Show PDOS Caching Configuration admin
Show PDOS Logging Configuration admin
Show PDOS Server Audit Level admin
Show PDOS Server Configuration admin
176 Administration Guide
Table 67. Authorization for Tivoli Access Manager for Operating Systems tasks (continued)
Task name Authorization roles
Show PDOS TCB Configuration admin
Start TEC Adapter admin
Stop TEC Adapter admin
Subscribe PDOS Endpoints admin
Update PDOS Hostname Cache admin
Running tasks as users other than root
If root is removed from the osseal-admin group, the PDOS Tasks must be
modified to run under a user ID that has been added to the osseal-admin group.
Several other actions should be taken due to the architecture of endpoint task
execution. The basic execution of a Task on an endpoint is as follows. Solaris is
used in the example, but the steps apply to all platforms.
1. The user runs a task on a Solaris endpoint for the first time.
2. The executable that contains the run_task() method for an endpoint is named
task_endpoint. The endpoint knows that this is supposed to live at
$LCFROOT/dat/1/cache/bin/solaris2/TAS/TASK_LIBRARY/task_endpoint.
3. The endpoint checks its cache index to determine if the file exists.
4. Because this is a brand new endpoint install, it does not exist.
5. The endpoint contacts to its gateway and downloads task_endpoint from the
/lcf_bundle directory. It then updates its cache index with unique information
about task_endpoint. The information is basically a signature that uses the date
of the file.
6. The endpoint spawns $LCFROOT/dat/1/cache/bin/solaris2/TAS/TASK_LIBRARY/task_endpoint as root to execute the requested task.
7. Before spawning the actual task, task_endpoint must switch to the user ID
under which the task is supposed to run. If a group ID was specified, it must
be changed to this ID as well.
8. The user runs the task on the same endpoint again.
9. The endpoint checks its cache index, finds task_endpoint, and requests that the
gateway compare the signature to task_endpoint in the gateway’s /lcf_bundle
directory. If they match, task execution proceeds. If they do not match, meaning
that task_endpoint in the gateway’s /lcf_bundle is newer (from a patch) than
what is in the cache, then the endpoint downloads the new task_endpoint and
task execution proceeds.
Steps 7 and 9 can cause problems in a Tivoli Access Manager environment. For
step 7, appropriate policy must be implemented to allow task_endpoint to switch
to execution ID. This can be accomplished by registering task_endpoint as an
impersonator program (/OSSEAL/policy-branch/TCB/Impersonator-Programs/LCFROOT/dat/1/cache/bin/cache/bin/ solaris2/TAS/TASK_LIBRARY/task_endpoint).
If a new task_endpoint is downloaded, as in step 9, then task_endpoint becomes
untrusted. The pdosobjsig command can be used to re-trust task_endpoint.
Take this information into account when changing the user ID that the PDOS Tasks
run under and implement policy appropriate to your environment.
Chapter 6. Using the Tivoli desktop to perform management tasks 177
General information about wrunjob and wruntask
You can use the wrunjob and wruntask commands to run the Tivoli Access
Manager for Operating Systems tasks from a script, and you can use the
wschedjob command to schedule jobs. In the following sections, each Tivoli Access
Manager for Operating Systems task description includes the arguments required
for wruntask and wrunjob. All arguments listed must be used, and they must be
used in the order shown. For more information about the wruntask and wrunjob
commands, as well as the wschedjob command for scheduling jobs, see the Tivoli
Management Framework: Reference Manual.
Add and remove PDOS auditors and administrators
This task can be used to add or remove users as Tivoli Access Manager for
Operating Systems auditors or administrators. To add a user as an administrator,
you must make the user a member of the local UNIX group, osseal, and a member
of the associated Tivoli Access Manager group, osseal-admin. To add a user as an
auditor, you must make the user a member of the local UNIX group, ossaudit, and
a member of the associated Tivoli Access Manager group, osseal-auditors.
To remove a user’s privileges as an administrator, you should remove the user
from the osseal group. To remove a user’s privileges as an auditor, you should
remove the user from the ossaudit group. If you remove the user from
osseal-auditors or osseal-admin, you remove the user’s auditor or administrator
privileges on all Tivoli Access Manager for Operating Systems machines. Both the
Add and Remove actions to osseal-auditors and osseal-admin require a Tivoli
Access Manager administrator name and password to be specified.
Note: All of the Tivoli Access Manager for Operating Systems Management Tasks
run as root on the target system. The tasks rely on the root user’s privileges
as a Tivoli Access Manager for Operating Systems runtime administrator. If
the root user ID is removed as a Tivoli Access Manager for Operating
Systems runtime administrator, the tasks must be modified to run as a
different runtime administrator. See the Tivoli Management Framework: User’s
Guide for more information about task libraries, tasks, and jobs.
The following window corresponds to the Add/Remove PDOS
Auditors/Administrators task:
178 Administration Guide
Use the following steps to perform this task:
1. If the user is to be added to or removed from the osseal-auditors or
osseal-admin, group you must specify the first two fields.
Note: When you type the password, the characters are not masked. When the
password is sent over the network to the target machine, it is not
encrypted. The password could be intercepted, which might compromise
security.
2. Specify the name of the user to be added or removed.
3. Select the desired operation: Add or Remove.
4. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Add/Remove PDOS Auditors/Administrators" –l "PDOS Tasks" –a
pd_admin_id –a pd_admin_passwd –a account –a action –a ossaudit –a
osseal_auditors –a osseal –a osseal_admin
v wruntask –t "Add/Remove PDOS Auditors/Administrators" –l "PDOS Tasks" –a
pd_admin_id –a pd_admin_passwd –a account –a action –a ossaudit –a
osseal_auditors –a osseal –a osseal_admin –h task_endpoint
Figure 3. Add/Remove PDOS Auditors/Administrators task window
Chapter 6. Using the Tivoli desktop to perform management tasks 179
where:
pd_admin_id
Specifies the name of a Tivoli Access Manager Administrative account to
use to perform the add or remove action. This argument is required only
when osseal_auditors or osseal_admin is set to True.
pd_admin_passwd
Specifies the password of the administrative account. This argument is
required when osseal_auditors or osseal_admin is set to True.
Note: When the password is sent over the network to the target machine,
it is not encrypted. The password could be intercepted, which might
compromise security.
account
Specifies the user account from which to add or remove privileges.
Completion of this parameter is required.
action Specifies whether to add or remove privileges from the specified account.
This value must be ADD or REMOVE.
ossaudit
If this parameter is set to TRUE, the user is added to or removed from the
local UNIX group, ossaudit. This value must be TRUE or FALSE.
osseal_auditors
If this parameter is set to TRUE, the user is added to or removed from the
Tivoli Access Manager group, osseal-auditors. This value must be TRUE or
FALSE.
osseal If this parameter is set to TRUE, the user is added to or removed from the
local UNIX group, osseal. This value must be TRUE or FALSE.
osseal_admin
If this parameter is set to TRUE, the user is added to or removed from the
Tivoli Access Manager group, osseal-admin. This value must be TRUE or
FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Backup PDOS database
This task allows the administrator to back up the Tivoli Access Manager for
Operating Systems databases and configuration files to an optionally specified file
name. The file name can be specified as a relative or absolute path. If the path is
relative, it is assumed relative to the directory /var/pdos/pdosbkup. The file name
can contain format characters that are supported by the date command. These
characters are automatically expanded. If not specified, the file name defaults to
/var/pdos/pdosbkup/pdosbkup%m%d%y.tar.
By default, backup files can be restored on a machine that is configured as a Tivoli
Access Manager client. Extended backup files can be created to restore a machine
to a working state in an isolated environment where the Tivoli Access Manager
server is not available.
180 Administration Guide
The following window corresponds to the Backup PDOS Database task:
Use the following steps to perform this task:
1. Type a name for the Tivoli Access Manager for Operating Systems database
backup file. This can be specified as an absolute or relative path; if relative, it is
assumed relative to /var/pdos/backup. The file name can contain format
characters as supported by the date command. These characters are
automatically expanded. If unspecified, the file name used is
/var/pdos/pdosbkup/pdosbkup%m%d%y.tar.
2. If an extended backup is required, check Perform extended backup.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Backup PDOS Database" –l "PDOS Tasks" –a file_name –a
extended_backup
v wruntask –t "Backup PDOS Database" –l "PDOS Tasks" –a file_name –a
extended_backup –h task_endpoint
where:
file_name
Specifies the file name in which to store the database backup. If this value
is the empty string, the default name is used.
extended_backup
Specifies whether or not to perform an extended backup. The value is TRUE
or FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Figure 4. Backup PDOS Database task window
Chapter 6. Using the Tivoli desktop to perform management tasks 181
Branch configuration
This task can be used to control the configuration of a Tivoli Access Manager for
Operating Systems machine to multiple policy branches. During configuration a
machine is configured to its initial policy branch using the –branch option of the
pdoscfg command. Use this task to configure a machine to additional policy
branches and to modify the precedence order of the configured policy branches for
that machine.
To configure a machine to an additional policy branch, set the Add Branch radio
button. With this option, you can use the Position field to specify the position in
the precedence order of the added policy branch. If the Position field is not
specified, the policy branch is placed at the lowest precedence.
To change the precedence order of the policy branches for a machine, set the Move
Branch radio button. With this option, you can use the Position field to specify the
new position for a policy branch in the precedence order. If the Position field is
not specified, the policy branch is placed at the lowest precedence.
The position specifies the position in the precedence order with 1 being of highest
precedence. If you specify 2 when either the Add Branch or Move Branch radio
button is set, the specified policy branch is placed second in the precedence order
and any of the other branches are shifted accordingly to a lower precedence. If the
Position field specifies a number that is greater than the number of configured
policy branches, the policy branch is placed at the lowest precedence.
To unconfigure a machine from a policy branch, set the Delete Branch radio
button.
The following window corresponds to the Branch Configuration task:
Use the following steps to perform this task:
1. Select the branch operation that you want to perform:
Figure 5. Multiple Branch Configuration task window
182 Administration Guide
v Add Branch
v Delete Branch
v Move Branch
2. In the Policy Branch Name field, specify the name of the policy branch to add,
delete, or move.
3. In the Position field for an add or move operation, optionally type the position
for the policy branch.
4. In the Access Manager Administrator password field, type the password for
the Tivoli Access Manager administrator that was used to configure Tivoli
Access Manager for Operating Systems.
5. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Branch Configuration" –l "PDOS Tasks" –a branch_operation –a
branch_name –a position –a admin_password
v wruntask –t "Branch Configuration" –l "PDOS Tasks" –a –h task_endpoint
where:
branch_operation
Specifies the configuration operation to perform. The following values are
valid, and must be enclosed in quotation marks:
v "Add Branch"
v "Delete Branch"
v "Move Branch"
branch_name
Specifies the name of the policy branch to add, delete, or move.
position
Specifies the position in the precedence order for the policy branch within
the configuration.
admin_password
Specifies the Tivoli Access Manager administrator password.
The Tivoli Access Manager administrator name is retrieved from the
configuration file.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Certificate transfer utility
Before a managed node or endpoint can be installed with Tivoli Access Manager
for Operating Systems, it must have the digital CA certificates needed to configure
both the Tivoli Access Manager runtime environment and Tivoli Access Manager
for Operating Systems.
Tivoli Access Manager for Operating Systems requires the SSL certificate used by
the user registry server for SSL communications as well as the CA certificate for
the Tivoli Access Manager policy server. If the policy server is not configured to
automatically download the CA certificate during the configuration of the Tivoli
Chapter 6. Using the Tivoli desktop to perform management tasks 183
Access Manager runtime environment, the certificate must be obtained manually
from the policy server. This task provides an easy method to transfer the two
certificates to target systems. The two certificates must be placed in directories on a
managed node. The certificates do not need to be in the same directory. The task
itself generates tasks that will be run on each destination system selected.
The following window corresponds to the Certificate Transfer Utility task:
Use the following steps to perform this task:
1. Type the path name for the User registry SSL certificate. This path name must
be on the Tivoli server. It must be readable by the root user.
2. Type the path name for the policy server certificate. This path name must be
on the Tivoli server. It must be readable by the root user.
3. Type the path name for the Destination Directory on the target systems. It
must be writable by the root user.
4. Specify the desired Destination Systems.
5. Click Okay to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Certificate_Transfer" –l "PDOS Tasks" –a ssl_certificate –a
ca_certificate –a dest_directory –a dest_system [–a dest_system,...]
v wruntask –t "Certificate_Transfer" –l "PDOS Tasks" –a ssl_certificate –a
ca_certificate –a dest_directory –a dest_system [–a dest_system,...] –h
task_endpoint
Figure 6. Certificate Transfer Utility task window
184 Administration Guide
Note: While the Tivoli Access Manager for Operating Systems installation program
requires that the installation images be put on a local directory, the
certificates can be placed in a common network location. Use this task if you
cannot use other methods, such as FTP, to transfer the certificates to a Tivoli
Access Manager for Operating Systems target system.
where:
ssl_certificate
Specifies the path name of the user registry SSL certificate.
ca_certificate
Specifies the path name of the Tivoli Access Manager server certificate.
dest_directory
Specifies the destination directory.
dest_system
Specifies the destination system. Destination systems must be specified as
"system(Endpoint)" or "system(ManagedNode)".
task_endpoint
Specifies the name of the managed node where the certificates to be
transferred are stored. This task should not be run on an endpoint or
profile manager.
Configure audit health
Tivoli Access Manager for Operating Systems supports the generation of audit
records that pertain to its health. With health auditing, you can monitor the
availability of Tivoli Access Manager for Operating Systems daemons and can
monitor the lifetime of the certificates that are used to communicate with the Tivoli
Access Manager user registry. Health auditing is a global audit level.
To generate audit records that monitor the availability of Tivoli Access Manager for
Operating Systems daemons, set the Enable Heartbeat check box and specify an
interval in minutes to configure the generation of heartbeat audit records.
To generate audit records that monitor the lifetime of the certificates that are used
to communicate with the Tivoli Access Manager user registry, set the Enable
Certificate Lifetime check box and specify a threshold in days and an interval in
days to configure the generation of certificate lifetime audit records. When
controlling the generation of certificate lifetime audit records, you also control the
generation of certificate expiration warning messages that are written to the
daemon log files.
The following window corresponds to the Configure Audit Health task:
Chapter 6. Using the Tivoli desktop to perform management tasks 185
Use the following steps to perform this task:
1. To monitor Tivoli Access Manager for Operating Systems availability:
a. Select Enable Heartbeat.
b. In the Heartbeat Interval field, type the interval in minutes.2. To monitor certificate lifetimes:
a. Select Enable Certificate Lifetime.
b. In the Certificate Threshold field, type the threshold in days.
c. In the Certificate Interval field, type the interval in days.3. To disable all audit health monitoring, select Disable Audit Health.
4. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Configure Audit Health" –l "PDOS Tasks" –a enable_heartbeat –a
heartbeat_interval –a enable_lifetime –a certificate_threshold –a
certificate_interval –a disable_audit_health
v wruntask –t "Configure Audit Health" –l "PDOS Tasks" –a enable_heartbeat
–a heartbeat_interval –a enable_lifetime –a certificate_threshold –a
certificate_interval –a disable_audit_health –h task_endpoint
where:
Figure 7. Audit Health Configuration task window
186 Administration Guide
enable_heartbeat
Indicates whether to enable health auditing to monitor the availability of
Tivoli Access Manager for Operating Systems daemons. Valid values are
TRUE and FALSE.
heartbeat_interval
Specifies the interval in minutes between the generation of heartbeat audit
events.
enable_lifetime
Indicates whether to enable health auditing to monitor the lifetime of the
certificates that are used to communicate with the Tivoli Access Manager
user registry. Valid values are TRUE and FALSE.
certificate_threshold
Specifies the threshold in days after which the generation of certificate
lifetime audit records and the generation of certificate lifetime warning
messages becomes daily.
certificate_interval
Specifies the interval in days between the generation of certificate lifetime
audit records.
disable_audit_health
Indicates whether to disable audit health. Valid values are TRUE and FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Configure PDOS auditing
This task allows the administrator to modify the Tivoli Access Manager for
Operating Systems configuration parameters related to auditing.
Two parameters can be modified: the audit log size limit and the audit log flush
frequency. If a value is not specified, the configuration parameter is left unchanged.
Changes can be placed into effect immediately or can take effect at the next restart
of Tivoli Access Manager for Operating Systems.
The following window corresponds to the Configure PDOS Auditing task:
Figure 8. Configure PDOS Auditing task window
Chapter 6. Using the Tivoli desktop to perform management tasks 187
Use the following steps to perform this task:
1. Type values for the parameters you want to change. Parameters with no value
set are left unchanged.
2. If Tivoli Access Manager for Operating Systems should be restarted after
making the configuration changes, check Apply changes immediately.
Otherwise, changes do not take effect until the next restart of Tivoli Access
Manager for Operating Systems.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Configure PDOS Auditing" –l "PDOS Tasks" –a apply_now –a size –a
frequency
v wruntask –t "Configure PDOS Auditing" –l "PDOS Tasks" –a apply_now –a
size –a frequency –h task_endpoint
where:
apply_now
Indicates that Tivoli Access Manager for Operating Systems should be
restarted after the changes are made. This value must be TRUE or FALSE.
size Specifies the size limit for audit logs in bytes. If this value is the empty
string, no change is made.
frequency
Specifies the frequency of flushes to the audit log in seconds. If this value
is the empty string, no change is made.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Configure PDOS caching
This task allows the administrator to modify the Tivoli Access Manager for
Operating Systems configuration parameters related to caching.
Eight parameters can be modified: the refresh frequency of administrator
credentials, the refresh frequency of user credentials, the critical system users
group, the refresh frequency of critical system user credentials, how long to wait
for a response from the user registry before going into isolation mode, how long to
cache user credentials that have not been accessed, whether a host name resolution
cache should be used, and whether a user name resolution cache should be used.
If a value is not specified, the configuration parameter is left unchanged. Changes
can be placed into effect immediately or can take effect at the next restart of Tivoli
Access Manager for Operating Systems.
The following window corresponds to the Configure PDOS Caching task:
188 Administration Guide
Use the following steps to perform this task:
1. Type values for the parameters you want to change. If a value is left
unspecified, it is be left unchanged. The refresh intervals and credential hold
period are in minutes.
2. If Tivoli Access Manager for Operating Systems should cache host names and
IP addresses, check Cache hostname to IP address mapping.
3. If Tivoli Access Manager for Operating Systems should cache user/group
names and user/group IDs, check Cache username to uid/gid mapping.
4. If Tivoli Access Manager for Operating Systems should be restarted after
making the configuration changes, check Apply changes immediately.
Otherwise, changes do not take effect until the next restart of Tivoli Access
Manager for Operating Systems.
5. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Configure PDOS Caching" –l "PDOS Tasks" –a apply_now –a
admin_refresh –a user_refresh –a user_cred_hold –a cache_hosts –a
cache_users–a crit_cred_group –a crit_cred_refresh –a cred_response_wait
Figure 9. Configure PDOS Caching task window
Chapter 6. Using the Tivoli desktop to perform management tasks 189
v wruntask –t "Configure PDOS Caching" –l "PDOS Tasks" –a apply_now –a
admin_refresh –a user_refresh –a user_cred_hold –a cache_hosts –a
cache_users –a crit_cred_group –a crit_cred_refresh –a cred_response_wait
–h task endpoint
where:
apply_now
Indicates that Tivoli Access Manager for Operating Systems should be
restarted after the changes are made. This value must be TRUE or FALSE.
admin_refresh
Specifies how often cached administrator credentials should be refreshed in
minutes. If this value is the empty string, no change is made.
user_refresh
Specifies how often cached user credentials should be refreshed in minutes.
If this value is the empty string, no change is made.
user_cred_hold
Specifies how long to cache unaccessed user credentials in minutes. This
value must be greater than or equal to the configured values for the
administrator and user credentials refresh intervals. If this value is the
empty string, no change is made.
cache_hosts
Indicates whether host name resolution should use a local cache. This
value must be TRUE or FALSE.
cache_users
Indicates whether user name resolution should use a local cache. This
value must be TRUE or FALSE.
crit_cred_group
Specifies the name of the Tivoli Access Manager for Operating Systems
group whose members are treated as critical system users.
crit_cred_refresh
Specifies the amount of time (in minutes) between refreshes of the critical
user credentials.
cred_response_wait
Specifies the amount of time (in minutes) to wait for a response from the
user registry before going into isolation mode.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Configure PDOS logging
This task allows the administrator to modify the Tivoli Access Manager for
Operating Systems configuration parameters related to logging.
Eight configuration parameters related to logging can be modified. These
parameters specify the number of log files and the maximum number of entries
per log file to use for logging in the Tivoli Access Manager for Operating Systems
daemons, pdosd, pdoswdd, pdosauditd, pdoslpmd, and pdoslrd. If a value is not
190 Administration Guide
specified, the configuration parameter is left unchanged. Changes can be placed
into effect immediately or can take effect at the next restart of Tivoli Access
Manager for Operating Systems.
The following window corresponds to the Configure PDOS Logging task:
Use the following steps to perform this task:
Figure 10. Configure PDOS Logging task window
Chapter 6. Using the Tivoli desktop to perform management tasks 191
1. Type values for the parameters that you want to change. If a value is not
specified, the parameter remains unchanged.
2. To restart Tivoli Access Manager for Operating Systems to apply these changes,
check Apply changes immediately. Otherwise, these changes take effect at the
next restart of Tivoli Access Manager for Operating Systems.
3. Click Execute and Close.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Configure PDOS Logging" –l "PDOS Tasks" –a apply_now –a
pdosd_logs –a pdosd_entries –a pdoswdd_logs –a pdoswdd_entries –a
pdosauditd_logs –a pdosauditd_entries –a pdoslrd_logs –a
pdoslrd_entries –a pdoslpmd_logs –a pdoslpmd_entries
v wruntask –t "Configure PDOS Logging" –l "PDOS Tasks" –a apply_now –a
pdosd_logs –a pdosd_entries –a pdoswdd_logs –a pdoswdd_entries –a
pdosauditd_logs –a pdosauditd_entries –a pdoslrd_logs –a
pdoslrd_entries –a pdoslpmd_logs –a pdoslpmd_entries –h task_endpoint
where:
apply_now
Indicates that Tivoli Access Manager for Operating Systems should be
restarted after the changes are made. This value must be TRUE or FALSE.
pdosd_logs
Specifies the number of log files to use for the pdosd daemon. If this value
is the empty string, the parameter is left unchanged.
pdosd_entries
Specifies the number of entries to allow per log for the pdosd daemon. If
this value is the empty string, the parameter is left unchanged.
pdoswdd_logs
Specifies the number of log files to use for the pdoswdd daemon. If this
value is the empty string, the parameter is left unchanged.
pdoswdd_entries
Specifies the number of entries to allow per log for the pdoswdd daemon.
If this value is the empty string, the parameter is left unchanged.
pdosauditd_logs
Specifies the number of log files to use for the pdosauditd daemon. If this
value is the empty string, the parameter is left unchanged.
pdosauditd_entries
Specifies the number of entries to allow per log for the pdosauditd
daemon. If this value is the empty string, the parameter is left unchanged.
pdoslrd_logs
Specifies the number of log files to use for the pdoslrd daemon. If this
value is the empty string, the parameter is left unchanged.
pdoslrd_entries
Specifies the number of entries to allow for the pdoslrd daemon. If this
value is the empty string, the parameter is left unchanged.
192 Administration Guide
pdoslpmd_logs
Specifies the number of log files to use for the pdoslpmd daemon. If this
value is the empty string, the parameter is left unchanged.
pdoslpmd_entries
Specifies the number of entries to allow for the pdoslpmd daemon. If this
value is the empty string, the parameter is left unchanged.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Configure PDOS login and password policy
This task allows the administrator to configure parameters related to Tivoli Access
Manager for Operating Systems login and password policy. The following policy
can be configured:
v Tivoli Access Manager for Operating Systems login and password policy can be
enabled or disabled. By default, the field is blank and does not change the
current setting.
v A specified user account can be locked, unlocked, have its login activity records
deleted, or have the password change date set to the current date.
The following window corresponds to the Configure PDOS Login and Password
Policy task:
Chapter 6. Using the Tivoli desktop to perform management tasks 193
Use the following steps to perform this task:
1. You can enable, disable, or leave Tivoli Access Manager for Operating Systems
login and password policy at its current setting.
2. In the Concurrent Authentication Limit field, specify the maximum number of
pending login failures to authenticate.
3. In the Login Failure Audit Interval field, specify the maximum amount of
time, in seconds, for login failures to be authenticated.
4. Specify the User account to be modified.
5. Select the operation you want to perform.
6. Specify whether to reset the date.
7. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Configure PDOS Login and Password Policy" –l "PDOS Tasks" –a
enable_login –a pending_logins –a failure_audit –a account –a action
Figure 11. Configure PDOS Login and Password Policy task window
194 Administration Guide
v wruntask –t "Configure PDOS Login and Password Policy" –l "PDOS Tasks" –a
enable_login –a pending_logins –a failure_audit –a account –a action -h
task_endpoint
where:
enable_login
Indicates whether or not to enable Tivoli Access Manager for Operating
Systems login and password policy processing. This value must be TRUE or
FALSE. If this value is the empty string, no change is made.
account
If this parameter is not blank, the action specified in the action parameter
is performed on the specified user account.
action Indicates what action to perform on the specified account. Valid values are
DELETE, LOCK, UNLOCK, and CHANGEDATE.
pending_logins
Specifies the maximum number of records to track for login failures.
failure_audit
Specifies the maximum amount of time in seconds that will pass before the
pdoslpmd daemon audits login failures.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Configure PDOS server
This task allows the administrator to modify miscellaneous Tivoli Access Manager
for Operating Systems configuration parameters.
The following parameters can be modified:
v The port Tivoli Access Manager for Operating Systems uses to receive
notifications of policy updates
v How often (in minutes) policy refreshes occur
v Whether system login and password restrictions are enabled
v The number of kernel threads used to handle authorization requests
v The certificate used to communicate and authenticate with the user registry
server
v Whether Tivoli Access Manager for Operating Systems should be automatically
started at system startup
v Whether first failure data should be captured when a Tivoli Access Manager for
Operating Systems daemon dies
v Whether to configure the Tivoli Access Manager for Operating Systems log
router daemon
v Whether to configure the Common Auditing and Reporting Service server
Note: There are four configuration options for configuring the Common
Auditing and Reporting Service server. These options are not available
from the Tivoli desktop task. These options can be specified only when
using the wrunjob or wruntask command.
If a value is not specified, the configuration parameter is left unchanged.
Chapter 6. Using the Tivoli desktop to perform management tasks 195
The following window corresponds to the Configure PDOS Server task:
Use the following steps to perform this task:
1. Tivoli Access Manager for Operating Systems can be configured to receive
policy update notifications on a specified port. If the Policy Update
Notification Port is set to 0, policy updates will not be received by notification.
If a value is not specified, the parameter is left unchanged.
Note: The security master password is not required unless using Tivoli Access
Manager for Operating Systems, version 4.1 and earlier. When you type
the password, the characters are not masked. When the password is sent
Figure 12. Configure PDOS Server task window
196 Administration Guide
over the network to the target machine, it is not encrypted. The
password could be intercepted, which might compromise security.
2. Tivoli Access Manager for Operating Systems can be configured to poll the
Tivoli Access Manager policy server for policy updates. The Policy Update
Polling Interval is specified in minutes, and a value of 0 will disable policy
update polling. If a value is not specified, the parameter will be left unchanged.
3. Tivoli Access Manager for Operating Systems can be enabled or disabled to
enforce system login and password restrictions. If a value is not specified, the
parameter will be left unchanged.
4. The number of kernel threads used to handle authorization requests can be
changed. This value must be positive. If a value is not specified, the parameter
will be left unchanged.
5. The User registry SSL CA certificate can be changed by supplying the full
path name to the file that contains the new SSL CA certificate. If a value is not
specified, the parameter will be left unchanged.
6. Tivoli Access Manager for Operating Systems can be configured to capture first
failure data.
7. The startup behavior of Tivoli Access Manager for Operating Systems can be
changed with the Automatically start PDOS at system startup box. If a value
is not specified, the parameter will be left unchanged.
8. The configuration of the log router daemon can be changed with the Configure
Log Router Daemon box. A Tivoli Access Manager administrator name and
password must be supplied to change the configuration. You can specify to
which Tivoli Access Manager local domain the log router daemon will be
configured. If no domain is specified, the system will try to use the local
domain to which pdosd is configured.
Note: When you type the password, the characters are not masked. When the
password is sent over the network to the target machine, it is not
encrypted. The password could be intercepted, which might compromise
security.
9. Click Execute and Close to perform the task. The Tivoli Access Manager for
Operating Systems instance will be restarted with the new configuration.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Configure PDOS Server" –l "PDOS Tasks" –a notification_port –a
password –a refresh_interval –a login_policy –a threads –a
ssl_certificate –a autostart –a password –a first_failure –a lrd_config
–a lrd_local_domain –a lrd_admin_name –a lrd_admin_pwd -a
lrd_cars_server_label -a lrd_cars_ssl_cacert -a lrd_cars_user_name -a
lrd_cars_user_name_password
v wruntask –t "Configure PDOS Server" –l "PDOS Tasks" –a notification_port
–a password –a refresh_interval –a login_policy –a threads –a
ssl_certificate –a autostart –a password –a first_failure –a lrd_config
–a lrd_local_domain –a lrd_admin_name –a lrd_admin_pwd -a
lrd_cars_server_label -a lrd_cars_ssl_cacert -a lrd_cars_user_name -a
lrd_cars_user_name_password –h task_endpoint
where:
Chapter 6. Using the Tivoli desktop to perform management tasks 197
notification_port
Specifies a port to use to receive policy update notifications. A value of
zero will disable policy update notifications. If this value is the empty
string, the parameter is left unchanged. A password must be specified to
change this parameter.
refresh_interval
Specifies an interval in minutes that the Tivoli Access Manager policy
server is polled for policy updates. A value of zero will disable policy
updates polling. If this value is the empty string, the parameter is left
unchanged.
login_policy
Specifies whether Tivoli Access Manager for Operating Systems should
enforce system login and password restrictions. This value can be TRUE,
FALSE, or the empty string.
threads Specifies the number of kernel threads used to handle authorization
requests. If this value is the empty string, the parameter is left unchanged.
password
Specifies the security master password.
Note: This password only needs to be specified to change the notification
port for Tivoli Access Manager for Operating Systems, version 4.1
and earlier. When the password is sent over the network to the
target machine, it is not encrypted. The password could be
intercepted, which might compromise security.
ssl_certificate
Specifies the SSL CA certificate to communicate and authenticate with the
user registry server. A full path name to the file that contains the SSL CA
certificate must be specified. If this value is the empty string, the
parameter is left unchanged. A password must be specified to change this
parameter.
autostart
Specifies whether Tivoli Access Manager for Operating Systems should be
automatically started at system startup. This value can be TRUE, FALSE, or
the empty string.
first_failure
Indicates that first failure data should be automatically captured when a
Tivoli Access Manager for Operating Systems daemon dies. The value must
be TRUE or FALSE.
lrd_config
Specifies whether the Tivoli Access Manager for Operating Systems log
router daemon should be configured. This value can be TRUE, FALSE, or the
empty string.
lrd_local_domain
Specifies the Tivoli Access Manager local domain name that the log router
daemon will be configured to. If this value is not specified, the system will
try to use the local domain to which pdosd is configured.
lrd_admin_name
Specifies a Tivoli Access Manager administrator name.
lrd_admin_pwd
Specifies a Tivoli Access Manager administrator password.
198 Administration Guide
Note: When the password is sent over the network to the target machine,
it is not encrypted. The password could be intercepted, which might
compromise security.
lrd_cars_server_label
Specifies the label of the CA certificate to add for the specified Common
Auditing and Reporting Service event server.
lrd_cars_ssl_cacert
Specifies the file name of the CA certificate of the Common Auditing and
Reporting Service event server that receives Tivoli Access Manager for
Operating Systems auditing events. This certificate is required for the
mutual authentication that occurs between Tivoli Access Manager for
Operating Systems and Common Auditing and Reporting Service event
server and for the encryption of audit records that are sent to the Common
Auditing and Reporting Service event server.
lrd_cars_user_name
Specifies the user name to add for authenticating with Common Auditing
and Reporting Service event servers. This option, along with the password
for this user, is required if the event server is configured to authenticate
with the client.
lrd_cars_user_name_password
Specifies the password for the user that is used to authenticate with the
Common Auditing and Reporting Service event servers.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Configure PDOS TCB
This task allows the administrator to modify the Tivoli Access Manager for
Operating Systems configuration parameters related to the Trusted Computing
Base (TCB). The following parameters can be modified:
v The number of monitoring threads
v The delay interval (in seconds) between monitoring attempts
v The maximum number of megabytes of a file to be used for calculating a
checksum (TCB signature)
v Whether to ignore ctime of the file in TCB signature comparisons
v Whether to perform the CRC checksum calculation and comparison during
execution authorizations
If a value is not specified for the first three parameters, the configuration
parameter is left unchanged. Changes can be placed into effect immediately or wait
until the next restart of Tivoli Access Manager for Operating Systems.
The following window corresponds to the Configure PDOS TCB task:
Chapter 6. Using the Tivoli desktop to perform management tasks 199
Use the following steps to perform this task:
1. Type values for the parameters you want to change. If a value is not specified,
the parameter will be left unchanged.
2. If Tivoli Access Manager for Operating Systems should be restarted after
making the configuration changes, check Apply changes immediately.
Otherwise, changes will not take effect until the next restart of Tivoli Access
Manager for Operating Systems.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Configure PDOS TCB" –l "PDOS Tasks" –a apply_now –a threads –a
interval –a checksum_max_size –a ignore_ctime –a nocrc_on_exec
v wruntask –t "Configure PDOS TCB" –l "PDOS Tasks" –a apply_now –a threads
–a interval –a checksum_max_size –a ignore_ctime –a nocrc_on_exec -h
task_endpoint
where:
apply_now
Indicates that Tivoli Access Manager for Operating Systems should be
restarted after the changes are made. This value must be TRUE or FALSE.
threads Specifies the number of threads used to monitor TCB objects. If this value
is the empty string, the parameter is left unchanged.
interval
Specifies the interval in seconds between monitoring sweeps of the TCB. If
this value is the empty string, the parameter is left unchanged.
checksum_max_size
Specifies the maximum number of megabytes of a file to be used when
computing its checksum (TCB signature). The bytes are distributed
throughout the file. If this value is the empty string, the parameter is left
unchanged.
Figure 13. Configure PDOS TCB task window
200 Administration Guide
ignore_ctime
If this parameter is set toTRUE (enabled), the ctime is ignored in all TCB
signature comparisons. A change in ctime does not cause the TCB resource
to become untrusted. This value must be TRUE or FALSE. The default value
is FALSE.
nocrc_on_exec
If this parameter is set to TRUE (enabled), the CRC data checksum
calculation and comparison will be skipped on TCB signature checks
during Tivoli Access Manager for Operating Systems execution
authorization processing. This value must be TRUE or FALSE. The default
value is FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Display PDOS host name cache
This task allows the administrator to view entries in the IP address and host name
translation cache used by Tivoli Access Manager for Operating Systems.
All stale entries, all valid entries, or both, might be displayed.
The following window corresponds to the Display PDOS Hostname Cache task:
Use the following steps to perform this task:
1. Select the types of entries to display: expired, valid, or both.
2. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Display PDOS Hostname Cache" –l "PDOS Tasks" –a display_valid –a
display_stale
v wruntask –t "Display PDOS Hostname Cache" –l "PDOS Tasks" –a
display_valid –a display_stale –h task_endpoint
where:
Figure 14. Display PDOS Hostname Cache
Chapter 6. Using the Tivoli desktop to perform management tasks 201
display_valid
Indicates that all valid entries should be displayed. This value must be
TRUE or FALSE.
display_stale
Indicates that all stale entries should be displayed. This value must be TRUE
or FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Distribute log router daemon control file
A file, pdoslrd.xml, is used to specify the various parameters necessary to run the
Tivoli Access Manager for Operating Systems log router daemon, pdoslrd. The
format of this file must comply with the XML 1.0 specification. This task provides
an easy method to distribute pdoslrd.xml to target systems. The file must be
placed in a directory on a managed node. The task itself generates tasks that run
on each destination system that you select.
The following window corresponds to the Distribute Log Router Daemon Control
File task:
Use the following steps to perform this task:
1. Type the path name for the pdoslrd.xml file. This path name must be on the
Tivoli server and it must be readable by the root user.
2. Specify the desired destination systems.
3. Click OK to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
Figure 15. Distribute Log Router Daemon Control File
202 Administration Guide
v wrunjob "Distribute_Log_Router_Daemon_Control_File" –l "PDOS Tasks" –a
lrd_cont_file –a dest_system [–a dest_system,...]
v wruntask "Distribute_Log_Router_Daemon_Control_File" –l "PDOS Tasks" –a
lrd_cont_file –a dest_system [–a dest_system,...] –h task_endpoint
where:
lrd_cont_file
Specifies the path name of pdoslrd.xml file
dest_system
Specifies the destination systems. Destination systems must be specified as
"system(Endpoint)″ or "system(ManagedNode)".
task_endpoint
Specifies the name of the managed node where the file to be distributed is
stored. This task should not be run on an endpoint or profile manager.
Import UNIX TCB
This task allows the administrator to populate the Trusted Computing Base (TCB)
by recursively searching the UNIX system for setuid and setgid programs.
The administrator must specify the class of resources to populate:
Immune-Surrogate-Programs, Secure-Files, Impersonator-Programs, or
Immune-Programs. The default is Secure-Programs. Additionally, one or more
directories to recursively search can be supplied in the form of a comma-separated
list. If desired, another list of directories to exclude from the search can be
provided. A specific policy branch into which to populate can optionally be
supplied. If omitted, the current subscribed policy branch is used. Also, you can
choose whether to generate a script to update the TCB with records for the
discovered files or simply report the discovered files.
Finally, you can choose whether or not to add multiple entries to the TCB for hard
links to files.
The following window corresponds to the Import UNIX TCB task:
Chapter 6. Using the Tivoli desktop to perform management tasks 203
Use the following steps to perform this task:
1. Choose the category of files on which to search.
2. As an option, you can specify directories to be included or excluded from the
search.
3. If the files discovered in the file system search should generate a script to
update the TCB, check Generate update script. Otherwise, the found files will
be reported in a window.
4. If files with hard links to them should generate multiple entries in the TCB,
check Generate duplicate entry for hard links. Otherwise, one entry will be
generated regardless of the number of links to the file.
5. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Import UNIX TCB" –l "PDOS Tasks" –a class –a branch –a
directories –a excludes –a duplicate_links –a generate_script
v wruntask –t "Import UNIX TCB" –l "PDOS Tasks" –a class –a branch –a
directories –a excludes –a duplicate_links –a generate_script –h
task_endpoint
where:
class Specifies the class of TCB resource to create. This must be one of the
classes listed above.
branch Specifies into which policy branch to import TCB resources. If empty, the
currently subscribed policy branch is used.
directories
Specifies a comma-separated list of directories to recursively search.
excludes
Specifies a comma-separated list of directories to exclude from the search.
Figure 16. Import UNIX TCB task window
204 Administration Guide
duplicate_links
Indicates whether multiple entries should be generated for hard linked
files. This value must be TRUE or FALSE.
generate_script
Indicates that a script should be generated to add the discovered files to
the TCB. This value must be TRUE or FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Import UNIX users and groups
This task allows the administrator to populate the Tivoli Access Manager user
registry using local native operating system account information.
The users and groups that are provided in comma-separated lists are used to
obtain account data from native operating system user registry. Each list can be
inclusive or exclusive. An inclusive list means that only those specified users and
groups should be imported. An exclusive list means that all users and groups except
for the ones specified should be imported. A list value of * indicates all users. List
entries must be user names and group names, not their UID or GID, respectively.
A user registry suffix to be appended to the created users groups must be
specified. An administrative account in Tivoli Access Manager and its password
are also required to import data. You can specify how to import account data that
already exists in user registry. If a user or group to be imported has a
corresponding entry in the user registry, an administrator can specify whether to
import the information from the user registry.
Note: You cannot use this task when Tivoli Access Manager is configured to
multiple Active Directory domains and Tivoli Access Manager for Operating
Systems is not configured. In this situation, use the pdosrgyimp command.
When Tivoli Access Manager for Operating Systems is configured and when
Tivoli Access Manager is configured to multiple Active Directory domains,
the Active Directory domain name from the osseal.conf configuration file is
used.
Optionally, the administrator can choose to only report on the accounts that would
be imported. For users, the administrator can specify whether accounts are created
enabled (the default) or disabled. The administrator can also specify a default
group for users without group membership and a default password (if empty, a
random password is assigned). For groups, the administrator can specify the
behavior when the group exists in Tivoli Access Manager. The administrator can
specify that group entries be refreshed for groups that already exist in Tivoli
Access Manager.
The following window corresponds to the Import UNIX Users and Groups task:
Chapter 6. Using the Tivoli desktop to perform management tasks 205
You can specify a Tivoli Access Manager local domain that the accounts will be
imported to. If you do not specify a local domain, the system will try to use the
domain to which pdosd is configured.
Use the following steps to perform this task:
1. You must specify the first three fields in the Access Manager block. All other
fields are optional.
Figure 17. Import UNIX Users and Groups
206 Administration Guide
Note: When you type the password, the characters are not masked. When the
password is sent over the network to the target machine, it is not
encrypted. The password could be intercepted, which might compromise
security.
2. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Import UNIX Users and Groups" –l "PDOS Tasks" –a admin_id –a
admin_pwd –a suffix –a registry_import –a report_only –a user_list –a
user_list_type –a create_disabled –a default_group –a default_passwd –a
group_list –a group_list_type –a group_refresh –a local_domain
v wruntask –t "Import UNIX Users and Groups" –l "PDOS Tasks" –a admin_id –a
admin_pwd –a suffix –a registry_import –a report_only –a user_list –a
user_list_type –a create_disabled –a default_group –a default_passwd –a
group_list –a group_list_type –a group_refresh –a local_domain –h
task_endpoint
where:
admin_id
Specifies the name of a Tivoli Access Manager administrative account to
use to import entries. Completion of this argument is required.
admin_pwd
Specifies the password of the administrative account. Completion of this
argument is required.
Note: When the password is sent over the network to the target machine,
it is not encrypted. The password could be intercepted, which might
compromise security.
suffix Specifies the user registry suffix to append to created users and groups.
Completion of this argument is required.
registry_import
Indicates that the user or group should be imported from user registry if it
exists there and it is not already a Tivoli Access Manager user or group.
This value must be TRUE or FALSE.
report_only
Indicates that the task should only report what it would do and not update
the database. This value must be TRUE or FALSE.
user_list
Specifies a comma-separated list of user names to import (or exclude from
import).
user_list_type
Indicates whether the list is of users to include or exclude. This value must
be Inclusive or Exclusive.
create_disabled
Indicates that users should be created disabled. This value must be must
be TRUE or FALSE.
Chapter 6. Using the Tivoli desktop to perform management tasks 207
default_group
Specifies a default Tivoli Access Manager group to which to add created
users if they have no group membership.
default_passwd
Specifies a default password to assign to the created users.
group_list
Specifies a comma-separated list of group names to import, or exclude
from import.
group_list_type
Indicates whether the list of groups is inclusive or exclusive. This value
must be Inclusive or Exclusive.
group_refresh
Indicates whether, if the group already exists, the group membership
should be updated to match the UNIX group. This value must be must be
TRUE or FALSE.
local_domain
Specifies a Tivoli Access Manager local domain to which the accounts will
be imported to. If you do not specify a local domain, the system tries to
use the domain to which Tivoli Access Manager for Operating Systems is
configured.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Manage PDOS credential cache
This task allows the administrator to refresh and/or destroy entries in the
credential cache used by Tivoli Access Manager for Operating Systems.
The administrator can specify two comma-separated lists. One list indicates the
credentials to refresh, and the other list indicates the credentials to destroy. Both
lists are optional. List entries can be a UID or a user name.
The following window corresponds to the Manage PDOS Credential Cache task:
Use the following steps to perform this task:
Figure 18. Manage PDOS Credential Cache task window
208 Administration Guide
1. Type a comma-separated list of users or UIDs whose cached credentials should
be refreshed. An empty list indicates no credentials should be refreshed. An
asterisk (*) indicates that all users currently in the credential cache should be
refreshed.
2. Type a comma-separated list of users or UIDs whose cached credentials should
be destroyed. An empty list indicates no credentials should be destroyed.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Manage PDOS Credential Cache" –l "PDOS Tasks" –a refresh_list –a
destroy_list
v wruntask –t "Manage PDOS Credential Cache" –l "PDOS Tasks" –a
refresh_list –a destroy_list –h task_endpoint
where:
refresh_list
Specifies UIDs/user names for which the cached credential should be
refreshed. If empty, no cached credentials are refreshed.
destroy_list
Specifies UIDs/user names for which the cached credential should be
removed. If empty, no cached credentials are removed.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Manage PDOS server state
This task allows the administrator to individually change the state of the daemons
that comprise a running Tivoli Access Manager for Operating Systems instance.
The pdosd, pdosauditd, pdoswdd, pdoslpmd, and pdoslrd daemons can be told:
Do Nothing
Leaves the state of the daemon state unchanged.
Start Starts any daemons not currently running in the Tivoli Access Manager for
Operating Systems instance.
Stop Stops the daemon, if it is not already stopped.
Restart
Stops the daemon in the Tivoli Access Manager for Operating Systems
instance and restarts it.
The following window corresponds to the Manage PDOS Server State task:
Chapter 6. Using the Tivoli desktop to perform management tasks 209
Use the following steps to perform this task:
1. Set the desired state changes for each daemon.
2. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Manage PDOS Server State" –l "PDOS Tasks" –a pdosd_state –a
pdosauditd_state –a pdoswdd_state –a pdoslpmd –a pdoslrd_state
Figure 19. Manage PDOS Server State task window
210 Administration Guide
v wruntask –t "Manage PDOS Server State" –l "PDOS Tasks" –a pdosd_state –a
pdosauditd_state –a pdoswdd_state –a pdoslpmd –a pdoslrd_state –h
task_endpoint
where:
pdosd_state
Indicates the change to make to the state of the pdosd daemon. If not
Start, Stop, or Restart, the state remains unchanged.
pdosauditd_state
Indicates the change to make to the state of the pdosauditd daemon. If not
Start, Stop, or Restart, the state remains unchanged.
pdoswdd_state
Indicates the change to make to the state of the pdoswdd daemon. If not
Start, Stop, or Restart, the state remains unchanged.
pdoslpmd_state
Indicates the change to make to the state of the pdoslpmd daemon. If not
Start, Stop, or Restart, the state remains unchanged.
pdoslrd_state
Indicates the change to make to the state of the pdoslrd daemon. If not
Start, Stop, or Restart, the state remains unchanged.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Manage PDOS TCB
This task allows the administrator to modify or validate the trust status of objects
in the Tivoli Access Manager for Operating Systems Trusted Computing Base
(TCB).
An operation and a comma-separated list of objects on which to apply the
operation must be supplied. The following operations are valid:
Trust Marks the specified objects as trusted.
Untrust
Marks the specified objects as untrusted.
Validate
Checks the signature of the specified objects and if they have been
modified, marks them untrusted.
Objects must be specified as absolute paths. A list value of * indicates all objects in
the TCB.
The following window corresponds to the Manage PDOS TCB task:
Chapter 6. Using the Tivoli desktop to perform management tasks 211
Use the following steps to perform this task:
1. Type a comma-separated list of objects in the TCB on which you wish to
modify the trust state. A value of * can be used to indicate all objects in the
TCB.
2. Select an operation to perform. Trust marks the files as trusted. Untrust marks
the files as untrusted. Validate checks the signature of the files and if they have
been modified, marks them untrusted.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Manage PDOS TCB" –l "PDOS Tasks" –a operation –a objects
v wruntask –t "Manage PDOS TCB" –l "PDOS Tasks" –a operation –a objects –h
task_endpoint
where:
operation
Indicates the operation to apply. It must be one of Trust, Untrust, or
Validate.
objects Specifies the objects to which to apply the operation. If this value is the
empty string, no objects are modified.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Purge PDOS host name cache
This task allows the administrator to remove entries from the IP address/host
name translation cache used by Tivoli Access Manager for Operating Systems.
Two non-exclusive options are available–removing all stale entries and removing
entries by name. Entries to be removed are specified by host name or IP address in
a comma-separated list. If this list contains the special value *, all entries are
removed. If the list is empty, no entries are removed.
Figure 20. Manage PDOS TCB task window
212 Administration Guide
The following window corresponds to the Purge PDOS Hostname Cache task:
Use the following steps to perform this task:
1. Type a comma-separated list of the IP addresses or host names that are to be
removed from the cache. The value * can be used to indicate all cache entries.
2. If cache entries that have exceeded their expiration date should be removed,
check Remove all stale entries from database.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Purge PDOS Hostname Cache" –l "PDOS Tasks" –a remove_entries –a
remove_stale
v wruntask –t "Purge PDOS Hostname Cache" –l "PDOS Tasks" –a remove_entries
–a remove_stale –h task_endpoint
where:
remove_entries
Indicates which entries to remove from the cache. If this value is the empty
string, no entries are removed.
remove_stale
Indicates whether stale entries should be removed. This value must be
TRUE or FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Query branch membership
This task can be used to report the machines that are subscribed to a particular
Tivoli Access Manager for Operating Systems branch.
The following window corresponds to the Query Branch Membership task:
Figure 21. Purge PDOS Hostname Cache task window
Chapter 6. Using the Tivoli desktop to perform management tasks 213
Use the following steps to perform this task:
1. Type the Tivoli Access Manager user name.
2. Type the password for the Tivoli Access Manager user.
Note: When you type the password, the characters are not masked. When the
password is sent over the network to the target machine, it is not
encrypted. The password could be intercepted, which might compromise
security.
3. Type the name of the policy branch whose membership you are trying to
determine.
4. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Query Branch Membership" –l "PDOS Tasks" –a pd_admin_id –a
pd_admin_passwd –a policy_branch
v wruntask –t "Query Branch Membership" –l "PDOS Tasks" –a pd_admin_id –a
pd_admin_passwd –a policy_branch –h task_endpoint
where:
pd_admin_id
Specifies the name of a Tivoli Access Manager for Operating Systems
account to use to perform the query.
pd_admin_passwd
Specifies the password of the user account.
Note: When the password is sent over the network to the target machine,
it is not encrypted. The password could be intercepted, which might
compromise security.
policy_branch
Specifies which policy branch to report the subscribed machines for.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name: separate
multiple names with spaces.
Figure 22. Query Branch Membership task window
214 Administration Guide
Query PDOS login and password policy
This task allows the administrator to generate reports related to Tivoli Access
Manager for Operating Systems login and password policy. Two types of reports
can be generated:
v Reports can be created that show the status of user accounts or that show all
details related to a user’s record in the Tivoli Access Manager for Operating
Systems Login Activity Database.
v Reports can be created detailing the default login and password policy for all
users or the policy for specific users.
The following window corresponds to the Query PDOS Login and Password
Policy task:
Use the following steps to perform this task:
1. If you want to generate a user status report, click Generate user status report
and specify the reporting requirements.
2. A comma-separated list of users whose status should be queried can be
specified.
3. For login and password information, click Display login and password policy.
Figure 23. Query PDOS Login and Password Policy task window
Chapter 6. Using the Tivoli desktop to perform management tasks 215
4. A comma-separated list of users whose login and password policy should be
reported can be specified.
5. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Query PDOS Login and Password Policy" –l "PDOS Tasks" –a
generate_report –a detailed –a enabled –a disabled –a report_users –a
display_policy –a policy_users
v wruntask –t "Query PDOS Login and Password Policy" –l "PDOS Tasks" –a
generate_report –a detailed –a enabled –a disabled –a report_users –a
display_policy –a policy_users –h task_endpoint
where:
generate_report
Indicates whether or not to create a report showing the user entries in the
Tivoli Access Manager for Operating Systems Login Activity Database. This
value must be TRUE or FALSE.
detailed
Specifies if the user status report should include detailed information on
each user entry, or simply its status. This value must be TRUE or FALSE.
enabled If this parameter is set to TRUE, only unlocked (enabled) user entries are
shown. If this parameter is set to TRUE, disabled cannot also be set to TRUE.
disabled
If this parameter is set to TRUE, only locked (disabled) user entries are
shown. If this parameter is set to TRUE, enabled cannot also be set to TRUE.
report_users
A comma-separated list of users can be specified. Only the user entries
from the users in the list are reported.
display_policy
Indicates whether or not to create a report showing the Tivoli Access
Manager for Operating Systems login and password policy. This value
must be TRUE or FALSE.
policy_users
A comma-separated list of users can be specified. Only the Tivoli Access
Manager for Operating Systems login and password policy for the users in
the list are reported. If this parameter is blank, then the default Tivoli
Access Manager for Operating Systems login and password policy are
reported.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Query PDOS server state
This task allows the administrator to individually determine the current state of
the daemons comprising a running Tivoli Access Manager for Operating Systems
instance.
216 Administration Guide
The following window corresponds to the Query PDOS Server State task:
Use the following steps to perform this task:
1. Select the daemons on which to report status.
2. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Query PDOS Server State" –l "PDOS Tasks" –a query_pdosd –a
query_pdosauditd –a query_pdoswdd –a query_pdoslpmd –a query_pdoslrd
v wruntask –t "Query PDOS Server State" –l "PDOS Tasks" –a query_pdosd –a
query_pdosauditd –a query_pdoswdd –a query_pdoslpmd –a query_pdoslrd –h
task_endpoint
where:
query_pdosd
Indicates whether the state of the pdosd daemon should be reported. It
must be TRUE or FALSE.
query_pdosauditd
Indicates whether the state of the pdosauditd daemon should be reported.
It must be TRUE or FALSE.
query_pdoswdd
Indicates whether the state of the pdoswdd daemon should be reported. It
must be TRUE or FALSE.
query_pdoslpmd
Indicates whether the state of the pdoslpmd daemon should be reported. It
must be TRUE or FALSE.
query_pdoslrd
Indicates whether the state of the pdoslrd daemon should be reported. It
must be TRUE or FALSE.
Figure 24. Query PDOS Server State task window
Chapter 6. Using the Tivoli desktop to perform management tasks 217
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Query PDOS TCB
This task allows the administrator to query the trust status of objects in the Tivoli
Access Manager for Operating Systems Trusted Computing Base (TCB).
A comma-separated list of objects on which to report the trust status must be
specified. Object names must be provided as absolute paths. You can use the
following special list values:
* Specifies all objects in the TCB.
AnyTrusted
Specifies all trusted objects in the TCB.
AnyUntrusted
Specifies all untrusted objects in the TCB.
The following window corresponds to the Query PDOS TCB task:
Use the following steps to perform this task:
1. Specify any general categories of file system objects to report using the Report
all trusted files or Report all untrusted files options.
2. Optionally, select any specific file system objects to be reported.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Query PDOS TCB" –l "PDOS Tasks" –a query_objects
v wruntask –t "Query PDOS TCB" –l "PDOS Tasks" –a query_objects –h
task_endpoint
where:
Figure 25. Query PDOS TCB task window
218 Administration Guide
query_objects
Specifies a list of objects on which to report the trust status. Three special
list values can be used:
* Specifies all objects in the TCB.
AnyTrusted
Specifies all trusted objects in the TCB.
AnyUntrusted
Specifies all untrusted objects in the TCB.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Restore PDOS database
This task allows the administrator to restore a specified Tivoli Access Manager for
Operating Systems backup file. The path to the backup file can be absolute or
relative. If the path is relative, it is assumed to be relative to /var/pdos/pdosbkup.
The following window corresponds to the Restore PDOS Database task:
Use the following steps to perform this task:
1. Type the name of a backup file to restore. The name can be an absolute path or
relative path; if relative, it is assumed relative to /usr/pdos/pdosbkup.
2. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Restore PDOS Database" –l "PDOS Tasks" –a filename
v wruntask –t "Restore PDOS Database" –l "PDOS Tasks" –a filename –h
task_endpoint
where:
filename
Specifies the name of a backup file to restore.
Figure 26. Restore PDOS Database task window
Chapter 6. Using the Tivoli desktop to perform management tasks 219
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Set PDOS server audit level
This task allows the administrator to set the global audit levels of the Tivoli Access
Manager for Operating Systems instance.
The audit level is specified as a mask with the possible masked events being
permitted accesses, denied accesses, administrative events, Tivoli Access Manager
for Operating Systems updates, permitted logins, denied logins, process
invocations, and accesses to protected files. Auditing can be made verbose. Tivoli
Access Manager for Operating Systems can also be placed in warning mode, where
accesses that are normally denied are granted, but an audit record is generated
indicating the bypass. In addition, a modifier indicating how and when the change
occurs must be supplied. The following modifiers are valid:
Permanent
Indicates the change are effective immediately and persist across a restart
of the instance.
Temporary
Indicates the change are effective immediately but do not persist across a
restart of the instance.
Deferred
Indicates the change does not take effect until a restart of the instance.
Action-based audit can also be set for permitted accesses and denied accesses to
filter out the generation of audit records at the global level. Tivoli Access Manager
for Operating Systems uses the following actions:
C Connect
D Change directory
G Surrogate
K Kill program
L Login
N Create
R Rename
U Update timestamp
d Delete
l List directory
o Change ownership
p Change permission
r Read
w Write
x Execute
The following window corresponds to the Set PDOS Server Audit Level task:
220 Administration Guide
Use the following steps to perform this task:
1. Select the audit events that should be enabled. Only events of the specified
types appear in the audit log. Choose actions to audit for both successful and
unsuccessful accesses. If none is selected, the action-based audit at the global
level is left unchanged.
2. Check Run in warning mode if Tivoli Access Manager for Operating Systems
should not enforce security policy, but only log violations of the policy.
3. Select how the auditing changes should be applied. Deferred changes do not
take effect immediately; they take effect on the next restart of Tivoli Access
Manager for Operating Systems. Permanent changes take effect immediately
and are persisted even after restarting Tivoli Access Manager for Operating
Systems. Temporary changes take effect immediately but are not persisted after
Tivoli Access Manager for Operating Systems is restarted.
4. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
Figure 27. Set PDOS Server Audit Level task window
Chapter 6. Using the Tivoli desktop to perform management tasks 221
v wrunjob "Set PDOS Server Audit Level" –l "PDOS Tasks" –a audit_permit –a
audit_permit_C –a audit_permit_D –a audit_permit_G –a audit_permit_K –a
audit_permit_L –a audit_permit_N –a audit_permit_R –a audit_permit_U –a
audit_permit_d –a audit_permit_l –a audit_permit_o –a audit_permit_p –a
audit_permit_r –a audit_permit_w –a audit_permit_x –a audit_deny –a
audit_deny_C –a audit_deny_D –a audit_deny_G –a audit_deny_K –a
audit_deny_L –a audit_deny_N –a audit_deny_R –a audit_deny_U –a
audit_deny_d –a audit_deny_l –a audit_deny_o –a audit_deny_p –a
audit_deny_r –a audit_deny_w –a audit_deny_x –a audit_admin –a audit_info
–a logpermit –a logdeny –a trace_exec –a trace_file –a warning_mode –a
change_type
v wruntask –t "Set PDOS Server Audit Level" –l "PDOS Tasks" –a audit_permit
–a audit_permit_C –a audit_permit_D –a audit_permit_G –a audit_permit_K
–a audit_permit_L –a audit_permit_N –a audit_permit_R –a audit_permit_U
–a audit_permit_d –a audit_permit_l –a audit_permit_o –a audit_permit_p
–a audit_permit_r –a audit_permit_w –a audit_permit_x –a audit_deny –a
audit_deny_C –a audit_deny_D –a audit_deny_G –a audit_deny_K –a
audit_deny_L –a audit_deny_N –a audit_deny_R –a audit_deny_U –a
audit_deny_d –a audit_deny_l –a audit_deny_o –a audit_deny_p –a
audit_deny_r –a audit_deny_w –a audit_deny_x –a audit_admin –a audit_info
–a logpermit –a logdeny –a trace_exec –a trace_file –a warning_mode –a
change_type –h task_endpoint
where:
audit_permit
Indicates that auditing of permitted accesses should be done. This value
must be TRUE or FALSE.
audit_permit_[C | D | G | K | L | N | R | U | d | l | o | p | r | w | x]
Indicates the selection of action-based audit for permitted access. The value
must be TRUE or FALSE.
audit_deny_[C | D | G | K | L | N | R | U | d | l | o | p | r | w | x]
Indicates that auditing of denied accesses should be done. This value must
be TRUE or FALSE.
audit_admin
Indicates that auditing of administrative events should be done. This value
must be TRUE or FALSE.
audit_info
Indicates that auditing of automatic actions taken within Tivoli Access
Manager for Operating Systems, such as receiving valid policy updates,
should be done. This value must be TRUE or FALSE.
logpermit
Indicates that auditing of all authorization decisions that permit a login
should be done. This value must be TRUE or FALSE.
logdeny
Indicates that auditing of all authorization decisions that deny a login
should be done. This value must be TRUE or FALSE.
trace_exec
Indicates that auditing of all process invocations should be done. This
value must be TRUE or FALSE.
222 Administration Guide
trace_file
Indicates that auditing of all accesses to protected files should be done.
This value must be TRUE or FALSE.
warning_mode
Indicates that Tivoli Access Manager for Operating Systems should run in
warning mode. This value must be TRUE or FALSE.
change_type
Indicates the type of change. This value must be one of Permanent,
Temporary, or Deferred.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Set PDOS server trace level
This task allows the administrator to set the current tracing levels of the daemons
comprising the Tivoli Access Manager for Operating Systems instance and is
intended to be used in conjunction with IBM Software Support. The entry of
random strings for trace levels is not recommended.
The following window corresponds to the Set PDOS Server Trace Level task:
Chapter 6. Using the Tivoli desktop to perform management tasks 223
Use the following steps to perform this task:
1. Type serviceability trace strings for the desired daemons.
2. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Set PDOS Server Trace Level" –l "PDOS Tasks" –a pdosd_trace –a
pdosauditd_trace –a pdoswdd_trace –a pdoslpmd_trace –a pdoslrd_trace
Figure 28. Set PDOS Server Trace Level task window
224 Administration Guide
v wruntask –t "Set PDOS Server Trace Level" –l "PDOS Tasks" –a pdosd_trace
–a pdosauditd_trace –a pdoswdd_trace –a pdoslpmd_trace –a pdoslrd_trace
–h task_endpoint
where:
pdosd_trace
Indicates the change to make to the trace level of the pdosd daemon. If the
empty string is specified, the trace level remains unchanged.
pdosauditd_trace
Indicates the change to make to the trace level of the pdosauditd daemon.
If the empty string is specified, the trace level remains unchanged.
pdoswdd_trace
Indicates the change to make to the trace level of the pdoswdd daemon. If
the empty string is specified, the trace level remains unchanged.
pdoslpmd_trace
Indicates the change to make to the trace level of the pdoslpmd daemon. If
the empty string is specified, the trace level remains unchanged.
pdoslrd_trace
Indicates the change to make to the trace level of the pdoslrd daemon. If
the empty string is specified, the trace level remains unchanged.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Setup TEC event server for PDOS
The Setup TEC Event Server for PDOS task automatically configures the Tivoli
Enterprise Console event server to recognize Tivoli Access Manager for Operating
Systems events. The task and job are available only if both Tivoli Access Manager
for Operating Systems Enterprise Console Integration and Tivoli Enterprise
Console Server are installed. For more information about installing the Tivoli
Enterprise Console logfile adapter on a Tivoli Access Manager for Operating
Systems client to send Tivoli Access Manager for Operating Systems events, see
Chapter 9, “Integrating with Tivoli Enterprise Console,” on page 357. For more
information about Tivoli Enterprise Console, see the IBM Tivoli Enterprise Console:
User’s Guide.
By default, this job runs on the Tivoli Enterprise Console event server, because this
task should only be run on the Tivoli Enterprise Console event server. The
following window corresponds to the Setup TEC Event Server for PDOS job and
task:
Chapter 6. Using the Tivoli desktop to perform management tasks 225
Use the following steps to perform this task:
1. Select one or two Tivoli Access Manager for Operating Systems integration
targets. The available selections are Integrate with Tivoli Enterprise Console
and Integrate with Tivoli Risk Manager. The task fails if <None> is selected.
2. Specify whether you want this task to create a new rule base or add
information to an existing rule base.
v If you create a new rule base, you must provide the following additional
information:
– New Rule Base name. Specifies a name for the new rule base. If a rule
base already exists with this name, an error occurs. The default rule base
name is PDOS.
– Rule Base to clone. Specifies the name of an existing rule base from
which to copy configuration files. The default name is Default. If
Integrate with Tivoli Risk Manager is selected, the rule base to clone
from must be installed and configured by Tivoli Risk Manager. For more
information, see the IBM Tivoli Risk Manager: User’s Guide.
Figure 29. Setup TEC Event Server for PDOS task window
226 Administration Guide
– Path for new Rule Base. Specifies the directory on the Tivoli Enterprise
Console server in which the new rule base’s configuration files are to be
stored. If this path does not exist, it is created.v If you choose to add to an existing rule base, you must specify a name for
the existing rule base. The default rule base name is PDOS. If the rule base
you specify does not already exist, an error occurs.3. Select the name of the event console to configure. Selecting a console from the
list causes the Tivoli Access Manager for Operating Systems event group
(through which all Tivoli Access Manager for Operating Systems related events
are accessible) to be added to the selected console. If you choose None, you will
not receive Tivoli Access Manager for Operating Systems events at any event
console.
4. Click the Set and Close button to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Setup TEC Event Server for PDOS" –l "PDOS Tasks" –a IntegrateTEC
-a IntegrateRM –a NeworExisting –a ExistingRuleBase –a NewRuleBase –a
CloneRuleBase –a RuleBasePath –a EventConsole
v wruntask –t "Setup TEC Event Server for PDOS" –l "PDOS Tasks" -a
IntegrateTEC –a IntegrateRM –a NeworExisting –a ExistingRuleBase –a
NewRuleBase –a CloneRuleBase –a RuleBasePath –a EventConsole –h
task_endpoint
where:
IntegrateTEC
Specifies whether to integrate with Tivoli Enterprise Console. Valid values
are on (integrate with Tivoli Enterprise Console) and off (do not integrate).
IntegrateRM
Specifies whether to integrate with Tivoli Risk Manager. Valid values are on
(integrate with Tivoli Risk Manager) and off (do not integrate).
NeworExisting
Specifies whether to create a new rule base or use an existing rule base.
Valid values are new (create new database) and exist (use an existing
database).
If you specify new, you must also specify a name for NewRuleBase.
If you specify exist, you must also specify a name for ExistingRuleBase.
ExistingRuleBase
Specifies the name of the rule base in which to add information. If the
exist option is specified, you must supply the name of an existing
database. The default name is PDOS.
NewRuleBase
Specifies a name for the new rule base. If a rule base already exists with
this name, an error occurs. If the new option is specified, you must supply
a name for the new database.
CloneRuleBase
Specifies the name of an existing rule base from which to copy
configuration files. The default name is Default.
Chapter 6. Using the Tivoli desktop to perform management tasks 227
RuleBasePath
Specifies the full path of the directory on the Tivoli Enterprise Console
server in which the new rule base’s configuration files are to be stored. If
this path does not exist, it is created.
EventConsole
Specifies the name of the event console to be configured with this rule
base.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Notes:
1. If you choose integration with Tivoli Risk Manager, and the Tivoli Enterprise
Console event server in your environment is running on a Microsoft Windows
system, you must customize the $RMADHOME/etc/riskmgr_baroc.lst file to
include the pdosrm.baroc file. Include the pdos.baroc file also if the event
server should send events to the Tivoli Enterprise Console as well. Make your
changes effective by entering the following commands using the bash shell
from the event server after running this task:
cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdosrm.baroc \
$RMADHOME/etc/baroc/
cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdos.baroc \
$RMADHOME/etc/baroc/
$RMADHOME/bin/rmcorr_cfg -update
2. Tivoli Access Manager for Operating Systems Risk Manager events can be
integrated with Tivoli Data Warehouse. Additional steps are required to ensure
that events are properly integrated in the data warehouse product. See
Chapter 10, “Integrating with Tivoli Risk Manager,” on page 361 for more
information.
Show PDOS auditing configuration
This task allows you to review the parameters related to Tivoli Access Manager for
Operating Systems auditing. When you run this task from the desktop, the audit
parameters are displayed in a window. Displayed output includes the maximum
file size of an audit log and how often, in seconds, audit log buffers are flushed to
disk. If a parameter’s value is blank, it has never been explicitly configured and is
using its default value.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Show PDOS Auditing Configuration" –l "PDOS Tasks"
v wruntask –t "Show PDOS Auditing Configuration" –l "PDOS Tasks" –h
task_endpoint
where:
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
228 Administration Guide
Show PDOS auditors and administrators
This task can be used to display users who have auditor or administrator
privileges. To be an auditor, the user must be a member of both the osseal-auditors
Tivoli Access Manager group and the ossaudit UNIX group. To be an
administrator, the user must be a member of the osseal-admin Tivoli Access
Manager group and a member of the osseal UNIX group.
The Show Auditors and Show Administrators check boxes are used to select
which UNIX and Tivoli Access Manager groups to display. To run this task, a
Tivoli Access Manager administrator name and password must be specified.
The following window corresponds to the Show PDOS Auditors/Administrators
task:
Use the following steps to perform this task:
1. You must specify the first two fields.
Note: When you type the password, the characters are not masked. When the
password is sent over the network to the target machine, it is not
encrypted. The password could be intercepted, which might compromise
security.
2. Select the types of Tivoli Access Manager for Operating Systems users you
want to display.
3. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Show PDOS Auditors/Administrators" –l "PDOS Tasks" –a
pd_admin_id –a pd_admin_passwd –a show_auditors –a show_admins
Figure 30. Show PDOS Auditors/Administrators task window
Chapter 6. Using the Tivoli desktop to perform management tasks 229
v wruntask –t "Show PDOS Auditors/Administrators" –l"PDOS Tasks" –a
pd_admin_id –a pd_admin_passwd –a show_auditors –a show_admins –h
task_endpoint
where:
pd_admin_id
Specifies the name of a Tivoli Access Manager administrative account to
use to generate the report. Completion of this parameter is required.
pd_admin_passwd
Specifies the password of the administrative account. Completion of this
parameter is required.
Note: When the password is sent over the network to the target machine,
it is not encrypted. The password could be intercepted, which might
compromise security.
show_auditors
If this parameter is set to TRUE, the members of the Tivoli Access Manager
osseal-auditors group and the UNIX ossaudit group are displayed. This
value must be TRUE or FALSE.
show_admins
If this parameter is set to TRUE, the members of the Tivoli Access Manager
osseal-admin group and the UNIX osseal group are displayed. This value
must be TRUE or FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Show PDOS caching configuration
This task allows you to review the parameters related to the internal caches of
Tivoli Access Manager for Operating Systems. When you run this task from the
desktop, the cache parameters are displayed in a window. Displayed output
includes how often (in minutes) to refresh cached administrator credentials, how
often (in minutes) to refresh cached user credentials, how long (in minutes) to
cache user credentials that have not been accessed, the critical system users group,
how often (in minutes) to refresh critical system user credentials, how long (in
minutes) to wait for responses from the user registry before going into isolation
mode, whether host name caching is turned on, and whether user name caching is
turned on. If a parameter’s value is blank, it has never been explicitly configured
and is using its default value.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Show PDOS Caching Configuration" –l "PDOS Tasks"
v wruntask –t "Show PDOS Caching Configuration" –l "PDOS Tasks" –h
task_endpoint
where:
230 Administration Guide
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Show PDOS logging configuration
This task allows you to review the parameters related to logging for the Tivoli
Access Manager for Operating Systems daemons, pdosd, pdoswdd, pdosauditd,
and pdoslrd. When you run this task from the desktop, the logging parameters are
displayed in a window. Displayed output includes the number of log files and the
maximum number of entries in the log files. If a parameter’s value is blank, it has
never been explicitly configured and is using its default value.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Show PDOS Logging Configuration" –l "PDOS Tasks"
v wruntask –t "Show PDOS Logging Configuration" –l "PDOS Tasks" –h
task_endpoint
where:
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Show PDOS server audit level
This task allows you to review the parameters related to the Tivoli Access Manager
for Operating Systems instance’s auditing level. When you run this task from the
desktop, these parameters are displayed in a window. Displayed output includes
the current audit level (permitted accesses, denied accesses, and administrative
events) and whether Tivoli Access Manager for Operating Systems is in warning
mode, where all accesses are granted but accesses that would normally be denied
generate audit records. Also, the configured audit levels are displayed. Configured
audit levels will be in effect after the next restart of Tivoli Access Manager for
Operating Systems. If a parameter’s value is blank, it has never been explicitly
configured and is using its default value.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Show PDOS Server Audit Level" –l "PDOS Tasks"
v wruntask –t "Show PDOS Server Audit Level" –l "PDOS Tasks" –h
task_endpoint
where:
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Chapter 6. Using the Tivoli desktop to perform management tasks 231
Show PDOS server configuration
This task allows you to review miscellaneous parameters for the Tivoli Access
Manager for Operating Systems server. When you run this task from the desktop,
the parameters are displayed in a window. If a parameter’s value is blank, it has
never been explicitly configured and is using its default value. Displayed output
includes the following information.
v The port Tivoli Access Manager for Operating Systems uses to receive
notifications of policy updates
v How often, in minutes, to poll for policy updates
v Whether system and password login restrictions are enabled
v The number of kernel threads used to handle authorization requests
v Whether Tivoli Access Manager for Operating Systems is configured to start
automatically at system startup
v The name of the initial policy branch
v Whether first failure data capture is enabled
v Whether log router daemon pdoslrd is configured.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Show PDOS Server Configuration" –l "PDOS Tasks"
v wruntask –t "Show PDOS Server Configuration" –l "PDOS Tasks" –h
task_endpoint
where:
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Show PDOS TCB configuration
This task allows you to review parameters related to the Tivoli Access Manager for
Operating Systems Trusted Computing Base (TCB). When you run this task from
the desktop, the parameters are displayed in a window. Displayed output includes
the number of threads used to monitor TCB objects, the interval (in seconds)
between TCB monitoring runs, and the maximum number of bytes in megabytes
from a file to use in a checksum (TCB signature). If a parameter’s value is blank, it
has never been explicitly configured and is using its default value.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Show PDOS TCB Configuration" –l "PDOS Tasks"
v wruntask –t "Show PDOS TCB Configuration" –l "PDOS Tasks" –h
task_endpoint
where:
232 Administration Guide
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Start PDOS TEC adapter
This task allows the administrator to start the Tivoli Access Manager for Operating
Systems Tivoli Enterprise Console daemon and the Tivoli Enterprise Console
logfile adapter. This task will not start the processes if they are already running.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Start TEC Adapter" –l "PDOS Tasks"
v wruntask –t "Start TEC Adapter" –l "PDOS Tasks" –h task_endpoint
where:
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Stop PDOS TEC adapter
This task allows the administrator to stop the Tivoli Access Manager for Operating
Systems Tivoli Enterprise Console daemon and the Tivoli Enterprise Console
logfile adapter.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Stop TEC Adapter" –l "PDOS Tasks"
v wruntask –t "Stop TEC Adapter" –l "PDOS Tasks" –h task_endpoint
where:
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Subscribe PDOS endpoints
This task creates a list of all managed nodes and endpoints that have Tivoli Access
Manager for Operating Systems installed on them. These managed nodes and
endpoints are then added to the subscriber list of the local PDOS profile manager.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Subscribe PDOS Endpoints" –l "PDOS Tasks"
v wruntask –t "Subscribe PDOS Endpoints" –l "PDOS Tasks" –h task_endpoint
Chapter 6. Using the Tivoli desktop to perform management tasks 233
where:
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Update PDOS host name cache
This task allows the administrator to add entries to the IP address and host name
translation cache used by Tivoli Access Manager for Operating Systems, as well as
to force a refresh of all cache entries.
Two non-exclusive options are available—refreshing all cache entries and adding
new cache entries. New entries to add are specified by host name or IP address in
a comma-separated list. If this list is empty, no entries are added. When adding
entries, a time-to-live can be provided indicating how many seconds the entry
remains valid in the cache. If omitted, a reasonable default is used.
The following window corresponds to the Update Hostname Cache task:
Use the following steps to perform this task:
1. Type a comma-separated list of host names or IP addresses to add to the host
name cache. If empty, no new entries are added.
2. Type the number of seconds that newly added entries remain valid in the
Cache timeout field.
3. If all entries currently in the cache should be refreshed, check Refresh all
database entries.
4. Click Execute and Close to perform the task.
Syntax for wrunjob and wruntask
Use the following arguments, in the order shown, to run this task from the
command line or a script using wrunjob or wruntask:
v wrunjob "Update Hostname Cache" –l "PDOS Tasks" –a add_entries –a
entry_ttl –a refresh
v wruntask –t "Update Hostname Cache" –l "PDOS Tasks" –a add_entries –a
entry_ttl –a refresh –h task_endpoint
Figure 31. Update Hostname Cache Window
234 Administration Guide
where:
add_entries
Indicates which entries to add to the cache. If this value is the empty
string, no new entries are added.
entry_ttl
Indicates the length of time (in seconds) any newly added cache entries
remains valid. If this value is the empty string, a default value is used.
refresh Indicates whether all cache entries should be refreshed. This value must be
TRUE or FALSE.
task_endpoint
Specifies the name of the profile manager, managed node, or endpoint on
which to run the task. You can specify more than one name; separate
multiple names with spaces.
Chapter 6. Using the Tivoli desktop to perform management tasks 235
236 Administration Guide
Chapter 7. Auditing
Tivoli Access Manager for Operating Systems provides auditing capabilities that
you can use to track authorization access decisions that are made to protected
resources and to monitor administrative activities, such as starting and stopping
daemons.
This chapter provides information about the types of events that can be audited,
the format of the resulting log entries, and how to view the log entries.
Auditing authorization decisions
Auditing of authorization decisions can be set for a specific machine (referred to as
global auditing), set for a specific resource (referred to resource-level auditing), or set
for a specific user (referred to user-level auditing).
You can audit authorization access decisions for specific resources by enabling
resource-level auditing. Use protected object policy (POP) access controls to enable
resource-based auditing by setting the audit-level attribute to permit, deny, or
both. Setting the POP audit-level attribute to permit results in the generation of
audit records for all authorization decisions that permit access to the resource the
POP is associated with. Setting the POP audit-level attribute to deny results in the
generation of audit records for all authorization decisions that deny access to the
resource the POP is associated with. Because resource-level auditing is set by
defining POP access controls in policy, all Tivoli Access Manager for Operating
Systems clients that are configured to the same branch have the same
resource-level audit policy.
Audit records for authorization access decisions are also generated if the permit or
deny level is set in the global audit level. Setting the global audit level to permit
results in the generation of audit records for all authorization decisions that permit
access to protected resources. Setting the global audit level to deny results in the
generation of audit records for all authorization decisions that deny access to
protected resources. The global audit level is set on a per-machine basis.
The auditing levels for the global audit level and the resource audit level are
cumulative. For example, if the global audit level is set to deny, and a resource has
a POP attached to it with an audit level of permit, every authorization decision for
access to that resource will be audited.
You can enable more granular auditing for authorization access decisions based on
the action being performed against the protected resource. This granularity can be
accomplished by specifying the accessing permissions that trigger the generation of
an audit record. This action can be useful in reducing the total amount of audit
records that are generated. For example, for file system resources, it might be
desirable to only audit authorization decisions that permit actions that could
modify the file resource, such as the OSSEAL actions kill program (K), create (N),
rename (R), delete (d), change ownership (o), change permission (p), and write
(w). Auditing based on the action being performed can be specified separately for
global permit, global deny, per-resource permit, and per-resource deny audit levels
and only has an effect if the corresponding global or per-resource audit level is
enabled. The global and per-resource level are cumulative. For example, if the
global audit level is set to deny, and a resource has a POP attached to it with an
© Copyright IBM Corp. 2000, 2005 237
audit level of permit and the audit permit actions are set to only audit the write,
create, and rename actions, every authorization decision that is denied will be
audited; however, only authorization decisions that permit the specified actions of
write, create, and rename to the resource that the POP applies to will be audited.
You can audit authorization decisions that are specific to login by setting the global
loginpermit and logindeny audit levels. Setting the loginpermit global audit level
results in the generation of audit records for all login authorization decisions that
permit the login action. Setting the logindeny global audit level results in the
generation of audit records for all login authorization decisions that deny the login
action. Authorization decisions that are specific to login are also audited if the
global audit levels are set to permit or deny. The loginpermit and logindeny audit
levels allow you to globally audit login separately from other authorization
decisions.
You can audit authorization decisions on a per user basis by defining user-level
audit authorization policy using AuditAuth resource definitions. The user-level
audit authorization policy can be set on an individual user, a group, or
unauthenticated users. Supported audit levels for user-level audit authorization
policy are: permit, deny, loginpermit, logindeny, all, and none. The permit audit
level enables the generation of audit records for all authorization decisions that
permit access by the user to protected resources. The deny audit level enables the
generation of audit records for all authorization decisions that deny access by the
user to protected resources. The loginpermit audit level enables the generation of
audit records for all login-related authorization decisions that permit a login by a
user. The logindeny audit level enables the generation of audit records for all
login-related authorization decisions that deny a login by a user. Specifying all
turns on all the audit levels. The none level is a special case that indicates that no
audit records should be generated for the user even if global or resource level
auditing is set. Because user-level audit authorization policy is set by defining
resources and resources are defined on a per-branch basis, all Tivoli Access
Manager for Operating Systems clients that are configured to the same branch
have the same user-level audit authorization policy. User-level audit can be used
by itself or together with global and resource-based audit levels. It can be used to
define audit levels for individual users or groups of users for which authorization
decisions should be audited or for which no authorization decisions should be
audited. With the exception of audit level none, all audit levels are in addition to
audit levels set by global and resource audit.
Consider, for example, auditing all authorization decisions that permit access to
resources under the /var/testd/data directory. The administrator would create a
POP with the audit level set to permit and attach it to the /OSSEAL/policy-branch/File/var/testd/data object. Suppose that there is a daemon, testdm, running on
the system under the testd user ID, that frequently accesses data in the
/var/testd/data directory. To prevent the audit log from being cluttered up with
audit records generated by the testd user ID, the administrator could set the testd
users audit level to none by creating the following object: /OSSEAL/policy-branch/AuditAuth/User/testd/none. In this case, authorization decisions made on behalf of
the testd user will not generate audit records.
Another useful example is auditing all authorization decisions that permit access to
resources by Tivoli Access Manager for Operating Systems runtime administrative
users. The administrator creates the following object: /OSSEAL/policy-branch/AuditAuth/Group/osseal-admin/permit. This causes all authorization decisions that
permit access made on behalf of any users who are members of the osseal-admin
group to be audited. By default, the root user is a member of the osseal-admin
238 Administration Guide
group. Suppose that, in addition, the administrator wants to audit deny for the
root user. One might think that the administrator could create the following object:
/OSSEAL/policy-branch/AuditAuth/User/root/deny. This is incorrect because after
policy is set for a user, only that policy will apply and the osseal-admin group
policy no longer applies to the root user. The administrator would have to either
create two objects, one for permit and one for deny for the root user, or create the
/OSSEAL/policy-branch/AuditAuth/User/root/all object.
If warning mode is enabled, audit records are generated for authorization access
decisions that are changed from deny to permit regardless of the current audit
level. Use POP access controls to enable resource-based warning mode. Also,
similar to auditing, there is a global warning mode that can be activated.
Auditing administrative activity
You can audit actions taken by the Tivoli Access Manager for Operating Systems
daemons of an administrative nature by setting the admin level on in the global
audit level. The admin audit level causes Tivoli Access Manager for Operating
Systems daemons to generate audit records for events such as starting and
stopping the daemons, loss of connectivity with the Tivoli Access Manager user
registry, Trusted-Computing-Base-related activity such as a file being marked
untrusted by the Trusted Computing Base monitoring function, and the detection
of incorrect policy. The admin audit level also causes the generation of audit records
for events related to a user login account being enabled or disabled when login
activity policy is being enforced. Setting the info level on in the global audit level
causes auditing to occur for routine events such as the pdosd daemon receiving
valid policy updates. Setting the info level will result in a large amount of audit
data being generated. The overall space consumed by audit data should be
carefully monitored.
Setting the admin audit level also causes the generation of audit records for events
from the pdosctl command, such as:
v Attempts to stop the daemons
v Modification of the global audit level
v Modification of the global warning mode
Auditing trace events
Tivoli Access Manager for Operating Systems supports the generation of TraceExec
and TraceFile audit events. Trace-style audit events are generated by setting the
trace_exec, trace_exec_l, trace_exec_root, or trace_file levels in the global
audit level or defining user-level trace policy.
Setting the trace_exec global audit level causes the Tivoli Access Manager for
Operating Systems kernel code to track program invocations initiated by the exec()
system call that occur in processes that descend from a login event that was
detected by Tivoli Access Manager for Operating Systems. This action results in the
generation of a TraceExec audit record for each detected exec() system call. These
records are generated regardless of whether the program being executed is
protected by Tivoli Access Manager for Operating Systems policy or not.
Depending on the amount of activity on the system, activating the trace_exec
global audit level can generate a large amount of auditing data that can be difficult
to manage. The trace_exec_l and trace_exec_root global audit levels allow you to
enable TraceExec auditing under more limited circumstances.
Chapter 7. Auditing 239
When the trace_exec_l global audit level is enabled, and the trace_exec audit
level is not enabled, TraceExec audit data is only generated for exec() activity when
the accessing user’s accessor identity and effective UNIX identity do not match
(this typically happens when a user surrogates to another user). Use of the
trace_exec_l level instead of trace_exec prevents TraceExec audit data from being
generated when the accessing user’s accessor identity and effective UNIX identity
are the same.
When the trace_exec_root global audit level is enabled, and the trace_exec audit
level is not enabled, TraceExec audit data is only generated for the exec() activity
when the accessing user’s accessor identity is the root user. Note that it is the
accessing user’s accessor identity, the identity used by Tivoli Access Manager for
Operating Systems for purposes of making authorization decisions, that matters,
not the user’s effective UNIX identity.
Using both the trace_exec_root and trace_exec_l audit levels, instead of
trace_exec, will cause TraceExec audit data to be generated only for program
invocations initiated by the exec() system call that occur in processes that descend
from a login event that was detected by Tivoli Access Manager for Operating
Systems and when the accessing user’s accessor identity is either the root user or
the accessor identity and the effective UNIX identity do not match.
Setting the trace_file global audit level results in the generation of a TraceFile
audit record for each access to a file system resource that is protected by Tivoli
Access Manager for Operating Systems policy.
You can audit trace events on a per user basis by defining user-level trace policy.
Supported user-level trace audit levels are exec, exec_l, file, all, and none.
Setting the exec audit level causes the Tivoli Access Manager for Operating
Systems kernel code to track program invocations initiated by the exec() system
call that occur in processes that descend from a login event for the specified user
that was detected by Tivoli Access Manager for Operating Systems. This action
results in the generation of a TraceExec audit record for each detected exec()
system call. These records are generated regardless of whether the program being
executed is protected by Tivoli Access Manager for Operating Systems policy or
not. Setting the exec_l audit level limits the generation of TraceExec audit records
to program invocations initiated by exec() that occur in processes for this user
when the user’s accessing identity and effective UNIX identity do not match
(which typically happens when a user surrogates to another user). Setting the file
audit level results in the generation of a TraceFile audit record for all accesses to
protected file resources by the specified user. Specifying all activates both exec and
file audit levels. The none level is a special case that indicates that no audit
records should be generated for the specified user even if global trace auditing is
set. Because user-level trace policy is set by defining resources and resources are
defined on a per-branch basis, all Tivoli Access Manager for Operating Systems
clients that are configured to the same branch have the same user-level trace
policy. User-level trace can be used by itself or together with global audit levels. It
can be used to define trace levels for individual users for which trace events
should be audited or for which no trace events should be audited. With the
exception of trace level none, all trace levels are in addition to the trace levels set
via global audit.
Consider, for example, tracing all exec() operations that are initiated by the root
user. To set this up on all systems configured to use the same policy branch, the
administrator creates the /OSSEAL/policy-branch/AuditTrace/User/root/exec
240 Administration Guide
object. To set this up on just selected systems, the administrator enables the
trace_exec_root global audit level on the desired systems.
Note that TraceExec and TraceFile audit records are generated only for processes
that descend from a login event that was detected by Tivoli Access Manager for
Operating Systems. The following processes do not generate TraceExec or TraceFile
audit records:
v Processes that are started or descended from the UNIX init process during
system boot.
v Processes that are active before Tivoli Access Manager for Operating Systems
and its processes are started.
v Processes that are running programs registered as Immune-Programs in the
Trusted Computing Base (TCB).
In addition, TraceExec and TraceFile audit records are generated only if the request
is handled at the operating system service level. If an operation is handled at the
application level, such as within a command shell, Tivoli Access Manager for
Operating Systems might not be aware of the activity and would not generate an
audit record for it.
Enabling auditing
The type of auditing information collected can be tailored based on your needs.
Auditing can be set globally, for a specific protected resource, or on a per user
basis. For global and resource-level auditing, the permit and deny levels can be
further qualified so that they are only in effect for specified OSSEAL actions, such
as write.
Global auditing
Tivoli Access Manager for Operating Systems supports global auditing that can be
enabled on a per-machine basis.
Table 68. Global audit levels
Audit level Description
none Turns off all auditing. This is the default value.
permit Tracks all authorization decisions that permit access to a protected
resource.
deny Tracks all authorization decisions that deny access to a protected
resource.
loginpermit Tracks all login authorization decisions that permit a login.
logindeny Tracks all login authorization decisions that deny a login.
admin Tracks daemon activity of an administrative nature. For example,
if the global audit level has the admin level set, a log entry is
created each time one of the Tivoli Access Manager for Operating
Systems daemons is started or stopped.
trace_exec Tracks program invocations initiated by exec() that occur in
processes that descend from a login event that was detected by
Tivoli Access Manager for Operating Systems.
Chapter 7. Auditing 241
Table 68. Global audit levels (continued)
Audit level Description
trace_exec_l Tracks program invocations initiated by exec() that occur in
processes that descend from a login event that was detected by
Tivoli Access Manager for Operating Systems when the accessing
user’s accessor identity is different than the user’s effective UNIX
identity (which typically happens when a user surrogates to
another user).
trace_exec_root Tracks program invocations initiated by exec() that occur in
processes that descend from a login event that was detected by
Tivoli Access Manager for Operating Systems when the accessing
user’s accessor identity is the root user.
trace_file Tracks all accesses to protected files. Tracking occurs whether or
not resource auditing is enabled, or global permit or deny auditing
is enabled.
Tracking occurs only for those processes that descend from a login
event that was detected by Tivoli Access Manager for Operating
Systems.
all Enables all of the following audit levels:
v permit
v deny
v loginpermit
v logindeny
v admin
info Tracks actions that are done automatically, such as receiving valid
policy updates.
verbose Enables all of the following audit levels:
v permit
v deny
v loginpermit
v logindeny
v admin
v info
Setting and querying the global audit level
To set the global audit level that goes into effect at the next restart of Tivoli Access
Manager for Operating Systems, enter:
pdoscfg –audit_level level
Where level is one of the supported global audit levels shown in “Global auditing”
on page 241.
You can use the pdosctl command to set or reset the global audit level during
runtime.
The –A option resets the current global audit level to the specified value. If
multiple –A options are specified, the global audit level is set to all the specified
values. The –a option modifies the global audit level by resetting just the specified
audit level. Multiple –a options can be specified. To reset or modify the global
audit level, the –A or –a option is followed by an audit level and the keyword on
or off separated by a colon (:). If only the audit level is specified without the
keyword on or off, the value on is assumed. Valid values for audit level are
242 Administration Guide
defined in “Global auditing” on page 241. They are all, none, permit, deny,
loginpermit, logindeny, admin, verbose, info, trace_exec, trace_exec_l,
trace_exec_root, and trace_file.
To reset the current global auditing to specific levels immediately, enter:
pdosctl –A level:[on | off]
To turn on additional global audit levels, enter:
pdosctl –a level:[on | off]
To set the global audit level to permit and deny, enter:
pdosctl -A permit:on -A deny:on
To add the admin audit level to the global audit level, enter:
pdosctl -a admin:on
The –a and –A options when specified with no arguments display the current
global audit level of the pdosd, pdoswdd, pdoslpmd, pdoslrd, and pdosauditd
daemons.
To query the global audit level, enter:
pdosctl -a
The output is:
pdosd has the following audit levels on: permit, deny, admin
pdoswdd has the following audit levels on: permit, deny, admin
pdoslpmd has the following audit levels on: permit, deny, admin
pdoslrd has the following audit levels on: permit, deny, admin
pdosauditd has the following audit levels on: permit, deny, admin
Global-level auditing based on actions against protected
resources
The global permit and deny audit levels can be tuned for more granular auditing of
authorization access decisions based on the action being performed against the
protected resource. This tuning can be done by specifying the accessing
permissions that trigger the generation of an audit record; it can be useful for
reducing the total amount of audit records that are generated. For example, for file
system resources, it might be desirable to only audit authorization decisions that
permit actions that could modify a file resource such as the OSSEAL actions kill
program (K), create (N), rename (R), delete (d), change ownership (o), change
permission (p), and write (w). Auditing based on the action being performed can
be enabled separately for global permit and global deny audit levels.
To set the global-audit action level that goes into effect at the next restart of Tivoli
Access Manager for Operating Systems, enter:
pdoscfg –audit_permit_actions permission-set
pdoscfg –audit_deny_actions permission-set
Where permission-set is the set of permissions from the OSSEAL action group that
should cause generation of an audit record. You must include the [OSSEAL]
qualifier as part of the permission set. For example, to enable the global permit
audit level at the next restart of the daemons so that all authorizations decisions
that deny access generate an audit record and all authorization decisions that
permit an action that could modify a protected file generate an audit record, the
following pdoscfg command could be used:
pdoscfg -audit_level permit,deny -audit_permit_actions [OSSEAL]NdwpoUR
Chapter 7. Auditing 243
You can use the pdosctl command to set or reset the global audit action level
during runtime. To reset the audit permit actions:
pdosctl –p [OSSEAL]permission-set
To reset the deny actions:
pdosctl –d [OSSEAL]permission-set
Where permission-set is the set of permissions from the OSSEAL action group that
should cause generation of an audit record. You must include the [OSSEAL]
qualifier as part of the permission set.
For example, to dynamically enable the global auditing so that all authorization
decisions that deny access generate an audit record and all authorization decisions
that permit an action that could modify a protected file generate an audit record,
the following pdosctl command could be used:
pdosctl -a deny -a permit -p [OSSEAL]NdwpoUR
Note: The audit actions further qualify the base global audit level. The
corresponding base global audit level must be enabled for the specified
audit actions to have an effect. For example, the global permit audit level
must be enabled for the audit permit actions to have an effect. The global
deny audit level must be enabled for the audit deny actions to have an
effect.
Resource-level auditing
Tivoli Access Manager for Operating Systems supports resource-level auditing of
authorization decisions. Auditing of admin and info levels cannot be controlled
through resource-level audit. Use protected object policy (POP) access controls to
enable resource-based auditing by setting the audit-level attribute. Because
resource-level auditing is set by defining POP access controls in policy, all Tivoli
Access Manager for Operating Systems clients that are configured to the same
branch have the same resource-level audit policy.
Setting and querying the resource audit level
To set the audit level for a specific resource, set up a POP with the audit level set
as desired and attach the POP to the protected object name. The audit level
specified controls under what circumstances an access to an object generates an
audit record. The audit level can be set to one of the following values:
permit If enabled, an audit record is generated for all authorization decisions that
permit access to the resource the POP is associated with.
deny If enabled, an audit record is generated for all authorization decisions that
deny access to the resource the POP is associated with
all Enables both permit and deny.
none None of the defined audit levels are enabled. This is the default.
To use the pdadmin pop modify command to set a POP’s audit-level attribute,
enter:
pdadmin> pop modify pop_name set audit-level level
where level is one of the supported audit levels.
244 Administration Guide
For example, to set an audit level of permit and deny for accesses to the protected
object named /OSSEAL/Default/NetIncoming/tcp/telnet/*.company.com using the
POP sample_pop, enter:
pdadmin> pop create sample_pop
pdadmin> pop modify sample_pop set audit-level permit,deny
pdadmin> pop attach /OSSEAL/Default/NetIncoming/tcp/telnet/*.company.com sample_pop
An audit record is generated for all NetIncoming accesses using the telnet service
from systems with host names that match the pattern *.company.com. The audit
record indicates whether the access was permitted or denied.
To disable the generation of audit records, set the audit-level attribute to none or
detach the POP from the protected object name. If you are using other attributes in
the POP for the object and you only want to turn off the audit level, leaving the
other attributes intact, set audit-level to none, as follows:
pdadmin> pop modify sample_pop set audit-level none
If you are using this POP only for resource auditing or if it is also controlling other
protected objects that you still want to audit, detach the POP from the protected
object to disable resource-level auditing for just that object:
pdadmin> pop detach /OSSEAL/Default/NetIncoming/tcp/telnet/*.company.com
To query the audit level setting in a POP, enter:
pdadmin> pop show pop_name
Resource-level auditing based on actions against protected
resources
The POP audit-level attribute values permit and deny can be tuned for more
granular auditing of authorization access decisions based on the action being
performed against the protected resource. This mechanism is particularly useful for
file resources where it might be desirable to audit authorization decisions that
allow someone to modify a file resource but not audit authorization decisions that
allow read or list access to a resource. This focus can help reduce the volume of
audit records generated and make risk assessment easier. To enable auditing based
on the action being performed against the protected resource, extended attributes
specifying the accessing permissions can be set on a POP in conjunction with the
corresponding audit-level attribute.
The names of the extended attributes are audit_permit_actions and
audit_deny_actions. Their formats are:
audit_permit_actions permission-set
audit_deny_actions permission-set
The permission set is defined in the same way as in an ACL entry. These extended
attributes apply only to Tivoli Access Manager for Operating Systems actions. The
[OSSEAL] qualifier must be specified in front of the actions.
The audit_permit_actions and audit_deny_actions extended POP attributes only
take affect if the corresponding audit level is enabled by the audit-level attribute.
If permit is enabled in the audit-level attribute and the extended attribute
audit_permit_actions is set on in the POP, an audit record is generated when
access to the resource is granted for the actions specified in the permission-set.
Audit records are not generated when access to the resource is granted for actions
not specified in the permission set.
Chapter 7. Auditing 245
If deny is enabled in the audit-level attribute and the extended attribute
audit_deny_actions is set on in the POP, an audit record is generated when access
to the resource is denied for the actions specified in the permission-set. Audit
records are not generated when access to the resource is denied for actions not
specified in the permission set.
For example, to turn on auditing for all authorization decisions that deny access to
the file /etc/passwd and limit auditing of authorization decisions that permit
access to only those actions that could modify the file, an administrator would
enter the following:
pdadmin> pop create passwdpop
pdadmin> pop modify passwdpop set audit-level permit,deny
pdadmin> pop modify passwdpop set attribute audit_permit_actions [OSSEAL]NdwpoUR
pdadmin> pop attach /OSSEAL/policy_branch/File/etc/passwd passwdpop
User-level auditing
Tivoli Access Manager for Operating Systems supports user-level auditing of
authorization and trace events. Auditing of admin and info levels cannot be
controlled through user-level audit. User-level audit is specified in the Tivoli
Access Manager policy space. It is set and enforced on a per-branch basis.
User-level audit policy provides the same function as the global levels (permit,
deny, loginpermit, logindeny, trace_exec, trace_exec_l, and trace_file) except
that it allows you to enable or disable auditing for specific users. See “Audit
resources” on page 70 for details.
Setting and querying the user audit levels
User audit levels can be set for authorization decisions and trace by defining
resources that represent the audit levels. User-level audit authorization resources
are represented by defining an object name with a resource type of AuditAuth.
User-level trace resources are represented by defining an object name with a
resource type of AuditTrace.
User-level audit specifies additional audit policy beyond that which is already
provided through global and resource audit levels. It can be used to generate
additional audit records or to limit the audit records generated on behalf of a
specific user. User-level auditing takes precedence over global and resource audit
levels. For example, if the global audit level is set to permit and deny and a user
audit authorization level of none is set for the root user, no audit records will be
generated for access decisions that are made on behalf of the root user.
AuditAuth resources can be defined for users who are unauthenticated in the
Tivoli Access Manager user registry by using the Unauth keyword in the resource
definition. AuditAuth resources can be defined for users that are members of a
group in the Tivoli Access Manager user registry by using the Group keyword in
the resource definition. AuditAuth resources can be defined for a specific UNIX
user by using the User keyword in the resource definition. User-specific resource
definitions take precedence over Unauth and Group definitions.
AuditAuth resource policy supports the following audit levels:
permit Enables the generation of audit records for all authorization decisions that
permit access to protected resources for the user.
deny Enables the generation of audit records for all authorization decisions that
deny access to protected resources for the user.
246 Administration Guide
loginpermit
Enables the generation of audit records for all login-related authorization
decisions that permit a login by the user.
logindeny
Enables the generation of audit records for all login-related authorization
decisions that deny a login by the user.
all Turns on all audit levels.
none A special case. Indicates that no audit records should be generated for the
user even if global or resource-level auditing is set.
To set the AuditAuth levels, objects of the following format are created:
/OSSEAL/policy-branch/AuditAuth/Unauth/audit-level
/OSSEAL/policy-branch/AuditAuth/Group/group-name/audit-level
/OSSEAL/policy-branch/AuditAuth/User/user-name/audit-level
where:
audit-level
A valid audit level (permit, deny, loginpermit, logindeny, all, or none)
group-name
The name of the Tivoli Access Manager group
policy-branch
The name of the policy branch
user-name
The name of the UNIX user
To set up policy such that all access decisions made on behalf of members of the
osseal-admin Tivoli Access Manager group that permit the action are audited,
create the following object:
pdadmin> object create /OSSEAL/Default/AuditAuth/Group/osseal-admin/permit \
"Audit all permit access decisions" 11 ispolicyattachable no
To set up policy such that all login access decisions made on behalf of members of
the osseal-admin Tivoli Access Manager group are audited, create the following
objects:
pdadmin> object create /OSSEAL/Default/AuditAuth/Group/osseal-admin/loginpermit \
"Audit all loginpermit access decisions" 11 ispolicyattachable no
pdadmin> object create /OSSEAL/Default/AuditAuth/Group/osseal-admin/logindeny \
"Audit all logindeny access decisions" 11 ispolicyattachable no
To set up policy such that no access decisions made on behalf of the root user are
audited, create the following object:
pdadmin> object create /OSSEAL/Default/AuditAuth/User/root/none "Audit no \
access decisions" 11 ispolicyattachable no
To set up policy such that all access decisions made on behalf of unauthenticated
users are audited, create the following object:
pdadmin> object create /OSSEAL/Default/AuditAuth/Unauth/all "Audit all \
access decisions" 11 ispolicyattachable no
AuditTrace resources can be defined for a specific UNIX user by using the User
keyword in the resource definition. Supported user-level trace audit levels are
exec Causes the Tivoli Access Manager for Operating Systems kernel code to
Chapter 7. Auditing 247
track program invocations initiated by the exec() system call that occur in
processes that descend from a login event for the specified user that was
detected by Tivoli Access Manager for Operating Systems. This results in
the generation of a TraceExec audit record for each detected exec() system
call. These records are generated regardless of whether the program being
executed is protected by Tivoli Access Manager for Operating Systems
policy or not.
exec_l Limits the generation of TraceExec audit records to program invocations
initiated by exec() that occur in processes for this user when the user’s
accessing identity and effective UNIX identity are not the same (which
typically happens when a user surrogates to another user).
file Results in the generation of a TraceFile audit record for all accesses to
protected file resources by the specified user.
all Activates both exec and file audit levels.
none A special case that indicates that no audit records should be generated for
the specified user even if global trace auditing is set.
User-level trace can be used by itself or together with global audit levels. With the
exception of trace level none, all trace levels are in addition to the trace levels set
with global audit.
To set the AuditTrace levels, objects of the following format are created:
/OSSEAL/policy-branch/AuditTrace/User/user-name/trace-level
where:
policy-branch
The name of the policy branch
trace-level
A valid audit trace level (exec, exec_l, file, all, or none)
user-name
The name of the UNIX user
To set up policy such that all execs by the root user are traced, create the following
object:
pdadmin> object create /OSSEAL/Default/AuditTrace/User/root/exec "Trace all execs" \
11 ispolicyattachable no
Use the pdosshowuser command to query the current user audit levels in effect for
a particular user. For example, to see the user-level audit policy that is in effect for
the root user on an Tivoli Access Manager for Operating Systems client enter the
following command.
$ pdosshowuser -a -n root
You must be an OSSEAL administrator to execute the pdosshowuser command.
Health auditing
Tivoli Access Manager for Operating Systems supports the generation of audit
records that pertain to its health. With health auditing, you can monitor the
availability of Tivoli Access Manager for Operating Systems daemons and can
monitor the lifetime of the certificates that are used to communicate with the Tivoli
Access Manager user registry. Health auditing is a global audit level.
248 Administration Guide
To generate audit records that monitor the availability of Tivoli Access Manager for
Operating Systems daemons, use the pdoscfg command to configure the
generation of heartbeat audit records.
To generate audit records that monitor the lifetime of the certificates that are used
to communicate with the Tivoli Access Manager user registry, use the pdoscfg
command to configure the generation of certificate lifetime audit records. When
controlling the generation of certificate lifetime audit records, you also control the
generation of certificate expiration warning messages that are written to the
daemon log files.
The configuration of global health auditing uses the following pdoscfg options:
v –audit_health
v –certlife_interval
v –certlife_threshold
v –heartbeat_interval
For additional information about these command options, see “pdoscfg” on page
280.
Enabling health auditing
To enable health auditing, use the –audit_health option of the pdoscfg command
to specify which health types to monitor. The following values are available:
certlife
Enables health auditing to monitor the lifetime of the certificates that are
used to communicate with the Tivoli Access Manager user registry. This
type of auditing generates certificate lifetime audit records and is known as
certificate auditing.
heartbeat
Enables health auditing to monitor the availability of Tivoli Access
Manager for Operating Systems daemons. This type of auditing generates
heartbeat audit records and is known as heartbeat auditing.
all Enables health auditing to monitor both the lifetime of the certificates that
are used to communicate with the Tivoli Access Manager user registry and
the availability of Tivoli Access Manager for Operating Systems daemons.
none Disables health auditing.
By default, health auditing to monitor the lifetime of the certificates that are used
to communicate with the Tivoli Access Manager user registry (-audit_health
certlife) is enabled.
To monitor only the availability of Tivoli Access Manager for Operating Systems
daemons, enter the following command:
$ pdoscfg -audit_health heartbeat
To monitor both the availability of Tivoli Access Manager for Operating Systems
daemons and the lifetime of the certificates that are used to communicate with the
Tivoli Access Manager user registry, enter either of the following commands:
$ pdoscfg -audit_health heartbeat,certlife
$ pdoscfg -audit_health all
To disable monitoring, enter the following command:
$ pdoscfg -audit_health none
Chapter 7. Auditing 249
For additional information, see “pdoscfg” on page 280.
Controlling certificate lifetime audit records
After enabling certificate lifetime auditing, you can control the generation of
certificate lifetime audit records using the –certlife_interval and
–certlife_threshold options of the pdoscfg command. By default the interval
between the generation of certificate lifetime audit records is seven days with a
certificate expiration threshold is 30 days.
The following example shows how to change the existing certificate lifetime
interval to five days with an expiration threshold of 15 days:
$ pdoscfg -certlife_interval 5 -certlife_threshold 15
If certificate lifetime auditing is not enabled, these values are saved. After enabling
certificate lifetime auditing, these settings take effect the next time the daemons
start.
For additional information, see “pdoscfg” on page 280.
Controlling heartbeat audit records
After enabling heartbeat auditing, you can control the generation of heartbeat audit
records using the –heartbeat_interval option of the pdoscfg command. By default
the interval between the generation of heartbeat audit records is ten minutes.
The following example shows how to change the existing heartbeat interval to 30
minutes:
$ pdoscfg -heartbeat_interval 30
If heartbeat auditing is not enabled, this value is saved. After enabling heartbeat
auditing, this setting takes effect the next time the daemons start.
For additional information, see “pdoscfg” on page 280.
Warning mode
Tivoli Access Manager for Operating Systems supports the enabling of warning
mode. Warning mode allows you to check the effects of authorization policy on a
system without enabling enforcement of the policy. If warning mode is enabled, an
audit record is generated for accesses to resources that would normally be denied
due to policy but are granted because of warning mode. View the audit log to
determine if the current authorization policy is having the desired effect. You can
enable warning mode globally for all policy or for specific protected resources.
Note: If you enable global warning, you have no enforcement in effect. Ensure that
you enable enforcement again, when required.
Enabling, disabling, and querying global warning mode
To enable global warning mode immediately, enter:
$ pdosctl –w on
To disable global warning mode immediately, enter:
$ pdosctl –w of
250 Administration Guide
To enable global warning mode to take effect the next time Tivoli Access Manager
for Operating Systems is restarted, enter:
$ pdoscfg –warning on
To disable global warning mode to take effect at the next restart, enter:
$ pdoscfg –warning off
To query the current global warning mode setting, specify the –w with no
arguments:
$ pdosctl –w
The output is:
The global warning mode setting is off
Enabling, disabling, and querying resource warning mode
To enable warning mode for a specific resource, set up a protected object policy
(POP) with warning mode enabled and attach it to the protected resource. Access
to a protected object that would normally be denied by access controls is granted if
a POP is attached or inherited with warning mode enabled. An audit record is
generated regardless of the audit level setting in the POP or the global audit level.
Warning mode is disabled by default.
For example, to enable warning mode for accesses to the protected object name
/OSSEAL/Default/NetIncoming/tcp/telnet/*.company.com, enter:
pdadmin> pop create sample_pop
pdadmin> pop modify sample_pop set warning yes
pdadmin> pop attach /OSSEAL/Default/NetIncoming/tcp/telnet/*.company.com
NetIncoming accesses using Telnet from systems with host names that match the
pattern *.company.com and that would normally be denied are now permitted. An
audit record is generated that shows that access was permitted due to resource
warning mode. To disable warning mode, set the warning attribute to no or detach
the POP from the protected object name. If you are using other attributes in the
POP for the object and you want to disable only the warning mode, leaving the
other attributes intact, set warning mode to off:
pdadmin> pop modify sample_pop set warning no
Warning mode is now disabled.
If you are using this POP only for warning mode or it is also controlling other
protected objects for which you still want warning mode enabled, detach the POP
from the protected object to disable warning mode for just that object:
pdadmin> pop detach /OSSEAL/Default/NetIncoming/tcp/telnet/*.company.com sample_pop
To query the warning mode setting in a POP, enter:
pdadmin> pop show pop_name
The audit log file
The pdosauditd daemon manages the Tivoli Access Manager for Operating
Systems audit log file. Details on the operation and configuration of the daemon
can be found in “The pdosauditd audit daemon” on page 100.
Chapter 7. Auditing 251
The active audit log file is /var/pdos/audit/audit.log. Audit records are written
to the audit log in binary format. Based on the settings of the pdosauditd daemon,
the audit log is archived when it reaches a configured maximum size and logging
continues in a new audit.log file in the same directory. The name of the archived
file has a timestamp appended to it, audit.log.YYYY-MM-DD-HH-MM-SS, and resides
in the same directory as the active log file.
The audit.log file is the input to the pdostecd Tivoli Enterprise Console daemon
and the pdoslrd log router daemon. If these daemons are configured to run and if
the active audit log file is not available, the daemons shut down. After making the
audit.log file available again, restart the daemon. For more information, see “The
pdostecd Tivoli Enterprise Console daemon” on page 104 and “The pdoslrd log
router daemon” on page 107.
Audit log consolidation
Tivoli Access Manager for Operating Systems supports the functionality to send
audit data to the following destinations (or all destinations):
v A local text file
v An e-mail address
v A remote collection point, which is a Tivoli Access Manager authorization server
(pdacld) or the Common Auditing and Reporting Service event server
The data that is sent to these destinations can be filtered and formatted.
The audit log consolidation functionality is controlled by pdoslrd, the log router
daemon. The daemon reads a Tivoli Access Manager for Operating Systems audit
record from an input channel (the audit logs), formats the record, and sends the
formatted record to the appropriate destination (local file, e-mail, or remote host).
A control file is used to specify the destination channels and associated filters. The
path name of this file is /opt/pdos/etc/pdoslrd.xml. The pdoslrd daemon reads
this file at startup to determine which destination’s channels have been enabled.
The pdoslradm command can be used to control some aspects of the pdoslrd log
router daemon and the channels in the log router configuration file.
Multiple Tivoli Access Manager for Operating Systems machines can be configured
to send audit data to the same Tivoli Access Manager authorization server as the
remote collection point, consolidating the audit data into a single file. Using the
pdoscollview command allows you to view the audit records stored in the
consolidated audit log file.
Note: Tivoli Access Manager for Operating Systems must be installed on the same
system as the Tivoli Access Manager authorization server to use the
pdoscollview command to view the consolidated audit log file. It does not,
however, have to be configured.
For information about how to specify the parameters of the pdoslrd control file,
see Chapter 4, “The log router daemon,” on page 121. For information about the
pdoslradm options, see “pdoslradm” on page 318. For information about the
pdoscollview command options, see “pdoscollview” on page 292. For information
about installing the Tivoli Access Manager authorization server (pdacld) or the
Common Auditing and Reporting event server, refer to the IBM Tivoli Access
Manager for Operating Systems: Installation Guide.
252 Administration Guide
Viewing audit logs
Use the audit view tool to search the audit log files for records and parse those
records into a readable text format. You can view all log records or filter them by a
number of parameters such as resource type, authorization decision, timestamp,
and accessor type. When you define a search using the audit view tool, the tool
parses the binary data from the audit log to a text file containing all the records
that matched your search. By default this file is called text.log and is stored in the
same directory where the audit.log file is stored.
Each time you perform a search, the text.log file is replaced with the records
matching that search. You also can view the filtered records immediately on screen
by issuing pdosaudview with the –l option.
The audit view tool is run on the command line. The command and filter options
for the audit view tool are defined in “pdosaudview” on page 270.
Here are some sample uses of the audit view tool.
v To display all audit records that were generated as a result of an access attempt
that was denied:
pdosaudview –w deny
v To display denied login attempts that occurred today for user ID maggie:
pdosaudview –s today –e today –g login –w deny –n maggie
v To display audit records recorded in the last 30 minutes:
pdosaudview –s now–30
v To write, in concise format, audit records associated with denied file accesses for
user ID bjones between October 25, 2002 and October 31, 2002 to a file called
/tmp/audout/bjones:
pdosaudview –F concise –s 2002–10–25–00:00 \
–e 2002–10–31–23:59 –g file \
–w deny –n bjones –f /tmp/audout/bjones
v To display audit records that were written in the last minute:
pdosaudview –s now
Audit log formats
Because audit logs are written to disk in binary format, you must use the audit
view tool, pdosaudview, to view them. The complete syntax of the command can
be found in “pdosaudview” on page 270. By default, the audit view tool writes its
output to a text file named text.log in the /var/pdos/audit directory.
The audit view tool displays the records in the audit log based on the value
defined for the –F option of the pdosaudview command. The following values are
valid:
concise
Indicates that the records are in the concise format.
keyvalue
Indicates that the records are in the key-value format.
verbose
Indicates that the records are in the verbose format.
The content of the records that are produced in these formats is described in
“Audit log record types” on page 257.
Chapter 7. Auditing 253
Concise format
In concise format, the output consists of one physical line of output per log record
with the data separated by commas. The fields are positional and if a field does
not have a value or if the field does not pertain to the particular event then just a
comma is displayed. There are no field or column headings. Concise output would
look similar to the following. Note that the command output illustrated here is
wrapped to fit the page.
Mon 29 Oct 2001 04:35:27 PM CST,28,P,1,TraceFile,ossyes,ossyes,Trace,wr,,
/export/home/ossyes,.sh_history,1235,/usr/bin/ksh,6
Mon 29 Oct 2001 04:35:27 PM CST,7,P,1,File,ossyes,ossyes,Check Access,wr,34,bvt,
File/export/home/ossyes,.sh_history,,,,,,1235,,/usr/bin/ksh,,,,,,,,S,,7
Mon 29 Oct 2001 04:35:38 PM CST,7,P,1,NetOutgoing,ossyes,ossyes,Check Access,C,34,
bvt,NetOutgoing/*/tcp/telnet,,,dfstest08.austin.lab.tivoli.com,tcp,23,,1239,,
/usr/bin/telnet,,,,,,,,S,,0
Mon 29 Oct 2001 04:35:44 PM CST,17,A,1,Policy,root,root,Apply,,,,,,,,,,,831
,,,,,,,,,14711,S,,0
Mon 29 Oct 2001 04:35:44 PM CST,17,A,1,Policy,root,root,Apply,,,,,,,,,,,831
,/opt/pdos/bin/pdosd,/opt/pdos/bin/pdosd,,,,,,,14711,S,,1
Mon 29 Oct 2001 04:35:45 PM CST,6,P,1,Logout,ossyes,,Logout,1235,
goblue.tivoli.com,0
Mon 29 Oct 2001 04:35:45 PM CST,7,P,1,File,root,root,Check Access,r,34,bvt,
File/opt/pdos,/usr/lib/liblpm.so,,,,,,1233,,/usr/sbin/in.telnetd,,,,,,,,S,,1
Use the Fixed Position column in the audit record format tables to locate
information on what each comma-delimited field represents.
Key-value format
In key-value format, the output consists of one physical line of output per log
record, as in concise format; however, each field is preceded by a keyword (1 to 4
characters) and equal sign (=) identifying it. In other words, the output is provided
in keyword=value format. If a field does not apply to a particular event, it is not
shown in the output. Key-value output looks similar to the following. Note that
the command output illustrated here is wrapped to fit the page.
TS=Mon 29 Oct 2001 04:35:27 PM CST,E=28,V=P,R=1,RT=TraceFile,AN=ossyes,AEN=ossyes,
A=Trace,P=wr,PRS=/export/home/ossyes,ARS=.sh_history,APID=1235,RPSN=/usr/bin/ksh,
UQ=6
TS=Mon 29 Oct 2001 04:35:27 PM CST,E=7,V=P,R=1,RT=File,AN=ossyes,AEN=ossyes,
A=Check Access,P=wr,Q=34,PBN=bvt,PON=File/export/home/ossyes,SRN=.sh_history,
APID=1235,RPSN=/usr/bin/ksh,O=S,UQ=7
TS=Mon 29 Oct 2001 04:35:38 PM CST,E=7,V=P,R=1,RT=NetOutgoing,AN=ossyes,AEN=ossyes,
A=Check Access,P=C,Q=34,PBN=bvt,PON=NetOutgoing/*/tcp/telnet,NRH=dfstest08.
austin.lab.tivoli.com,NP=tcp,NS=23,APID=1239,RPSN=/usr/bin/telnet,O=S,UQ=0
TS=Mon 29 Oct 2001 04:35:44 PM CST,E=17,V=A,R=1,RT=Policy,AN=root,AEN=root,
A=Apply,APID=831,PVN=14711,O=S,UQ=0
TS=Mon 29 Oct 2001 04:35:44 PM CST,E=17,V=A,R=1,RT=Policy,AN=root,AEN=root,
A=Apply,APID=831,RPPN=/opt/pdos/bin/pdosd,RPSN=/opt/pdos/bin/pdosd,PVN=14711,O=S,
UQ=1
TS=Mon 29 Oct 2001 04:35:45 PM CST,E=6,V=P,R=1,RT=Logout,AN=ossyes,A=Logout,APID=
1235,LL=goblue.tivoli.com,UQ=0
TS=Mon 29 Oct 2001 04:35:45 PM CST,E=7,V=P,R=1,RT=File,AN=root,AEN=root,
A=Check Access,P=r,Q=34,PBN=bvt,PON=File/opt/pdos,SRN=/usr/lib/liblpm.so,APID=
1233,RPSN=/usr/sbin/in.telnetd,O=S,UQ=1
Use the Keyword column in the audit record format tables to determine what the
indicated field represents.
This is the default format of the pdosaudview command unless the output is
written to stdout using the –l option.
254 Administration Guide
Verbose format
In verbose format, the output consists of several lines of output per log record with
each value preceded with a descriptive label and the values interpreted and fully
expanded, if possible. For example, the Audit Event field would be a text string
describing the event instead of an integer value. The start of each record is
indicated by the following text string:
***START OF NEW RECORD***
The field headings and values are displayed on multiple lines in the output. If a
field does not apply to a particular event, it is not displayed.
Verbose mode would look similar to the following:
*** START OF NEW RECORD ***
Timestamp Mon 29 Oct 2001 04:35:27 PM CST
Audit Event TRACE File access
Audit View Permit
Audit Reason Global Audit
Audit Resource Type TraceFile
Accessor Name ossyes
Accessor Effective Name ossyes
Audit Action Trace
Audit Permissions write read
Protected Resource Specification /export/home/ossyes
Accessed Resource Specification .sh_history
Accessor Process ID 1235
Running Program System Resource Name /usr/bin/ksh
Audit Uniqifier 6
*** START OF NEW RECORD ***
Timestamp Mon 29 Oct 2001 04:35:27 PM CST
Audit Event An authorization decision was made.
Audit View Permit
Audit Reason Global Audit
Audit Resource Type File
Accessor Name ossyes
Accessor Effective Name ossyes
Audit Action Check Access
Audit Permissions write read
Audit Qualifier All resource policy checks permitted
access.
Policy Branch Name bvt
Protected Object Name File/export/home/ossyes
System Resource Name .sh_history
Accessor Process ID 1235
Running Program System Resource Name /usr/bin/ksh
Audit Outcome Success
Audit Uniqifier 7
*** START OF NEW RECORD ***
Timestamp Mon 29 Oct 2001 04:35:38 PM CST
Audit Event An authorization decision was made.
Audit View Permit
Audit Reason Global Audit
Audit Resource Type NetOutgoing
Accessor Name ossyes
Accessor Effective Name ossyes
Audit Action Check Access
Audit Permissions connect
Audit Qualifier All resource policy checks permitted
access.
Policy Branch Name bvt
Protected Object Name NetOutgoing/*/tcp/telnet
Chapter 7. Auditing 255
Network Remote Host Identifier dfstest08.austin.lab.tivoli.com
Network Protocol tcp
Network Service 23
Accessor Process ID 1239
Running Program System Resource Name /usr/bin/telnet
Audit Outcome Success
Audit Uniqifier 0
*** START OF NEW RECORD ***
Timestamp Mon 29 Oct 2001 04:35:44 PM CST
Audit Event The policy version has been set
in the Kernel Policy Cache.
Audit View Admin
Audit Reason Global Audit
Audit Resource Type Policy
Accessor Name root
Accessor Effective Name root
Audit Action Apply
Accessor Process ID 831
Policy Version Number 14711
Audit Outcome Success
Audit Uniqifier 0
*** START OF NEW RECORD ***
Timestamp Mon 29 Oct 2001 04:35:44 PM CST
Audit Event The policy version has been set
in the Kernel Policy Cache.
Audit View Admin
Audit Reason Global Audit
Audit Resource Type Policy
Accessor Name root
Accessor Effective Name root
Audit Action Apply
Accessor Process ID 831
Running Program Protected Name /opt/pdos/bin/pdosd
Running Program System Resource Name /opt/pdos/bin/pdosd
Policy Version Number 14711
Audit Outcome Success
Audit Uniqifier 1
*** START OF NEW RECORD ***
Timestamp Mon 29 Oct 2001 04:35:45 PM CST
Audit Event Logout occurred.
Audit View Permit
Audit Reason Global Audit
Audit Resource Type Logout
Accessor Name ossyes
Audit Action Logout
Accessor Process ID 1235
Login Location Identifier goblue.tivoli.com
Audit Uniqifier 0
*** START OF NEW RECORD ***
Timestamp Mon 29 Oct 2001 04:35:45 PM CST
Audit Event An authorization decision was made.
Audit View Permit
Audit Reason Global Audit
Audit Resource Type File
Accessor Name root
Accessor Effective Name root
Audit Action Check Access
Audit Permissions read
Audit Qualifier All resource policy checks permitted
access.
Policy Branch Name bvt
Protected Object Name File/opt/pdos
256 Administration Guide
System Resource Name /usr/lib/liblpm.so
Accessor Process ID 1233
Running Program System Resource Name /usr/sbin/in.telnetd
Audit Outcome Success
Audit Uniqifier 1
This is the default format of the pdosaudview command if the –l option is
specified.
Audit log record types
Audit log records are divided into three distinct types based on their content:
v General
v Trace
v Logout
The information contained in the record varies based not only on the record type,
but also on the type of resource being audited.
The content of the three types of audit log records is described first, and then the
method for viewing the log records is discussed next.
General audit event record type
Most audit events use the general audit event record type. These include:
v Login-related events
v Authorization decision events
v Administration events
v Informational events
The content of a general audit event is described in Table 69.
Table 69. General audit event record type
Fixed
position Keyword Field heading Description
1 TS Timestamp Date and time that the audit record was
generated.
2 E Audit Event Identifier Type of event that occurred. The audit event
identifiers are enumerated in “Audit event
identifiers” on page 262.
3 V Audit View Audit view associated with the event.
A Admin
D Deny
H Health
I Info
P Permit
T Trace
W Warning
4 R Audit Reason One of the following reasons why audit
record was generated:
1 Global Audit
2 Resource Audit
3 Global Warning
4 Resource Warning
5 User Audit
6 Global Health
Chapter 7. Auditing 257
Table 69. General audit event record type (continued)
Fixed
position Keyword Field heading Description
5 RT Audit Resource Type One of the following resource types:
v Azn
v Cred
v File
v Health
v Login
v Logout
v NetIncoming
v NetOutgoing
v Password
v Policy
v Process
v Sudo
v Surrogate
v TCB
6 AN Accessor Name The name of the accessing UNIX user
7 AEN Accessor Effective
Name
The effective name of the accessing UNIX
user
8 A Audit Action One of the following actions for the audit
event:
v Add
v Apply
v CertLife
v Change
v Check Access
v Delete
v Disable
v Enable
v Heartbeat
v Isolated
v Login
v Logout
v Not Isolated
v Register
v Retrieve
v Start
v Stop
v Trace
v Trust
v Untrust
258 Administration Guide
Table 69. General audit event record type (continued)
Fixed
position Keyword Field heading Description
9 P Audit Permissions If the Audit Action field value is Check
Access, the specific actions for the access
request.
C connect
D chdir
G surrogate
K kill
L login
N create
R rename
U utime
d delete
l readdir
o chown
p chmod
r read
w write
x execute
10 Q Audit Qualifier Additional information for the audit event.
See “Audit qualifiers” on page 264 for
details.
Note: For password strength-related
qualifiers, failed attempts to change a
password on AIX systems are not audited
by Tivoli Access Manager for Operating
Systems. The AIX system does not call
Tivoli Access Manager for Operating
Systems when a password change request
fails.
11 PBN Policy Branch Name Policy Branch Name. Only provided if the
Protected Object Name field is filled in.
12 PON Protected Object
Name
Protected Object Name associated with the
audit event.
For events with Audit Action of Check
Access
Tail of the Protected Object Name
used to determine if access is allowed.
For events with Audit Resource Type of
Policy and the Audit Action is Apply
Protected Object Name to which the
policy was applied.
Chapter 7. Auditing 259
Table 69. General audit event record type (continued)
Fixed
position Keyword Field heading Description
13 SRN System Resource
Name
If the Audit Resource Type is File
System name of the file being
accessed.
If the Audit Resource Type is TCB and the
Audit Action is Trust or Untrust
The name of the TCB resource that
was marked trusted or untrusted.
If the Audit Resource Type is Login and the
Audit View is Admin and the Audit Action is
Disable or Enable
The name of the user account that was
enabled or disabled for login.
If the Audit Resource Type is Password
The name of the user account.
If the Audit Resource Type is Health and
the Audit Action is CertLife
The name of the key file that contains
the certificate. Following the key file
name is the certificate label.
14 SN Surrogate Name If the Audit Resource Type is Surrogate, the
user name or ID of the target user or the
group name or ID of the target group.
15 NRH Network Remote Host
Identifier
If the Audit Resource Type is NetIncoming
The name of the remote host where
access originated.
If the Audit Resource Type is NetOutgoing
The name of the remote host being
accessed.
If the Audit Resource Type is Health and
the Audit Action is CertLife
The name of the SSL server that is
accepting the SSL connection using the
certificate that is specified in the
System Resource Name field.This field will be a host name if the address
can be converted; otherwise, it is an IP
address.
16 NP Network Protocol If the Audit Resource Type is NetIncoming
or NetOutgoing, contains the protocol being
used in the access.
260 Administration Guide
Table 69. General audit event record type (continued)
Fixed
position Keyword Field heading Description
17 NS Network Service
If the Audit Resource Type is NetIncoming
The service name or port number of
the local service being accessed.
If the Audit Resource Type is NetOutgoing
The service name or port number of
the remote network service being
accessed.
If the Audit Resource Type is Health and
the Audit Action is CertLife
The port number of the SSL server
that is accepting the SSL connection
using the certificate that is specified in
the System Resource Name field.
18 LL Login Location
Identifier
If the Audit Resource Type is Login and the
login occurred from a local terminal, this is
the terminal name. If the login occurred on
a remote system, this is either the host
name or the IP address of the remote
system.
19 APID Accessor Processor ID The process identifier (pid).
20 RPPN Running Program
Protected Name
If the running program is registered in the
Trusted Computing Base (TCB), the name
under which the program is registered.
21 RPSN Running Program
System Resource
Name
The name of the running program as
invoked.
22 SC Sudo Command and
Arguments
If the Audit Resource Type is Sudo and the
command and arguments are relevant to the
Sudo policy, the target command name and
arguments.
23 SU Sudo User Name If the Audit Resource Type is Sudo and the
command and arguments are relevant to the
Sudo policy, the target user name that the
Sudo command will be executed as.
24 SF Sudo Flags If the Audit Resource Type is Sudo, this field
indicates whether the Sudo policy required
the invoker password, the target user
password, or both passwords before
running the target command. Otherwise this
field contains no value.
Chapter 7. Auditing 261
Table 69. General audit event record type (continued)
Fixed
position Keyword Field heading Description
25 AP Additional Parameters Additional information that is related to the
particular audit event.
If Audit Event is 23
The Global Audit Level setting and
the Global Warning Mode setting.
If Audit Event is 32
The Global Audit Level setting.
If Audit Event is 33
The Global Warning Mode setting.
If Audit Event is 34
The heartbeat number and the
heartbeat reporting interval in
minutes.
If Audit Event is 35
The expiration date of the certificate
and the number of days before the
certificate expires.
26 CDAF TCB Changed Data
Attr Flags
Additional information related to Trusted
Computing Base (TCB) resources.
27 PE Policy Epoch Additional information related to Policy
resources.
28 PVN Policy Version
Number
Additional information related to Policy
resources.
29 O Audit Outcome If the audit record was generated as a result
of an action taken due to an error condition,
this field contains F or Failure. Otherwise,
this field contains S or Success.
30 FS Audit Fail Status If the Audit Outcome field is F or Failure,
the error code for the error.
31 UQ Audit Uniqifier Integer field that uniquely identifies audit
records that occur within the same second.
The value starts at 0 (for the first record
that is recorded in that second) and
increments for each subsequent record that
is written in that second.
Audit event identifiers
The audit event identifier is a field in the audit record that identifies the type of
event that occurred. The possible content of the audit event identifier field is
described in Table 70.
Table 70. Description of audit event identifiers
Audit event
identifier
(E) Description
1 A login-related authorization decision was made.
2 User account was disabled (locked), preventing future log ins.
3 User account was disabled (suspended), preventing future log ins.
262 Administration Guide
Table 70. Description of audit event identifiers (continued)
Audit event
identifier
(E) Description
4 User account was enabled for login.
5 The password change time was modified by an administrator.
6 Logout occurred. (See “Logout audit event record type” on page 267 for a
description of the audit record used for this event.)
7 An authorization decision was made.
8 An authorization decision API failure occurred.
9 Access granted to a file marked untrusted in the TCB database.
10 Tivoli Access Manager for Operating Systems kernel lost contact with pdosd.
Accesses are being denied by default.
11 Tivoli Access Manager for Operating Systems kernel has regained contact
with pdosd. Accesses are determined by authorization policy.
12 Tivoli Access Manager user registry is unavailable (isolation mode).
13 Tivoli Access Manager user registry is now available.
14 Credential acquired.
15 Policy not applied for an invalid protected object name.
16 Policy applied for a protected object name.
17 Policy version set in the Kernel Policy Cache.
18 Kernel Policy Cache epoch updated.
19 A file has been added to the TCB database
20 A file has been removed from the TCB database
21 A file has been marked untrusted
22 A file has been marked trusted
23 A Tivoli Access Manager for Operating Systems process has started
24 A Tivoli Access Manager for Operating Systems process has stopped
25 A process has been added into the watchdog set
26 A kosseal_register call was made to acquire privileged access.
27 TRACE Exec program (See “Trace audit event record type” on page 265 for a
description of the audit record used for this event.)
28 TRACE File access (See “Trace audit event record type” on page 265 for a
description of the audit record used for this event.)
29 Password change has occurred.
30 A password-change-related authorization decision was made.
31 The pdosctl command requested a stop of a Tivoli Access Manager for
Operating Systems process.
32 The pdosctl command modified the global audit level of a Tivoli Access
Manager for Operating Systems process.
33 The pdosctl command modified the global warning mode of a Tivoli Access
Manager for Operating Systems process.
34 Heartbeat event.
35 The lifetime of the certificate was checked.
36 The password was changed by an administrator.
Chapter 7. Auditing 263
Table 70. Description of audit event identifiers (continued)
Audit event
identifier
(E) Description
37 The password was changed by the user.
Audit qualifiers
The audit qualifier is a field in the audit record that provides additional
information about the audit event. The possible content of the audit qualifier field
is described in Table 71.
Table 71. Description of audit qualifiers
Audit
qualifier
(Q) Description
Login-related qualifiers
1 User account is locked.
2 The user password has expired and no further grace logins remain.
3 Maximum number of concurrent logins reached.
4 Lock time interval has not elapsed.
5 Minimum time interval required between password changes has not elapsed.
6 User account was unlocked because lock time interval has elapsed.
7 Maximum number of failed logins reached.
8 Maximum inactive days has elapsed.
9 Maximum time interval since last password change has elapsed.
10 Checking login location access control policy.
11 Checking access restrictions associated with login location access control
policy.
12 Checking login holiday access control policy.
13 Checking access restrictions associated with login holiday access control
policy.
14 Checking time of day login access control policy.
15 Unknown user attempted login.
16 Login denied by native authentication method.
17 User account modified by administrative action.
18 All login policy checks permitted access.
General resource-related qualifiers
30 Checking resource access control policy.
31 Checking access restrictions associated with resource access control policy.
32 Checking trust state for TCB resource.
33 Error occurred reading the request message data.
34 All resource policy checks permitted access.
35 Access denied due to the policy defined in the authorization rule
(AuthzRule).
36 Access denied due to the absence of the traverse (T) permission.
264 Administration Guide
Table 71. Description of audit qualifiers (continued)
Audit
qualifier
(Q) Description
Password strength-related qualifiers
50 Password does not contain the required minimum number of alphabetic
characters.
51 Password does not contain the required minimum number of alphanumeric
characters.
52 Password does not contain the required minimum number of numeric
characters.
53 Password does not contain the required minimum number of lowercase
characters.
54 Password does not contain the required minimum number of uppercase
characters.
55 Password does not contain the required minimum number of special
characters.
56 Password exceeds the maximum allowed number of repeated characters.
57 Password contains the user name or is contained in the user name.
58 Password is a recently used old password.
59 Password contains the old password or is contained in the old password.
60 Password does not contain the required number of characters.
61 Password exceeds the allowed number of consecutive characters that are
common with the previous password.
62 Password contains a numeric first or last character.
Daemon-related qualifiers
75 pdosd
76 pdoswdd
77 pdosauditd
78 pdoslpmd
79 pdoslrd
Report-related qualifiers
80 The number of days before the certificate expires is less than the value of the
certlife_threshold attribute.
Trace audit event record type
Trace audit event records record when an exec() is done or when a file access
occurs.
The content of a trace audit event record is described in Table 72.
Table 72. Trace audit event record type
Fixed
position Keyword Field heading Description
1 TS Timestamp Date and time audit record was generated.
Chapter 7. Auditing 265
Table 72. Trace audit event record type (continued)
Fixed
position Keyword Field heading Description
2 E Audit Event
Identifier
Type of event that occurred.
27 TRACE Exec program
28 TRACE File access
3 V Audit View Audit view associated with the event.
D Deny
P Permit
T Trace
4 R Audit Reason Reason why audit record was generated.
1 Global Audit
2 User Audit
5 RT Audit Resource Type Resource type
v TraceExec
v TraceFile
6 AN Accessor Name The name of the accessing UNIX user
7 AEN Accessor Effective
Name
The effective name of the accessing UNIX
user
8 A Audit Action Trace
9 P Audit Permissions This field contains the specific actions
associated with the access request.
D chdir
K kill
N create
R rename
U utime
d delete
l readdir
o chown
p chmod
r read
w write
x execute
10 Q Audit Qualifier Additional information for the audit event.
See “Audit qualifiers” on page 264 for details
11 PRS Protected Resource
Specification
v If the Audit Resource Type is TraceFile, the
name of the accessed file resource.
v If the Audit Resource Type is TraceExec,
the name of the executed program as
invoked.
266 Administration Guide
Table 72. Trace audit event record type (continued)
Fixed
position Keyword Field heading Description
12 ARS Accessed Resource
Specification
v If the Audit Resource Type is TraceFile, the
name of the file resource used in the
access.
v If the Audit Resource Type is TraceExec,
the name of the file resource as specified in
the exec() operation.
– If the file is a setuid program, a [SU]
token follows the name.
– If the file is a setgid program, a [SG]
token follows the name.
– If the file is both a setuid program and a
setgid program, a [SUG] token follows
the name.
The argv string provided in the exec() call,
which normally reflects the command
arguments, follows enclosed in parentheses.
For example:
/usr/bin/ps [SG] (ps –elf | grep pdos)
13 APID Accessor Processor
ID
The process identifier (pid)
14 RPSN Running Program
System Resource
Name
Name of the running program as executed.
15 UQ Audit Uniqifier Integer field that uniquely identifies audit
records that occur within the same second.
The value starts at 0 (for the first record that
is recorded in that second) and increments for
each subsequent record that is written in that
second.
Logout audit event record type
Logout audit event records are used for user logout events. Table 73 describes the
content of the logout audit event record type.
Table 73. Logout audit event record type
Fixed
position Keyword Field heading Description
1 TS Timestamp Date and time audit record was generated.
2 E Audit Event Identifier Type of event that occurred.
6 Logout Occurred
3 V Audit View Audit view associated with the event.
P Permit
4 R Audit Reason Reason why audit record was generated.
1 Global Audit
2 User Audit
5 RT Audit Resource Type Resource type: Logout
6 AN Accessor Name The name of the UNIX user who logged out
Chapter 7. Auditing 267
Table 73. Logout audit event record type (continued)
Fixed
position Keyword Field heading Description
7 AEN Accessor Effective
Name
The effective name of the accessing UNIX
user
8 A Audit Action The action for the audit event: Logout
9 APID Accessor Processor ID The process identifier (pid)
10 LL Login Location
Identifier
If the login terminal information from the
original login is available, it is provided
here. This will either be the local terminal
device name, such as /dev/tty0, or a
remote host name or IP address.
11 UQ Audit Uniqifier Integer field that uniquely identifies audit
records that occur within the same second.
The value starts at 0 (for the first record
recorded in the second) and is incremented
for each subsequent record written in that
second.
268 Administration Guide
Chapter 8. Commands
This chapter provides an overview of the commands available in Tivoli Access
Manager for Operating Systems.
Several of the commands require that the user be a Tivoli Access Manager for
Operating Systems runtime administrator. A runtime administrator is any user that
is a member of both of the following groups:
v osseal-admin group in the Tivoli Access Manager user registry
v osseal group in UNIX
The pdosaudview command requires that the user be a Tivoli Access Manager
auditor. An auditor is any user that is a member of both of the following groups:
v osseal-auditors group in the Tivoli Access Manager user registry
v ossaudit group in UNIX
Default policy has been established to ensure that the commands operate
successfully and securely. Changes to the default policy affecting these commands
might compromise the security of your system or render the commands
inoperative. Refer to Chapter 2, “Policy,” on page 7 for more detailed information
on the default policy.
Note: The –t trace_string option available on many of the commands is primarily
intended for use by IBM Software Support. The contents of the trace_string is
not described in this document. For more information, see the IBM Tivoli
Access Manager for Operating Systems: Problem Determination Guide.
© Copyright IBM Corp. 2000, 2005 269
pdosaudview
Parses the binary audit log produced by Tivoli Access Manager for Operating
Systems into a number of readable formats.
Syntax
pdosaudview
[–l]
[–g resource_type]
[–z azn_resource_type]
[–p process]
[–w audit_view]
[–a action]
[–r reason]
[–o outcome]
[–n accessor_name | accessor_uid]
[–c accessor_effective_name | accessor_effective_uid]
[–s start_time]
[–e end_time]
[–f output_file]
[–i audit_file]
[–F format]
[–M mapping_type]
[–R timestamp uniqifier]
[–N]
[–O]
[–L filter_file_name]
[–I filter_name]
pdosaudview –h
pdosaudview –V
pdosaudview –?
Description
The pdosaudview command is used to process a binary audit file produced by
Tivoli Access Manager for Operating Systems and convert it into readable text. The
resulting output can be viewed, printed, or analyzed by scripts and other
programs.
The output format of the pdosaudview command can be concise, key-value, or
verbose depending on the value defined for the –F option. A description of these
formats can be found in “Audit log formats” on page 253.
A variety of filtering options are provided on the command to limit the amount of
output produced: –g, –z, –p, –w, –a, –o, –n, –c, –s, –e, –R, and –I. Audit records
can be selected based on such factors as type of event, time of event, outcome of
the event, and type of resource affected.
By default, all audit logs in the /var/pdos/audit directory are processed by the
command. To limit the processing to a specific file, use the –i option.
pdosaudview
270 Administration Guide
Options
–? Displays the usage message.
–a action
Specifies the action on which to filter the records. The following values are
valid:
v add
v apply
v certLife
v change
v check_access
v delete
v disable
v enable
v heartbeat
v isolated
v login
v logout
v not-isolated
v register
v retrieve
v start
v stop
v trace
v trust
v unknown
v untrust
–c accessor_effective_name | accessor_effective_uid
Specifies the accessor effective name or accessor effective UID on which to
filter the records.
–e end_time[-n]
Specifies the end time on which to filter the values. You can specify this
option as a timestamp in the form of YYYY-MM-DD or YYYY-MM-DD-hh:mm:ss
(using a 24-hour clock) or by using the special qualifiers of today and now
to represent the current day and the current minute, respectively.
Optionally when using the special qualifiers, an integer value, n, can be
used to specify the previous number of days (today-n) or to specify the
previous number of minutes (now-n). Only records that were logged before
or at the end time are provided in the output.
–f output_file
Specifies the fully qualified file to receive the ASCII output of the
command. If not specified, the command writes the output to the
/var/pdos/audit/text.log file.
–F format
Specifies the formatting style of the audit records. The following values are
valid:
v concise
v keyvalue
v verbose
The default is keyvalue unless the –l option is used. If the –l option is
specified without the –F option, records are written in verbose format.
pdosaudview
Chapter 8. Commands 271
–g resource_type
Specifies the resource type on which to filter the records. The following
values are valid:
v azn
v cred
v daemon
v file
v health
v login
v logout
v netincoming
v netoutgoing
v password
v policy
v sudo
v surrogate
v tcb
v trace_exec
v trace_file
–h Displays the usage message.
–i audit_file
Specifies the path name of the audit file that is the input audit log to be
processed. If this option is omitted, all audit logs in the /var/pdos/audit
directory are processed.
–I filter_name
Specifies the name of the filter definition to be used. The name of the file
containing the filter definition is given by the –L option. If the –L option is
not specified, the file /opt/pdos/etc/pdoslrd.xml is used. For an
explanation of the format of a filter definition, see the section on pdoslrd in
Chapter 4, “The log router daemon,” on page 121. The filter that is defined
by this option is another way to limit the output of the pdosaudview
command. The filter works in conjunction with the other command options
that limit output (such as –g, –z, –p, –w, –a).
–l Prints command output to the screen. If the –F option is not specified, the
records are written in verbose format.
–L filter_file_name
Specifies the file name of a filter file, that is, the file that contains the filter
definition whose name is specified by the –I option. The default is
/opt/pdos/etc/pdoslrd.xml, if it exists. If it does not exist, the user must
specify the –L option when the –I option is specified.
–M mapping_type
Displays the mapping of audit record fields. The following values are
valid:
v all
v event
v keyword
v outcome
v permission
v qualifier
v reason
v view
pdosaudview
272 Administration Guide
–n accessor_name | accessor_uid
Specifies the accessor name or accessor user ID on which to filter the
records.
–N Indicates that the host name of the machine that originally generated the
audit record will be included in the output.
–o outcome
Specifies the outcome on which to filter the values. The following values
are valid:
v failure
v success
–O Indicates that the domain name will be included in the output of each
audit record.
–p process
Specifies the process on which to filter the values. This process is the one
that generated the audit event. The following values are valid:
v AUDITD
v CTL
v GENERAL
v KERNEL
v LPM
v LRD
v PDOSD
v TCB
v WATCHDOG
This field is no longer displayed in the output of the pdosaudview
command. This option, maintained for backward compatibility, allows you
to show only the audit events that were generated by a specific
component.
–r reason
Specifies the reason on which to filter the records. The following values are
valid:
v global_audit
v global_warning
v resource_audit
v resource_warning
v user_audit
–R timestamp uniqifier
Selects the specific audit record given its timestamp using a 24-hour clock
(YYYY-MM-DD-hh:mm:ss) and its uniqifier.
–s start_time[-n]
Specifies the start time on which to filter the values. You can specify this
option as a timestamp in the form of YYYY-MM-DD or YYYY-MM-DD-hh:mm:ss
(using a 24-hour clock) or by using the special qualifiers of today and now
to represent the current day and the current minute, respectively.
Optionally when using the special qualifiers, an integer value, n, can be
used to specify the previous number of days (today-n) or to specify the
previous number of minutes (now-n). Only records that were logged at or
after the specified start time are provided in the output.
–V Displays the version information.
pdosaudview
Chapter 8. Commands 273
–w audit_view
Indicates the audit view on which to filter the records. The following
values are valid:
v admin
v deny
v info
v permit
v trace
v warning
–z azn_resource_type
Specifies the authorization resource type on which to filter the records. The
following values are valid:
v file
v netincoming
v netoutgoing
v login
v surrogate
v sudo
Authorization
You must be a Tivoli Access Manager for Operating Systems auditor to use this
command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
v To display audit records with a resource type of login, enter:
pdosaudview –g login
v To display audit records for surrogate accesses that were permitted yesterday,
enter:
pdosaudview –s today–1 –e today–1 –g surrogate –w permit
v To display to the screen all audit records that written within the previous
minute, enter:
pdosaudview –l –s now–1 –e now–1
More examples can be found in “Viewing audit logs” on page 253.
pdosaudview
274 Administration Guide
pdosbkup
Backs up Tivoli Access Manager for Operating Systems databases and
configuration files.
Syntax
pdosbkup [–f file_name] [–p directory_path] [–x]
pdosbkup –h
pdosbkup –V
pdosbkup –?
Description
The pdosbkup command backs up all files and directories that are listed in the
/opt/pdos/etc/pdosbkuplist file. If the –x option is specified, backs up all files and
directories that are listed in the /opt/pdos/etc/pdosbkuplistx file. By default, the
archive file that is created as the backup file is placed in the /var/pdos/pdosbkup
directory with a file name of the form pdosbkupDDMMMYYYY.hh_mm_ss.tar.
The –p option can be used to change the directory where the backup file is stored.
The –f option can be used to change the name of the file created.
If the pdosbkup command is executed while the Tivoli Access Manager for
Operating Systems daemons are running, the state of some of the files can change
during the backup.
Options
–? Displays the usage message.
–f file_name
Specifies the name of the backup file.
–h Displays the usage message.
–p directory_path
Specifies the name of the directory in which to place the backup file.
–V Displays the version information.
–x Performs an extended backup.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
pdosbkup
Chapter 8. Commands 275
Examples
v To back up critical Tivoli Access Manager for Operating Systems configuration
files, enter:
pdosbkup
If the backup was done on December 7, 2002 at 04:30:00, the name of the backup
file would be /var/pdos/pdosbkup/pdosbkup07Dec2002.04_30_00.tar.
v To do an extended Tivoli Access Manager for Operating Systems backup and
store the result in the /var/disaster_rcvy/December2002.tar file, enter:
pdosbkup –x –p /var/disaster_rcvy –f December2002.tar
pdosbkup
276 Administration Guide
pdosbranchcfg
Controls the configuration of a Tivoli Access Manager for Operating Systems
machine to multiple policy branches.
Syntax
pdosbranchcfg –add policy_branch –admin_name admin_name –admin_pwd
admin_password [–pos position] [–domain domain]
pdosbranchcfg –delete policy_branch –admin_name admin_name –admin_pwd
admin_password [–domain domain]
pdosbranchcfg –list
pdosbranchcfg –move policy_branch [–pos position]
pdosbranchcfg –h
pdosbranchcfg –V
pdosbranchcfg –?
Description
The pdosbranchcfg command is used to control the configuration of a Tivoli
Access Manager for Operating Systems machine to multiple policy branches.
During configuration a machine is configured to its initial policy branch using the
–branch option of the pdoscfg command. The pdosbranchcfg command is used to
configure a machine to additional policy branches and to modify the precedence
order of the configured policy branches for that machine.
To configure a machine to an additional policy branch, use the –add option. With
this option, you can use the –pos option to specify the position in the precedence
order of the added policy branch. If the –pos option is not specified, the policy
branch is placed at the lowest precedence. For each policy branch to be added to
the configuration, you must run the command with the –add option.
To change the precedence order of the policy branches for a machine, use the
–move option. With this option, you can use the –pos option to specify the new
position for a policy branch in the precedence order. If the –pos option is not
specified, the policy branch is placed at the lowest precedence. For each policy
branch to move in the configuration, you must run the command with the –move
option.
The position specifies the position in the precedence order with 1 being of highest
precedence. If -pos 2 is specified with the –add or –move option, the specified
policy branch is placed second in the precedence order and any of the other
branches are shifted accordingly to a lower precedence. If the –pos option specifies
a number that is greater than the number of configured policy branches, the policy
branch is placed at the lowest precedence.
To unconfigure a machine from a policy branch, use the –delete option. To
unconfigure the machine from multiple policy branches, run the command and
specify the –delete policy_branch for each policy branch to be removed from the
configuration.
pdosbranchcfg
Chapter 8. Commands 277
To list the configured policy branches and their precedence order, use the –list
option.
If the –add or –delete option is specified, the administrator name and password
are required. If they are not specified, they are prompted for. The administrator
name and password are required to add or delete a machine from the group that
stores the branch membership (pdosd-branch/policy-branch).
Options
–? Displays the usage message.
–admin_name admin_name
Specifies the Tivoli Access Manager administrator name.
–admin_pwd admin_password
Specifies the Tivoli Access Manager administrator password. This option is
used in combination with the –admin_name option.
–domain domain
Specifies the name of the Tivoli Access Manager server domain.
–h Displays command help.
–list Displays the current list of configured policy branches and their
precedence order.
–add policy_branch
Adds the specified policy branch to the configuration. To specify the
precedence of the added policy branch, use the –pos option. If the –pos
option is not specified, the added policy branch is added to the end of the
list of configured policy branches (lowest precedence).
–delete policy_branch
Deletes the specified policy branch from the configuration. This option can
be specified multiple times. You cannot remove the initial policy branch.
–move policy_branch
Moves the specified policy branch within the configuration. To specify the
precedence, use the –pos option. If the –pos option is not specified, the
policy branch is moved to the end of the list of configured policy branches
(lowest precedence).
–pos position
Specifies the position in the precedence order for the policy branch within
the configuration. This option can be used in conjunction with –add or
–move option.
–V Displays the version of the command.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
that has privileges to create or modify groups and users to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
pdosbranchcfg
278 Administration Guide
Examples
v To view the configured policy branches and their precedence, enter:
pdosbranchcfg -list
v To add the MYAPP policy branch to the configuration at position 2 in the
precedence order, enter:
pdosbranchcfg -add MYAPP –pos 2 -admin_name sec_master -admin_pwd password
v To change the precedence of the MYAPP policy branch to position 4 in the
precedence order, enter:
pdosbranchcfg -move MYAPP -pos 4
v To remove the MYAPP policy branch from the configuration, enter:
pdosbranchcfg -delete MYAPP -admin_name sec_master -admin_pwd password
pdosbranchcfg
Chapter 8. Commands 279
pdoscfg
Configures Tivoli Access Manager for Operating Systems.
Syntax
pdoscfg
[–AD_domain domain] [–admin_cred_refresh minutes]
[–admin_name admin_user_name] [–admin_pwd admin_user_password]
[–audit_deny_actions osseal_action_group osseal_action_bits]
[–audit_health health_types] [–audit_level audit_levels]
[–audit_logflush seconds] [–audit_log_size bytes]
[–audit_permit_actions osseal_action_group osseal_action_bits]
[–autostart on | off]
–branch policy_branch
[–certlife_interval days] [–certlife_threshold days]
[–cred_hold minutes] [–cred_response_wait minutes]
[–critical_cred_group group_name] [–critical_cred_refresh minutes]
[–dns on | off] [–ffdc_capture on | off]
[–heartbeat_interval minutes] [–hostname host_name]
[–kmsg_hnd_threads number_threads] [–ldap_ssl_cacert ldap_certificate_name]
[–local_domain management_domain] [–login_policy on | off]
[–lrd_admin_name admin_user_name] [–lrd_admin_pwd admin_user_password]
[–lrd_cars_ssl_add label]
[–lrd_cars_ssl_cacert ssl_cacert_name] [–lrd_cars_ssl_delete label]
[–lrd_cars_user_name_add cars_user_name]
[–lrd_cars_user_name_delete cars_user_name]
[–lrd_cars_user_name_pwd cars_user_password] [–lrd_config on | off]
[–lrd_local_domain management_domain]
[–net_ACL_limited on | off] [–pdosauditd_log_entries number_log_entries]
[–pdosauditd_logs number_logs] [–pdosd_init_wait minutes]
[–pdosd_log_entries number_log_entries] [–pdosd_logs number_logs]
[–pdoslpmd_failure_audit_seconds seconds]
[–pdoslpmd_log_entries number_log_entries] [–pdoslpmd_logs number_logs]
[–pdoslpmd_max_pending_logins number_logins]
[–pdoslrd_log_entries number_log_entries] [–pdoslrd_logs number_logs]
[–pdoswdd_log_entries number_log_entries] [–pdoswdd_logs number_logs]
[–refresh_interval minutes] [–registry_ssl_cacert ssl_certificate_name]
[–rspfile file_name] [–ssl_listening_port port]
–suffix suffix [–tcb_ignore_ctime on | off]
[–tcb_interval seconds] [–tcb_max_file_size megabytes]
[–tcb_monitor_threads number_threads] [–tcb_nocrc_on_exec on | off]
[–uid on | off] [–user_cred_refresh minutes] [–verbose]
[–warning on | off]
pdoscfg –delete options
pdoscfg –lrd_cars_ssl_list
pdoscfg –lrd_cars_user_name_list
pdoscfg –rspfile file_name
pdoscfg –help [option]
pdoscfg –operations
pdoscfg
280 Administration Guide
pdoscfg –usage
pdoscfg –version
pdoscfg –V
pdoscfg –?
Description
Use the pdoscfg command to initially configure Tivoli Access Manager for
Operating Systems. After the initial configuration, use the pdoscfg command to
modify the configuration attributes. The changes that are made with the pdoscfg
command take effect the next time Tivoli Access Manager for Operating Systems is
started.
You can use the pdoscfg command to delete attributes from the configuration files.
The daemons will use the default values the next time you start Tivoli Access
Manager for Operating Systems.
After the initial configuration, you cannot change the Active Directory domain
with the –AD_domain option. This domain is required when the Tivoli Access
Manager Runtime component is configured to multiple Active Directory domains.
For Tivoli Access Manager for Operating Systems, the Active Directory domain
must be the same for all clients that are configured to the same Tivoli Access
Manager policy server.
To re-configure the value of the –admin_name, –admin_pwd, –branch,
–local_domain, or –suffix option, you must use the pdosucfg command to
unconfigure Tivoli Access Manager for Operating Systems. Then, use the pdoscfg
command to re-configure the options with different values.
To re-configure the value of the –ssl_listening_port, –registry_ssl_cacert, or
–ldap_ssl_cacert option, you must stop Tivoli Access Manager for Operating
Systems before running the pdoscfg command.
Options
Options for the configuration command are described in this section. The
definition and default, if applicable, for each option is given.
–? Displays command usage information.
–AD_domain domain
Specifies the name of the Active Directory domain that contains the all of
the users and groups used by Tivoli Access Manager for Operating
Systems. This option is required when configuring Tivoli Access Manager
for Operating Systems into a Tivoli Access Manager environment that uses
multiple Active Directory domains. The specified domain must be the same
for all Tivoli Access Manager for Operating Systems clients that are
configured to the same Tivoli Access Manager policy server. For all other
situations, this option is not valid.
–admin_cred_refresh minutes
Specifies the refresh interval of administrator credentials in minutes. The
default is 360.
pdoscfg
Chapter 8. Commands 281
–admin_name admin_user_name
Specifies the name of the Tivoli Access Manager administrator. The default
is sec_master.
–admin_pwd admin_user_password
Specifies the password for the Tivoli Access Manager administrator. Use in
combination with the –admin_name option. Replaces the –sec_master_pwd
option.
–audit_deny_actions osseal_action_group osseal_action_bits
Specifies the [OSSEAL] action group followed by a list of the Tivoli Access
Manager for Operating Systems action bits to be audited. Valid action bits
are DKNRUdloprwxCGL. There is no default.
To audit actions defined with this option, the deny and logindeny global
audit levels must be defined in the configuration file or explicitly set with
options of the pdosctl command for the current invocation of the daemon.
–audit_health health_types
Specifies a comma-separated list of audit health types. During a
reconfiguration, the value specified for this option replaces the current
value. The following values are valid:
v all
v certlife
v heartbeat
v none
The default is certlife.
–audit_level audit_levels
Specifies a comma-separated list of audit levels. The following values are
valid:
v admin
v all
v deny
v logindeny
v loginpermit
v info
v none
v permit
v trace_exec
v trace_exec_l
v trace_exec_root
v trace_file
v verbose
The default is none.
–audit_logflush seconds
Specifies the interval in seconds that the pdosauditd daemon flushes the
audit records to the active audit log. The default is 5.
–audit_log_size bytes
Specifies the maximum size in bytes to which the active audit log can grow
before the pdosauditd daemon rolls over to use a new active audit log. The
default is 1000000.
–audit_permit_actions osseal_action_group osseal_action_bits
Specifies the [OSSEAL] action group followed by a list of the Tivoli Access
Manager for Operating Systems action bits to be audited. Valid action bits
are DKNRUdloprwxCGL. There is no default.
pdoscfg
282 Administration Guide
To audit actions defined with this option, the permit and loginpermit
global audit levels must be defined in the configuration file or explicitly set
with options of the pdosctl command for the current invocation of the
daemon.
–autostart on | off
Indicates whether to automatically start Tivoli Access Manager for
Operating Systems at system reboot. The default is on.
–branch policy_branch
Specifies the name of the initial policy branch to which this machine
subscribes. There is no default.
–certlife_interval days
Specifies the interval in days between the generation of certificate lifetime
audit records.
Note: To generate certificate lifetime audit records, certificate lifetime
health auditing must be enabled (the value for the –audit_health
option must include certlife). When not enabled, the value
specified for the –certlife_interval option is written to the
configuration file. After enabling certificate lifetime health auditing,
this saved value will be used.
v If the -certlife_threshold option is set to a nonzero value, the interval for
the generation of certificate lifetime audit records becomes daily when
the certificate threshold is reached.
v If the –certlife_interval option is set to zero, no certificate lifetime audit
records is generated until the certificate threshold is reached. After
reaching this threshold, the interval for the generation of certificate
lifetime audit records becomes daily.
v If both the –certlife_interval option and the -certlife_threshold option
are set to zero, no certificate lifetime audit records are generated.
The default is 7.
–certlife_threshold days
Specifies the threshold in days after which the generation of certificate
lifetime audit records and the generation of certificate lifetime warning
messages becomes daily.
Note: To generate certificate lifetime audit records and certificate lifetime
warning messages, certificate lifetime health auditing must be
enabled (the value for the –audit_health option must include
certlife). When not enabled, the value specified for the
–certlife_threshold option is written to the configuration file. After
enabling certificate lifetime health auditing, this saved value will be
used.
v If the value of the -certlife_threshold option is less than or equal to the
time before the certificate expires, certificate lifetime audit records are
generated and certificate expiration warning messages are written daily
to the daemon log file. After refreshing the certificate, the value specified
for the -certlife_interval option controls the interval at which certificate
lifetime audit records are generated.
v If the -certlife_threshold option is set to zero, certificate lifetime audit
records are generated according to the value specified for the
-certlife_interval option. Certificate expiration warning message are not
written to the daemon log file.
pdoscfg
Chapter 8. Commands 283
v If the both the -certlife_threshold option and the -certlife_interval
option are set to zero, no certificate lifetime audit records are generated.
The default is 30.
–cred_hold minutes
Specifies the maximum amount of time in minutes that a
non-administrator credential is cached without being accessed. This value
must be greater than or equal to the values of the –admin_cred_refresh
option and the –user_cred_refresh option. The default is 10080.
–cred_response_wait minutes
Specifies the minimum length of time in minutes to wait for a response to
a credential request before entering isolation mode. The default is 2.
–critical_cred_group group_name
Specifies the name of the Tivoli Access Manager group whose members are
to be treated as critical system users and whose credentials should always
be available in the credential cache. There is no default.
–critical_cred_refresh minutes
Specifies the refresh interval for the credentials of the critical system users
in minutes. These users are members of the group defined by the
–critical_cred_group option). The default is 720.
–delete options
Specifies a comma-separated list of options to remove from configuration
files. The following values are valid:
v admin_cred_refresh
v audit_level
v audit_log_entries
v audit_logflush
v audit_logs
v audit_log_size
v audit_deny_actions
v audit_permit_actions
v certlife_interval
v certlife_threshold
v cred_hold
v cred_response_wait
v critical_cred_group
v critical_cred_refresh
v dns
v ffdc_capture
v heartbeat_interval
v kmsg_hnd_threads
v pdosd_log_entries
v pdosd_logs
v pdoswdd_log_entries
v pdoswdd_logs
v refresh_interval
v tcb_ignore_ctime
v tcb_interval
v tcb_max_file_size
v tcb_monitor_threads
v tcb_nocrc_on_exec
v uid
v user_cred_refresh
v warning
pdoscfg
284 Administration Guide
–dns on | off
Indicates whether to enable Tivoli Access Manager for Operating Systems
to store the IP address to host name mapping information. The default is
on.
–ffdc_capture on | off
Indicates whether to enable the capture of first failure data upon abnormal
termination of the core Tivoli Access Manager for Operating Systems
daemons. The default is on.
–heartbeat_interval minutes
Specifies the interval in minutes between the generation of heartbeat audit
events.
Note: To generate heartbeat audit events, heartbeat auditing must be
enabled (the value for the –audit_health option must include
heartbeat). When not enabled, the value specified for the
–heartbeat_interval option is written to the configuration file. After
enabling heartbeat auditing, this saved value will be used.
The default is 10.
–help [option]
Displays help for all of the options. To display help for one option, use
–help option.
For example, to display help for the –kmsg_hnd_threads option, enter:
-help -kmsg_hnd_threads
–hostname host_name
Specifies the host name that will be used by the Tivoli Access Manager
server to recognize this machine. If not specified, the default is the local
host name returned by the operating system.
–kmsg_hnd_threads number_threads
Specifies the number of threads to be used to handle authorization
requests. This value must be a positive integer.
Increasing this value on multiprocessor systems with more than eight
processors can reduce the time that authorization requests take and can
improve performance. Specify a value equal to the number of processors in
the system or 8, whichever is greater. The maximum recommended
number of threads is 24.
The default is 8.
–ldap_ssl_cacert ldap_certificate_name
This option is deprecated and replaced with the –registry_ssl_cacert
option.
–local_domain management_domain
Specifies the Tivoli Access Manager secure domain into which the pdosd
daemon is to be configured. If this option is not specified, the local domain
defaults to the secure domain that the Tivoli Access Manager Runtime
configuration is using. If a domain was not specified when the Tivoli
Access Manager Runtime component was configured, its local domain
defaulted to the Default management domain.
The Tivoli Access Manager secure domain must exist and the administrator
name and password specified with the –admin_name and –admin_pwd
options must be valid for this domain.
pdoscfg
Chapter 8. Commands 285
–login_policy on | off
Indicates whether to enable system login and password restrictions.
After enabling login policy, any of the graphical login methods, such as
dtlogin, that are running must be restarted if login activity policy is to be
active for logins that use those methods. When the graphical login
program is restarted, the login activity policy is read and made active.
The default is on.
–lrd_admin_name admin_user_name
Specifies the Tivoli Access Manager administrator name to use when
registering the pdoslrd daemon with the Tivoli Access Manager policy
server.
–lrd_admin_pwd admin_user_password
Specifies the Tivoli Access Manager administrator password to use when
registering the pdoslrd daemon with the Tivoli Access Manager policy
server.
–lrd_cars_ssl_add label
Specifies the label of the CA certificate to add for the specified Common
Auditing and Reporting Service event server.
–lrd_cars_ssl_cacert ssl_cacert_name
Specifies the file name of the CA certificate of the Common Auditing and
Reporting Service event server that receives Tivoli Access Manager for
Operating Systems auditing events. This certificate is required for the
mutual authentication that occurs between Tivoli Access Manager for
Operating Systems and Common Auditing and Reporting Service event
server and for the encryption of audit records that are sent to the Common
Auditing and Reporting Service event server.
–lrd_cars_ssl_delete label
Specifies the label of the CA certificate to delete for the specified Common
Auditing and Reporting Service event server.
–lrd_cars_ssl_list
Displays the list of CA certificates for all defined Common Auditing and
Reporting Service event servers.
–lrd_cars_user_name_add cars_user_name
Specifies the user name to add for authenticating with Common Auditing
and Reporting Service event servers. This option, along with the
–lrd_cars_user_name_pwd, is required if the event server is configured to
authenticate with the client.
–lrd_cars_user_name_delete cars_user_name
Specifies the user name to delete. After being deleted, that user cannot be
used to authenticate with Common Auditing and Reporting Service event
servers.
–lrd_cars_user_name_list cars_user_name
Lists the user names that are associated with Common Auditing and
Reporting Service event servers and were configured using the
–lrd_cars_user_name_add option.
–lrd_cars_user_name_pwd cars_user_password
Specifies the password for the user that is used to authenticate with the
Common Auditing and Reporting Service event servers.
pdoscfg
286 Administration Guide
–lrd_config on | off
Indicates whether to configure or unconfigure the pdoslrd daemon. The
default is off.
–lrd_local_domain management_domain
Specifies the name of the Tivoli Access Manager secure domain that the
pdoslrd daemon will be configured to use. If the pdoslrd daemon will be
used to send audit data to a Tivoli Access Manager authorization server
(pdacld daemon) as a remote collection point, the pdoslrd daemon must be
configured into the same secure domain that the pdacld daemon is
configured to use. In an environment where the Tivoli Access Manager
policy server is managing multiple secure domains, this might mean that
the pdoslrd daemon needs to be configured into a different secure domain
than the pdosd daemon. If this option is not specified, the local domain
defaults to the secure domain that the pdosd configuration is using.
This Tivoli Access Manager secure domain must exist and the
administrator name and password specified with the –lrd_admin_name
and –lrd_admin_pwd options must be valid for this domain.
–net_ACL_limited on | off
Indicates whether network access decisions inherit ACLs that are attached
at or above the /OSSEAL/branch/NetIncoming and /OSSEAL/branch/NetOutgoing resource objects in the policy object space hierarchy. Limiting
ACL inheritance allows for improved performance of network access
decisions if there is no need to define policy at these junctions in the policy
object space. The default is off.
–operations
Lists the supported options in a condensed format.
–pdosauditd_log_entries number_log_entries
Specifies the number of log entries to write before archiving the pdosauditd
log file. If the values for the –pdosauditd_log_entries option and the
–pdosauditd_logs option are nonzero, the pdosauditd log file will be
archived when the number of entries reaches the number of entries
specified by the –pdosauditd_log_entries option or when the pdosauditd
daemon is restarted. If the value for the –pdosauditd_log_entries option is
nonzero and the value for the –pdosauditd_logs option is zero, the
pdosauditd log file will be recycled when the number of entries reaches the
number specified by the –pdosauditd_log_entries option or when the
pdosauditd daemon is restarted.
The default of 0 means that the number of entries to write is unlimited and
that the log file will not be archived.
–pdosauditd_logs number_logs
Specifies the number of archive log files to use before recycling the
pdosauditd archive log files. Setting the number of archive log files to a
nonzero value has an effect only if the value for the
–pdosauditd_log_entries option is nonzero. The pdosauditd log file will be
archived when the number of entries reaches the number of entries
specified by the –pdosauditd_log_entries option or when the pdosauditd
daemon is restarted.
The default of 0 means never archive the pdosauditd log file.
pdoscfg
Chapter 8. Commands 287
–pdosd_init_wait minutes
Specifies the maximum number of minutes to wait at startup for the
background pdosd daemon to complete initialization and enable policy
enforcement. The default is 5.
–pdosd_log_entries number_log_entries
Specifies the number of log entries to write before archiving the pdosd log
file. If the values for the –pdosd_log_entries option and the –pdosd_logs
option are nonzero, the pdosd log file will be archived when the number of
entries reaches the number of entries specified by the –pdosd_log_entries
option or when the pdosd daemon is restarted. If the value for the
–pdosd_log_entries option is nonzero and the value for the –pdosd_logs
option is zero, the pdosd log file will be recycled when the number of
entries reaches the number specified by the –pdosd_log_entries option or
when the pdosd daemon is restarted.
The default of 0 means that the number of entries to write is unlimited and
that the log file will not be archived.
–pdosd_logs number_logs
Specifies the number of archive log files to use before recycling the pdosd
archive log files. Setting the number of archive log files to a nonzero value
has an effect only if the value for the –pdosd_log_entries option is
nonzero. The pdosd log file will be archived when the number of entries
reaches the number of entries specified by the –pdosd_log_entries option
or when the pdosd daemon is restarted.
The default of 0 means never archive the pdosd log file.
–pdoslpmd_failure_audit_seconds seconds
Specifies the maximum amount of time in seconds for auditing login
failures. The default value is 10.
–pdoslpmd_log_entries number_log_entries
Specifies the number of log entries to write before archiving the pdoslpmd
log file. If the values for the –pdoslpmd_log_entries option and the
–pdoslpmd_logs option are nonzero, the pdoslpmd log file will be archived
when the number of entries reaches the number of entries specified by the
–pdoslpmd_log_entries option or when the pdoslpmd daemon is restarted.
If the value for the –pdoslpmd_log_entries option is nonzero and the
value for the –pdoslpmd_logs option is zero, the pdoslpmd log file will be
recycled when the number of entries reaches the number specified by the
–pdoslpmd_log_entries option or when the pdoslpmd daemon is restarted.
The default of 0 means that the number of entries to write is unlimited and
that the log file will not be archived.
–pdoslpmd_logs number_logs
Specifies the number of archive log files to use before recycling the
pdoslpmd archive log files. Setting the number of archive log files to a
nonzero value has an effect only if the value for the
–pdoslpmd_log_entries option is nonzero. The pdoslpmd log file will be
archived when the number of entries reaches the number of entries
specified by the –pdoslpmd_log_entries option or when the pdoslpmd
daemon is restarted.
The default of 0 means never archive the pdoslpmd log file.
–pdoslpmd_max_pending_logins number_logins
Specifies the maximum number of logins that can be in the authentication
process at the same time. The default value is 100.
pdoscfg
288 Administration Guide
–pdoslrd_log_entries number_log_entries
Specifies the number of log entries to write before archiving the pdoslrd
log file. If the values for the –pdoslrd_log_entries option and the
–pdoslrd_logs option are nonzero, the pdoslrd log file will be archived
when the number of entries reaches the number of entries specified by the
–pdoslrd_log_entries option or when the pdoslrd daemon is restarted. If
the value for the –pdoslrd_log_entries option is nonzero and the value for
the –pdoslrd_logs option is zero, the pdoslrd log file will be recycled when
the number of entries reaches the number specified by the
–pdoslrd_log_entries option or when the pdoslrd daemon is restarted.
The default of 0 means that the number of entries to write is unlimited and
that the log file will not be archived.
–pdoslrd_logs number_logs
Specifies the number of archive log files to use before recycling the pdoslrd
archive log files. Setting the number of archive log files to a nonzero value
has an effect only if the value for the –pdoslrd_log_entries option is
nonzero. The pdoslrd log file will be archived when the number of entries
reaches the number of entries specified by the –pdoslrd_log_entries option
or when the pdoslrd daemon is restarted.
The default of 0 means never archive the pdoslrd log file.
–pdoswdd_log_entries number_log_entries
Specifies the number of log entries to write before archiving the pdoswdd
log file. If the values for the –pdoswdd_log_entries option and the
–pdoswdd_logs option are nonzero, the pdoswdd log file will be archived
when the number of entries reaches the number of entries specified by the
–pdoswdd_log_entries option or when the pdoswdd daemon is restarted.
If the value for the –pdoswdd_log_entries option is nonzero and the value
for the –pdoswdd_logs option is zero, the pdoswdd log file will be recycled
when the number of entries reaches the number specified by the
–pdoswdd_log_entries option or when the pdoswdd daemon is restarted.
The default of 0 means that the number of entries to write is unlimited and
that the log file will not be archived.
–pdoswdd_logs number_logs
Specifies the number of archive log files to use before recycling the pdoswdd
archive log files. Setting the number of archive log files to a nonzero value
has an effect only if the value for the –pdoswdd_log_entries option is
nonzero. The pdoswdd log file will be archived when the number of entries
reaches the number of entries specified by the –pdoswdd_log_entries
option or when the pdoswdd daemon is restarted.
The default of 0 means never archive the pdoswdd log file.
–refresh_interval minutes
Specifies the interval in minutes that the Tivoli Access Manager policy
server is polled for policy database updates, if it has not received updates
during this interval. A value of zero indicates that policy database updates
are not received by polling. Compare with the –ssl_listening_port option.
The default is 0.
–registry_ssl_cacert ssl_certificate_name
Specifies the SSL certificate file of the Tivoli Access Manager user registry.
This certificate is required for the mutual authentication that occurs
between Tivoli Access Manager for Operating Systems and the Tivoli
Access Manager user registry server.
pdoscfg
Chapter 8. Commands 289
If the install_ldap_server program was used to install and configure IBM
Tivoli Directory Server and you chose to use the default SSL CA certificate
file that was provided by Tivoli Access Manager, you must obtain the
/etc/gsk/pd_ldapcert.arm file from the user registry server and use that
file during the configuration of Tivoli Access Manager for Operating
Systems.
–rspfile file_name
Specifies the name of file that contains option values for the configuration.
–ssl_listening_port port
Specifies the port to listen for policy database update notifications. A value
of zero indicates that policy database updates will not be received by
notification. Compare with the –refresh_interval option. The default is
7134.
–suffix suffix
Specifies the user registry suffix under which the Tivoli Access Manager
users and groups for Tivoli Access Manager for Operating Systems should
be created during configuration. An example suffix is
ou=austin,o=ibm,c=us. If the suffix contains spaces, enclose it in quotation
marks (″suffix″).
–tcb_ignore_ctime on | off
Indicates whether the ctime should be ignored when performing Trusted
Computing Base (TCB) signature comparisons. When enabled, a change in
ctime does not cause the TCB resource to become untrusted. The default is
off.
–tcb_interval seconds
Specifies the interval in seconds during which all TCB files are checked for
signature changes. The workload is distributed uniformly (approximately)
over this interval. The default is 1800.
–tcb_max_file_size megabytes
Specifies the maximum number of megabytes of a file that is considered
significant for calculating a checksum. The bytes checked are distributed
throughout the file. The default is 10.
–tcb_monitor_threads number_threads
Specifies the number of threads used to monitor TCB files for changes.
Setting this value above one is useful on multiprocessor machines only.
The value must be a positive integer. The default is 1.
–tcb_nocrc_on_exec on | off
Indicates whether to skip the CRC data checksum that normally occurs as
part of the authorization check that is associated with running an
executable file that is registered in the TCB. Enabling this option avoids
performing the CRC check on large binary files. The default is off.
–uid on | off
Indicates whether to enable caching of the UID/GID to user/group
name-mapping information. The default is off.
–usage
Displays command usage information.
–user_cred_refresh minutes
Specifies the refresh interval of user credentials in minutes. The default is
720.
pdoscfg
290 Administration Guide
–verbose
Displays verbose messages.
–version
Displays the version of the command.
–warning on | off
Indicates whether to enables global authorization warning mode. The
default is off.
Authorization
You must be a Tivoli Access Manager for Operating Systems administrator that has
privileges to create or modify groups and users to use this command.
Examples
1. To configure an Tivoli Access Manager for Operating Systems client to the
AServers policy branch from the command line, enter:
pdoscfg -admin_name sec_master -admin_pwd password \
-registry_ssl_cacert /tmp/ldapcacert.b64 -branch AServers \
-suffix o=tivoli
2. To configure an Tivoli Access Manager for Operating Systems client from the
/opt/pdos/etc/config.rsp response file and override the values for the –uid
and –audit_level options, enter:
pdoscfg -rspfile /opt/pdos/etc/config.rsp \
-uid off -audit_level all
pdoscfg
Chapter 8. Commands 291
pdoscollview
Views records in a collection file created by pdoslrd, the log router daemon.
Syntax
pdoscollview
[–l ]
[–g resource_ type]
[–z azn_resource_type]
[–w audit_view]
[–a action]
[–r reason]
[–o outcome]
[–n accessor_name]
[–c accessor_effective_name]
[–s start_time
[–e end_time
[–f output_file]
[–i audit_file]
[–F format]
[–M mapping_type]
[–R timestamp uniqifier]
[–H host_name]
[–D local_domain_name]
[–b collection_file_path]
[–d delimiter]
[–N]
[–O]
[–L filter_file_name]
[–I filter_name]
pdoscollview –h
pdoscollview –V
pdoscollview –?
Description
The pdoscollview command is used to process a collection file generated by the
pdacld daemon. The resulting output can be viewed, printed, or analyzed by
scripts and other programs.
Options
–? Displays the usage message.
–a action
Specifies the action on which to filter the output. The following values are
valid:
v add
v apply
v certLife
v change
v check_access
v delete
v disable
pdoscollview
292 Administration Guide
v enable
v heartbeat
v isolated
v login
v logout
v not_isolated
v register
v retrieve
v start
v stop
v trace
v trust
v unknown
v untrust
–b collection_file_path
Specifies the path name of the base collection file. Specifying this option
causes the command to process all the collection files in the directory that
are archived versions of the base file name. For example, if the base path
name is /x/y/audit_collect, and the directory /x/y contains the collection
files, audit_collect.2002-10-13-09:34:55, audit_collect.2002-10-14-10:55:03, and audit.collect, then the collection files will be processed in
the order listed here. They are processed in the order of increasing time
suffix, except that the base name (the file without a time suffix) is
processed last, because it is the most recent.
–c accessor_effective_name
Specifies the accessor effective name on which to filter the output.
–d delimiter
Specifies the field delimiter for concise and key-value formats. The
delimiter consists of one or more characters and replaces the default
delimiter, which is a comma. Note that some values might have to be
enclosed in quotation marks for the shell to accept them. For example, to
use a vertical bar (|) as a delimiter, specify –d "|".
–D local_domain_name
Specifies the name of the local domain. When specified, the output
contains only records with the specified domain name.
–e end_time
Specifies the end time on which to filter the output. You can specify this
option as a timestamp in the format of YYYY-MM-DD or YYYY-MM-DD-hh:mm:ss
(using a 24-hour clock) or by using the special qualifiers of today and now
to represent the current day and the current minute, respectively.
Optionally, when using the special qualifiers, an integer value, n, can be
used to specify the previous number of days (today-n) or to specify the
previous number of minutes (now-n). Only records logged before or at the
specified end time are provided in the output.
–f output_file
Specifies the fully qualified file to receive the ASCII output of the
command.
–F format
Specifies the formatting style of audit records. The following values are
valid:
v concise
v keyvalue
pdoscollview
Chapter 8. Commands 293
v verbose
The default is keyvalue unless the –l option is specified. If the –l option is
specified without the –F option, records are displayed in verbose format.
–g resource_type
Specifies the resource type on which to filter the output. The following
values are valid:
v azn
v cred
v daemon
v file
v health
v login
v logout
v netincoming
v netoutgoing
v password
v policy
v sudo
v surrogate
v tcb
v trace_exec
v trace_file
–h Displays the usage message.
–H host_name
Specifies that only records for audit events generated on the specified host
be provided in the output.
–i audit_ file
Specifies the path name of the audit file that is the input collection file to
be processed.
–I filter_name
Specifies the name of the filter definition to be used. The name of the file
containing the filter definition is given by the –L option. If the –L option is
not specified, the /opt/pdos/etc/pdoslrd.xml file is used. For an
explanation of the format of a filter definition, see the section on pdoslrd in
Chapter 4, “The log router daemon,” on page 121. The filter that is defined
by this option is another way to limit the output of the pdoscollview
command. The filter works in conjunction with the other options of this
command which limit output (such as –g, –z, –p, –w, –a).
–l Prints output to the screen.
–L filter_file_name
Specifies the file name of a filter file, that is, the file containing the filter
definition whose name is given by the –I option. The default is
/opt/pdos/etc/pdoslrd.xml, if it exists. If it does not exist, the user must
enter the –L option when the –I option is specified.
–M mapping_type
Specifies the mapping types on which to filter the output of audit fields.
The following values are valid:
v all
v event
v keyword
v outcome
pdoscollview
294 Administration Guide
v permission
v qualifier
v reason
v view
–n accessor_name
Specifies the accessor name on which to filter the output.
–N Indicates that the host name should be included in the output. When
specified, this option causes the host name of the machine that originally
generated the audit record to be included in the output of each audit
record. This is useful when the –H option is not specified, because a
collection file might contain audit records from multiple hosts.
–o outcome
Specifies the outcome on which to filter the output. The following values
are valid:
v failure
v success
–O Indicates that the output contains the local domain name for each audit
record. This option is useful when the –D option is not specified, because a
collection file might contain audit records from multiple domains.
–r reason
Specifies the reason on which to filter the output. The following values are
valid:
v global_audit
v global_warning
v resource_audit
v resource_warning
v user_audit
–R timestamp uniqifier
Selects a specific audit record given its timestamp using a 24-hour clock
(YYYY-MM-DD-hh:mm:ss) and its uniqifier.
–s start_time
Specifies the start time on which to filter the output. You can specify this
option as a timestamp in the format of YYYY-MM-DD or YYYY-MM-DD-hh:mm:ss
(using a 24-hour clock) or by using the special qualifiers of today and now
to represent the current day and the current minute, respectively.
Optionally, when using the special qualifiers, an integer value, n, can be
used to specify the previous number of days (today-n) or to specify the
previous number of minutes (now-n). Only records logged at or after the
specified start time are provided in the output.
–V Displays the version information.
–w audit_view
Specifies the audit view on which to filter the output. The following values
are valid:
v admin
v deny
v info
v permit
v trace
v warning
pdoscollview
Chapter 8. Commands 295
–z azn_resource_type
Specifies the authorization resource type on which to filter the output. The
following values are valid:
v file
v login
v netincoming
v netoutgoing
v sudo
v surrogate
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Examples
v To view records in the netout-tamos.log file that occur at or after 2:34:44 PM on
November 22, 2005 and display the output on the screen, enter:
pdoscollview -l -s 2005-11-22-14:34:44 -i netout-tamos.log
pdoscollview
296 Administration Guide
pdosctl
Sends control messages to selected Tivoli Access Manager for Operating Systems
daemons.
Syntax
pdosctl –k [daemon [–k daemon ...]]
pdosctl –s [daemon [–s daemon ...]] [–q]
pdosctl –w [on | off]
pdosctl –a [audit_level[:{on | off}] [–a audit_level[:{on | off}] ...]]
pdosctl –A [audit_level[:{on | off}] [–A audit_level[:{on | off}] ...]]
pdosctl –d [OSSEAL]osseal_action_bits
pdosctl –p [OSSEAL]osseal_action_bits
pdosctl –t [daemon[:trace_string] [–t daemon[:trace_string] ...]]
pdosctl –t trace_string
pdosctl –h
pdosctl –v
pdosctl –V
pdosctl –?
Description
The pdosctl command sends control messages to the specified daemons. The
pdosctl command is able to shut down an individual daemon, control audit views,
control warning mode, set debug trace levels, and display daemon status. This
command can control the following daemons:
v pdosd
v pdosauditd
v pdoswdd
v pdoslpmd
v pdoslrd
The –k option when specified with no arguments shuts down these five Tivoli
Access Manager for Operating Systems daemons. The –k option can also be used
to shut down individual daemons by following it with a daemon name. The –k
option can be specified multiple times on a single command line.
The –s option when specified with no arguments displays the status of each of
these five daemons. The –s option can also be used to display the status of
individual daemons by following it with a daemon name. The –s option can be
specified multiple times on a single command line.
pdosctl
Chapter 8. Commands 297
The –q option can be specified with the –s option. The –q option suppresses the
messages generated by the –s option and sets the return code to 0 on success and 1
if any of the queried daemons are down.
The –w option when specified with no arguments displays the global warning
mode for Tivoli Access Manager for Operating Systems. The –w option can also be
used to set the global warning mode by following it with either the keyword on or
off.
The –a and –A options, when specified with no arguments, display the current
global audit level of the daemons. You can also use the –a and –A options to
modify the current global audit level:
v The –A option resets the current global level to the specified value. If multiple
–A options are specified in a single command line, the global audit level is set to
all of the specified values.
v The –a option modifies the global audit level by resetting only the specified
audit level. You can specify multiple –a options on a single command line.
To reset or modify the global audit level, the –a and –A options are followed by an
audit level and the keyword on or off separated by a colon (:). If only the audit
level is specified without the keyword on or off, the value on is assumed. The
following values are valid for audit levels:
v admin
v all
v deny
v logindeny
v loginpermit
v info
v none
v permit
v trace_exec
v trace_exec_l
v trace_exec_root
v trace_file
v verbose
The –t option, when specified with no arguments, displays the current trace level
of each of the daemons. The –t option can be followed by a daemon name to
display the trace level for the specified daemon. The –t option can also be used to
set the trace level for a specified daemon. To set the trace level for a daemon, the
–t option must be followed by the daemon name, a colon (:), and then by the trace
string. The –t option is used only for Tivoli Access Manager for Operating Systems
support debugging purposes. The –t option can be specified multiple times on a
single command line. For more information about using the trace level, see the
IBM Tivoli Access Manager for Operating Systems: Problem Determination Guide.
Options
–? Displays the usage message.
–a [audit_levels]
Sends a control message to modify or display the global audit levels. The
following values are valid for audit levels:
v admin
v all
v deny
pdosctl
298 Administration Guide
v logindeny
v loginpermit
v info
v none
v permit
v trace_exec
v trace_exec_l
v trace_exec_root
v trace_file
v verbose
–A [audit_levels]
Sends a control message to set or display the global audit levels. The
following values are valid for audit levels:
v admin
v all
v deny
v logindeny
v loginpermit
v info
v none
v permit
v trace_exec
v trace_exec_l
v trace_exec_root
v trace_file
v verbose
–d [OSSEAL]osseal_action_bits
Sends a control message to set the action bits for which auditing is enabled
when decisions result in a deny.
To audit actions defined with this option, the deny and logindeny global
audit levels must be defined in the configuration file or explicitly set with
the pdosctl command with the –a or –A for the current invocation of the
daemon.
–h Displays the usage message.
–k [daemon]
Sends a control message to shut down all daemons or the specified
daemon. The following values are valid for daemons:
v pdosd
v pdosauditd
v pdoswdd
v pdoslpmd
v pdoslrd
–p [OSSEAL]osseal_action_bits
Sends a control message to set the action bits for which auditing is enabled
when decisions result in a permit.
To audit actions defined with this option, the permit and loginpermit
global audit levels must be defined in the configuration file or explicitly set
with the pdosctl command with the –a or –A for the current invocation of
the daemon.
–s [daemon]
Sends a control message to query the status of all daemons or the specified
daemon. The following values are valid for daemons:
pdosctl
Chapter 8. Commands 299
v pdosd
v pdosauditd
v pdoswdd
v pdoslpmd
v pdoslrd
–t trace_string
Sets the trace string for this command.
–t [daemon[:trace_string]]
Sends a control message to set or display the trace level of all daemons or
the specified daemon. The following values are valid for daemons:
v pdosd
v pdosauditd
v pdoswdd
v pdoslpmd
v pdoslrd
–v Displays verbose messages.
–V Displays the version information.
–w [on | off]
Sends a control message to display, turn on, or turn off the global warning
level.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
>=1 An error occurred.
Examples
The following are examples of pdosctl usage:
1. To shut down the Tivoli Access Manager for Operating Systems daemons,
enter:
pdosctl –k
2. To shut down the pdoswdd daemon, enter
pdosctl –k pdoswdd
3. To check the status of the Tivoli Access Manager for Operating Systems
daemons, enter:
pdosctl –s
4. To turn on global warning mode, enter:
pdosctl –w on
5. To query the global warning mode, enter:
pdosctl –w
6. To set the global audit level to grant and deny, enter:
pdosctl –A permit:on –A deny:on
7. To add the admin audit level to the global audit level, enter:
pdosctl –a admin:on
8. To query the global audit level, enter:
pdosctl
300 Administration Guide
pdosctl –a
9. To set the global deny actions to read and write permissions, enter:
pdosctl –d [OSSEAL] rw
pdosctl
Chapter 8. Commands 301
pdosdestroy
Destroys the Tivoli Access Manager for Operating Systems credentials for the
specified users.
Syntax
pdosdestroy [–v] [–t trace_string] [–u uid [ ...]] [–n name [ ...]]
pdosdestroy –h
pdosdestroy –V
pdosdestroy –?
Description
The pdosdestroy command removes the cached credentials for the specified users
from the Tivoli Access Manager for Operating Systems Credential Cache. If the –u
or –n options are not specified, the credentials of the invoking user are destroyed.
If the –u option is specified, the credentials for the user specified by the UID are
destroyed. If the –n option is specified, the credentials for the user specified by the
name will be destroyed.
If you specify the –u or –n options, you must be a Tivoli Access Manager for
Operating Systems runtime administrator. The –u and –n options can be specified
multiple times on the same command line and can be used together.
Options
–? Displays the usage message.
–h Displays the usage message.
–n name
Specifies the UNIX name of the user whose credential is to be destroyed.
–t trace_string
Sets the trace string for displaying trace messages.
–u uid Specifies the UID of the user whose credential is to be destroyed.
–v Displays verbose messages.
–V Displays the version information.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdosdestroy usage:
1. To destroy the credentials of the invoking user, enter:
pdosdestroy
2. To destroy the credentials of users anne and riley, whose UID is 300, enter:
pdosdestroy –n anne –u 300
pdosdestroy
302 Administration Guide
pdosent
Creates an entitlement report for a specified user or group.
Syntax
pdosent –g name [–v] [–a admin_name] [–p admin_password] [–d domain] [–r resource]
[–b branch_list] [–o out_file] [–t trace_string] [–x exclude_map]
pdosent –u name [–v] [–a admin_name] [–p admin_password] [–d domain] [–r resource]
[–b branch_list] [–o out_file] [–t trace_string] [–x exclude_map]
pdosent –h
pdosent –V
pdosent –?
Description
The pdosent command extracts protected object policy from a Tivoli Access
Manager policy server and formats it into two types of output. The data is
formatted into a plain text file and a file containing XML-formatted data. The
output files are placed in the current working directory with the names
pdosent.txt and pdosent.xml. The –o flag can be used to modify the names of the
output files.
If the –u option is specified, all user-specific information is displayed. If the user is
unauthenticated, the information displayed is limited and the user-related policy
will be that for an unauthenticated user. If the user is authenticated, the full user
information available from the Tivoli Access Manager user registry will be
displayed.
If the –g option is specified, all group-specific information available from the Tivoli
Access Manager user registry will be displayed and the group-related policy will
be displayed for that group name.
If the –r option is not specified, the following objects will be displayed for those
policy branches beginning at /OSSEAL/policy-branch where policy-branch is the
highest precedence policy branch:
v /OSSEAL/policy-branch/File
v /OSSEAL/policy-branch/RootDir
v /OSSEAL/policy-branch/Login/Terminal
v /OSSEAL/policy-branch/Login/Holiday
v /OSSEAL/policy-branch/NetIncoming
v /OSSEAL/policy-branch/NetOutgoing
v /OSSEAL/policy-branch/Sudo
v /OSSEAL/policy-branch/Surrogate
If the –r option is specified and the resource begins with a slash (/) character, then
the resource is considered to be an absolute object name. In this case, if the –b
option was specified, it will be ignored and any configured policy branches will
not be considered. Objects will be displayed beginning with the specified resource
name.
pdosent
Chapter 8. Commands 303
If the –r option is specified and the resource does not begin with a slash (/)
character, then the resource is considered to be a relative object name. If the –b
option is not specified, all objects under the configured Tivoli Access Manager for
Operating Systems policy branches will be displayed in precedence order
beginning relative to the specified resource. If the –b option was specified, all
objects under the policy branches specified by the –b option will be displayed in
precedence order beginning relative to the specified resource. Objects will be
displayed for those policy branches beginning at /OSSEAL/policy-branch/resource
where the policy-branch is the highest precedence policy branch. If the same
resource exists under more than one policy branch, only the highest precedence
object will be displayed.
Options
–? Displays the usage message.
–a admin_name
Specifies the Tivoli Access Manager administrator name. This defaults to
the admin_name specified in the Tivoli Access Manager for Operating
Systems configuration. If Tivoli Access Manager for Operating Systems is
not configured, the default is sec_master.
–b branch_list
Specifies a hierarchical list of policy branches.
–d domain
Specifies the Tivoli Access Manager secure domain. If Tivoli Access
Manager for Operating Systems is configured, this defaults to the domain
to which the Tivoli Access Manager runtime is configured.
–g name
Displays group entitlements for the specified group.
–h Displays the usage message.
–o out_file
Specifies the base name of the output files. If this option is not specified,
the base name of the output files will be ./pdosent.
–p admin_password
Specifies the Tivoli Access Manager administrator password.
–r resource
Specifies the resource starting point.
–t trace_string
Sets the trace string for displaying trace messages.
–u name
Displays user entitlements for the specified user.
–v Displays verbose messages.
–V Displays the version information.
–x exclude_map
Sets the exclusion bit mask that is used to exclude output fields from the
output.
Exit status
0 The command completed successfully.
pdosent
304 Administration Guide
1 An error occurred.
Examples
The following are examples of pdosent usage:
1. To get the entitlement report for the user bob, enter:
pdosent -a sec_master -p password -u bob
2. To get the entitlement report for the user bob on the /Management policy space,
enter:
pdosent -p password -u bob -r /Management
3. To get the entitlements report for the group admin on the file resource
/opt/pdos with a branch ordering of db2, unix, enter:
pdosent -p password -g admin -b db2,unix -r File/opt/pdos
pdosent
Chapter 8. Commands 305
pdosexempt
Disables Tivoli Access Manager for Operating Systems authorization decisions.
Note: This command disables Tivoli Access Manager for Operating Systems
authorization decisions. Remember to revoke the exemption with the
pdosrevoke command.
Syntax
pdosexempt [–v] [–t trace_string] [–i] [pid [pid ...]]
pdosexempt –h
pdosexempt –V
pdosexempt –?
Description
The pdosexempt command disables Tivoli Access Manager for Operating Systems
authorization decisions. When the pdosexempt command is invoked with no
arguments, all processes running under the OSSEAL privileged user (osseal) are
exempt from policy. In addition, any new processes running as the OSSEAL
privileged user (osseal) are also exempt from policy.
Note: The pdosexempt command only works for processes that Tivoli Access
Manager for Operating Systems is aware of. Tivoli Access Manager for
Operating Systems gains awareness when it sees a process start. Processes
that exist prior to the first start of Tivoli Access Manager for Operating
Systems on a system after a reboot cannot be exempted from authorization
policy by the pdosexempt command. Any such process must be restarted so
that Tivoli Access Manager for Operating Systems is aware of the process
before the pdosexempt command can be used to render that process exempt
from policy.
Strong protection should be provided to both the osseal account and the
pdosexempt command such as permitting access to it through only the following:
v Non-remote terminals
v A stronger authentication mechanism than simple password based
authentication
v Highly restrictive ACLs on pdosexempt
If a process ID (PID) or list of PIDs is specified on the pdosexempt command line,
the processes represented by those PIDs are immediately exempt from policy. The
list of PIDs must occur last on the pdosexempt command line.
The –i option can be specified in conjunction with the list of PIDs. If the –i option
is specified, any new children of the processes represented by the specified PIDs
inherit the policy exemption.
The pdosrevoke command is used to revoke the Tivoli Access Manager for
Operating Systems authorization exemption granted by the pdosexempt command.
pdosexempt
306 Administration Guide
Options
–? Displays the usage message.
–h Displays the usage message.
–i [pid [pid ...]]
Causes the specified PIDs to be immediately exempt from policy and for
new child processes of the specified PIDs to inherit the policy exemption.
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays verbose messages.
–V Displays the version information.
pid [pid ...]
Causes the specified PIDs to be immediately exempt from policy.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdosexempt usage:
1. To make all processes running under the OSSEAL privileged user exempt from
Tivoli Access Manager for Operating Systems authorization decisions, enter:
pdosexempt
The output is:
User osseal (uid 1444) is now exempt from policy
2. To make a specific process and its children exempt from Tivoli Access Manager
for Operating Systems authorization decisions, enter:
pdosexempt –i 9688
The output is:
Process 9688 and any future children are now exempt from policy
pdosexempt
Chapter 8. Commands 307
pdoshla
Manages host name lookaside database.
Syntax
pdoshla [–v] [–t trace_string] [–D database_path] –a IP_address [–T TTL_secs] [–H
host_name]
pdoshla [–v] [–t trace_string] [–D database_path] –f
pdoshla [–v] [–t trace_string] [–D database_path] –F
pdoshla [–v] [–t trace_string] [–D database_path] –r IP_address
pdoshla [–v] [–t trace_string] [–D database_path] –l entry_type
pdoshla [–v] [–t trace_string] [–D database_path] –u
pdoshla –h
pdoshla –V
pdoshla –?
Description
The pdoshla command manages the host name lookaside database. You can use
this command to add, remove, refresh, or view entries in the database. If you do
not specify the –D option, the default database in the /var/pdos/hla directory is
used. When adding and removing entries, specify the entries as IP addresses. IP
addresses can be either IP version 4 (IPv4) dotted notation or IP version 6 (IPv6)
text representation.
To add entries in the database, use the –a option. When adding entries, you can
use the –T option to specify the time-to-live for this entry and use the –H option to
specify the host name associated with this entry. Without the –T option, the added
entries uses the default value of 21600 seconds (6 hours). Without the –H option, a
DNS lookup is performed to determine the host name associated with the given IP
address.
To remove entries from the database, use one of the following options:
v Use the –r option to remove a specific entry
v Use the –f option to flush only stale entries
v Use the –F option to flush the entire database
To refresh entries in the database, use the –u option. To refresh entries, a DNS host
name lookup occurs for each entry in the database.
To view entries in the database, use the –l option with the type of entry to view.
You can view all entries, only stale entries, or only fresh entries.
Options
–? Displays the usage message.
pdoshla
308 Administration Guide
–a IP_address
Adds or replaces the specified entry in the database. IP address can be
IPv4 dotted notation or IPv6 text representation.
–D database_path
Specifies the path name of the database.
–f Specifies that stale entries should be flushed from the database.
–F Specifies that all entries should be flushed from the database.
–h Displays the usage message.
–H host_name
Specifies the host name.
–l entry_type
Lists database entries. The following values are valid:
v all
v stale
v fresh
–r IP_address
Removes the specified entry from the database. IP address can be IPv4
dotted notation or IPv6 text representation.
–t trace_string
Sets the trace string for displaying trace messages.
–T TTL_seconds
Specifies the time-to-live in seconds when creating a new database entry.
Default: 21600
–u Refresh all entries in the database.
–v Displays verbose messages.
–V Displays version information.
Authorization
To run this command, you must be a Tivoli Access Manager for Operating Systems
runtime administrator.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdoshla usage:
1. To add an entry to the default database for IP address 146.84.107.11, enter:
pdoshla –a 146.84.107.11
2. To view all of the entries in the default database, enter:
pdoshla –l all
The output is:
# Internet Address Hostname
9.41.3.101 carlb.austin.lab.tivoli.com
146.84.107.11 riley.tivoli.com
9.41.3.123 dfstest13.austin.lab.tivoli.com
pdoshla
Chapter 8. Commands 309
3. To view stale entries found in the default database, enter:
pdoshla –l stale
The output is:
# Internet Address Hostname
9.41.3.123 dfstest13.austin.lab.tivoli.com
4. To flush stale entries from the default database, enter:
pdoshla –f
5. To refresh all entries found in the default database, enter:
pdoshla –u
pdoshla
310 Administration Guide
pdoslpinf
Displays information about a user password expiration and grace logins.
Syntax
pdoslpinf [–v] [–t trace_string] –p [–s]
pdoslpinf [–v] [–t trace_string] –r [–s]
pdoslpinf [–v] [–t trace_string] –g
pdoslpinf –h
pdoslpinf –V
pdoslpinf –?
Description
The pdoslpinf command displays information about password expiration and
grace logins for the invoking user. If no options are specified, the output states the
number of days within which the password will expire. If the password has
expired, the output includes the number of remaining grace logins. Unless the
invocation contains the –v option, the output shows data unaccompanied by text.
Options
–? Displays the usage message.
–g Displays the number of remaining grace logins.
–h Displays the usage message.
–p Displays the password expiration. The password expiration date is
displayed in the current locale. When used in combination with the –s
option, the output shows the password expiration as the number of
seconds after the UNIX epoch. If the password is not configured to expire,
the output shows 0.
–r Displays the time within which the password will expire. If the password
will expire in less than 24 hours, the output shows the number of days as
1. If the password has expired, the output shows a negative number that
represents the number of days that has passed since the expiration date. If
the password is not configured to expire, the output shows 0. When used
in combination with the –s option, the output shows the remaining time in
number of seconds instead of days.
–s Displays output values in seconds. This option can be specified with the –p
or –r options
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays the verbose messages, when available.
–V Displays version information.
Exit status
0 The command completed successfully.
pdoslpinf
Chapter 8. Commands 311
1 An error occurred.
Examples
The following are examples of pdoslpinf usage:
1. To display a message that states the number of days until password expiration
and the number of grace logins remaining if the password has expired, enter:
pdoslpinf
2. To display the password expiration date in the current locale, enter:
pdoslpinf -p
3. To display the password expiration date as a number of seconds since the
UNIX epoch, enter:
pdoslpinf -p -s
4. To display the number of days remaining before the password expires, enter:
pdoslpinf -r
5. To display the number of seconds remaining before the password expires, enter:
pdoslpinf -r -s
6. To display the number of grace logins remaining, enter:
pdoslpinf -g
7. To display a verbose message for the number of grace logins remaining, enter:
pdoslpinf -g -v
pdoslpinf
312 Administration Guide
pdoslpadm
Perform administrative commands pertaining to the Tivoli Access Manager for
Operating Systems Login Activity Database.
Syntax
pdoslpadm –c on [–n client | server]
pdoslpadm –c off [–n client | server]
pdoslpadm [–q] –l user [user ... ]
pdoslpadm [–q] –m user [date]
pdoslpadm –p [user] ...
pdoslpadm –P [user] ...
pdoslpadm –r [–f] [–d] [user ... ]
pdoslpadm –r [–f] [–e] [user ... ]
pdoslpadm [–q] –u [–z] user ...
pdoslpadm [–q] –x user
pdoslpadm –h
pdoslpadm –V
pdoslpadm –?
Description
The pdoslpadm command aids in the administration of Login Activity and
Password Policy that is local to a native UNIX system. After login policy is
configured in Tivoli Access Manager for Operating Systems, login and password
policy records are recorded for each user. Records are generated for each
individual user account as each user logs into each system.
Use the –r option to generate a report detailing the status of the native UNIX user
accounts that are recorded in the Login Activity Database. If one or more users is
specified with the –r option, only the specified accounts are included in the report.
If no user is specified with the –r option, all user accounts are included in the
report. With the –r option, you can use the following options:
v Use the –e option to generate a report of only those user accounts that are
enabled (unlocked).
v Use the –d option to generate a report of only those user accounts that are
disabled (locked).
v Use the –f option to generate a full, detailed report.
Note: The rhost name field displayed when using the –r and –f options might
appear truncated. This is caused by the way the native login application
stored the host information and has no effect on policy enforcement.
pdoslpadm
Chapter 8. Commands 313
Use the –m option to modify the time of the Password Change Date recorded in
the Login Activity Database for the specified user. If no password change date is
specified, the current time minus the number of days specified in the
MinPasswordDays attribute of the Password Policy is used. For example, if the
specified number of days is five, the value of –m is five days prior to the current
time. If a password change date is specified, it must be in the following format:
MMDDhhmm[[CC]YY]
where:
MM Indicates the month in the year (01 – 12).
DD Indicates the day in the month (01 – 31).
hh Indicates the hour in the day using a 24-hour clock (00 – 23).
mm Indicates the minute in the hour (00 – 59).
CC Indicates the century, either 20 or 21. Optional, defaults to the current
century.
YY Indicates the year (00 – 99). Optional, defaults to the current year.
The –m option is intended primarily for the support of policy that relies on the
password change date, such as grace logins and minimum and maximum
password age, on systems where password change dates for users are not
provided. This situation occurs in environments with distributed user registries,
such as NIS, that do not return the password change date with the POSIX APIs.
This situation also occurs on HP-UX systems that are not configured to be trusted
secure systems.
When the password change date is set in a user record using the –m option, the
date stored in the user record is used until the password is reset, even if the
change date is available in local system files. After the password is reset (using
passwd) the password change date in the record that is stored in the Login
Activity Database is used only if the native UNIX password change date cannot be
retrieved.
When the pdoslpadm command generates a report, the password change date that
is currently in effect is displayed. If the date is the value stored in the Login
Activity Database, a string is displayed to indicate this. If no date is specified in
the user account record from the Tivoli Access Manager for Operating Systems
Login Activity Database and no value is found in the system files, a string is
displayed that indicates that there is no valid password change data available.
Use the –c option to enable or disable configuration of Login Activity Policy on the
local UNIX system. The optional –n option specifies whether the configuration
change is occurring on an NIS server or on an NIS client.
The –c option, used in conjunction with the –n option, allows you to configure NIS
support of password change dates in a Tivoli Access Manager for Operating
Systems environment without having to manually specify password change dates
for users using the –m option. To accomplish this, you must enable the support on
the NIS server and on all NIS clients with Tivoli Access Manager for Operating
Systems and Login Activity Policy enabled.
Use the –p option to display the login policy. If no users are specified, the default
policy is displayed. If one or more users is specified, the policy associated with
pdoslpadm
314 Administration Guide
each user is displayed. If there is no policy for a specified user, this is indicated
and the default policy that is in effect for the user is displayed.
Use the –P option to display the password policy. If no users are specified, the
default policy is displayed. If one or more users is specified, the policy associated
with each user is displayed. If there is no policy for a specified user, this is
indicated and the default policy that is in effect for the user is displayed.
Use the –x option to delete the record for a user from the Login Activity Database.
Use the –l option to lock (disable) one or more native UNIX user accounts. Locking
a user account prevents the user from logging into the system.
Use the –u option to unlock (enable) one or more native UNIX user accounts.
Unlocking a locked account allows the user to log in to the system, changing any
appropriate state for the user. Specify the –z option along with the –u option to
zero all fields in the Login Activity Database record for the specified user account;
for example, the number of failed logins.
Options
–? Displays the usage message.
–c on | off
Enable (on) or disable (off) specialized configuration for Login Activity
Policy.
–d Specifies a report of only locked (disabled) user accounts.
–e Specifies a report of only unlocked (enabled) user accounts.
–f Specifies a full, detailed report.
–h Displays the usage message.
–l Locks the specified user accounts.
–m user [date]
Modifies the password change date for a user account. If no date is
entered, the value used is the current date minus the number of days
specified in the MinPasswordDays attribute of the password policy. This
value must be specified in the following format:
MMDDhhmm[[CC]YY]
–n client | server
Used with the –c option to indicate whether the configuration change
specified applies to an NIS server (server) or to an NIS client (client).
–p Displays the login activity policy for a specific user exception, or displays
the default if no user-specific policy.
–P Displays the password policy for a specific user exception, or displays the
default if no user-specific policy.
–q Runs in silent mode. Returns only the exit status.
–r Reports the state of user accounts
–u Unlocks the specified user accounts.
–V Displays the version information.
–x Deletes a user record from the database.
pdoslpadm
Chapter 8. Commands 315
–z Clears (zeroes) all fields in the database when unlocking the user account.
user Specifies the user for the requested operation.
Exit status
<0 An error occurred.
>=0 The number of records processed.
Examples
The following are examples of pdoslpadm use:
1. To generate a report of all users in the Tivoli Access Manager for Operating
Systems Login Activity Database, enter:
pdoslpadm –r
The output is:
User(uid) State<:time locked>
-------------------------------
root(0) Unlocked
anne(202) Unlocked
riley(204) Unlocked
2. To lock the anne user account, enter:
pdoslpadm –l anne
3. To generate a report of all users in the Login Activity Database whose accounts
are locked, enter:
pdoslpadm –r –d
The output is:
User(uid) State<:time locked>
-------------------------------
anne(202) Locked(administrator): Tue Mar 27 14:38:58 CST 2001
4. To unlock the anne user account, enter:
pdoslpadm –u anne
5. To display the login policy for the root user, enter:
pdoslpadm –p root
The output is as follows:
Policy for root is:
MinPasswordDays = 0
MaxPasswordDays = 0
MaxInactiveDays = 0
MaxFailedLogins = 5
MaxGraceLogins = 3
LoginMinutes = 0
LockMinutes = 0
MaxConcurrent = 5
PolicyDisabled = 0
6. To display the password policy for the root user, enter:
pdoslpadm –P root
The output is as follows:
Policy for root is:
MinPasswordLen = 6
MaxPasswordAlpha = 0
MaxPasswordAlphaNum = 0
MaxPasswordNumeric = 1
pdoslpadm
316 Administration Guide
MinPasswordLower = 0
MinPasswordUpper = 0
MinPasswordSpecial = 0
MaxPasswordRepeat = 0
PasswordNameCheck = 0
PasswordHistory = 5
PasswordOldPwdCheck = 1
PasswordMaxConsPrev = 0
PasswordNonNumFirstLast = 0
MinPasswordDays = 0
7. To delete a record for user anne from the Login Activity Database, enter:
pdoslpadm –x anne
pdoslpadm
Chapter 8. Commands 317
pdoslradm
Controls the log router daemon and channels in the log router configuration file.
Syntax
pdoslradm –c channel_name –S option=value
pdoslradm –c channel_name –D option
pdoslradm –c channel_name –d
pdoslradm –d
pdoslradm –b
pdoslradm –R
pdoslradm –h
pdoslradm –V
pdoslradm –?
Options
–? Displays the usage message.
–b Makes pdoslrd perform batch processing, if an active router element has
the batch_mode option turned on. The pdoslrd daemon processes all of the
audit records in the audit log that have not been processed at the time that
the pdoslradm command is issued. Any new audit records that are
generated during batch processing will not be processed until the next time
the pdoslradm command is issued with the –b option. The pdoslradm
command can be issued manually or through a cron job. The cron facility
provides a great deal of flexibility in specifying periodic invocations of a
command.
After batch processing, the audit logs are deleted. Sometimes, however,
some of the audit logs in the /var/pdos/audit directory are not deleted.
–c channel_name
Specifies the name of the channel.
–d Displays the channels in the pdoslrd.xml file and their current options. If
specified with the –c option, displays only that channel.
–D option
Deletes the option.
–h Displays the usage message.
–R Makes pdoslrd reread the control file and make all adjustments accordingly
(for example, turn channels on or off; start new channels).
–S option=value
Sets the value of the option. If the option does not exist, it will be added.
–V Displays the version information.
pdoslradm
318 Administration Guide
pdosobjsig
Manages the Tivoli Access Manager for Operating Systems object signature
database.
Syntax
pdosobjsig [–v] [–t trace_string] [–D database_path] –g object_name
pdosobjsig [–v] [–t trace_string] [–D database_path] [–n] –l {all | trusted |
untrusted}
pdosobjsig [–v] [–t trace_string] [–D database_path] –c object_name
pdosobjsig [–v] [–t trace_string] [–D database_path] –C
pdosobjsig [–v] [–t trace_string] [–D database_path] –u object_name –s {trusted |
untrusted}
pdosobjsig [–v] [–t trace_string] [–D database_path] –S {trusted | untrusted}
pdosobjsig –h
pdosobjsig –V
pdosobjsig –?
Description
The pdosobjsig command manages the object signature database. You can use this
command to display, modify, and check the state of objects in the database. If you
do not specify the –D option, the default database in the /var/pdos/tcb directory
is used.
To view objects in the database, use the –g option or the –l option.
v Use the –g option to display state information for a specific object.
v Use the –l option to list all objects found in the database, to list only trusted
objects, or to list only untrusted objects. By default, using this invocation
produces a detailed list of objects. To list only object names, use the –n in
combination with the –l option. If any element of an object is configured for
exclusion from TCB checks, the output associated with these objects includes a
marker to show that they are ignored.
To check the state of objects in the database, use the –c option or the –C option.
Using these options verify that the signature for an object has not changed. If a
change is detected, the object is marked untrusted.
v The –c option can be used to check the signature of a specific object.
v The –C option can be used to check the signature of all objects in the database.
To change the state of objects in the database, use the –u in combination with the
–s option or use the –S option.
v The –u option in combination with the –s can be used to set the state of a
specific object to trusted or untrusted.
v The –S option can be used to set the state of all objects to trusted or untrusted.
pdosobjsig
Chapter 8. Commands 319
Note: You cannot set the state of the pdosobjsig command to untrusted.
Options
–? Displays the usage message.
–c object_name
Checks the state of the specified object.
–C Checks the state information for all objects.
–D database_path
Specifies the path of the database.
–g object_name
Displays the state information for the specified object.
–h Displays the usage message.
–l all | trusted | untrusted
Provides a detailed listing of all objects in the database or objects in the
database with the specified qualifier.
–n List only the names of the objects in the database. This option can be used
only in conjunction with the –l option.
–s trusted | untrusted
Updates the state of an object in the database with the specified qualifier.
–S trusted | untrusted
Updates the state of all objects in the database with the specified qualifier.
–t trace_string
Sets the trace string for displaying trace messages.
–u object_name
Specifies the name of the object to update in the database.
–v Displays verbose messages.
–V Displays the version information.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdosobjsig usage:
1. To change the state of the object /anne/usertest in the default database to
untrusted, enter:
pdosobjsig –u /anne/usertest –s untrusted
2. To display detailed information about all untrusted objects found in the default
database, enter:
pdosobjsig –l untrusted
pdosobjsig
320 Administration Guide
Assuming that /anne/usertest is the only untrusted object and no elements are
configured for exclusion in TCB checks as indicated by the Ignore token after
the attribute value, the output is:
Object Name : /anne/usertest
CRC sum : 279204844
Inode 289 on device 10/5
Permissions : rwxr-xr-x
Owner : 0 : root
Group : 0 :
system Size : 6446
Last status update time : Fri Sep 15 11:04:12 2000
Last modification time : Fri Sep 15 11:04:12 2000
State : Untrusted
Reason : The Administrator changed the state explicitly
Last state transition time: Wed Oct 25 16:07:28 2000
Assuming that /anne/usertest is the only untrusted object and various
elements are configured for exclusion in TCB checks as indicated by the Ignore
token after the attribute value, the output is:
Object Name : /anne/usertest
CRC sum : 279204844 (Ignored on execution)
Inode 289 on device 10/5 (Ignored)
Permissions : rwxr-xr-x
Owner : 0 : root
Group : 0 :
system Size : 6446 (Ignored)
Last status update time : Fri Sep 15 11:04:12 2000
Last modification time : Fri Sep 15 11:04:12 2000 (Ignored)
State : Untrusted
Reason : The Administrator changed the state explicitly
Last state transition time: Wed Oct 25 16:07:28 2000
3. To reset the state of object /anne/usertest to trusted, enter:
pdosobjsig –u /anne/usertest –s trusted
4. To set the state of all objects in the default database to trusted, enter:
pdosobjsig –S trusted
5. To view the state information for object /anne/usertest, enter:
pdosobjsig –g /anne/usertest
The output is:
Object Name : /anne/usertest
State : Trusted
Reason : The Administrator changed the state explicitly
Last state transition time: Wed Oct 25 16:16:45 2000
pdosobjsig
Chapter 8. Commands 321
pdosrefresh
Refreshes the Tivoli Access Manager for Operating Systems credentials for the
invoking user, specified users, or all currently cached users.
Syntax
pdosrefresh [–v] [–t trace_string] [–u uid] [–u uid ...] [–n name] [–n name ...]
pdosrefresh [–v] [–t trace_string] [–C]
pdosrefresh –h
pdosrefresh –V
pdosrefresh –?
Description
The pdosrefresh command refreshes the cached Tivoli Access Manager for
Operating Systems credentials for the invoking user, specified users, or the entire
cache.
If the –u, –n, or –C options are not specified, the credentials of the invoking user
are refreshed. If the –u option is specified, the credentials for the user specified by
the UID will be refreshed. If the –n option is specified, the credentials for the user
specified by the name will be refreshed. The –u and –n options can be specified
multiple times on the same command line and can be used together. They cannot
be used with the –C option.
If the –C option is specified, all of the currently cached credentials will be
refreshed.
Options
–? Displays the usage message.
–C Refreshes all the cached credentials.
–h Displays the usage message.
–n name
Specifies the UNIX name of the user whose credential is to be refreshed.
–t trace_string
Sets the trace string for displaying trace messages.
–u uid
Specifies the UID of the user whose credential is to be refreshed.
–v Displays verbose messages.
–V Displays the version information.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use the –u, –n, or –C options of the pdosrefresh command.
pdosrefresh
322 Administration Guide
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdosrefresh usage:
1. To refresh the credentials of the invoking user, enter:
pdosrefresh
2. To refresh the credentials of users anne and riley, whose UID is 300, enter:
pdosrefresh –n anne –u 300
3. To refresh all of the credentials in the cache, enter:
pdosrefresh –C
pdosrefresh
Chapter 8. Commands 323
pdosrespolicy
Displays the protected object name and applied policy for a specified File,
NetIncoming, or NetOutgoing resource.
Syntax
pdosrespolicy –f resource [ –v] [–D] [–a admin_name] [–p admin_password] [–d
domain] [–b branch_list] [–t trace_string] [–x exclude_map]
pdosrespolicy –i resource [ –v] [–D] [–a admin_name] [–p admin_password] [–d
domain] [–b branch_list] [–t trace_string] [–x exclude_map]
pdosrespolicy –o resource [ –v] [–D] [–a admin_name] [–p admin_password] [–d
domain] [–b branch_list] [–t trace_string] [–x exclude_map]
pdosrespolicy –h
pdosrespolicy –V
pdosrespolicy –?
Description
The pdosrespolicy command extracts protected object policy from a Tivoli Access
Manager policy server and finds the matching policy object for a given resource
name. The command allows querying for a File resource, a NetIncoming resource,
or a NetOutgoing resource.
Options
–? Displays the usage message.
–a admin_name
Specifies the Tivoli Access Manager administrator name. This defaults to
the admin_name specified in the Tivoli Access Manager for Operating
Systems configuration. If Tivoli Access Manager for Operating Systems is
not configured, the default is sec_master.
–b branch_list
Specifies a hierarchical list of policy branches.
–d domain
Specifies the Tivoli Access Manager secure domain. If Tivoli Access
Manager for Operating Systems is configured, this defaults to the domain
to which the Tivoli Access Manager runtime is configured.
–D Shows duplicate policy entries.
–f Indicates that the specified resource is a File resource.
–h Displays the usage message.
–i Indicates that the specified resource is a NetIncoming resource.
–o Indicates that the specified resource is a NetOutgoing resource.
–p admin_password
Specifies the Tivoli Access Manager administrator password.
–t trace_setting
Sets the trace string for displaying trace messages.
pdosrespolicy
324 Administration Guide
–v Displays verbose messages.
–V Displays the version information.
–x exclude_map
Sets the exclusion bit mask that is used to exclude output fields from the
output.
resource
Specifies resource associated the –f, –i, or –o option. For the –f option,
specifies the name of the file. For the –i and –o options, specifies the
network resource as a host-service pair.
For network resources, you can specify the host by either its host name or
its IP address, and you can specify the service as either its service name
(such as, telnet, ftp) or its service port (23, 21). When specifying an IP
address in IPv6 format, enclose the IP address in square brackets.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdosrespolicy usage:
1. To display the applicable policy for a file named /usr/bin/foo, enter:
pdosrespolicy -a sec_master -p password -f /usr/bin/foo
2. To display the applicable policy for a network incoming operation from host
test.ibm.com on port 23, enter:
pdosrespolicy -a research_admin -p password -i test.ibm.com/23
3. To display the applicable policy for a network outgoing operation to host
test.ibm.com on port 21, enter:
pdosrespolicy -a research_admin -p password -o test.ibm.com/21:
4. To display the applicable policy for a network outgoing operation to host
1080::8:800:200C:417A, including duplicates, on the telnet port, enter:
pdosrespolicy -D -o [1080::8:800:200C:417A]/telnet
pdosrespolicy
Chapter 8. Commands 325
pdosrevoke
Revokes an exemption from Tivoli Access Manager for Operating Systems
authorization decisions.
Syntax
pdosrevoke [–v] [–t trace_string] [pid [pid ...]]
pdosrevoke –h
pdosrevoke –V
pdosrevoke –?
Description
The pdosrevoke command revokes an exemption from Tivoli Access Manager for
Operating Systems authorization decisions that was previously granted by the
pdosexempt command.
When the pdosrevoke command is invoked with no arguments, all processes
running under the OSSEAL privileged user (osseal) lose their exemption from
policy. This does not affect processes explicitly made immune by the pdosexempt
command invoked with PID parameters.
If a PID or list of PIDs is specified on the pdosrevoke command line, the processes
represented by those PIDs immediately lose their exemption from policy. The list
of PIDs must occur last on the pdosrevoke command line.
There is no equivalent of the pdosexempt command with the –i flag. All exempt
processes must have their privilege explicitly revoked.
Options
–? Displays the usage message.
–h Displays the usage message.
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays verbose messages.
–V Displays the version information.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdosrevoke usage:
pdosrevoke
326 Administration Guide
1. To revoke the exemption granted to the osseal privileged user by the
pdosexempt command, enter:
pdosrevoke
The output is:
User osseal (uid 1444) is no longer exempt from policy
The UID might be different in your system.
2. To revoke the exemption granted by the pdosexempt command to the PID
9688, enter:
pdosrevoke 9688
The output is:
Process 9688 is no longer exempt from policy
pdosrevoke
Chapter 8. Commands 327
pdosrgyimp
Imports UNIX users and groups into the Tivoli Access Manager user registry.
Syntax
pdosrgyimp –u [–d] [–i] [–n] [–r] [–v] [–G default_group] –S suffix [–P password] [–L
log_directory] [–E exclude_file] [–I include_file] –l admin_name –p admin_password [–D
domain] [–R AD_domain]
pdosrgyimp –g [–d] [–i] [–n] [–r] [–v] [–G default_group] –S suffix [–P password] [–L
log_directory] [–E exclude_file] [–I include_file] –l admin_name –p admin_password [–D
domain] [–R AD_domain]
pdosrgyimp –a [–d] [–i] [–n] [–r] [–v] [–G default_group] –S suffix [–P password] [–L
log_directory] [–E exclude_file] [–I include_file] –l admin_name –p admin_password [–D
domain] [–R AD_domain]
pdosrgyimp –h
pdosrgyimp –V
pdosrgyimp –?
Description
The pdosrgyimp command imports UNIX users and groups from the UNIX
registry into the Tivoli Access Manager user registry. All Tivoli Access Manager
user accounts are set to valid by default. However, the –d option disables or
invalidates the accounts. The password for each Tivoli Access Manager user
account is set to invalid when it is created.
Command line options control which portions of the UNIX registry are to be
imported. The –u, –g and –a options control whether users are imported (–u),
groups are imported (–g), or both users and groups are imported (–a). The default
is to import both users and groups.
The –I option restricts the import to a specific set of users and groups found in the
UNIX registry.
The –E option eliminates a specific set of users and groups found in the UNIX
registry.
If an attempt is made to create a Tivoli Access Manager user registry entry for a
user that already exists, that user is excluded from the rest of the import. Any
excluded users are not included when populating group memberships. If an
attempt is made to create a Tivoli Access Manager user registry entry for a group
that already exists, the existing group is not populated with entries corresponding
to the UNIX group membership. Use the –r flag to change this behavior.
As a part of importing UNIX groups into the Tivoli Access Manager user registry,
the Tivoli Access Manager group is populated with Tivoli Access Manager users,
who are members of the UNIX group, which were not excluded either via
command line options or a conflict. Use caution when importing groups separately
from users.
pdosrgyimp
328 Administration Guide
The –R option is required only when Tivoli Access Manager is configured to
multiple Active Directory domains and Tivoli Access Manager for Operating
Systems is not configured. If the –R option is not specified when Tivoli Access
Manager for Operating Systems is configured and when Tivoli Access Manager is
configured to multiple Active Directory domains, the Active Directory domain
name from the osseal.conf configuration file is used. However if Tivoli Access
Manager is not configured to multiple Active Directory domains, the –R option is
not valid.
The –S option is required on all imports. This option specifies an existing Tivoli
Access Manager user registry suffix that will be used in the distinguished name
(dn) for each user and group. Tivoli Access Manager users and groups are created
using the following mapping:
user name
UNIX_user_name[@AD_domain]
user cn
UNIX_user_name
user sn
UNIX_user_name
user dn
cn=pdos user UNIX_user_name, suffix
group name
UNIX_group_name[@AD_domain]
group cn
UNIX_group_name
group dn
cn=pdos group UNIX_group_name, suffix
The pdosrgyimp command produces two files in the current working directory
named pdosrgyimp.import and pdosrgyimp.conflict. A record is written to the
pdosrgyimp.import file for each user and group that is created in the Tivoli Access
Manager user registry. If an attempt is made to create a user or group that already
exists in the Tivoli Access Manager user registry, a record of that conflict will be
written to the pdosrgyimp.conflict file.
These two files are written in the format of commands that can be sent to the
pdadmin utility with comment lines detailing the actions. The
pdosrgyimp.conflict file has a comment line explaining the failure followed by the
pdadmin utility that generated the conflict. For example:
# create user failed
#
user create "test1" "cn=pdos user test1,ou=tivoli,o=ibm" "test1" "test1" "s12t"
An example taken from a pdosrgyimp.import file is:
# create user
#
user create "riley" "cn=pdos user riley,ou=tivoli,o=ibm" "riley" \
"riley" "3AD4l00u"
user modify "riley" password-valid no
user modify "riley" account-valid yes
#
# create user
#
user create "maggie" "cn=pdos user maggie,ou=tivoli,o=ibm" "maggie" \
pdosrgyimp
Chapter 8. Commands 329
"maggie" "34pkjTaU"
user modify "maggie" password-valid no
user modify "maggie" account-valid yes
#
# create group
#
group create "canine" "cn=pdos group canine,ou=tivoli,o=ibm" "canine"
group modify "canine" add "riley"
group modify "canine" add "maggie"
The –n or no action option generates a list of pdadmin style commands that would
be executed had the –n option not been specified.
Options
–? Displays the usage message.
–a Specifies that UNIX users and groups should be imported.
–d Disable all newly created Tivoli Access Manager user accounts.
–D domain
Specifies the Tivoli Access Manager domain to which all users and groups
are imported. If this option is not specified, the domain to which Tivoli
Access Manager for Operating Systems is configured will be used; if Tivoli
Access Manager for Operating Systems is not configured, the domain to
which Tivoli Access Manager is configured will be used.
–E exclude_file
Specifies a filename containing a list of UNIX users and groups to exclude
from the import. The format of entries in the file follows:
# Comment characters
USER UNIX_user_name
USER UNIX_user_name
GROUP UNIX_user_name
GROUP UNIX_user_name ...
–g Specifies that only UNIX groups should be imported.
–G default_group
Specifies the name of a Tivoli Access Manager group of which all newly
imported users will be members. If this group does not exist, it is created.
–h Displays the usage message.
–i Specifies that when importing UNIX users and groups, if a matching user
registry entry exists, and that entry is not already a Tivoli Access Manager
user or group entry, the entry should be imported from the user registry.
–I include_file
Specifies a filename containing a list of UNIX users and groups to include
in the import. User and groups that are not in this list are not imported.
The format of entries in the file follows:
# Comment characters
USER UNIX_user_name
USER UNIX_user_name
GROUP UNIX_user_name
GROUP UNIX_user_name ...
–l admin_name
Specifies the Tivoli Access Manager administrator login ID to authenticate
as. This user must be a member of the iv-admin group.
pdosrgyimp
330 Administration Guide
–L log_directory
Specifies the directory in which to create the pdosrgyimp.import and the
pdosrgyimp.conflict logs.
–n Specifies that no action should be taken. A list of pdadmin commands is
generated.
–p admin_password
Specifies the password of the Tivoli Access Manager administrator login
ID. If not specified, you are prompted for the password.
–P password
Specifies a default password to be used for all Tivoli Access Manager user
accounts that are created by this import.
–r Specifies that group membership for existing groups should be refreshed. If
a group that was requested to be imported already exists in Tivoli Access
Manager, any non-excluded user entries from the UNIX group will be
added to the existing Tivoli Access Manager group.
–R AD_domain
Specifies the name of the Active Directory domain to use in user names
and group names. This option is required only when Tivoli Access
Manager is configured to multiple Active Directory domains and Tivoli
Access Manager for Operating Systems is not configured
–S suffix
Specifies the Tivoli Access Manager suffix that is to be appended to the
common name when creating a distinguished name in the Tivoli Access
Manager user registry. This suffix must exist in the Tivoli Access Manager
user registry.
–u Specifies that only UNIX users should be imported.
–v Displays verbose messages.
–V Displays the version information.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
1. To import all users and groups from the UNIX registry, enter:
pdosrgyimp –S o=ibm –l sec_master
2. To import all users and groups from the UNIX registry and refresh group
membership for UNIX groups that previously existed in the Tivoli Access
Manager user registry, enter:
pdosrgyimp –S o=ibm –l sec_master –r
3. To import all users and groups from the UNIX registry with the exception of
those found in the exclude.1 exclude file, enter:
pdosrgyimp –S o=ibm –l sec_master –E exclude.1
4. To import only users and groups from the UNIX registry that are listed in the
include.1 include file, enter:
pdosrgyimp –S o=ibm –l sec_master –I include.1
5. To import only users from the UNIX registry that are listed in the include.2
include file and add them as members of the default-group group, enter:
pdosrgyimp
Chapter 8. Commands 331
pdosrgyimp –S o=ibm –l sec_master –u –I include.2 –G default–group
6. To import only groups from UNIX registry that are listed in the include.2
include file and exclude the users listed in the exclude.2 exclude file from
group membership, enter:
pdosrgyimp –S o=ibm –l sec_master –g –I include.2 –E exclude.2
7. To import all users and groups from the UNIX registry into the tivoli.com
Active Directory domain when Tivoli Access Manager is configured to use
multiple Active Directory domains (which includes tivoli.com) and Tivoli
Access Manager for Operating Systems is not configured, enter:
pdosrgyimp -S dc=tivoli,dc=com -R tivoli.com -l sec_master
8. To import all users and groups from the UNIX registry in the tivoli.com
Active Directory domain when Tivoli Access Manager is configured to use a
single Active Directory domain, enter:
pdosrgyimp -S dc=tivoli,dc=com -l sec_master
pdosrgyimp
332 Administration Guide
pdosrstr
Restores Tivoli Access Manager for Operating Systems database and configuration
files from a backup file.
Syntax
pdosrstr –f filename
pdosrstr –h
pdosrstr –V
pdosrstr –?
Description
The pdosrstr command restores Tivoli Access Manager for Operating Systems files
that were previously saved using the pdosbkup command. Files are restored from
the backup file specified by the –f option.
Options
–? Displays the usage message.
–f filename
Specifies the name of the backup file.
–h Displays the usage message.
–V Displays the version information.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following is an example of pdosrstr usage:
1. To restore files saved in the pdosbkup25Oct2001.14_32_41.tar file in the default
directory, enter:
pdosrstr –f /var/pdos/pdosbkup/pdosbkup25Oct2001.14_32_41.tar
pdosrstr
Chapter 8. Commands 333
pdosshowuser
Shows various attributes of a specific user.
Syntax
pdosshowuser [–v] [–c] [–g] [–a] [–l] [–p] [–t trace_string]
pdosshowuser [–v] [–c] [–g] [–a] [–l] [–p] –u uid [–t trace_string]
pdosshowuser [–v] [–c] [–g] [–a] [–l] [–p] –n name [–t trace_string]
pdosshowuser –h
pdosshowuser –V
pdosshowuser –?
Description
The pdosshowuser command displays various attributes of the invoking or
specified user. All attributes of the user are displayed by default but they can be
limited to a subset of attributes by specifying any combination of the –c, –g, –l, –a,
and –p options.
Options
–? Displays the usage message.
–a Displays the user audit level for the specified user.
–c Displays credential information for the specified user.
–g Displays Tivoli Access Manager group membership information for the
specified user.
–h Displays the usage message.
–n name
Specifies the UNIX name of the user whose information is to be displayed.
–p Displays the password management policy attributes for the specified user.
–l Displays the login activity policy attributes for the specified user.
–t trace_string
Sets the trace string for displaying trace messages.
–u uid Specifies the UID of the user whose information is to be displayed.
–v Displays verbose messages.
–V Displays the version information.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
pdosshowuser
334 Administration Guide
Examples
1. To view all of the information for the invoking user, root (Tivoli Access
Manager groups, cached credential information, user-level audit, login activity
policy, and password management policy), enter:
pdosshowuser
The output is:
User root (uid 0)
Group Membership Information
root is a member of the following Access Manager groups:
osseal-admin
osseal-auditors
Cached Credential Information
root is authenticated.
The credential was last refreshed at Mon Aug 11 12:14:12 CDT 2003.
The credential refresh time never expires.
The credential was last accessed at Mon Aug 11 12:23:44 CDT 2003.
The credential hold time never expires.
Audit Information
The following AuditAuth policy is in effect for root:
none
There is no AuditTrace policy in effect for root.
Login Activity Policy Attributes
MaxInactiveDays = 0
MaxFailedLogins = 0
MaxGraceLogins = 0
LoginMinutes = 0
LockMinutes = 0
MaxConcurrent = 0
PolicyDisabled = 1
MinPasswordDays = 0
MaxPasswordDays = 0
Password Management Policy Attributes
MinPasswordLen = 8
MinPasswordAlpha = 4
MinPasswordAlphaNum = 0
MinPasswordNumeric = 2
MinPasswordLower = 0
MinPasswordUpper = 0
MinPasswordSpecial = 0
MaxPasswordRepeat = 0
PasswordNameCheck = 0
PasswordHistory = 0
PasswordOldPwdCheck = 0
PasswordMaxConsPrev = 0
PasswordNonNumFirstLast = 0
MinPasswordDays = 0
2. To view only the cached credential information for the user riley, enter:
pdosshowuser -c -n riley
If there is no cached credential for riley, the output is:
User riley (uid 204)
Cached Credential Information
riley is authenticated
There is no cached credential for riley
If there is a cached credential for riley, the output is:
User riley (uid 204)
Cached Credential Information
riley is authenticated.
The credential was last refreshed at Mon Aug 11 12:30:06 CDT 2003
pdosshowuser
Chapter 8. Commands 335
The credential refresh time expires at Mon Aug 11 12:45:06 CDT 2003
The credential was last accessed at Mon Aug 11 12:30:06 CDT 2003
The credential hold time expires at Mon Aug 11 12:50:06 CDT 2003
3. To view the user-level audit information for the user riley, enter:
pdosshowuser -a -n riley
The output is:
User riley (uid 204)
Audit Information
The following AuditAuth policy is in effect for riley:
deny
The following AuditTrace policy is in effect for riley:
exec_l
pdosshowuser
336 Administration Guide
pdossudo
Invoke a command as a different UNIX user.
Syntax
pdossudo [–v] [–t trace_string] command_alias [arg [arg ...]]
pdossudo –h
pdossudo –V
pdossudo –?
Description
The pdossudo command lets an authorized user invoke a command that would
otherwise require UNIX privileges that the invoking UNIX user does not possess.
The invoker must pass the following authorization checks before the command is
executed:
v The prevailing Tivoli Access Manager for Operating Systems user must have
permission to surrogate to the target user as specified in the extended attributes
of the Sudo protected object.
v The prevailing Tivoli Access Manager for Operating Systems user must have
execute permission on the specified sudo-command (or matching subordinate
argument class if an ACL is present).
v The arguments satisfy any constraints specified in a matching argument class.
Options
–? Displays the usage message.
–h Displays the usage message.
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays verbose messages.
–V Displays the version information.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
See “An example of Sudo usage” on page 66 for an example of setting up a
command for pdossudo use.
pdossudo
Chapter 8. Commands 337
pdosteccfg
Configures pdostecd, the Tivoli Enterprise Console daemon.
Syntax
pdosteccfg [–v] [–admin_name admin_name] [–admin_pwd admin_password]
[–autostart on | off] [–burst number_events] [–delay seconds] [–delete option [, option
...]] [–interval seconds] [–log_entries number_entries] [–logs number_logs] [–rspfile
file_name] [–sec_master_pwd admin_password]
pdosteccfg –rspfile file_name
pdosteccfg –help [option]
pdosteccfg –operations
pdosteccfg –usage
pdosteccfg –version
pdosteccfg –?
Description
The pdosteccfg command is used to configure the pdostecd daemon.
The pdostecd daemon uses the /var/pdos/audit/audit.log file as input for its
processing. This file must exist and be accessible to the pdostecd daemon,
otherwise the daemon shuts down. Restart the pdostecd daemon after making the
audit.log file available again.
Options
–? Displays the usage message.
–admin_name admin_name
Specifies the name of the Tivoli Access Manager administrator. In
combination with the –admin_pwd option, replaces the
–sec_master_password option.
–admin_pwd admin_password
Specifies the Tivoli Access Manager administrator password. In
combination with the –admin_name option, replaces the
–sec_master_password option.
–autostarton | off
Indicates whether the pdostecd daemon should start automatically (on) or
not (off).
–burst number_events
Specifies the maximum number of events that the daemon should process
at a time.
–delay seconds
Specifies the number of seconds to wait when there is no event that is
available.
pdosteccfg
338 Administration Guide
–delete option
Deletes the specified options from the current configuration. One or more
of the following, separated by commas, can be specified:
v burst
v delay
v interval
v log_entries
v logs
.
–h Displays help for each of the options.
–help [option]
Displays help for each of the options. To display help for a specific option,
use –help option.
–interval seconds
Specifies the number of seconds to wait after processing events before
checking for the arrival of new events.
–log_entries number_entries
Specifies the number of msg__pdostecd.log entries to use before rolling
over to a new log. A value of zero, the default, means never roll over to a
new log.
–logs number_logs
Specifies the number of msg__pdostecd.log files to use before recycling log
files. A value of zero indicates that log files should never be recycled. This
option only has an effect if –log_entries is nonzero.
–operations
Displays the command options available.
–rspfile file_name
Specifies the name of a file that contains the option values for the
configuration. Options that are specified on the command line override
options that are specified in the response file.
–sec_master_pwd admin_password
Specifies the Tivoli Access Manager security master password.
–usage
Displays the usage message.
–v Displays the version information.
–version
Displays the version information.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
pdosteccfg
Chapter 8. Commands 339
Examples
To have the pdostecd daemon start automatically:
pdosteccfg –autostart on
pdosteccfg
340 Administration Guide
pdostecucfg
Unconfigures pdostecd, the Tivoli Enterprise Console daemon.
Syntax
pdostecucfg [–admin_name admin_name] [–admin_pwd admin_password]
[–remove_per_policy on | off] [–rspfile file_name] [–sec_master_pwd
admin_password]
pdostecucfg –rspfile file_name
pdostecucfg –help [option]
pdostecucfg –operations
pdostecucfg –usage
pdostecucfg –version
pdostecucfg –?
Description
The pdostecucfg command is used to unconfigure the pdostecd daemon. The
pdostecd daemon must be unconfigured before using the pdosucfg command to
unconfigure Tivoli Access Manager for Operating Systems.
Options
–? Displays help on the command usage.
–admin_name admin_name
Specifies the name of the Tivoli Access Manager administrator. In
combination with the –admin_pwd option, replaces the
–sec_master_password option.
–admin_pwd admin_password
Specifies the the Tivoli Access Manager administrator password. In
combination with –admin_name, replaces the –sec_master_password
option.
–help [option]
Displays help for all of the options. To display help for one option, use
–help option.
–operations
Lists the supported options.
–remove_per_policy on | off
Indicates whether to unregister the policy branch specific Tivoli Access
Manager for Operating Systems information this machine is configured to
use. Accept the default value (off), if other Tivoli Access Manager for
Operating Systems machines are configured under that policy branch.
Doing so could make the machine inoperable. If additional policy was
added under that policy branch, you might need to remove it manually.
The default is off.
–rspfile file_name
Specifies the file that contains option values for the unconfiguration.
pdostecucfg
Chapter 8. Commands 341
–sec_master_pwd admin_password
Specifies the Tivoli Access Manager security master password.
–usage
Displays help on the command usage.
–version
Displays the version.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
pdostecucfg
342 Administration Guide
pdosucfg
Unconfigures Tivoli Access Manager for Operating Systems.
Syntax
pdosucfg [–admin_name admin_name] [–admin_pwd admin_password]
[–lrd_admin_name admin_name] [–lrd_admin_pwd admin_password]
[–remove_once_only on | off] [–remove_per_policy on | off] [–rspfile file_name]
[–force]
pdosucfg –rspfile file_name
pdosucfg –help [option]
pdosucfg –operations
pdosucfg –usage
pdosucfg –version
pdosucfg –?
Description
The pdosucfg command is used to unconfigure the pdosd daemon. Before
unconfiguring Tivoli Access Manager for Operating Systems, you must
unconfigure the pdostecd daemon using the pdostecucfg command before
unconfiguring Tivoli Access Manager for Operating Systems. See “pdostecucfg” on
page 341.
Options
–? Displays help on the command usage.
–admin_name admin_name
Specifies the name of the Tivoli Access Manager administrator.
–admin_pwd admin_password
Specifies the Tivoli Access Manager administrator password.
–force Causes the operation to proceed even if the command-checking indicates
that the operation cannot be performed. Can be used in combination with
the –remove_once_only option.
–help [option]
Displays help for all of the options. To display help for one option, use
–help option.
–lrd_admin_name admin_name
Specifies the name of the Tivoli Access Manager administrator name to use
when unregistering the pdoslrd daemon with the Tivoli Access Manager
policy server.
–lrd_admin_pwd admin_password
Specifies the Tivoli Access Manager administrator password to use when
unregistering the pdoslrd daemon with the Tivoli Access Manager policy
server.
–operations
Lists the supported options.
pdosucfg
Chapter 8. Commands 343
–remove_once_only on | off
Indicates whether to unregister the Tivoli Access Manager for Operating
Systems product policy. Accept the default (off) if other Tivoli Access
Manager for Operating Systems clients are configured to this Tivoli Access
Manager server. Specifying this information under this condition could
make those other clients inoperable. If additional policy were added, you
might need to remove it manually.
The default is off.
–remove_per_policy on | off
Indicates whether to unregister the initial policy branch-specific
information. Accept the default (off) if other Tivoli Access Manager for
Operating Systems clients are configured under this initial policy branch.
Specifying this information under this condition could make those clients
inoperable. If additional policy were added under the initial policy branch,
you might need to remove it manually.
The default is off.
–rspfile file_name
File containing option values for the unconfigure operation.
–usage
Displays help on the command usage.
–version
Displays the version.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
pdosucfg
344 Administration Guide
pdosuidprog
Identifies setuid or setgid programs on a system so that an administrator can
decide whether they should be included in the Trusted Computing Base (TCB).
Syntax
pdosuidprog –l [–v] [–t trace_string] [–H] [–s] [–x directory [–x directory ...]]
[directories ...]
pdosuidprog –g [–v] [–t trace_string] [–c class_name] [–H] [–s] [–p policy-branch] [–x
directory [–x directory...]] [directories ...]
pdosuidprog –h
pdosuidprog –V
pdosuidprog –?
Description
The pdosuidprog command searches the specified directories for setuid and setgid
programs. If no directories are specified on the command line, the search begins in
the current directory and descends all of the directories under it. This command
does not search the /dev directory on any system nor the /proc directory on Solaris
or Linux systems.
Multiple directories can be searched by specifying them on the command line. If
directories are specified, they must be last entry on the command line. Directories
that should not be descended should be specified with the –x option.
The pdosuidprog command relies on the operating system to detect circular linked
directory structures. The command continues to descend through the directory
structure until the operating system denies the request. Circular linked directory
structures should be excluded from the search using the –x option.
The format of the output produced by the pdosuidprog command depends on
whether the –l or the –g option is specified. If the –l option is specified, the
pdosuidprog command generates a list of all of the setuid and setgid programs
that were found. The list includes the file name, the UID for setuid programs and
the GID for setgid programs.
If the –H option is specified with the –l option, any duplicate hard links that are
found are not listed.
The –l option cannot be used with the –g option and either the –l or –g option
must be specified. If the –g option is specified, the pdosuidprog command
generates a list of pdadmin commands that are required to place the setuid and
setgid programs in the Trusted Computing Base (TCB).
If the –H option is specified with the –g option, commands generated for duplicate
hard links are in the form of a comment.
The default class used to generate the Tivoli Access Manager TCB entry commands
is Secure-Programs. However, it can be changed using the –c option followed by
the class name.
pdosuidprog
Chapter 8. Commands 345
The default policy branch name used to generate the Trusted Computing Base
object create commands is obtained from the osseal.conf file. The policy branch
name can be changed by using the –p option.
Options
–? Displays the usage message.
–c class_name
Specifies the class name to be used in the pdadmin object creation
commands. The following values are valid:
v Secure-Files
v Secure-Programs
v Impersonator-Programs
v Immune-Programs
v Immune-Surrogate-Programs
The default value is Secure-Programs.
–g Generates pdadmin object creation commands.
–h Displays the usage message.
–H Does not generate duplicates for hard links.
–l Generates a list of filenames.
–p policy_branch
Specifies the policy branch name to be used in the pdadmin object creation
commands.
–s Does not traverse symbolic links to other file systems.
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays verbose messages.
–V Displays the version information.
–x directory
Specifies a directory that should not be descended in the search. The
directory name must be a fully qualified path name.
directories
Indicates directories that should be descended in the search. The directory
name must be a fully qualified path name.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
The following are examples of pdosuidprog usage:
1. To search the current directory for setuid and setgid programs and generate a
list of files, enter:
pdosuidprog
346 Administration Guide
pdosuidprog -l
The output is:
/opt/pdos/bin/pdosunauth : 1444 : 228
/opt/pdos/bin/pdosrefresh : 1444 : 228
/opt/pdos/bin/pdosdestroy : 1444 : 228
/opt/pdos/bin/pdoswhoami : : 228
/opt/pdos/bin/pdoswhois : 1444 : 228
/opt/pdos/bin/pdossudo : 0 : 228
/opt/pdos/bin/pdosexempt : 1444 : 228
/opt/pdos/bin/pdosrevoke : 1444 : 228
/opt/pdos/bin/pdosctl : : 228 /opt/pdos/bin/pdosd : 0 : 228
/opt/pdos/bin/pdoswdd : 0 : 228
/opt/pdos/bin/pdosauditd : 0 : 228
2. To search the /opt directory for setuid and setgid programs without
descending the /opt/pdos/bin directory and generate a list of pdadmin
commands for the testbranch policy branch, enter:
pdosuidprog -g -x /opt/pdos/bin -p testbranch /opt
The output, formatted to fit on the printed page, is:
object create /OSSEAL/testbranch/TCB/Secure-Programs
/opt/local/bin/ansuprog "" 2 ispolicyattachable yes
pdosuidprog
Chapter 8. Commands 347
pdosunauth
Spawns a shell that executes commands in an unauthenticated environment.
Syntax
pdosunauth [–v] [–t trace_string] [command]
pdosunauth –h
pdosunauth –V
pdosunauth –?
Description
The pdosunauth command spawns a shell that is treated as unauthenticated for
the purposes of Tivoli Access Manager for Operating Systems authorization
decisions. This command allows a program to be tested in an unauthenticated
environment. If a command is specified, the shell is spawned to execute only that
command.
Options
–? Displays the usage message.
–h Displays the usage message.
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays verbose messages.
–V Displays the version information.
command
The name of the command to be executed.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
1. To invoke a shell that can be used to invoke commands as an unauthenticated
user, enter:
pdosunauth
2. To list the contents of the /var/pdos/cred directory as an unauthenticated user,
enter:
pdosunauth ls /var/pdos/cred
The output is:
ls: /var/pdos/cred:
The file access permissions do not allow the specified action.
pdosunauth
348 Administration Guide
pdosversion
Displays the version information for Tivoli Access Manager for Operating Systems.
Syntax
pdosversion
Description
The pdosversion command displays the version information for Tivoli Access
Manager for Operating Systems including the versions of the shared libraries.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
Examples
To display the Tivoli Access Manager for Operating Systems version information,
enter:
pdosversion
The output is similar to the following:
IBM Tivoli Access Manager for Operating Systems Runtime 6.0.0
pdosversion 6.0.0.0 (060111a)
libosseald 6.0.0.0 (060111a)
libosseal 6.0.0.0 (060111a)
libkosseal 6.0.0.0 (060111a)
liblpm 6.0.0.0 (060111a)
LRD_AuditInput 6.0.0.0 (060111a)
LRD_EmailOutput 6.0.0.0 (060111a)
LRD_FileOutput 6.0.0.0 (060111a)
LRD_NetOutput 6.0.0.0 (060111a)
Chapter 8. Commands 349
pdoswhoami
Displays information about the Tivoli Access Manager user.
Syntax
pdoswhoami [–v] [–t trace_string] –a
pdoswhoami [–v] [–t trace_string] –l
pdoswhoami [–v] [–t trace_string] –n
pdoswhoami –h
pdoswhoami –V
pdoswhoami –?
Description
The pdoswhoami command displays Tivoli Access Manager accessor information
about the invoking user.
With no specified options, the pdoswhoami command displays the invoking user’s
Tivoli Access Manager user name.
The –n option displays the accessor UID of the invoking user.
The –a option displays both the accessor UID and the Tivoli Access Manager user
name of the invoking user.
The –l option displays the accessor UID, Tivoli Access Manager user name, and the
following credential information about the invoking user:
v Tivoli Access Manager for Operating Systems group membership information
v Time that the credential was last refreshed
v The refresh expiry of the credential
v Time that the credential was last accessed
v The hold time expiry of the credential
Options
–? Displays the usage message.
–a Displays the accessor UID and Tivoli Access Manager user name.
–h Displays the usage message.
–l Displays the accessor UID, Tivoli Access Manager user name, and Tivoli
Access Manager credential information.
–n Displays the accessor UID.
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays verbose messages.
–V Displays the version information.
pdoswhoami
350 Administration Guide
Exit status
0 The command completed successfully.
1 An error occurred.
Authorization
No required authorization.
Examples
1. To display the Tivoli Access Manager user name of the invoking user, enter:
pdoswhoami
The output is:
riley
2. To display the user ID and Tivoli Access Manager user name of the invoking
user, enter:
pdoswhoami –a
The output is:
204 riley
3. To display the user ID, Tivoli Access Manager user name, and credential
information of the invoking user, enter:
pdoswhoami –l
The output is:
204 riley
The credential is associated with the following groups:
staff
The credential was last refreshed at Wed Oct 25 08:21:40 2001
The credential refresh time expires at Wed Oct 25 08:41:40 2001
The credential was last accessed at Wed Oct 25 08:31:20 2001
The credential hold time expires at Wed Oct 25 08:56:20 2001
If Tivoli Access Manager for Operating Systems is configured to use the
tivoli.com domain in a Tivoli Access Manager environment configured to use
multiple Active Directory domains, the output is:
The credential is associated with the following groups:
The credential was last refreshed at Wed Oct 25 08:21:40 2001
The credential refresh time expires at Wed Oct 25 08:41:40 2001
The credential was last accessed at Wed Oct 25 08:31:20 2001
The credential hold time expires at Wed Oct 25 08:56:20 2001
pdoswhoami
Chapter 8. Commands 351
pdoswhois
Displays Tivoli Access Manager for Operating Systems accessor ID information
associated with the specified process IDs.
Syntax
pdoswhois [–v] [–t trace_string] [–l] pid [pid ...]]
pdoswhois –h
pdoswhois –V
pdoswhois –?
Description
The pdoswhois command displays the Tivoli Access Manager for Operating
Systems accessor ID information about the specified process ID (PID) list. The list
of PIDs must occur last on the pdoswhois command line. The Tivoli Access
Manager for Operating Systems accessor ID and accessor user ID for each specified
process are displayed.
If the –l option is specified, the pdoswhois command also displays the following
credential information for each specified process:
v Tivoli Access Manager for Operating Systems group membership information
v The time that the credential was last refreshed
v The refresh expiry of the credential
v The time that the credential was last accessed
v The hold time expiry of the credential
Options
–? Displays the usage message.
–h Displays the usage message.
–l Displays the Tivoli Access Manager for Operating Systems accessor UID,
accessor name, and credential information associated with each specified
process.
–t trace_string
Sets the trace string for displaying trace messages.
–v Displays verbose messages.
–V Displays the version information.
pid Specifies the process ID (PID).
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
pdoswhois
352 Administration Guide
Examples
1. To display the Tivoli Access Manager for Operating Systems accessor ID
information for a single process, enter:
pdoswhois 170358
The output is:
Pid, 170358, is running under the uid = 204, user name = riley
2. To display the Tivoli Access Manager for Operating Systems accessor ID
information for multiple processes, enter:
pdoswhois 170358 53804 219134
The output is:
Pid, 170358, is running under the uid = 204, user name = riley.
The process with pid, 53804, is running as unauthenticated.
Pid, 219134, is running under the uid = 0, user name = root.
3. To display the Tivoli Access Manager for Operating Systems accessor ID
information for multiple processes along with the credential information, enter:
pdoswhois –l 170358 219134
The output is:
Pid, 170358, is running under the uid = 204, user name = riley.
The credential is associated with the following groups: staff
The credential was last refreshed at Wed Oct 25 08:56:39 2000
The credential refresh time expires at Wed Oct 25 09:16:39 2000
The credential was last accessed at Wed Oct 25 08:40:12 2000
The credential hold time expires at Wed Oct 25 09:05:12 2000
-------------------------------------------------------
Pid, 219134, is running under the uid = 0, user name = root.
The credential is associated with the following groups:
osseal-admin
osseal-auditors
The credential was last refreshed at Wed Oct 25 08:59:05 2000
The credential refresh time never expires.
The credential was last accessed at Wed Oct 25 09:00:51 2000
The credential hold time never expires.
pdoswhois
Chapter 8. Commands 353
policyview
Extract policy from the Tivoli Access Manager policy database to a plain text file.
Syntax
policyview [–v] [–e] [–D] [–a admin_name] [–p admin_password] [–d domain] [–r
resource] [–b branch_list] [–o out_file] [–t trace_string] [–x exclude_map]
policyview –h
policyview –V
policyview –?
Description
The policyview command extracts protected object policy from a Tivoli Access
Manager policy database and formats it into three types of output. The data is
formatted into a plain text file, a file containing pdadmin commands that can be
used to recreate the policy, and a file containing XML-formatted data. The output
files will be placed in the current working directory with names of policyview.txt,
policyview.cmd, and policyview.xml. The –o option can be used to modify the
names of the output files.
If the –r and –b options are not specified, all objects under the configured Tivoli
Access Manager for Operating Systems policy branches will be displayed in
precedence order. Objects will be displayed for those policy branches beginning at
the /OSSEAL/policy-branch where policy-branch is the highest precedence policy
branch. If the same resource exists under more than one policy branch, the highest
precedence object will be displayed. If the –D option is specified, the duplicate
objects from the lower precedence policy branches will be displayed after the
highest precedence object.
If the –r option is not specified, but the –b option is, all objects under the policy
branches specified by the –b option will be displayed in precedence order. Objects
will be displayed for those policy branches beginning at /OSSEAL/policy-branch
where policy-branch is the highest precedence policy branch. If the same resource
exists under more than one policy branch, the highest precedence object will be
displayed. If the –D option is specified, the duplicate objects from the lower
precedence policy branches will be displayed after the highest precedence object.
If the –r option is specified and the resource begins with a slash (/) character, then
the resource is considered to be an absolute object name. In this case, if the –b
option was specified, it will be ignored and any configured policy branches will
not be considered. Objects will be displayed beginning with the specified resource
name.
If the –r option is specified and the resource does not begin with a slash (/)
character, the resource is considered to be a relative object name. If the –b option is
not specified, all objects under the configured Tivoli Access Manager for Operating
Systems policy branches are displayed in precedence order beginning relative to
the specified resource. If the –b option is specified, all objects under the policy
branches specified by the –b option are displayed in precedence order beginning
relative to the specified resource. Objects are displayed for those policy branches
beginning at /OSSEAL/policy-branch/resource where the policy-branch is the highest
precedence policy branch. If the same resource exists under more than one policy
policyview
354 Administration Guide
branch, the highest precedence object is displayed. If the –D option is specified, the
duplicate objects from the lower precedence policy branches are displayed after the
highest precedence object.
If the –e option is specified, any inherited (effective) ACL, POP, or authorization
rule is not be displayed.
Options
–? Displays the usage message.
–a admin_name
Specifies the Tivoli Access Manager administrator name. If Tivoli Access
Manager for Operating Systems is not configured, the default is
sec_master.
–b branch_list
Specifies a comma-separated, hierarchical list of policy branches.
–d domain
Specifies the Tivoli Access Manager secure domain. If Tivoli Access
Manager for Operating Systems is configured, this option defaults to the
configured domain; otherwise, it defaults to the domain to which Tivoli
Access Manager is configured.
–D Indicates that duplicate policy entries are displayed.
–e Indicates that the effective ACL, POP, and authorization rule are not
displayed.
–h Displays the usage message.
–o out_file
Specifies the base name of the output files. If this option is not specified,
the base name of the output files will be ./policyview.
–p admin_password
Specifies the Tivoli Access Manager administrator password.
–r resource
Specifies the resource starting point.
–t trace_string
Sets the trace string for displaying trace messages.
–x exclude_map
Sets the exclusion bit mask that is used to exclude output fields from the
output.
–v Displays verbose messages.
–V Displays the version information.
Authorization
You must be a Tivoli Access Manager for Operating Systems runtime administrator
to use this command.
Exit status
0 The command completed successfully.
1 An error occurred.
policyview
Chapter 8. Commands 355
Examples
1. To display all files in the Trusted Computing Base, using the configured
precedence order, enter:
policyview -a sec_master -p password -r TCB
2. To display all of the files listed in the TCB where Tivoli Access Manager for
Operating Systems is configured to the dev policy branch in the research Tivoli
Access Manager secure domain:
policyview -d research -a sec_research -p password -b dev -r TCB
OR
policyview -d research -a sec_research -p password -r /OSSEAL/dev/TCB
3. To display all of the information needed to access file resources in /opt/pdos,
using the configured branches and domain, enter:
policyview -p password -r File/opt/pdos
4. To display all of the information needed to access file resources in /opt/pdos,
using a branch ordering of test, db2, and ihs, enter:
policyview -p password -b test,db2,ihs -r File/opt/pdos
5. To display all of the information controlling access to the /Management object
space, enter:
policyview -p password -r /Management
policyview
356 Administration Guide
Chapter 9. Integrating with Tivoli Enterprise Console
Tivoli Access Manager for Operating Systems provides the ability to generate
Tivoli Enterprise Console events. This chapter provides information about how to
configure the Tivoli Enterprise Console log file adapter to send Tivoli Enterprise
Console events for Tivoli Access Manager for Operating Systems.
For more information about Tivoli Enterprise Console, and the list of supported
operating system platforms, see the IBM Tivoli Enterprise Console: User’s Guide.
Overview
Tivoli Access Manager for Operating Systems handles auditing tasks and can
generate Tivoli Enterprise Console events. To integrate Tivoli Access Manager for
Operating Systems with the functionality of Tivoli Enterprise Console, the Tivoli
Access Manager for Operating Systems Enterprise Console Integration product
must be installed on the following machines:
v The Tivoli server
v The Tivoli Enterprise Console event server
v Any managed node that is a gateway to a machine running Tivoli Access
Manager for Operating Systems
Note: The Tivoli Access Manager for Operating Systems Enterprise Console
Integration component can be installed on any supported Tivoli Enterprise
Console system.
Additionally, the Tivoli Enterprise Console logfile adapter for Tivoli Access
Manager for Operating Systems must be installed on the endpoints that have Tivoli
Access Manager for Operating Systems installed. For information about installing
Tivoli Access Manager for Operating Systems Enterprise Console Integration, see
the IBM Tivoli Access Manager for Operating Systems: Installation Guide. For
information about installing the Tivoli Enterprise Console logfile adapter, refer to
the Tivoli Enterprise Console documentation to determine the system requirements
that must be met to run Tivoli Enterprise Console on a given operating system
platform.
After Tivoli Access Manager for Operating Systems Enterprise Console Integration
has been installed, the pdostecd daemon must be configured and started on
endpoints. The endpoints and the event server must be configured to send and
receive Tivoli Enterprise Console events for Tivoli Access Manager for Operating
Systems. If this configuration is not done, events from Tivoli Access Manager for
Operating Systems will not be received.
Notes:
1. If no auditing is being done, no events will be generated, regardless of whether
required software has been installed and configured.
2. The Tivoli Enterprise Console event server can be configured to receive and
process one or both Tivoli Enterprise Console events and Tivoli Risk Manager
events from Tivoli Access Manager for Operating Systems clients. However,
each Tivoli Access Manager for Operating Systems client can only be
configured to send either Tivoli Enterprise Console events or Tivoli Risk
Manager events.
© Copyright IBM Corp. 2000, 2005 357
3. The /var/pdos/audit/audit.log file is the source for the pdostecd daemon. If
this file is removed or becomes unavailable, the pdostecd daemon shuts down
and no further events are processed. After making the file available again,
restart the pdostecd daemon to resume the processing of events.
Installing and configuring the logfile adapter
The Tivoli Enterprise Console logfile adapter for Tivoli Access Manager for
Operating Systems executable files and other files are installed on the endpoint
through the Adapter Configuration Facility.
Notes:
1. The logfile adapter for Tivoli Access Manager for Operating Systems can be
installed only on endpoints. To generate events from a managed node, you
must install an endpoint on the managed node.
2. Refer to the Tivoli Enterprise Console documentation to determine the system
requirements that must be met to run Tivoli Enterprise Console on a given
operating system platform. The Tivoli Access Manager for Operating Systems
Enterprise Console Integration component can be installed on any supported
Tivoli Enterprise Console system.
3. The root user has to be defined as a Tivoli Access Manager for Operating
Systems runtime administrator during distribution of the PDOS-ACPROF
profile for the setup to complete successfully.
The process of installing Tivoli Access Manager for Operating Systems Enterprise
Console Integration creates an adapter configuration profile (PDOS-ACPROF) in
the PDOS profile manager and adds a tecad_logfile_pdos record to that profile.
For more information on the Adapter Configuration Facility, refer to the IBM Tivoli
Enterprise Console: User’s Guide.
Complete the following steps to complete the integration process:
1. Distribute PDOS-ACPROF to all the endpoints on which you want to generate
Tivoli Enterprise Console events.
After this profile has been successfully distributed, the Tivoli Enterprise
Console logfile adapter for Tivoli Access Manager for Operating Systems will
be started automatically.
2. Use the Setup TEC Event Server for PDOS job to set up the event server so
that it can receive and process Tivoli Enterprise Console events for Tivoli
Access Manager for Operating Systems.
For more information, see “Setup TEC event server for PDOS” on page 225.
3. Configure and start the pdostecd daemon. See “The pdostecd Tivoli Enterprise
Console daemon” on page 104 for details.
After the Setup TEC Event Server for PDOS job has been successfully executed,
the Tivoli Enterprise Console event console will start receiving Tivoli Access
Manager for Operating Systems events. All the Tivoli Access Manager for
Operating Systems audit events are accessible through the LOGFILE event source.
To stop the Tivoli Enterprise Console logfile adapter for Tivoli Access Manager for
Operating Systems, go to the /etc/Tivoli/tecad/pdos/bin directory on the
endpoints and run stop_tecad_pdos. Or, you can use the Stop TEC Adapter task
or job. To restart the logfile adapter, run start_tecad_config_pdos from the same
directory. Or, you can use the Start TEC Adapter task or job. The Tivoli Enterprise
Console logfile adapter subsequently restarts automatically on system reboot.
358 Administration Guide
For more information, see “Start PDOS TEC adapter” on page 233 and “Stop PDOS
TEC adapter” on page 233.
Chapter 9. Integrating with Tivoli Enterprise Console 359
360 Administration Guide
Chapter 10. Integrating with Tivoli Risk Manager
Tivoli Access Manager for Operating Systems provides the ability to generate
Tivoli Risk Manager events. This chapter provides information about how to
configure the Tivoli logfile adapter to send Tivoli Risk Manager events for Tivoli
Access Manager for Operating Systems.
For more information about Tivoli Risk Manager, see the IBM Tivoli Risk Manager:
User’s Guide.
Overview
Tivoli Access Manager for Operating Systems handles auditing tasks and can
generate Tivoli Risk Manager events. To integrate Tivoli Access Manager for
Operating Systems with the functionality of Tivoli Risk Manager, the Tivoli Access
Manager for Operating Systems Enterprise Console Integration must be installed
on the following machines:
v The Tivoli server
v The Tivoli Enterprise Console event server
v Any managed node that is a gateway for a machine running Tivoli Access
Manager for Operating Systems
Additionally, the Tivoli logfile adapter for Tivoli Access Manager for Operating
Systems must be installed on the endpoints that have Tivoli Access Manager for
Operating Systems installed. For information about installing Tivoli Access
Manager for Operating Systems Enterprise Console Integration, see the IBM Tivoli
Access Manager for Operating Systems: Installation Guide. Information about installing
the Tivoli logfile adapter is contained in the next section of this document.
After Tivoli Access Manager for Operating Systems Enterprise Console Integration
is installed, the endpoints and the event server must be configured to send and
receive Tivoli Risk Manager events for Tivoli Access Manager for Operating
Systems. If this configuration is not done, events from Tivoli Access Manager for
Operating Systems will not be received.
Notes:
1. If no auditing is being done, no events will be generated, regardless of whether
the required software is installed and configured.
2. The Tivoli Enterprise Console event server can be configured to receive and
process one or both Tivoli Enterprise Console events and Tivoli Risk Manager
events from endpoints. However, each endpoint can only be configured to send
either Tivoli Enterprise Console events or Tivoli Risk Manager events.
3. The /var/pdos/audit/audit.log file is the source for the pdostecd daemon. If
this file is removed or becomes unavailable, the pdostecd daemon shuts down
and no further events are processed. After making the file available again,
restart the pdostecd daemon to resume the processing of events.
© Copyright IBM Corp. 2000, 2005 361
Installing and configuring the logfile adapter to integrate with Tivoli
Risk Manager
The Tivoli logfile adapter for Tivoli Access Manager for Operating Systems
executables and other files are installed on the endpoint through the Adapter
Configuration Facility.
Notes:
1. The Tivoli logfile adapter for Tivoli Access Manager for Operating Systems can
be installed only on endpoints. To generate events from a managed node, you
must install an endpoint on the managed node.
2. Refer to the Tivoli Enterprise Console documentation to determine the system
requirements that must be met to run Tivoli Enterprise Console on a given
operating system platform. The Tivoli Access Manager for Operating Systems
Enterprise Console Integration component can be installed on any supported
Tivoli Enterprise Console system.
3. The root user must be defined as a Tivoli Access Manager for Operating
Systems runtime administrator during distribution of the PDOS-RISKMGR-ACPROF profile for the setup to complete successfully.
The process of installing Tivoli Access Manager for Operating Systems Enterprise
Console Integration creates an adapter configuration profile (PDOS-RISKMGR-ACPROF) in the PDOS profile manager and adds a tecad_logfile_pdos_riskmgr
record to that profile. For more information on the Adapter Configuration Facility,
refer to the Tivoli Enterprise Console: User’s Guide.
Complete the following steps to complete the integration process:
1. Distribute PDOS-RISKMGR-ACPROF to all the endpoints from which you
want to send Tivoli Risk Manager events.
After this profile has been successfully distributed, the Tivoli logfile adapter for
Tivoli Access Manager for Operating Systems will be started automatically.
2. Use the Setup TEC Event Server for PDOS job to set up the event server so
that it can receive and process Tivoli Risk Manager events for Tivoli Access
Manager for Operating Systems.
For more information, see “Setup TEC event server for PDOS” on page 225.
3. If the Tivoli Enterprise Console event server in your environment is running on
a Microsoft Windows system, you must customize the $RMADHOME/etc/riskmgr_baroc.lst file to include the pdosrm.baroc file. Include the pdos.baroc
file also if the event server should process Tivoli Enterprise Console events as
well. Make your changes effective by entering the following commands in a
bash shell from the event server after running this task:
cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdosm.baroc $RMADHOME/etc/baroc/
cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdos.baroc $RMADHOME/etc/baroc/
$RMADHOME/bin/rmcorr_cfg -update
4. Configure and start the pdostecd daemon. See “The pdostecd Tivoli Enterprise
Console daemon” on page 104 for details.
After the Setup TEC Event Server for PDOS job has been successfully executed,
the Tivoli Enterprise Console event console will start receiving Tivoli Access
Manager for Operating Systems events. All the Tivoli Access Manager for
Operating Systems audit events are accessible through the LOGFILE event source.
To stop the Tivoli logfile adapter for Tivoli Access Manager for Operating Systems,
go to the /etc/Tivoli/tecad/pdos/bin directory and run stop_tecad_pdos, or you
362 Administration Guide
can use the Stop TEC Adapter task or job. To restart the logfile adapter, run
start_tecad_config_pdos from the same directory, or you can use the Start TEC
Adapter task or job. The Tivoli logfile adapter for Tivoli Access Manager for
Operating Systems will restart automatically on system reboot.
For more information, see “Start PDOS TEC adapter” on page 233 and “Stop PDOS
TEC adapter” on page 233.
Integrating with Tivoli Data Warehouse
Tivoli Access Manager for Operating Systems Risk Manager events can be
integrated with Tivoli Data Warehouse. You must use the following procedure to
ensure that events are properly integrated into Tivoli Data Warehouse.
1. Complete the procedure described in “Installing and configuring the logfile
adapter to integrate with Tivoli Risk Manager” on page 362.
2. Source the Tivoli Enterprise™ and Tivoli Risk Manager environments:
. /etc/Tivoli/setup_env.sh
and
. /etc/Tivoli/rma_eif_env.sh
3. If the Tivoli Risk Manager agent is running, stop it with the following
command:
$RMADHOME/bin/wrmadmin —k
4. Enter:
cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdosrm.baroc $RMADHOME/etc/baroc
5. Enter:
cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdos.baroc $RMADHOME/etc/baroc
6. Edit the riskmgr_baroc.lst file in the $RMADHOME/etc directory to add the
pdosrm.baroc file to the end of the list of baroc files. Include the pdos.baroc file
also if the event server should process Tivoli Enterprise Console events as well.
7. Run:
$RMADHOME/bin/rmcorr_cfg —update
8. Start the Tivoli Risk Manager agent with the following command:
$RMADHOME/bin/wrmadmin —r
Note: RMADHOME is an environment variable that is set to the installed
location of Tivoli Risk Manager.You might have to restart the Tivoli Enterprise Console event server.
Chapter 10. Integrating with Tivoli Risk Manager 363
364 Administration Guide
Appendix A. Policy quick reference
Table 74. System resources and corresponding Tivoli Access Manager for Operating
Systems resource types
System resource type Tivoli Access Manager for Operating Systems
resource type
File system resources File and RootDir
Network resources NetIncoming and NetOutgoing
Login resources Login
Login/Terminal/Local
Login/Terminal/Remote
Login/Holidays
Surrogate resources Surrogate
Sudo resources Sudo
Trusted Computing Base (TCB)
resources
TCB/Login-Programs
TCB/Secure-Files
TCB/Secure-Programs
TCB/Impersonator-Programs
TCB/Immune-Programs
TCB/Immune-Surrogate-Programs
Password management resources Password
Audit resources AuditAuth and AuditTrace
Table 75. Tivoli Access Manager for Operating Systems permissions defined in the
[OSSEAL] action group
Action
bit Description
Tivoli Access Manager for Operating
Systems resource type
C Connect NetIncoming and NetOutgoing
D Change directory File
G Surrogate Surrogate
K Kill program File
L Login Login
N Create File
R Rename File
U Update timestamp File
d Delete File
l List directory File
o Change ownership File
p Change permission File
r Read File
w Write File
x Execute File and Sudo
© Copyright IBM Corp. 2000, 2005 365
Table 76. Tivoli Access Manager permissions used for policy management defined in the
primary action group
Action bit Description
a Attach an ACL, POP, or authorization rule
b Browse object space and see object names
c Control or modify an ACL
d Delete an object
m Modify the attributes of an object
v View the attributes of an object
Table 77. Tivoli Access Manager permissions used for policy decisions defined in the
primary action group
Action bit Description
B Bypass POP restriction
R Bypass authorization rule restriction
T Traverse
366 Administration Guide
Appendix B. Wildcard character set expressions
The wildcard character set expressions comply with the POSIX Regular Expression
(RE) bracket expression definition. Table 78 summarizes this definition.
Table 78. Special elements of wildcard character set
Character set element Description Examples
^ (circumflex) A circumflex introduces a set
of characters to exclude from
the character set. Characters
following it will not match
the character set. The
circumflex character has this
special meaning only if it is
the first character in the
character set. Otherwise it
simply represents the
circumflex character itself.
[^a-z]
Matches everything, except
lowercase ASCII characters
[ab^]
Matches ’a’, ’b’ or ’^’
] (right bracket) The right bracket character
normally terminates the
character set. When it
appears as the first character
in the character set it
represents the right bracket
character.
[]]
Matches the ’]’ character
[a]]
Is not a valid expression
[.collating-symbol.] q The [..] brackets allow
specification of a collating
symbol that does not consist
of a single character. For
example [.ch.]. If the string
enclosed in the [..] brackets
is not a valid collating
symbol, the expression is
treated as not valid.
[[.ch.]]+c
Matches the string ’chchc’,
but not ’hc’ or ’cc’
[[.qx.]]
Is not a valid expression
[=equivalence-class=] The [= =] brackets allow
specification of a
character-equivalence class.
A character-equivalence class
consists of all matching
characters, independent of
case, umlauts, graves, and so
forth.
[[=a=]]
Matches ’a’, ’A’, ’Å’ and other
A characters
© Copyright IBM Corp. 2000, 2005 367
Table 78. Special elements of wildcard character set (continued)
Character set element Description Examples
[:character-class:] The [::] brackets allow
specification of an entire
class of characters. Valid
character classes are those
characters relevant to the
LC_CTYPE category of the
locale in which policy is
being enforced. The character
classes valid in all locales are
shown in Table 79. Character
classes that are specific to the
locale in which PDOSD is
running are also supported.
[[:digit:]]
Matches any digit
[[:lower:]]
Is equivalent to [a-z] in the
C locale, but will, for
example, include characters
such as the cedilla ( q) in
French-speaking locales.
Table 79. Wildcard character classes valid for all locales
Character class Description Examples
[:alnum:] Alphabetic characters and
decimal digits
’a’, ’A’, ’6’
[:alpha:] Alphabetic characters ’a’, ’A’, ’Z’
[:blank:] Blank characters Space, tab, new line
[:cntrl:] ASCII control characters ’^A’, ’^C’
[:digit:] Decimal digits ’0’, ’1’, ’2’, ’3’
[:graph:] Graphical characters
[:lower:] Lowercase characters ’a’, ’b’, ’c’
[:print:] Printable characters Anything matching
[:alnum:], [:graph:],
[:punct:] or the space
character, and does not
match [:cntrl:]
[:punct:] Punctuation characters ’,’, ’"’
[:space:] White space characters: space
and tab
Space, tab
[:upper:] Uppercase characters ’A’, ’B’, ’C’
[:xdigit:] Hexadecimal digits ’0’, ’3’, ’A’, ’f’
368 Administration Guide
Appendix C. Tivoli Enterprise Console and Tivoli Risk
Manager events
Tivoli Access Manager for Operating Systems uses the Tivoli Enterprise Console
logfile adapter (if installed) to send information about critical UNIX security
system events to security administrators. The adapter formats and forwards events
to Tivoli Enterprise Console. Also, a set of rules and associated actions are defined
for the supported events. This chapter describes the events and associated
information that are sent to Tivoli Enterprise Console by the logfile adapter.
The following Tivoli Access Manager for Operating Systems events are monitored:
v Login (permit, deny, or warning)
v Login deny due to:
– Login disabled
– Login locked
– Login suspendedv Login enabled
v Password change (permit, deny, or warning)
v Logout
v Credential acquired
v Certificate lifetime
v Heartbeat
v Process start (success or failure)
v Process stop (success or failure)
v Process adopt (success or failure)
v Contact lost
v Contact restored
v Register (success or failure)
v User registry server (up or down)
v Set group (deny or warning)
v Trusted Computing Base add (success or failure)
v Trusted Computing Base remove (success or failure)
v Policy (valid or not valid)
v Policy set (success or failure)
v Outgoing network connection (deny or warning)
v Incoming network connection (deny or warning)
v Untrusted program execution (success or failure)
v File access (deny or warning)
v Untrusted file accessed
v User su (permit, deny, or warning)
v User switches groups (success or failure)
v Process Stop Request (success or failure)
v Process Audit Level Change (success or failure)
v Process Warning Mode Change (success or failure)
For information about how to install and configure the Tivoli Enterprise Console
logfile adapter to receive and process Tivoli Access Manager for Operating Systems
events, see Chapter 9, “Integrating with Tivoli Enterprise Console,” on page 357.
For more information about Tivoli Enterprise Console, see the IBM Tivoli Enterprise
Console: User’s Guide.
© Copyright IBM Corp. 2000, 2005 369
Tivoli Enterprise Console events
This section contains tables that provide information about Tivoli Enterprise
Console events. Each table contains the following information:
v The event message
v A description of the message
v The name of the event
v The severity of the event
There is a separate table for each of the following classification of events:
v Process-related events
v File-related events
v Network-related events
v Sudo-related events
v Set(User)-related events
v Set(Group)-related events
v Trusted Computing Base (TCB)-related events
v Policy-related events
v Login-related events
v Credential-related events
v Password strength-related events
Process events
Table 80. Process-related Tivoli Enterprise Console events
Message Description Event name Severity
AMOS Process Started
Successfully. Process:
AMOS_run_srn
A Tivoli Access Manager
for Operating Systems
daemon was successfully
started.
AMOS_ProcessStartSuccess Harmless
AMOS Process Start
Failed. Process:
AMOS_run_srn
An attempt to start a
Tivoli Access Manager
for Operating Systems
daemon was not
successful.
AMOS_ProcessStartFail Critical
AMOS Process Stopped
Successfully. Process:
AMOS_run_srn
A Tivoli Access Manager
for Operating Systems
daemon was successfully
stopped.
AMOS_ProcessStopSuccess Harmless
AMOS Process Stop
Failed. Process:
AMOS_run_srn
An attempt to stop a
Tivoli Access Manager
for Operating Systems
daemon was not
successful.
AMOS_ProcessStopFail Critical
AMOS Process Adopted
Successfully. Process:
AMOS_run_srn
A Tivoli Access Manager
for Operating Systems
daemon was successfully
adopted into the set of
watched processes.
AMOS_ProcessAdoptSuccess Harmless
AMOS Process Adopt
Failed. Process:
AMOS_run_srn
An attempt to adopt a
Tivoli Access Manager
for Operating Systems
daemon into the set of
watched processes was
not successful.
AMOS_ProcessAdoptFail Minor
AMOS Authorization
Decision API Failed.
An authorization API
encountered an
unexpected error.
AMOS_AznApiFailure Warning
370 Administration Guide
Table 80. Process-related Tivoli Enterprise Console events (continued)
Message Description Event name Severity
Kernel lost contact with
pdosd
Communications
between the Tivoli Access
Manager for Operating
Systems kernel service
and the pdosd daemon
have been lost.
Authorization cannot be
enforced.
AMOS_LostContact Critical
Kernel has regained
contact with pdosd.
Communications
between the Tivoli Access
Manager for Operating
Systems kernel service
and the pdosd daemon
have been restored.
AMOS_ContactRestored Warning
A kosseal_register call
was made to acquire
privileged access.
A Tivoli Access Manager
for Operating Systems
process has gained
privileged access.
AMOS_RegisterSuccess Harmless
A kosseal_register call
failed to acquire
privileged access.
A Tivoli Access Manager
for Operating Systems
process was unable to
gain privileged access.
AMOS_RegisterFail Critical
Policy Director user
registry is available.
The Tivoli Access
Manager user registry is
now available. Policy
updates can be
downloaded.
AMOS_LdapServerUp Harmless
Policy Director user
registry is unavailable
(isolation mode).
The Tivoli Access
Manager user registry is
not available. Policy
cannot be updated at this
time.
AMOS_LdapServerDown Minor
AMOS Process Stop
Request Success.
AMOS_acc_name,
AMOS_run_srn
A request to stop a Tivoli
Access Manager daemon
was successful.
AMOS_StopRequestSuccess Warning
AMOS Process Stop
Request Failed.
AMOS_acc_name,
AMOS_run_srn
A request to stop a Tivoli
Access Manager daemon
was not successful.
AMOS_StopRequestFail Warning
AMOS Change Audit
Level Request Success.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global audit level of a
Tivoli Access Manager
daemon was successful.
AMOS_ChangeAuditLevel
Success
Warning
AMOS Change Audit
Level Request Failed.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global audit level of a
Tivoli Access Manager
daemon was not
successful.
AMOS_ChangeAuditLevelFail Warning
AMOS Change Warning
Mode Request Success.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global warning mode of
a Tivoli Access Manager
daemon was successful.
AMOS_ChangeWarningLevel
Success
Warning
AMOS Change Warning
Mode Request Failed.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global warning mode of
a Tivoli Access Manager
daemon was not
successful.
AMOS_ChangeWarningLevelFail Warning
Appendix C. Tivoli Enterprise Console and Tivoli Risk Manager events 371
Table 80. Process-related Tivoli Enterprise Console events (continued)
Message Description Event name Severity
A call was made to check
the lifetime of the
certificate. AMOS_srn,
AMOS_ap
Notification of the
lifetime of the certificate.
Action needs to be taken
to refresh the certificate
before its expiration.
AMOS_CertLife Warning
A heartbeat event was
logged
Notification of a
heartbeat event. The
heartbeat numeric
identifier and the
heartbeat time interval
are recorded in the
additional parameters.
AMOS_Heartbeat Harmless
File events
Table 81. File-related Tivoli Enterprise Console events
Message Description Event name Severity
Failed File Access. File
AMOS_acc_name
Program: AMOS_run_srn
Action: AMOS_permission
Access to a file was
denied.
AMOS_FileAccessDeny Warning
Warning File Access. File
AMOS_acc_name
Program: AMOS_run_srn
Action: AMOS_permission
Access to a file was
allowed only because
policy is set to warn
instead of deny.
AMOS_FileAccessWarning Warning
Network events
Table 82. Network-related Tivoli Enterprise Console events
Message Description Event name Severity
Failed Incoming Network
Connection. From Host:
AMOS_ipaddress Services:
AMOS_port
Access to an incoming
network connection was
denied.
AMOS_IncomingNetConnDeny Warning
Warning Incoming
Network Connection.
From Host:
AMOS_ipaddress Services:
AMOS_port
Access to an incoming
network connection was
allowed only because
policy is set to warn
instead of deny.
AMOS_IncomingNetConn
Warning
Warning
Failed Outgoing Network
Connection. To Host:
AMOS_ipaddress User:
AMOS_acc_name
Program: AMOS_run_srn
Access to an outgoing
network connection was
denied.
AMOS_OutgoingNetConnDeny Warning
Warning Outgoing
Network Connection. To
Host: AMOS_ipaddress
User: AMOS_acc_name
Program: AMOS_run_srn
Access to an outgoing
network connection was
allowed only because
policy is set to warn
instead of deny.
AMOS_OutgoingNetConn
Warning
Warning
372 Administration Guide
Sudo events
Table 83. Sudo-related Tivoli Enterprise Console events
Message Description Event name Severity
Successful Sudo
operation. User:
AMOS_acc_name
Program: AMOS_exe
Sudo operation was
successful.
AMOS_SudoPermit Harmless
Failed Sudo operation.
User: AMOS_acc_name
Program: AMOS_exe
Sudo operation was
unsuccessful.
AMOS_SudoDeny Warning
Warning Sudo operation.
User: AMOS_acc_name
Program: AMOS_exe
Sudo operation was
allowed only because
policy is set to warn
instead of deny.
AMOS_SudoWarning Warning
User set events
Table 84. Set(User)-related Tivoli Enterprise Console events
Message Description Event name Severity
Failed Substitution to
User. To User:
AMOS_sname From User:
AMOS_acc_name
Program: AMOS_run_srn
Substitute user failed. AMOS_SetUserDeny Harmless
Warning Substitution to
User. To User:
AMOS_sname From User:
AMOS_acc_name
Program: AMOS_run_srn
Substitute user was
allowed only because
policy is set to warn
instead of deny.
AMOS_SetUserWarning Warning
Group set events
Table 85. Set(Group)-related Tivoli Enterprise Console events
Message Description Event name Severity
Failed Substitution to
Group. To Group:
AMOS_sname From User:
AMOS_acc_name
Program: AMOS_run_srn
Substitute group failed. AMOS_SetGroupDeny Harmless
Warning Substitution to
Group. To Group:
AMOS_sname From User:
AMOS_acc_name
Program: AMOS_run_srn
Substitute group was
allowed only because
policy is set to warn
instead of deny.
AMOS_SetGroupWarning Warning
TCB events
Table 86. TCB-related Tivoli Enterprise Console events
Message Description Event name Severity
Access allowed to
untrusted file. File:
AMOS_srn User:
AMOS_acc_name
Program: AMOS_run_srn
Access to an untrusted
file was allowed.
AMOS_AccessUntrust Minor
Appendix C. Tivoli Enterprise Console and Tivoli Risk Manager events 373
Table 86. TCB-related Tivoli Enterprise Console events (continued)
Message Description Event name Severity
Access allowed to a TCB
file in an unknown state.
File: AMOS_srn User:
AMOS_acc_name
Program: AMOS_run_srn
Access to a Trusted
Computing Base (TCB)
file in an unknown trust
state was allowed.
AMOS_AccessUnknownTrust
State
Warning
A file has been marked
trusted. File: AMOS_srn
User: AMOS_acc_name
A file has been
successfuly marked as
trusted.
AMOS_TrustSuccess Harmless
AMOS failed to mark a
file trusted. File:
AMOS_srn User:
AMOS_acc_name
Fail_Status:
AMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to mark a file
trusted.
AMOS_TrustFail Warning
A file has been marked
untrusted. File:
AMOS_srn User:
AMOS_acc_name Reason:
AMOS_cdata
Tivoli Access Manager
for Operating Systems
was marked a file as
untrusted.
AMOS_UntrustSuccess Warning
AMOS failed to mark a
file untrusted. File:
AMOS_srn User:
AMOS_acc_name Reason:
AMOS_cdata Fail_Status:
AMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to mark a file
untrusted.
AMOS_UntrustFail Warning
New file added to TCB
database. File: AMOS_srn
User: AMOS_acc_name
A file has been
successfully added to the
Trusted Computing Base
(TCB) database.
AMOS_TcbAddSuccess Harmless
AMOS failed to add new
file to TCB database. File:
AMOS_srn User:
AMOS_acc_name
Fail_Status:
AMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to add a file
to the Trusted
Computing Base (TCB)
database.
AMOS_TcbAddFail Warning
File removed from TCB
database. File: AMOS_srn
User: AMOS_acc_name
A file has been
successfully removed
from the Trusted
Computing Base (TCB)
database.
AMOS_TcbRemoveSuccess Warning
AMOS failed to remove a
file from TCB database.
File: AMOS_srn User:
AMOS_acc_name
Fail_Status:
AMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to remove a
file from the Trusted
Computing Base (TCB)
database.
AMOS_TcbRemoveFail Warning
Policy events
Table 87. Policy-related Tivoli Enterprise Console events
Message Description Event name Severity
Policy applied for a
protected object name.
Name: AMOS_pon
The policy was
successfully applied to
the protected object
name.
AMOS_PolicyValid Harmless
374 Administration Guide
Table 87. Policy-related Tivoli Enterprise Console events (continued)
Message Description Event name Severity
Policy not applied for
an invalid protected
object name. Name:
AMOS_pon
When processing the
policy update, a policy
that is not valid was
detected.
AMOS_PolicyInvalid Warning
Policy version set in
Kernel Policy Cache.
The policy update was
processed.
AMOS_PolicySetSuccess Warning
Failed to set policy
version in Kernel
Policy Cache.
The policy update
failed to be processed.
AMOS_PolicySetFail Warning
Login events
Table 88. Login-related Tivoli Enterprise Console events
Message Description Event name Severity
Login successful. User:
AMOS_acc_name From
Host:
AMOS_login_location
Program: AMOS_exe
User login permitted. AMOS_LoginPermit Harmless
Login Failed. User:
AMOS_acc_name From
Host:
AMOS_login_location
Program: AMOS_run_srn
Reason: AMOS_qualifier
User login was denied. AMOS_LoginDeny Warning
Login Warning. User:
AMOS_acc_name From
Host:
AMOS_login_location
Program: AMOS_run_srn
Reason: AMOS_qualifier
User login was allowed
only because policy is set
to warn instead of deny.
AMOS_LoginWarning Warning
User Account AMOS_srn
enabled for login.
The specified user
account was enabled for
login.
AMOS_LoginEnabled Warning
User Account AMOS_srn
disabled for login.
The specified user
account has been
disabled for login.
AMOS_LoginDisabled Warning
User Account AMOS_srn
locked for login.
The specified user
account has been locked
for login.
AMOS_LoginLocked Warning
User Account AMOS_srn
suspended for login.
The specified user
account has been
suspended for login.
AMOS_LoginSuspended Warning
Password change time
was modified by
administrator. User:
AMOS_acc_name
The password change
time associated with this
user account has been
changed by the
administrator.
AMOS_LoginAdm Warning
Password successfully
changed. User:
AMOS_srn
The password associated
with this user account
has been changed.
AMOS_LoginPwdChange Warning
Logout occurred. User:
AMOS_acc_name
Location:
AMOS_login_location
The specified user has
logged off.
AMOS_Logout Harmless
Appendix C. Tivoli Enterprise Console and Tivoli Risk Manager events 375
Credential events
Table 89. Credential-related Tivoli Enterprise Console events
Message Description Event name Severity
Obtained credential.
User: AMOS_acc_name
Credential successfully
obtained.
AMOS_GetCredSuccess Harmless
Failed to obtain
credential. User:
AMOS_acc_name
Tivoli Access Manager
for Operating Systems
was unable to obtain
credential.
AMOS_GetCredFail Warning
Password strength events
Table 90. Password strength-related Tivoli Enterprise Console events
Message Description Event name Severity
Password-change-related
authorization decision
was made. User:
AMOS_acc_name
A password change
request was allowed.
AMOS_PasswordChgPermit Harmless
Password-change-related
authorization decision
was denied. User:
AMOS_acc_name
A password change
request was not allowed.
AMOS_PasswordChgDeny Warning
Password-change-related
authorization was
made.AMOS_acc_name
A password change was
allowed only because
policy is set to warn
instead of deny.
AMOS_PasswordChgWarning Warning
Tivoli Risk Manager events
This section contains tables that provide information about Tivoli Risk Manager
events. Each table contains the following information:
v The event message
v A description of the message
v The name of the event
v The severity of the event
There is a separate table for each of the following classification of events:
v Process-related events
v File-related events
v Network-related events
v Sudo-related events
v Set(User)-related events
v Set(Group)-related events
v Trusted Computing Base (TCB)-related events
v Policy-related events
v Login-related events
v Credential-related events
v Password strength-related events
376 Administration Guide
Process events
Table 91. Process-related Tivoli Risk Manager events
Message Description Event name Severity
PDOS Process Started
Successfully. Process:
RMAMOS_run_srn
A Tivoli Access Manager
for Operating Systems
daemon was successfully
started.
RMAMOS_ProcessStartSuccess Harmless
PDOS Process Start
Failed. Process:
RMAMOS_run_srn
An attempt to start a
Tivoli Access Manager
for Operating Systems
daemon was not
successful.
RMAMOS_ProcessStartFail Critical
PDOS Process Stopped
Successfully. Process:
RMAMOS_run_srn
A Tivoli Access Manager
for Operating Systems
daemon was successfully
stopped.
RMAMOS_ProcessStopSuccess Harmless
PDOS Process Stop
Failed. Process:
RMAMOS_run_srn
An attempt to stop a
Tivoli Access Manager
for Operating Systems
daemon was not
successful.
RMAMOS_ProcessStopFail Critical
PDOS Process Adopted
Successfully. Process:
RMAMOS_run_srn
A Tivoli Access Manager
for Operating Systems
daemon was successfully
adopted into the set of
watched processes.
RMAMOS_ProcessAdoptSuccess Harmless
PDOS Process Adopt
Failed. Process:
RMAMOS_run_srn
An attempt to adopt a
Tivoli Access Manager
for Operating Systems
daemon into the set of
watched processes was
not successful.
RMAMOS_ProcessAdoptFail Minor
PDOS Authorization
Decision API Failed.
An authorization API
encountered an
unexpected error.
RMAMOS_AznApiFailure Warning
Kernel lost contact with
pdosd
Communications
between the Tivoli Access
Manager for Operating
Systems kernel service
and the pdosd daemon
have been lost.
Authorization cannot be
enforced.
RMAMOS_LostContact Critical
Kernel has regained
contact with pdosd.
Communications
between the Tivoli Access
Manager for Operating
Systems kernel service
and the pdosd daemon
have been restored.
RMAMOS_ContactRestored Warning
A kosseal_register call
was made to acquire
privileged access.
A Tivoli Access Manager
for Operating Systems
process has gained
privileged access.
RMAMOS_RegisterSuccess Harmless
A kosseal_register call
failed to acquire
privileged access.
A Tivoli Access Manager
for Operating Systems
process was unable to
gain privileged access.
RMAMOS_RegisterFail Critical
Appendix C. Tivoli Enterprise Console and Tivoli Risk Manager events 377
Table 91. Process-related Tivoli Risk Manager events (continued)
Message Description Event name Severity
Policy Director user
registry is available.
The Tivoli Access
Manager user registry is
now available. Policy
updates can be
downloaded.
RMAMOS_LdapServerUp Harmless
Policy Director user
registry is unavailable
(isolation mode).
The Tivoli Access
Manager user registry is
not available. Policy
cannot be updated at this
time.
RMAMOS_LdapServerDown Minor
AMOS Process Stop
Request Success.
AMOS_acc_name,
AMOS_run_srn
A request to stop a Tivoli
Access Manager daemon
was successful.
RMAMOS_StopRequestSuccess Warning
AMOS Process Stop
Request Failed.
AMOS_acc_name,
AMOS_run_srn
A request to stop a Tivoli
Access Manager daemon
was not successful.
RMAMOS_StopRequestFail Warning
AMOS Change Audit
Level Request Success.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global audit level of a
Tivoli Access Manager
daemon was successful.
RMAMOS_ChangeAuditLevel
Success
Warning
AMOS Change Audit
Level Request Failed.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global audit level of a
Tivoli Access Manager
daemon was not
successful.
RMAMOS_ChangeAuditLevelFail Warning
AMOS Change Warning
Mode Request Success.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global warning mode of
a Tivoli Access Manager
daemon was successful.
RMAMOS_ChangeWarningLevel
Success
Warning
AMOS Change Warning
Mode Request Failed.
AMOS_acc_name,
AMOS_run_srn
A request to change the
global warning mode of
a Tivoli Access Manager
daemon was not
successful.
RMAMOS_ChangeWarningLevel
Fail
Warning
A call was made to check
the lifetime of the
certificate. AMOS_srn,
AMOS_ap
Notification of the
lifetime of the certificate.
Action needs to be taken
to refresh the certificate
before its expiration.
AMOS_CertLife Warning
File events
Table 92. File-related Tivoli Risk Manager events
Message Description Event name Severity
Failed File Access. File
RMAMOS_srn User:
RMAMOS_acc_name
Program:
RMAMOS_run_srn
Action:
RMAMOS_permissions
Access to a file was
denied.
RMAMOS_FileAccessDeny Warning
378 Administration Guide
Table 92. File-related Tivoli Risk Manager events (continued)
Message Description Event name Severity
Warning File Access. File
RMAMOS_srn User:
RMAMOS_acc_name
Program:
RMAMOS_run_srn
Action:
RMAMOS_permissions
Access to a file was
allowed only because
policy is set to warn
instead of deny.
RMAMOS_FileAccessWarning Warning
Network events
Table 93. Network-related Tivoli Risk Manager events
Message Description Event name Severity
Failed Incoming Network
Connection. From Host:
RMAMOS_ipaddress
Services: RMAMOS_port
Access to an incoming
network connection was
denied.
RMAMOS_IncomingNetConn
Deny
Warning
Warning Incoming
Network Connection.
From Host:
RMAMOS_ipaddress
Services: AMOS_port
Access to an incoming
network connection was
allowed only because
policy is set to warn
instead of deny.
RMAMOS_IncomingNetConn
Warning
Warning
Failed Outgoing Network
Connection. To Host:
RMAMOS_ipaddress User:
RMAMOS_acc_name
Program:
RMAMOS_run_srn
Access to an outgoing
network connection was
denied.
RMAMOS_OutgoingNetConn
Deny
Warning
Warning Outgoing
Network Connection. To
Host: RMAMOS_ipaddress
User:
RMAMOS_acc_name
Program:
RMAMOS_run_srn
Access to an outgoing
network connection was
allowed only because
policy is set to warn
instead of deny.
RMAMOS_OutgoingNetConn
Warning
Warning
Sudo events
Table 94. Sudo-related Tivoli Risk Manager events
Message Description Event name Severity
Successful Sudo
operation. User:
RMAMOS_acc_name
Program: RMAMOS_exe
Sudo operation was
successful.
RMAMOS_SudoPermit Harmless
Failed Sudo operation.
User:
RMAMOS_acc_name
Program: RMAMOS_exe
Sudo operation was
unsuccessful.
RMAMOS_SudoDeny Warning
Warning Sudo operation.
User:
RMAMOS_acc_name
Program: RMAMOS_exe
Sudo operation was
allowed only because
policy is set to warn
instead of deny.
RMAMOS_SudoWarning Warning
Appendix C. Tivoli Enterprise Console and Tivoli Risk Manager events 379
User set events
Table 95. Set(User)-related Tivoli Risk Manager events
Message Description Event name Severity
Failed Substitution to
User. To User:
RMAMOS_sname From
User:
RMAMOS_acc_name
Program: RMAMOS_exe
Substitute user failed. RMAMOS_SetUserDeny Harmless
Warning Substitution to
User. To User:
RMAMOS_sname From
User:
RMAMOS_acc_name
Program: RMAMOS_exe
Substitute user was
allowed only because
policy is set to warn
instead of deny.
RMAMOS_SetUserWarning Warning
Group set events
Table 96. Set(Group)-related Tivoli Risk Manager events
Message Description Event name Severity
Failed Substitution to
Group. To Group:
RMAMOS_sname From
User:
RMAMOS_acc_name
Program: RMAMOS_exe
Substitute group failed. RMAMOS_SetGroupDeny Harmless
Warning Substitution to
Group. To Group:
RMAMOS_sname From
User:
RMAMOS_acc_name
Program: RMAMOS_exe
Substitute group was
allowed only because
policy is set to warn
instead of deny.
RMAMOS_SetGroupWarning Warning
TCB events
Table 97. TCB-Related Tivoli Risk Manager events
Message Description Event name Severity
Access allowed to
untrusted file. File:
RMAMOS_srn User:
RMAMOS_acc_name
Program: RMAMOS_exe
Access to an untrusted
file was allowed.
RMAMOS_AccessUntrust Minor
Access allowed to a TCB
file in an unknown state.
File: RMAMOS_srn User:
RMAMOS_acc_name
Program: RMAMOS_exe
Access to a Trusted
Computing Base (TCB)
file in an unknown trust
state was allowed.
RMAMOS_AccessUnknownTrust
State
Warning
A file has been marked
trusted. File:
RMAMOS_srn User:
RMAMOS_acc_name
Program: RMAMOS_exe
A file has been
successfuly marked as
trusted.
RMAMOS_TrustSuccess Harmless
380 Administration Guide
Table 97. TCB-Related Tivoli Risk Manager events (continued)
Message Description Event name Severity
PDOS failed to mark a
file trusted. File:
RMAMOS_srn User:
RMAMOS_acc_name
Program: RMAMOS_exe
Fail_Status:
RMAMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to mark a file
trusted.
RMAMOS_TrustFail Warning
A file has been marked
untrusted. File:
RMAMOS_srn User:
RMAMOS_acc_name
Program: RMAMOS_exe
Tivoli Access Manager
for Operating Systems
was marked a file as
untrusted.
RMAMOS_UntrustSuccess Warning
PDOS failed to mark a
file untrusted. File:
RMAMOS_srn User:
RMAMOS_acc_name
Program: RMAMOS_exe
Fail_Status:
RMAMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to mark a file
untrusted.
RMAMOS_UntrustFail Warning
New file added to TCB
database. File:
RMAMOS_srn User:
RMAMOS_acc_name
A file has been
successfully added to the
Trusted Computing Base
(TCB) database.
RMAMOS_TcbAddSuccess Harmless
AMOS failed to add new
file to TCB database. File:
RMAMOS_srn User:
RMAMOS_acc_name
Fail_Status:
RMAMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to add a file
to the Trusted
Computing Base (TCB)
database.
RMAMOS_TcbAddFail Warning
File removed from TCB
database. File:
RMAMOS_srn User:
RMAMOS_acc_name
A file has been
successfully removed
from the Trusted
Computing Base (TCB)
database.
RMAMOS_TcbRemoveSuccess Warning
PDOS failed to remove a
file from TCB database.
File: RMAMOS_srn User:
RMAMOS_acc_name
Fail_Status:
RMAMOS_fail_status
Tivoli Access Manager
for Operating Systems
was unable to remove a
file from the Trusted
Computing Base (TCB)
database.
RMAMOS_TcbRemoveFail Warning
Policy events
Table 98. Policy-related Tivoli Risk Manager events
Message Description Event name Severity
Policy applied for a
protected object name.
Name: RMAMOS_pon
The policy was
successfully applied to
the protected object
name.
RMAMOS_PolicyValid Harmless
Policy not applied for an
invalid protected object
name. Name:
RMAMOS_pon
When processing the
policy update, a policy
that is not valid was
detected.
RMAMOS_PolicyInvalid Warning
Policy kernel version set
in Kernel Policy Cache.
The policy update was
processed.
RMAMOS_PolicySetSuccess Warning
Failed to set policy
version in Kernel Policy
Cache.
The policy update failed
to be processed.
RMAMOS_PolicySetFail Warning
Appendix C. Tivoli Enterprise Console and Tivoli Risk Manager events 381
Login events
Table 99. Login-related Tivoli Risk Manager events
Message Description Event name Severity
Login successful. User:
RMAMOS_acc_name
From Host:
RMAMOS_login_location
Program:
RMAMOS_run_srn
User login permitted. RMAMOS_LoginPermit Harmless
Login Failed. User:
RMAMOS_acc_name
From Host:
RMAMOS_login_location
Program: RMAMOS_exe
Reason:
RMAMOS_qualifier
User login was denied. RMAMOS_LoginDeny Warning
Login Warning. User:
RMAMOS_acc_name
From Host:
RMAMOS_login_location
Program:
RMAMOS_run_srn
Reason:
RMAMOS_qualifier
User login was allowed
only because policy is set
to warn instead of deny.
RMAMOS_LoginWarning Warning
User Account
RMAMOS_srn enabled
for login.
The specified user
account was enabled for
login.
RMAMOS_LoginEnabled Warning
User Account
RMAMOS_srn disabled
for login.
The specified user
account has been
disabled for login.
RMAMOS_LoginDisabled Warning
User Account
RMAMOS_srn locked for
login.
The specified user
account has been locked
for login.
RMAMOS_LoginLocked Warning
User Account
RMAMOS_srn suspended
for login.
The specified user
account has been
suspended for login.
RMAMOS_LoginSuspended Warning
Password change time
was modified by
administrator. User:
RMAMOS_srn
The password change
time associated with this
user account has been
changed by the
administrator.
RMAMOS_LoginAdm Warning
Password successfully
changed. User:
RMAMOS_acc_name
The password associated
with this user account
has been changed.
RMAMOS_LoginPwdChange Warning
Logout occurred. User:
RMAMOS_acc_name
The specified user has
logged off.
RMAMOS_Logout Harmless
Credential events
Table 100. Credential-related Tivoli Risk Manager events
Message Description Event name Severity
Obtained credential.
User:
RMAMOS_acc_name
Credential successfully
obtained.
RMAMOS_GetCredSuccess Harmless
Failed to obtain
credential. User:
RMAMOS_acc_name
Tivoli Access Manager
for Operating Systems
was unable to obtain
credential.
RMAMOS_GetCredFail Warning
382 Administration Guide
Password strength events
Table 101. Password strength-related Tivoli Risk Manager events
Message Description Event name Severity
Password-change-related
authorization decision
was made. User:
RMAMOS_acc_name
A password change
request was allowed.
RMAMOS_PasswordChgPermit Harmless
Password-change-related
authorization decision
was denied. User:
RMAMOS_acc_name
A password change
request was not allowed.
RMAMOS_PasswordChgDeny Warning
Password-change-related
authorization was made.
RMAMOS_acc_name
A password change was
allowed only because
policy is set to warn
instead of deny.
RMAMOS_PasswordChgWarning Warning
Appendix C. Tivoli Enterprise Console and Tivoli Risk Manager events 383
384 Administration Guide
Appendix D. Accessibility
Tivoli Access Manager for Operating Systems is accessed primarily through a
command line interface, so all interaction with the product is through the
keyboard.
If you install the Tivoli Access Manager for Operating Systems Management Tasks
component, you gain of the option of performing administrative tasks from the
Tivoli desktop, which features a graphical interface. For information about the
accessibility features of the Tivoli desktop, consult the Tivoli Management
Framework documentation.
The only other exception is the optional installation wizard, which features a short
series of graphical screens to accomplish production installation. Tivoli Access
Manager for Operating Systems can be installed through utilities that are native to
each of the supported platforms.
The Tivoli Access Manager for Operating Systems library is available in both
Portable Document Format (PDF) and HTML format. All the documentation is
available at the following Web address:
http://www.ibm.com/software/tivoli/library/.
© Copyright IBM Corp. 2000, 2005 385
386 Administration Guide
Appendix E. Support information
This section describes the following options for obtaining support for IBM
products:
v “Searching knowledge bases”
v “Obtaining fixes”
v “Registering with IBM Software Support” on page 388
v “Receiving weekly software updates” on page 388
v “Contacting IBM Software Support” on page 389
Searching knowledge bases
If you encounter a problem, you want it resolved quickly. You can search the
available knowledge bases to determine whether the resolution to your problem
was already encountered and is already documented.
Searching information centers
IBM provides extensive documentation in an information center that can be
installed on your local computer or on an intranet server. You can use the search
function of this information center to query conceptual information, instructions
for completing tasks, reference information, and support documents.
Searching the Internet
If you cannot find an answer to your question in the information center, search the
Internet for the latest, most complete information that might help you resolve your
problem. To search multiple Internet resources for your product, perform the
following steps:
1. Expand the product folder in the navigation frame on the left.
2. Expand Troubleshooting and support.
3. Expand Searching knowledge bases.
4. Click Web search.
From this topic, you can search a variety of resources, which includes the
following resources:
v IBM Technotes
v IBM downloads
v IBM Redbooks
v IBM developerWorks®
v Forums and news groups
v Google
Obtaining fixes
A product fix might be available to resolve your problem. To determine what fixes
are available for your IBM software product, check the product support site by
performing the following steps:
1. Go to the IBM Software Support site at the following Web address:
© Copyright IBM Corp. 2000, 2005 387
http://www.ibm.com/software/support2. Under Products A - Z, click the letter with which your product starts to open a
Software Product List.
3. Click your product name to open the product-specific support page.
4. Under Self help, follow the link to All Updates, where you will find a list of
fixes, fix packs, and other service updates for your product. For tips on refining
your search, click Search tips.
5. Click the name of a fix to read the description.
6. Optional, download the fix.
Registering with IBM Software Support
Before you can receive weekly e-mail updates about fixes and other news about
IBM products, you need to register with IBM Software Support. To register with
IBM Software Support, follow these steps:
1. Go to the IBM Software Support site at the following Web address:
http://www.ibm.com/software/support2. Click Register in the upper right-hand corner of the support page to establish
your user ID and password.
3. Complete the form, and click Submit.
Receiving weekly software updates
After registering with IBM Software Support, you can receive weekly e-mail
updates about fixes and other news about IBM products. To receive weekly
notifications, follow these steps:
1. Go to the IBM Software Support site at the following Web address
http://www.ibm.com/software/support2. Click the My support link to open the Sign in page.
3. Provide your sign in information, and click Submit to open your support page.
4. Click the Edit profile tab.
5. For each product about which you want to receive updates, use the filters to
choose your exact interests, and click Add products.
6. Repeat step 5 for each additional product.
7. After choosing all your products, click the Subscribe to email link.
8. For each product category, use the filters and choose which updates you want
to receive, and click Update.
9. Repeat step 8 for each additional product category.
For more information about the types of fixes that are available, see the IBM
Software Support Handbook at the following Web address:
http://techsupport.services.ibm.com/guides/handbook.html
388 Administration Guide
Contacting IBM Software Support
IBM Software Support provides assistance with product defects. Before contacting
IBM Software Support, the following criteria must be met:
v Your company has an active IBM software maintenance contract.
v You are authorized to submit problems to IBM Software Support.
The type of software maintenance contract that you need depends on the type of
product that you have. Product types are one of the following categories:
v For IBM distributed software products (including, but not limited to, Tivoli,
Lotus®, and Rational® products, as well as DB2® and WebSphere products that
run on Windows, Linux, or UNIX operating systems), enroll in Passport
Advantage® in one of the following ways:
Online
Go to the IBM Software Passport Advantage site at the following Web
address and click How to Enroll:
http://www.lotus.com/services/passport.nsf/
WebDocs/Passport_Advantage_Home
By phone
For the phone number to call in your country, go to the IBM Software
Support site at the following Web address and click the name of your
geographic region:
http://techsupport.services.ibm.com/guides/contacts.htmlv For IBM eServer™ software products (including, but not limited to, DB2 and
WebSphere® products that run in zSeries®, POWER™, pSeries®, and iSeries™
environments), you can purchase a software maintenance agreement by working
directly with an IBM sales representative or an IBM Business Partner. For more
information about support for eServer software products, go to the IBM eServer
Technical Support Advantage site at the following Web address:
http://www.ibm.com/servers/eserver/techsupport.html
If you are not sure what type of software maintenance contract you need, call
1-800-IBMSERV (1-800-426-7378) in the United States or, from other countries, go to
the contacts page of the IBM Software Support Handbook at the following Web
address and click the name of your geographic region for phone numbers of
people who provide support for your location:
http://techsupport.services.ibm.com/guides/contacts.html
To contact IBM Software support, follow these steps:
1. “Determining the business impact”
2. “Describing problems and gathering information” on page 390
3. “Submitting problems” on page 390
Determining the business impact
When you report a problem to IBM, you are asked to supply a severity level.
Therefore, you need to understand and assess the business impact of the problem
that you are reporting. Use the following severity criteria:
Appendix E. Support information 389
Severity 1
The problem has a critical business impact. You are unable to use the
program, resulting in a critical impact on operations. This condition
requires an immediate solution.
Severity 2
The problem has a significant business impact. The program is usable, but
it is severely limited.
Severity 3
The problem has some business impact. The program is usable, but less
significant features that are not critical are unavailable.
Severity 4
The problem has minimal business impact. The problem causes little impact
on operations, or a reasonable circumvention to the problem was
implemented.
Describing problems and gathering information
When explaining a problem to IBM, be as specific as possible. Include all relevant
background information so that IBM Software Support specialists can help you
solve the problem efficiently. To save time, know the answers to these questions:
v What software versions were you running when the problem occurred?
v Do you have logs, traces, and messages that are related to the problem
symptoms? IBM Software Support is likely to ask for this information.
v Can you create the problem again? If so, what steps were performed to
encounter the problem?
v Was any change made to the system? For example, were there changes to the
hardware, operating system, networking software, and so on.
v Are you currently using a workaround for this problem? If so, please be
prepared to explain it when you report the problem.
Submitting problems
You can submit your problem to IBM Software Support in one of two ways:
Online
Go to the Submit and track problems page on the IBM Software Support
site at the following address, and provide your information into the
appropriate problem submission tool:
http://www.ibm.com/software/support/probsub.html
By phone
For the phone number to call in your country, go to the contacts page of
the IBM Software Support Handbook at the following Web address and click
the name of your geographic region:
http://techsupport.services.ibm.com/guides/contacts.html
If the problem you submit is for a software defect or for missing or inaccurate
documentation, IBM Software Support creates an Authorized Program Analysis
Report (APAR). The APAR describes the problem in detail. Whenever possible,
IBM Software Support provides a workaround that you can implement until the
APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the
IBM product support Web pages daily, so that other users who experience the
same problem can benefit from the same resolution.
390 Administration Guide
For more information about problem resolution, see “Searching knowledge bases”
on page 387 and “Obtaining fixes” on page 387.
Appendix E. Support information 391
392 Administration Guide
Appendix F. Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement might not apply
to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
© Copyright IBM Corp. 2000, 2005 393
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
Such information may be available, subject to appropriate terms and conditions,
including in some cases payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM’s future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
Trademarks
The IBM, IBM logo, AIX, DB2, developerWorks, iSeries, Lotus, Passport Advantage,
POWER, Rational, Redbooks, SecureWay, Tivoli, Tivoli logo, Tivoli Enterprise,
Tivoli Enterprise Console, Tivoli Management Environment, WebSphere, xSeries,
and zSeries are trademarks of International Business Machines Corporation in the
United States, other countries, or both.
Lotus is a trademarks of International Business Machines Corporation and Lotus
Development Corporation in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are registered
trademarks of Microsoft Corporation in the United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or
both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
394 Administration Guide
Other company, product, and service names may be trademarks or service marks
of others.
Appendix F. Notices 395
396 Administration Guide
Index
Special characters.rhosts file 54
Aaccess control
File system resources 28
Login objects 54
network resource 49
root directory 30
surrogate resources 64
access control lists 14
access controls 13
access restriction 17
evaluation 20
examples 22
accessibility 385
accessor identitydetermining 165
processes 165
users 165
accessor identity and the UNIX identity
differences 166
ACL 14
administrative activityauditing 239
administrative tasksbacking up and restoring
configuration files and
databases 168
configuring and managing the host
name lookaside database 167
defining runtime administrators and
auditors 141
establishing a consistent user name
space 142
limiting ACL inheritance for network
policy 148
managing credentials 163
managing login activity and password
management policy
enforcement 160
managing processes 149
tuning the configuration 146
administratorsadding 178
removing 178
showing 229
auditadministrative activity 239
authorization decisions 237
global audit levels 241
audit authorization resources 70
example 71
audit authorization usageexample 72
audit configurationshowing 228
audit daemon 100
audit event record typegeneral 257
audit health, configuring 185
audit levelserver
setting 220
showing 231
audit logconsolidation 252
record types 257
audit log record types 257
audit logsfiles 251
formats 253
viewing 253
audit record formatconcise 254
key-value 254
verbose 255
audit recordscertificate lifetime
controlling 250
enabling 249
heartbeatcontrolling 250
enabling 249
audit resources 70
audit trace resources 72
example 73
audit view tool 253
auditingenabling 241
resource-level 244
trace events 239
user-level 246
auditing trace events 239
auditor 110
auditorsadding 178
removing 178
showing 229
authenticationremote authentication limitations 2
authentication model 2
authorization daemon 90
authorization decision process 95
authorization decisionsauditing 237
authorization model 2
authorization policy 4
authorization rolesfor tasks 175
Bbacking up configuration files and
databases 168
branch membershipquerying 213
Ccaching configuration
showing 230
certificate expiration threshold 250
certificate lifetime audit recordscontrolling 250
enabling 249
certificationtransferring 183
channel typesLRD_AuditInput 130
LRD_EmailOutput 131
LRD_FileOutput 131
LRD_NetOutput 132
checking daemon status 151
commandpdossudo 68
commandspdosaudview 270
pdosbkup 275
pdosbranchcfg 277
pdoscfg 280
pdoscollview 292
pdosctl 297
pdosdestroy 302
pdosent 303
pdosexempt 306
pdoshla 308
pdoslpadm 313
pdoslpinf 311
pdoslradm 318
pdosobjsig 319
pdosrefresh 322
pdosrespolicy 324
pdosrevoke 326
pdosrgyimp 328
pdosrstr 333
pdosshowuser 334
pdossudo 337
pdosteccfg 338
pdostecucfg 341
pdosucfg 343
pdosuidprog 345
pdosunauth 348
pdosversion 349
pdoswhoami 350
pdoswhois 352
policyview 354
wrunjob 178
wruntask 178
wschedjob 178
common problemsreporting
describing problem 390
determining business impact 389
gathering information 390
submitting problems 390
concise format 254
configurationpolicy branches
adding branches 145
© Copyright IBM Corp. 2000, 2005 397
configuration (continued)policy branches (continued)
changing precedence order 145
deleting branches 145
listing branches 145
listing precedence order 145
tuning 146
configuration filesbacking up 168
restoring 169
configuring the host name lookaside
database 167
considerations for establishing surrogate
policy 63
controlling access 13
credential acquisition 90
credential acquisition and user type 91
credential cachemanaging 208
credential-related eventsTivoli Enterprise Console 376
Tivoli Risk Manager 382
credentialsexplicitly destroying 164
explicitly refreshing 164
managing 163
credentials cachetuning 163
critical users group 111
customer supportcontacting 389
obtaining fixes 387
receiving updates from 388
registering with 388
searching information centers 387
searching knowledge bases 387
searching the Internet 387
submitting problems 390
DD (chdir) ACL
Linux with 2.6 kernel 32
policy enforcement 32
d (delete) ACLLinux with 2.6 kernel 32
policy enforcement 32
daemonchecking status 151
pdosauditd 100
pdosd 90
pdoslpmd 105
pdoslrd 107
pdostecd 104
pdoswdd 102
daemon log files 151
daemonsfunctions 89
databasehost name lookaside 167
databases 1
backing up 168
restoring 169
device files 35
domain 7
Eenabling auditing 241
endpointssubscribing 233
environment 1
eventscredential-related
Tivoli Enterprise Console 376
Tivoli Risk Manager 382
descriptions 369
file-relatedTivoli Enterprise Console 372
Tivoli Risk Manager 378
login-relatedTivoli Enterprise Console 375
Tivoli Risk Manager 382
network-relatedTivoli Enterprise Console 372
Tivoli Risk Manager 379
password strength-relatedTivoli Enterprise Console 376
Tivoli Risk Manager 383
policy-relatedTivoli Enterprise Console 374
Tivoli Risk Manager 381
process-relatedTivoli Enterprise Console 370
Tivoli Risk Manager 377
sent to Tivoli Enterprise Console 369
Set(Group)-relatedTivoli Enterprise Console 373
Tivoli Risk Manager 380
Set(User)-relatedTivoli Enterprise Console 373
Tivoli Risk Manager 380
Sudo-relatedTivoli Risk Manager 379
Sudos-relatedTivoli Enterprise Console 373
TCB-relatedTivoli Enterprise Console 373
Tivoli Risk Manager 380
Tivoli Enterprise Console 370
Tivoli Risk Manager 376
examplesaudit authorization resources 71
audit authorization usage 72
audit trace resources 73
backing up PDOS 169
duplicate user names 143
hard link aliases 34
holiday login 52
log router control file 121
login activity policy 57
login resource specifications 54
network resource 47
password management policy 61
pdoshla 168
pdoswhoami 165
pdoswhois 165
restoring PDOS 169
Sudo usage 66
surrogate resources 62
symbolic link aliases 33
user exception policy 58, 61
user name relationships 3
wildcard matching 11
expiration threshold, certificates 250
explicitly destroying credentials 164
explicitly refreshing credentials 164
extended attributesaudit-level 26
time-of-day 27
Ffile permissions 28
file policy 27, 28
file system aliases 31
file system resourcesfile policy 28
File system resourcesaccess control 28
file-related eventsTivoli Enterprise Console 372
Tivoli Risk Manager 378
files.rhosts 54
audit logs 251
hosts.equiv 54
scheduled upgrades 158
files and directories 111
fixes, obtaining 387
format 255
Gglobal audit level
setting and querying 154, 242
global auditing 241
global warning modeenabling, disabling, and
querying 250
global-level auditaction against protected resource 243
grace loginsdisplaying 162
groupsimporting from native accounts 205
ossaudit 110
osseal 109
osseal-admin 108
osseal-auditors 110
groups and users 108
Hhard link alias
example 34
hard links 34
health auditingenabling 249
introduction 248
heartbeat audit recordscontrolling 250
enabling 249
holiday login example 52
holiday login restrictions 51
host name cachedisplaying 201
removing entries 212
updating 234
398 Administration Guide
host name lookaside databaseconfiguring 167
configuring and managing 167
managing 167
host name resolution server
isolation 120
host pattern precedence 48
hosts.equiv file 54
Iidentity
UNIX 3
user 3
Immune-Programs 41
Immune-Surrogate-Programs 40
Impersonator-Programs 40
information centers, searching 387
inheritance 23
inheritance of ACLs 23
initial policy 114
osseal-audit 115
osseal-audit-exec 115
osseal-credentials 115
osseal-default 115
osseal-default-file 115
osseal-default-login 115
osseal-default-net-incoming 115
osseal-default-net-outgoing 115
osseal-default-sudo 116
osseal-default-surrogate 116
osseal-exec-root 116
osseal-hla 116
osseal-kazndrv 116
osseal-logs 116
osseal-open 117
osseal-privileged-user 117
osseal-restricted 117
osseal-restricted-read 117
osseal-tcb 117
osseal-umsg 117
osseal-var-lpm 117
installing and configuring the logfile
adapter 358
installing and configuring the TEC log
file adapter 362
integrating with Tivoli Data
Warehouse 363
Internet, searching 387
isolated operation 118
isolationhost name resolution server 120
non-local UNIX user registry 119
policy server 118
Tivoli Access Manager user
registry 118
KKerberos
authenticating 2
authentication limitation 2
key-value format 254
knowledge basesinformation centers 387
searching 387
knowledge bases (continued)the Internet 387
Ll (directory list) ACL
Linux with 2.6 kernel 32
policy enforcement 32
LDAPauthenticating 2
authentication limitation 2
limiting ACL inheritance for network
policy 148
local and remote terminals 53
locking and unlocking accounts 161
log file archive 90
log filesdaemon 151
log routeraudit record fields 133
channels 130
output formats 137
log router control file 121
elements 122
example 121
log router daemon 121
logfile adapterstarting 233
stopping 233
logging configurationshowing 231
loginholiday restrictions 51
login activitypolicy 54
login activity policy 54
configuring NIS 162
example 57
login activity policy enforcementmanaging 160
login location restriction 53
Login objectsaccess controls 54
login policy 50
configuring 193
displaying grace logins 162
querying 215
login restrictionstime-of-day 50
Login-Programs 37
login-related eventsTivoli Enterprise Console 375
Tivoli Risk Manager 382
logout audit event record type 267
LRD_AuditInput channel type 130
LRD_EmailOutput channel type 131
LRD_FileOutput channel type 131
LRD_NetOutput channel type 132
Mmanagement tasks
adding auditors and
administrators 178
available for Tivoli desktop 175
Backing up PDOS Database 180
management tasks (continued)configuring audit health 185
configuring auditing 187
configuring branches 182
configuring caching 188
configuring logging 190
configuring login policy 193
configuring password policy 193
configuring server 195
configuring Trusted Computing
Base 199
displaying host name cache 201
distributing control file, pdoslrd
daemon 202
importing UNIX groups 205
importing UNIX Trusted Computing
Base 203
importing UNIX users 205
managing credential cache 208
managing server state 209
managing Trusted Computing
Base 211
querying branch membership 213
querying login policy 215
querying password policy 215
querying server state 216
querying Trusted Computing
Base 218
removing auditors and
administrators 178
removing entries for host name
cache 212
restoring database 219
setting server audit level 220
setting server trace level 223
setting up the Tivoli Enterprise
Console event server 225
showing administrators 229
showing audit configuration 228
showing auditors 229
showing caching configuration 230
showing logging configuration 231
showing server audit level 231
showing server configuration 232
showing Trusted Computing Base
configuration 232
starting logfile adapter 233
stopping logfile adapter 233
subscribing endpoints 233
transferring certificates 183
updating host name cache 234
managing credentials 163
managing operating system
upgrades 159
managing processes 149
managing scheduled upgrades to
files 158
managing the host name lookaside
database 167
managing the object signature
database 157
managing the Trusted Computing
Base 156
membership report, policy branch 148
Index 399
NN (create) ACL
Linux with 2.6 kernel 32
policy enforcement 32
network policy 44
limiting ACL inheritance 148
network resource access control 49
network resourcesexample 47
network service and host pattern
precedence 47
network-related eventsTivoli Enterprise Console 372
Tivoli Risk Manager 379
NFS clients 35
NIS, authenticating 2
non-local UNIX user registry
isolation 119
Oo (chown) ACL
Linux with 2.6 kernel 32
policy enforcement 32
object name 10
object name structureobject name 10
object space root 9
policy branch 9
protected 8
resource types 10
object signature databasemanaging 157
object space root 9
operating system upgradesmanaging 159
ossaudit group 110
osseal group 109
osseal user 109
osseal-admin group 108
osseal-audit 115
osseal-audit-exec 115
osseal-auditors group 110
osseal-credentials 115
osseal-default 115
osseal-default-file 115
osseal-default-login 115
osseal-default-net-incoming 115
osseal-default-net-outgoing 115
osseal-default-sudo 116
osseal-default-surrogate 116
osseal-exec-root 116
osseal-hla 116
osseal-kazndrv 116
osseal-logs 116
osseal-open 117
osseal-privileged-user 117
osseal-restricted 117
osseal-restricted-read 117
osseal-tcb 117
osseal-umsg 117
osseal-unauth user 110
osseal-var-lpm 117
output formatslog router 137
Pp (chmod) ACL
Linux with 2.6 kernel 32
policy enforcement 32
password change date for user
accounts 161
password expirationdisplaying 162
password management policy 58
example 61
password management policy
enforcementmanaging 160
password policyconfiguring 193
displaying password expiration 162
querying 215
password strength-related eventsTivoli Enterprise Console 376
Tivoli Risk Manager 383
PDOS taskstask overview 175
PDOS Tasks task library 175
pdosauditd 100
pdosauditd configuration 101
pdosaudview 115, 270
pdosbkup 275
pdosbranchcfg 277
pdoscfg 280
pdoscollview 292
pdosctl 297
pdosd 90
pdosd log configuration attributes 99
pdosd-hostname user 110
pdosdestroy 302
pdosent 303
pdosexempt 306
pdoshla 308
pdoslpadm 313
pdoslpinf 311
pdoslpmd 105
pdoslpmd configuration 106
pdoslpmd daemon 105
pdoslradm 318
pdoslrd 107, 121
pdoslrd configuration 107
pdoslrd daemondistributing control file 202
pdoslrdlog router daemon 107
pdosobjsig 319
pdosrefresh 322
pdosrespolicy 324
pdosrevoke 326
pdosrgyimp 328
pdosrstr 333
pdosshowuser 334
pdossudo 68, 337
pdosteccfg 338
pdostecd 104
periodic log maintenance 105
pdostecd configuration 104
pdostecd daemon 104
pdostecucfg 341
pdosucfg 343
pdosuidprog 345
pdosunauth 348
pdosversion 349
pdoswdd 102
pdoswdd configuration 103
pdoswdd watchdog daemon 102
pdoswhoami 350
example 165
pdoswhois 352
example 165
planning policy 7
policyauthorization 4
authorization decision process 95
hard links 34
initialosseal-exec-root 116
initial configuration 114
login 50
configuring 193
querying 215
login activity 54
network 44
passwordconfiguring 193
querying 215
password management 58
planning 7
security considerations 95
Sudo 64
surrogate 62
symbolic links 31
user exception 58
warning modes 152
policy administration 7
policy branch 9
policy branch configurationadding branches 145
changing precedence order 145
configuring additional branches 145
deleting branches 145
listing branches 145
listing precedence order 145
policy brancheslisting subscribers 149
listing subscriptions 149
membership 148
Policy Director Region policy region 175
policy enforcementLinux with 2.6 kernel 32
symbolic links 32
policy quick reference 365
policy region, Policy Director
Region 175
policy server isolation 118
policy warning modes 152
policy-related eventsTivoli Enterprise Console 374
Tivoli Risk Manager 381
policyview 354
precedence orderchanging 145
listing 145
process-related eventsTivoli Enterprise Console 370
Tivoli Risk Manager 377
processesdetermining accessory identity 165
protected object name structure 8
protected object policies 25
400 Administration Guide
protected object policies (continued)audit-level attribute 26
time-of-day attribute 27
warning mode 25
protected system resources 27
Rr (read) ACL
Linux with 2.6 kernel 32
policy enforcement 32
R (rename) ACLLinux with 2.6 kernel 32
policy enforcement 32
resource audit levelsetting and querying 155, 244
resource managers 1
resource types 10
resource warning modeenabling, disabling, and
querying 251
resource-level auditaction against protected resource 245
resource-level auditing 244
resourcesaudit authorization 70
audit trace 72
restoring configuration files and
databases 168
restriction types 19
root directoryaccess control 30
root user 109
runtime 89
runtime administrator 109
SSecure-Files 39
Secure-Programs 39
securityauthorization decision process 95
security considerations 95
server configurationshowing 232
server statemanaging 209
querying 216
service pattern precedence 48
Set(Group)-related eventsTivoli Enterprise Console 373
Tivoli Risk Manager 380
Set(User)-related eventsTivoli Enterprise Console 373
Tivoli Risk Manager 380
setting and querying the global audit
level 154, 242
setting and querying the resource audit
level 155
setting and querying user-level
audit 246
software updates, receiving 388
specifying recurring holidays 52
starting processes 149
stopping processes 150
structure of holiday object names 53
Sudowildcard arguments 67
Sudo policy 64
Sudo usageexample 66
Sudo-related eventsTivoli Enterprise Console 373
Tivoli Risk Manager 379
supportSee customer support
surrogate policy 62
surrogate resourcesaccess control 64
example 62
symbolic links 31
example 33
Linux with 2.6 kernel 32
policy enforcement 32
system resourcesfile policy 27
Ttask
authorization roles 175
task library, PDOS Tasks 175
TCBmanaging 156
tuning monitoring 156
TCB monitoring 97
TCB resources 36
Immune-Programs 41
Immune-Surrogate-Programs 40
Impersonator-Programs 40
Login-Programs 37
Secure-Files 39
Secure-Programs 39
TCB-related eventsTivoli Enterprise Console 373
Tivoli Risk Manager 380
TEC logfile adapterinstalling and configuring 358
integrating with Tivoli Risk
Manager 362
terminal resources definition 54
time-of-daylogin restrictions 50
Tivoli Data Warehouse 363
Tivoli desktopAdd/Remove PDOS
Auditors/Administrators task 178
Audit Health Configuration task 185
available management tasks 175
Backup PDOS Database task 180
Certificate Transfer Utility task 183
Configure PDOS Auditing task 187
Configure PDOS Caching task 188
Configure PDOS Logging task 190
Configure PDOS Login and Password
Policy task 193
Configure PDOS Server task 195
Configure PDOS TCB task 199
Display PDOS Hostname Cache
task 201
Distribute Log Router Daemon
Control File task 202
Import UNIX TCB task 203
Tivoli desktop (continued)Import UNIX Users and Groups
task 205
Manage PDOS Credential Cache
task 208
Manage PDOS Server State task 209
Manage PDOS TCB task 211
Multiple Branch Configuration
task 182
Purge PDOS Hostname Cache
task 212
Query Branch Membership task 213
Query PDOS Login and Password
Policy task 215
Query PDOS Server State task 216
Query PDOS TCB task 218
Restore PDOS Database task 219
Set PDOS Server Audit Level
task 220
Set PDOS Server Trace Level
task 223
Setup TEC Event Server for PDOS
task 225
Show PDOS Auditing Configuration
task 228, 232
Show PDOS Auditors/Administrators
task 229
Show PDOS Caching Configuration
task 230
Show PDOS Logging Configuration
task 231
Show PDOS Server Audit Level
task 231
Show PDOS Server Configuration
task 232
Start PDOS TEC Adapter task 233
Stop PDOS TEC Adapter task 233
Subscribe PDOS Endpoints task 233
Update PDOS Hostname Cache
task 234
Tivoli Enterprise Consolecredential-related events 376
integrating with 357
integrating with Tivoli Risk
Manager 361
login-related events 375
network-related events 372
password strength-related events 376
policy-related events 374
process-related events 370, 372
Set(Group)-related events 373
Set(User)-related events 373
Sudo-related events 373
TCB-related events 373
Tivoli Enterprise Console event serversetting up 225
Tivoli Enterprise Console events 370
Tivoli Risk Managercredential-related events 382
file-related events 378
integrating with Tivoli Enterprise
Console 361
login-related events 382
network-related events 379
password strength-related events 383
policy-related events 381
process-related events 377
Index 401
Tivoli Risk Manager (continued)Set(Group)-related events 380
Set(User)-related events 380
Sudo-related events 379
TCB-related events 380
Tivoli Risk Manager events 376
trace audit event record type 265
trace levelserver
setting 223
traversal 23
Trusted Computing Baseconfiguring 199
managing 156, 211
querying 218
showing configuration 232
tuning monitoring 156
trusted computing base resources 36
tuningcredentials cache 163
TCB monitoring 156
UU (utime) ACL
Linux with 2.6 kernel 32
policy enforcement 32
unauthenticated environmenttesting programs 155
UNIXidentity 3
user accountsminimum password age 161
password change date 161
user accounts with minimum password
age policy 161
user exception policy 58
example 58, 61
user identity 3
user namesduplicates
identifying 143
user registry 93
user registry isolation 118
user-level auditsetting and querying 246
user-level auditing 246
usersdetermining accessory identity 165
importing from native accounts 205
osseal 109
osseal-unauth 110
root 109
users and groups 108
using auditing to verify policy 153
Vverifying policy 152
using auditing 153
viewing account records 160
Ww (write) ACL
Linux with 2.6 kernel 32
w (write) ACL (continued)policy enforcement 32
warning mode 250
for a specific resource 153
global 152, 250
resource 251
warning modespolicy 152
wildcard 10
character set expression 367
file name precedence 12
host name precedence 12
precedence 11
Sudo arguments 67
wildcardsmatching example 11
wrunjob command 178
wruntask command 178
wschedjob command 178
Xx (execute) ACL
Linux with 2.6 kernel 32
policy enforcement 32
402 Administration Guide
����
Printed in USA
SC32-1709-00
