Administration Guide

Tivoli Access Manager for e-business
®
Version 6.1.1
Administration Guide
SC23-6504-01
Tivoli Access Manager for e-business
®
Version 6.1.1
Administration Guide
SC23-6504-01
Note
Before using this information and the product it supports, read the information in Appendix H, “Notices,” on page 379.
Edition notice
This edition applies to version 6, release 1, modification 1 of IBM Tivoli Access Manager (product number
5724-C87) and to all subsequent releases and modifications until otherwise indicated in new editions.
All rights reserved.
© Copyright IBM Corporation 1999, 2010.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this publication . . . . . . . . ix
Intended audience . . . . . . . . . . . . ix
Publications . . . . . . . . . . . . . . ix
IBM Tivoli Access Manager for e-business library ix
Related products and publications . . . . . . xi
Accessing terminology online . . . . . . . xii
Accessing publications online . . . . . . . xii
Ordering publications . . . . . . . . . . xii
Accessibility . . . . . . . . . . . . . . xiii
Tivoli technical training . . . . . . . . . . xiii
Tivoli user groups . . . . . . . . . . . . xiii
Support information . . . . . . . . . . . xiii
Conventions used in this publication . . . . . xiv
Typeface conventions . . . . . . . . . . xiv
Operating system-dependent variables and
paths . . . . . . . . . . . . . . . xiv
Chapter 1. Tivoli Access Manager
overview . . . . . . . . . . . . . . 1
Core technologies. . . . . . . . . . . .
Authentication. . . . . . . . . . . .
Authorization . . . . . . . . . . . .
Quality of Protection. . . . . . . . . .
Scalability . . . . . . . . . . . . .
Accountability . . . . . . . . . . . .
Centralized management . . . . . . . .
Security policy overview . . . . . . . . .
Authorization API standard . . . . . . . .
Authorization: conceptual model . . . . . .
The benefits of a standard authorization service
Tivoli Access Manager authorization service
overview . . . . . . . . . . . . .
Tivoli Access Manager authorization service . . .
Components . . . . . . . . . . . .
Authorization service interfaces . . . . .
Replication for scalability and performance . .
Implementing a network security policy . . . .
Defining and applying security policy . . .
The authorization process: step-by-step . . .
Tivoli Access Manager authorization API . . .
Using the authorization API: examples . . .
Authorization API: remote cache mode . . .
Authorization API: local cache mode . . . .
External authorization capability . . . . . .
Extending the authorization service . . . .
Imposing conditions on resource requests . .
The authorization evaluation process . . . .
Implementing an external authorization service
Deployment strategies . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
3
4
4
5
5
6
7
. 8
. 9
. 9
. 10
. 10
. 11
. 11
. 13
. 14
. 14
. 15
. 16
. 17
. 17
. 18
. 18
20
. 20
Chapter 2. Web Portal Manager . . . . 23
Types of administration
Delegate administration
Self-care . . . .
Self-registration . .
. .
tasks
. .
. .
© Copyright IBM Corp. 1999, 2010
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
Web Portal Manager common tasks . . . .
Starting Web Portal Manager . . . . .
Logging in and signing off . . . . . .
Accessing online help . . . . . . . .
Customizing the Web Portal Manager interface
Customizing the images . . . . . . .
Self-registration tasks . . . . . . . . .
Performing self-registration . . . . . .
Changing Java Server Pages . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
27
27
28
28
28
28
29
Chapter 3. Tivoli Access Manager
administration . . . . . . . . . . . 33
Domains . . . . . . . . . . . .
Protected object space . . . . . . . .
Users and groups . . . . . . . . .
Security policy . . . . . . . . . .
ACL policies . . . . . . . . . . .
Using ACL policies with the authorization
Evaluating ACL policies . . . . . .
Protected object policies . . . . . . .
Authorization rules . . . . . . . . .
How authorization rules differ . . . .
When to use authorization rules . . .
Guidelines for a secure object space . . .
. . .
. . .
. . .
. . .
. . .
service
. . .
. . .
. . .
. . .
. . .
. . .
33
34
36
37
38
38
39
40
40
40
41
41
Chapter 4. Default security policy . . . 43
Default administration users and groups . . . . 43
iv-admin group . . . . . . . . . . . . 43
sec_master user . . . . . . . . . . . . 43
ivmgrd-servers group . . . . . . . . . . 43
Administration users . . . . . . . . . . 43
Defining and applying security policy . . . . . 45
ACL policies . . . . . . . . . . . . . 45
Protected object policies . . . . . . . . . 45
Authorization rules . . . . . . . . . . . 46
Sparse security policy model . . . . . . . . 47
Security policy inheritance . . . . . . . . 47
default-root ACL policy . . . . . . . . . 48
Control permission . . . . . . . . . . . 48
Traverse permission . . . . . . . . . . 48
Resolving an access request . . . . . . . . 49
Applying ACL policies to different object types
50
ACL policy inheritance example . . . . . . 50
Default ACL policies . . . . . . . . . . . 51
default-root ACL policy . . . . . . . . . 51
default-management ACL policy . . . . . . 52
default-replica ACL policy . . . . . . . . 52
default-config ACL policy . . . . . . . . 52
default-gso ACL policy . . . . . . . . . 52
default-policy ACL policy . . . . . . . . 52
default-domain ACL policy . . . . . . . . 53
default-proxy ACL policy. . . . . . . . . 53
/Management permissions . . . . . . . . . 53
/Management/ACL permissions . . . . . . 53
/Management/Action permissions . . . . . 54
iii
/Management/POP permissions .
/Management/Server permissions.
/Management/Config permissions
/Management/Policy permissions .
/Management/Replica permissions
/Management/Users permissions .
/Management/Groups permissions
/Management/GSO permissions .
/Management/Rule permissions .
/Management/Domain permissions
/Management/Proxy permissions .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
56
56
56
57
58
58
59
59
Chapter 5. Managing domains. . . . . 61
Logging in to domains . .
Creating a domain . . . .
Modifying the description for
Listing domains . . . . .
Deleting a domain . . . .
.
.
. .
. .
a domain
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
62
63
64
Chapter 6. Managing object spaces . . 65
Creating an object space
Listing object spaces .
Copying an object space
Importing object spaces
Exporting object spaces
Deleting an object space
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 7. Managing protected objects
Creating an object
Listing objects .
Importing objects
Exporting objects
Deleting an object
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
67
67
68
68
69
71
.
.
.
.
.
71
73
73
74
74
Chapter 8. Managing access control . . 77
ACL policies . . . . . . . . . . . . .
ACL entries . . . . . . . . . . . . .
Type attribute . . . . . . . . . . .
ID attribute . . . . . . . . . . . .
Permissions attribute . . . . . . . . .
Action groups and actions . . . . . . . .
Default permissions in the primary action group
Custom permissions in custom action groups .
Managing ACL policies . . . . . . . . .
Creating an ACL policy . . . . . . . .
Modifying the description of an ACL policy .
Listing ACL policies . . . . . . . . .
Viewing an ACL policy . . . . . . . .
Cloning an ACL policy . . . . . . . .
Importing ACL policies . . . . . . . .
Exporting all ACL policies . . . . . . .
Exporting a single ACL policy . . . . . .
Exporting multiple ACL policies . . . . .
Attaching an ACL policy to an object . . . .
Detaching an ACL policy from an object. . .
Locating where an ACL policy is attached . .
Deleting an ACL policy . . . . . . . .
Managing ACL entries in ACL policies . . . .
Creating an ACL entry . . . . . . . .
Modifying permissions for an ACL entry . .
iv
Administration Guide
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
78
79
79
79
80
80
81
83
84
84
85
85
86
86
86
87
87
88
88
89
89
90
90
91
Removing ACL entries from an ACL policy. . .
Managing extended attributes in ACL policies . . .
Creating extended attributes for an ACL policy
Modifying extended attributes from an ACL
policy . . . . . . . . . . . . . . .
Listing extended attributes of an ACL policy . .
Viewing extended attributes of an ACL policy . .
Deleting extended attributes from an ACL policy
Deleting extended attribute values from an ACL
policy . . . . . . . . . . . . . . .
Managing action groups . . . . . . . . . .
Creating action groups . . . . . . . . .
Listing action groups . . . . . . . . . .
Deleting an action group . . . . . . . . .
Managing actions . . . . . . . . . . . .
Creating actions in an action group . . . . .
Listing actions in an action group . . . . . .
Deleting actions from an action group . . . .
91
92
92
93
93
94
94
95
95
96
96
97
97
97
98
98
Chapter 9. Protected object policy
management. . . . . . . . . . . . 101
Managing protected object policies . . . . .
Creating a POP . . . . . . . . . . .
Modifying a POP . . . . . . . . . .
Listing POPs . . . . . . . . . . .
Viewing a POP . . . . . . . . . . .
Cloning a POP . . . . . . . . . . .
Importing POPs . . . . . . . . . .
Exporting all POPs . . . . . . . . .
Export a single POP . . . . . . . . .
Exporting multiple POPs . . . . . . .
Attaching a POP to an object . . . . . .
Detaching a POP from an object . . . . .
Locating where a POP is attached . . . .
Deleting a POP . . . . . . . . . . .
Network-based authorization algorithm . . .
Network-based authorization policy . . . . .
Configuring POP attributes . . . . . . . .
Setting a warning mode . . . . . . . .
Setting an audit level . . . . . . . . .
Setting a time-of-day restriction . . . . .
Specifying IP addresses and ranges . . . .
Setting a Quality of Protection level . . . .
Step-up authentication . . . . . . . . .
Configuring levels for step-up authentication
Applying step-up authentication policy. . .
Distinguishing step-up from multi-factor
authentication . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
102
102
104
105
105
106
106
107
107
107
108
108
109
109
110
110
111
111
111
112
113
114
114
115
. 115
. 116
Chapter 10. Authorization rules
management . . . . . . . . . . . . 119
Authorization rules overview . . .
Access decision information . . .
Sources for retrieving ADI . . .
Volatile versus nonvolatile data .
Authorization rule language . . .
ADI XML document model. . .
XML access decision information .
Defining an XML namespace . .
Authorization rules evaluator . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
119
119
121
122
122
124
126
128
Format and constraints of rules . . . . . .
Examples of authorization rules . . . . . .
Methods of providing ADI to the rules
evaluator . . . . . . . . . . . . . .
Reason codes for rule failures . . . . . . .
Configuration file and initialization attributes . .
resource-manager-provided-adi . . . . . .
dynamic-adi-entitlement-services . . . . . .
input-adi-xml-prolog and xsl-stylesheet-prolog
[xmladi-attribute-definitions] . . . . . . .
Managing authorization rules . . . . . . . .
Creating an authorization rule . . . . . . .
Modifying an authorization rule . . . . . .
Listing authorization rules . . . . . . . .
Cloning an authorization rule . . . . . . .
Importing authorization rules . . . . . . .
Exporting all authorization rules . . . . . .
Exporting a single authorization rule . . . .
Exporting multiple authorization rules . . . .
Attaching an authorization rule to a protected
object . . . . . . . . . . . . . . .
Detaching an authorization rule . . . . . .
Locating where an authorization rule is attached
Deleting an authorization rule . . . . . . .
129
131
133
135
135
136
136
136
137
137
138
139
140
140
140
141
141
141
142
143
143
144
Chapter 11. Managing users and
groups . . . . . . . . . . . . . . 145
Managing users . . . . . .
Creating a user . . . . . .
Listing users. . . . . . .
Changing a password . . .
Setting user policy. . . . .
Setting global user policy . .
Importing users . . . . .
Deleting a user . . . . . .
Managing groups . . . . . .
Creating a group . . . . .
Listing groups . . . . . .
Importing groups . . . . .
Deleting a group . . . . .
Enabling dynamic group support.
LDAP registry . . . . . .
Active Directory . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
145
146
147
148
149
151
153
154
154
155
155
156
157
158
158
158
Chapter 12. Certificate and password
management. . . . . . . . . . . . 159
Initial configuration . . . . . . . . . .
Key file and stash file renewal information . .
Trust determination . . . . . . . . . .
Reconfiguring the PDCA on the policy server
Reconfiguring the PDCA on the runtime
machines . . . . . . . . . . . . .
Transferring the PDCA certificate to other
machines . . . . . . . . . . . . .
Server certificate revocation . . . . . . .
Additional key and stash file considerations . .
. 160
. 161
. 162
163
. 163
. 164
. 164
. 165
Chapter 13. Server management . . . 167
Tivoli Access Manager servers .
Proxy server. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. 167
. 168
Server dependencies . . . . . . . . .
Tivoli Access Manager utilities . . . . . .
Tivoli Access Manager servers tasks . . . . .
Starting and stopping servers on Linux and
UNIX operating systems. . . . . . . .
Starting and stopping servers on Windows
operating systems . . . . . . . . . .
Server configuration file tasks . . . . . . .
Changing configuration settings . . . . .
Automating server startup at boot time. . .
Policy server administration tasks . . . . .
Replicating the authorization database . . .
Using the server replicate command. . . .
Setting the number of update-notifier threads
Setting the notification delay time . . . .
. 169
. 170
. 170
. 170
.
.
.
.
.
.
.
171
172
172
173
174
174
175
175
. 176
Chapter 14. High availability of the
policy server. . . . . . . . . . . . 177
Data integrity . . . . . . . . .
Primary and replica LDAP servers . .
Active and passive policy servers. . .
High availability management . . . .
Verify the policy server setup for high
availability . . . . . . . . .
Review log files . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
177
177
178
.
.
.
.
.
.
. 178
. 179
Chapter 15. Multiple-tenancy policy
server . . . . . . . . . . . . . . 181
Chapter 16. Delegated administration
183
Overview of delegated administration . . . .
Delegated role administration . . . . . . .
Administrative tasks for roles . . . . . . .
Delegated object space management . . . . .
Structuring the object space for management
delegation . . . . . . . . . . . .
Default administration users and groups . .
Example of management delegation . . . .
Delegated user and group management . . .
Creating group container objects . . . . .
Creating groups . . . . . . . . . .
ACL policies affecting group management. .
ACL policies affecting user management . .
Security policy for delegated administration . .
.
.
.
.
183
185
186
186
.
.
.
.
.
.
.
.
.
187
187
187
188
189
190
191
192
193
Chapter 17. Diagnostics and auditing
Diagnostic events .
Auditing events .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
197
.
.
. 197
. 197
Appendix A. Guidelines for changing
configuring files . . . . . . . . . . 199
General guidelines
Default values . .
Strings . . . .
Defined strings . .
File names . . .
Integers . . . .
Boolean values . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
199
200
200
200
200
201
201
Contents
v
Appendix B. Configuration file
reference . . . . . . . . . . . . . 203
Location of configuration files . . . . . . .
Tivoli Access Manager runtime configuration file
Authorization server configuration file . . . .
Policy server configuration file . . . . . .
Policy proxy server configuration file . . . .
LDAP server configuration file . . . . . .
LDAP client with Active Directory server
configuration file . . . . . . . . . . .
Active Directory server configuration file . . .
Domino server configuration file . . . . . .
Web Portal Manager configuration file . . . .
Common audit service configuration files . . .
Resource manager configuration files . . . .
. 204
205
. 205
. 206
. 206
. 207
.
.
.
.
.
.
207
207
208
208
208
209
Appendix C. Configuration file stanza
reference . . . . . . . . . . . . . 211
[authentication-mechanisms] stanza . . .
cert-ldap . . . . . . . . . . .
cert-uraf . . . . . . . . . . .
passwd-ldap. . . . . . . . . .
passwd-uraf . . . . . . . . . .
[aznapi-admin-services] stanza . . . .
service-id . . . . . . . . . . .
[aznapi-configuration] stanza . . . . .
audit-attribute . . . . . . . . .
azn-app-host . . . . . . . . .
azn-server-name . . . . . . . .
cache-refresh-interval . . . . . . .
cred-attributes-entitlement-services . .
db-file . . . . . . . . . . . .
dynamic-adi-entitlement-services . . .
input-adi-xml-prolog . . . . . . .
listen-flags . . . . . . . . . .
logcfg . . . . . . . . . . . .
mode . . . . . . . . . . . .
pd-user-name . . . . . . . . .
pd-user-pwd . . . . . . . . .
permission-info-returned . . . . .
policy-cache-size . . . . . . . .
resource-manager-provided-adi . . .
xsl-stylesheet-prolog . . . . . . .
[aznapi-cred-modification-services] stanza .
service-id . . . . . . . . . . .
[aznapi-entitlement-services] stanza . . .
service-id . . . . . . . . . . .
[aznapi-external-authzn-services] stanza .
policy-trigger . . . . . . . . . .
[aznapi-pac-services] stanza . . . . .
service-id . . . . . . . . . . .
[cars-client] stanza. . . . . . . . .
compress . . . . . . . . . . .
diskCachePath . . . . . . . . .
doAudit . . . . . . . . . . .
clientPassword . . . . . . . . .
clientUserName . . . . . . . .
errorFilePath . . . . . . . . .
flushInterval. . . . . . . . . .
keyFilePath . . . . . . . . . .
vi
Administration Guide
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
211
212
213
213
214
215
215
217
217
218
218
219
219
220
221
221
222
222
223
224
224
224
225
225
226
227
227
228
229
230
230
231
232
233
233
233
234
235
235
235
236
236
lowWater . . . . . . . . .
hiWater . . . . . . . . .
maxCacheFiles . . . . . . .
maxCacheFileSize . . . . . .
maxErrorFiles . . . . . . .
maxErrorFileSize . . . . . .
maxTraceFiles . . . . . . .
maxTraceFileSize . . . . . .
numberCMThreads . . . . .
numberEQThreads . . . . .
numberRetries . . . . . . .
queueSize . . . . . . . .
rebindInterval . . . . . . .
retryInterval . . . . . . . .
serverURL . . . . . . . .
stashFilePath . . . . . . .
traceLevel . . . . . . . .
traceFilePath . . . . . . .
transferSize . . . . . . . .
useDiskCache . . . . . . .
[cars-filter] stanza . . . . . . .
auditevent . . . . . . . .
[configuration-database] stanza . .
file . . . . . . . . . . .
[delegated-admin] stanza . . . .
authorize-group-list . . . . .
[domains] and [domain=domain_name]
allowed-registry-substrings . . .
database-path . . . . . . .
domain . . . . . . . . .
[ivacld] stanza . . . . . . . .
log-file . . . . . . . . .
logcfg . . . . . . . . . .
permit-unauth-remote-caller . .
pid-file . . . . . . . . .
tcp-req-port . . . . . . . .
unix-user . . . . . . . . .
unix-group . . . . . . . .
[ivmgrd] stanza . . . . . . .
provide-last-login . . . . . .
provide-last-pwd-change . . .
auto-database-update-notify . .
ca-cert-download-enabled . . .
database-path . . . . . . .
log-file . . . . . . . . .
logcfg . . . . . . . . . .
max-notifier-threads . . . . .
notifier-wait-time . . . . . .
pid-file . . . . . . . . .
standby . . . . . . . . .
tcp-req-port . . . . . . . .
unix-user . . . . . . . . .
unix-group . . . . . . . .
[ldap] stanza . . . . . . . .
enhanced-pwd-policy. . . . .
max-auth-connections . . . .
enable-last-login . . . . . .
auth-using-compare . . . . .
authn-timeout . . . . . . .
bind-dn . . . . . . . . .
cache-enabled . . . . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
stanzas
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
237
237
237
238
238
238
239
239
239
240
240
240
241
241
241
242
242
242
243
243
244
244
246
246
247
247
248
248
249
249
250
250
251
252
252
253
253
254
254
254
255
255
256
256
257
257
258
259
259
260
261
261
261
262
262
264
265
265
266
266
267
cache-group-expire-time . . .
cache-group-membership . .
cache-group-size . . . . .
cache-policy-expire-time . . .
cache-policy-size . . . . .
cache-return-registry-id . . .
cache-use-user-cache . . . .
cache-user-expire-time . . .
cache-user-size . . . . . .
default-policy-override-support
ldap-server-config . . . . .
login-failures-persistent . . .
max-search-size. . . . . .
port . . . . . . . . .
prefer-readwrite-server . . .
search-timeout . . . . . .
ssl-enabled . . . . . . .
ssl-keyfile . . . . . . .
ssl-keyfile-dn . . . . . .
ssl-keyfile-pwd . . . . . .
user-and-group-in-same-suffix .
[ldap] stanza for ldap.conf . . .
cache-enabled . . . . . .
connection-inactivity . . . .
dynamic-groups-enabled . .
enabled . . . . . . . .
host . . . . . . . . .
ignore-suffix . . . . . . .
max-search-size. . . . . .
max-server-connections . . .
novell-suffix-search-enabled .
port . . . . . . . . .
replica . . . . . . . . .
secauthority-suffix . . . . .
ssl-port . . . . . . . .
[manager] stanza . . . . . .
management-domain . . . .
master-host . . . . . . .
master-port . . . . . . .
[meta-info] stanza . . . . . .
version . . . . . . . .
[pdconfig] stanza . . . . . .
LdapSSL . . . . . . . .
LdapSSLKeyFile . . . . .
LdapSSLKeyFileDn . . . .
LdapSSLKeyFilePwd . . . .
[pdaudit-filter] stanza . . . .
logcfg . . . . . . . . .
[pdmgrproxyd] stanza . . . .
cache-database . . . . . .
log-file . . . . . . . .
pid-file . . . . . . . .
tcp-req-port . . . . . . .
unix-group . . . . . . .
unix-user . . . . . . . .
[pdrte] stanza . . . . . . .
boot-start-ivacld . . . . .
boot-start-ivmgrd . . . . .
boot-start-pdproxyd . . . .
configured . . . . . . .
tivoli_common_dir . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
267
268
268
269
269
270
270
271
271
271
272
273
273
274
274
274
275
276
276
277
277
278
278
278
279
279
280
280
281
281
282
283
283
284
284
285
285
286
286
287
287
287
287
288
288
289
289
289
290
290
291
292
292
293
293
294
294
294
295
295
295
user-reg-host . . . . . . . . .
user-reg-hostport . . . . . . . .
user-reg-server . . . . . . . . .
user-reg-type . . . . . . . . .
[pdwpm] stanza . . . . . . . . .
aclMembership . . . . . . . . .
authMethod . . . . . . . . . .
bannerFile . . . . . . . . . .
changePassword . . . . . . . .
debug . . . . . . . . . . . .
infoBarGif . . . . . . . . . .
jrteHost . . . . . . . . . . .
jrteProps . . . . . . . . . . .
loginGif . . . . . . . . . . .
splashGif . . . . . . . . . . .
wasEmbedded . . . . . . . . .
[ssl] stanza . . . . . . . . . . .
ssl-authn-type . . . . . . . . .
ssl-auto-refresh . . . . . . . . .
ssl-cert-life . . . . . . . . . .
ssl-enable-fips . . . . . . . . .
ssl-io-inactivity-timeout . . . . . .
ssl-keyfile . . . . . . . . . .
ssl-keyfile-label . . . . . . . . .
ssl-keyfile-stash. . . . . . . . .
ssl-listening-port . . . . . . . .
ssl-local-domain . . . . . . . .
ssl-maximum-worker-threads . . . .
ssl-pwd-life . . . . . . . . . .
ssl-v3-timeout . . . . . . . . .
[ssl] stanza for ldap.conf. . . . . . .
ssl-local-domain . . . . . . . .
[uraf-registry] stanza . . . . . . . .
bind-id . . . . . . . . . . .
cache-mode . . . . . . . . . .
cache-lifetime . . . . . . . . .
cache-size . . . . . . . . . .
uraf-registry-config . . . . . . .
[uraf-registry] stanza for domino.conf . .
enabled . . . . . . . . . . .
NAB . . . . . . . . . . . .
PDM . . . . . . . . . . . .
server . . . . . . . . . . . .
uraf-return-registry-id . . . . . .
[uraf-registry] stanza for activedir.conf . .
dnforpd . . . . . . . . . . .
domain . . . . . . . . . . .
dynamic-groups-enabled . . . . .
enabled . . . . . . . . . . .
hostname. . . . . . . . . . .
multi-domain . . . . . . . . .
uraf-return-registry-id . . . . . .
use-email-as-user-id . . . . . . .
useEncryption . . . . . . . . .
[uraf-registry] stanza for activedir_ldap.conf
change-pwd-using-ldap-api. . . . .
dnforpd . . . . . . . . . . .
domain . . . . . . . . . . .
dynamic-groups-enabled . . . . .
enabled . . . . . . . . . . .
ldap-client-timeout . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
296
296
296
296
296
297
297
298
298
299
299
300
300
300
300
301
301
302
302
302
303
303
304
304
305
305
306
306
307
307
308
308
308
309
309
309
310
311
312
312
312
313
313
314
314
314
315
315
315
316
316
316
317
317
318
318
318
319
320
320
321
vii
max-connections-per-ad-domain .
multi-domain . . . . . . .
primary-domain . . . . . .
ssl-keyfile . . . . . . . .
ssl-keyfile-label . . . . . . .
ssl-keyfile-pwd . . . . . . .
uraf-return-registry-id . . . .
use-email-as-user-id . . . . .
ad-gc-server . . . . . . . .
ad-gc-port . . . . . . . .
UseSSL . . . . . . . . .
[xmladi-attribute-definitions] stanza .
AttributeName . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
321
321
322
322
323
324
324
324
325
325
326
326
327
Appendix D. User registry differences
329
General concerns . . . . . . . . . . .
LDAP concerns . . . . . . . . . . . .
Sun Java System Directory Server concerns .
Microsoft Active Directory Application Mode
(ADAM) concerns . . . . . . . . . .
URAF concerns. . . . . . . . . . . .
Lotus Domino Server concerns . . . . .
Microsoft Active Directory Server concerns .
Length of names . . . . . . . . . . .
. 329
. 329
. 330
.
.
.
.
.
330
331
331
331
334
Appendix E. pdadmin to Web Portal
Manager equivalents . . . . . . . . 337
Appendix F. Managing user registries
345
LDAP-specific tasks . . . . . . . . . .
LDAP failover configuration . . . . . .
Using valid characters for LDAP user and
group names . . . . . . . . . . .
Applying Tivoli Access Manager ACLs to new
LDAP suffixes . . . . . . . . . . .
Setting the password history policy . . . .
Active Directory-specific tasks . . . . . . .
Setting up Microsoft Windows 2003 Domain
Name System for Active Directory . . . .
. 345
. 345
viii
Administration Guide
. 349
. 350
. 361
. 362
. 362
Adding a new domain name to a DNS . . . .
Updating the Tivoli Access Manager schema
Adding a Tivoli Access Manager user to the
Active Directory system group . . . . . .
Using valid characters for Active Directory user,
group, and distinguished names . . . . . .
Importing dynamic groups to Tivoli Access
Manager . . . . . . . . . . . . . .
Enabling change user password requests to be
performed using LDAP APIs . . . . . . .
Enabling support for the use of email address or
other alternate format as user identity . . . .
Novell-specific tasks . . . . . . . . . . .
Updating the eDirectory schema . . . . . .
Novell eDirectory maintenance activities that
can damage schema modifications applied by
Tivoli Access Manager . . . . . . . . .
363
363
364
364
366
366
367
368
368
370
Appendix G. Support information . . . 373
Searching knowledge bases . . . . . . . . .
Searching information centers . . . . . . .
Searching the Internet . . . . . . . . .
Obtaining fixes . . . . . . . . . . . . .
Registering with IBM Software Support . . . .
Receiving weekly software updates . . . . . .
Contacting IBM Software Support . . . . . .
Determining the business impact . . . . . .
Describing problems and gathering information
Submitting problems . . . . . . . . . .
373
373
373
373
374
374
375
375
376
376
Appendix H. Notices . . . . . . . . 379
Trademarks .
.
.
.
.
.
.
.
.
.
.
.
.
. 380
Glossary . . . . . . . . . . . . . 383
Index . . . . . . . . . . . . . . . 393
About this publication
IBM® Tivoli® Access Manager for e-business provides an access control
management solution to centralize network and application security policy for
e-business applications.
The IBM Tivoli Access Manager for e-business: Administration Guide provides a
comprehensive set of procedures and for managing Tivoli Access Manager servers
and resources. This guide also provides you with valuable background and
conceptual information about the wide range of Tivoli Access Manager
functionality.
Intended audience
This guide is for system administrators responsible for the deployment and
administration of base Tivoli Access Manager software.
Readers should be familiar with the following:
v Microsoft® Windows® and UNIX® operating systems
v Database architecture and concepts
v Security management
v Internet protocols, including HTTP and TCP/IP
v Lightweight Directory Access Protocol (LDAP) and directory services
v Authentication and authorization
v Tivoli Access Manager security model and its capabilities
You should also be familiar with SSL protocol, key exchange (public and private),
digital signatures, cryptographic algorithms, and certificate authorities.
Publications
This section lists publications in the IBM Tivoli Access Manager for e-business
library and related documents. The section also describes how to access Tivoli
publications online and how to order Tivoli publications.
IBM Tivoli Access Manager for e-business library
The following documents are in the Tivoli Access Manager for e-business library:
v IBM Tivoli Access Manager for e-business: Quick Start Guide, GI11-9333
Provides steps that summarize major installation and configuration tasks.
v IBM Tivoli Access Manager for e-business: Release Notes, GC23-6501
Provides information about installing and getting started, system requirements,
and known installation and configuration problems.
v IBM Tivoli Access Manager for e-business: Installation Guide, GC23-6502
Explains how to install and configure Tivoli Access Manager for e-business.
v IBM Tivoli Access Manager for e-business: Upgrade Guide, SC23-6503
Upgrade from version 5.0, 6.0, or 6.1 to version 6.1.1.
v IBM Tivoli Access Manager for e-business: Administration Guide, SC23-6504
© Copyright IBM Corp. 1999, 2010
ix
Describes the concepts and procedures for using Tivoli Access Manager. Provides
instructions for performing tasks from the Web Portal Manager interface and by
using the pdadmin utility.
v IBM Tivoli Access Manager for e-business: WebSEAL Administration Guide,
SC23-6505
Provides background material, administrative procedures, and for using
WebSEAL to manage the resources of your secure Web domain.
v IBM Tivoli Access Manager for e-business: Plug-in for Edge Server Administration
Guide, SC23-6506
Provides instructions for integrating Tivoli Access Manager with the IBM
WebSphere® Edge Server application.
v IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Administration
Guide, SC23-6507
Provides procedures and for securing your Web domain using a Web server
plug-in.
v IBM Tivoli Access Manager for e-business: Shared Session Management Administration
Guide, SC23-6509
Provides deployment considerations and operational instructions for the session
management server.
v IBM Global Security Kit: Secure Sockets Layer Introduction and iKeyman User's Guide,
SC23-6510
Provides information for enabling SSL communication in the Tivoli Access
Manager environment.
v IBM Tivoli Access Manager for e-business: Auditing Guide, SC23-6511
Provides information about configuring and managing audit events using the
native Tivoli Access Manager approach and the Common Auditing and
Reporting Service. You can also find information about installing and
configuring the Common Auditing and Reporting Service. Use this service for
generating and viewing operational reports.
v IBM Tivoli Access Manager for e-business: Command Reference, SC23-6512
Provides about the commands, utilities, and scripts that are provided with Tivoli
Access Manager.
v IBM Tivoli Access Manager for e-business: Administration C API Developer Reference,
SC23-6513
Provides about using the C language implementation of the administration API
to enable an application to perform Tivoli Access Manager administration tasks.
v IBM Tivoli Access Manager for e-business: Administration Java Classes Developer
Reference, SC23-6514
Provides about using the Java™ language implementation of the administration
API to enable an application to perform Tivoli Access Manager administration
tasks.
v IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference,
SC23-6515
Provides about using the C language implementation of the authorization API to
enable an application to use Tivoli Access Manager security.
v IBM Tivoli Access Manager for e-business: Authorization Java Classes Developer
Reference, SC23-6516
Provides about using the Java language implementation of the authorization API
to enable an application to use Tivoli Access Manager security.
x
Administration Guide
v IBM Tivoli Access Manager for e-business: Web Security Developer Reference,
SC23-6517
Provides programming and for developing authentication modules.
v IBM Tivoli Access Manager for e-business: Troubleshooting Guide, GC27-2717
Provides problem determination information.
v IBM Tivoli Access Manager for e-business: Error Message Reference, GI11-8157
Provides explanations and recommended actions for the messages and return
code.
v IBM Tivoli Access Manager for e-business: Performance Tuning Guide, SC23-6518
Provides performance tuning information for an environment consisting of Tivoli
Access Manager with the IBM Tivoli Directory Server as the user registry.
Related products and publications
This section lists the IBM products that are related to and included with a Tivoli
Access Manager solution.
IBM Global Security Kit
Tivoli Access Manager provides data encryption through the use of the Global
Security Kit (GSKit), version 7.0. GSKit is included on the IBM Tivoli Access
Manager Base CD for your particular platform, as well as on the IBM Tivoli Access
Manager Web Security CDs, the IBM Tivoli Access Manager Shared Session Management
CDs, and the IBM Tivoli Access Manager Directory Server CDs.
The GSKit package provides the iKeyman key management utility, gsk7ikm, which
creates key databases, public-private key pairs, and certificate requests. The IBM
Global Security Kit: Secure Sockets Layer Introduction and iKeyman User's Guide is
available on the Tivoli Information Center Web site in the same section as the
Tivoli Access Manager product documentation.
IBM Tivoli Directory Server
IBM Tivoli Directory Server, version 6.1, is included on the IBM Tivoli Access
Manager Directory Server set of CDs for the required operating system.
You can find additional information about Tivoli Directory Server at:
http://www.ibm.com/software/tivoli/products/directory-server/
IBM Tivoli Directory Integrator
IBM Tivoli Directory Integrator, version 6.1.1, is included on the IBM Tivoli
Directory Integrator CD for the required operating system.
You can find additional information about IBM Tivoli Directory Integrator at:
http://www-306.ibm.com/software/tivoli/products/directory-integrator/
IBM DB2 Universal Database
IBM DB2 Universal Database™ Enterprise Server Edition, version 9.1, is provided
on the IBM Tivoli Access Manager Directory Server set of CDs and is installed with
the Tivoli Directory Server software. DB2® is required when using Tivoli Directory
Server or z/OS® LDAP servers as the user registry for Tivoli Access Manager. For
z/OS LDAP servers, you must separately purchase DB2.
You can find additional information about DB2 at:
About this publication
xi
http://www.ibm.com/software/data/db2
IBM WebSphere Application Server
WebSphere Application Server, version 6.1, is included on the IBM Tivoli Access
Manager WebSphere Application Server set of CDs for the required operating system.
WebSphere Application Server enables the support of the following applications:
v Web Portal Manager interface, which administers Tivoli Access Manager.
v Web Administration Tool, which administers Tivoli Directory Server.
v Common Auditing and Reporting Service, which processes and reports on audit
events.
v Session management server, which manages shared session in a Web security
server environment.
v Attribute Retrieval Service.
You can find additional information about WebSphere Application Server at:
http://www.ibm.com/software/webservers/appserv/infocenter.html
Accessing terminology online
The Tivoli Software Glossary includes definitions for many of the technical terms
related to Tivoli software. The Tivoli Software Glossary is available at the following
Tivoli software library Web site:
http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm
The IBM Terminology Web site consolidates the terminology from IBM product
libraries in one convenient location. You can access the Terminology Web site at
http://www.ibm.com/software/globalization/terminology .
Accessing publications online
The documentation CD contains the publications that are in the product library.
The format of the publications is PDF, HTML, or both. Refer to the readme file on
the CD for instructions on how to access the documentation.
The product CD contains the publications that are in the product library. The
format of the publications is PDF, HTML, or both. To access the publications using
a Web browser, open the infocenter.html file. The file is in the appropriate
publications directory on the product CD.
IBM posts publications for this and all other Tivoli products, as they become
available and whenever they are updated, to the Tivoli Documentation Central
Web site at http://www.ibm.com/tivoli/documentation.
Note: If you print PDF documents on other than letter-sized paper, set the option
in the File → Print window that allows Adobe Reader to print letter-sized
pages on your local paper.
Ordering publications
You can order many Tivoli publications online at http://
www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss.
You can also order by telephone by calling one of these numbers:
v In the United States: 800-879-2755
xii
Administration Guide
v In Canada: 800-426-4968
In other countries, contact your software account representative to order Tivoli
publications. To locate the telephone number of your local representative, perform
the following steps:
1. Go to http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss.
2. Select your country from the list and click Go.
3. Click About this site in the main panel to see an information page that
includes the telephone number of your local representative.
Accessibility
Accessibility features help users with 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 can also
use the keyboard instead of the mouse to operate all features of the graphical user
interface.
Visit the IBM Accessibility Center at http://www.ibm.com/alphaworks/topics/
accessibility/ for more information about IBM's commitment to accessibility.
For additional information, see the Accessibility Appendix in IBM Tivoli Access
Manager for e-business Installation Guide.
Tivoli technical training
For Tivoli technical training information, refer to the following IBM Tivoli
Education Web site at http://www.ibm.com/software/tivoli/education.
Tivoli user groups
Tivoli user groups are independent, user-run membership organizations that
provide Tivoli users with information to assist them in the implementation of
Tivoli Software solutions. Through these groups, members can share information
and learn from the knowledge and experience of other Tivoli users. Tivoli user
groups include the following members and groups:
v 23,000+ members
v 144+ groups
Access the link for the Tivoli Users Group at http://www.tivoli-ug.org/.
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:
Online
Access the Tivoli Software Support site at http://www.ibm.com/software/
sysmgmt/products/support/index.html?ibmprd=tivman. Access the IBM
Software Support site at http://www.ibm.com/software/support/
probsub.html .
IBM Support Assistant
The IBM Support Assistant is a free local software serviceability workbench
that helps you resolve questions and problems with IBM software
About this publication
xiii
products. The Support Assistant provides quick access to support-related
information and serviceability tools for problem determination. To install
the Support Assistant software, go to http://www.ibm.com/software/
support/isa.
Troubleshooting Guide
For more information about resolving problems, see the IBM Tivoli Access
Manager for e-business Installation Guide.
Conventions used in this publication
This publication uses several conventions for special terms and actions, operating
system-dependent commands, and paths.
Typeface conventions
This publication uses the following typeface conventions:
Bold
v Lowercase commands and mixed case commands that are otherwise
difficult to distinguish from surrounding text
v Interface controls (check boxes, push buttons, radio buttons, spin
buttons, fields, folders, icons, list boxes, items inside list boxes,
multicolumn lists, containers, menu choices, menu names, tabs, property
sheets), labels (such as Tip:, and Operating system considerations:)
v Keywords and parameters in text
Italic
v Citations (examples: titles of publications, diskettes, and CDs
v Words defined in text (example: a nonswitched line is called a
point-to-point line)
v Emphasis of words and letters (words as words example: "Use the word
that to introduce a restrictive clause."; letters as letters example: "The
LUN address must start with the letter L.")
v New terms in text (except in a definition list): a view is a frame in a
workspace that contains data.
v Variables and values you must provide: ... where myname represents....
Monospace
v Examples and code examples
v File names, programming keywords, and other elements that are difficult
to distinguish from surrounding text
v Message text and prompts addressed to the user
v Text that the user must type
v Values for arguments or command options
Operating system-dependent variables and paths
This publication 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 backslash (\) in
directory paths. The names of environment variables are not always the same in
the Windows and UNIX environments. For example, %TEMP% in Windows
environments is equivalent to $TMPDIR in UNIX environments.
xiv
Administration Guide
Note: If you are using the bash shell on a Windows system, you can use the UNIX
conventions.
About this publication
xv
xvi
Administration Guide
Chapter 1. Tivoli Access Manager overview
Tivoli Access Manager is an authentication and authorization solution for corporate
Web, client/server, and existing applications. Tivoli Access Manager allows you to
control user access to protected information and resources. By providing a
centralized, flexible, and scalable access control solution, Tivoli Access Manager
allows you to build secure and easy-to-manage network-based applications and
e-business infrastructure.
Tivoli Access Manager supports authentication, authorization, data security, and
resource management capabilities. You use Tivoli Access Manager in conjunction
with standard Internet-based applications to build highly secure and well-managed
intranets.
Tivoli Access Manager provides the following frameworks:
Authentication framework
The Tivoli Access Manager authentication service uses a wide range of
built-in authenticators and supports external authenticators.
Authorization framework
The Tivoli Access Manager authorization service, accessed through a
standard authorization application programming interface (API), provides
permit and deny decisions on access requests for native Tivoli Access
Manager servers and other applications.
The authorization service, together with resource managers, provides a
standard authorization mechanism for business network systems.
Tivoli Access Manager can be integrated into existing and emerging infrastructures
to provide secure, centralized policy management capability.
The following resource managers are some of the existing resource managers:
IBM Tivoli Access Manager WebSEAL
Manages and protects Web-based information and resources. WebSEAL is
included with Tivoli Access Manager for e-business.
IBM Tivoli Access Manager for Operating Systems
Provides a layer of authorization policy enforcement on Linux® and UNIX
operating systems in addition to that provided by the native operating
system.
Existing applications can take advantage of the Tivoli Access Manager
authorization service as well as provide a common security policy for the entire
enterprise.
Core technologies
The Tivoli Access Manager network security management solution provides and
supports the following core technologies:
v Authentication
v Authorization
v Quality of Protection
© Copyright IBM Corp. 1999, 2010
1
v Scalability
v Accountability
v Centralized management
Authentication
Authentication is the first step a user must take when making a request for a
resource that is protected by Tivoli Access Manager. During authentication, a user
identity is validated. The authentication process is usually dependent on the
specific requirements of the service-providing application. Tivoli Access Manager
allows a highly flexible approach to authentication through the use of the
authorization API.
Tivoli Access Manager provides built-in support of user name and password
authentication through the authorization API. Applications can build any custom
authentication mechanism that uses the authorization API.
Authorization
Authorization enforces the security policy by determining what objects a user can
access and what actions a user can take on those objects and then granting
appropriate access to the user. Tivoli Access Manager handles authorization
through the use of the following:
v Tivoli Access Manager authorization service
v Access control lists (ACLs), protected object policies (POPs), and authorization
rules for fine-grained access control
v Standards-based authorization API, using the aznAPI for C language
applications, and the Java Authentication and Authorization Service (JAAS) for
Java language applications
v External authorization service capability
Quality of Protection
Quality of Protection (QoP) is the degree to which Tivoli Access Manager protects
any information that is transmitted between a client and a server. The quality of
data protection is determined by the combined effect of encryption standards and
modification-detection algorithms. The resource manager is responsible for
ensuring that the quality of data protection is enforced.
Tivoli Access Manager supports the following levels of Quality of Protection:
v Standard Transmission Control Protocol (TCP) communication (no protection)
v Data integrity – protects messages (data stream) from being modified during
network communication
v Data privacy – protects messages from being modified or inspected during
network communication
Supported encryption ciphers
Tivoli Access Manager uses encryption ciphers that are provided by GSKit and
Java Secure Socket Extension (JSSE). To learn about these encryption ciphers, see
the GSKit and JSSE documentation.
Secure communication
Tivoli Access Manager supports the data integrity and data privacy provided by
the Secure Socket Layer (SSL) communication protocol and the Transport Layer
Security (TLS) communication protocol.
2
Administration Guide
The SSL handshake protocol provides security and privacy over the Internet. SSL
works by using public key for authentication and secret key to encrypt data that is
transferred over the SSL connection.
The TLS protocol meets the Federal Information Processing Standards (FIPS) 140-2
standard that describes United States Federal government requirements for
sensitive, but unclassified use of information technology products. When FIPS
mode is enabled in Tivoli Access Manager, TLS version 1 (TLSv1) is used instead
of SSL version 3 (SSLv3).
Tivoli Access Manager generates keys and certificates using FIPS-approved
operations. Therefore, the client- and server-side keys and certificates are always
FIPS approved.
To switch from SSL to TLS, all server and remote runtime configurations must be
changed. In Tivoli Access Manager this indicates whether FIPS mode is enabled or
disabled in the environment. When FIPS mode is enabled, the desired protocol is
TLS. When FIPS mode is not enabled, the desired protocol is SSL.
Note: SSL and TLS protocols cannot be mixed in a Tivoli Access Manager
environment. If a previous release of Tivoli Access Manager runtime did not
support TLS (currently communicating with SSL), these runtimes cannot
communicate with a server that is enabled for FIPS (now communicating
with TLS).
Scalability
Scalability is the ability to respond to increasing numbers of users who access
resources in the domain. Tivoli Access Manager uses the following techniques to
provide scalability:
v Replication of services
– Authentication services
– Authorization services
– Security policies
– Data encryption services
– Auditing services
v Front-end replicated servers
– Mirrored resources for high availability
– Load balancing client requests
v Back-end replicated servers
– Back-end servers can be Tivoli Access Manager WebSEAL, Tivoli Access
Manager for Operating Systems, Tivoli Access Manager for Business
Integration, or other application servers
– Mirrored resources (unified object space) for high availability
– Additional content and resources
– Load balancing of incoming requests
v Optimized performance by allowing for the off-loading of authentication services
and authorization services to separate servers
v Scaled deployment of services without increasing management overhead
Chapter 1. Tivoli Access Manager overview
3
Accountability
Tivoli Access Manager provides a number of logging and auditing capabilities. Log
files capture any error and warning messages generated by Tivoli Access Manager
servers. Audit trail files monitor Tivoli Access Manager server activity.
Centralized management
The following methods are provided for managing security policy and the Tivoli
Access Manager servers:
v pdadmin command line interface
v Web Portal Manager graphical user interface (GUI)
v Administration API
You can accomplish most tasks using any of these methods. However, some tasks
cannot be performed using Web Portal Manager.
pdadmin command interface
The pdadmin command line interface is used for Tivoli Access Manager
administration. This interface provides commands for managing users, groups,
roles, permissions, policies, domains, and servers, as well as for performing other
tasks. This interface can be used in scripts or batch files to automate processing.
This interface is installed as part of the Tivoli Access Manager runtime package.
For specific task information, see the task-specific chapters in this guide. For
detailed syntax information about the pdadmin command line interface, see the
IBM Tivoli Access Manager for e-business: Command Reference.
Web Portal Manager
Web Portal Manager is an optional Web-based interface used for Tivoli Access
Manager administration. Web Portal Manager allows you to perform
administrative tasks, such as managing users, groups, roles, permissions, policies,
domains, and servers. This optional interface must be installed separately from the
Tivoli Access Manager Web Portal Manager CD for your operating system. A key
advantage to using Web Portal Manager is that you can perform these tasks
remotely using any supported Web browser. You do not need any special network
configuration.
For specific task information, refer to chapters in this guide. For more information
on using Web Portal Manager, see the Web Portal Manager online help.
Administration API
The administration API provided by Tivoli Access Manager is a set of
programming interfaces that allow you to write applications to manage users,
groups, roles, permissions, policies, domains, and servers. Both C and Java
language versions of these functions are available.
Details on the administration API are provided in the IBM Tivoli Access Manager for
e-business: Administration C API Developer Reference and the IBM Tivoli Access
Manager for e-business: Administration Java Classes Developer Reference.
4
Administration Guide
Security policy overview
The goal of any security policy is to adequately protect business assets and
resources with a minimal amount of administrative effort. First, you must define
what resources need to be protected. These could be any type of data object, such
as files, directories, network servers, messages, databases, or Web pages. Then, you
must decide what users and groups of users should have access to these protected
resources. You also need to decide what type of access to these resources should be
permitted. Finally, you must apply the proper security policy on these resources to
ensure that only the right users can access them.
The enforcement of the security policy is the job of the resource manager. The
resource manager calls the Tivoli Access Manager authorization service with the
credentials of the user making the request, the type of access desired, and the
object to be accessed. The credential provides detailed information, acquired
during authentication, that describes the user, any group associations, and other
security-related identity attributes. Credentials can be used to perform a multitude
of services, such as authorization, auditing, and delegation.
The authorization service, also known as the authorization engine, uses the
security policy to determine whether the request should be allowed, denied, or
conditionally allowed pending additional verification by the resource manager. The
resource manager takes the recommendation of the authorization service, performs
any additional verification actions, and ultimately either denies the request, or
permits the request to be processed.
For example, suppose that Todd wants to access a particular Web page that is
located on a Web site protected by Tivoli Access Manager WebSEAL. WebSEAL is a
resource manager that is responsible for managing and protecting Web-based
information and resources and must decide whether or not Todd can access that
page. The resource manager obtains the credentials for Todd, and then asks the
authorization service whether Todd has read access to the Web page. The
authorization service checks the security policy and determines that Todd should
be permitted access, so it recommends to the resource manager that the request be
granted. The resource manager then directs Todd's request to the appropriate
back-end Web server, which provides the Web page.
The security policy in Tivoli Access Manager is defined through the use of access
control lists (ACLs), protected object policies (POPs), and authorization rules.
Authorization API standard
Authorization services are a critical part of the security architecture of an
application. After a user passes the authentication process, authorization services
proceed to enforce the business policy by determining what services and
information the user can access.
For example, a user accessing a Web-based retirement fund could view personal
account information after an authorization server verifies the identity, credentials,
and privilege attributes of that user.
The standards-based authorization API (aznAPI) allows applications to call the
centralized authorization service, thus eliminating the necessity for developers to
write authorization code for each new application.
Chapter 1. Tivoli Access Manager overview
5
The authorization API allows businesses to standardize all applications on a
trusted authorization framework. With the authorization API, businesses can
provide more control over access to resources on their networks.
Authorization: conceptual model
When servers enforce security in a domain, each client must provide proof of its
identity. In turn, security policy determines whether that client is permitted to
perform an operation on a requested resource. Access to every resource in a
domain is controlled by a server. So the demands on the server for authentication
and authorization can provide comprehensive network security.
In security systems, authorization is distinct from authentication. Authorization
determines whether an authenticated client has the right to perform an operation
on a specific resource in a domain. Authentication ensures that the individual is
who that individual claims to be.
In the Tivoli Access Manager authorization model, authorization policy is
implemented independently of the mechanism used for user authentication. Users
can authenticate their identity using either public/private key, secret key, or
customer-defined mechanisms.
Part of the authentication process involves the creation of a credential that
describes the identity of the client. Authorization decisions made by an
authorization service are based on user credentials.
The resources in a domain receive a level of protection as dictated by the security
policy for the domain. The security policy defines the legitimate participants of the
domain. It also defines the degree of protection that is surrounding each resource
requiring protection.
The authorization process, as shown in Figure 1 on page 7, includes the following
basic components:
resource manager
A resource manager responsible for implementing the requested operation
when authorization is granted.
A component of the resource manager is a policy enforcer that directs the
request to the authorization service for processing.
authorization service
An authorization service that performs the decision-making action on the
request.
6
Administration Guide
Authorization
service
authorization
check
request for
resource
Authenticated
client
Application
server
yes | no
Policy
enforcer
Resources
Resource manager
Figure 1. General authorization model
Traditional applications bundle the policy enforcer and resource manager into one
process. Examples of this structure include Tivoli Access Manager WebSEAL, Tivoli
Access Manager for Operating Systems, and Tivoli Access Manager for Business
Integration.
The independent functionality of these authorization components allows flexibility
in the design of the security enforcement strategy.
For example, such independence allows the security administrator to control:
v Where the processes are located
v Who writes the code for the processes
v How the processes perform their tasks
The benefits of a standard authorization service
Authorization in most systems, both existing and new, is tightly coupled to
individual applications. Companies typically build applications over time to serve
their business needs. Many of these applications require some specific form of
authorization.
The result is often a wide variety of applications with differing authorization
implementations. These proprietary authorization implementations require separate
administration, are difficult to integrate, and result in higher costs of ownership.
A distributed authorization service can provide these independent applications
with a standard authorization decision-making mechanism. Benefits of such a
standard authorization service include:
v Reduced cost of developing and managing access to applications
v Reduced total cost of ownership and management of separate authorization
systems
v Use the existing security infrastructure
v Allow new businesses to open more securely
v Enable newer and different kinds of applications
v Allow shorter development cycles
v Share information securely
Chapter 1. Tivoli Access Manager overview
7
Tivoli Access Manager authorization service overview
Tivoli Access Manager can be integrated into existing and emerging infrastructures
to provide a secure, centralized policy management capability. The Tivoli Access
Manager authorization service, together with resource managers, provides a
standard authorization mechanism for business network systems, as shown in
Figure 2:
Web Portal
Manager
Policy server
Master
authorization
database
User
registry
Authorization
server
Replica
authorization
database
Figure 2. Tivoli Access Manager server components
Existing applications can take advantage of the authorization service. Authorization
policy is based on user or group roles and can be applied to network servers,
individual transactions or database requests, specific Web-based information,
management activities, and user-defined objects.
The authorization API allows existing applications to call the authorization service
which in turn makes decisions based on the corporate security policy. For more
information on authorization API, see “Tivoli Access Manager authorization API”
on page 14.
The Tivoli Access Manager authorization service is also extensible and can be
configured to call on other authorization services for additional processing using
the external authorization service plug-in interface.
The authorization service provides the following benefits:
v The service is application independent.
v The service uses a standard authorization coding style that is language
independent (the authorization API).
v The service is centrally managed and therefore easy to administer. The addition
of a new employee, for example, requires modifying the privilege database in
one central location, rather than across multiple systems.
v The service addresses the application of security services in a heterogeneous
cross-platform environment.
v The service integrates existing non-Tivoli Access Manager authorization systems
through an external authorization service capability.
v The service has a scalable and flexible architecture that can be easily integrated
with existing infrastructure.
8
Administration Guide
v The service enables multi-tiered authorization. A credentials packet can be
passed through the multiple layers of an application process or transaction.
v The service uses a common and effective auditing model.
v The service is independent of any authentication mechanism.
Tivoli Access Manager authorization service
The Tivoli Access Manager authorization service is responsible for the
authorization decision-making process that helps to enforce a network security
policy. Authorization decisions made by the authorization service result in the
approval or denial of client requests to perform operations on protected resources
in a domain.
Components
The authorization service is made up of three basic components:
v Master authorization policy database
v Policy server
v The authorization decision-making evaluator
Policy database
The policy database, also referred to as the master authorization policy database
and the master authorization database, contains the security policy information for
all resources in a domain. Each domain has its own policy database. The contents
of this database are manipulated using Web Portal Manager, the pdadmin
command-line interface, and the administration API.
Policy server
The policy server maintains the policy databases, replicates this policy information
throughout the domains, and updates the database replicas whenever a change is
made to the master.
The policy server also maintains location information about the other Tivoli Access
Manager and non-Tivoli Access Manager resource managers operating in the
domain.
Authorization evaluator
The authorization evaluator is the decision-making process that determines the
ability of the client to access a protected resource based on the security policy. The
evaluator makes its recommendation to the resource manager which, in turn,
responds accordingly.
User registry replication parameters are configurable for each evaluator.
Figure 3 on page 10 illustrates the main components of the authorization service:
Chapter 1. Tivoli Access Manager overview
9
Authorization Service
Web Portal
Manager
Management
Interface
Policy
Server
(pdmgrd)
Authorization
Evaluator
Master
Authorization
Policy
Replica
Authorization
Policy
AuthAPI
Resource
Manager
Figure 3. Authorization service components
Authorization service interfaces
The authorization service has two interfaces where interaction takes place:
Management interface
The security administrator manages the security policy by using the Web
Portal Manager or the pdadmin command-line interface to apply policy
rules to resources in a domain. The security policy is managed in the
policy database by the policy server.
This interface is complex and involves detailed knowledge of the object
space, policies, and credentials.
Authorization API
The authorization API passes requests for authorization decisions from the
resource manager to the authorization evaluator which then passes back a
recommendation whether the request must be granted or denied.
Replication for scalability and performance
Authorization service components can be replicated to increase availability in a
heavy-demand environment.
You can configure the master authorization policy database, containing policy rules
and credential information, to automatically replicate. Resource managers that call
the authorization service have two options for referencing this database
information:
v The application, when configured to work seamlessly with the authorization
evaluator, uses a local cache of the database
The database is replicated for each resource manager that uses the authorization
service in local cache mode.
v The application uses a shared replica cached by the remote authorization server
component
The database is replicated for each instance of the authorization server. Many
applications can access a single authorization server.
10
Administration Guide
Update notification from the policy server (whenever a change was made to the
master authorization policy database) triggers the caching process to update all
replicas, as shown in Figure 4:
Authorization Service
Web Portal
Manager
Policy
Server
(pdmgrd )
Master
Authorization
Policy
Replica
Authorization
Policy
Replica
Authorization
Policy
Authorization
Evaluator
Replica
Authorization
Policy
AuthAPI
Resource
Manager
Figure 4. Replicated authorization service components
Performance notes
v You can update notifications directly from the policy server. You can also
configure the resource managers to verify the version of the master
authorization policy database every few minutes to ensure that the update
notification are not missed. Such a mechanism is called polling and is not
enabled by default.
If an update notification fails to reach a server, a log entry is created. In both
cases, a retry mechanism also ensures that the update happens in the future.
v The cached authorization policy information results in high system performance.
For example, when WebSEAL does an authorization check, it checks the policy
in its own cached version of the database. WebSEAL does not have to access the
network to obtain this information from the master database. The result is fast
response times (performance) for authorization checks.
v Individual authorization results are not cached by the calling application server.
Implementing a network security policy
The security policy for a domain is determined by controlling user and group
participation in the domain and applying rules to resources requiring protection.
These rules are defined through the use of access control lists (ACLs), protected
object policies (POPs), and authorization rules. The authorization service enforces
these policies by matching the credentials of a user with the permissions in the
policy assigned to the requested resource. The resulting recommendation is passed
to the resource manager, which completes the response to the original request.
Defining and applying security policy
You protect system resources by defining a security policy. This security policy is
created by defining access control lists (ACLs), protected object policies (POPs),
and authorization rules, and then applying these policies to the object
representations of those resources in the object space. You can apply ACLs, POPs,
Chapter 1. Tivoli Access Manager overview
11
and authorization rules to the same object. The pdadmin command-line interface,
the Web Portal Manager, and the administration API are used to define this policy.
The authorization service performs authorization decisions based on the policies
applied to these objects. When a requested operation on a protected object (also
referred to as a protected resource) is permitted, the resource manager responsible
for the resource implements this operation.
One policy can dictate the protection parameters of many objects. Any change to
the security policy affects all objects to which the policy is attached.
Explicit and inherited policy
A security policy can be explicitly applied or inherited. The Tivoli Access Manager
protected object space supports inheritance of ACLs, POPs, and authorization
rules. This factor is an important consideration for the security administrator who
manages the object space. The administrator needs to apply explicit policies only at
points in the hierarchy where the rules must change, as shown in Figure 5:
Explicit rule
Inherited rule
Management
objects
Web
objects
User-defined
objects
Figure 5. Explicit and inherited policies
Examples of policy types include:
v Hardcoded rules
v External authorization capability
v Special secure labeling
v Access control lists (ACLs), protected object policies (POPs), and authorization
rules
Access control lists
An access control list (ACL) policy, or ACL policy, is the set of actions, controls, or
permissions that specifies the conditions necessary for a particular user or group to
perform certain operations on that resource. ACL policy definitions are important
components of the security policy established for a domain.
An ACL policy specifically determines what operations can be performed on a
resource, and who can perform those operations. An ACL policy is made up of one
or more entries that include user and group designations and either their specific
permissions or rights.
12
Administration Guide
Protected object policies
Protected object policies (POPs) contain additional conditions that must be met in
order to be granted access. Unlike ACLs, which are dependent on what user or
group is attempting the action, POPs affect all users and groups. POPs also
indicate whether requests must be audited. It is the responsibility of Tivoli Access
Manager and the resource manager to enforce the POP conditions.
Authorization rules
Authorization rules are defined to specify further conditions that must be met
before access to a resource is permitted. Rules allow you to make authorization
decisions based on the context and the environment surrounding the request, as
well as who is attempting the access, and what type of action is being attempted.
These conditions are evaluated as a Boolean expression to determine if the request
must be allowed or denied.
The authorization process: step-by-step
Figure 6 illustrates the complete authorization process:
Secure Domain
Authorization
Service
2. Request for
Authorization
(AuthAPI)
Policy
Enforcer
6. Response
Authorization
Policy
/
4. Authorization
Decision
(AuthAPI)
1. Request
Client
3. Authorization
Check
Protected Object
Space
5. Authorized
Operation
Resources
Resource
Manager
Figure 6. The Tivoli Access Manager authorization process
1. An authenticated client request for a resource is directed to the resource
manager server and intercepted by the policy enforcer process. For example,
the resource manager can be WebSEAL for Hypertext Transfer Protocol (HTTP),
HTTPS access or another application.
2. The policy enforcer process uses the authorization API to call the authorization
service for an authorization decision. For more information about the
authorization API, see “Tivoli Access Manager authorization API” on page 14.
3. The authorization service performs an authorization check on the resource. See
page 37 for details on the algorithm used.
4. The decision to accept or deny the request is returned as a recommendation to
the resource manager (through the policy enforcer).
5. If the request is finally approved, the resource manager passes the request on to
the application responsible for the resource.
6. The client receives the results of the requested operation.
Chapter 1. Tivoli Access Manager overview
13
Tivoli Access Manager authorization API
The Tivoli Access Manager authorization application programming interface (API)
allows Tivoli Access Manager applications and other applications to query the
authorization service to make authorization decisions.
The authorization API is the interface between the resource manager (requesting
the authorization check) and the authorization service itself. The authorization API
allows Tivoli Access Manager resource managers and other resource managers to
ask for an authorization decision, but shields the application from the complexities
of the actual decision-making process.
The authorization API provides a standard programming model for coding
authorization requests and decisions. The authorization API lets you make
standardized calls to the centrally managed authorization service from any existing
or newly developed application.
The authorization API can be used in one of the following modes:
Remote cache mode
In this mode, the API is initialized to call the (remote) authorization server
to perform authorization decisions on behalf of the application. The
authorization server maintains its own cache of the replica authorization
policy database. This mode is best suited for handling authorization
requests from application clients.
For more information about remote cache mode, see “Authorization API:
remote cache mode” on page 15.
Local cache mode
In this mode, the API is initialized to download and maintain a local
replica of the authorization database for the application. Local cache mode
provides better performance because the application performs all
authorization decisions locally instead of across a network. However, the
overhead of database replication and the security implications of using this
mode make it best suited for use by trusted application servers.
For more information about local cache mode, see “Authorization API:
local cache mode” on page 16.
One of the primary values and benefits of the authorization API is its ability to
shield the resource manager from the complexities of the authorization service
mechanism itself. Issues of management, storage, caching, replication, credential
formats, and authentication methods are all hidden behind the authorization API.
The authorization API also works independently from the underlying security
infrastructure, the credential format, and the evaluating mechanism. The
authorization API makes it possible to request an authorization check and get a
simple yes or no recommendation in return. The details of the authorization check
mechanism are invisible to the user.
Using the authorization API: examples
Applications can use the authorization API to perform access control on specific
and specialized processes.
Example 1
A graphical interface can be designed to dynamically show task buttons as
active or inactive, according to the results of the authorization check.
14
Administration Guide
Example 2
Another use of the authorization API is demonstrated in Figure 7,
illustrating a request for a Common Gateway Interface (CGI) transaction
by a Web application.
The lowest level of authorization, as illustrated in Figure A of Figure 7, involves an
“all-or-nothing” access control on the uniform resource locator (URL). This
coarse-grained level of authorization only determines if the client can run the CGI
program. If access is allowed to the CGI application, no further control is available
to resources manipulated by the CGI application.
As illustrated in Figure B of Figure 7, access controls were set on resources that the
CGI program manipulates. The Web application is configured to use the
authorization API. Now the CGI program can call the authorization service to
make authorization decisions on the resources it manipulates — based on the
identity of the requesting client.
Figure A
Authorization
Service
Coarse-grained
Access
Request
Client
Response
Third-Party
Application
Web
Application
Objects
Manipulated
by CGI
Figure B
Authorization
Service
Request
Client
Response
Third-Party
Application
Function Call
A
Web
P
Application
I
Fine-grained
Authorized
Access
Objects
Manipulated
by CGI
Figure 7. Example use of the authorization API
Authorization API: remote cache mode
In remote cache mode, resource managers use the function calls provided by the
authorization API to communicate to the (remote) authorization server. The
authorization server functions as the authorization decision-making evaluator and
maintains its own replica authorization policy database.
The authorization server makes the decision and returns a recommendation to the
application through the API. The server can also write an audit record containing
the details of the authorization decision request.
There must be an authorization server running somewhere in a domain when
using remote cache mode, as shown in Figure 8 on page 16. The authorization
server can be located on the same machine as the application or on another
Chapter 1. Tivoli Access Manager overview
15
machine. You can also install the authorization server on more than one machine in
a domain to allow for high availability. The authorization API transparently
performs failover when a particular authorization server fails.
Authorization Service
Policy
Server
(pdmgrd )
pdacld
Authorization
Evaluator
Master
Authorization
Policy
Replica
Authorization
Policy
AuthAPI
AuthAPI
Third-Party
Application
Resources
Authenticated
Client
Figure 8. Authorization API: remote cache mode
Authorization API: local cache mode
In local cache mode, the API downloads and maintains a replica of the
authorization policy database on the local file system of the resource manager. It
performs all authorization decisions in-memory, which results in higher
performance and better reliability.
The local replica is persistent across invocations of the application. When the API
starts in replica mode, it checks for any updates to the master authorization policy
database that might have occurred since the local replica was built.
16
Administration Guide
Authorization Service
Policy
Server
(pdmgrd)
Authorization
Evaluator
Master
Authorization
Policy
Replica
Authorization
Policy
AuthAPI
Third-Party
Application
Resources
Authenticated
Client
Figure 9. Authorization API: local cache mode
External authorization capability
In some situations, the standard Tivoli Access Manager policy implementations of
ACLs, POPs, and authorization rules might not be able to express all the
conditions required by the security policy of an organization. Tivoli Access
Manager provides an optional external authorization capability to accommodate
any additional authorization requirements.
The external authorization service allows you to impose additional authorization
controls and conditions that are dictated by a separate, external, authorization
service module.
Extending the authorization service
External authorization capability is automatically built into the Tivoli Access
Manager authorization service. If you configure an external authorization service,
the Tivoli Access Manager authorization service simply incorporates the access
decision paths into its evaluation process.
Resource managers that use the authorization service, such as WebSEAL and any
application using the authorization API, benefit from the additional, but seamless,
contribution of a configured external authorization service. Any addition to the
security policy through the use of an external authorization service is transparent
to these applications and requires no change to the applications.
The external authorization service architecture allows the full integration of an
existing security service. An external authorization service preserves a the initial
Chapter 1. Tivoli Access Manager overview
17
investment that a company makes in security mechanisms by allowing existing
servers to be incorporated into the Tivoli Access Manager authorization
decision-making process.
Imposing conditions on resource requests
An external authorization service can be used to impose more specific conditions
or system-specific side effects on a successful or unsuccessful access attempt.
Examples of such conditions include:
v Causing an external auditing mechanism to record the successful or unsuccessful
access attempt
v Actively monitoring the access attempt and causing an alert or alarm whenever
unacceptable behavior is detected
v Conducting billing or micro-payment transactions
v Imposing access quotas on a protected resource
The authorization evaluation process
An authorization decision that incorporates an external authorization server takes
place in the following manner:
1. If a trigger condition is met during an access decision, the external
authorization services that were configured for that condition are each called in
turn to evaluate their own external authorization constraints.
Invocation of the external authorization service occurs regardless of whether
the necessary permission is granted to the user by the Tivoli Access Manager
authorization service.
2. Each external authorization service returns a decision of permitted, denied, or
indifferent.
When indifferent is returned, the external authorization service has
determined that its functionality is not required for the decision process and
that it does not participate.
3. Each external authorization service decision is weighted according to the level
of importance that its decision carries in the process.
The weighting of individual external authorization services is configured when
the service plug-in is loaded.
4. All authorization decision results are summed and combined with the decision
made by the Tivoli Access Manager authorization service. The resulting
decision is returned to the caller.
Example
Figure 10 on page 19 illustrates an authorization decision involving an application
server and an external authorization service.
18
Administration Guide
External
Authorization
Service
4. External
Authorization
Check
Secure Domain
5. External Authorization
Results (denied-101)
Authorization
Policy
Authorization
Service
2. Request for
Authorization
3. Authorization
Check
(allowed +100)
6. Combined Authorization
Decision (denied -1)
/
Protected Object
Space
Authzn API
1. Request
7. Denied Access
Client
8. Response:
Denied
Third-Party
Resource Manager
Resources
Figure 10. External authorization service with an application server
In this example, the purpose of the external authorization service is to impose a
quota restriction on how often a photo-quality printer resource can be accessed.
The service implementation imposes a limit on the number of job submissions that
any one person can make to this printer in one week. An external authorization
service trigger condition was attached to the photo printer resource so that the
external authorization service is invoked anytime that the photo printer is
accessed.
The external authorization service was loaded with the default decision weighting
of 101, which overrides any decision made by the Tivoli Access Manager
authorization service if required.
1. The resource manager server receives a request from a client for access to an
online photo printing resource. The client is a member of the appropriate group
GraphicArtists and so is normally permitted to submit jobs to the printer.
2. The application server first consults the Tivoli Access Manager authorization
service to determine whether the requesting user has permission to submit jobs
to the printer.
3. The authorization service verifies the access permissions on the target requested
object and compares the permissions against the capabilities of the requesting
user:
group GraphicArtists rx
In the ACL on the printer resource, the x permission grants any user in the
GraphicArtists group access to the resource. Therefore, the authorization
service grants the user permission to submit the job.
4. The photo printer resource is being accessed and an external authorization
service trigger condition was attached to this object. So a request is also made
to the external authorization service configured for that trigger condition.
Chapter 1. Tivoli Access Manager overview
19
The external authorization service receives all the Access Decision Information
(ADI) that was passed in with the original access decision check by the
resource manager server.
5. The external authorization service consults a record of previous accesses made
by this user. If the requesting user has not exceeded the quota for the week, it
returns an access decision of indifferent.
The implication is that the external authorization service is indifferent to the
request and has no intention of participating in the access decision because its
conditions for denying access have not been met.
However, if the user has exceeded the quota, then the external authorization
service returns a decision of access denied.
For this example, it is assumed that the requester has exceeded the quota and
that the external authorization service detects this problem and returns an
access denied decision.
6. The Tivoli Access Manager authorization service receives the access denied
result from the external authorization service. It then takes this decision and
weights it with the default external authorization service weighting value of
101.
The results of the external authorization service decision, and the decision
made by the Tivoli Access Manager authorization service, are combined. The
result is access denied, because the result of the external authorization service
(–101) outweighs that of the Tivoli Access Manager authorization service (100).
7. The resource manager server rejects the job submission to the photo printer
resource.
8. The resource manager server returns a response to the caller to indicate that the
job was rejected.
Implementing an external authorization service
Two general steps are required to set up an external authorization service:
1. Write an external resource manager service plug-in module with an
authorization interface that can be referenced during authorization decisions.
2. Register the external authorization service with the resource manager so that
the resource manager can load the plug-in service at initialization time.
Registering the service sets a trigger condition for the invocation of the external
authorization service. When the trigger condition is encountered during an
authorization check, the external authorization service interface is invoked to make
an additional authorization decision.
Deployment strategies
Tivoli Access Manager allows you to implement an external authorization service
in several ways:
v Any number of external authorization services can be registered with resource
manager applications. Applications that can load external authorization services
include the authorization server, other Tivoli Access Manager resource managers,
and any other resource manager applications that you create.
v Remote-mode authorization API clients, which make requests to the
authorization server for authorization decisions, automatically use any external
authorization service that is loaded by the authorization server.
v More than one external authorization service can be called for any single trigger
condition. In this case, the results of each external authorization service is
20
Administration Guide
v
v
v
v
weighted accordingly, and then the results are combined with the result of the
Tivoli Access Manager authorization service.
Trigger conditions can be placed on objects, using a POP trigger, such that any
request to an object, regardless of the operation that is being requested, triggers
a call to the external authorization services that are configured for the trigger.
Trigger conditions can also be placed on the operations requested by a user. For
example, an external authorization service can be triggered specifically when a
user requests a Write operation to a protected resource, but not for any other
operation. It is then possible to develop sets of operations for which one or more
external authorization services in combination are triggered according the set of
operations requested.
The external authorization services are implemented as dynamically loadable
library (dynamic link library (DLL)) modules. This feature greatly simplifies the
task of external authorization service development. There is no requirement to
make remote requests to the external authorization service and the overhead of
making the call is equivalent to the overhead of a function call.
The combination of the authorization API and an external authorization service
provides a highly extensible and flexible solution for implementing a complex
security policy.
Chapter 1. Tivoli Access Manager overview
21
22
Administration Guide
Chapter 2. Web Portal Manager
Tivoli Access Manager includes the following user interfaces that allow you to
manage domains, users and groups, permissions, policies, and other resources in
your enterprise:
pdadmin
pdadmin is a command-line interface that you can think about as the
pdadmin shell.
The pdadmin command-line interface is installed as part of the Tivoli
Access Manager runtime package. You can also automate certain
management tasks by writing scripts that use the pdadmin utility.
The IBM Tivoli Access Manager for e-business: Command Reference provides
detailed information about the pdadmin command-line interface, the
commands that you can run from this interface, and other utilities.
Web Portal Manager
Web Portal Manager is a management console that you can use to perform
tasks that are like the commands provided by the pdadmin commands.
The Web Portal Manager is implemented as a plug-in to the IBM
Integrated Solutions Console. The Integrated Solutions Console is a
graphical administration console that provides a framework for
administering multiple products. For example, your console enables you to
administer Tivoli Access Manager and WebSphere Application Server.
Web Portal Manager roles: Using Web Portal Management administrator
roles, an enterprise can limit the Tivoli Access Manager administrator
access to management functionality. Tivoli Access Manager 6.1.1
administrators do not have to be WebSphere Application Server
administrators. For example, one Tivoli Access Manager administrator can
manage policies and another administrator can manage WebSEAL
junctions. The following list describes the capabilities of each Web Portal
Management role:
Role name: wpmpolicyadmin
wpmpolicyadmin is a Web Portal Manager policy administrator role.
The following is a list of tasks that the wpmpolicyadmin role
performs:
v Object Space:
– Browse Object Space
– Copy/Paste Object Space
– Create Object
– Import Object
– Create Object Space
v Access Control List (ACL):
– List ACLs
–
–
–
–
© Copyright IBM Corp. 1999, 2010
Create ACL
Import ACL
Export All ACLs
List Action Groups
23
– Create Action Group
v Protected Object Policy (POP):
– List POPs
– Create POP
– Import POP
– Export All POPs
v Authorization (AuthzRules):
– List AuthzRules
– Create AuthzRule
– Import AuthzRule
– Export All AuthzRules
v Global Sign-On (GSO) Resources:
– List GSOs
– Create GSO
– List GSO Groups
– Create GSO Groups
v Secure Domain:
– List Secure Domains
– Create Secure Domain
Role name: wpmregistryadmin
wpmregistryadmin is a Web Portal Manager registry administrator
role. The following is a list of tasks that the wpmregistryadmin role
performs:
v User tasks:
– Search Users
–
–
–
–
Create User
Import User
Show Global User Policy
Change My Password
v Group tasks:
– Search Groups
– Create Group
– Import Group
Role name: wpmwebsealadmin
wpmwebsealadmin is a Web Portal Manager WebSEAL administrator
role. The following is a list of tasks that the wpmwebsealadmin role
performs:
v
v
v
v
v
List Junctions
Create Junctions
List Virtual Host Junctions
Create Virtual Host Junctions
Dynamic URL Files
Role name: wpmdelegateadmin
wpmdelegateadmin is a Web Portal Manager delegate administrator
role. The following is a list of tasks that the wpmdelegateadmin role
performs:
24
Administration Guide
v
v
v
v
Manage Enterprise Domains
Manage Roles
Domain User Search
Change My Password
Web Portal Manager is not installed as part of the Tivoli Access Manager
runtime. To use Web Portal Manager, you must install it separately. The
Integrated Solutions Console is automatically installed when you install
WebSphere Application Server.
Note: For complete installation instructions, see the IBM Tivoli Access
Manager for e-business: Installation Guide.
Although you can manage your enterprise using either interface, only a subset of
the management tasks can be performed using Web Portal Manager. To compare
the mapping between the pdadmin utility and Web Portal Manager tasks, see
Appendix E, “pdadmin to Web Portal Manager equivalents,” on page 337.
Another difference between these interfaces is that when you use the pdadmin
utility, you can specify a file. When using Web Portal Manager, you cannot specify
a file name. In some cases, however, you can copy and paste the contents of the
file.
This chapter contains the following sections:
v “Types of administration”
v “Delegate administration tasks”
v “Web Portal Manager common tasks” on page 26
v “Customizing the Web Portal Manager interface” on page 28
v “Self-registration tasks” on page 28
Types of administration
Tivoli Access Manager provides two types of administration:
v Administration
v Delegate administration
You can use Web Portal Manager to perform both types of tasks. The administrator
uses the same URL to connect to Web Portal Manager for both administration and
delegate administration.
Delegate administration tasks
Web Portal Manager delegate administration provides a Web-based interface that
includes a set of delegated management services. The delegated management
services enable a business to delegate user administration, group and role
administration, security administration, and application access provisioning to
participants (subdomains) in the business system. These subdomains can further
delegate management and administration to trusted subdomains under their
control, thus supporting multilevel delegation and management hierarchy based on
roles.
The delegate administration supports the following operations:
v Creation of multiple enterprise domains
Chapter 2. Web Portal Manager
25
v Assignment of users to be domain administrators
v Assignment of administrator types (such as: Tivoli Access Manager
Administrator, Domain Administrator, Senior Administrator, Administrator, and
Support Administrator) and enforcement of the administrative tasks that can be
performed with each administrator type
v Use of self-registration, meaning to become a registered Tivoli Access Manager
user without the involvement of an administrator, and self-care to reduce the
administration load.
Refer to Chapter 16, “Delegated administration,” on page 183 for a complete
description of Tivoli Access Manager delegate administration tasks.
Self-care
Web Portal Manager deployments can grow to support large number of users. As
the number of users grows, so does the number of administrators required to
manage these users. Self-registration and self-care are features of the Web Portal
Manager that can be used to reduce the administration load.
Web Portal Manager supports self-care operations by allowing Tivoli Access
Manager users to change their Tivoli Access Manager password through Web
Portal Manager. Users can go to the Web Portal Manager delegate administration
page and manage their passwords. After logging in, the user must go to the
Change My Password task.
Self-registration
Self-registration is the process by which a user can enter required data to become a
registered Tivoli Access Manager user, without the involvement of an
administrator.
Web Portal Manager includes a sample application that allows end users to
perform self-registration. This sample is supported only on an LDAP registry, not
Domino® or Active Directory.
Included with Web Portal Manager is sample code that implements a
self-registration page. The sample code shows how to use the Tivoli Access
Manager Java Administration APIs along with Java 2 Platform, Enterprise Edition
(J2EE) servlets and Java Server Pages (JSPs) to implement self-registration. See
“Self-registration tasks” on page 28.
Web Portal Manager common tasks
This chapter provides procedures for the more common Web Portal Manager tasks,
such as:
v “Starting Web Portal Manager”
v “Logging in and signing off” on page 27
v “Accessing online help” on page 27
Starting Web Portal Manager
Before starting Web Portal Manager, ensure that the WebSphere Application Server
is running. While the WebSphere server is running, use one of the following Web
addresses to start Web Portal Manager for administration:
v If you installed, configured, and enabled SSL or FIPS, type the following Web
address:
26
Administration Guide
https://hostname:9043/ibm/console
where hostname is the machine where IBM HTTP server and WebSphere
Application Server are running, and 9043 is the secured port for the Integrated
Solutions Console.
For example:
https://testgroup.austin.ibm.com:9043/ibm/console
Note: For information about enabling FIPS in a WebSphere environment, see the
WebSphere Application Server documentation.
v If you do not have SSL or FIPS installed, configured, and enabled, type the
following Web address:
http://hostname:9060/ibm/console
where hostname is the machine where IBM HTTP server and WebSphere
Application Server are running, and 9060 is the non-secured port for the
Integrated Solutions Console.
For example:
http://testgroup.austin.ibm.com:9060/ibm/console
The Web Portal Manager delegate administration tasks are accessed from the same
Web address as are the Web Portal Manager administration tasks. Users can go to
the Web Portal Manager delegate administration page and manage their
passwords. After logging in, the user must select Delegate Administration >
Change My Password.
Logging in and signing off
To log in to Web Portal Manager, complete the following steps:
1. Launch the Integrated Solutions Console.
2. Provide the appropriate user name, and click Log in.
3. In the navigation panel, expand Tivoli Access Manager, and then expand Web
Portal Manager or Delegate Administration, depending on the tasks you need
to perform.
4. In the navigation pane, click a task to display the Web Portal Manager Sign On
fields.
5. Provide Web Portal authentication, such as the following information, and then
click Sign On:
v Name of the domain in which you want to perform tasks
v User name
v Password associated with the user name
6. After the Tivoli Access Manager splash screen appears in the content pane,
select and perform tasks, as needed.
Note: After a certain period of inactivity, the system might prompt you to log
in again.
7. Click Logout at the top right of the Integrated Solutions Console to terminate
the session and log out of the Integrated Solutions Console.
Accessing online help
Instructions for completing tasks using Web Portal Manager are documented in the
online help system. Refer to the help system when you enter information in fields
or select or clear choices.
Chapter 2. Web Portal Manager
27
To
1.
2.
3.
access online help, complete the following steps:
Use Web Portal Manager to log in to the domain.
Select a task such as Group → Import Group.
In the task title bar, click the question mark icon on the right side of the page.
A help window contains the online information for completing the task.
4. Close the help window after you complete the task.
Customizing the Web Portal Manager interface
Web Portal Manager allows you to customize the interface. You can customize the
branding of Web Portal Manager by modifying the configuration to specify which
Web page (HTML or JSP file) or image (GIF file) must be loaded when Web Portal
Manager starts.
Customizing the images
Customizing images in Web Portal Manager consists of placing new replacement
images where the default images are currently located. To customize the images for
Web Portal Manager, complete the following steps:
1. Change the value of the following entries in the amconf.properties
configuration file to specify the new images to display:
loginGif
Shows the specified image on the login page. The default value is
accessmanager.gif.
splashGif
Shows the specified image on the welcome page, after the login page.
The default value is accessmanager.gif.
2. Place the new images in the following directory for administration:
For Linux and UNIX operating systems
websphere_install_dir/WebSphere/AppServer/systemApps/isclite.ear/
iscwpm.war/images/en
For Windows operating systems
websphere_install_dir\Program Files\IBM\WebSphere\AppServer\
systemApps\isclite.ear\ iscwpm.war\images\en
where websphere_install_dir is the directory where WebSphere is installed.
3. For locale-specific versions of these images, create a locale-specific subdirectory
under the /images directory and place the new images in this subdirectory.
4. Restart the WebSphere server.
Self-registration tasks
Tivoli Access Manager provides a self-registration sample to demonstrate how it
works.
Note: This sample is supported only when your Tivoli Access Manager user
registry is an LDAP user registry. You cannot perform self-registration tasks
for an IBM Lotus® Domino or a Microsoft Active Directory user registry.
Performing self-registration
One possible scenario for implementing self-registration is where a user opens a
Web browser to view a self-registration Web page. On this Web page, the user
28
Administration Guide
enters specific identification information (either company-specific or user-specific)
with a Tivoli Access Manager user ID and password. The identification information
provided by the user is then validated and the user is created in the Tivoli Access
Manager registry.
Because users do not typically have permission to create objects in Tivoli Access
Manager, the self-registration sample requires the ID and password of an
administrator who has permission to create users. This login information is then
used to create users when somebody enters the required information about the
registration page.
The following information is requested the first time the self-registration sample is
accessed. This data is saved by the servlet in memory and then used to create
users who request to be registered.
v Administrator name
v Password
v Registry container
The administrator name and password must be the name of an administrator who
has permission to create users in Tivoli Access Manager. The sec_master
administrator has the proper access by default. The Registry Container field must
be the base name in LDAP where user entries must go. This value is used to
construct the distinguished name (DN) of self-registered users.
For example, enter o=ibm,c=us and the registered users are created in LDAP as,
cn=FirstnameLastname,o=ibm,c=us. The user is not added to any groups. In a real
application, the user would probably be added to some groups to have access to
some applications. After the administrator information is entered, this page is not
shown again. If you access the sample, you are shown only the registration page
where you can enter the given name, family name, and a password.
The administrator login is saved in the servlet session. Any user who accesses the
self-registration sample from the same browser can create a user in Tivoli Access
Manager. You must restart the application server to clear the administrator login
information.
For this sample, the ID and password are not saved in a secure manner. If you use
this sample as the basis for a production registration application, you must
consider ways to secure the administrator login information.
Changing Java Server Pages
The provided sample application includes the following Java Server Pages (JSPs):
regAdmin.jsp
The page that is displayed to gather login information for the
administrator.
regProp.jsp
The page that is displayed to gather the given name, family name, and
password of the user.
regControl.jsp
The code that creates the user. This page receives and processes the
registration requests. This page could also be a servlet class.
The files are installed in the following directory:
Chapter 2. Web Portal Manager
29
For Linux and UNIX operating systems
websphere_install_dir/WebSphere/AppServer/profile/profile_name/
installedApps/cell_name/TAMWPM.ear/pdadmin.war/images/
register.war/register
For Windows operating systems
websphere_install_dirProgram Files\IBM\WebSphere\AppServer\profile\
profile_name\ installedApps\cell_name\TAMWPM.ear\register.war\ register
where websphere_install_dir is the directory where WebSphere is installed,
profile_name is the name of the application profile, and cell_name is the name of the
WebSphere cell.
When the administrator login information is entered, a PDContext object is created
and stored in the user servlet session as shown in the following code sample:
String adminid = request.getParameter("admin");
String adminPassword = request.getParameter("password");
String ldapSuffix = request.getParameter("suffix");
...
// Try a login
try {
ctx = new PDContext(adminid,
adminPassword.toCharArray(),
url);
// Save the PDcontext and the LDAP Suffix
session.setAttribute("regAdminCtx", ctx);
session.setAttribute("ldapSuffix", ldapSuffix);
}
catch(PDException e) {
// process exception
...
}
After the user enters the new user information, the PDContext object is retrieved
from the session and used to create the user as shown in the following code
fragment:
// Creating the Access Manager User
pwd = request.getParameter("password");
ldapcn = request.getParameter("ldapcn");
ldapsn = request.getParameter("ldapsn");
ldapdn = "cn=" + ldapcn + ldapsn + "," + ldapSuffix;
userid = ldapcn + ldapsn;
desc = ldapcn + " " + ldapsn;
ctx = (PDContext)session.getAttribute("regAdminCtx");
// Make sure the session has not timed out
if ( ctx == null ) {
%>
<%@ include file="regAdmin.jsp" %
<%
return;
}
PDMessages messages = new PDMessages();
try {
createUser(bundle, ctx, userid, pwd, desc, ldapcn,
ldapsn, ldapdn, usergroups, acc_valid,
pwd_valid, gso_user, no_pwd_pol,
messages);
succmsg = userid +
ResourceFile.getString(bundle,
"userRegisteredMsg");
}
30
Administration Guide
catch(PDException e) {
// process exception
...
}
The new user ID is the given name and family name concatenated together.
Chapter 2. Web Portal Manager
31
32
Administration Guide
Chapter 3. Tivoli Access Manager administration
The administration of Tivoli Access Manager involves the following major tasks:
1. Creating domains and subdomains for management purposes, as necessary.
2. Install and configure resource managers. All the Tivoli Access Manager resource
managers, such as WebSEAL or Tivoli Access Manager for Operating Systems,
and other components, such as plug-ins for Web Server, automatically create a
protected object space and create the required protected resources (also known
as protected objects) when they are configured.
3. Create additional object spaces, as needed, for management purposes.
4. Define protected objects in the object space, as needed, to represent the
resources that are to be protected. For protected objects, you can define the
following characteristics:
v Who is allowed access.
v What type of access is permitted.
v When that access is allowed.
v What other conditions that must be met before permitting access.
v Whether the access request is audited.
5. Define users and groups that require access to the protected resources.
6. Implement your security policy by attaching an access control list (ACL) policy, a
protected object policy (POP), and an authorization rule to objects in the
protected object space.
Domains
A domain consists of all the resources that require protection along with the
associated security policy used to protect those resources. The resources that you
can protect depend on the resource managers that are installed. Depending on the
resource managers that are installed, these resources can be any physical or logical
entity, including objects such as files, directories, Web pages, printer and network
services, and message queues. Any security policy that is implemented in a
domain affects only the objects in that domain. Users with authority to perform
tasks in one domain do not necessarily have the authority to perform those tasks
in other domains.
Tivoli Access Manager creates a domain, referred to as the management domain, as
part of its initial configuration. The default name of this management domain is
Default, and by default it is located in a stand-alone naming context, a suffix
called secAuthority=Default. This domain is used by Tivoli Access Manager to
manage the security policy of all domains and is available for managing other
protected resources as well. The administrator can rename the management
domain and change its location when the Policy Server is configured.
For small and moderately sized enterprises, one domain is typically sufficient. If
only one domain is needed, no explicit action needs to be taken.
In large enterprises, however, you might want to define two or more domains.
Each domain is given a name and is established with a unique set of physical and
logical resources. The security administrator can define the resources in a domain
based on geography, business unit, or major organizational division within the
© Copyright IBM Corp. 1999, 2010
33
enterprise. The security policy defined in the domain affects only the resources in
that domain, which allows data to be partitioned and managed independently.
A multiple domain environment can be invaluable when there is a business need
to keep a physical separation between different sets of data. The following other
benefits are associated with using multiple domains:
Increased security
Security policy data for each domain is mutually exclusive. Users, groups,
and resources that are defined within a domain cannot be associated with
another domain. For example, suppose that a user named John Doe is
identified as JohnDoe in the Sales domain and as JDoe in the Advertising
domain. Although the same person, each user ID is unique for each
domain. Therefore resources available to user JohnDoe can be granted
access only by the unique identity by which the user is defined in that
domain (Sales) or by groups that are defined in the Sales domain that
JohnDoe is a member of. Likewise, user JDoe, even though it is the same
person, can be granted access only by the unique identity by which the
user is defined in the Advertising domain.
Simplified administration
You can assign independent administrators to handle policy management
tasks for each domain. For example, assume that you are an IT specialist
for a large corporation, assigned to deploy Tivoli Access Manager from a
single data center. You could create a separate domain (with a unique
policy database and an administrator) for each organization, division, or
geographic area in your company. As users, groups, or resources change,
the assigned administrator is responsible for updating the security policy
for that particular domain. This domain administrator can also delegate
administration tasks to others within that specific domain.
An administrator assigned to a specific domain has authority only within that
domain. However, by default, an administrator can view users and groups defined
in the user registry that are not necessarily Tivoli Access Manager users or groups.
This feature is beneficial if, for example, an administrator wants to import a user
or group from a different domain. Conversely, if you are the administrator of the
management domain and want to limit the registry data that a domain
administrator can access, you can add the allowed-registry-substrings stanza
entry to the [domains] stanza in the ivmgrd.conf configuration file for the policy
server.
For more information about managing domains, see Chapter 5, “Managing
domains,” on page 61.
Protected object space
Tivoli Access Manager represents resources within a domain using a virtual
representation called the protected object space. The protected object space is the
logical and hierarchical portrayal of resources belonging to a domain.
The structure of the protected object space consists of two types of objects:
Resource objects
Resource objects are the logical representation of actual physical resources,
such as files, services, Web pages, message queues, and so on, in a domain.
34
Administration Guide
Container objects
Container objects are structural components that allow you to group
resource objects hierarchically into distinct functional regions.
Security policy can be applied to both types of objects. Figure 11 shows a logical
representation of a protected object space with multiple container and resource
objects. This illustration shows container objects as white boxes and resource
objects as gray boxes.
Container objects
Resource objects
Figure 11. Tivoli Access Manager protected object space
The structural top of the protected object space is the root container object. Below the
root container object are one or more container objects. Each container object
represents an object space that consists of a related set of resources. These
resources can be resource objects or container objects.
The installation of Tivoli Access Manager creates the /Management object space. This
object space consists of the objects that are used to manage Tivoli Access Manager
itself. Under the /Management object space, the installation creates the following
container objects:
v /Users
v /Groups
v /POP
v /Action
v /ACL
v /GSO
v /Server
v /Config
v /Replica
Figure 12 on page 36 shows the complete /Management object space that is created
during the installation of Tivoli Access Manager.
Chapter 3. Tivoli Access Manager administration
35
/ (root)
Management
Users
Groups
GSO
Server
Action
POP
Config
ACL
Replica
Figure 12. Regions of the Tivoli Access Manager protected object space
Each resource manager that protects a related set of resources creates its own object
space. For instance, the installation of the WebSEAL component creates the
/WebSEAL object space, and Tivoli Access Manager for Operating Systems creates
the /OSSEAL object space.
Users and groups
Tivoli Access Manager maintains information about Tivoli Access Manager users
and groups in the user registry. In you have a user registry that maintains users
and groups for another application, you can import this user registry information
into Tivoli Access Manager. If a required user or group was not in the user registry
before it was imported into Tivoli Access Manager or a new user or group needs to
be added to the Tivoli Access Manager user registry, you can create it using Tivoli
Access Manager.
Tivoli Access Manager supports two types of group definitions. The most common
type of group maintains the group membership as an explicit list of members
(users). This type of group is sometimes referred to as a static group, because the
membership is listed and maintained.
For Active Directory and LDAP registry users, Tivoli Access Manager also supports
the use of dynamic groups. Dynamic groups are groups whose members are
automatically resolved when the group is accessed. This resolution is based on the
results of a defined search filter. For example, you create a dynamic group for
members of department XYZ. If you import a new user whose data matches an
entry in the search filter, the user is automatically added to the group. If an
existing employee switches department, the user is automatically removed from
the group. Manual intervention is not required.
The creation and management of a dynamic group can be complex and is specific
to the vendor implementation, because it requires a search-like filter to be specified
and used for group membership resolution. Because of these variables, dynamic
groups cannot be created or maintained using Tivoli Access Manager utilities or
user interfaces. The vendor-specific tools must be used to create and maintain
dynamic groups. Tivoli Access Manager, however, can import and use these
dynamic groups after they are created.
Tivoli Access Manager supports different types of users. When a domain is created,
a special user known as the domain administrator is created. For the management
domain, the domain administrator is sec_master. The sec_master user and
36
Administration Guide
associated password are created during the configuration of the Tivoli Access
Manager policy server. For other domains, the user ID and password of the
domain administrator are established when the domain is created. The domain
administrator has nearly complete control of the domain. Think of the domain
administrator as the Tivoli Access Manager equivalent to the Linux or UNIX root
account or the Microsoft Windows Administrator user.
The domain administrator is added as a member of the Tivoli Access Manager
iv-admin group within the domain. The iv-admin group represents those users
with domain administration privileges. When adding users to the iv-admin group,
ensure that you do not compromise the security of your domain.
Security policy
Access to objects in a domain is controlled by attaching security policy to objects in
the protected object space. After attaching a security policy to an object, any
change to the security policy is reflected immediately throughout the domain. Each
security policy can be defined using a combination of the following controls:
Access control list policies
An access control list (ACL) policy specifies what set of predefined actions
that a set of users and groups can perform on an object. For example, a
specific set of groups or users can be granted read access to an object.
Protected object policies
A protected object policy (POP) specifies access conditions that are
associated with an object. A POP affects all users and groups. For example,
a time-of-day restriction can be placed on an object that excludes all users
and groups from accessing that object during the specified time.
Authorization rules
An authorization rule specifies a complex condition that is evaluated to
determine whether access is permitted. The data used to make this
decision can be based on the context of the request, the current
environment, or other external factors. For example, a request to modify an
object more than five times in an eight-hour period could be denied.
Security policy can be explicitly applied to an object or can be inherited by an
object that is above it in the hierarchy. Apply an explicit security policy in the
protected object space only at those points in the hierarchy where the security
policy must change.
Security policy is implemented by strategically attaching ACL policies, POPs, and
authorization rules to objects that require protection. The Tivoli Access Manager
authorization service decides whether to permit or deny access to objects based on
the credentials of the user that is making the request and the specific permissions
and conditions that are set in the ACL policies, POPs, and authorization rules.
The authorization service uses the following algorithm to process the security
policy that is attached to a protected object:
1. Check permissions in the ACL policy to determine whether the user can
override the attached POP or authorization rule. See “Evaluating ACL policies”
on page 39 for information about the evaluation process.
2. When there is an authorization rule attached and the user cannot override it,
gather the Access Decision Information (ADI).
3. When there is a POP attached, check the Internet Protocol (IP) endpoint
authentication method policy.
Chapter 3. Tivoli Access Manager administration
37
4. When there is a POP attached, check the time-of-day policy.
5. When there is a POP attached, check the audit-level policy, and audit the access
decision.
6. When an authorization rule is attached and the user cannot override the
authorization rule, check the authorization rule policy.
7. When an external authorization service (EAS) operation or a POP trigger
applies to this access decision, invoke the EAS.
If any of the ACL policy, POP, or authorization rule evaluations fail, the access
request is denied. The EAS can override this decision on its own, if it was
designed to do.
ACL policies
The policy that defines who has access to an object, and what operations can be
performed on the object, is known as the ACL policy. Each ACL policy has a
unique name and can be applied to multiple objects within a domain.
An ACL policy consists of one or more of the following entries descriptions:
v The names of users and groups whose access to the object is explicitly controlled
v The specific operations permitted to each user, group, or role
v The specific operations permitted to the special any-other and unauthenticated
user categories
Using ACL policies with the authorization service
Tivoli Access Manager relies on ACL policies to specify the conditions necessary
for a particular user to perform an operation on a protected object. When an ACL
policy is attached to an object, entries in the ACL specify what operations are
allowed on this object and who can perform those operations.
Tivoli Access Manager uses a default set of actions that cover a wide range of
operations. Actions, or permissions, are represented by single alphabetic ASCII
characters (a-z, A-Z). Each permission is displayed (by the pdadmin utility or Web
Portal Manager) with a label describing the operation it governs. In addition, the
Web Portal Manager groups the ACL policies according to their use in a particular
part of the object space (such as WebSEAL) or their use across the entire object
space (Base, Generic).
A resource manager software typically contains one or more operations that are
performed on protected resources. Tivoli Access Manager requires that resource
managers make calls to the authorization service before the requested operation is
allowed to progress. This call is made through the authorization application
programming interface (authorization API) for both Tivoli Access Manager services
and other applications.
The authorization service uses the information contained in the ACL entry to make
a simple “yes” or “no” response to the following question:
Does this user or group have the appropriate permission to perform the
requested operation on the requested object? For example, does the user have
the view (r) permission to view an object?
38
Administration Guide
The authorization service has no knowledge about the operation requiring the read
(r) permission. It is merely noting the presence or absence of the r action bit in the
ACL entry of the requesting user or group.
The authorization service is independent of the operations being requested. This
independence is why it is easy to extend the benefits of the authorization service to
other applications.
Evaluating ACL policies
Tivoli Access Manager follows a specific evaluation process to determine the
permissions granted to a particular user by an ACL policy. When you understand
this process, you can determine how best to keep unwanted users from gaining
access to resources.
Evaluating authenticated requests
Tivoli Access Manager evaluates an authenticated user request in the following
order:
1. Match the user ID with the user ACL entries. The permissions granted are the
permissions in the matching entry.
Successful match
Evaluation stops here.
Unsuccessful match
Continue to the next step.
2. Determine the groups to which the user belongs and match group ID with the
group ACL entries. If more than one group entry is matched, the resulting
permissions are a logical “or” operation (most permissive) of the permissions
granted by each matching entry.
Successful match
Evaluation stops here.
Unsuccessful match
Continue to the next step.
3. Grant the permissions of the any-other entry, if it exists.
Successful match
Evaluation stops here.
Unsuccessful match
Continue to the next step.
4. An implicit any-other entity exists when there is no any-other ACL entry. This
implicit entry grants no permissions.
Successful match
No permissions granted. End of evaluation process.
Evaluating unauthenticated requests
Tivoli Access Manager evaluates an unauthenticated user by granting the
permissions from the unauthenticated ACL entry.
The unauthenticated entry is a mask (a bit-wise “and” operation) against the
any-other entry when permissions are determined. A permission for
unauthenticated is granted only if the permission also appears in the any-other
entry.
Because unauthenticated depends on any-other, it makes little sense for an ACL
entry to contain unauthenticated without any-other. If an ACL entry contains
unauthenticated without any-other, the default response is to deny permissions to
unauthenticated.
Chapter 3. Tivoli Access Manager administration
39
Protected object policies
A protected object policy (POP) specifies security policy that applies to an object
regardless of what user or what operation is being performed. Each POP has a
unique name and can be applied to multiple objects within a domain.
The purpose of a POP is to impose access conditions on an object based on the
time of the access and to indicate whether the access request must be audited.
Specifically, the conditions you can apply are:
v POP attributes, such as warning mode, audit level, and time-of-day.
More details about these attributes are in “Configuring POP attributes” on page
111.
v Authentication strength POP (step-up).
More details about this policy are in “Step-up authentication” on page 114.
v Quality of Protection POP.
More details about this policy are in “Setting a Quality of Protection level” on
page 114.
v Network-based authentication POP.
More details about this policy are in “Network-based authorization policy” on
page 110.
Authorization rules
An authorization rule policy specifies security policy that applies to an object
based on various conditions, such as context and environment. Each authorization
rule policy has a unique name and can be applied to multiple objects within a
domain.
Like ACL policies and POPs, authorization rules are defined to specify conditions
that must be met before access to a protected object is permitted. An authorization
rule is created using a number of conditions that are based on data supplied to the
authorization engine within the user credential, from the resource manager
application or from the encompassing business environment. These conditions are
evaluated as a Boolean expression to determine if access to the object must be
granted or denied.
The language of an authorization rule allows you to work with complex,
structured data. You can examine values in the rule data and make informed
access decisions. The data used in an access decision can be defined statically
within the system or defined during a business process. Rules give you the
flexibility of the policy defined by an external authorization service without
requiring that you develop and build the logic of an external authorization service
into a shared library plug-in.
How authorization rules differ
ACL policies take a given predefined set of operations and control which users and
groups have permission to perform those operations on a protected object. For
example, the ability of a user to read data associated with an object is either
granted or denied by an ACL policy. POPs apply to all users and groups and
control conditions that are specific to a particular protected object. For example,
time-of-day access excludes all users and groups from accessing an object outside
of the times set in the time-of-day policy.
40
Administration Guide
Rules allow you to make decisions based on the attributes of a person or object
and the context and environment surrounding the access decision. For example,
you can use a rule to implement a time-of-day policy that depends on the user or
group. You also can use an authentication rule to extend the controls that are
provided by the ACL policies by implementing a more advanced policy, such as
one based on quotas. An ACL policy can grant a group permission to write to a
resource. A rule can go a step further by allowing you to determine if a group has
exceeded a specific quota for a given week before permitting that group to write to
a resource.
When to use authorization rules
In the Tivoli Access Manager authorization process, the entire security policy (ACL
policies, POPs, and authorization rules) must permit access to the protected object
before access is granted. Authorization rules provide the flexibility needed to
extend an ACL policy or POP by tailoring security policy to your needs.
Authorization rules can be used to extend the policy implemented by other Tivoli
Access Manager policy types. However, these are not simply extensions of the
existing policy types. An authorization rule is a policy type that is rich enough in
functionality to replace the ACL policy and POP. However, using ACL policies and
POPs generally provides better performance. Therefore, use a rule to complement
these policies instead of replacing them.
Guidelines for a secure object space
The following guidelines are applicable for a secure object space:
v Set high-level security policy on container objects at the top of the object space.
Set exceptions to this policy with explicit ACL policies, POPs, and authorization
rules on objects that are lower in the hierarchy.
v Arrange your protected object space so that most objects are protected by
inherited, rather than explicit, ACL policies, POPs, and authorization rules.
Reduce the risk of an error that could compromise your network by simplifying
the maintenance of your tree. Inherited security policy lowers maintenance
because it reduces the number of ACL policies, POPs, and authorization rules
that you must maintain.
v Position new objects in the tree where they inherit the appropriate permissions.
Arrange your object tree into a set of subtrees, where each subtree is governed
by a specific access policy. You determine the access policy for an entire subtree
by setting explicit ACL policies, POPs, and authorization rules at the root of the
subtree.
v Create a core set of ACL policies, POPs, and authorization rules, and reuse these
policies wherever necessary.
ACL policies, POPs, and authorization rule policies are a single-source
definition. So any modification to the policy impacts all objects associated with
the ACL policy, POP, or authorization rule.
v Control user access through the use of groups.
It is possible for an ACL policy to consist of only group entries. Individual user
entries are not required in the ACL policy when the users can be categorized
into groups instead. Authorization rules can also be written to consider any
group memberships of an individual rather than the individual specifically. This
feature can reduce the complexity of the rule logic considerably.
Access to an object by individual users can be efficiently controlled by adding
users to or removing users from these groups.
Chapter 3. Tivoli Access Manager administration
41
42
Administration Guide
Chapter 4. Default security policy
Tivoli Access Manager establishes a default security policy to protect all objects in
a domain. A set of administrative users and groups is established and granted a
predefined set of permissions. The default security policy is described in this
chapter.
Default administration users and groups
At installation, Tivoli Access Manager provides several important administration
groups. By default, these users and groups are given special permissions to control
and manage all operations in a domain. This default security policy is defined by
the access control lists (ACLs) created during configuration.
The following sections detail the specific roles assigned to each of these users and
groups at installation time, and explain how to create administration users.
iv-admin group
This group represents the administrator group. All members of this group are
considered administrators of the domain by the default policy.
You can easily place users into an administration role by adding them to the
iv-admin group. The danger with this procedure is that as soon as a user becomes
a member of this group (with the default ACLs), that user has full rights to
perform administration operations on any object in the protected object space.
When the policy server is configured, the administrator (sec_master) user is
created and added to the iv-admin group. It is the combination of group
memberships that grants sec_master complete rights for all operations within the
management domain but only within the default policy. The sec_master user does
not have rights to new groups created outside of the default policy unless it is
added as a user or a member of a group.
sec_master user
The sec_master user is created when Tivoli Access Manager is initially installed
and configured. The default policy makes the sec_master user a member of the
iv-admin group, permitting it to perform all actions within Tivoli Access Manager.
Think of this account as the equivalent of the Linux or UNIX root account, or a
member of the Microsoft Windows Administrator group.
ivmgrd-servers group
The ivmgrd-servers group contains the policy servers and the policy proxy servers.
By default, members of this group are authorized to delegate requests to other
Tivoli Access Manager servers on behalf of the requestor.
Administration users
You can create administration accounts with varying degrees of responsibility.
Responsibility is delegated to administrators through strategically placed
administration ACLs.
The following list illustrates possible administration roles:
© Copyright IBM Corp. 1999, 2010
43
Security policy administrator
Security policy administrators are responsible for defining and organizing
security policy in a domain. The administrator needs to be able to create,
modify, and delete security policy. To perform these tasks, these
administrators need the following permissions on the /Management/ACL,
/Management/POP, and /Management/Rule resources:
v Traverse (T)
v Browse (b)
v View (v)
v Modify (m)
v Delete (d)
These administrators need the following permissions to navigate their
subtree of protected resources:
v Traverse (T)
v Browse (b)
v View (v)
These administrators need the following permission to ability to attach and
detach security policy to the same subtree:
v Attach (a)
These administrators must have the following permissions so as not to be
affected by security policies that apply to all users for the same subtree.
v Bypass POP (B)
v Bypass rule (R)
Protected resource administrator
Protected resource administrators are responsible for adding and removing
user access to one or more protected resources. These tasks include:
v Adding users to and removing users from groups that are defined in the
security policy
v Adding permissions to and removing permissions from resources
These administrators need the following permission on the
/Management/Groups protected resource or on the individual groups that are
defined in the /Management/Groups subtree:
v Traverse (T)
v Browse (b)
v View (v)
v Add (A)
Deployment administrator
Deployment administrators are responsible for installation and
configuration of the resource managers in the domain.
These administrators need the following permissions on the
/Management/Server protected resource:
v Traverse (T)
v Browse (b)
v View (v)
v Modify (m)
v Delete (d)
These permissions give the ability to configure resource managers into and
out of the domain as well as update their configuration.
44
Administration Guide
Defining and applying security policy
Security administrators protect system resources by defining a security policy. A
security policy consists of the access control list (ACL) policies, protected object
policies (POPs), and authorization rules that can be applied to the object
representations of the system resources to be protected in the object space. You can
apply ACL policies, POPs, and authorization rules to the same object.
The authorization service performs authorization decisions based on the policies
applied to these objects. When a requested operation on a protected object is
permitted, the resource manager responsible for the resource implements this
operation.
One policy can dictate the protection parameters of many objects. Any change to
an ACL policy, POP, or authorization rule affects all objects to which the policy is
attached.
ACL policies
An ACL policy is the set of controls (permissions) that specifies the conditions
necessary to perform certain operations on that resource. ACL policies are
important components of the security policy that is established for the domain.
ACL policies, like all policies, are used to stamp the set of security standards for an
organization on the resources that are represented in their protected object spaces.
An ACL policy provides the following controls:
v What operations can be performed on an object or resource
v Who can perform an operation
An ACL policy is made up of one or more entries that include user and group
designations and their specific permissions.
ACL
user
peter
---------T---rx
user
michael
---------T---rx
group
engineering
---------T---rx
unauthenticated
---------------
Figure 13. ACL policy
Protected object policies
ACL policies provide the authorization service with information that results in a
yes or no answer on a request to access a protected object and perform some
operation on that object.
In contrast to ACL policies, protected object policies (POPs) contain additional
conditions on the request that are passed back to Tivoli Access Manager and the
resource manager along with the yes ACL policy decision from the authorization
server. It is the responsibility of Tivoli Access Manager and the resource manager
to enforce the POP conditions.
The following table lists the available attributes for a POP that are provided by
Tivoli Access Manager.
Chapter 4. Default security policy
45
Table 1. POP attributes that are enforced by Tivoli Access Manager
POP attribute
Description
Name
Name of the policy. This attribute relates to the pop-name
variable in the pop command documentation.
Description
Descriptive text for the policy. This attribute appears in
the pop show command.
Warning mode
Provides administrators a means to test ACLs, POPs, and
authorization rules. Warning mode provides a way to
test security policy before they are made active.
Audit level
Specifies the type of auditing: all, none, successful access,
denied access, or errors. Audit level informs the
authorizations service that extra services are required
when permitting access to the object.
Time-of-day access
Day and time restrictions for successful access to the
protected object. Time-of-day places restrictions on the
access to the object.
IP endpoint authorization
method policy
Specifies authorization requirements for access from
members of external networks. IP endpoint
authentication method policy places restrictions on the
access to the object.
EAS trigger attributes
Specifies an External Authorization Service (EAS) plug-in
that is invoked to make an authorization decision using
the externalized policy logic of the customer.
Quality of Protection
Specifies degree of data protection: none, integrity, or
privacy. Quality of Protections informs the authorizations
service that extra services are required when permitting
access to the object.
Although Tivoli Access Manager provides these POP attributes, it only enforces the
following attributes:
v Name
v Description
v Warning mode
v Audit level
v Time-of-day access
Each resource manager or plug-in can optionally enforce one or more of the
following attributes:
v IP endpoint authorization method policy
v EAS trigger attributes
v Quality of Protection
The concept of inherited, or sparse ACLs as described in “Sparse security policy
model” on page 47 also applies to POPs in the same manner.
Authorization rules
An authorization rule specifies the policy that applies to an object and that is based
on various conditions, such as context and environment. Each authorization rule
has a unique name and can be applied to multiple objects in a domain.
Like ACL policies and POPs, authorization rules are defined to specify conditions
that must be met before access to a protected object is permitted. An authorization
rule is created using a number of Boolean conditions that are based on data that is
46
Administration Guide
supplied to the authorization service within the user credential, from the resource
manager, or from the encompassing business environment. The language of an
authorization rule allows customers to work with complex, structured data, by
examining the values in that data, and making informed access decisions. This
information can be defined statically within the system or defined during a
business process. Authorization rules can be used to implement extensible
attribute-based authorization policy using attributes within the business
environment or attributes from trusted external sources.
The authorization rule is stored as a text rule within a rule policy object and is
attached to a protected object in the same way and with similar constraints as ACL
policies and POPs.
Sparse security policy model
To secure network resources in a protected object space, each object must be
protected by security policy.
You can assign security policy to an object in one of following ways:
v Attach an explicit security policy on the object.
v Allow the object to inherit its security policy from a preceding container object
in the hierarchy.
Adopting an inherited security scheme can greatly reduce the administration tasks
for a domain. This section discusses the concepts of inherited, or sparse security
policies.
Security policy inheritance
The power of security policy inheritance is based on the following principle:
Any object without an explicitly attached security policy inherits the policy of
its nearest container object with an explicitly set security policy. The
inheritance chain is broken when an object has an explicitly attached security
policy.
Security policy inheritance simplifies the task of setting and maintaining access
controls on a large protected object space. In a typical object space, you need to
attach only a few security policies at key locations to secure the entire object space.
Therefore, it is called a sparse security policy model.
A typical object space begins with a single explicit security policy attached to the
root container object. The root ACL must always exist and can never be removed.
Normally, the root ACL is an ACL with little restriction. All objects located in the
object space inherit this ACL.
When a region or subtree in the object space requires different access control
restrictions, you attach an explicit security policy at the root of that subtree. This
interrupts the flow of inherited security policies from the primary object space root
to that subtree. A new chain of inheritance begins from this newly created explicit
security policy.
Chapter 4. Default security policy
47
default-root ACL policy
During the installation and initial configuration of Tivoli Access Manager, the ACL
policy for the entire object space is created and explicitly set. This ACL policy is
the default-root ACL policy and includes the following users and permissions:
group iv-admin
any-other
unauthenticated
TcmdbvaBR
T
T
Tivoli Access Manager checks inheritance beginning with the root of the protected
object space. If you do not explicitly set an ACL policy on any other object in the
tree, the entire tree inherits this root ACL policy.
There is always an explicit ACL policy set at the root of the protected object space.
An administrator can replace this ACL policy with another ACL policy that
contains different entries and permission settings, but the administrator cannot
completely remove the root ACL policy.
Control permission
The control (c) permission is a powerful permission that gives you ownership of an
ACL policy. Ownership allows you to modify entries in the ACL policy. Being able
to modify entries in the ACL policy means that you can create entries, delete
entries, grant permissions, and take away permissions.
The administrator who wants to delete a permission from an ACL policy must
have an entry in that ACL policy and must have the control permission set in that
entry.
The control permission allows you to grant administration powers to another user,
such as the ability to attach or detach that ACL policy to objects. You must use the
control permission with great care, because of its powerful ownership properties.
Traverse permission
Tivoli Access Manager access control depends on the following conditions:
v The permission that controls the requested object must contain appropriate
access permissions for the requesting user.
v The requested object must be accessible to the requesting user. Accessibility to
protected objects is controlled by the traverse (T) permission.
The traverse permission is applied only to container objects in the protected object
space. The traverse permission specifies that a user or group that is identified in
the ACL entry has permission to pass through this container object to gain access
to a protected resource.
If there are no permissions defined for a user, that user cannot even traverse the
root container object. This user cannot gain access at all to the protected object
space, regardless of any permissions that might be granted lower in the tree.
A protected object is accessible if the requester possesses the traverse permission
on each ACL attached to container objects above the requested resource on the
path towards root and including root.
Figure 14 on page 49 illustrates how the traverse permission works. Within the
fictional ACME Corporation, there is an Engineering container object (directory),
which contains a TechPubs directory. Kate (user kate) is a member of the Sales
48
Administration Guide
department and requires traversing to the Engineering/TechPubs/ directory tree to
review a release note file (release_note). The administrator provides traverse for
any-authenticated at the root. The administrator provides traverse permission for
group sales on the Engineering directory. The TechPubs directory inherits the ACL
from the Engineering directory. Although Kate has no other permissions in these
two directories, she can pass (traverse) through these directories to access the
required file. Because this file has read permission for Kate, she can view the file.
ACME Corporation
/ (root)
Sales
Engineering
TechPubs
release_note
any-authenticated -------T---------
group sales
-------T---------
(ACL inherited)
user kate
---------------r-
Figure 14. Traverse permission
You can easily restrict access to the hierarchy below a given container object
without resetting individual permissions on these objects by deleting the traverse
permission from the appropriate ACL policy. Deleting traverse permission on a
directory object protects all objects lower in the hierarchy, even if those objects that
contain other less restrictive ACL policies.
For example, if sales group did not have the traverse permission on the
Engineering directory, user kate could not access the release_note file even
though the user has read permission for that file.
Resolving an access request
Inheritance begins at the root of the protected object space and impacts all objects
in the object space until it reaches an object with an explicit ACL policy. At this
point, a new chain of inheritance begins.
Objects below an explicitly set ACL policy inherit the new ACL policy. If you
delete an explicit ACL policy, permission for all objects reverts to the nearest
container object with an explicitly set ACL policy.
When a user tries to access a protected object (such as a document), Tivoli Access
Manager checks whether that user has the permissions to access the object. Tivoli
Access Manager checks each object along the object hierarchy for the proper
inherited or explicitly set permissions. A user is denied access to an object if any
container object in the hierarchy above the protected object does not include the
traverse permission for that user or is denied if the target object does not contain
sufficient permissions to perform the requested operation.
To succeed an access check, the requestor must have both of the following
permissions:
Chapter 4. Default security policy
49
v Permission to traverse the path to the requested object.
v Appropriate permissions on the requested object.
For example, to determine whether a user can read the report.html resource in the
/acme/engineering/project_Y/current/ object, Tivoli Access Manager performs the
following checks:
1. Whether traverse permission is set on the root (/).
2. Whether traverse permission is set on the acme, engineering, project_Y, and
current directories.
3. Whether read permission is set on the report.htmlfile.
If any of these checks fail, the user is denied access.
Applying ACL policies to different object types
Permissions for various operations can be set in an ACL policy. Only a subset of
these possible operations might be relevant for a specific object to which the ACL
policy is attached.
The reason for this behavior is related to the following Tivoli Access Manager
features that are designed to make administration easier:
v ACL policies
v ACL inheritance
ACL policies allow you to use the same set of permissions to multiple objects in
the protected object space. The ACL policy contains enough permissions to meet
the requirements of all objects to which the ACL applies. However, each individual
object might be affected by only a few of these permissions.
In an ACL inheritance model, any object without an explicitly attached ACL policy
inherits the policy definitions from the nearest attached ACL policy to an object
above it in the hierarchy.
In summary, an ACL policy has to describe the necessary permissions for all object
types to which it can apply, not just the object to which it is attached.
ACL policy inheritance example
Figure 15 on page 51 illustrates the impact of a mixture of inherited and explicit
ACL policies in the fictional ACME corporate object space.
A corporate object space has a general security policy set at the root object. Root is
followed by the /WebSEAL container object and individually controlled departmental
subtrees.
In this example, the sales group is given ownership of its departmental subtree.
The ACL policy on this subtree no longer acknowledges the unauthenticated or
any-other entry types.
The ytd.html file has an attached ACL policy that grants read permission to
members of the sales-vp group (who are also members of the sales group).
Note: This ACL policy scheme does not need to be changed when users are added
to or removed from the domain. Users can be added to or removed from the
50
Administration Guide
existing groups.
WebSEAL server
(www.acme.com/)
Production
Departments
Personnel
tele.html
staff.html
clientA.html
manager.html
products.html
sales.html
-abc---Tdm----lrx
-------T------l--a--g--Tdm----lrx
-----------------------T-------r-
group
group
group
group
-abc---Tdm----lrx
-------T------l--a--g--Tdm----lrx
-------T------lrx
Inventory
Sales
president.html
group iv-admin
group ivmgrd-servers
group webseal-servers
unauthenticated
any_authenticated
iv-admin
ivmgrd-servers
webseal-servers
sales
Note: group sales includes members of group sales-vp.
ytd.html
group
group
group
group
iv-admin
ivmgrd-servers
webseal-servers
sales-vp
-abc---Tdm----lrx
-------T------l--a--g--Tdm----lrx
-------T-------r-
Figure 15. ACL inheritance example
Default ACL policies
You can add entries for users, groups, any-other (any-authenticated), and
unauthenticated to provide a broader range of control and better meet the
requirements of your protected object space.
Users and groups with the control (c) permission own the ACL and have the
power to modify the ACL entries.
A detailed description of permissions can be found in “Default permissions in the
primary action group” on page 80.
The following default ACL policies are suggested starting points for securing
management operations in a domain:
v default-root
v default-management
v default-config
v default-gso
v default-policy
v default-domain
v default-management-proxy
default-root ACL policy
The ACL policy for the entire object space is the default-root ACL policy. This ACL
policy includes the following users and permissions:
group iv-admin
any-other
unauthenticated
TcmdbvaBR
T
T
Chapter 4. Default security policy
51
The default-root ACL policy is a basic policy that enables everyone to traverse the
object space, but they cannot perform any other actions. Typically, you would not
need to change this setting.
One useful function of the default-root ACL policy is that it allows you to quickly
deny access to the entire object space for an individual user or group. Consider the
following entry in the default-root ACL policy:
user john
-----------------
The user john has no permissions. So this user cannot even traverse the root
container object and cannot access the protected object space regardless of any
permissions that are granted lower in the tree.
default-management ACL policy
The default ACL policy of the /Management container object is the
default-management ACL policy. At installation, this ACL policy is attached to the
/Management container object in the object space. This ACL policy includes the
following users and permissions:
group iv-admin
group ivmgrd-servers
any-other
TcmdbsvaBtNWAR
Ts
Tv
default-replica ACL policy
The default ACL policy for the /Management/Replica container object is the
default-replica ACL policy. This ACL policy includes the following users and
permissions:
group
group
group
group
iv-admin
ivmgrd-servers
secmgrd-servers
ivacld-servers
TcbvaBR
m
mdv
mdv
default-config ACL policy
The default ACL policy for the /Management/Config container object is the
default-config ACL policy. This ACL policy includes the following users and
permissions:
Group iv-admin
Any-other
Unauthenticated
TcmdbsvaBR
Tv
Tv
default-gso ACL policy
The default ACL policy for the /Management/GSO container object is the default-gso
ACL policy. This ACL policy includes the following users and permissions:
group iv-admin
any-other
unauthenticated
TcmdbvaBNR
Tv
Tv
default-policy ACL policy
The default ACL policy for the /Management/Policy container object is the
default-policy ACL policy. This ACL policy includes the following users and
permissions:
group iv-admin
any-other
unauthenticated
52
Administration Guide
TcmdbvaBNR
Tv
Tv
default-domain ACL policy
The default ACL policy for the /Management/Domain container object is the
default-domain ACL policy. This ACL policy includes the following users and
permissions:
group iv-admin
TcmdbvaBNR
group ivmgrd-servers v
default-proxy ACL policy
The default ACL policy for the /Management/Proxy container object is the
default-proxy ACL policy. This ACL policy includes the following users and
permissions:
group iv-admin
Tcbv
group ivmgrd-servers Tg
/Management permissions
The /Management region of the protected object space contains multiple container
objects.
The following security considerations apply for the /Management region of the
protected object space:
v The /Management object begins the chain of permission inheritance for the entire
/Management region of the object space.
v If you do not apply any other explicit permission, this object defines, through
inheritance, the security ACL policy for the entire /Management object space.
v The traverse (T) permission is required for access to /Management.
The /Management region contains the following container objects that each requires
a specific set of permissions:
v “/Management/ACL permissions”
v “/Management/Action permissions” on page 54
v “/Management/POP permissions” on page 55
v “/Management/Server permissions” on page 55
v “/Management/Config permissions” on page 55
v “/Management/Policy permissions” on page 56
v “/Management/Replica permissions” on page 56
v “/Management/Users permissions” on page 56
v
v
v
v
v
“/Management/Groups permissions” on page 57
“/Management/GSO permissions” on page 58
“/Management/Rule permissions” on page 58
“/Management/Domain permissions” on page 59
“/Management/Proxy permissions” on page 59
/Management/ACL permissions
This object allows administration users to perform high-level ACL management
tasks that can affect the security policy for the domain.
Permission
Operation
d (delete)
Delete an existing ACL policy.
m (modify)
Create an ACL policy.
Chapter 4. Default security policy
53
Permission
Operation
v (view)
List and find view ACLs; show ACL details. This permission must be in
an entry of an ACL attached to /Management/ACL object.
The acl find command shows the list of protected resources where this ACL is
attached. You must have the view (v) permission on those protected resources
before they can be shown.
You must create ACL administrator entries in the effective ACL policy for the
/Management/ACL object. The ACL entry of an administrator might contain any of
the permissions listed in the table. These permissions give the administrator
powers to create, view, and delete ACL policies.
An ACL administrator cannot modify an existing ACL unless there is an entry in
that ACL for the administrator containing the control (c) permission. Only the
owner of an ACL can modify its entries.
The creator of a new ACL policy (m on /Management/ACL) becomes the first entry in
that ACL with the TcmdbsvaBIR permissions set by default.
For example, if sec_master is an administrator entry in the default-management
ACL, with m permission, sec_master can create an ACL policy. User sec_master
becomes the first entry in the new ACL, with TcmdbsvaBIR permissions.
Ownership of the default-management ACL itself is given to the iv-admin group
by default.
/Management/Action permissions
This object allows administration users to manage custom actions and action
groups. Action tasks and associated permissions include:
Permission
Operation
d (delete)
Delete an existing action or action group.
m (modify)
Create an action or action group.
To view an action or action group, no special permissions are required.
Resource managers can call the authorization service through the authorization
API. The following steps are required to integrate a resource manager with the
authorization service:
1. Define the object space for the resource manager
2. Define the action groups and actions for the resource manager
3. Apply permissions on resources and objects that need protection
The administrator of a resource manager object space can use the pdadmin utility
to define new permissions and actions. Resource managers generally define the
actions and action groups that are applicable to the resources that they are
protecting.
The administrator must have the m and d permissions on the Management/Action
object to create and delete these new permissions or actions.
54
Administration Guide
/Management/POP permissions
This object allows administration users to manage protected object policies. All
permissions must appear in entries for ACLs on /Management/POP. Action tasks and
associated permissions include:
Permission
Operation
d (delete)
Delete a POP.
m (modify)
Create POPs and modify POP attributes.
v (view)
Find and list POPs and show POP details.
B (bypass POP)
Override the POP on an object.
The pop find command shows the list of protected resources where this POP is
attached. You must have the view (v) permission on those protected resources
before they can be shown.
/Management/Server permissions
The /Management/Server container object of the protected object space allows
administrators to perform server tasks when the appropriate permissions are set.
Server management controls are used to determine whether a user has permission
to view configured resource managers, initiate a replication of one or more
resource managers, and to enable runtime tracing features on behalf of resource
managers.
Resource managers become available in the list of resource managers after they are
configured into the domain. Resource managers are removed when they are
unconfigured.
The viewable resource manager information allows other Tivoli Access Manager
servers, particularly the policy server, to locate and communicate with that
resource manager.
Permission
Operation
s (server)
Replicate the resource manager or the authorization database.
v (view)
List registered servers and display server properties.
t (trace)
Enable dynamic trace or statistics administration.
/Management/Config permissions
The /Management/Config container object of the protected object space allows
administrators to perform configuration tasks when the appropriate permissions
are set.
Configuration management controls are used to determine whether a user has
permission to configure, unconfigure, or update the configuration of a resource
manager.
A server definition is created for a particular resource manager or the authorization
server as part of the configuration process. The definition for a server is deleted
when the server is unconfigured.
Chapter 4. Default security policy
55
Server definitions contain information that allows other Tivoli Access Manager
servers, particularly the policy server, to locate and communicate with that
resource manager.
Permission
Operation
m (modify)
Configure a resource manager into a domain or update the
configuration of a resource manager.
d (delete)
Unconfigure a resource manager from a domain.
/Management/Policy permissions
The /Management/Policy container object of the protected object space allows
administrators to authorize the policy get and policy set commands when the
appropriate permissions are set.
Permission
Operation
v (view)
Required for policy get commands.
m (modify)
Required for policy set commands.
/Management/Replica permissions
The /Management/Replica container object of the protected object space controls the
replication of the master policy database. High-level controls on this object affect
the operation of the policy server and the resource managers in the domain.
Replica management controls are used to determine which resource managers are
allowed to download the master policy database to their local file system.
Permission
v (view)
Operation
Read the master policy database.
All Tivoli Access Manager servers that maintain a local replica of the policy
database, which includes all resource managers and the authorization servers, must
be granted view (v) permission on the /Management/Replica object. The replication
process requires that these processes be allowed to view and access entries out of
the master policy database.
The Tivoli Access Manager installation automatically grants read permission to any
server requiring access to the master policy database. When a resource manager is
configured into the domain, it is automatically added as a member to the
ivacld-servers group. This group, by default, is given permission to download the
master policy database.
/Management/Users permissions
This object allows administration users to manage user accounts. Action tasks and
associated permissions include:
56
Administration Guide
Permission
Operation
d (delete)
Delete a user account.
m (modify)
Modify the details of a user account.
N (create)
Create a user and optionally assign that user to one or more groups.
Import group data from the user registry.
Permission
Operation
v (view)
List user accounts and show details for a user account.
W (password)
Reset and validate a user password.
The password (W) permission allows password resets and is appropriate to give to
help desk administrators so that they can assist users who have forgotten their
passwords. This permission allows an administrator to reset the password and
then to use the user modify password-valid command to set a value of no. This
action allows the user to log on and then forces the user to immediately apply a
new password. Setting user modify password-valid to no for a user does not
indicate if the password is not valid due to the maximum password age policy,
which is a global setting. The policy set max-password-age command sets the
maximum time before a password expires.
The ability for an administrator to manage all user accounts is controlled by
permissions on the /Management/Users object. For example, if an administrator has
view (v) permission on the /Management/Users object, that administrator can view
information about all users.
To limit the scope of administrator control to a specific group, remove the
administrator permissions from the /Management/Users object and apply
permissions to the /Management/Groups object that is associated with the group to
be managed. For example, if an administrator is given view (v) permission on the
/Management/Groups/Accounting object, that administrator can only view
information about users in the Accounting group.
If an administrator has view (v) permission to any group that the user is a member
of, the administrator can view the information for that user. Adding the view (v)
permission to the /Management/Groups object itself allows an administrator to view
information about any user who is a member of any group.
Access granted by the /Management/Users object overrides any access restrictions
imposed by delegated administration policy ACLs under /Management/Groups/
group_name. For information about delegated administration, see Chapter 16,
“Delegated administration,” on page 183.
/Management/Groups permissions
This object allows administration users to manage groups and group membership.
Permission
Description
d (delete)
Delete a group.
m (modify)
Modify group descriptions. Remove one or more user members of a
group.
N (create)
Create a group. Import group data from the user registry.
v (view)
List groups and show group details.
A (add)
Add one or more users to a group.
The add (A) permission is required on your entry in the ACL on a group to allow
you to add existing users to your group. Use the user create command, which
requires the N permission, to create new users and optionally place them in one or
more existing groups.
Chapter 4. Default security policy
57
The capability of adding existing users to your group is powerful because the
owner of a group has control over all user members of the group. If you, as the
owner of the group, also have the delete (d) permission, you can delete this user
from the entire domain.
The ability for an administrator to manage all groups is controlled by permissions
on the /Management/Groups object. For example, if an administrator has delete (d)
permission on the /Management/Groups object, that administrator can delete any
group.
To limit the scope of administrator control to a specific group, apply permissions to
the object that is associated with the group. For example, if an administrator is
given delete (d) permission on the /Management/Groups/Travel/Europe object, that
administrator can delete any group within that object.
Permissions on /Management/Groups objects affect the ability of an administrator to
manage users who are part of those groups. Giving an administrator delete (d)
permission on a group allows that administrator to delete a user who is a member
of the group. If an administrator has view (v) permission on a group, that
administrator can view information about the users that are part of those groups.
/Management/GSO permissions
The /Management/GSO container object of the protected object space allows
administrators to perform Global Sign-On (GSO) tasks when the appropriate
permissions are set.
Permission
Operation
N (create)
Create a resource, resource group, or resource credential. Creating a
resource, resource group, or resource credential also require the m
(modify) permission.
d (delete)
Delete a resource, resource group, or resource credential. Deleting a
resource, resource group, or resource credential also require the m
(modify) permission.
m (modify)
Modify a resource group or resource credential.
v (view)
List or show resources, resource groups, and resource credentials.
/Management/Rule permissions
This object allows administration users to manage authorization rule policies. All
permissions must appear in entries for ACLs on /Management/Rule.
Permission
Operation
R (bypass rule)
Override the authorization rule policy on an object.
d (delete)
Delete an authorization rule.
m (modify)
Create authorization rules and modify authorization rule attributes.
v (view)
Find and list authorization rules and show authorization rule details.
The authzrule find command shows the list of protected resources where this rule
is attached. You must have the view (v) permission on those protected resources
before they can be shown.
58
Administration Guide
/Management/Domain permissions
The /Management/Domain container object of the protected object space allows
administrators to perform domain tasks when that appropriate permissions are set.
Permission
Operation
m (modify)
Modify or create a domain.
v (view)
List and show domains.
d (delete)
Delete a domain.
/Management/Proxy permissions
The /Management/Proxy container object of the protected object space allows
administrators or resource managers to perform delegated management tasks when
the appropriate permissions are set.
Permission
Operation
g (delegate)
Allows administrators and resource managers to act on the behalf of
the specified credential.
Chapter 4. Default security policy
59
60
Administration Guide
Chapter 5. Managing domains
An administrator in the management domain can create additional domains. A
domain is given a unique name, and a domain administrator must be specified
when the domain is created. Domain administrators can perform administrative
tasks only within their own domains, and do not have the authority to perform
tasks in other domains.
Within a domain, an administrator can create users, groups, and other objects.
Users and groups are specific to their domain and are not allowed to access
resources that are contained in other domains. If users and groups are created
outside of Tivoli Access Manager, these users and groups can be imported into
other domains. Resources that are defined and access controls for resources that are
protected by Tivoli Access Manager are maintained on a per domain basis.
Resources and access controls for resources cannot be shared among domains.
You can perform the following domain tasks:
v “Logging in to domains”
v “Creating a domain”
v “Modifying the description for a domain” on page 62
v “Listing domains” on page 63
v “Deleting a domain” on page 64
Logging in to domains
You can log in to a domain using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To log in to the domain that you created, complete the following steps:
1. From the login screen, type the domain name that you created. The default
domain name is Default.
2. Type the user ID that was created for this domain. The default user ID is
sec_master.
3. Type the password associated with the user ID.
pdadmin
To log in to a domain using the pdadmin utility, use the login command.
For example, for the myadmin_id administrator to log in interactively to the
Domain-ABC domain using the login command, enter the following command:
pdadmin login -a myadmin_id -p 12A345 -d Domain-ABC
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Creating a domain
Any number of additional domains can be created in addition to the management
domain.
© Copyright IBM Corp. 1999, 2010
61
Only an administrator who is logged in to the management domain is authorized
to create additional domains. A domain can be created only by an administrator
with the appropriate permissions within that management domain.
You can create a domain using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To create a domain, complete the following steps:
1. Use Web Portal Manager to log in to the management domain as a domain
administrator.
2. Click Secure Domain → Create Secure Domain.
3. Type the Secure Domain Name that you want to create. For example, type
Domain-ABC.
The following restrictions apply to the domain name:
v The maximum length is limited to 64 characters.
v The name can contain a-z, A–Z, 0–9, hyphen (-), underscore (_), period (.),
"at" symbol (@), or ampersand (&) characters.
v The name can contain any character from a double-byte character set.
4. Optional: Type a Description of the domain, such as: Test Domain.
5. Type a New Domain Administrator ID. For example, type myadmin_id.
Note: You must create an administrator ID for the domain.
6. Type a New Administrator Password. For example, type 12A345. Passwords
must adhere to the password policies set by the domain administrator.
7. Type the password again in Confirm Password.
8. Click Create.
pdadmin
To create a domain using the pdadmin utility, log in to the management domain
and use the domain create command. For example, to create a domain named
Domain-ABC, enter the following command on a single line:
pdadmin sec_master> domain create Domain-ABC myadmin_id 12A345 -desc "Test Domain"
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Modifying the description for a domain
Only an administrator who is logged in to the management domain is authorized
to modify a domain description. A domain can be modified only by an
administrator with the appropriate permissions within the management domain.
You can modify a domain description using Web Portal Manager or the pdadmin
utility.
Web Portal Manager
To modify a domain description, complete the following steps:
1. Use Web Portal Manager to log in to the management domain as a domain
administrator.
2. Click Secure Domain → List Secure Domain.
62
Administration Guide
3. From the Manage Secure Domains page, click the name of the domain that you
want to change. For example, click Domain-ABC.
4. From the Secure Domain Properties page, edit the Description field to add a
new description or change the existing description. For example, type new test
domain description to change the existing description.
5. Click Apply.
pdadmin
To modify a domain description using the pdadmin utility, log in to the
management domain as a domain administrator and use the domain modify
command.
For example, to change the description of the domain named Domain-ABC to new
test domain description, enter the following command on a single line:
pdadmin sec_master> domain modify Domain-ABC description "new test
domain description"
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing domains
You can list all domains, except for the management domain, using Web Portal
Manager or the pdadmin utility.
Only an administrator who is logged in to the management domain is authorized
to list domains. The administrator must have the appropriate permissions to list
domains within the management domain.
Web Portal Manager
To list all domains, except for the management domain, complete the following
steps:
1. Use Web Portal Manager to log in to the management domain as a domain
administrator.
2. Click Secure Domain → List Secure Domain.
The Manage Secure Domains page displays all the domain names, except for the
management domain, as links. You can filter the domain names to view only the
domain names that meet the criteria you specify.
pdadmin
To list all domains, except for the management domain, using the pdadmin utility,
log in to the management domain as a domain administrator and use the domain
list command. To list domains, enter the following command:
pdadmin sec_master> domain list
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Chapter 5. Managing domains
63
Deleting a domain
Only an administrator who is logged in to the management domain is authorized
to delete domains. A domain can be deleted only by an administrator with the
appropriate permissions within the management domain.
Deleting a domain deletes the specified Tivoli Access Manager group. If you
specify the optional registry entry option, all user and group information,
including associated ACL entries, are deleted from the user registry when the
domain is deleted.
Note: The delete operation cannot be reversed.
You can delete a domain using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To delete a domain, complete the following steps:
1. Use Web Portal Manager to log in to the management domain as a domain
administrator.
2. Click Secure Domain → List Secure Domain.
3. From the Domain List page select the domain you want to delete
4. From the Domain Properties page click Delete.
To permanently remove domain information from the user registry, click Delete
Registry Entry. Otherwise, the user and group information for the domain
remains in the user registry and can be used if the domain is created again.
pdadmin
To delete a domain using the pdadmin utility, log in to the management domain as
a domain administrator and use the domain delete command.
To permanently remove domain information from the user registry, use the
–registry option. Otherwise, the user and group information for the domain
remains in the user registry and can be used if the domain is created again.
For example, to delete the domain named Domain-ABC and permanently remove the
domain information from the user registry, enter the following command:
pdadmin sec_master> domain delete Domain-ABC –registry
Note: If you unconfigure the management domain using the pdconfig utility, any
additional domain that exists is deleted.
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
64
Administration Guide
Chapter 6. Managing object spaces
Tivoli Access Manager represents resources to be protected using a virtual
representation of the object space that is called the protected object space. An object
space consists of resource objects and container objects. Resource objects are logical
representations of resources to be protected. Container objects allow you to group
resource objects and other container objects hierarchically into logical groups or
regions. Grouping similar objects makes it easier for you to administer a consistent
security policy.
Security policy is applied by attaching access control list (ACL) policies, protected
object policies (POPs), and authorization rules to the objects within the object space
that represent the physical resources to be protected. The Tivoli Access Manager
authorization service decided whether to permit or deny access to resources based
on user credentials and the conditions specified by the security policy.
The following object spaces are created during the installation of Tivoli Access
Manager products:
v The /Management object space during the installation of any Tivoli Access
Manager product, if it does not exist
v The /WebSEAL object space during the installation of Tivoli Access Manager for
e-business
v The /OSSEAL object space during the installation of Tivoli Access Manager for
Operating Systems
v The /PDMQ object space during the installation of Tivoli Access Manager for
Business Integration
You can perform the following object space tasks:
v “Creating an object space”
v “Listing object spaces” on page 67
v
v
v
v
“Copying an object space” on page 67
“Importing object spaces” on page 68
“Exporting object spaces” on page 68
“Deleting an object space” on page 69
In the following sections, instructions are provided for using either Web Portal
Manager or pdadmin, or both. For online help while using Web Portal Manager,
click the question mark to open a separate help window for the current page.
Note: There are no equivalent pdadmin commands for importing, exporting, and
copying object spaces.
Creating an object space
You can create an object space using Web Portal Manager or the pdadmin utility.
To perform this task, the administrator requires the following permissions:
v Create (N)
v Modify (m)
© Copyright IBM Corp. 1999, 2010
65
Web Portal Manager
To
1.
2.
3.
create an object space, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click Object Space → Create Object Space.
Type an Object Name. This field is required. For example: /Test-Space
4. Type a Description for the object space. For example: New Object Space
5. Click Create. To see the /Test-Space object space in the hierarchical structure,
browse the object space. See “Listing object spaces” on page 67.
Because an object space consists of resource objects and container objects, you do
not have to specify an object type when using Web Portal Manager.
pdadmin
To create an object space in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the objectspace create command.
Note: Do not use the objectspace command on object spaces that are created by or
developed using Tivoli Access Manager. The following object spaces are
created by Tivoli Access Manager:
v /Management
v /WebSEAL
v /OSSEAL
v /PDMQ
For example, to create the /Test-Space object space that is an application container
object, which is object type 14, enter the following command:
pdadmin sec_master> objectspace create /Test-Space "New Object Space" 14
When creating an object space, an object type must be specified. This object space
example assigns an object type of 14, which is for an application container object.
“Protected object space” on page 34 discusses the two general types of objects:
resource objects and container objects. You can select any of the listed object space
types, or use any unused category number listed in the following list to designate
the object space type and assign a meaning to it.
The
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
66
Administration Guide
following object space types are valid for Tivoli Access Manager:
Unknown
Secure domain
File
Executable program
Directory
Junction
WebSEAL server
Unused
Unused
HTTP server
Nonexistent object
Container object
Leaf object
Port
Application container object
Application leaf object
Management object
17
Unused
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing object spaces
You can list all object spaces using Web Portal Manager or the pdadmin utility.
To perform this task, the administrator requires the following permissions:
v Browse (b)
v View (v)
Web Portal Manager
To list all object spaces, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Object Space → Browse Object Space to display the Browse Object Space
page.
The Browse Object Space page displays all the objects in the domain in a
hierarchical structure. All object spaces appear at the same structural level as the
default /Management object space. Each object space and the corresponding object
are displayed as a link. When you select any link, the Protected Object Properties
page for that object or object space is displayed.
pdadmin
To list all object spaces in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the objectspace list command.
pdadmin sec_master> objectspace list
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Copying an object space
You can copy an object space using Web Portal Manager only.
Web Portal Manager
To copy an object space, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Object Space → Copy/Paste Object Space to display the Copy/Paste
Object Space page.
3. To select which objects to copy, navigate the object space and select the
object-specific check boxes in the Copy column.
4. To select where these objects are to be pasted, navigate to the object space and
select the object-specific check boxes in the Paste column.
5. Click Copy/Paste to copy the selected object space hierarchies to the designated
locations.
If successful, the copied object space is shown under the pasted location. To
validate, click Refresh.
Chapter 6. Managing object spaces
67
Importing object spaces
You can import an object space using Web Portal Manager only.
Web Portal Manager
To
1.
2.
3.
4.
5.
6.
7.
import an object space, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click Object Space → Import Object.
From the Import Protected Object From File page, complete one of the
following steps:
v In the Object File Name field, type the name of the object to import. For
example, type objectImport.xml.
v Click Browse to select a file name.
Optional: Select the Create Groups check box to trigger the creation of a group
for associated ACLs with entries with the type Group.
When the Create Groups box is selected, in the Registry Container text field,
type the name of the registry container. For example, type o=ibm,c=us.
If the file containing the object space was encrypted when it was exported, in
the Encryption String text field, type the string that was used to encrypt the
XML file.
Click Import.
If successful, the imported object space is available when you browse the object
space.
Exporting object spaces
You can export an object space using Web Portal Manager only.
Web Portal Manager
To export an object space, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Object Space → Browse Object Space to display the Browse Object
Space page.
3. Navigate the hierarchy and select the object that you want to export.
4. From the Protected Object Properties page, click Export to display the Export
Object to File page.
5. Optional: Select the Export Object including Children check box to descend
the object hierarchy and export all child objects.
6. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
7. When an Encryption String is provided, in the Confirm Encryption String
text field, type the string again.
8. Click Export to display the File Download window.
9. Click Save to display the Save As window.
10. Click Save to create the file that contains the exported description. The default
file name is objectExport.xml.
If successful, the exported XML description file is available in the specified
location.
68
Administration Guide
Deleting an object space
You can delete an object from the object space using Web Portal Manager or the
pdadmin utility.
To perform this task, the administrator requires the following permissions:
v Delete (d)
v Modify (m)
Web Portal Manager
To
1.
2.
3.
delete an object from the object space, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click Object Space → Browse Object Space.
From the Browse Object Space page, expand and click the object space that you
want to delete.
4. From the Protected Object Properties page, the name of the object space is
displayed in the Object Name field. Click Delete.
5. To confirm the deletion, click Delete again.
If successful, a message displays indicating that the object space was deleted.
pdadmin
To delete an object space in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the objectspace delete command.
For example, to delete the object space named /Test-Space, enter the following
command:
pdadmin sec_master> objectspace delete /Test-Space
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Chapter 6. Managing object spaces
69
70
Administration Guide
Chapter 7. Managing protected objects
An object is a logical representation of a system resource. To protect objects, you
need to apply security policies. Security policies are the combination of access
control list (ACL) policies, protected object policies (POPs), and authorization rules
that you can attach to an object.
You can perform the following object tasks:
v “Creating an object”
v “Listing objects” on page 73
v “Importing objects” on page 73
v “Exporting objects” on page 74
v “Deleting an object” on page 74
In the following sections, instructions are provided for using either Web Portal
Manager or pdadmin, or both. For online help while using Web Portal Manager,
click the question mark to open a separate help window for the current page.
Note: There are no equivalent pdadmin commands for importing and exporting
objects.
After an object space is created, you can populate it with objects and then manage
these objects. For information about creating an object space, see “Creating an
object space” on page 65.
Creating an object
You can create an object using Web Portal Manager or the pdadmin utility. Web
Portal Manager provides two ways of creating objects:
v Specifying the fully qualified path of the new object starting at root
v Specifying the new object from the provided path of the parent object
To perform this task, the administrator requires the following permissions:
v Create (N)
v Modify (m)
Web Portal Manager, from root
To create an object specifying the path from root, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Object Space → Create Object to display the Create Protected Object
page.
3. Type the full path of the object in the Object Name text field. For example,
type /Management/Groups/test-object.
4. Optional: In the Description text field, type a description for the object. For
example, type Test Object.
5. Click Create.
To be able to attach a policy to this protected object, click Object Space → Browse
Object Space. The Browse Object Space page provides a hierarchical view of all
© Copyright IBM Corp. 1999, 2010
71
the objects in the domain as links. Click the link for an object to go to its Protected
Object Properties page. From this page, select the Can Policy be attached to this
object check box and click Apply.
Web Portal Manager, from parent object
To create an object when using the parent object as the base path, complete the
following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Object Space → Browse Object Space to display the Browse Object Space
page.
3. Navigate the object hierarchy and select the link of the parent object to display
the Protect Object Properties page. For example, select the link that is
associated with the /Management/Groups object.
4. Click the Create Child Object link to display the Create Protected Object page
where the Object Name and Description text fields contain the values of the
parent object.
5. In the Object Name text field, append a slash and the name of the new object.
For example, append /test-object to the provided parent path of
/Management/Groups.
6. Optional: In the Description text field, modify the description for the object.
For example, type Test Object.
7. Click Create.
After the object is created, a dialog is displayed with the link to this object. To
attach a policy to this protected object, click this link to display its Protected Object
Properties page. From this page, select the Can Policy be attached to this object
check box and click Apply.
pdadmin
To create an object in the domain using the pdadmin utility, log in to the domain
as the domain administrator and use the object create command.
For example, to create the object named /Management/test-object that is an
application container object (14), enter the following command:
pdadmin object create /Management/test-object “Test Object” 14
ispolicyattachable yes
The
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
72
Administration Guide
type can be one of the following object type categories:
Unknown
Secure domain
File
Executable program
Directory
Junction
WebSEAL server
Unused
Unused
HTTP server
Nonexistent object
Container object
Leaf object
Port
Application container object
15
16
17
Application leaf object
Management object
Unused
When creating an object, a type must be specified. You can select an appropriate
category, or use any number to designate the object type and assign a meaning to
it.
If the ispolicyattachable option is omitted from the object create command, this
command assumes that you intended to use the objectspace create command. An
object space is created rather than an object.
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing objects
You can list objects in the domain using Web Portal Manager or the pdadmin
utility. To perform this task, the administrator requires the following permissions:
v Browse (b)
v View (v)
Web Portal Manager
To list objects, complete the following steps:
1. Use Web Portal Manager log in to the domain as a domain administrator.
2. Click Object Space → Browse Object Space.
The Browse Object Space page displays all the objects in the domain in a
hierarchical structure. All object spaces appear at the same structural level as the
default /Management object space. Each object space and each object are displayed
as a link. When you select any link, the Protected Object Properties page for that
object or object space is displayed.
pdadmin
To list all objects in the domain using the pdadmin utility, log in to the domain as
the domain administrator and use the object list command.
For example, to list the objects under the /Management object space, enter the
following command:
pdadmin sec_master> object list /Management
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Importing objects
You can import an object using Web Portal Manager only.
Web Portal Manager
To import an object, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Object Space → Import Object.
Chapter 7. Managing protected objects
73
3. From the Import Protected Object From File page, complete one of the
following steps:
v In the Object File Name field, type the name of the object to import. For
example, type objectImport.xml.
v Click Browse to select a file name.
4. Optional: Select the Create Groups check box to trigger the creation of a group
for associated ACLs with the type Group.
5. When the Create Groups box is selected, in the Registry Container text field,
type the name of the registry container. For example, type o=ibm,c=us.
6. If the file containing the object space was encrypted when it was exported, in
the Encryption String text field, type the string that was used to encrypt the
XML file.
7. Click Import.
If successful, the imported object is available when you browse the object space.
Exporting objects
You can export an object using Web Portal Manager only.
Web Portal Manager
To export an object, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Object Space → Browse Object Space to display the Browse Object
Space page.
3. Navigate the hierarchy and select the object that you want to export.
4. From the Protected Object Properties page, click Export to display the Export
Object to File page.
5. Optional: Select the Export Object including Children check box to descend
the object hierarchy and export all child objects.
6. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
7. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
8. Click Export to display the File Download window.
9. Click Save to display the Save As window.
10. Click Save to create the file that contains the exported description. The default
file name is objectExport.xml.
If successful, the exported XML description file is available in the specified
location.
Deleting an object
You can delete an object using Web Portal Manager or the pdadmin utility.
To perform this task, the administrator requires the following permissions:
v Delete (d)
v Modify (m)
74
Administration Guide
Web Portal Manager
To delete an object, complete the following steps:
1. Use Web Portal Manager log in to the domain as a domain administrator.
2. Click Object Space → Browse Object Space.
The Browse Object Space page provides a hierarchical display of all objects in
the domain as links.
3. Click the link for an object to see its properties. These properties include
whether ACL policies, POPs, and authorization rules are attached to the object
and whether the object has extended attributes. For example, click the
/Management/text-object link to display its properties.
4. From the Protected Object Properties page, ensure the object named is the one
you want to delete and click Delete.
pdadmin
To delete an object in the domain using the pdadmin utility, log in to the domain
as the domain administrator and use the object delete command.
For example, to delete the object named /Management/test-object, enter the
following command:
pdadmin object delete /Management/test-object
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Chapter 7. Managing protected objects
75
76
Administration Guide
Chapter 8. Managing access control
A domain administrator can use access control list (ACL) policies to control access
to objects. ACL policies contain ACL entries that control who can access which
domain resources and perform which actions. For more information about ACL
policies, see “ACL policies.” For details about the ACL policy tasks that a domain
administrator can perform, see “Managing ACL policies” on page 83.
A domain administrator manages the ACL policies by adding, removing, and
modifying the ACL entries in the ACL policies. An ACL entry defines a user or
group and which actions each can perform against a protected object. A domain
administrator can manage these ACL entries before or after the ACL policy is
attached to domain resources. Any change to the ACL entry affects only the access
that these users and groups have against a specific domain resource to which the
ACL policy is attached. For more information about ACL entries in an ACL policy,
see “ACL entries” on page 78.
To define ACL entries, a domain administrator adds or removes permissions
(actions) for specific users or groups. A permission is an action that is defined by an
action bit in an action group. An action group is a set of permissions. A domain
administrator can add to or remove from an ACL entry. When Tivoli Access
Manager is installed, the primary action group is created, and contains 17
permissions. These permissions are defined using action bits. As additional
resource managers are installed, additional action groups might be created. As
needed, a domain administrator can create additional action groups and add new
actions to previously created action groups. For additional information about
actions and action groups, see “Action groups and actions” on page 80. For details
about the action group tasks that a domain administrator can perform, see
“Managing action groups” on page 95. For details about the action tasks that a
domain administrator can perform, see “Managing actions” on page 97.
A domain administrator can assign another user administrative authority. To define
another administrative user, the domain administrator sets the ACL entries for that
user to match the ACL entries of the domain administrator. In this situation, both
the new administrative user and the domain administrator have the same
authority.
ACL policies
Within the protected object space, ACL policies can be attached to resource objects
and container objects. Each ACL policy contains one or more ACL entries that
affect only that object. For example, the ACL policy that is attached to the spooler
object might allow all requesters the following permissions:
v Execute
v List
v Read
v Write
However, the ACL policy that is attached to the docs_repository object might
allow all requesters the following permissions:
v List
v Read
© Copyright IBM Corp. 1999, 2010
77
In this case, the ACL policy that is attached to these objects are both for all
requesters, but the permissions that are defined in the ACL entry for all requesters
is different.
Container objects represent specific regions in the protected object space. After a
domain administrator creates an ACL policy and attaches it to a container object,
the ACL policy serves the following important security tasks:
v The root (/) container object begins the chain of ACL inheritance for the entire
protected object space.
v Through inheritance, the root object defines the security policy for the entire
object space.
v Unless an explicit ACL policy is attached to a contained object, the ACL policy
for the container object defines the security policy for all resources in that
container object.
v The traverse permission allows a requester to pass through a container object to
the requested object. To deny access to all objects in a region, remove the
traverse permission (T action bit) from the ACL entry.
v The traverse permission does not grant any other access controls to the container
object.
ACL entries
Each ACL policy can contain one or more ACL entries. Each ACL entry contains
attributes that identify the user or group and the actions that this user or group
can perform. The number of required attributes for an ACL entry depends on the
ACL entry type. The general format of an ACL entry contains the following
attributes:
Type
The type attribute specifies the entity category (user, group, or special) for
which the ACL entry was created. For additional information about the
type attribute, see “Type attribute” on page 79.
ID
The ID attribute is the unique identifier (name) of the user or group that is
specified with the type attribute. The any-other and unauthenticated
special entry types do not require the ID attribute. For additional
information about the ID attribute, see “ID attribute” on page 79.
Permissions
The permissions attribute defines the set of permissions (actions) that are
permitted on the resource by this user or group. Permissions are defined
using action bits. Actions bits are defined in action groups. For additional
information about the permissions attribute, see “Permissions attribute” on
page 79. For additional information about action bits and action groups,
see “Action groups and actions” on page 80.
Figure 16 shows the attributes of an ACL entry.
Figure 16. ACL entry attributes
78
Administration Guide
Type attribute
The type attribute of an ACL entry type identifies the user, group, or special entity
for a specific ACL entry. The following types are supported:
user
Sets permissions for a specific user in a domain. The user must be a
member of the domain with an account in the registry. The user entry type
requires a user name (ID). The entry format is user ID permissions as
shown in the following example:
user anthony -------T-----r-
group Sets permissions for all members of a specific group in a domain. The
group entry type requires a group name (ID). The entry format is group ID
permissions as shown in the following example:
group engineering -------T-----r-
any-other
Sets permissions for all authenticated users. No ID designation is required.
The entry format is any-other permissions as shown in the following
example:
any-other
-------T-----r-
The any-other entry type is also known as any-authenticated.
unauthenticated
Sets permissions for those users who have not been authenticated by the
policy server. No ID attribute is required in the ACL entry. The entry
format is unauthenticated permissions as shown in the following
example:
unauthenticated -------T-----r-
This ACL entry is a mask (a bit-wise and operation) against the any-other
ACL entry to determine the action set. A permission for unauthenticated is
granted only if the permission also appears in the any-other entry.
For example, when unauthenticated has read and write permissions and
any-other has transverse and read permissions, the resulting action set is
read only. This example is shown in the following equation:
+
unauthenticated -------------rw
any-other
-------T-----r-------------r-
ID attribute
Each user ACL entry and each group ACL entry have unique identifiers (name).
These names must represent valid users or groups that are created in a domain
and have an account in the registry.
The any-other and unauthenticated special entry types do not use the ID attribute.
Permissions attribute
Each ACL entry contains a set of permissions (actions) that describes the specific
operations that are permitted on the object by the user or group. Permissions are
context sensitive. The behavior of certain permissions varies according to where
the permissions are applied. For example, the modify permission (m action bit)
behaves differently for protected resources in the /WebSEAL object space than for
protected resources in the /Management object space.
Chapter 8. Managing access control
79
Permissions control protected resources in the following ways:
v Determine whether a user can perform operations on protected objects
v Determine whether an administrator can change security policy on the object
and any object that inherits permissions
v Determine whether Tivoli Access Manager itself can delegate credentials for a
user
Action groups and actions
A domain administrator defines the actions that requesters can perform on objects
in the protected object spaces. An action is a permission in an action group that is
defined in the action group by an action bit. A domain administrator modifies the
ACL entries in an ACL policy before or after the ACL policy is attached to an
object. The actions that can be defined in an ACL entry must be previously defined
in an action group.
When Tivoli Access Manager is installed, the primary action group is created. As
additional applications and resource managers are installed, additional action
groups might be created. Independent of whether additional action groups are
created during subsequent installations, a domain administrator can create
additional action groups. In the primary action group, an action group that is
created during the installation of an application or resource manager, or a custom
action group, a domain administrator can create custom permissions by defining
new action bits.
Default permissions in the primary action group
Tivoli Access Manager defines permissions using action bits. When you install
Tivoli Access Manager, the default primary action group is created. This action
group contains 17 permissions. Web Portal Manager divides these permissions into
the following categories.
v Base
v Generic
v Application
Table 2 shows the action bit in the primary action group, a brief description of its
associated permission, and its category as shown in Web Portal Manager.
Table 2. Action bits, permissions, and Web Portal Manager category of the default primary
action group
Action bit
80
Administration Guide
Description of permission
Category
a
Attach
Base
A
Add
Base
b
Browse
Base
B
Bypass protected object policy (POP)
Base
c
Control
Base
d
Delete
Generic
g
Delegation
Base
l
List directory
Application
m
Modify
Generic
N
Create
Base
R
Bypass rule
Base
Table 2. Action bits, permissions, and Web Portal Manager category of the default primary
action group (continued)
Action bit
Description of permission
Category
r
Read
Application
s
Server administration
Generic
t
Trace
Base
T
Traverse
Base
v
View
Generic
W
Password
Base
x
Execute
Application
Tivoli Access Manager provides the capability to define additional permissions for
use by resource managers. For more information, see “Managing action groups” on
page 95.
Custom permissions in custom action groups
The default permissions in the primary action group are available to all
applications. If a custom action group uses these default permissions, the
associated actions must closely match that of the actual operation that is performed
by an action in the primary action group. For example, the read permission (action
bit r) must be used only by an action that requires read-only access to a protected
object.
The authorization service does not know or care about the action. So a custom
action group can reuse an action bit from the primary action group to create an
action in a custom action group for an unrelated operation. However, this situation
might cause difficulty for a domain administrator who must be able to distinguish
between two dissimilar uses of the same action bit.
If a custom action group uses an action that is not appropriately represented by a
default permission, a domain administrator can define a new action bit for a
permission that can be used and be recognized by the authorization service. For
details, see “Managing action groups” on page 95.
When to create custom permissions
To protect a printer from unauthorized use, a domain administrator can create a
custom action. Figure 17 on page 82 shows an example of this requirement. A print
spooling service is written with the authorization application programming
interface (authorization API) so that it can call the authorization service to perform
ACL checks on requests made to the printer.
The default permissions do not include a permission for protecting printers.
However, the printer can be protected by a custom action bit (p in this example).
An ACL policy is attached to the printer object. If a user requests the use of this
protected printer, that user must have an ACL entry that contains the p action bit.
The authorization service returns a favorable response if the p action bit is present
and the printing operation proceeds. If the authorization service returns an
unfavorable response, the printing operation is not allowed to proceed.
Chapter 8. Managing access control
81
Print
spooler
service
A
P
I
C an Iuse this
printer?
Authorization
service
"YES"
Authorization
policy
database
Printer ACL
User michael p
Figure 17. Permissions for a custom print spooler
Representation of custom actions and action groups
As discussed in “ACL entries” on page 78, ACL entries contain an entry type, an
ID for user and group types, and the set of permissions (action bits).
You must use a special syntax to identify custom action bits that belong to action
groups other than the primary action group. The primary action group is the
default action group. Permissions that represent the action bits from multiple
action groups are presented in the following format:
bits[group_1]bits_1...[group_n]bits_n
The following example is an example of the permissions attribute:
abgTr[groupA]Pq[groupB]Rsy[groupC]ab
The previous permissions attribute has the following interpretation:
v The primary action group contains the a, b, g, T, and r action bits.
v The groupA action group contains the P and q action bits.
v The groupB action group contains the R, s, and y action bits.
v The groupC action group contains the a and b action bits.
Action group groupC contains action bits that use the same letters for action bits as
used in the primary action group. The action bits are associated with a specific
action group (groupC). So the a and b action bits have unique identities and can
represent different permissions from those action bits in the primary action group.
Scenario using custom actions
The following scenarios show how to add custom actions to an ACL policy that is
attached to a protected object:
1. To show action groups, enter the following command:
pdadmin sec_master> action group list
primary
test-group
2. To list permissions in the test-group action group, enter the following
command:
pdadmin sec_master> action list test-group
P
S
Test-Action
Test-Action2
Special
Special
3. To list ACL policies, enter the following command:
pdadmin sec_master> acl list
default-webseal
82
Administration Guide
default-root
default-gso
default-policy
default-config
test-acl
default-replica
default-management
4. To show details about the ACL name test-acl, enter the following command:
pdadmin sec_master> acl show test-acl
ACL Name: test-acl
Description:
Entries:
User sec_master Tcmdbva
Group ivmgrd-servers Tl
Any-other r
5. To add an ACL entry for the user named Kathy that contains permissions from
the action groups named primary and test-group, enter the following
command:
pdadmin sec_master> acl modify test-acl set user kathy brT[test-group]PS
6. To validate this addition, enter the following command:
pdadmin sec_master> acl show test-acl
ACL Name: test-acl
Description:
Entries:
User sec_master Tcmdbva
Group ivmgrd-servers Tl
Any-other r
User kathy Tbr[test-group]PS
Managing ACL policies
You can create and configure an ACL policy and attach it to objects in the
protected object space. ACL policies are placed in the master policy database on a
domain-by-domain basis. The master policy database is controlled by the policy
server.
You can perform the following ACL policy tasks:
v
v
v
v
v
v
v
“Creating an ACL policy” on page 84
“Modifying the description of an ACL policy” on page 84
“Listing ACL policies” on page 85
“Viewing an ACL policy” on page 85
“Cloning an ACL policy” on page 86
“Importing ACL policies” on page 86
“Exporting all ACL policies” on page 86
v
v
v
v
v
v
“Exporting a single ACL policy” on page 87
“Exporting multiple ACL policies” on page 87
“Attaching an ACL policy to an object” on page 88
“Locating where an ACL policy is attached” on page 89
“Detaching an ACL policy from an object” on page 88
“Deleting an ACL policy” on page 89
Chapter 8. Managing access control
83
In the following sections, instructions are provided for using either Web Portal
Manager or pdadmin, or both. For online help while using Web Portal Manager,
click the question mark to open a separate help window for the current page.
Note: There are no equivalent pdadmin commands for importing, exporting, or
cloning ACL policies.
Creating an ACL policy
You can create an ACL policy using Web Portal Manager or the pdadmin utility.
After creating an ACL policy, it contains an entry for as the logged in user who
created the ACL policy. This ACL entry has all the defined permissions. You must
modify this ACL policy by adding ACL entries for the additional users and groups
that need to manage this ACL policy and manage the objects to which this ACL
policy is attached.
After adding the appropriate ACL entries for these users and groups, you might
need to remove the ACL entry for the user who created the ACL policy.
Web Portal Manager
To create an ACL policy, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → Create ACL.
3. In the ACL Name file, type the name of the ACL policy. For example, type
Test-ACL.
4. Optional: In the Description field, type a description of the ACL. For example,
type Test of new ACL.
5. Click Create.
If successful, a link for this ACL policy is available when you list all ACL policies.
You can now add and remove ACL entries from the ACL policy. For details about
adding and removing ACL entries, see “Creating an ACL entry” on page 90 and
“Removing ACL entries from an ACL policy” on page 91.
pdadmin
To create an ACL policy in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the acl create command.
For example, to create an ACL policy named Test-ACL, enter the following
command:
pdadmin sec_master> acl create Test-ACL
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Modifying the description of an ACL policy
You can modify an ACL policy using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To
1.
2.
3.
84
Administration Guide
modify the description of an ACL policy, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click ACL → List ACL.
From the Manage ACLs page, click the link for the ACL policy that you want
to change.
4. From the ACL Properties page, modify the text in the Description field, as
appropriate.
5. Click Set.
pdadmin
To modify the description of an ACL policy in the domain using the pdadmin
utility, log in to the domain as a domain administrator and use the acl modify
command with the description option.
For example, to modify the description of the ACL named Test-ACL to be ACL for
Test resources, enter the following command:
pdadmin sec_master> acl modify Test-ACL description "ACL for Test resources"
To show the modifications to the ACL, use the acl show command. For example,
to show the ACL named Test-ACL, enter the following command:
pdadmin sec_master> acl show Test-ACL
ACL Name: Test-ACL
Description: ACL for Test resources
Entries:
User
maryj r
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing ACL policies
You can list all ACL policies using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To list all ACL policies in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
The Manage ACLs page displays all the ACL policies in the domains.
pdadmin
To list all ACL policies in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the acl list command.
pdadmin sec_master> acl list
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Viewing an ACL policy
You can view an ACL policy using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To
1.
2.
3.
view an ACL policy in the domain, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click ACL → List ACL.
From the Manage ACLs page, click the link for the ACL policy that you want
to view.
Chapter 8. Managing access control
85
pdadmin
To view an ACL policy in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the acl show command.
pdadmin sec_master> acl show test-acl
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Cloning an ACL policy
You can clone an ACL policy using Web Portal Manager only. To clone an ACL
policy in the domain using Web Portal Manager:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, select the ACL policy you want to clone.
4. From the ACL Properties page, click Clone.
5. From the Clone ACL page, type an ACL Name. For example, type Test-ACL.
The default value is the name of the original ACL with the prefix Clone.
6. Optional: Type a Description of the ACL policy For example, type Clone of
new ACL. The default value is the description of the original ACL.
7. Click Clone.
If successful, a link for the cloned ACL policy is created and a success message is
displayed.
Importing ACL policies
You can import an ACL policy using Web Portal Manager only. To import an ACL
policy in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → Import ACL.
3. From the Import ACL page, complete one of the following steps:
v In the ACL File Name field, type the name of the ACL to import. For
example, type aclImport.xml.
v Click Browse to select a file name.
4. Optional: Select the Create Groups check box to create a group for ACL entries
with the type Group.
5. When Create Groups is selected: In the Registry Container text field, type the
name of the registry container for the ACL. For example, type o=ibm,c=us.
6. If the file containing the ACL was encrypted when it was exported, in the
Encryption String text field, type the string that was used to encrypt the XML
file.
7. Click Import.
If successful, the imported ACL policy is available when you list all the ACL
policies.
Exporting all ACL policies
You can export the definitions of all ACL policies using Web Portal Manager only.
To export the definition of all ACL policies in the domain, complete the following
steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
86
Administration Guide
2. Click ACL → Export All to display the Export ACL to File page.
3. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
4. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
5. Click Export to display the File Download window.
6. Click Save to display the Save As window.
7. Click Save to create the file that contains the exported description. The default
file name is aclExport.xml.
If successful, the exported XML description file is available in the specified
location.
Exporting a single ACL policy
You can export the definition of a single ACL policy using Web Portal Manager
only. To export the definition of a single ACL policy in the domain, complete the
following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, select the ACL that you want to export.
4. From the ACL Properties page, click Export to display the Export ACL to File
page.
5. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
6. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
7. Click Export to display the File Download window.
8. Click Save to display the Save As window.
9. Click Save to create the file that contains the exported description. The default
file name is aclExport.xml.
If successful, the exported XML description file is available in the specified
location.
Exporting multiple ACL policies
You can export the definition of ACL policies from a list using Web Portal Manager
only. To export the definition of ACL policies from the list in the domain, complete
the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, select the ACLs that you want to export.
4. Click Export to display the Export ACL to File page.
5. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
6. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
7. Click Export to display the File Download window.
8. Click Save to display the Save As window.
Chapter 8. Managing access control
87
9. Click Save to create the file that contains the exported descriptions. The default
file name is aclExport.xml.
If successful, the exported XML description file is available in the specified
location.
Attaching an ACL policy to an object
You can attach an ACL to a protected object using Web Portal Manager or the
pdadmin utility.
To perform this task, the administrator requires the attach (a) permission.
Web Portal Manager
To
1.
2.
3.
attach an ACL to a protected object, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click ACL → List ACL.
From the Manage ACLs page, click the link for the name of the ACL that you
want to attach to a protected object.
4. From the ACL Properties page, click the Attach tab.
5. Click Attach.
6. From the Attach ACL page, type a Protected Object Path. For example, type
/Management/test-object.
7. Click Attach.
If successful, the protected object is displayed as a protected object link for the
named ACL.
pdadmin
To attach an ACL to a protected object in the domain using the pdadmin utility,
log in to the domain, and use the acl attach command.
For example, to attach an ACL named Test-ACL to a protected object named
/Management/test-object, enter the following command:
pdadmin sec_master> acl attach /Management/test-object Test-ACL
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Detaching an ACL policy from an object
You can detach an ACL from an object using Web Portal Manager or the pdadmin
utility.
To perform this task, the administrator requires the attach (a) permission.
Web Portal Manager
To detach an ACL from a protected object in the domain, complete the following
steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, click the link for the ACL policy to detach.
4. From the ACL Properties page, click the Attach tab.
88
Administration Guide
5. If the ACL is attached to protected objects, select one or more check boxes for
the protected objects from which you want to detach the ACL.
6. Click Detach. You are asked to confirm the detachment.
pdadmin
To detach an ACL from a protected object in the domain using the pdadmin utility,
log in to the domain, and use the acl detach command.
For example, to detach the ACL from the protected object named
/Management/test-object, enter the following command:
pdadmin sec_master> acl detach /Management/test-object
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Locating where an ACL policy is attached
You can find where an ACL is attached using Web Portal Manager or the pdadmin
utility.
Web Portal Manager
To find where an ACL is attached, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL. A list of ACL names is displayed.
3. From the Manage ACLs page, click the link for the name of the ACL.
4. From the ACL Properties page, click the Attach tab.
pdadmin
To find where an ACL is attached in the domain using the pdadmin utility, log in
to the domain as a domain administrator and use the acl find command.
For example, to find where the ACL named Test-ACL is attached, enter the
following command:
pdadmin sec_master> acl find Test-ACL
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting an ACL policy
You can delete an ACL policy using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To delete an ACL policy, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, select one or more check boxes of the ACL
policies that you want to delete.
4. Click Delete, and then confirm the deletion by clicking Delete again on the
Delete confirmation page.
If successful, the ACL policy is no longer included in the list of ACL policies in the
Manage ACLs page.
Chapter 8. Managing access control
89
pdadmin
To delete an ACL policy in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the acl delete command.
For example, to delete the ACL named Test-ACL, enter the following command:
pdadmin sec_master> acl delete Test-ACL
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Managing ACL entries in ACL policies
You can perform the following ACL entry tasks on ACL policies:
v “Creating an ACL entry”
v “Modifying permissions for an ACL entry” on page 91
v “Removing ACL entries from an ACL policy” on page 91
In the following sections, instructions are provided for using either Web Portal
Manager or the pdadmin utility, or both. For online help while using Web Portal
Manager, click the question mark to open a separate help window for the current
page.
Creating an ACL entry
You can create an ACL entry for an ACL policy using Web Portal Manager or the
pdadmin utility. Use this procedure to create the ACL entry for any user, group, or
special ACL entry type (any-other and unauthenticated).
Web Portal Manager
To create an ACL entry, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, click the link for the ACL policy you want to
change.
4. From the ACL Properties page, click Create.
5. Select the appropriate entry type: user, group, any-other, or unauthenticated.
6. For user or group, specify the name.
7. Select the check box for each permission to enable.
8. Click Apply.
pdadmin
To create an ACL entry for an ACL policy in the domain using the pdadmin utility,
log in to the domain as a domain administrator and use the acl modify command
with the set option.
For example, to create the permissions for user maryj for the Test-ACL ACL policy
to have r (read) action bit, enter the following command:
pdadmin sec_master> acl modify Test-ACL set user maryj r
To show the modifications to the ACL, use the acl show command. For example,
to show the ACL named Test-ACL, enter the following command:
90
Administration Guide
pdadmin sec_master> acl show Test-ACL
ACL Name: Test-ACL
Description:
Entries:
User
maryj r
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Modifying permissions for an ACL entry
You can modify permissions for an ACL policy using Web Portal Manager or the
pdadmin utility. Use this procedure to modify the permissions for any user, group,
or special ACL entry type (any-other and unauthenticated).
Web Portal Manager
To modify permissions in an ACL entry, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, click the link for the ACL policy you want to
change.
4. From the ACL Properties page, click the permission link.
5. From the ACL Entry Properties page, select the check box for each permission
to enable or clear the check box for each permission to disable.
6. Click Apply.
pdadmin
To modify an ACL policy in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the acl modify command with the set
option.
For example, to modify the permissions for user maryj for the Test-ACL ACL policy
to have r (read) and w (write) action bits, enter the following command:
pdadmin sec_master> acl modify Test-ACL set user maryj rw
To show the modifications to the ACL, use the acl show command. For example,
to show the ACL named Test-ACL, enter the following command:
pdadmin sec_master> acl show Test-ACL
ACL Name: Test-ACL
Description:
Entries:
User
maryj rw
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Removing ACL entries from an ACL policy
You can remove ACL entries from an ACL policy using Web Portal Manager or the
pdadmin utility. Use this procedure to remove the ACL entry for any user, group,
or special ACL entry type (any-other and unauthenticated).
Web Portal Manager
To remove an ACL entry, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
Chapter 8. Managing access control
91
3. From the Manage ACLs page, click the link for the ACL policy that you want
to remove.
4. From the ACL Properties page, select the user, group, or special ACL entry type
to remove.
5. Click Delete.
pdadmin
To remove an ACL entry from an ACL policy in the domain using the pdadmin
utility, log in to the domain as a domain administrator and use the acl modify
command with the remove option.
For example, to remove the ACL entry for user maryj from the Test-ACL ACL
policy, enter the following command:
pdadmin sec_master> acl modify Test-ACL remove user maryj
To show the modifications to the ACL, use the acl show command. For example,
to show the ACL named Test-ACL, enter the following command:
pdadmin sec_master> acl show Test-ACL
ACL Name: Test-ACL
Description:
Entries:
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Managing extended attributes in ACL policies
You can perform the following extended attribute tasks on an ACL policy:
v “Creating extended attributes for an ACL policy”
v “Modifying extended attributes from an ACL policy” on page 93
v “Listing extended attributes of an ACL policy” on page 93
v “Viewing extended attributes of an ACL policy” on page 94
v “Deleting extended attributes from an ACL policy” on page 94
v “Deleting extended attribute values from an ACL policy” on page 95
In the following sections, instructions are provided for using either Web Portal
Manager or pdadmin, or both. For online help while using Web Portal Manager,
click the question mark to open a separate help window for the current page.
Creating extended attributes for an ACL policy
You can create an extended attribute for an ACL policy using Web Portal Manager
or the pdadmin utility.
Web Portal Manager
To create an extended attribute for an ACL policy, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, click the link of the ACL policy for which you
want to create an extended attribute.
4. From the ACL Properties page, click the Extended Attribute tab.
5. Click Create.
92
Administration Guide
6. From the Create Extended Attribute page, define the extended attribute:
a. In the Attribute Name field, type the name of the attribute. This field is
displayed only when the attribute type is “Generic Attribute”.
b. In the Attribute Type field, select the type of attribute.
c. In the Attribute Value field, select the value for the attribute, unless the
selected attribute type is “Generic Attribute”. When you select the “Generic
Attribute” attribute type, type the value for the attribute.
7. Click Apply.
pdadmin
To create an extended attribute for an ACL policy in the domain using the
pdadmin utility, log in to the domain as a domain administrator and use the acl
modify command with the set attribute option.
For example, to create a generic attribute named Dept_No with a value of 445 and
associate it with the ACL named Test-ACL, enter the following command:
pdadmin sec_master> acl modify Test-ACL set attribute Dept_No 445
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Modifying extended attributes from an ACL policy
You can modify extended attributes for an ACL policy using the pdadmin utility
only. Web Portal Manager does not support modifying attributes. To use Web
Portal Manager, an administrator needs to delete the attribute and then create the
attribute again.
pdadmin
To modify an extended attribute for an ACL policy in the domain using the
pdadmin utility, log in to the domain as a domain administrator and use the acl
modify command with the set attribute option.
For example, to modify a generic attribute named Dept_No and add a value of 445
and associate it with the ACL named Test-ACL, enter the following command:
pdadmin sec_master> acl modify Test-ACL set attribute Dept_No 445
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing extended attributes of an ACL policy
You can list the extended attributes of an ACL policy using Web Portal Manager or
the pdadmin utility.
Web Portal Manager
To list all the extended attributes of an ACL policy in the domain, complete the
following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, click the link for name of the ACL policy that
you want to view.
4. From the ACL Properties page, click the Extended Attribute tab.
Chapter 8. Managing access control
93
The ACL Properties page displays all the extended attributes for the selected ACL
policy.
pdadmin
To list all the extended attributes for an ACL policy using the pdadmin utility, log
in to the domain as a domain administrator and use the acl list command with the
attribute option. For example, to list the extended attributes of the ACL policy
named pub_acl_3, enter the following command:
pdadmin sec_master> acl list pub_acl_3 attribute
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Viewing extended attributes of an ACL policy
You can view the extended attributes of an ACL policy using Web Portal Manager
or the pdadmin utility.
Web Portal Manager
To view the extended attributes of an ACL policy in the domain, complete the
following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, click the link for the ACL policy that you want
to view.
4. Click the Extended Attribute tab.
pdadmin
To view the extended attributes for an ACL policy using the pdadmin utility, log in
to the domain as a domain administrator and use the acl show command with the
attribute option. For example, to show the myAttribute attribute of the test-acl
ACL policy, enter the following command:
pdadmin sec_master> acl show test-acl attribute myAttribute
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting extended attributes from an ACL policy
You can delete an extended attribute for an ACL policy using Web Portal Manager
or the pdadmin utility.
Web Portal Manager
To delete an extended attribute for an ACL policy, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List ACL.
3. From the Manage ACLs page, click the link for the ACL policy from which you
want to delete extended attributes.
4. From the ACL Properties page, click the Extended Attributes tab.
5. Select the extended attributes.
6. Click Delete.
94
Administration Guide
pdadmin
To delete an extended attribute for an ACL policy in the domain using the
pdadmin utility, log in to the domain as a domain administrator and use the acl
modify command with the delete attribute option.
For example, to delete the extended attributed named Dept_No from the ACL
named Test-ACL, enter the following command:
pdadmin sec_master> acl modify Test-ACL delete attribute Dept_No
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting extended attribute values from an ACL policy
You can delete a value for an extended attribute from an ACL policy using the
pdadmin utility only.
pdadmin
To delete an attribute value, log in to the domain as a domain administrator and
use the acl modify command with the delete attribute attribute_name attribute_value
options.
For example, to delete the value 445 from the extended attributed named Dept_No
from the ACL named Test-ACL, enter the following command:
pdadmin sec_master> acl modify Test-ACL delete attribute Dept_No 445
Only the attribute value is deleted.
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Managing action groups
Permissions are used to grant access to perform a specific operation on resources
that are protected by Tivoli Access Manager. Tivoli Access Manager provides 17
predefined permissions for immediate use. These permissions are stored in the
predefined action group named primary.
Each permission is associated with an action bit. These predefined permissions are
described in “Default permissions in the primary action group” on page 80.
Tivoli Access Manager provides the ability to create resource manager-specific
permissions. For example, Tivoli Access Manager for Business Integration defines
Enqueue and Dequeue permissions to grant access to put messages in a message
queue or to get messages from the message queue.
Tivoli Access Manager supports a total of 32 action groups, including the primary
action group.
When you define an action group, the following guidelines and limitations apply:
v Each action group can hold up to 32 action bits (including the action bits for the
17 predefined permissions).
v An action bit is made up of a letter: a-z, A-Z.
v Each action bit character can be used only once within an action group.
v You can reuse the same action bit in other action groups.
Chapter 8. Managing access control
95
You can perform the following action group tasks:
v “Creating action groups”
v “Listing action groups”
v “Deleting an action group” on page 97
Creating action groups
You can create an action group using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To
1.
2.
3.
create an action group, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click ACL → Create Action Group.
Type the new Action Group Name. For example, type test-group.
4. Click Create.
If successful, a message is displayed when the action group is created.
pdadmin
To create an action group in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the action group create command.
For example, to create an action group named test-group, enter the following
command:
pdadmin sec_master> action group create test-group
The primary action group always appears in a group listing and cannot be deleted.
You must have an entry in an ACL on the /Management/ACL object with the modify
(m) action to create action groups and the delete (d) permission to delete action
groups.
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing action groups
You can list all action groups using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To list all action group, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List Action Groups.
The Manage Action Groups page displays a list of all action groups in the domain.
pdadmin
To list all action groups in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the action group list command.
For example, to list all action groups, enter the following command:
pdadmin sec_master> action group list
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
96
Administration Guide
Deleting an action group
You can delete an action group using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To
1.
2.
3.
delete an action group, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click ACL → List Action Groups.
From the Manage Action Groups page, select one or more check boxes for the
action groups that you want to delete.
4. Click Delete.
5. Confirm the deletion by clicking Delete again on the Delete Action Groups
page.
pdadmin
To list action groups in the domain using the pdadmin utility, log in to the domain
as a domain administrator and use the action group delete command.
For example, to delete the action group named test-group, enter the following
command:
pdadmin sec_master> action group delete test-group
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Managing actions
You can perform the following action tasks:
v “Creating actions in an action group”
v “Listing actions in an action group” on page 98
v “Deleting actions from an action group” on page 98
Creating actions in an action group
You can create an action in an action group using Web Portal Manager or the
pdadmin utility.
Web Portal Manager
To create an action in an action group, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List Action Groups.
3. From the Manage Action Group page, click the link for the action group name
in which to create the permission. For example, select the Test-Group link.
4. From the Action Group Properties page, click Create to display the Create
Action page. The Action Group Name is automatically completed.
5. Type a single character Action Name. For example, type x.
6. In the Action Label field, type a short description of the permission. For
example, type Execute.
7. In the Action Type field, type a description of the permission, such as the
application to which the permission is specific. For example, type WebSEAL.
8. Click Create.
If successful, a message is displayed when the permission is created.
Chapter 8. Managing access control
97
pdadmin
To create an action in an action group using the pdadmin utility, log in to the
domain as a domain administrator and use the action create command.
For example, to create an x action bit in the Test-Group action group, enter the
following command:
pdadmin sec_master> action create x Execute WebSEAL Test-Group
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing actions in an action group
You can list all actions in an action group using Web Portal Manager or the
pdadmin utility.
Web Portal Manager
To list all actions in an action group, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List Action Groups.
3. From the Manage Action Group page, click the link for the action group name.
pdadmin
To list the actions in an action group using the pdadmin utility, log in to the
domain as a domain administrator and the action list command.
For example, to list the actions in the Test-Group action group, enter the following
command:
pdadmin sec_master> action list Test-Group
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting actions from an action group
You can delete an action from an action group using Web Portal Manager or the
pdadmin utility.
Web Portal Manager
To delete an action from an action group, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List Action Groups.
3. From the Manage Action Group page, click the link for the action group name
that contains the permission to be deleted.
4. From the Action Group Properties page, select the permission to delete.
5. Click Delete.
6. Confirm the deletion by clicking Delete on the Delete Action page.
pdadmin
To delete an action from an action group using the pdadmin utility, log in to the
domain as a domain administrator and the action delete command.
For example, to delete the x action bit from the Test-Group action group, enter the
following command:
98
Administration Guide
pdadmin sec_master> action delete x Test-Group
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Chapter 8. Managing access control
99
100
Administration Guide
Chapter 9. Protected object policy management
While the access control list (ACL) policies provide the authorization service with
information to make a yes or no answer on a request to access a protected object
and perform some operation on that object, a protected object policy (POP) contains
additional conditions on the request that are passed back to the resource manager
along with the yes ACL policy decision from the authorizations service. It is the
responsibility of Tivoli Access Manager and the resource manager to enforce the
POP conditions.
Table 3 lists the available attributes for a POP that are provided by Tivoli Access
Manager.
Table 3. POP attributes that are enforced by Tivoli Access Manager
POP attribute
Description
Name
Specifies the name of the policy. This attribute relates to
the pop-name variable in the pop command
documentation.
Description
Specifies the descriptive text for the policy. This attribute
appears in the pop show command.
Warning mode
Provides administrators a means to test ACLs, POPs, and
authorization rules. Warning mode provides a way to
test the security policy before it is made active.
Audit level
Specifies the type of auditing: all, none, successful access,
denied access, or errors. Audit level informs the
authorizations service that extra services are required
when permitting access to the object.
Time-of-day Access
Day and time restrictions for successful access to the
protected object. Time-of-day places restrictions on the
access to the object.
IP endpoint authorization
method policy
Specifies authorization requirements for access from
members of external networks. The IP endpoint
authentication method policy places restrictions on the
access to the object.
EAS trigger attributes
Specifies an External Authorization Service (EAS) plug-in
that is invoked to make an authorization decision using
the externalized policy logic of the customer.
Quality of Protection
Specifies the degree of data protection: none, integrity, or
privacy. Quality of Protections informs the authorizations
service that extra services are required when permitting
access to the object.
Although Tivoli Access Manager provides these POP attributes, it only enforces the
following attributes:
v Name
v Description
v Warning mode
v Audit level
v Time-of-day Access
© Copyright IBM Corp. 1999, 2010
101
Each resource manager or plug-in can optionally enforce one or more of the
following attributes:
v IP endpoint authorization method policy
v EAS trigger attributes
v Quality of Protection
For Tivoli Access Manager IP address support:
v You can grant access to a protected resource based on the IP address that is used
by the identity. For example, only users from IP address 9.18.n.n are allowed to
access the protected resource.
v You can define that an additional authentication level is required to access this
protected resource based on the IP address that is used by the identity. The
step-up level authentication is described in “Configuring levels for step-up
authentication” on page 115 and the IBM Tivoli Access Manager for e-business:
WebSEAL Administration Guide.
Managing protected object policies
You create and configure a protected object policy (POP) and then attach the POP
to objects in the protected object space. POPs are placed in the master
authorization database on a per domain basis, which is controlled by the policy
server.
You can perform the following POP tasks:
v “Creating a POP”
v “Modifying a POP” on page 104
v “Listing POPs” on page 105
v “Viewing a POP” on page 105
v
v
v
v
v
v
“Cloning a POP” on page 106
“Importing POPs” on page 106
“Exporting all POPs” on page 107
“Export a single POP” on page 107
“Exporting multiple POPs” on page 107
“Attaching a POP to an object” on page 108
v “Locating where a POP is attached” on page 109
v “Detaching a POP from an object” on page 108
v “Deleting a POP” on page 109
In the following sections, instructions are provided for using either Web Portal
Manager or the pdadmin utility, or both. For online help while using Web Portal
Manager, click the question mark to open a separate help window for the current
page.
Note: There are no equivalent pdadmin commands for importing, exporting, or
cloning POPs.
Creating a POP
You can create a POP using Web Portal Manager or the pdadmin utility. After
creating a POP, you can attach it to an object. For information about attaching a
POP, see “Attaching a POP to an object” on page 108.
102
Administration Guide
Web Portal Manager
To create a POP, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → Create POP to display the Create POP page.
3. In the POP Name field, type the name for the POP. For example, type
poptest1.
4. In the Description field, type a description of the POP.
5. Select one or more check boxes for the appropriate audit levels. The audit
level is the level of auditing that applies when a resource, to which this POP
is attached, is accessed. You can select more than one audit level. The
following choices are available:
Permit
Audits all requests on a protected object that result in successful
access.
Deny
Audits all requests on a protected object that result in denial of access.
Error
Audits all internally generated error messages resulting from a denial
of access to the protected object.
Admin
Audits not used by Tivoli Access Manager. However, this option can
be used by custom applications.
For more information, refer to “Setting an audit level” on page 111
6. Select the Warn Only On Policy Violation check box to enable warning mode
attributes. A warning mode attribute indicates whether a policy violation that
is related to a resource results in denial of access or in an auditable failure. An
auditable failure is an access attempt to a resource, to which a POP applies,
that results in the access being audited, not denied.
For more information, refer to “Setting a warning mode” on page 111.
7. Select a type of Quality of Protection. The level of protection that applies
when a resource, to which this POP is attached, is accessed. The following
choices are available:
None
Requires no Quality of Protection.
Integrity
Uses some mechanism to ensure that the data has not changed.
Privacy
Requires data encryption for Secure Sockets Layer (SSL).
For more information, refer to “Setting a Quality of Protection level” on page
114.
8. Optional: For Time of Day Access, specify the days and times of the day that
the resource can be accessed.
v Select the check boxes for the days of the week that the resource can be
accessed.
v Select either All Day or Between hours of for the access times that the
resource can be accessed on the selected days.
If you select Between hours of, you must also specify the Start time and
End time.
v If you select Between hours of, you must also specify the Local Time or
UTC Time (Coordinated Universal Time).
For more information, refer to “Setting a time-of-day restriction” on page 112.
v
Chapter 9. Protected object policy management
103
9. Click Create or click Create Another if you want to create another POP.
If successful, a message confirming that the POP was created is displayed.
10. If you clicked Create, click Done. Otherwise, repeat this procedure starting at
step 3 on page 103 to create another POP.
pdadmin
To create a POP in the domain using the pdadmin utility, log in to the domain as a
domain administrator and use the pop create command.
For example, to create a POP named poptest1, enter the following command:
pdadmin sec_master> pop create poptest1
The new POP contains the following default settings:
pdadmin sec_master> pop show poptest1
Protected object policy: poptest1
Description:
Warning: no
Audit level: none
Quality of protection: none
Time of day access: sun, mon, tue, wed, thu, fri, sat:
anytime:local
IP Endpoint Authentication Method Policy
Any Other Network 0
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Modifying a POP
You can modify a POP using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To
1.
2.
3.
modify a POP, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click POP → List POP to display the Manage POPs page.
Click the link for the POP. For example, select poptest1 to display the POP
Properties page.
4. Click the General tab to change the information pertaining to the POP, as
needed. For example, change the description from Test POP to Test 1 for POP,
and then click Apply.
5. Click the Attach tab to change the protected object attachments.
6. Click the IP Auth tab to change the IP authentication.
7. Click the Extended Attributes tab to change an extended attribute.
pdadmin
To modify a POP using the pdadmin utility, log in to the domain as a domain
administrator and use the pop modify commands. For example to enable the
warning mode and set the audit level to permit and deny for the poptest1 POP,
enter the following commands:
pdadmin sec_master> pop modify poptest1 set warning yes
pdadmin sec_master> pop modify poptest1 set audit-level permit,deny
To show these modifications, use the pop show commands. For example, to show
the modifications to the poptest1 POP, enter the following command:
104
Administration Guide
pdadmin sec_master> pop show poptest1
Protected object policy: poptest1
Description: Test 1 for POP
Warning: yes
Audit level: permit, deny
Quality of protection: none
Time of day access: sun, mon, tue, wed, thu, fri, sat:
anytime:local
IP Endpoint Authentication Method Policy
Any Other Network 0
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing POPs
You can list all POPs using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To view a list of all POPs, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → List POP to display the Manage POPs page.
All the POPs for the domain are listed as links.
pdadmin
To list all POPs in the domain using the pdadmin utility, log in to the domain as a
domain administrator and use the pop list command.
For example, to list all POPs, enter the following command:
pdadmin sec_master> pop list
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Viewing a POP
You can view a POP using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To view a POP, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → List POP to display the Manage POPs page.
3. Click the link for the POP. For example, select poptest1 to display the POP
Properties page.
4. On the General tab, change the information pertaining to the POP, as needed.
For example, change the description from Test POP to Test 1 for POP, and
then click Apply.
5. Click the Attach tab to view the protected object attachments.
6. Click the IP Auth tab to view the IP authentication.
7. Click the Extended Attributes tab to view all extended attributes.
pdadmin
To view a POP using the pdadmin utility, log in to the domain as a domain
administrator and use the pop show commands.
Chapter 9. Protected object policy management
105
For example, to show the modifications to the POP name poptest1, enter the
following command:
pdadmin sec_master> pop show poptest1
Protected object policy: poptest1
Description: Test 1 for POP
Warning: no
Audit level: none
Quality of protection: none
Time of day access: sun, mon, tue, wed, thu, fri, sat:
anytime:local
IP Endpoint Authentication Method Policy
Any Other Network 0
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Cloning a POP
You can clone a POP using the Web Portal Manager only. To clone a POP in the
domain, complete the following steps:
1.
2.
3.
4.
5.
Use Web Portal Manager to log in to the domain as a domain administrator.
Click POP → List POP.
From the Manage POPs page, select the POP you want to clone.
From the POP Properties page, click Clone.
From the Clone POP page, in the POP Name text field, type the name of the
POP. For example, type Test-POP. The default value is the name of the original
POP with the prefix Clone. This field is required.
6. Optional: In the Description text field, type the description of the POP. For
example, type Clone of new POP. The default value is the description of the
original POP.
7. Click Clone.
If successful, a link for this cloned POP is created and a success message is
displayed.
Importing POPs
You can import a POP by using Web Portal Manager only. To import a POP in the
domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → Import POP.
3. From the Import POP page, complete one of the following steps:
v In the POP File Name field, type the name of the POP to import. For
example, type popImport.xml.
v Click Browse to select a file name.
4. If the file containing the POP was encrypted when it was exported, in the
Encryption String text field, type the string that was used to encrypt the XML
file.
5. Click Import.
If successful, the imported POP is available when you list all the POPs.
106
Administration Guide
Exporting all POPs
You can export all POPs using Web Portal Manager only. To export all POPs in the
domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → Export All POPs to display the Export POP to File page.
3. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
4. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
5. Click Export to display the File Download window.
6. Click Save to display the Save As window.
7. Click Save to create the file that contains the exported POP description. The
default file name is popExport.xml.
If successful, the exported POP description is available in the specified location.
Export a single POP
You can export a single POP using Web Portal Manager only. To export a single
POP in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → List POP.
3. From the Manage POPs page, select the POP that you want to export.
4. From the POP Properties page, click Export to display the Export POP to File
page.
5. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
6. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
7. Click Export to display the File Download window.
8. Click Save to display the Save As window.
9. Click Save to create the file that contains the exported POP description. The
default file name is popExport.xml.
If successful, the new XML file is available in the specified location.
Exporting multiple POPs
You can export POPs using Web Portal Manager only. To export POPs in the
domain from a list, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → List POP.
3. From the Manage POPs page, select the POPs that you want to export.
4. Click Export to display the Export POP to File page.
5. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
6. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
7. Click Export to display the File Download window.
8. Click Save to display the Save As window.
Chapter 9. Protected object policy management
107
9. Click Save to create the file that contains the exported POP descriptions. The
default file name is popExport.xml.
If successful, the new XML file is available in the specified location.
Attaching a POP to an object
You can attach a POP to an object using Web Portal Manager or the pdadmin
utility.
To perform this task, the administrator requires the attach (a) permission.
Web Portal Manager
To
1.
2.
3.
attach a POP to an object, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click POP → List POP to display the Manage POPs page.
Click the link for the POP.
4. From the POP Properties page, click the Attach tab.
5. Click Attach to display the Attach POP page.
6. Type the Protected Object Path for the protected object to which to attach the
POP. Express the path as the full path name. For example, type
/WebSEAL/serverA/index.html.
7. Click Attach.
If successful, the protected object is added to the list at the POP Properties–Attach
page.
pdadmin
To attach a POP to a protected object in the domain by using the pdadmin utility,
log in to the domain as a domain administrator and use the pop attach command.
For example, to attach a POP named poptest1 to a protected object named
/WebSEAL/serverA/index.html enter the following command:
pdadmin sec_master> pop attach /WebSEAL/serverA/index.html poptest1
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Detaching a POP from an object
You can detach a POP from a protected object using Web Portal Manager or the
pdadmin utility.
To perform this task, the administrator requires the attach (a) permissions.
Web Portal Manager
To
1.
2.
3.
4.
detach a POP from a protected object, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click Object Space → Browse to display the Browse Object Space page.
Click the link for the POP.
From the POP Properties page, click the Attach tab.
5. Select one or more check boxes for the protected objects from which you want
to detach the POP.
108
Administration Guide
6. Click Detach to display the Detach POP from Object page, where you are
prompted to confirm or cancel the detachment.
pdadmin
To detach a POP from a protected resource in the domain by using the pdadmin
utility, log in to the domain as a domain administrator and use the pop detach
commands.
For example, to detach the POP from the protected object named
/WebSEAL/serverA/index.html, enter the following command:
pdadmin sec_master> pop detach /WebSEAL/serverA/index.html
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Locating where a POP is attached
You can locate where a POP is attached using Web Portal Manager or the pdadmin
utility.
Web Portal Manager
To locate where a POP is attached, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click ACL → List POP. A list of POP names is displayed. Each POP name is a
link that you can click to display the POP properties page.
3. Click the Attach tab.
pdadmin
To locate where a POP is attached in the domain using the pdadmin utility, log in
to the domain as a domain administrator and use the pop find command.
For example, to find where the POP named poptest1 is attached, enter the
following command:
pdadmin sec_master> pop find poptest1
/WebSEAL/serverA/index.html
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting a POP
You can delete a POP using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To delete a POP, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click POP → List POP to display the Manage POPs page.
3. Select one or more check boxes for the POPs that you want to delete.
4. Click Delete to display the Delete Pop page.
5. Click Delete to confirm the deletion.
pdadmin
To delete a POP in the domain using the pdadmin utility, log in to the domain as a
domain administrator and use the pop delete command.
Chapter 9. Protected object policy management
109
For example, to delete the POP named poptest2, enter the following command:
pdadmin sec_master> pop delete poptest2
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Network-based authorization algorithm
The authorization server uses the following algorithm to process the conditions in
a POP:
1. Check ACL permissions.
Note: The ACL policy bypass (B) permission overrides POP authorization
conditions on an object. This permission must be used only by a
high-level administrator who needs full access to the protected object
space.
2. Verify whether a rule is attached to the object, then verify that all the access
decision information (ADI) is present for the coming rule evaluation. If it is not,
then find it by querying one of the available sources.
3. Check the IP endpoint authentication method policy on the POP.
4. Check the time-of-day policy on the POP.
5. Check the audit level policy on the POP.
6. Check the authorization rule policy if a rule is attached to the object.
7. If an external authorization service (EAS) operation or POP trigger applies to
this access decision, then invoke the EAS that applies.
Network-based authorization policy
The network-based authorization policy allows you to control access to objects
based on the IP address of the user. When an environment contains both IP version
4 (IPv4) and IP version 6 (IPv6) address formats, be aware of the following
restrictions:
v For administration commands (for example, pop modify set ipauth), IPv4 clients
must provide addresses in IPv4 format even with IPv6 servers.
v For C APIs, IPv4 clients must provide addresses in IPv4 format even with IPv6
servers.
v For C APIs, IPv6 clients can provide addresses in IPv4 or IPv6 format to IPv6
servers.
v For Java methods, both IPv4 and IPv6 clients must provide addresses in IPv4
format to IPv4 servers.
v For Java methods, IPv4 clients can provide addresses in IPv4 or IPv6 format to
IPv6 servers.
For an IPv6 address to be accepted (commands, C APIs, and Java methods), the
server must be IPv6. You cannot provide an IPv6 address to an IPv4 server.
This authorization policy uses the IP endpoint authentication method policy POP
attribute. You can use this functionality to prevent specific IP addresses or IP
address ranges from accessing any resources in your domain. When setting an
authorization policy, you can apply requisite step-up configuration.
110
Administration Guide
The network-based authorization policy is set in the IP endpoint authentication
method attribute of a POP. When you define a network-based authentication
policy, specify the two parts for the attribute:
v Step-up authentication
v Allowed networks
You can also apply step-up authentication configuration to this policy and require
a specific authentication method for each specified IP address range. For more
information about authentication levels, see “Step-up authentication” on page 114.
Note: The IP address used by the resource manager for enforcing the
network-based authorization policy must be the IP address of the originator
of the connection. If your network topology uses proxies, the address that
appears to the resource manager might be the IP address of the policy proxy
server.
In this case, the resource manager cannot definitively identify the true IP
address of the client. When setting a network-based authorization policy
that depends on specific client IP addresses, ensure that those network
clients are connecting directly to the resource manager.
Configuring POP attributes
POP attributes impose access conditions on an object based on the time of the
access and to indicate whether the access request must be audited.
Setting a warning mode
The pop modify set warning command defines the warning mode attribute to
allow a security administrator to debug or troubleshoot the accuracy of the
authorization policy set on the protected object space.
When you set the warning mode attribute to yes, any action is possible by any
user on the object where the POP is attached. Any access to an object is permitted
even if the security policy that is attached to the object is set to deny this access.
Audit records are generated that capture the results of all security policies with
warning mode set throughout the object space. The audit log shows the outcome
of an authorization decision as if the warning attribute was set to no. Therefore, the
administrator can determine if the policy is set and enforced correctly.
For example:
pdadmin sec_master> pop modify poptest1 set warning yes
For more information about the pop commands, see IBM Tivoli Access Manager for
e-business: Command Reference.
Setting an audit level
The pop modify set audit-level command specifies the granularity level of
auditing for a POP. For example, if auditing is set to record unsuccessful events,
you can use the results to detect an unusual number of failed access attempts on a
particular resource.
Chapter 9. Protected object policy management
111
Auditing records are written in a standard Extensible Markup Language (XML)
format that allows easy parsing to extract whatever information is required. For
example:
pdadmin sec_master> pop modify pop_name set audit-level permit,deny
Table 4. Audit levels
Value
Description
permit
Audit all requests on a protected object that result in successful access.
deny
Audit all requests on a protected object that result in denial of access.
error
Audit all internally generated error messages resulting from a denial of
access to the protected object.
You can apply any combination of these values or specify either all to audit all
requests or none to audit no requests. When enabling granular auditing, specify
one or more of the following values:
v permit
v deny
v error
When you specify multiple granular values, use a comma as a separator character
between these values.
For more information about the pop commands, see IBM Tivoli Access Manager for
e-business: Command Reference.
Setting a time-of-day restriction
The pop modify set tod-access command defines the time-of-day (TOD) attribute
that allows you to place specific day and time conditions on the access to a
protected object. This type of condition might be useful to limit access to
information that regularly requires periods of inactivity for modification and
updates.
pdadmin sec_master> pop modify pop_name set tod-access
time_of_day_string
The time-of-day-string argument includes a day-range and a time-range and uses
the following format:
{anyday|weekday|day_list}:
{anytime|time_spec-time_spec}
[:{utc|local}]
The day_list variable can be any combination of the following values:
mon, tue, wed, thu, fri, sat, sun
The time_spec range variable must be expressed (using 24 hour time) in the
following format:
hhmm-hhmm
For example, you can specify the time range using the following string:
0700-1945
The optional time zone [:{utc|local}] for the server (not the client) is local by
default.
112
Administration Guide
For example to change the time-of-day attribute to Monday, Tuesday, and Friday
from 1:15 p.m. to 5:30 p.m. local time for the POP named poptest1, enter the
following command:
pdadmin sec_master> pop modify poptest1 set tod-access mon,tue,fri:1315-1730
For more information about the pop modify commands, see IBM Tivoli Access
Manager for e-business: Command Reference.
Specifying IP addresses and ranges
The pop modify set ipauth command allows the specification of a network (or
network range) and the required authentication level in the POP. The network (or
network range) can be an IP version 4 (IPv4) or an IP version 6 (IPv6) address.
Note: When adding addresses to a POP, IPv4 addresses must be specified in IPv4
format, due to limitations in the operating system functions provided to
Tivoli Access Manager.
All POPs have an anyothernw (any other network) IP entry whose default
authentication level is 0. The anyothernw entry applies to all networks not
specified in the POP. Authentication level 0 adds no additional requirement for
authentication. The anyothernw authentication level can be modified to a non-zero
number or to forbidden.
The anyothernw entry appears in a POP as Any Other Network in the output of the
pop show command:
pdadmin sec_master> pop show poptest1
Protected object policy: poptest1
Description: Test POP
Warning: no
Audit level: none
Quality of protection: none
Time of day access: sun, mon, tue, wed, thu, fri, sat:
anytime:local
IP Endpoint Authentication Method Policy
Any Other Network 0
For more information about setting the IP authentication mechanism using the pop
modify command, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Adding IP entries
To add IP entries to a POP, specify network (or network range) with an
authentication level as a number or as forbidden. Specifying an authentication
level of 0 indicates that authentication is allowed. A forbidden authentication level
indicates that authentication is denied. Specifying an authentication greater than 0
provides the ability to step-up a user to an authentication level. The enforcement of
step-up authentication is the responsibility of resource managers. For more
information about step-up authentication, see “Step-up authentication” on page
114.
Note: When adding addresses to a POP, IPv4 addresses must be specified in IPv4
format, due to limitations in the operating system functions provided to
Tivoli Access Manager.
The following example adds an IP entry for identities from IPv4 addresses that
begin with 9.
Chapter 9. Protected object policy management
113
pdadmin sec_master> pop modify poptest1 set ipauth add 9.0.0.0 255.0.0.0 5
The following example adds an entry for an IPv6 network range:
pdadmin sec_master> pop modify poptest1 set ipauth add \
fedc:ba98:7654:3210:fedc:ba98:7654:3210 ffff:ffff:ffff:ffff:ffff:ffff:ffff:0 6
The following example prevents all users (except users specified like in the
examples above) from accessing the object:
pdadmin sec_master> pop modify poptest1 set ipauth anyothernw forbidden
For more information about adding IP entries to a POP using the pop modify
command, see the IBM Tivoli Access Manager for e-business: Command Reference.
Deleting IP entries
The following example deletes an IPv4 entry from the poptest1 POP:
pdadmin sec_master> pop modify poptest1 set ipauth remove 9.0.0.0 255.0.0.0
Only network entries that were previously added can be removed. For more
information about removing IP entries from a POP using the pop modify
command, see the IBM Tivoli Access Manager for e-business: Command Reference.
Setting a Quality of Protection level
The Quality of Protection POP attribute allows you to specify what level of data
protection is required when performing an operation on an object.
The Quality of Protection POP attribute permits a single transaction where the yes
response to the ACL decision also includes the required Quality of Protection level.
If the resource manager cannot guarantee the required level of protection, the
request is denied.
Use the following pop modify command syntax to modify the QoP level for an
object:
pdadmin sec_master> pop modify pop-name set qop {none|integrity|privacy}
QoP level
Description
privacy
Data encryption is required for Secure Sockets Layer (SSL).
integrity
Use some mechanism to ensure that the data has not changed.
For example, to modify the POP named poptest1 to set the Quality of Protection
level to use SSL data encryption, enter the following command:
pdadmin sec_master> pop modify poptest1 set qop privacy
Step-up authentication
You can use protected object policies (POPs) to enforce certain access conditions on
specific resources. The authentication strength policy makes it possible to control
access to objects based on authentication method.
You can use this functionality, sometimes known as step-up authentication, to
ensure that users accessing more sensitive resources use a stronger authentication
mechanism. You might want this condition because of the greater threat of
improper access to certain resources.
114
Administration Guide
For example, you can provide greater security to a junctioned region of the
protected object space by applying a step-up POP policy that requires a stronger
level of authentication than the client used when initially entering the domain.
The authentication strength policy is set in the IP endpoint authentication method
attribute of a POP policy.
Configuring levels for step-up authentication
The first step in configuring authentication-specific access is to configure the
supported authentication methods and determine the order in which these
authentication methods must be considered stronger.
Any client accessing a resource manager has an authentication level, such as
“unauthenticated” or “password”, which indicates the method with which the
client was last authenticated by the resource manager.
In some situations, it might be necessary to enforce minimum safe levels of
authentication required to access certain resources. For example, in one
environment, authentication by token pass code might be considered more secure
than authentication by user name and password. Another environment might
require different standards.
Rather than forcing clients to restart their sessions with the resource manager when
they do not meet the required level of authentication, the step-up authentication
mechanism provides clients a second chance to authenticate using the required
method of authentication (level).
Step-up authentication allows resource managers to control how users access
protected resources. If step-up authentication is required because the user has not
authenticated with the sufficient method, the access decision is still permitted by
the authorization engine but the resource manager is presented with a required
authentication level as an output of the authorization decision. The resource
manager can then decide how to further authenticate the user to gain the required
level of authentication needed for the user to access the protected object.
How a particular authentication method is mapped to an authentication level is
determined by the resource manager application. For all cases, the absolute
minimum acceptable method of authentication must be set as level 0 with more
secure methods being mapped to integral numbers in ascending order (1..x) from
that point forward.
Applying step-up authentication policy
Step-up authentication is implemented through a POP policy placed on the objects
requiring authentication-sensitive authorization. You use the IP endpoint
authentication method attribute of a POP policy.
The pop modify set ipauth command specifies both the allowed networks and the
required authentication level in the IP endpoint authentication method attribute.
Note: When specifying an IPv4 address it must be in IPv4 format.
The configured authentication levels can be linked to IP address ranges. This
method is intended to provide management flexibility. If filtering users by IP
address is not important, you can set a single entry for anyothernw (any other
network). This setting affects all accessing users, regardless of IP address, and
Chapter 9. Protected object policy management
115
requires the users to authenticate at the specified level. This method is the most
common method for implementing step-up authentication.
The anyothernw entry is used as a network range that matches any network not
otherwise specified in the POP. This method can be used to create a default entry
that could either deny all unmatched IP addresses or allow anyone access who can
meet the authentication level requirement.
By default, anyothernw appears in a POP with an authentication level index of 0.
The entry appears as Any Other Network in the output of the pop show command.
The following output shows a sample for the poptest1 POP:
pdadmin sec_master> pop show poptest1
Protected object policy: poptest1
Description: Test POP
Warning: no
Audit level: none
Quality of protection: none
Time of day access: sun, mon, tue, wed, thu, fri, sat:
anytime:local
IP Endpoint Authentication Method Policy
Any Other Network 0
For more information about the pop modify set ipauth command, see the IBM
Tivoli Access Manager for e-business: Command Reference.
Distinguishing step-up from multi-factor authentication
Tivoli Access Manager step-up authentication and multi-factor authentication are
two different mechanisms for controlling access to resources. Tivoli Access
Manager provides only step-up authentication functionality.
Multi-factor authentication forces a user to authenticate using two or more levels
of authentication. For example, the access control on a protected resource can
require the user to authenticate with both user name and password (level 1) and
also require the user to authenticate with user name and token passcode (level 2).
Tivoli Access Manager step-up authentication relies on a pre-configured hierarchy
of authentication levels and enforces a specific level of authentication according to
the policy set on a resource. Step-up authentication does not force the user to
authenticate using multiple levels of authentication to access any given resource.
Instead, step-up authentication requires the user to authenticate at a level at least
as high as the level required by the policy protecting the resource.
The following example shows the series of commands that are needed to define
step-up authentication:
pdadmin > pop create test1
pdadmin > pop modify test1 set ipauth anyothernw 1
pdadmin > pop attach /WebSEAL/hostA/junction test1
pdadmin > pop create test2
pdadmin > pop modify test2 set ipauth anyothernw 2
pdadmin > pop attach /WebSEAL/hostA/junction/applicationA test2
In the previous example, the /WebSEAL/hostA/junction object is protected by a
POP requiring authentication level 1, and the /WebSEAL/hostA/junction/
applicationA object is protected by a POP requiring authentication level 2.
116
Administration Guide
Under step-up authentication, user name/password (level 1) authentication is
required to access /WebSEAL/hostA/junction.
However, user name/token passcode (level 2) authentication is required to access
/WebSEAL/hostA/junction/applicationA. If the user is currently logged in with a
user name and password, a prompt appears requesting user name and token
passcode information (the step-up). However, if the user initially logged in to
WebSEAL using a user name and a token passcode, access to applicationA is
immediate (assuming a successful ACL check).
Multi-factor authentication requires both level 1 and level 2 authentication for
access to applicationA.
Chapter 9. Protected object policy management
117
118
Administration Guide
Chapter 10. Authorization rules management
This chapter provides information about Tivoli Access Manager authorization
rules. Authorization rules are conditions contained in an authorization policy that
are used to make access decisions based on attributes such as user, application, and
environment context.
This chapter contains the following sections:
v “Authorization rules overview”
v “Access decision information”
v “Authorization rule language” on page 122
v “Authorization rules evaluator” on page 128
v “Examples of authorization rules” on page 131
v “Methods of providing ADI to the rules evaluator” on page 133
v “Reason codes for rule failures” on page 135
v “Configuration file and initialization attributes” on page 135
v “Managing authorization rules” on page 137
Authorization rules overview
Authorization rules are defined to specify conditions that must be met before
access to a protected object is permitted. A rule is created using a number of
Boolean conditions that are based on data supplied to the authorization engine
within the user credential, from the resource manager application, or from the
encompassing business environment. The language of an authorization rule allows
customers to work with complex, structured data by examining the values in that
data, and making informed access decisions. This information can be defined
statically within the system or can be defined during a business process. Rules can
also be used to implement extensible, attribute-based, authorization policy by
using attributes within the business environment or attributes from trusted external
sources.
A Tivoli Access Manager authorization rule is a policy type like an access control
list (ACL) or a protected object policy (POP). The rule is stored as a text rule
within a rule policy object and is attached to a protected object in the same way
and with similar constraints as ACLs and POPs.
Access decision information
The data and attributes that are used in rule conditions collectively are called access
decision information (ADI). Authorization API attributes, which are name and value
pairs, form the basis of all ADI that can be referenced in a rule or presented to the
authorization engine.
Sources for retrieving ADI
The authorization engine can gather ADI from the following sources:
v User credential entitlements
v Application context information passed in by the Tivoli Access Manager resource
manager
© Copyright IBM Corp. 1999, 2010
119
v Tivoli Access Manager authorization engine context
v Dynamic ADI retrieval entitlement services
User credential entitlements
Additional entitlements data can be inserted as attribute name-value pairs into the
client credential by a Tivoli Access Manager authorization client during the user
authentication process or at any time during the process of the transaction. For
example, Tivoli Access Manager can be configured to gather entitlements at the
time that a user is authenticated. You can configure entitlement services to run
during credential acquisition, collect entitlements data, and then append the data
to the credential. Tivoli Access Manager provides a credential attributes entitlement
service that retrieves entitlements data from the user registry. Or, you can define
your own entitlement services. For more information about defining entitlement
services, refer to IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
Any attribute added to the user credential can be used as ADI in a rule definition.
There are also attributes that are built into the Tivoli Access Manager user
credential when it is created by the authorization engine. Just like attributes that
can be added to the credential by the resource manager, the built-in credential
attributes can be used in authorization rules. The built-in credential attributes
include items of information, such as the user name (or the principal UUID) and
the groups (or the group UUID) of which the user is a member.
See the IBM Tivoli Access Manager for e-business: Authorization C API Developer
Reference for a table of valid credential attribute names. All credential attribute
names begin with azn_cred_ (for example, azn_cred_principal_uuid). This table
lists attribute names available within the Tivoli Access Manager authenticated user
credential, their value, and a description. Many attributes in this table are also
available in an unauthenticated user credential, except attributes related to a the
identity of a user. For example, attributes such as the user name, principal UUID,
group name, and group UUID, as well as the LDAP DN for LDAP configurations
are not available in an unauthenticated credential. When developing rules that use
these particular attributes, the authorization engine requires all ADI to be present
before a rule can be evaluated. If the ADI is not available, the authorization
decision is returned with an error status. Requiring the user to authenticate before
accessing the protected object with such a rule attached ensures that the
authenticated credential information is available. This requirement can be achieved
using an ACL entry on the object that requires authenticated access.
Application context information
Authorization rules might require application context information to complete an
evaluation. Context information includes information that is not an entitlement but
is specific to the current transaction or operation. An example is a transaction
amount, such as purchase price or transfer amount. This information is passed to
the decision through the app_context attribute list of the
azn_decision_access_allowed_ext() call. Tivoli Access Manager WebSEAL also
uses this mechanism to pass the values of certain HTML tags and HTML request
data (from a get or post request) into the access decision for use in a rule
evaluation.
Authorization engine context information
Authorization engine context information is provided automatically by the
authorization engine, if required, before the authorization rule is evaluated. The
ADI provided by the authorization engine includes the name of the protected
120
Administration Guide
object that is the target of the access decision and the string of operations that the
requesting user wants to perform on the protected object.
The following attribute names are reserved for these data items:
v azn_engine_target_resource
v azn_engine_requested_actions
Dynamic ADI retrieval entitlement services
The final source for retrieving ADI is the dynamic ADI retrieval entitlements
service. This class of authorization entitlement services is designed to retrieve ADI
from an external source. These services can be developed to retrieve ADI from an
enterprise database containing employee, customer, partner, or inventory
information. The dynamic ADI retrieval service is called to retrieve ADI when the
access decision is being made. Calling both at the same time has the benefit of
being able to retrieve volatile data, such as quotas, at a time when its value is most
current.
The Tivoli Access Manager Attribute Retrieval Service (AMWebARS) is an example
of a service that can retrieve ADI from external sources. AMWebARS is the official
package name for a Tivoli Access Manager J2EE Web service that implements a
dynamic ADI retrieval service. To facilitate communication between the resource
manager, which is invoking the rules engine, and AMWebARS, which is performed
using SOAP over HTTP, the Access Manager runtime environment (pdrte package)
provides an authorization entitlement service called azn_ent_amwebars.
See the IBM Tivoli Access Manager for e-business: Authorization C API Developer
Reference for more information about developing and using dynamic ADI retrieval
entitlement services to fetch ADI when the rule is evaluated. See the IBM Tivoli
Access Manager for e-business: Administration C API Developer Reference for an
in-depth discussion of attribute lists, their formats, and of the authorization APIs
that are used to manipulate them. For more information about the constraints and
format for ADI, refer to “Format and constraints of rules” on page 129.
Volatile versus nonvolatile data
In general, the source for any particular piece of ADI depends largely on what the
data is. The most important question is whether the data is volatile. For example,
is it possible for the data to change during the lifetime of the session of the user
and, if so, is it important to use the most up-to-date information when it does?
Volatile data must be retrieved using a dynamic ADI retrieval service unless the
resource manager application can provide this data.
Application-specific data that is nonvolatile and not user-specific is provided by
the resource manager application. Data that is nonvolatile and user-specific is
loaded into the user credential when the user is authenticated and is kept with the
credential for the lifetime of the user session.
The set of data provided by the authorization engine, including the target
protected object and permissions, is fixed and cannot be changed.
Chapter 10. Authorization rules management
121
Authorization rule language
Extensible Style Language (XSL) is the language used to specify rules and
Extensible Markup Language (XML) is the language used for the data that forms
an input to the rules. The combination of XML and XSL provides a platform
independent way to express both the inputs to the rules evaluator and the rules
themselves.
XML also provides the ability to express complex data types in a structured and
standard manner in text format. This text format allows rules for processing the
XML data to be written without having to cater to platform and programming
language specifics.
XSL is a functional stylesheet language that can be used to perform simple tasks or
complex tasks depending on your needs. XSL possesses an inherent ability to
analyze and evaluate XML data, which is becoming the standard for data
representation in e-business models. XSL is built on other XML-based standards
such as XPath, which is the expression language at the core of an authorization
rule.
To implement rules-based authorization policy, it is necessary to impose a number
of constraints on the XSL rules, including the requirements that the output of the
rule evaluation are simple text and that the output conforms to one of a known set
of result strings. For more information about the format and constraints of
authorization rules, see “Format and constraints of rules” on page 129.
It is also necessary to impose constraints on the XML input document that is built
as input to the rule evaluation. The ADI XML document model enables the
authorization engine to detect when ADI is missing and when it needs to be
requested from the resource manager or an external entity through the dynamic
ADI retrieval service interface.
ADI XML document model
The ADI XML document model (or ADI XML model) is a set of restrictions placed
on the XSL/XML model by the authorization rules implementation to enable the
interface to be simple and yet functional for authorization purposes. The model
constrains the authorization rules to function within a predetermined XML
document format with the same top-level XML document element for all rules. The
XML ADI that is imported by the rules evaluator from credential attributes, from
application context, or from other data sources must be inserted into this XML
document before authorization rules can use the data. Similarly to simplify the
process of defining rules, the authorization rules must operate within the confines
of the ADI XML model. The ADI XML model requires the XML document to
contain the following top-level XML element into which all target ADI for a
particular rule evaluation is inserted. The XMLADI element is created automatically
as part of the rule evaluation process by the authorization engine.
<XMLADI>
<!-XML formatted ADI are inserted here.
</XMLADI>
-->
As a result of this restriction, the XPath to the data used in an authorization rule
must include the prefix /XMLADI to access a particular data element within the
model. For example, if an ADI item of JohnSmith is added to the document to
access the fields of JohnSmith within the ADI XML document, you have to specify
the XPath /XMLADI/JohnSmith to access the data contained in the XML object
JohnSmith.
122
Administration Guide
An XPath is the path to a particular child element within the hierarchy of a
structured XML data object. Much like a directory path on a hard disk drive is
used to access a specific file, an XPath designation starts from the root of the
document (in this case /XMLADI) and traces a path from this root down through its
child elements to the specific element that is being referenced. For example, using
the example entitlement JohnSmith in the “XML entitlement example” on page 125
as a reference, the JohnSmith XML object has a child element called CreditCard.
The child elements of the CreditCard element are attributes which are common to
most credit cards. To access Balance under the CreditCard element of JohnSmith,
you would use the following XPath:
"/XMLADI/JohnSmith/CreditCard/Balance"
XPaths like this example are the means by which authorization rules access the
ADI data values that are needed to make attribute-based authorization decisions.
All data elements are restricted to work within the ADI XML model. So the
authorization rules must also be restricted to operate on or match XPaths within
the model. Therefore, XSL template match statements are also restricted to
matching XPaths starting from /XMLADI within the ADI XML document. For
additional information, see “Format and constraints of rules” on page 129.
Containers and XML ADI container names
When data is requested from a resource manager, the granularity of the XML data
returned is at the level of a single container of information. The container is
normally also the smallest data element (for example, elements that might be
considered for billing purposes). This convention was adopted for the ADI XML
model as well. The ADI that is used in authorization rules is also defined and
manipulated as containers of XML data. For example, the JohnSmith XML object
defined in “XML entitlement example” on page 125 is an example of an ADI
container.
To this end, the top-most element in the definition of an item of ADI is referred to
as the container name of that item of ADI. When defining an authorization rule, the
XPath to the XML definition of data in any ADI container must always be
referenced using the name of the container as the first element /XMLADI in the
XPath specification for the data element.
Returning to the example ADI item JohnSmith, you can assume there is a container
received from the data provider named JohnSmith. To access any element within
the JohnSmith container, the XPath specification must be prefixed with JohnSmith.
For example, JohnSmith/CreditCard/AcctNumber refers to the AcctNumber value. To
access this information from within an authorization rule, this XPath must also be
prefixed by the top-level element of the XML target ADI input document, which is
XMLADI (for example, /XMLADI/JohnSmith/CreditCard/AcctNumber). However, both
of these XPaths are valid when used in an authorization rule due to the default
template match statement that is added to all authorization rules that do not
explicitly include one. The default template match statement matches the ADI XML
document from /XMLADI. So JohnSmith can be referred to either with a relative
reference or with an absolute reference that is prefixed with /XMLADI. For additional
information, see “Format and constraints of rules” on page 129.
Limitations of container names
One restriction imposed by the ADI XML document model is that each item of
ADI that can be consumed by the rules evaluator must have a unique container
name that cannot be confused with containers provided by other entitlements data
providers. For example, if two different data providers provide a data item called
Chapter 10. Authorization rules management
123
TxInfo, there is no way for the rules evaluator to know which provider it must
make a request to in order to get this item of data. To help differentiate items of
ADI with the same name, XML provides the ability to define namespaces for data.
The namespace ID of the namespace can then be used to differentiate one ADI
element from another. For TxInfo, we could define a namespace companyA and
reference this instance of ADI with companyA:TxInfo. For more information about
namespace definitions, see “Defining an XML namespace” on page 126.
This restriction on container naming among data providers is not enforced by the
authorization engine. On the contrary, if the engine encounters multiple instances
of the same item of ADI (for example, TxInfo), it adds them all to the ADI XML
document for use in the evaluation. In the ADI XML document, there can be two
items of ADI data with the same container name within the ADI XML input
document. The assumption is then made that they are structured in the exact same
way. For example, a particular application request might involve a number of
individual transactions each with its own transaction amount. An authorization
rule can be formulated to add all these items together and compare the sum of the
items to a predefined total transactions limit or to a per-transaction limit using an
XSL node select statement. “Example: ADI from dynamic ADI retrieval services”
on page 132 in the “Examples of authorization rules” on page 131 section in this
chapter shows an example rule that sums multiple transaction elements in this way
and even counts the number of instances of a particular ADI element.
XML access decision information
By default, the rule evaluator automatically transforms into XML format any
name/value pair attributes passed to it by the calling application that were
identified as target access decision information (ADI) for the current evaluation.
When transforming the attribute to XML, the attribute name is used as the
container name of the XML data item and the attribute value is converted into an
XML value. The container name of an item of ADI equates to the XML element
name in the XML definition. For example, the following XML data is generated for
attribute name VPS_CREDIT_CARD with a string attribute value of 5517 3394 8324
0965:
<VPS_CREDIT_CARD>5517 3394 8324 0965</VPS_CREDIT_CARD>
The container name and XML element name in this case is VPS_CREDIT_CARD. The
graphical user interface, the command-line interface, and the Tivoli Access
Manager authorization API attribute list interfaces do not permit the administrator
to define rules that contain invalid XML container names.
If the application passes entitlements or application context that have already been
formatted as XML for an access decision, the authorization rules evaluator expects
the data to be of type azn_string_t and expects the format of the string to be
XML. The attribute name must match the container name of the XML data item. If
the names do not match, the evaluator does not evaluate the rule correctly.
The evaluator identifies XML format data by locating the less than (<) character at
the beginning of the attribute value. If the attribute value does not begin with a
less than character, the data is not considered to be an XML data item and the
evaluator attempts to convert the data item to XML format automatically. This
means of identification is used only on attributes or application context identified
as target ADI for the access decision. Therefore, non-XML attribute values starting
with a less than character cannot be used by the application and results in an error
status that is returned from the authorization decision. If the data is not correct
XML, the XSL processor fails and returns an error to denote the failure.
124
Administration Guide
Data items that must be defined in XML must be entirely defined in XML and
must not rely on the translation mechanism for non-XML items to generate the
appropriate XML element name automatically. For example, to define an attribute
to contain the XML definition of MY_CREDIT_CARD_NUM, you must add an attribute
with the attribute name MY_CREDIT_CARD_NUM. The attribute value for
MY_CREDIT_CARD_NUM is the following:
<MY_CREDIT_CARD_NUM>5517 3394 8324 0965</MY_CREDIT_CARD_NUM>
By defining the XML element as opposed to only defining its value, XML attributes
can be added to the element definition without affecting the name by which the
ADI is referred to when talking with data providers.
In the following definition of the XML item MY_CREDIT_CARD_NUM, the CardType
XML attribute has the value of "visa". XML attributes are defined in the element
start tag of the element to which they apply. XML attributes are equivalent to any
other first-level child element of the XML object. To reference the attribute
CardType, the required XPath would be:
/XMLADI/MY_CREDIT_CARD_NUM/CardType
XML attributes must not be confused with the authorization API attributes and
attribute lists that are used to carry data into and out of the authorization process.
<MY_CREDIT_CARD_NUM CardType="visa">
5517 3394 8324 0965
</MY_CREDIT_CARD_NUM>
The ability to add XML attributes to an element definition is useful when it comes
to defining a namespace for the data item. For more information about XML
namespaces, see “Defining an XML namespace” on page 126.
If the ADI attribute contains multiple attribute values (string, XML, or any
combination), the evaluator converts each attribute value as a separate instance of
ADI. For example, the TxData attribute has values of 100 and 500. The evaluator
inserts the following XML item declarations into the ADI XML document:
<TxData>100</TxData>
<TxData>500</TxData>
The policy administrator can then design an authorization rule that uses XSL
language node selection statements to work with these two values independently
or to add the values and compare the sum total with some predefined limit. If
TxData is compared to a value, it is treated as a node set comparison where each
TxData value is compared to the data in turn with success being indicated if any of
the TxData values equal the target data. Node set comparisons have slightly
different behavior than expected when using the != operator. In most cases, use the
not() function instead. For information about when to use != and not() when
comparing a node set, see “Example: ADI from dynamic ADI retrieval services” on
page 132.
XML entitlement example
The following example is an ADI XML document that might be passed to the XSL
processor from the rules evaluator during the evaluation of an authorization rule.
The document contains two containers: JohnSmith and AmountReqd. The attribute
value of the container JohnSmith is defined in XML. The AmountReqd container is
translated to XML from an incoming string application context attribute. The
container JohnSmith is an entitlement and the container AmountReqd is an item of
transaction context.
Chapter 10. Authorization rules management
125
The authorization rules evaluator automatically encompasses all the data under the
XML top-level node declaration XMLADI when the ADI XML document is created, so
this top-level element was added for clarity.
The XML document that is passed to the evaluation routines by the authorization
rules evaluator is as follows:
<XMLADI>
<JohnSmith>
<CreditCard>
<AcctNumber>0123456776543210</AcctNumber>
<Limit>10000.00</Limit>
<Balance>2000.00</Balance>
</CreditCard>
<MileagePlus>
<MemberStatus>100k</MemberStatus>
<CardNumber>12345678</CardNumber>
<MileagePlus>
<JohnSmith>
<AmountReqd>500.00</AmountReqd>
</XMLADI>
When referencing a particular ADI item within the XMLADI document available to
a rule, the XPath path specifier can begin from the container name of the XML
element, for example, JohnSmith, as the default template rule matches the /XMLADI
element automatically. If the callers want to specify their own template match
statement explicitly, they can do so.
In this example, the ADI container names are JohnSmith and AmountReqd. For
additional information, see “Format and constraints of rules” on page 129.
Defining an XML namespace
XML namespaces are used to differentiate between XML items with the same name
or are used to group XML data of the same type or function. The same principles
can be used with ADI that is defined for use with authorization rules. For example,
a customer database and a product inventory database might both define ADI
called name that could be used in authorization rules. By defining an XML
namespace with the namespace ID item, you can differentiate between the two
instances of name by calling the ADI from the product database item:name. This
example provides a namespace definition for the item namespace:
xmlns:item="http://mycompany/namespaces/items
where xmlns is a standard XML attribute name and item is the namespace ID
chosen for the namespace. The URI following the = is used to distinguish one
namespace ID from another.
This namespace declaration associates the namespace ID item with the URI string:
http://mycompany/namespaces/items
The value of the URI string is of no consequence to the XML and XSL processors
but it must be unique. Unlike the XML and XSL processors, the Tivoli Access
Manager authorization engine does not permit two namespace IDs to be assigned
the same URI value. The Tivoli Access Manager authorization engine uses the URI
to uniquely identify the namespaces. Defining two namespaces with the same URI
results in an initialization error. The authorization application cannot start, and an
error is logged to the error log of the application. The source from which the item
name is to be obtained must be aware of this relationship. The source must be able
to make the connection between the item:name requested by the authorization
126
Administration Guide
engine and the name data stored in the product database. The source must also be
able to provide this data to the authorization engine in an attribute called
item:name when it is needed. For example, a dynamic ADI retrieval service must
understand that, when it is asked for item:name, it must fetch the required value
by looking for name in the product database. The service needs to return the data
to the authorization engine in an attribute called item:name. When an application
uses namespaces to differentiate or aggregate ADI items, it is required to define the
namespace for both the XML and XSL processors.
To define a namespace for the XSL processor, add the namespace definition to the
xsl-stylesheet-prolog configuration file entry discussed in “input-adi-xml-prolog
and xsl-stylesheet-prolog” on page 136. This is an example of how to add a
namespace definition for the item namespace to the xsl-stylesheet-prolog entry:
xsl-stylesheet-prolog = <?xml version=’1.0’ encoding=’UTF-8’?>
<xsl:stylesheet xmlns:xsl=’http://www.w3.org/1999/XSL/Transform’
xmlns:item="http://mycompany/namespaces/items" version=’1.0’>
<xsl:output method = ’text’ omit-xml-declaration=’yes’
encoding=’UTF-8’ indent=’no’/>
<xsl:template match=’text()’>
</xsl:template>
There are two ways to define a namespace prefix to the XML processor:
v Define the namespace globally for the entire XMLADI document.
v Define it individually within those ADI items that use the prefix.
In both cases, the namespace declaration must be included in the start tag for the
XML element.
The first and simplest method of defining a namespace for the XML processor is to
add the namespace definition to the XMLADI document element start tag. Adding
the definition to the XMLADI document element start tag is easiest to do because
it automatically defines the namespace for the entire document. Therefore, any ADI
items in the document whose names are prefixed with this namespace ID do not
have to have the namespace definition added to their own element start tag. This
method does not suffer any of the drawbacks of defining the namespace by using
the second method. The [xmladi-attribute-definitions] stanza was added to the
configuration file to allow customers to define namespaces globally for use within
the XMLADI document. For information about how to add a namespace definition
to the [xmladi-attribute-definitions] stanza, refer to
“[xmladi-attribute-definitions]” on page 137.
The second method of specifying an XML namespace definition to the XML
processor is to add the definition to the XML value of the ADI element. For
example, to add the XML namespace definition to the item:name XML item with a
string value of Widget A, you would define item:name in XML as follows:
<item:name xmlns:item="http://mycompany/namespaces/items">
Widget A
</item:name>
The ADI item:name must be added to an attribute list with the item:name attribute
name and its value is the entire XML element definition in the example entered as
a single contiguous text string. There are some drawbacks to defining the XML
namespace within the XML definition of each ADI item rather than defining it
globally for the entire XMLADI document. For instance, the value of any ADI
items that use a namespace ID prefix must be in XML because the namespace
definition can only be added to the XML definition of the value of the item, as
Chapter 10. Authorization rules management
127
demonstrated for item:name in the example. As a result, items of ADI with
namespace prefixes cannot simply have the value 100. The value of the item must
be an XML fragment, such as the string <prefix:adi_name>100</prefix:adi_name>.
Also, any ADI source that can provide values for namespace prefixed ADI items
would need to ensure that the appropriate namespace definitions for the item are
added to each XML formatted value that it returns. When the service does not
normally return XML formatted data and is not aware of namespace prefixes, it
must be changed so that it does, which translates to increased processing overhead
for dynamic ADI retrieval services. By defining the namespace globally, all these
complications can be avoided. If a namespace has not been defined for either the
XML or XSL processors, an error is logged to the application error logs to the effect
that the namespace ID does not have an associated URI mapping. This problem
might occur during the creation of the rule if the XSL processor has not been
notified of the new namespace, or during rule evaluation if the XML processor has
not been notified.
Authorization rules evaluator
The authorization rules evaluator evaluates authorization rules within the
constraints that are required by the authorization engine.
The authorization rules evaluator takes the rule policy that is attached to the target
protected object and evaluates the rule by calling the XSL processor. The input
XML document for the transformation contains a definition for how the
authorization engine can retrieve one of the following sources for the ADI:
v User credential entitlements that is requesting the authorization
v Application context information that is passed in by the access decision call
(passed in by the resource manager)
v Tivoli Access Manager authorization engine context
v Dynamic ADI retrieval entitlement services
The authorization engine expects the rules evaluation to result in the return of one
of the string identifiers as shown in Table 5. These identifiers ensure uniqueness
when an XSL rule is written incorrectly and the evaluation returns incorrect
information. Delimiting the identifiers with an exclamation point (!) enables the
evaluator to identify errant cases.
Table 5. String identifiers returned by rules evaluation
Delimiter
Meaning
!TRUE!
Access is permitted.
!FALSE!
Access is denied.
!INDIFFERENT!
The rules engine has no opinion.
The identifiers must be the only text in the output document; although they can be
surrounded by white space. If a value other than the defined valid values or an
empty document is returned, the access decision fails and an error code is returned
to the resource manager to indicate that the rule is not compliant. The format of an
authorization rule is outlined in “Format and constraints of rules” on page 129.
In addition, the maximum length of any result text that is returned by a rule
evaluation is limited to 1023 characters. Rules returning more text than this limit
causes the access decision to fail at runtime with a minor error code of
ivacl_s_rule_result_string_too_large.
128
Administration Guide
Format and constraints of rules
An authorization rule must be defined as an XSL template in an XSL stylesheet
using the stylesheet prolog that is specified in the configuration file. The rule must
be written in a valid XSL template rule format and must return a text document
that contains one of the following string identifiers:
v !TRUE!
v !FALSE!
v !INDIFFERENT!
The identifiers must be the only text in the output document but they can be
surrounded by white space. The identifiers are not case-sensitive. If a value other
than one of the identifiers listed or an empty document is returned, the access
decision fails and an error code is returned to the resource manager indicating that
the rule is not compliant. For more information about string identifiers, see
“Authorization rules evaluator” on page 128.
For authorization decisions, the rule must return the expected decision data to the
rules evaluator. The data that is returned from the rules-driven entitlements
interface must be able to be expressed as a text name-value attribute pair in the
entitlements output parameter of the azn_entitlement_get_entitlements()
method. Many data providers return entitlements data in XML format; thus, no
additional transformation is required to pass these entitlements into the rules
evaluator as ADI.
All ADI that is passed to the rules evaluator must be specified in XML. Non-XML
ADI that is passed to the access decision or retrieved from the credential is
formatted into XML by the evaluator before an authorization rule can be evaluated.
The result of the XSL transformation performed by an XSL authorization rule must
be a text output document that contains only one of the supported string
identifiers.
The following example references the XML data item that is defined in JohnSmith.
The condition that the following example rule evaluates is expressed, as follows:
if ((AmountReqd + Credit Card Balance) < Credit Card Limit
&& MileagePlus Status is "100k")
The corresponding authorization rule is:
<xsl:if test="(AmountReqd + JohnSmith/CreditCard/Balance)
&lt; JohnSmith/CreditCard/Limit
and JohnSmith/MileagePlus/MemberStatus = ’100k’">
!TRUE!
</xsl:if>
This example rule is the simplest form for specifying an authorization rule. It does
not include its own template match statement and it accepts the default template
match statement, which is set to /XMLADI. Template match statements are an XSL
language construct that is used to select the point in the hierarchy of an XML
document at which the XSL rules, which are contained within the template match
statement, are applied. The default template match statement of the ADI XML
model matches from the top of the XMLADI document by specifying the XPath
/XMLADI.
To add your own template match statement to a rule definition, only two
additional lines are needed. For example, to rewrite the example to include your
Chapter 10. Authorization rules management
129
own explicit template match statement that matches from the root of the XMLADI
document, you would modify the rule as follows:
<xsl:template match="/XMLADI">
<xsl:if test="(AmountReqd + JohnSmith/CreditCard/Balance)
&lt; JohnSmith/CreditCard/Limit
and JohnSmith/MileagePlus/MemberStatus = ’100k’)
!TRUE!
</xsl:if>
</xsl:template>
To reference any data item in the document, the XPath to each node must include
the XMLADI node. For example, to access the credit card balance, the full path
would be /XMLADI/JohnSmith/CreditCard/Balance. When a rule is built, the rule
writer must understand what the correct XPath, used to access the XML data
nodes and subnodes, is from the current point in the tree. The current point in the
tree is selected by using the template match statement. The template match
statement allows an XSL programmer to shorten the XPath to each data element by
specifying that the XPath processing occur further down the XML document tree.
The <xsl:template match="/XMLADI"> statement tells the XSL processor that all
relative XPaths within the bounds of the template statement must be assumed to
be relative to the node XMLADI. To shorten the XPaths even further, the template
match statement could be set at /XMLADI/JohnSmith in which case, the credit card
balance could be referred to as CreditCard/Balance.
Policy administrators must also make the following assumptions about the XSL
stylesheet document that is created by the rules evaluator to contain the rule that
they devise:
v If a stylesheet prolog is specified in the azn client configuration file, that prolog
is imported into the empty stylesheet. If no prolog is specified, the following
default prolog is used instead:
<!-- Required for XSLT language -->
<?xml version="1.0" encoding=’UTF-8’?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<!-- Required to constrain output of rule evaluation -->
<xsl:output method="text" omit-xml-declaration="yes"
encoding=’UTF=8’ indent="no"/>
<!-- Need this to ensure default text node printing is off -->
<xsl:template match="text()"></xsl:template>
v Among other things, this prolog sets the XSL stylesheet syntax to version 1.0,
which is supported by the embedded XSL processor. The prolog sets the
namespace for XSL documents to xsl, which requires that all XSL
language-specific identities be prefixed by xsl:. This prefix is the standard mode
of operation for XSL stylesheets. Most attributes in this prolog must be in the
stylesheet or, if not, the results that are returned from the rules evaluator do not
conform to the expected results.
v All authorization rules must be enclosed in an xsl:template match statement. If
the rule is defined with its own xsl:template match statement, the rule is
accepted as is. This acceptance allows the rule creator to specify the level within
the ADI XML document at which the rule matches data items. But in this case,
the match statement must be the first statement encountered by the evaluator
when validating the rule or it is assumed that there is no template match
statement. If there is a match statement but the match statement does not begin
with the /XMLADI absolute path, the rule is returned as invalid. Relative match
statements are not accepted at this level.
130
Administration Guide
v If no match statement is specified in the rule, the rule is automatically enclosed
in the following match statement:
<xsl:template match="/XMLADI">
...
<xsl:template>
v Therefore, all rules devised without an explicit template match statement must
use XPath expressions that assume the XML context node is /XMLADI. The XPath
expression for any ADI item must begin with the container name of the item
and must be fully qualified.
Examples of authorization rules
Following are example rules that demonstrate how rules can be implemented.
v “Example: ADI from resource manager”
v “Example: ADI from entitlement data”
v “Example: ADI from dynamic ADI retrieval services” on page 132
Example: ADI from resource manager
The following example relies mostly on ADI that is passed in to the access decision
call but it also requires an ADI container called printQuota to be stored in the
requesting user credential or passed in as application context. The access decision
logic defined by this rule is to permit access only when one of the following
conditions is true:
v The user is in the printUsers group
v The user has requested a print operation (p)
v The user has requested to queue a print job for printing later (q) and the print
quota is less than 20
<xsl:if test=’azn_cred_groups = "cn=printUsers,o=ibm,c=us"
and (contains(azn_engine_requested_actions,"p")
or contains(azn_engine_requested_actions,"q"))
and printQuota &lt;20’>
!TRUE!
</xsl:if>
The test condition for the group name returns an appropriate result regardless of
the number of groups that the requesting user is in. The condition is an XSL node
test that compares each value within the XML element azn_cred_groups with the
DN string. It is important to note that the syntax for determining the opposite case
(for example, that the requesting user is not in the printUsers group) requires a
slightly different expression, because it is a node test. See “Example: ADI from
entitlement data” for an example of how to test for whether a set of values like the
azn_cred_group_names attribute does not contain a certain member.
Example: ADI from entitlement data
In the following example, the rule works on data that is within the authorization
credential. It evaluates the following attributes:
v azn_cred_principal_name
v azn_cred_groups
v azn_cred_registry_id
Each of the xsl:when statements are evaluated. The first statement with conditions
that are all true returns a result. Each condition tested has a comment that explains
its action.
<!-- Example choose rule -->
<xsl:choose>
<!-- Explicitly allow if the requesting user is myuser0 -->
Chapter 10. Authorization rules management
131
<xsl:when test="azn_cred_principal_name = ’myuser0’">
!TRUE!
</xsl:when>
<!-- Explicitly deny if the requesting user is myuser1 -->
<xsl:when test="azn_cred_principal_name = ’myuser1’">
!FALSE!
</xsl:when>
<!-- Explicitly allow if the requesting user’s LDAP DN
<!-- is the same as that specified
-->
-->
<xsl:when test="azn_cred_registry_id = ’cn=myuser3,secAuthority=Default’">
!TRUE!
</xsl:when>
<!-- This rule permits access to any user who is a member of mygroup1 -->
<!-- but is not a member of mygroup2
-->
<xsl:when test="azn_cred_groups = ’mygroup1’
and not (azn_cred_groups = ’mygroup2’)">
!TRUE!
</xsl:when>
<xsl:otherwise>
!FALSE!
<xsl:otherwise>
</xsl:choose>
The fourth xsl:when statement uses the not() function to negate the Boolean result
of the following test:
azn_cred_groups = ’mygroup2’
The not() function is used instead of the valid authorization rule operator !=
operator because, in this case, the azn_cred_groups attribute is a multi-valued
attribute. Multi-valued attributes like azn_cred_groups return a set of values,
referred to as a node-set in XSL, to be tested by the condition. Each node value in
the set is tested against the condition individually and !TRUE! is returned if any of
the conditions evaluate to true. In any case, where the user is in more than one
group, other than mygroup2, the result of the node test is always !TRUE!. To test the
nonexistence of something in a node-set, use the not() function instead of the !=
operator. For example, you can test that the condition group is mygroup2 is not
true.
Example: ADI from dynamic ADI retrieval services
The following example evaluates an application-defined XML input document that
is provided by a dynamic entitlement service that was written using the dynamic
ADI retrieval service. The code that must be written might create a batch object
that contains a list of operations that are to be performed together. The batch object
consists of a number of transaction elements. Each transaction consists of an item
and the amount of those items to order.
With these assumptions, the following XML object could be used as input for
making the authorization decision:
<!-- batched transaction -->
<batch>
<max_tx_count>5</max_tx_count>
<max_tx_amount>150</max_tx_amount>
<account>customerA</account>
<transaction>
<item>widgetA</item>
132
Administration Guide
<amount>10</amount>
</transaction>
<transaction>
<item>widgetB</item>
<amount>20</amount>
</transaction>
<transaction>
<item>widgetC</item>
<amount>30</amount>
</transaction>
<transaction>
<item>widgetD</item>
<amount>40</amount>
</transaction>
<transaction>
<item>widgetE</item>
<amount>50</amount>
</transaction>
</batch>
With this expected XML object, you could create the following authorization rule:
<!--Compare group to batch customer and num tranactions
and total tx amounts to limits.-->
<xsl:if test="azn_cred_groups = batch/account
and count (batch/transaction) &lt;= batch/max_tx_count
and sum (batch/transaction/amount) &lt;= batch/max_tx_amount">
!TRUE!
</xsl:if>
The authorization rule checks that the requesting user is a member of a group
whose name matches the name of the account in the transaction (in this example, it
is customerA). If the requesting user is not a member of this group, the user is not
authorized to submit batch requests on behalf of customerA. Then, the rule checks
that the total number of transactions within the batch is less than or equal to the
max_tx_count element of the batch object and that the total number of items
ordered in the entire request is less than the max_tx_amount element of the batch
object. The rule calls the count() and sum() functions. The count() function counts
the number of instances of a transaction element within the batch. The sum()
function totals the value of all the amount elements within all transaction elements
in the batch.
For additional information of creating authorization rules, see the IBM Tivoli Access
Manager for e-business: Authorization C API Developer Reference.
Methods of providing ADI to the rules evaluator
A resource manager application can provide ADI from the resource manager to the
rules evaluator in one of the following ways:
v Adding the attributes to the application context parameter
v Configuring the rules evaluator to supply the missing ADI to the authorization
engine only when it is explicitly requested
The first method is to provide the ADI by adding the attributes to the application
context parameter passed to the azn_decision_access_allowed_ext() method. The
problem with this method is that the resource manager must either know which
ADI is going to be needed by a particular access decision. Alternatively, you can
provide all the ADI for all known rules to the authorization engine for every access
decision call regardless of whether a rule is involved in the decision.
Chapter 10. Authorization rules management
133
The first method might be acceptable and even desirable for a smaller set of ADI.
However, for a larger and more varied set of possible ADI, a second method is
needed. You can configure the resource manager to supply the missing ADI to the
authorization engine only when it is explicitly requested. With this method, the
authorization engine can be configured with a set of ADI prefixes that can be
provided by the resource manager upon request. The authorization engine fails the
access decision and notifies the resource manager of the ADI it needs in a
permission information attribute returned by the
azn_decision_access_allowed_ext() method. The attribute contains a list of the
ADI that is needed to successfully evaluate the rule. The ADI was not found in the
application context that was passed in and did not have a prefix matching those
that the resource manager identified as its own.
The permission information attribute is named azn_perminfo_rules_adi_request
and contains a text attribute value for each item of ADI required. The resource
manager looks for this attribute when the access decision fails, and when it is
present, scans the list of ADI names in the attribute and gathers the requested data
to try the access decision with this additional data again. If the requested data
cannot be provided, the resource manager must deny access and log the problem
as a failure due to insufficient rules data. The requested list contains only the ADI
items that are identified as being provided by the resource manager. The unique
prefix added to the attribute name is used to identify the ADI. All resource
managers that provide data to the evaluation process in this manner must define a
unique prefix by which their ADI data set can be identified.
Permission information is returned to a resource manager application only when
the authorization client was configured that way. To activate the return of the
azn_perminfo_rules_adi_request permission information attribute, the name of
this attribute must either be added to the azn_init_set_perminfo_attrs
initialization attribute or the equivalent permission-info-returned entry in the
[aznapi-configuration] stanza.
The ADI prefixes that are recognized by the resource manager can be configured
using the resource-manager-provided-adi entry or the
azn_init_resource_mgr_provided_adi initialization attribute. For more information
about the configuration entry, see “resource-manager-provided-adi” on page 136.
For more information about the initialization attribute, see the IBM Tivoli Access
Manager for e-business: Authorization C API Developer Reference.
The authorization engine attempts to anticipate the need to request information
from the resource manager by obtaining the rule policy object on the protected
object early in the access decision process. The authorization engine then compares
the required ADI in the rule with the ADI names in the application context
parameter that is passed by the resource manager. The ADI names, which are
missing from the application context and which are specific to the resource
manager, are added to the returned permission information object.
ADI prefixes must be unique to identify them as resource manager ADI and to
avoid conflict with ADI provided in the credential from the authorization engine or
from an external data provider.
134
Administration Guide
Reason codes for rule failures
When this mode of operation is selected, the authorization engine processes all
policies for the access decision as normal. If the rule evaluation fails, the engine
returns access denied with a reason code in the azn_perminfo_reason_rule_failed
permission information attribute list.
This feature allows the target application to fail or permit the access request based
on the rule failure reason code it is given by the resource manager. When access is
denied, the application must check the permission_info attribute list returned from
the access decision call to determine if a rule failure reason code was returned
from the access decision. The resource manager does not need to check for the
attribute on a successful access decision call. The Tivoli Access Manager for
e-business application is an example of an aznAPI resource manager that can make
use of the rule failure reason code. When configured, Tivoli Access Manager for
e-business forwards the reason code to the protected Web application. The
protected Web application must be mounted through a secure junction to have
access to the reason code defined for the authorization rule. The use of rule failure
reason codes in Tivoli Access Manager for e-business is limited to the protected
object space of junctioned Web applications.
The attribute value (the reason code) of the azn_perminfo_reason_rule_failed
attribute is a single string whose value is determined and defined by the policy
administrator and is set in the rule policy object when it is first created. The only
constraint on the value of the reason code is that the value must be a string.
The following conditions must be met before a rule failure reason code is returned
to the caller:
v The reason code is returned only when the access request is denied and the rule
policy evaluation denies access, but not for every case in which access is denied.
The reason code is not returned when the rule evaluation succeeds. The rule
failure reason code is not returned if the rule failed due to a rule syntax error or
if there was insufficient ADI to perform the rule evaluation. In the latter cases,
the authorization decision is failed with an error status.
v There must be a reason code set in the attached rule policy object. This value is
set in the rule policy using the admin API or the pdadmin utility.
v The aznAPI application must be enabled to return the rule failure reason as
permission information. To perform this action, either the
azn_init_set_perminfo_attrs initialization parameter or the equivalent
configuration file entry in the [aznapi-configuration] stanza (stanza entry
permission-info-returned) must include the attribute name
azn_perminfo_reason_rule_failed. This feature enables the attribute to be
returned by the authorization engine in the permission information output
parameter (perminfo) of azn_decision_access_allowed_ext(). For more
information about permission information attributes and how to configure the
authorization engine to return them, refer to the IBM Tivoli Access Manager for
e-business: Authorization C API Developer Reference.
Configuration file and initialization attributes
A number of configuration file entries and initialization attributes are available to
control aspects of the initialization of the rules evaluator within the authorization
engine. The configuration entries are in the configuration file of the resource
manager. An example of this aznAPI.conf configuration file is provided in the
example/authzn_demo/cpp directory of the Tivoli Access Manager Application
Developer Kit (ADK) package. Configuration files are also used by Tivoli Access
Chapter 10. Authorization rules management
135
Manager resource management applications, such as Tivoli Access Manager for
e-business, and these configuration entries can be added to the configuration file of
these applications. Refer to the documentation for the specific Tivoli Access
Manager application for more information about the application configuration file.
Initialization attributes are the programmatic equivalent of configuration attributes
and are intended to be used to develop a custom resource manager application.
For more information about the authorization-rule-specific initialization attributes
and the process of developing a custom resource manager aznAPI application, see
the IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference.
resource-manager-provided-adi
The resource-manager-provided-adi configuration stanza entry defines the prefixes
that the authorization engine uses to determine the set of missing ADI that is
provided by the resource manager. This entry uses a string prefix as its value. To
specify more than one prefix you must add multiple stanza entries as in the
following examples:
resource-manager-provided-adi = sales_customer_
resource-manager-provided-adi = sales_item_
These examples notify the authorization engine that any ADI it requires that begins
with sales_customer_ or sales_item_ be provided by the resource manager
application. ADI items named sales_customer_name, sales_customer_address,
sales_item_count, and sales_item_price are examples of ADI that the
authorization engine would request from the resource manager.
dynamic-adi-entitlement-services
The dynamic-adi-entitlement-services configuration entry lists the service IDs of
the dynamic ADI retrieval entitlement services that must be called by the
authorization engine if ADI is missing from the requesting user credential or from
the application context, and cannot be gathered from the resource manager. Any
entitlement service configured under this entry is called by the authorization
engine using the azn_entitlement_get_entitlements() interface and is passed the
azn_perminfo_rules_adi_request attribute. The string values of this attribute are
the container names of the ADI that are still required. If the dynamic ADI retrieval
service can fulfill the request, it returns the requested data to the authorization
engine in the entitlements parameter. Examples of entitlement services that can be
used in this manner are the Cred Attributes Entitlement Service and the
Entitlement Service Demo, both of which are provided with Tivoli Access Manager.
For more information about configuring and using entitlement services, see the
IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference.
To specify that the authorization engine must call multiple dynamic ADI retrieval
services, you must specify multiple entries. The following examples demonstrate
how to specify the service IDs of two different entitlement services for use as
dynamic ADI entitlement services. The service IDs must correspond to valid
entitlement service definitions in the [aznapi-entitlement-service] stanza.
dynamic-adi-entitlement-services = ent_cred_attrs_id
dynamic-adi-entitlement-services = ent_svc_demo_id
input-adi-xml-prolog and xsl-stylesheet-prolog
The input-adi-xml-prolog and xsl-stylesheet-prolog configuration entries were
defined to allow augmentation of the XML and XSL prolog statements that are
136
Administration Guide
appended to the ADI XML document and authorization rule stylesheet before they
are passed to the rules evaluator for processing. The format and defaults for each
of these entries are:
input-adi-xml-prolog=<?xml version="1.0" encoding="UTF-8"?>
and
xsl-stylesheet-prolog=<?xml version="1.0" encoding=’UTF-8’?>
<xsl:stylesheet xmlns:xsl=’http://www.w3.org/1999/XSL/Transform’ version=’1.0’>
<xsl:output method = ’text’omit-xml-declaration=’yes’ encoding=’UTF-8’indent=’no’/>
<xsl:template match=’text()’>
</xsl:template>
Due to the constraints imposed by the authorization rule model, there are a
number of prolog attributes that are required by the authorization engine (all of
which are specified in the default prolog entries.) If any of these attributes are
changed or omitted from the entry, the authorization client fails to start and
returns an error.
Note: Ensure that you are familiar with the Xalan XSL processor, the Xerces XML
processor, and the use of prolog statements before any attempt is made to
change these entries from the defaults provided.
[xmladi-attribute-definitions]
The [xmladi-attribute-definitions] stanza enables customers to add XML
attribute definitions, such as XML namespace definitions, to the XMLADI
document start tag. For example, when an application wants to use namespaces to
differentiate or aggregate ADI items, as discussed in “Defining an XML
namespace” on page 126, the XML processor must be notified of the namespace by
using an XML namespace definition. The namespace definition can be added to
this stanza, and it is automatically added to the XMLADI document element start
tag. The benefit of adding definitions to the XMLADI document start tag is that
the attribute definitions are available for all ADI items that are defined in the
XMLADI document, whether their values were retrieved from the credential,
generated by the authorization engine or retrieved by a dynamic ADI entitlement
service. For example:
[xmladi-attribute-definitions]
xmlns:myNS = "http://myURI.mycompany.com"
appID = ’"Jupiter" - Account Management Web Portal Server #1.’
The XMLADI element start tag that results from these definitions is:
<XMLADI xmlns:myNS="http://myURI.mycompany.com"
appID=’"Jupiter" - Account Management Web Portal Server #1.’>
Both the namespace ID myNS and the attribute appID are defined globally in the
XMLADI document.
Managing authorization rules
You can perform the following authorization rule tasks:
v “Creating an authorization rule” on page 138
v “Modifying an authorization rule” on page 139
v “Listing authorization rules” on page 140
v “Cloning an authorization rule” on page 140
v “Importing authorization rules” on page 140
Chapter 10. Authorization rules management
137
v
v
v
v
v
“Exporting all authorization rules” on page 141
“Exporting a single authorization rule” on page 141
“Exporting multiple authorization rules” on page 141
“Attaching an authorization rule to a protected object” on page 142
“Detaching an authorization rule” on page 143
v “Locating where an authorization rule is attached” on page 143
v “Deleting an authorization rule” on page 144
In the following sections, instructions are provided for using either Web Portal
Manager or the pdadmin utility, or both. For online help while using Web Portal
Manager, click the question mark to open a separate help window for the current
page.
Notes:
1. There are no equivalent pdadmin commands for importing, exporting, or
cloning authorization rules.
2. When providing rule text with the pdadmin utility, enclose the rule text in
double quotation marks ("). Double quotation marks embedded within the rule
text must be escaped with a backward slash (\) so that they are ignored by the
pdadmin utility. The XSL processor treats single and double quotation marks
equally for defining text strings so they can be used interchangeably, but they
must always be paired appropriately. For example:
pdadmin sec_master> authzrule create testrule1
"<xsl:if test=’some_piece_of_ADI =\"any string\"’>!TRUE!</xsl:if>"
Creating an authorization rule
You can create an authorization rule using Web Portal Manager or the pdadmin
utility.
Web Portal Manager
To
1.
2.
3.
create an authorization rule, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click AuthzRule → Create AuthzRule to display the Create AuthzRule page.
Type the AuthzRule Name for the authorization rule that you want to create
(for example, r2).
Note: Do not use the following characters in the name of a rule:
! " # & ( ) * + , ; : < > = @ \ |
4. In the Description field, type a description of the authorization rule. For
example, type the following text:
time-of-day rule for engineering object space
5. In the AuthzRule Text field, type the text of the rule policy. For example, type
the following information:
<xsl:template match="/XMLADI">
<xsl:if test="(AmountReqd +JohnSmith/CreditCard/Balance)
<JohnSmith/CreditCard/Limit
and JohnSmith?mileagePlus/MemberStatus=’100k’>
!TRUE!
</xsl:if>
</xsl:template>
6. In the Fail Reason field, type the text that you want to be returned to the
resource manager if the rule denies access to a protected object. For example,
type error.
138
Administration Guide
7. Click Create. If successful, the new rule is displayed as a link on the Manage
AuthzRules page. If you select the authorization rule link, the properties of that
rule are displayed.
pdadmin
To create an authorization rule using the pdadmin utility, log in to the domain as a
domain administrator and use the authzrule create command. For example, to
create a rule named r2 with a rule file named engineering.xsl that implements
the time-of-day rule for the engineering object space and returns a fail reason code
of error, enter the following command on a single line:
pdadmin sec_master> authzrule create r2 -rulefile engineering.xsl
-desc "time-of-day rule for engineering object space"
-failreason error
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Modifying an authorization rule
You can modify an authorization rule using Web Portal Manager or the pdadmin
utility.
Web Portal Manager
To modify an authorization rule, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule to display the Manage AuthzRules page.
A list of authorization rules that were created in Tivoli Access Manager are
displayed. Each rule is a link that displays properties for that rule when
selected.
3. Click the authorization rule link for the rule that you want to change. The
AuthzRule Properties page is displayed.
4. As needed, change the following information:
v The description
v The authorization rule text
v The fail reason
For example, if no description currently exists, add a description. If a
description currently exists, change the authorization rule description by typing
the new description in the Description field (for example, adding the words
updated June 23 2003):
updated June 23 2003 time-of-day rule for engineering object space
5. Click Apply for the changes to take effect.
pdadmin
To modify an authorization rule in the domain using the pdadmin utility, log in to
the domain as a domain administrator and use the authzrule modify command.
For example, to change the rule named r2 to return a fail reason code of warning,
enter the following command:
pdadmin sec_master> authzrule modify r2 failreason warning
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Chapter 10. Authorization rules management
139
Listing authorization rules
You can list the authorization rules that were created using Web Portal Manager or
the pdadmin utility.
Web Portal Manager
To list all existing authorization rules, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule to display the Manage AuthzRules page.
A list of names for authorization rules that were created in Tivoli Access
Manager are displayed as links. If you select an authorization rule link, the
properties of that rule are displayed.
pdadmin
To list authorization rules in the domain using the pdadmin utility, log in to the
domain as a domain administrator and use the authzrule list command.
pdadmin sec_master> authzrule list
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Cloning an authorization rule
You can clone an authorization rule using Web Portal Manager only.
Web Portal Manager
To clone an authorization rule in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule.
3. From the Manage AuthzRules page, select the authorization rule you want to
clone.
4. From the AuthzRule Properties page, click Clone.
5. From the Clone AuthzRule page, type an AuthzRule Name For example, type
Test-AuthzRule. The default value is the name of the original authorization rule
with the prefix Clone. This field is required.
6. Optional: Type a Description of the authorization rule. For example, type Clone
of new authorization rule. The default value is the description of the original
authorization rule.
7. Click Clone. If successful, a link for this cloned authorization rule is created
and a success message is displayed.
Importing authorization rules
You can import an authorization rule by using Web Portal Manager only.
Web Portal Manager
To import an authorization rule in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → Import AuthzRule.
3. From the Import AuthzRule page, complete one of the following steps:
v In the AuthzRule File Name field, type the name of the authorization rule to
import. For example, type ruleImport.xml.
v Click Browse to select a file name.
140
Administration Guide
4. If the file containing the authorization rule was encrypted when it was
exported, in the Encryption String text field, type the string that was used to
encrypt the XML file.
5. Click Import.
If successful, the imported rule is available when you list all the rules.
Exporting all authorization rules
You can export all authorization rules by using Web Portal Manager only.
Web Portal Manager
To export all authorization rules in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → Export All AuthzRules to display the Export AuthzRule to
File page.
3. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
4. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
5. Click Export to display the File Download window.
6. Click Save to display the Save As window.
7. Click Save to create the file that contains the exported rule descriptions. The
default file name is ruleExport.xml.
If successful, the exported rule descriptions are available in the specified location.
Exporting a single authorization rule
You can export a single authorization rule using Web Portal Manager only.
Web Portal Manager
To export a single authorization rule in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule.
3. From the Manage AuthzRules page, select the authorization rule that you want
to export.
4. From the AuthzRule Properties page, click Export to display the Export
AuthzRule to File page.
5. Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
6. When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
7. Click Export to display the File Download window.
8. Click Save to display the Save As window.
9. Click Save to create the file that contains the exported authorization rule
description. The default file name is ruleExport.xml.
If successful, the exported rule description is available in the specified location.
Exporting multiple authorization rules
You can export multiple authorization rules using Web Portal Manager only.
Chapter 10. Authorization rules management
141
Web Portal Manager
To
1.
2.
3.
4.
5.
6.
7.
8.
9.
export authorization rules in the domain, complete the following steps:
Use Web Portal Manager to log in to the domain as a domain administrator.
Click AuthzRule → List AuthzRule.
From the Manage AuthzRules page, select the authorization rule that you want
to export.
Click Export to display the Export AuthzRule to File page.
Optional: In the Encryption String text field, type the string to use to encrypt
the XML file. If not specified, the exported file is in plain text.
When an encryption string is provided, in the Confirm Encryption String text
field, type the string again.
Click Export to display the File Download window.
Click Save to display the Save As window.
Click Save to create the file that contains the exported authorization rule
descriptions. The default file name is ruleExport.xml.
If successful, the new XML file is available in the specified location.
Attaching an authorization rule to a protected object
You can attach an authorization rule to a protected object using Web Portal
Manager or the pdadmin utility.
Web Portal Manager
To attach a rule to a protected object, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule to display the Manage AuthzRules page.
A list of authorization rules that were created in Tivoli Access Manager are
displayed. Each rule is a link that displays properties for that rule when
selected.
3. Click the link for the authorization rule that you want to attach to an object.
For example, the r2 authorization rule. The AuthzRule Properties page is
displayed.
4. Click the Attach tab to view a list of protected objects to which the
authorization rule is already attached, if any.
5. Click Attach to display the Attach AuthzRule page.
6. Type the Protected Object Path of the protected object to which you want to
attach the authorization rule. This field is required. Be sure to type the full path
name. For example, type the following path:
/WebSEAL/tivoli.com/w3junction/index.html
7. Click Attach. If successful, the new protected object is added as a link to the
list of objects to which the authorization rule is attached on the AuthzRule
Properties–Attach page.
pdadmin
To attach an authorization rule to a protected object using the pdadmin utility, log
in to the domain as a domain administrator and use the authzrule attach
command.
For example, to attach a rule named r2 to a protected object named
/WebSEAL/tivoli.com/w3junction/index.html, enter the following command:
pdadmin sec_master> authzrule attach /WebSEAL/tivoli.com/w3junction/index.html r2
142
Administration Guide
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Detaching an authorization rule
You can detach an authorization rule from a protected object using Web Portal
Manager or the pdadmin utility.
Web Portal Manager
To detach a rule from a protected object, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule to display the Manage AuthzRules page.
A list of authorization rules that were created in Tivoli Access Manager are
displayed. Each rule is a link that displays properties for that rule when
selected.
3. Click the link for the authorization rule that you want to detach from an object.
The AuthzRule Properties page is displayed.
4. Click the Attach tab to view a list of protected objects to which the
authorization rule is already attached, if any.
5. Select one or more check boxes for the protected objects from which you want
to detach the authorization rule.
6. Click Detach to display the Detach AuthzRule from Object page where you are
prompted to confirm or cancel the request.
pdadmin
To detach a rule from a protected object in the domain using the pdadmin utility,
log in to the domain as a domain administrator and use the authzrule detach
command.
For example, to detach a rule from a protected object named /WebSEAL/tivoli.com/
w3junction/index.html, enter the following command:
pdadmin sec_master> authzrule detach /WebSEAL/tivoli.com/w3junction/index.html
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Locating where an authorization rule is attached
You can find the protected objects that have an authorization rule attached using
Web Portal Manager or the pdadmin utility.
Web Portal Manager
To find protected objects that are attached to a rule, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule. A list of authorization names is displayed.
Each authorization rule name is a link that you can click to display the
AuthzRule Properties page.
3. Click the Attach tab.
pdadmin
To find all the protected objects to which an authorization rule is attached in the
domain using the pdadmin utility, log in to the domain as a domain administrator
and use the authzrule find command.
Chapter 10. Authorization rules management
143
For example, to find the protected objects attached to a rule named r2, enter the
following command:
pdadmin sec_master> authzrule find r2
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting an authorization rule
You can delete an authorization rule using Web Portal Manager or the pdadmin
utility.
Web Portal Manager
To delete an authorization rule, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click AuthzRule → List AuthzRule to display the Manage AuthzRules page.
A list of authorization rules that were created in Tivoli Access Manager are
displayed. Each rule is a link that displays properties for that rule when
selected.
3. Select one or more check boxes for the links that you want to delete. For
example, you might select the check box for the authorization rule named r2.
4. Click Delete to display the Delete AuthzRules page where you are prompted to
confirm or cancel the deletion.
pdadmin
To delete an authorization rule in the domain using the pdadmin utility, log in to
the domain as a domain administrator and use the authzrule delete command.
For example, to delete a rule named r2, enter the following command:
pdadmin sec_master> authzrule delete r2
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
144
Administration Guide
Chapter 11. Managing users and groups
An initial domain administrator is created when a new domain is created. The
domain administrator has the necessary privileges to manage the domain. The
domain administrator can create and configure users, groups, resources, and
applications, and can delegate administration tasks within the domain as required.
A user represents any authenticated Tivoli Access Manager identity. Typically, these
authenticated identities represent network users or resource managers.
A group is a collection of one or more users. An administrator can use group ACL
entries to assign the same permissions to multiple users. New users to the domain
gain access to objects by becoming members of groups. Group membership
eliminates the need to create new ACL entries for each new user. Groups can
represent organizational divisions or departments within a domain. Groups are
also useful in defining roles or functional associations.
An account refers to users and groups collectively.
A registry unique identifier (UID) specifies the location in the user registry where
the new user is created. Similarly, a registry group unique identifier (GID) specifies
the location in the user registry where the new group is created. For registry UIDs
and GIDs, you must type the full path name for the new user or group. The path
format depends on the type of registry that the product is using. The following list
shows sample formats for different user registries:
LDAP cn=IBM-Support,o=ibm,c=us
Active Directory
cn=IBM-Support,dc=Austin,dc=US
Domino
cn=IBM-Support,dc=Austin,dc=US
IBM-Support/Austin/US
The registry UID or registry GID provides extra security in the case where a user
or group is deleted from the domain and then recreated with the same name. For
example, even though a new user has the same name as the deleted user, Tivoli
Access Manager allocates a new registry UID to this user. Because the registry UID
is new, any existing ACL entries that refer to the old user name do not grant any
rights to the new user. Stale UIDs from deleted users and groups are silently
removed by the policy server.
Managing users
You can perform the following user tasks:
v “Creating a user” on page 146
v “Listing users” on page 147
v “Changing a password” on page 148
v “Setting user policy” on page 149
v “Setting global user policy” on page 151
v “Importing users” on page 153
v “Deleting a user” on page 154
© Copyright IBM Corp. 1999, 2010
145
In the following sections, instructions are provided for using either Web Portal
Manager or the pdadmin utility, or both. For online help while using Web Portal
Manager, click the question mark to open a separate help window for the current
page.
Creating a user
You can create a user using Web Portal Manager or the pdadmin utility.
When a user is created, the domain administrator assigns a user name, which is
sometimes referred to as a principal name. The user name must be unique within
the domain, because it is used by Tivoli Access Manager to identify this user. A
registry user identifier, known as a distinguished name (DN), is also assigned to
uniquely identify the user definition in the user registry. The format of the DN
depends on the registry type being used. Also assigned are the common name (CN)
and surname (SN) of the user being defined.
Note: When Active Directory Application Mode (ADAM) is used as the user
registry, users must be created within the same ADAM partition in which
Tivoli Access Manager was configured.
Web Portal Manager
To create a user in a domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click User → Create User.
3. In the User Id text field, type the user name (for example maryj).
4. Click Group Membership to search for groups in which the user can be a
member.
5. In the First Name text field, type the name of the user (for example Mary).
6. In the Last Name text field, type the family or surname of the user (for
example Jones).
7. In the Password text field, type the password. Passwords must adhere to the
password policies that are set by the domain administrator.
8. In the Confirm Password text field, type the password again.
9. In the Description text field, type the description for the user (for example,
Member of Marketing Group.
10. In the Registry UID text field, type the registry UID. The registry UID
specifies the location in the user registry where the new user is created. For
example: cn=maryj,o=ibm,c=us,dc=mkt. Lotus Notes® users require the full
path name for the user being created. For example: Mary Jones/IBM/US
11. Select the Account Valid check box to indicate that the new user can
participate in the domain. If this option is not selected, the new user account
is not valid and the user cannot log in.
12. Select the GSO User check box to indicate the use of global sign-on (single
sign-on) for Tivoli Access Manager.
13. Select the Password Valid check box to force a password change the next time
the user logs in to the domain. If this option is not selected, the user is
informed that the password has expired.
14. Click No Password Policy to indicate that you do not want the initial
password to conform to the password policies that are set by the domain
administrator.
15. Click Create.
146
Administration Guide
A message is shown if the user ID is created.
pdadmin
To create a user using the pdadmin utility, log in to the appropriate domain as a
domain administrator and use the user create command to create the user.
For example, to create the user named maryj with global sign-on capability, enter
the following command:
pdadmin sec_master> user create –gsouser maryj "cn=Mary Jones,o=IBM,c=us,dc=mkt" \
"Mary Jones" Jones pwd2pwd2
The format of the distinguished name depends on the type of user registry. For
more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing users
You can search for users using Web Portal Manager or the pdadmin utility.
However, when the user registry contains a large number of user definitions, use
wildcard characters with discretion. When a pattern includes one or more wildcard
characters, the command attempts to find all user definitions that match the
specified pattern, but displays only the specified number of matching definitions in
the user registry. For example if the user registry contains 10,000 definitions,
specifying a single wildcard (“*”), with a limit of 100, finds all 10, 000 definitions
but displays only the first 100 matching definitions.
Note: If a large number of users are defined in the user registry (for example,
more than 100,000), avoid using the global wildcard (*). Instead, use a search
filter that is as specific as possible, or qualify the search pattern to limit the
search results.
For example, if you are using the pdadmin tool and listing users whose
names start with John, limit the search results by specifying the number of
records to return, as in the following command: pdadmin user list john*
100
For the specific syntax of the user list command, see the IBM Tivoli Access
Manager for e-business: Command Reference.
For more specific information about tuning the directory server to achieve best
results, see the IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
Web Portal Manager
To search for and list up to a maximum of 100 users:
1. Use Web Portal Manager to log in to the appropriate domain as a domain
administrator.
2. Click User → Search Users to display the User Search page.
3. At the User Search page, specify the pattern to filter user ID names. Use
wildcard characters with discretion.
4. Use the default value of 100 or type another value in the Maximum Results
field. This number limits the number of user IDs that are displayed.
5. Click Search to display a table of user IDs. Each user ID is displayed as a link.
From the User Search page, you can perform these tasks: create a user, delete
one or more existing users, and click the link to view user properties.
Chapter 11. Managing users and groups
147
6. Use the default value of 15 user IDs per page, or click Options to type the
number of user IDs to view per page. Toggle back by clicking Hide Options.
7. Use the default value of None, meaning that no text is used for filtering, or, click
Filters to find user IDs that contain, start with, or end with the text that you
specify. Toggle back by clicking Hide Filters.
pdadmin
To search for a list of users using the pdadmin utility, log in to the domain as a
domain administrator and use the user list command to list users.
For example, to search for and list up to a maximum of 100 users, enter the
following command:
pdadmin sec_master> user list * 100
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Changing a password
You can change a user password using Web Portal Manager or the pdadmin utility.
The new password must comply with the password policies that are currently in
effect.
Note: When using Active Directory as your user registry and the Active Directory
server is running on Windows 2003 SP1 or later, old passwords might still
be able to be used after a password change.
For additional information, see the following Web page:
http://support.microsoft.com/?id=906305
When setting or changing a password, the password must comply with the
following policies:
v The defined Tivoli Access Manager password policy
v The password policy for the underlying operating system
v The password policy for the underlying user registry
When enforcing the password policy, Tivoli Access Manager validates compliance
in the following sequence:
1. Against the Tivoli Access Manager password policy currently in effect
2. Against the underlying user registry
Although a password complies to the defined Tivoli Access Manager password
policy, validation might fail against the password policy of the underlying
operating system or user registry.
For additional information about setting the password policy for Tivoli Access
Manager users, see“Setting global user policy” on page 151.
Web Portal Manager
To change the password for the specified user ID, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click User → Change My Password.
148
Administration Guide
3. Verify that the User ID identifies the login identifier for the user whose
password you want to change.
4. In the Current Password text field, type the existing password for the specified
user ID.
5. In the New Password text field, type the new password for the specified user
ID.
6. In the Confirm New Password text field, type the password again.
7. Click Apply.
pdadmin
To change the password for the user using the pdadmin utility, log in to the
domain as a domain administrator and use the user modify command with the
password option.
For example, to change the password for the user dlucas to newpasswd, enter the
following command:
pdadmin sec_master> user modify dlucas password newpasswd
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Setting user policy
You can change the user policy settings for specific users, such as password
policies, login-failure policies, access policies, and account expiration policies using
Web Portal Manager or the pdadmin utility.
Note:
v The valid range for numbers can be any number. However, use a
reasonable number for the task that you want to perform. For example, a
minimum password length must be long enough to protect your system
but not so short as to make it easy for someone to determine your
password by trying different combinations.
v When defining the password policy, ensure that this definition complies
with the password policy of the underlying operating systems and user
registries.
v When using Tivoli Directory Server as your user registry, you can take
advantage of its password history policy. For additional information about
setting the password history policy when using Tivoli Directory Server as
your user registry, see “Setting the password history policy” on page 361.
Web Portal Manager
To change policy settings for a specific user, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click User → Search Users to display the User Search page.
3. From the list of matching users, select the user whose policy needs to be
changed. The User Properties page for that user is displayed.
4. Click the Policy tab.
5. Modify the following policies as needed:
v For Max Login Failures, select Unset or Set to set or unset the maximum
number of login failures before the account is no longer allowed to
participate in the secure domain. If you select Set, either accept the default
value of 10 or change the value to a number equal to or greater than zero.
Chapter 11. Managing users and groups
149
v For Disable Time Interval, select Unset, Disable, or Set to set the time, in
seconds, or to disable each user account when the maximum number of login
failures is exceeded. If you select Set, either accept the default value of 180
seconds or change the value to a number equal to or greater than zero.
v For Minimum Password Length, select Unset or Set to set the minimum
number of characters required for the password. If you select Set, either
accept the default value of eight alphanumeric characters or change the value
to a number greater than zero.
v For Maximum Password Age, select Unset or Set to set the maximum time a
password can be used before it expires. The maximum password age is
relative to the last time the password was changed. If you select Set, either
accept the default value of 91 days (91-00:00:00) or change the value to a
number equal to or greater than zero. A value of 0 (000-00:00:00) indicates
that the password never expires.
v For Minimum Password Alphas, select Unset or Set to set the minimum
number of alphabetic characters required in a password. If you select Set,
either accept the default value of four alphabetic characters or change the
value to a number greater than zero.
v For Minimum Password Non-Alphas, select Unset or Set to set the
minimum number of non-alphabetic characters required in a password. If
you select Set, either accept the default value of one non-alphabetic character
or change the value to a number greater than one.
v For Max Password Repeated Characters, select Unset or Set to set the
maximum number of repeated characters allowed in a password. If you
select Set, either accept the default value of two repeated characters or
change the value to a number greater than two.
v For Password Spaces Allowed, select Unset, Yes, or No to determine
whether spaces are allowed in passwords. You can accept the default setting
of Unset. You can change the value to Yes to allow spaces in passwords or to
No to not allow spaces in passwords.
v For Max Concurrent Web Sessions, select Displace, Unset, Unlimited, or
Set to set the maximum number of concurrent Web sessions allowed. If you
select Set, type a number equal to or greater than one.
Note: This policy applies only to certain components. A Web session is a user
session that is maintained by the Web security solutions, such as
WebSEAL and plug-in for Web Servers. Refer to the component
administration guides to see if this setting is applicable and whether
specific configuration options are required to enforce this policy.
v For Account Expiration Date, select Unset, Unlimited, or Set to set the
account expiration date. You can accept the default setting of Unset. You can
change it to Unlimited or Set.
If you select Set, type the four-digit year in the Year field.
Either accept the default value of Jan 01-00:00:00 or change the value to the
date and time, specified as Month DD:hh:mm:ss. The hours must be entered
using a 24-hour clock (for example, 09 for 9:00 a.m. or 14 for 2:00 p.m.).
v For Time of Day Access, select Unset or Set to set the time of day access
policy. If you select Set, either accept the default settings or change them.
You can change these values:
– Select the days of the week from the choices provided.
– Select All Day or Between hours of.
150
Administration Guide
If you select Between hours of, also select the Start Time. The start time
format is specified as hours and minutes. The start time is expressed by
using a 24-hour clock.
If you select Between hours of, also select the End Time. The end time
format is specified as hours and minutes. The end time is expressed by
using a 24-hour clock.
If you select Between hours of, also select Local Time or UTC Time. The
time zone is local by default; UTC is Coordinated Universal Time.
6. Click Apply.
pdadmin
To set or change user policy settings using the pdadmin utility, log in to the
domain as a domain administrator and use the policy set command.
For example, to set the maximum password age of 31 days 8 hours and 30 minutes
for user bsmith, enter the following command:
pdadmin sec_master> policy set max-password-age 031-08:30:00 -user bsmith
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Setting global user policy
You can change global user settings, such as password policies, login-failure
policies, access policies, and account expiration policies using Web Portal Manager
or the pdadmin utility.
Notes:
v The valid range for numbers can be any number. However, use a
reasonable number for the task that you want to perform. For example, a
minimum password length must be long enough to protect your system
but not so short as to make it easy for someone to determine passwords
by trying different combinations.
v When defining the password policy, ensure that this definition complies
with the password policy of the underlying operating systems and user
registries.
v When using Tivoli Directory Server as your user registry, you can take
advantage of its password history policy. For additional information
about setting the password history policy when using Tivoli Directory
Server as your user registry, see “Setting the password history policy” on
page 361.
Web Portal Manager
To change global user settings, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click User → Show Global User Policy.
3. For Max Login Failures, select Unset or Set to set or clear the maximum
number of login failures before the account is no longer allowed to participate
in the secure domain. If you select Set, either accept the default value of 10 or
change the value to a number equal to or greater than zero.
4. For Disable Time Interval, select Unset, Disable, or Set to set the time, in
seconds, or to disable each user account when the maximum number of login
failures is exceeded. If you select Set, either accept the default value of 180
seconds or change the value to a number equal to or greater than zero.
Chapter 11. Managing users and groups
151
5. For Minimum Password Length, select Unset or Set to set the minimum
number of characters required for the password. If you select Set, either
accept the default value of eight alphanumeric characters or change the value
to a number greater than zero.
6. For Maximum Password Age, select Unset or Set to set the maximum time a
password can be used before it expires. The maximum password age is
relative to the last time the password was changed. If you select Set, either
accept the default value of 91 days (91-00:00:00) or change the value to a
number greater than zero.
7. For Minimum Password Alphas, select Unset or Set to set the minimum
number of alphabetic characters required in a password. If you select Set,
either accept the default value of four alphabetic characters or change the
value to a number greater than zero.
8. For Minimum Password Non-Alphas, select Unset or Set to set the minimum
number of non-alphabetic characters required in a password. If you select Set,
either accept the default value of one non-alphabetic character or change the
value to a number greater than one.
9. For Max Password Repeated Characters, select Unset or Set to set the
maximum number of repeated characters allowed in a password. If you select
Set, either accept the default value of two repeated characters or change the
value to a number greater than two.
10. For Password Spaces Allowed, select Unset, Yes, or No to determine whether
spaces are allowed in passwords. You can accept the default setting of Unset.
You can change the value to Yes to allow spaces in passwords or to No to not
allow spaces in passwords.
11. For Max Concurrent Web Sessions, select Displace, Unset, Unlimited, or Set
to set the maximum number of concurrent Web sessions to allow. If you select
Set, type a number equal to or greater than one.
Note: This policy applies only to certain components. A Web session is a user
session that is maintained by the Web security solutions, such as
WebSEAL and plug-in for Web Servers. Refer to the component
administration guides to see if this setting is applicable and whether
specific configuration options are required to enforce this policy.
12. For Account Expiration Date, select Unset, Unlimited, or Set to set the
account expiration date. You can accept the default setting of Unset. You can
change it to Unlimited or Set.
If you select Set, type the four-digit year in the Year field.
Either accept the default value of Jan 01-00:00:00 or change the value to the
date and time, specified as Month DD:hh:mm:ss. The hours must be entered
using a 24-hour clock (for example, 09 for 9:00 a.m. or 14 for 2:00 p.m.).
13. For Time of Day Access, select Unset or Set to set the time of day access
policy. If you select Set, either accept the default settings or change them.
You can change these values:
v Select the days of the week from the choices provided.
v Select All Day or Between hours of.
If you select Between hours of, also select the Start Time. The start time
format is specified as hours and minutes. The start time is expressed by
using a 24-hour clock.
If you select Between hours of, also select the End Time. The end time
format is specified as hours and minutes. The end time is expressed by
using a 24-hour clock.
152
Administration Guide
If you select Between hours of, also select Local Time or UTC Time. The
time zone is local by default; UTC is Coordinated Universal Time.
14. Click Apply.
pdadmin
To set or change global user settings using the pdadmin utility, log in to the
domain as a domain administrator and use the policy set command.
For example, to set a global user policy to a maximum password age of 31 days 8
hours and 30 minutes, enter the following command:
pdadmin sec_master> policy set max-password-age 031-08:30:00
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Importing users
You can import a user that exists in a user registry and make that user a Tivoli
Access Manager user using Web Portal Manager or the pdadmin utility.
When a user is imported, the domain administrator assigns a user name, which is
sometimes referred to as a principal name. The user name must be unique within
the domain because it is used by Tivoli Access Manager to identify this user.
Note: When ADAM is used as the user registry, you can import only existing users
defined within the same ADAM partition in which Tivoli Access Manager
was configured.
Web Portal Manager
To import a user that exists in a user registry and make that user a Tivoli Access
Manager user, complete the following steps:
1.
2.
3.
4.
Use Web Portal Manager to log in to the domain as a domain administrator.
Click User → Import User.
Type a User Id (for example maryj).
Click Group Membership to search for groups in which the user can be a
member.
5. Type a Registry UID. The registry UID specifies the location in the user
registry to be imported. For example: cn=maryj,o=ibm,c=us,dc=mkt. Lotus Notes
users require the full path name for the user being imported. For example: Mary
Jones/IBM/US
6. Select the Account Valid check box to indicate that the new user can participate
in the domain. If this option is not selected, the new user account is not valid
and the user cannot log in.
7. Select the GSO User check box to indicate that the user can use the global
sign-on (single sign-on) for Tivoli Access Manager.
8. Select the Password Valid check box to force a password change the next time
the user logs in to the domain. If this option is not selected, the user is
informed that the password has expired.
9. Click Create.
A message is shown if the user ID is created.
Chapter 11. Managing users and groups
153
pdadmin
To import a user that exists in a user registry and make that user a Tivoli Access
Manager user using the pdadmin utility, log in to the appropriate domain as a
domain administrator and use the user import command to import the user.
For example, to import the user information for the user named maryj from the
existing user registry definition, enter the following command:
pdadmin sec_master> user import –gsouser maryj "cn=Mary Jones,o=IBM,c=us,dc=mkt"
Note: When using an LDAP user registry and if necessary, the user information
that is imported to the domain can be imported again to another domain.
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting a user
You can delete a user using Web Portal Manager or the pdadmin utility. When you
delete a user, this user is removed from all objects with which it is associated. For
example, if this user is the only ACL entry that is associated with an ACL policy,
no other user or group can manage this ACL policy. Before deleting a user, you
must validate that there are other users or groups that can manage this ACL policy.
Web Portal Manager
To delete a user from a domain, complete the following steps:
1. User Web Portal Manager to log in to the domain as a domain administrator.
2. Click User → Search Users.
3. Search for one or more user names to delete and click Search.
4. Select the check boxes next to the user names to delete and then click Delete.
5. From the Delete Selected Users page, click Delete Users to confirm the deletion
or click Delete Users and Registry Entries to also remove the registry entries
associated with the selected users.
pdadmin
To delete a user from the domain using the pdadmin utility, log in to the domain
as a domain administrator and use the user delete command to delete a user. Any
resource credentials associated with a user account are automatically removed
when the user account is deleted. If the user does not exist in the user registry, an
error is displayed.
For example, to delete the user named jdoe and the associated information from
the user registry, enter the following command:
pdadmin sec_master> user delete –registry jdoe
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Managing groups
You can perform the following group tasks:
v “Creating a group” on page 155
v “Listing groups” on page 155
v “Importing groups” on page 156
v “Deleting a group” on page 157
154
Administration Guide
In the following sections, instructions are provided for using either Web Portal
Manager or the pdadmin utility, or both. For online help while using Web Portal
Manager, click the question mark to open a separate help window for the current
page.
Creating a group
You can create a group using Web Portal Manager or the pdadmin utility.
When a group is created, the domain administrator assigns a group name. The
group name must be unique within the domain because it is used by Tivoli Access
Manager to identify this group.
Note: When Active Directory Application Mode (ADAM) is used as the user
registry, groups must be created within the same ADAM partition in which
Tivoli Access Manager was configured.
For more information about groups, see “Creating groups” on page 190.
Web Portal Manager
To create a group in the domain, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Group → Create Group.
3. Type a Group Name for the group (for example, sales).
4. Optional: Type a Description for the group (for example, Sales).
5. Type a Registry GID. The registry GID specifies the location in the user
registry where the new group is created. For example:
cn=Sales,o=ibm,c=us,dc=mkt. Lotus Notes users require the full path name for
the group being created. For example: Sales/IBM/US.
6. Optional: Type the path in the Object Container field to the Tivoli Access
Manager object space where the group is to be created.
7. Click Create.
The new group is displayed as a link. Select the link and the properties for the
new group are displayed.
pdadmin
To create a group in the domain using the pdadmin utility, log in to the domain as
a domain administrator and use the group create command to create a group and
optionally place this group in a group container object. If the container object does
not currently exist, it is automatically created.
For example, to create the group named sales, enter the following command:
pdadmin sec_master> group create sales "cn=sales,o=IBM,c=us,dc=mkt" Sales
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Listing groups
You can search for group names using Web Portal Manager or the pdadmin utility.
Web Portal Manager
To search for and list up to a maximum of 100 groups, complete the following
steps:
Chapter 11. Managing users and groups
155
Use Web Portal Manager to log in to the domain as a domain administrator.
Click Search Groups.
At the Group Search page, use the special character (*) to filter group names.
Use the default value of 100 or type a Maximum Results number to limit the
number of group names that you want to view.
5. Click Search to display a table of group names. Each group name is displayed
as a link.
From the Group Search page, you can perform these tasks: create a group,
delete one or more existing groups, and click the link to view group properties.
6. Use the default value of 15 group names per page, or click Options to enter the
number of group names you want to view per page. Toggle back by clicking
Hide Options.
7. Use the default value of None, meaning that no text is used for filtering, or, click
Filters to find group names that contain, start with, or end with the text that
you specify. Toggle back by clicking Hide Filters.
1.
2.
3.
4.
pdadmin
To search for a list of groups using the pdadmin utility, log in to the domain as a
domain administrator and use the group list command to list groups.
For example, to search for and list up to a maximum of 100 groups, enter the
following command:
pdadmin sec_master> group list * 100
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Importing groups
You can import an existing group from a user registry into the domain and make
that group a Tivoli Access Manager group using Web Portal Manager or the
pdadmin utility.
When a group is imported, the domain administrator assigns a group name. The
group name must be unique within the domain because it is used by Tivoli Access
Manager to identify this group.
Note: When ADAM is used as the user registry, you can import only existing
groups defined within the same ADAM partition in which Tivoli Access
Manager was configured.
Attention: If you import a dynamic group, ensure that the policy server is
enabled for dynamic group support. For blade systems to benefit from dynamic
group support, also enable this stanza entry on each blade system. For details
about enabling the policy server for dynamic groups, see “Enabling dynamic group
support” on page 158.
Web Portal Manager
To import an existing group from a user registry into the domain and make that
group a Tivoli Access Manager group, complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Group → Import Group.
3. Type a Group Name for the group. For example, type sales.
156
Administration Guide
4. Type a Registry GID. The registry GID specifies the location in the user
registry of the group to be imported. For example, type
cn=sales,o=ibm,c=us,dc=mkt. Lotus Notes users require the full path name for
the group being imported. For example: sales/IBM/US.
5. Optional: Type the path in the Object Container field to the Tivoli Access
Manager object space where the group is to be imported.
6. Click Import.
The new group is displayed as a link. Select the link to display the properties for
the new group.
pdadmin
To import an existing group from a user registry into the domain and make that
group a Tivoli Access Manager group using the pdadmin utility, log in to the
domain as a domain administrator and use the group import command to import
an existing group and optionally place this group in a group container object. If
the container object does not currently exist, it is automatically created.
For example, to import the existing group named "cn=sales,o=IBM,c=us,dc=mkt"
from the user registry, enter the following command:
pdadmin sec_master> group import sales "cn=sales,o=IBM,c=us,dc=mkt"
Note: The group information that is imported to the domain can be imported
again to another domain, if necessary.
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Deleting a group
You can delete a group using Web Portal Manager or the pdadmin utility. When
you delete a group, this group is removed from all objects with which it is
associated. For example, if this group is the only ACL entry that is associated with
an ACL policy, no other user or group can manage this ACL policy. Before deleting
a group in this case, you must validate that there are other users or groups that
can manage this ACL policy.
Web Portal Manager
To delete a group from the domain, complete the following steps:
1.
2.
3.
4.
5.
Use Web Portal Manager to log in to the domain as a domain administrator.
Click Group → Search Groups.
Search for one or more group names to delete and click Search.
Select check boxes next to the group names to delete, and click Delete.
From the Delete Selected Groups page, click Delete Groups to confirm the
deletion or click Delete Groups and Registry Entries to also remove the
registry entries associated with the selected groups.
pdadmin
To delete a group from the domain using the pdadmin utility, log in to the domain
as a domain administrator and use the group delete command to delete a group.
For example, to delete the group named sales and the associated information from
the user registry, enter the following command:
pdadmin sec_master> group delete –registry sales
Chapter 11. Managing users and groups
157
For more information, see the IBM Tivoli Access Manager for e-business: Command
Reference.
Enabling dynamic group support
To enable dynamic group support on the policy server and all servers where
dynamic groups are supported, use the pdadmin utility. The command you run
depends on the type of user registry.
LDAP registry
For LDAP registry users, modify the dynamic-groups-enabled entry in the [ldap]
stanza of the ldap.conf file. To do so, edit the configuration files with a text editor
or use the pdadmin utility as follows:
pdadmin sec_master> config modify keyvalue set
"c:\Program Files\Tivoli\Policy Director\etc\ldap.conf
"ldap" "dynamic-groups-enabled" yes
For configuration changes to take effect, you must restart the updated server.
Note: Dynamic groups are not supported for the ADAM registry.
Active Directory
For Active Directory registry users, modify the dynamic-groups-enabled entry in
the [uraf-registry] stanza in the activedir.conf and activedir_ldap.conf files. To
do so, edit the configuration files with a text editor or use the pdadmin utility as
follows:
pdadmin sec_master> config modify keyvalue set
"c:\Program Files\Tivoli\Policy Director\etc\activedir.conf"
"uraf-registry" "dynamic-groups-enabled" yes
pdadmin sec_master> config modify keyvalue set
"c:\Program Files\Tivoli\Policy Director\etc\activedir_ldap.conf"
"uraf-registry" "dynamic-groups-enabled" yes
Note: Do not change this value if Active Directory cannot handle dynamic groups.
For information about setting up your environment to enable an Active
Directory registry to handle dynamic groups, consult the Microsoft Web site.
Microsoft supports Active Directory dynamic groups only for Windows
Server 2003 and beyond. For more information, see “Importing dynamic
groups to Tivoli Access Manager” on page 366.
For configuration changes to take effect, restart the server.
158
Administration Guide
Chapter 12. Certificate and password management
This chapter describes how Tivoli Access Manager uses server-side and client-side
certificates for authentication, key files and stash files, the configuration settings for
the default lifetime for both the certificates and the key file passwords, and the
initial configuration settings.
This chapter describes certificate and password management from the perspective
of the administration C API runtime. However, Tivoli Access Manager provides a
Java runtime for performing the same tasks. For more information about the
administration Java runtime and classes, see the IBM Tivoli Access Manager for
e-business: Administration Java Classes Developer Reference and the IBM Tivoli Access
Manager for e-business: Authorization Java Classes Developer Reference.
This chapter includes the following information:
v “Initial configuration” on page 160
v “Key file and stash file renewal information” on page 161
v “Trust determination” on page 162
v “Server certificate revocation” on page 164
v “Additional key and stash file considerations” on page 165
Tivoli Access Manager can use Secure Sockets Layer (SSL) for encryption, system
authentication, and application-level authentication. When installed and
configured, SSL uses certificates for operation that help to ensure a secure
environment. Tivoli Access Manager can also use Transport Layer Security (TLS)
version 1 instead of SSL. To use TLS, Federal Information Processing Standards
(FIPS) must be enabled.
In the secure environment, the policy server acts as the certificate authority (CA)
and is responsible for the creation and renewal of certificates. The Tivoli Access
Manager runtime package (PDRTE) relies on only SSL server-side authentication
and does not require a client-side certificate. However, all the Tivoli Access
Manager servers, such as the policy server, the authorization server, the policy
proxy server, and the resource manager servers rely on client-side certificates to
operate.
The Tivoli Access Manager servers use certificates to authenticate themselves. For
example, when the authorization server wants to communicate with the policy
server, it presents its client-side certificate. In this example, the policy server can be
considered the server and the authorization server as the client. The policy server
verifies that the certificate is valid and is signed by a trusted signer. In this case,
the trusted signer is the policy server itself, using the Tivoli Access Manager
certificate authority (PDCA) certificate. The authorization server does the same for
the certificate presented by the policy server. As part of the Tivoli Access Manager
application-level authentication, after the policy server determines that the
authorization server certificate is good, it tries to map that certificate to a Tivoli
Access Manager user. If the authentication succeeds, the servers can communicate.
The certificates used by Tivoli Access Manager are kept in key files. Key files have a
.kdb extension (or .ks extension for Java keystores). Key files must be secured and
protected by the strictest operating system controls available, because they contain
© Copyright IBM Corp. 1999, 2010
159
the private keys for the certificates. For example, the key file for the policy server
is ivmgrd.kdb and, by default, it can be read and written to by only the ivmgr
user.
The certificate files in a directory need to be accessible to the user ivmgr (or all
users). Ensure that the ivmgrd.kdb file and the directory or folder that contains the
ivmgrd.kdb file is accessible by the user ivmgr (or all users). In other words,
ensure that these users have the appropriate permissions for this file.
Furthermore, to facilitate unattended server operation, there are files that contain
an obfuscated (not encrypted) version of the password to the key files. These
versions are called stash files, and the stash files are denoted by a .sth file extension.
Java key files that are generated by Tivoli Access Manager do not have
corresponding stash files. Again, these stash files must be secured using native
standard operating system measures. For the policy server, the stash file is
ivmgrd.sth and its permissions are the same as the ivmgrd.kdb key file.
For security reasons, both the certificates and the key file passwords can be set to
expire after a configurable amount of time. The default lifetime for a certificate is
four years. The default lifetime for a key file password is 183 days. The fixed
lifetime for the PDCA certificate is 20 years. By default, the Tivoli Access Manager
servers refresh the certificates and passwords automatically while they are running.
The refresh process reissues a new certificate with a new lifetime and generates a
new password with the configured lifetime.
The Tivoli Access Manager calculates the life span of the certificate when you open
the PDContext. When opening the security context, the Tivoli Access Manager
verifies the need to refresh the context. If there is a need to refresh the certificate,
then Tivoli Access Manager creates an SSLContext with the new certificate and
processes the request.
If the servers are not running within a specified time frame, their certificates or
passwords can expire. In this case, a manual refresh is necessary. Furthermore, if a
certificate or a password or the entire key file is damaged, a manual refresh is
warranted to keep the Tivoli Access Manager domain secure. For information
about performing a manual refresh, see “Key file and stash file renewal
information” on page 161.
Initial configuration
The certificates used by the Tivoli Access Manager servers are created as part of
their initial configurations. In a brand-new Tivoli Access Manager installation, the
policy server is the first server configured. As part of its configuration, the PDCA
certificate is created, and a personal certificate that is used by the policy server is
created and signed by the PDCA certificate. Both of these certificates are located in
the ivmgrd.kdb key file. Also, as part of the policy server configuration, the Tivoli
Access Manager runtime key file pd.kdb is created, and the PDCA certificate is
inserted into it as a trusted certificate.
When new systems are added to the Tivoli Access Manager domain, the Tivoli
Access Manager runtime package is configured first. Again, as part of this
configuration, the system pd.kdb and pd.sth files are created and the PDCA
certificate is included in the key files as a trusted certificate.
When new resource managers, such as WebSEAL, are configured, the svrsslcfg
utility or an equivalent application programming interface (API) is run. This utility
160
Administration Guide
creates a key file (such as pdacld.kdb) and places a personal certificate for the
server in it. The utility also inserts the PDCA certificate as a trusted certificate in
the key file. These two certificates are obtained from the policy server and are
transported to the client machine over SSL using the Tivoli Access Manager
runtime key file.
The configuration files and certificate-related stanza entries, such as the configured
key file and the configured stash files, are discussed in Appendix B, “Configuration
file reference,” on page 203.
Key file and stash file renewal information
The following table lists the servers and their associated key files and stash files. It
also describes how they are created and refreshed.
Table 6. Server key and stash files
Server
Key and stash files
How created
How automatically
updated
How manually
updated
Tivoli Access
Manager runtime
package
pd.kdb and pd.sth
(does not contain a
client-side certificate)
During runtime
configuration
Running the
pdadmin1 utility
Running the
bassslcfg utility with
the –chgpwd option
Policy server
ivmgrd.kdb and
ivmgrd.sth
During server
configuration
Running the
pdmgrd1,2 command
Running the
mgrsslcfg utility with
the -chgpwd3 and
-chgcert3 options
Proxy server
pdmgrproxyd.kdb
During server
and pdmgrproxyd.sth configuration
Running the
pdmgrproxyd1
command
Running the svrsslcfg
utility with the
–chgpwd4 and the
–chgcert5 options
Authorization server
ivacld.kdb ivacld.sth
During server
configuration
Running the pdacld1
command
Running the svrsslcfg
utility with the
-chgpwd4 and
-chgcert5 options
Resource manager
The key files and
stash file names are
resource
manager-dependent,
and the file name is
configurable.6
Running the svrsslcfg Running an instance
utility with the
of the resource
–config option
manager1
Running the svrsslcfg
utility with the
–chgpwd7 and
–chgcert8 options
Table notes:
1
Automatic certificate and password refresh can be turned off by setting the
ssl-auto-refresh stanza entry to no in the [ssl] stanza in the respective
configuration file.
2
Because the policy server also acts as the CA for the secure domain, it must be
recycled after a refresh. It continues to operate normally until it is recycled,
except it cannot issue or renew certificates for other servers until it is recycled.
The policy server log file contains a message stating when the server needs to
be restarted.
3
Before running this command, the policy server must be stopped.
4
Before running this command, the authorization server must be stopped.
5
Before running this command, the policy server must be running, and the
authorization server must be stopped.
6
Java resource managers have an equivalent to key files, known as Java
keystores, where the application personal certificate and the PDCA certificate
Chapter 12. Certificate and password management
161
7
8
are stored. Java resource managers do not have a stash file equivalent. The
names of keystores are created by running the Java SvrSslCfg class with the
–action config option.
Before running this command, the resource manager must be stopped.
Before running this command, the policy server must be running, and the
resource manager must be stopped.
Trust determination
Each key file contains a list of trusted certificate authorities (CAs). For Tivoli
Access Manager, each key file except for ivmgrd.kdb key file has the Tivoli Access
Manager certificate authority (PDCA) certificate as a trusted CA. This CA is the
certificate that is used to sign all the other Tivoli Access Manager certificates. This
CA is created during policy server configuration and is placed in the ivmgrd.kdb
file.
It is important to protect the ivmgrd.kdb file to keep the private key in the PDCA
certificate from being compromised. If it is compromised, it must be regenerated. If
the compromise happens, each key file and each certificate in the domain needs to
be regenerated.
Use the following process for regenerating these files in the domain:
1. Regenerate the PDCA certificate and policy server certificate by generating a
new ivmgrd.kdb file using the mgrsslcfg –config utility. (The policy server
must be stopped.)
2. Regenerate the Tivoli Access Manager runtime certificates on the policy server
by running the bassslcfg –config utility.
3. After obtaining the CA certificate, you can choose to automatically download
the CA certificate or manually copy the file.
v If auto-download is set to on (enabled) and the policy server is running, the
CA certificate is automatically obtained. By default, auto-download is
enabled.
v If auto-download is set to off (disabled), the base-64 DER encoded version of
the PDCA certificate must be copied to the machine. This file is stored as
pdcacert.b64 on the policy server.
4. On each runtime machine, run the bassslcfg –config utility.
5. On each authorization server in the domain, regenerate its key files by running
the svrsslcfg –config utility. (The policy server must be running.) This
command updates both the server certificate for the authorization server and its
trusted certificate (the new PDCA certificate).
6. On each resource manager in the domain, regenerate its key files by running
the svrsslcfg –config utility. (The policy server must be running.) This
command updates both the server certificate for the authorization server and its
trusted certificate (the new PDCA certificate).
From the Java perspective, the Tivoli Access Manager runtime also stores the
PDCA certificate. If the PDCA certificate is compromised and must be regenerated,
all servers that are configured to use Tivoli Access Manager Runtime for Java must
be reconfigured. All resource managers that were previously configured with the
SvrSslCfg class must also be reconfigured.
162
Administration Guide
Reconfiguring the PDCA on the policy server
When the certificate is compromised or has expired, you need to reconfigure the
PDCA on the policy server. To reconfigure the PDCA, complete the following
steps:
1. Stop all Tivoli Access Manager services that are running on the machine by
entering the following command:
pd_start stop
2. Change to the directory where the key files are located. Assuming the default
directory on a Linux or UNIX operating system, enter the following command:
cd /var/PolicyDirector/keytab
3. Rename the ivmgrd.kdb key file, ivmgrd.sth stash file, and pdcacert.b64 PDCA
file by entering the following commands:
mv ivmgrd.kdb ivmgrd.kdb.old
mv ivmgrd.sth ivmgrd.sth.old
mv pdcacert.b64 pdcacert.b64.old
4. Change to the PolicyDirector/sbin directory. Assuming the default directory on
a Linux or UNIX operating system, enter the following command:
cd /opt/PolicyDirector/sbin
5. Configure the policy manager server to create a new key file and stash file by
entering the following command:
mgrsslcfg -config
6. Change the ownership of the newly created key file, stash file, and certificate to
ivmgr:ivmgr by entering the following commands:
chown ivmgr:ivmgr /var/PolicyDirector/keytab/ivmgrd.kdb
chown ivmgr:ivmgr /var/PolicyDirector/keytab/ivmgrd.sth
chown ivmgr:ivmgr /var/PolicyDirector/keytab/pdcacert.b64
7. Configure the Tivoli Access Manager runtime using the bassslcfg –config
utility. For example, enter the command but replace the values for the –c and
–h options.
bassslcfg -config -h myhostname -c /var/PolicyDirector/keytab/pdcacert.b64
8. Start the Tivoli Access Manager services on the machine by entering the
following command:
pd_start start
The management environment must be running.
After regenerating the PDCA certificate on the policy server, you might need to
copy the PDCA certificate to each runtime machine in the domain. If
auto-download is enabled, you do not need to copy the file.
Reconfiguring the PDCA on the runtime machines
After reconfiguring the policy server and transferring the newly generated PDCA
certificate to each runtime machine, complete the following steps on each runtime
machine:
1. Stop all Tivoli Access Manager services that are running on the machine by
entering the following command:
pd_start stop
2. Change to the PolicyDirector/sbin directory. Assuming the default directory on
a Linux or UNIX operating system, enter the following command:
cd /opt/PolicyDirector/sbin
Chapter 12. Certificate and password management
163
3. Configure the Tivoli Access Manager runtime using the bassslcfg –config
utility. For example, enter the command but replace the values for the –c and
–h options.
bassslcfg -config -h myhostname -c /var/PolicyDirector/keytab/pdcacert.b64
4. Start the Tivoli Access Manager services on the machine by entering the
following command:
pd_start start
Transferring the PDCA certificate to other machines
After regenerating the PDCA certificate, you might need to transfer it to each
machine in the domain. When auto-download is disabled, you need to copy the
file manually to each machine. If the File Transfer Protocol (FTP) is supported in
your environment, you can use one of the following FTP option:
v Use the put command from the policy server to transfer the certificate to the
other machine
v Use the get command from the other machine to retrieve the certificate from the
policy server
The following steps assume that the pdcacert.b64 certificate is retrieved from the
policy server:
1. Connect to the runtime machine by opening an FTP session. To illustrate,
pdruntime1 is the name of the runtime machine.
ftp pdruntime1
2. Log in to the remote machine using the appropriate user ID and password.
3. Change to the directory where the certificate is stored. Assuming the default
directory on a Linux or UNIX operating system, enter the following command:
cd /var/PolicyDirector/keytab
4. Indicate that the file to be transferred is a text (ASCII) file by entering the
following command:
ascii
5. To view the transfer process visually, enter the following command:
hash
6. Start the transfer by entering the following command:
put pdcacert.b64
7. After the transfer completes, end the FTP session by entering the following
command:
quit
Server certificate revocation
If the certificate on a C-based resource manager is compromised, you can run the
svrsslcfg –chgcert utility to replace the existing server certificate and update the
PDCA certificate. For Java-based resource managers, the
PDAppSvrConfig.replaceAppSvrCert() method must be used.
You can also unconfigure and reconfigure the server by running the svrsslcfg
–unconfig and svrsslcfg –config utilities. Make sure that the policy server is
running. These commands update both the server certificate for the authorization
server and its trusted certificate (the new PDCA certificate). Similarly, a Java-based
resource manager can be unconfigured and reconfigured using the Java SvrSslCfg
class.
164
Administration Guide
Additional key and stash file considerations
Additional considerations for key file and stash file renewal include:
v When a certificate and the password to the key file containing that certificate are
both expired, the password must be refreshed. For example, for the
authorization server, run the svrsslcfg –chgpwd utility and then the svrsslcfg
–chgcert utility. You must run these utilities, because a valid password is needed
to open the key file to obtain the certificate.
v The value for the lifetime of a certificate is controlled by the value of the
ssl-cert-life entry in the [ssl] stanza of the ivmgrd.conf file when the policy
server is started. Any certificates that are issued or renewed use this value. To
increase or decrease this value, change the value and restart the policy server.
The new value is in effect only for certificates that are issued or renewed from
that point onward. The actual time used is the lesser of the value specified in the
ivmgrd.conf configuration file and the number of days before the policy server
CA certificate expires.
v For automatic password renewal, the value for the lifetime of a password is
controlled by the value of the ssl-pwd-life entry in the [ssl] stanza that is in
effect when the server is started. For manual password renewal, the value is
dictated by the value supplied to the svrsslcfg –chgpwd utility. This value is
also written into the appropriate configuration file.
v The key file password refresh occurs after half the lifetime of the password
expiration date. If the blade server is not running during the second half of the
password life, an ACL update is unable to refresh the password because this
operation uses the connection from the management server to the blade server,
using the SSL connection protected by the certificate (which, in turn, is protected
by the password).
v Tivoli Access Manager servers can also communicate with Lightweight Directory
Access Protocol (LDAP) using SSL. In the standard configuration, this
communication uses server-side authentication only. Therefore, the Tivoli Access
Manager server needs only the CA certificate that signed the LDAP server
certificate or the LDAP server certificate itself. The expiration and management
of these certificates are not handled by Tivoli Access Manager. However, it is
possible to include the LDAP certificate in the key file for a resource manager by
running the svrsslcfg –config utility with the -C option.
For certificates that are not managed by Tivoli Access Manager, these certificates
must be refreshed by using the same mechanism used to create the initial
certificate. The new certificate can be replaced in the key file by running the
svrsslcfg –modify –C new_cert_filename utility.
v After running the bassslcfg –config utility, you might need to change the
permissions on the pd.kdb and pd.sth files.
v The configuration files mentioned are found in the install_dir/etc directory. For
example, on an AIX® system, the policy server, authorization server, and runtime
configuration files are /opt/PolicyDirector/etc/ivmgrd.conf,
/opt/PolicyDirector/etc/ivacld.conf, and /opt/PolicyDirector/etc/pd.conf.
Similarly, the key files and stash files can be found in the install_dir/keytabs
directory.
v Tivoli Access Manager does not distinguish between export and domestic
encryption. For Java-based encryption, the strength is regulated by the
jurisdiction files that are present in the Java runtime environment. There is no
set length for keys generated by the Tivoli Access Manager runtime.
v Both the public keys that are included in certificates and the private keys that
might be stored in key files have key lengths. The maximum key length is 2048
Chapter 12. Certificate and password management
165
bits. Public keys having 2048 bit key lengths can be generated by using the
configuration utilities (bassslcfg, mgrsslcfg, or svrsslcfg).
166
Administration Guide
Chapter 13. Server management
This chapter provides detailed information for performing general administration
and configuration tasks on the Tivoli Access Manager servers.
This chapter contains the following information:
v “Tivoli Access Manager servers”
v “Tivoli Access Manager utilities” on page 170
v “Tivoli Access Manager servers tasks” on page 170
v “Server configuration file tasks” on page 172
v “Policy server administration tasks” on page 174
Tivoli Access Manager servers
Tivoli Access Manager consists of the following server processes, or daemons:
pdmgrd
The server process for the policy server.
pdacld
The server process for the authorization server.
pdmgrproxyd
The server process for the policy proxy server
Web Portal
Manager
Policy server
Master
authorization
database
User
registry
Authorization
server
Replica
authorization
database
Figure 18. Tivoli Access Manager server components
The policy server manages the policy database, also called the master authorization
database, and maintains location information about other Tivoli Access Manager
servers in the domain. There must be at least one policy server defined for each
domain.
© Copyright IBM Corp. 1999, 2010
167
The authorization server allows other applications to make authorization calls to
Tivoli Access Manager using the authorization application programming interface
(API). The authorization server also acts as a logging and auditing collection server
to store records of server activity.
The policy proxy server helps support several network deployment strategies for
the policy server and the resource managers. A resource manager can be any server
or application that uses the Authorization API to process client requests for access
to resources, such as WebSEAL servers or Authorization API applications.
Proxy server
A policy proxy server is a server that acts as an intermediary between a less trusted
network and a more trusted network so that the enterprise can ensure security,
administrative control, and caching service. A policy proxy server is associated
with or part of a gateway server that separates the enterprise network from the
outside network and a firewall server that protects the enterprise network from
outside intrusion. In a Tivoli Access Manager environment, the policy proxy server
runs on behalf of the policy server for a given number of resource manager and
administrative tasks, such as the pdadmin commands.
The policy proxy server serves many important functions in a Tivoli Access
Manager environment. The proxy can be used to terminate any connections from a
less trusted network and to pass those requests to a policy server in a more trusted
network using a different connection. This protects the policy server in the more
trusted network from denial-of-service attacks and other similar attacks. In this
deployment scenario the proxy is deployed in what is commonly called the
demilitarized zone (DMZ).
Also, the proxy is useful in a wide-area network (WAN) deployment where the
policy server and several applications are deployed at separate locations across a
slow connection. Typically this happens when the policy server and the
applications are deployed in different geographical locations. If a proxy is
deployed on the same network as the applications and the applications are
configured to go through the proxy, only the proxy contacts the policy server
instead of each application. This configuration is important for the following
reasons:
v The policy proxy server can be configured to cache security policy such that
when a policy update occurs at the policy server, only one copy of the policy is
transmitted from the policy server to the proxy. The proxy then provides the
policy to all the applications. If the proxy was not there, each individual
application would request and receive the policy from the policy server,
significantly increasing the network traffic.
v This configuration can also improve security because firewalls between the
locations can be configured to only allow the proxy to contact the policy server
and not the applications.
Figure 19 on page 169 shows the interaction between applications, the policy proxy
server, and the policy server.
168
Administration Guide
Central Office
Internet
Internet
Policy Proxy Server
Policy Server
Internal Network
Subnet DMZ
Firewall
Application
Application
Application
Policy Proxy Server
Branch Office
Figure 19. Proxy server
Server dependencies
Take the following dependencies into account during your server configuration:
v There must be at least one instance of the policy server.
v There must be at least one policy server defined. You can have a single policy
server and create as many domains as you want. When a domain is created, a
separate policy database is also created for each domain. The single policy server
can access any of the distinct policy databases.
v The policy server manages the policy database.
v There must be only one policy database (master authorization database) in a
domain.
v The policy database must reside on a highly available policy server with a
robust file system.
v Each policy database is subject to a regular backup procedure. The administrator
can specify the location for the backup files.
v The policy servers provide authorization database replication services to all
other Tivoli Access Manager servers in the domain running in local cache mode.
v Each resource manager, such as Tivoli Access Manager WebSEAL, Tivoli Access
Manager for Business Integration, or Tivoli Access Manager for Operating
Systems, applies security policy based on information from either the policy
database or from a replicated authorization database.
Chapter 13. Server management
169
Tivoli Access Manager utilities
The Tivoli Access Manager utilities are discussed in detail in the IBM Tivoli Access
Manager for e-business: Command Reference. The table at the beginning of the utilities
section lists available utilities and their purposes.
The pdadmin utility, which is also discussed in IBM Tivoli Access Manager for
e-business: Command Reference, provides commands that assist in troubleshooting
problems. For example, the pdadmin utility includes the server task stats and
server task trace commands that allow you to enable statistics gathering and
capture information about error conditions. In addition, the IBM Tivoli Access
Manager for e-business: Troubleshooting Guide provides further diagnostic information
for using the Tivoli Access Manager pdadmin utility and other utilities.
Tivoli Access Manager servers tasks
This section describes the following server processes:
v “Starting and stopping servers on Linux and UNIX operating systems”
v “Starting and stopping servers on Windows operating systems” on page 171
Starting and stopping servers on Linux and UNIX operating
systems
Server processes are normally enabled and disabled through automated scripts that
run at system startup and shutdown.
In Linux and UNIX environments, you can also use the pd_start utility to
manually start and stop the server processes. This technique is useful when you
need to customize an installation or when you need to perform troubleshooting
tasks. You can run scripts only on the local machine.
The syntax for the pd_start utility is as follows:
# pd_start {start|restart|stop|status}
You can run the pd_start utility from any directory. This utility is located in the
following directory:
/opt/PolicyDirector/bin/
Starting the Tivoli Access Manager servers using the pd_start
utility
Use the pd_start utility to start all Tivoli Access Manager servers not currently
running on a particular machine:
# pd_start start
This utility waits until all servers have started before returning the prompt.
Starting individual servers manually
You can manually start the servers individually by running the server-specific
utilities.
You must run the start commands as an administration user, such as root.
Start the Tivoli Access Manager servers in the following order:
1. For the policy server, enter the following command:
170
Administration Guide
install_path/bin/pdmgrd
2. For the policy proxy server, enter the following command:
install_path/bin/pdmgrproxyd
3. For the authorization server, enter the following command:
install_path/bin/pdacld
Restarting the Tivoli Access Manager servers using the pd_start
utility
Use the pd_start utility to stop all Tivoli Access Manager servers on a particular
machine and then restart the servers:
pd_start restart
This utility waits until all servers have started before returning the prompt.
Stopping the Tivoli Access Manager servers using the pd_start
utility
Use the pd_start utility to stop all Tivoli Access Manager servers on a particular
machine in the correct order:
pd_start stop
This utility waits until all servers have stopped before returning the prompt.
Displaying server status using the pd_start utility
Use the pd_start command to display server status:
pd_start status
Tivoli Access Manager Servers:
Server
Enabled
Running
pdmgrd
webseald
pdacld
pdmgrproxyd
yes
no
yes
no
yes
no
no
no
Starting and stopping servers on Windows operating systems
On Microsoft Windows operating systems, use the Services window that is
accessed from the Control Panel window to start and stop the server processes
manually and to control whether these servers are started when the system is
booted. This capability can be useful when customizing an installation or when
troubleshooting problems. Administrative privileges are required to use this utility.
You can start and stop all Tivoli Access Manager servers, or you can start and stop
them individually. The servers must be stopped and started in the correct order.
The servers must be started in the following order:
1. Policy server
2. Proxy server
3. Authorization server
The servers must be stopped in the following order:
1. Authorization server
2. Proxy server
3. Policy server
Chapter 13. Server management
171
The AutoStart Service automatically starts each of the Tivoli Access Manager
servers whenever the Startup Type is set to Automatic. After the servers start, the
AutoStart Service exits.
To prevent automatic starting of a Tivoli Access Manager server by the AutoStart
Service, use the startup properties to set that server Startup Type to Disabled.
Starting the Tivoli Access Manager servers from the Services
window
You can also use the Services Control Panel to manually start the individual
servers:
1. From the Start menu, select Settings Control Panel.
2. Double-click Administrative Tools.
3. Double-click Services.
4. From the Name column, right-click the Tivoli Access Manager servers to start,
and click Start.
Note: The servers must be started in the following sequence:
v Policy server
v Proxy server
v Authorization server
Repeat the last step until all servers are started.
Stopping the Tivoli Access Manager servers from the Services
window
You can also use the Services Control Panel to manually stop the individual
servers:
1.
2.
3.
4.
From the Start menu, select Settings Control Panel.
Double-click Administrative Tools.
Double-click Services.
From the Name column, right-click the Tivoli Access Manager servers to stop,
and click Stop.
Note: The servers must be stopped in the following sequence:
v Authorization server
v Proxy server
v Policy server
Repeat the last step until all servers are stopped.
Server configuration file tasks
You can use the server configuration files to customize the operation of Tivoli
Access Manager and its servers. Various server configurations are discussed in
Appendix B, “Configuration file reference,” on page 203.
Changing configuration settings
The configuration files, stanzas, and stanza entries are described in Appendix B,
“Configuration file reference,” on page 203. To change a configuration setting,
complete the following steps:
172
Administration Guide
1. Make a backup copy of the configuration file that you plan to modify. Having a
backup copy allows you to return the configuration file to a known working
state, if you encounter an error.
2. Stop the Tivoli Access Manager servers that are affected.
3. Use one of the following mechanisms to modify the configuration file:
v Use the pdadmin config commands to modify the configuration file.
v Use the appropriate configuration tool for your server to change the
configuration settings:
– For the ivmgrd.conf file, use the mgrsslcfg utility.
– For the pd.conf file, use the bassslcfg utility.
– For all other configuration files, use the svrsslcfg utility.
Note: Many stanzas or values are created or modified only by using Tivoli
Access Manager configuration utilities. Some values are completed
automatically after the configuration is completed. Do not modify these
values.
4. Start the Tivoli Access Manager servers that are affected.
For example, if you want to change the ivmgrd.conf file, you must stop the policy
servers, make the change, and then restart all the policy servers for the change to
become effective.
Automating server startup at boot time
Stanza entries for automating server startup are located in the [pdrte] stanza of
the pd.conf configuration file.
By default, the pd.conf file is installed at the following location for Linux and
UNIX operating systems:
/opt/PolicyDirector/etc/pd.conf
By default, the pd.conf file is installed at the following location for Windows
operating systems:
c:\Program files\tivoli\Policy Director\etc\pd.conf
Policy server
When the PDMgr package is installed, the policy server automatically starts after
each system reboots:
[pdrte]
boot-start-ivmgrd = yes
To prevent the policy server from automatic startup, set:
boot-start-ivmgrd = no
Authorization server
When the PDAcld package is installed, the authorization server automatically
starts after each system reboots:
[pdrte]
boot-start-ivacld = yes
To prevent the authorization server from automatic startup, set:
boot-start-ivacld = no
Chapter 13. Server management
173
Proxy server
When the PDMgrProxyd package is installed, the policy proxy server automatically
starts after each system reboots:
[pdrte]
boot-start-pdmgrproxyd = yes
To prevent the policy proxy server from automatic startup, set:
boot-start-pdmgrproxyd = no
Policy server administration tasks
The policy server manages the policy database (or databases), and maintains
location information about other Tivoli Access Manager servers in each domain.
The policy server typically requires little administration or configuration. This
section describes configuration tasks available to the administrator.
v “Replicating the authorization database”
v “Setting the number of update-notifier threads” on page 175
v “Setting the notification delay time” on page 176
Replicating the authorization database
A Tivoli Access Manager domain administrator can make security policy changes
to a domain at any time. A primary responsibility of the policy server is to make
the necessary adjustments to the domain master authorization database to reflect
these changes.
When the policy server modifies the master authorization database, it can send out
notification of this change to all resource manager servers (with replica databases).
The authorization servers must then request a database update from the policy
server.
Note: Additionally, resource manager servers can check for database updates by
polling the policy server at regular intervals. Polling configuration for a
WebSEAL client, for example, is explained in the IBM Tivoli Access Manager
for e-business: WebSEAL Administration Guide.
Tivoli Access Manager allows you to configure update notifications from the policy
server to be an automatic process or a manually controlled task. The
auto-database-update-notify stanza entry is located in the [ivmgrd] stanza of the
ivmgrd.conf configuration file. By default, the stanza entry value is set to yes
(update notification is automatically performed by the policy server):
[ivmgrd]
auto-database-update-notify = yes
This automatic setting is appropriate for environments where database changes are
few and infrequent. When you configure update notification to be automatic, you
must also correctly configure the max-notifier-threads and notifier-wait-time
stanza entries. For more information about these entries, see “Setting the number
of update-notifier threads” on page 175 and “Setting the notification delay time”
on page 176.
When you configure update notification to be manual, manual application of the
server replicate command controls this event.
[ivmgrd]
auto-database-update-notify = no
174
Administration Guide
This manual setting is appropriate for environments where database modifications
occur frequently and involve substantial changes. In some cases several database
modifications can generate many update notifications that soon become obsolete
because of the continuing changes to the master database. These obsolete
notifications cause unnecessary network traffic and impair the performance of
resource managers because of continued requesting and processing of policy
updates.
The manual control of update notification allows you to complete the process of
modifying the master authorization database before update notifications are sent
out to authorization servers with database replicas.
In manual mode, update notification uses the notifier thread pool (as it does in
automatic mode). Therefore, the manual mode setting is affected by the
max-notifier-threads stanza entry value. For more information about this stanza
entry, see “Setting the number of update-notifier threads.”
Using the server replicate command
When you configure update notification to be manual, manual application of the
server replicate command controls this event.
pdadmin_secmaster> server replicate -server test_server
When the -server option (test_server in the previous example) is specified, only
that server is notified of changes to the master authorization database. A response
is returned indicating the success or failure of the notification and the replication.
When the -server option is not specified, all configured resource manager servers
receive update notifications. A successful response indicates only that the policy
server has begun sending out update notifications. The response does not indicate
success or failure of the actual notification and replication processes.
The authorization required to run this command is the s action bit on the
/Management/Server object.
For more information about the server replicate command, see the IBM Tivoli
Access Manager for e-business: Command Reference.
Setting the number of update-notifier threads
The policy server is responsible for synchronizing all database replicas in the
domain. When a change is made to the master database, notification threads
announce this change to all replicas configured to receive update notifications.
Each replica must then download the new information or the changes from the
master.
The policy server configuration file, ivmgrd.conf, contains a stanza entry for setting
the maximum number of update-notifier threads. This pool of threads allows
simultaneous (parallel) notification.
For example, to concurrently notify 30 replicas of a database change, the thread
pool must be set to at least 30. If there are more than 30 replicas, another round of
notifications occurs (in this example, 30 at a time). All replicas are guaranteed to be
notified, regardless of the value of this stanza entry.
The performance goal of the update-notifier threads value is to announce a
database change as quickly as possible. Generally the value must be set to equal
Chapter 13. Server management
175
the number of existing replicas. This results in the performance advantage of a
single pool of threads quickly accomplishing the notification task to all replicas at
once.
The default event notifier thread pool is set as the following:
[ivmgrd]
max-notifier-threads = 10
When the auto-database-update-notify stanza entry is set to yes, you must
correctly configure this stanza entry and also the notifier-wait-time stanza entry.
See also “Setting the notification delay time.”
Setting the notification delay time
When the policy server is instructed to make a change to the master authorization
database, it waits for a default period of time before sending out notifications to
database replicas. The default time delay is set at 15 seconds. This time delay is
reset with each subsequent change to the database.
The purpose of the time delay is to prevent the policy server from sending
individual replica notifications for each change in a series of database changes. The
time delay helps to ensure optimal performance of the Tivoli Access Manager
system.
This performance feature is particularly important for environments where batch
changes are made to the authorization database. It is not efficient for policy
changes to be sent to database replicas until all changes are made.
You can override this default notification time delay by changing the
notifier-wait-time entry value in the [ivmgrd] stanza of the ivmgrd.conf
configuration file. For example:
[ivmgrd]
notifier-wait-time = 20
By default, the value is set to 15 seconds.
When the auto-database-update-notify entry is set to yes, you must configure
this entry and the max-notifier-threads entry. See also “Setting the number of
update-notifier threads” on page 175.
176
Administration Guide
Chapter 14. High availability of the policy server
This chapter provides information on ensuring that Tivoli Access Manager
provides high availability for the policy server should a server failure occur. This
chapter describes how Tivoli Access Manager supports the replication capability of
the LDAP directory server to ensure that its data is always available.
This chapter includes the following information:
v “Data integrity”
v “Primary and replica LDAP servers”
v “Active and passive policy servers”
v “High availability management” on page 178
Data integrity
You should ensure that the data that is needed by Tivoli Access Manager is always
available. To ensure data redundancy, all data should be stored on data devices
that are Redundant Array of Independent Disks (RAID) secured.
Authorization information and decision making can be off-loaded to authorization
servers. All data should be subject to a robust backup process to ensure that you
can recover the data in the event of a hardware or software error. The pdbackup
utility provides backup, restore, and extract capabilities for Tivoli Access Manager
data. See IBM Tivoli Access Manager for e-business: Command Reference for more
information on this utility.
Primary and replica LDAP servers
Tivoli Access Manager allows primary and replica LDAP servers. The replica
LDAP server, on a different node, can assume LDAP server operations if the
primary LDAP server fails.
During failover, no write operations can occur. Only read-only LDAP server
operations are permitted during failover.
Refer to the LDAP server documentation for complete information about high
availability of LDAP servers.
Active and passive policy servers
The policy server manages the master policy database and the policy databases for
the other secure domains. The policy server also maintains location information
about other servers in the domain. When the policy server fails or when the
system on which the policy server is located become unavailable, an outage might
result because of the lack data redundancy.
To provide the redundancy for the shared data and for the functions that are
provided by the Tivoli Access Manager policy server, you can install and configure
a primary policy server and a standby policy server. The standby server takes over
policy server functions in the event of a system or primary policy server failure.
© Copyright IBM Corp. 1999, 2010
177
The standby policy server acts as the primary policy server until the original
primary policy server is up and running again. The standby server reverts back to
serving as the failover server.
If you plan to set up a primary and standby policy server, the following rules
apply:
v A 2-node IBM AIX High-Availability Cluster Multiprocessing (HACMP)
environment consisting of one active server and one standby server was tested.
Therefore, IBM supports only an AIX HACMP version 5.1 or later 2-node
environment.
v A primary and a standby policy servers must be installed and configured on
separate machines, and both policy servers must be within the AIX HACMP
cluster environment.
v The user registry servers (such as an LDAP server, Active Directory, or Lotus
Domino) must be on a machine other than the machines where the primary and
standby policy servers are installed.
v Back up any shared data or any shared policy database before configuring the
primary and standby servers to the shared file system.
v Each AIX system must have access to a shared disk array that is configured for
data redundancy.
v The primary and a standby policy server must be configured to the shared file
system, and the shared file system must be mountable by each server.
v Both the policy database and the configuration files, which are used by the
policy server, must be located on a shared disk array.
Follow the procedure in the IBM Tivoli Access Manager for e-business: Installation
Guide for setting up a policy standby server.
High availability management
The procedure for setting up a standby policy server is discussed in the IBM Tivoli
Access Manager for e-business: Installation Guide. The following tasks are procedures
to ensure that you correctly followed the initial Tivoli Access Manager
configuration procedures for setting up HACMP Tivoli Access Manager primary
and standby servers.
Verify the policy server setup for high availability
To verify that the installation and configuration procedures were correctly
followed, ensure that the following primary tasks are completed:
v Make sure that you have set up the required soft links from the active primary
server to the standby server.
v Make sure that you have modified the appropriate configuration options in the
ivmgrd.conf and pd.conf configuration files on both the primary and standby
policy servers. These configuration files must have the same default settings for
the following required user and group IDs:
– The ivmgr user ID
– The tivoli user ID
– The ivmgr group ID
– The tivoli group ID
v Make sure you copy files from the local AIX file system for the primary server,
the standby server, and the policy server to the shared file system, that the
shared file system is located on a common directory, and that each user and
group has the necessary access permissions.
178
Administration Guide
If any of these items are incorrectly set, return to the procedure for setting up a
standby policy server in the IBM Tivoli Access Manager for e-business: Installation
Guide.
Review log files
You can monitor the transition process of the primary policy to the standby server
by examining the hacmp.log file to verify that all HACMP failover operations
occurred. The procedure for reviewing HACMP logs can be found in the in the
HACMP documentation. This log is usually found in the /tmp directory.
If a read or write operation error occurred during the policy server failover, you
can review the primary policy server log files. The location of the Tivoli Access
Manager log files depends on whether Tivoli Common Directory is used. See the
IBM Tivoli Access Manager for e-business: Troubleshooting Guide for information about
these log files and the XML log file viewer.
Chapter 14. High availability of the policy server
179
180
Administration Guide
Chapter 15. Multiple-tenancy policy server
A multiple-tenancy server refers to a server that permits the hosting of multiple
customers on a single server instead of on multiple client machines. For example,
your company might be sharing applications or data on your company's server
with your customer (for example, Smith-Davis Enterprises). Before you add data
and information that belongs to another customer (for example, Systems, Inc.), you
must somehow ensure that these two customers cannot get access to the other
company's data or applications.
Using a multiple-tenancy (multi-domain) server, you can run each company's
applications or data in an isolated server environment. Running in an isolated or
partitioned server environment replaces the need to use multiple physical servers
for each customer and their applications. Depending on the demands of your
customers and their applications, you can host multiple clients on a single server.
Replacing multiple servers with one server reduces the costs to your company for
the services you provide to your customers. For example, fewer servers reduce
hardware costs and reduce IT personnel burden. It is easier to manage a single
server than it is to manage multiple servers.
A multiple-tenancy server does not have to be less secure than the traditional
one-server, one-client approach. Using technologies such as SSL and restricted
access, you can protect two customers (users) on the same server from one another.
Extra layers of security for multiple-user applications are designed into Tivoli
Access Manager. Tivoli Access Manager compartmentalizes each domain to seal
users off from one another rather than using the multiple-user security provisions
that are provided by the native operating system.
The Tivoli Access Manager runtime clients must be configured into a specific
domain at installation time. The domain membership information accompanies
each subsequent request from the client to the policy server. The [domains] stanza
in the ivmgrd.conf configuration file for the multiple-tenancy policy server contains
a list of valid existing domains. See “[domains] and [domain=domain_name]
stanzas” on page 248 for an explanation of each stanza entry.
Each domain must have its own [domain=domain_name] stanza. For example, to set
up separate domains for Smith-Davis Enterprises and Systems, Inc., you might
create two domains uniquely named smithdavis and systemsinc, respectively:
[domains]
domain = smithdavis
domain = systemsinc
[domain=smithdavis]
[domain=systemsinc]
The multi-tenancy domains implemented by Tivoli Access Manager results in
separate databases for each protected object space. All of the databases can use the
same underlying user registry (one LDAP registry with distinct and separate
distinguished names). For example, to specify the sde0001.db file, specify the file
name and directory in this stanza entry:
[domain=smithdavis]
database-path = D:\smithdavis\sde0001.db
© Copyright IBM Corp. 1999, 2010
181
The distinguished name (DN) can be used to restrict the registry into which users
can be created or imported. The distinguished name substrings must appear in the
user's distinguished name, for example:
cn=sdeuser1,ou=sde,dc=mkt,c=US
The previous distinguished name has the following representation:
cn = common name (sdeuser1) for K.L. Logan
ou = organizational unit (sde) for Smith-Davis Enterprises
dc = domain component (mkt) for Marketing Group
c = country (US) for United States
To restrict user accounts to be created in the dc=mkt,c=US directory container for
the smithdavis domain, you would specify to allow this registry substring in this
stanza entry:
[domain=smithdavis]
allowed-registry-substrings = "dc=mkt,c=US"
To restrict user accounts to be created in the dc=mkt directory container for the
smithdavis domain, regardless of where that container exists within the registry,
specify the following stanza entry:
[domain=smithdavis]
allowed-registry-substrings = "dc=mkt"
A completed [domains] stanza in the ivmgrd.conf configuration file might look like
the following stanza example for the policy server:
[domains]
domain = smithdavis
domain = systemsinc
[domain=smithdavis]
database-path = D:\smithdavis\sde0001.db
allowed-registry-substrings = "dc=mkt,c=US"
[domain = systemsinc]
database-path = D:\systemsinc\sysinc0001.db
allowed-registry-substrings = "dc=sales,c=US"
182
Administration Guide
Chapter 16. Delegated administration
Tivoli Access Manager allows high-level administrators to delegate management
responsibilities of the domain to lower-level administrators. This capability is vital
to successfully manage large domains that are composed of numerous
departments.
Tivoli Access Manager supports delegated administration in the following areas:
v Delegated management of resources in subregions of the object space
Administration capabilities are restricted to a portion of the object space.
v Delegated management of groups and users
Administration capabilities are restricted to a portion of the user population.
This chapter contains the following sections:
v “Overview of delegated administration”
v “Delegated role administration” on page 185
v “Delegated object space management” on page 186
v “Delegated user and group management” on page 188
v “Security policy for delegated administration” on page 193
Overview of delegated administration
Delegated administration provides a Tivoli Access Manager administrator the
ability to create delegate user domains, create new users, add existing users to
additional domains, and assign various types of administrators to the domains.
These delegate administrators can then perform a subset of administrative tasks on
the users in their assigned domain. This concept of delegate user administration
can be applied to all Tivoli Access Manager users so that a hierarchy of user
domains is formed. In this hierarchical arrangement, each Tivoli Access Manager
user can be managed only by the administrators for the domain of which the user
is a member or by the administrators for the super domains (explained later in this
chapter). The actual tasks that administrators can perform depend on their
assigned administrator types.
A Tivoli Access Manager administrator, such as sec_master, can create a number of
enterprise domains and assign one or multiple types of administrators to each
enterprise domain. The administrator for an enterprise domain can create new
users in the domain and add existing Tivoli Access Manager users to the domain.
In addition to this user-related task, Tivoli Access Manager administrators can
create new domains below the enterprise domain level (subdomains) and assign
users to be the administrators for these new domains (domain administrators).
Administrators of the new domains can then create new users in their own
domain.
The Tivoli Access Manager administrator for the enterprise domain (the domain's
superdomain) also has authority to administer the domain. Tivoli Access Manager
administrators can create and manage as many domains under their authority as
necessary to fulfill their unique business needs.
© Copyright IBM Corp. 1999, 2010
183
Note: An enterprise domain is basically the top-level domain, and any domain
created below an enterprise domain level is just called a domain.
As an example of this type of multiple domain administration in Figure 20, a Tivoli
Access Manager administrator can create enterprise domains A and B and assign
an administrator for each domain. The domain administrator for enterprise domain
B can create new users P and Q. A Tivoli Access Manager administrator can create
domains C and D below the enterprise domains A and B, and assign domain
administrators to C and D. The Tivoli Access Manager administrator can then
create domain E below domain D, and assign a domain administrator to E. The
domain administrator for domain E can then create new users X, Y, and Z within
domain E. Because a domain administrator for a domain can also administer that
domain's subdomains, both the domain administrators for domain D and the
domain administrator for enterprise domain B can create users (or perform other
administrative tasks) for domain E.
Secure domain
Enterprise domain A
...
Enterprise domain B
(Users P, Q, . . .)
Domain C
Domain D
Domain E
(Users X, Y, Z, . . .)
...
Figure 20. Delegate administrators
For each delegate user domain (including the enterprise domain), predefined
administrator types can be assigned in that domain. The following are the various
administrator types and the set of administrative tasks that can be performed by
administrators assigned to each of these types:
Tivoli Access Manager administrator
The Tivoli Access Manager administrator is a member of the iv-admin
group. The Tivoli Access Manager administrator can perform all delegate
administration tasks.
Domain administrator
The domain administrator can perform administrative tasks for the users in
their domain. Domain administrators can create new users and
administrators in their own domain, and assign an existing domain user to
be an administrator (of any type except domain administrator) for the
domain.
Senior administrator
A senior administrator has the same authority as a domain administrator,
except that a senior administrator cannot assign additional administrators.
184
Administration Guide
Administrator
An administrator has the same authority as a senior administrator, except
that an administrator cannot create new domain users. An administrator
can modify existing users' properties.
Support Administrator
A support administrator serves the user in a help desk role and can view
users’ properties, change users’ passwords, and modify the Is Password
Valid? flags for users.
The delegate user administration tool enforces the administrative tasks that can be
performed with each administrator type. When an administrator logs in,
administrative tasks become available in accordance to the administrator type of
that user.
Delegated role administration
Another part of the Tivoli Access Manager delegate administration system is role
administration. To successfully deploy Tivoli Access Manager, a security policy
must be defined that regulates access to objects, and the actions that can be
performed on those objects. Execution of this policy is usually difficult because the
security policy is often defined by high-level members of an organization with an
emphasis on global security issues. The policy then must be put into action by
local members of the organization, who see the lower-level details and
implementation concerns. Often these two groups have similar goals for overall
organizational security, but interconnecting these two disparate points of view is
challenging. Role-based administration provides an enhanced ability for
organizational security to meet the requirements of today’s complex security
requirements for scalability, simplicity, and flexibility.
To understand role administration, the first concept that must be defined is a role.
A role consists of a number of tasks, responsibilities, or skills required to fulfill a
specific job requirement. When this definition is contrasted against the access
control list (ACL) model, a role becomes a list of one or more pairs of objects and
one or more access permissions that are applied to the object. For example:
v object 1: permission 1
v object 2: permission 2, 3, and 4
v object 3: permission 5
For a role to be used it must be activated. A role is activated when a Tivoli Access
Manager administrator enables its definition in the Tivoli Access Manager
namespace. After a role is activated and a user is assigned to the role, the user has
permission 1 for object 1, permissions 2, 3, and 4 for object 2, and permission 5 for
object 3. The access permissions for these objects allow the user to access the
objects, and therefore perform the job responsibility defined by the role. For
example, an accountant role can be defined to consist of the following two pairs of
objects and permissions:
v Payroll check object: create/modify/delete
v Reimbursement request object: approve
When this role is activated and an employee in the accounting department is
assigned to this role, that employee can create, modify, or delete a payroll check
and approve a reimbursement request; thus, performing the job that an accountant
is expected to perform.
Chapter 16. Delegated administration
185
Administrative tasks for roles
To successfully administer roles, an administrator must be able to perform three
types of tasks:
Role creation
Role creation involves defining a role so that it has a list of one or more
pairs of Tivoli Access Manager objects and permissions that can be applied
to the objects. When a role is created, a Tivoli Access Manager group is
created to represent the role. A corresponding group object in the
management object space is also created. The object/permissions pair
information for the role is stored in the extended attributes associated with
the group object. Only a Tivoli Access Manager administrator can create a
role.
Role assignment
Role assignment consists of assigning a user to a role that was already
created. The purpose behind assigning users to roles is to let those users
have access permissions on objects defined in the role. This function
reduces the workload involved in maintaining user-permission-object
relationships, because role assignment is separated from object/access
permission management. When a user is assigned to a role in Web Portal
Manager, the user is added as a member of the group that represents the
role. Domain administrators, senior administrators, and administrators of a
domain can assign users in their domains to a role.
Role activation
Role activation enables a newly created role to function. After a role is
created and a user is assigned to that role, the user does not have access
permissions for the objects defined in the role until the role is activated.
When a role is activated in Web Portal Manager, an ACL entry that
contains the group that represents the role and the access permissions
defined in the role are added to the ACL for each object defined in the
role. Because a user was added to the group when the user is assigned to
the role, that user has permissions to access the objects only after a role is
activated. Only a Tivoli Access Manager administrator can activate a role.
A role is an entity that can be delegated and administered. When a role is created,
it can be assigned to an enterprise domain. Domain administrators can in turn
assign any of the roles within that domain to any subdomain. When a role is
assigned to a subdomain, an administrator for that subdomain can assign any
subdomain users to that role. This process of assigning roles to subdomains can be
repeated as needed so that roles can be made available to the appropriate users.
Role assignment to an enterprise domain can be performed only by the Tivoli
Access Manager administrator. Domain administrators can assign a role to their
subdomains.
Delegated object space management
The distribution of administration responsibilities within a domain is called
management delegation. The need for management delegation generally arises from
the growing demands of a large site containing many distinct departmental or
resource divisions.
186
Administration Guide
Typically, a large object space can be organized into regions representing these
departments or divisions. Each distinct region of the domain is usually better
organized and maintained by a manager who is more familiar with the issues and
needs of that branch.
Structuring the object space for management delegation
Structure your object space to contain distinct regions, or branches, where
submanagement responsibilities specific to that branch can be carried out.
In Figure 21, both the Engineering and Publications regions of the object space
require separate management control. Control of these regions begins with the root
of each region and extends to all objects below the root.
/WebSEAL
Marketing
server
Engineering
server
Resources
Publications
Object space
Figure 21. Structuring the object space for management delegation
Default administration users and groups
Tivoli Access Manager provides several important administration groups during
installation. For information on these user and groups, see “Default administration
users and groups” on page 43.
Example of management delegation
A large object space might require many administration users to manage a variety
of subbranches. In this scenario, the access control lists (ACLs) for the directories
on the path to each of these branches must contain entries for each account, with
traverse permission. For a site with many administration users, these ACLs could
contain a long list of entries representing all these administration accounts.
The following technique resolves the problem of numerous ACL entries for
administrators:
1. Create an administration group account.
2. Add all new administration users to this group.
3. Add this group as an ACL entry (with traverse) to the directories leading to
each subbranch that requires management delegation.
4. At each branch root ACL, create an administration group for each subbranch
and add the appropriate user to the appropriate subbranch administration
group (with b, c, T, plus other appropriate permissions).
5. Remove the administration group ACL entry (and any other entry) from the
root.
Chapter 16. Delegated administration
187
Now, only that user has control over the root and all objects below the root.
In Figure 22, the iv-admin group contains all administration users. The
pub-manager user is a member of this group and therefore, has the traverse
permission required to navigate to the/Publications directory.
The /Publications directory includes the pub-manager user entry in its ACL.
Because pub-manager is the delegated administrator of this branch (with the
appropriate permissions), pub-manager can remove the iv-admin group account
(and any other ACL entries) from the /Publications ACL to gain total control over
this branch of the Web space.
/WebSEAL
user sec_master
group iv-admin
abcTdmlrx
bT
/Marketing
user sec_master
group iv-admin
AbcTdmlrx
bT
Explicit
ACL
Inherited
ACL
/Resources
/Publications
group iv-admin
...
user pub-manager
bT
abcTdmlrx
Figure 22. Management Delegation Example
Delegated user and group management
In order to manage a large or complex set of users, you can delegate the
management of specific groups of users to lower-level administrators. When an
administrator is given policy management control of a group, that administrator
has policy management control over the user members of that group.
Delegated group management defines:
v Who has administration responsibility for a specific group (and the user
members of that group).
v What level of group and user control was given to this administrator.
In this discussion, the term, administrator, refers to the responsibilities and controls
granted to an otherwise typical user. An administrator of delegated duties is a
normal user with additional powers to perform certain management tasks.
Setting up delegated group management requires the following steps:
1. Determine a logical and practical hierarchy of the users and user types who are
members of the domain.
2. Create group container objects that reflect this hierarchy.
3. Create appropriate administration groups within these container objects.
188
Administration Guide
4. Add the appropriate user to the appropriate administration group with the
specific permissions needed to perform the required tasks.
Creating group container objects
By default, the /Management region of the Tivoli Access Manager object space has a
Groups container object that you can use to organize the hierarchy of groups in
your domain.
Container objects are structural designations that allow you to organize the object
space into distinct and hierarchical functional regions. Group container objects allow
you to define distinct categories of group types.
To create actual groups within each specific group container object using Web
Portal Manager or the pdadmin utility, log in to the domain as a domain
administrator.
Web Portal Manager
To create a new group container object using Web Portal Manager, complete the
following steps:
1. Log in to the domain.
2. Click Object Space → Create Object.
3. In the Object Name text field, type the full path for the object name. For
example: /Management/Groups/Travel
4. In the Description text field, type the description for the object space. For
example: Travel Container Object
5. Click Create.
To see the new object in the hierarchical structure, browse the object space. See
“Listing object spaces” on page 67.
-
/Management
-
/Management/Groups
+
/Management/Groups/Travel
Figure 23. Group container object
pdadmin
To create a new group container object using the pdadmin utility, log in to the
domain and use the object create command.
For example, to create the new /Management/Group/Accounting delegate container
object for the Accounting department and allow delegate administrators to attach
ACL policies, enter the following command:
pdadmin>object create /Management/Group/Accounting "Accounting Department"
14 ispolicyattachable yes
Chapter 16. Delegated administration
189
You can also use the group create command to create a group container object. See
“Creating groups.”
For more information about the object create command, see the IBM Tivoli Access
Manager for e-business: Command Reference.
Creating groups
To create a new group and optionally place this group in a group container object
using Web Portal Manager or the pdadmin utility, log in to the desired domain as
a domain administrator.
Web Portal Manager
To create a new group and optionally place this group in a group container object,
complete the following steps:
1. Use Web Portal Manager to log in to the domain as a domain administrator.
2. Click Group → Create Group.
3. In the Group Name text field, type the name for the group (for example,
group1). This field is required.
4. Optional: In the Description text field, type the description for the group (for
example, Travel group 1).
5. In the Registry GID text field, type the registry GID. The registry GID specifies
the location in the user registry where the new group is created. For example:
cn=travel,c=us. Lotus Notes users require the full path name for the user
being created. For example: travel/US.
6. Optional: In the Object Container text field, type the path to the Tivoli Access
Manager object space where the group is to be created. Be sure to type the path
using a leading backward slash (/):
/Travel
The path is created under /Management/Groups (for example,
/Management/Groups/Travel).
7. Click Create.
The new group is displayed as a link. Select the link and the properties for the
new group are displayed.
pdadmin
To create a new group and optionally place this group in a group container object
using the pdadmin utility, log in to the domain and use the group create
command. This command has the following syntax:
pdadmin>group create group_name dn cn [group_container]
Argument
Description
group_name
Name of the new group object.
dn
Distinguished name for the new group.
cn
Common name for the new group.
group_container
Relative path name for the group container object where this new
group should be located. If no group container object is specified,
the group is placed under /Management/Groups.
If the container object does not currently exist, it is created.
190
Administration Guide
For example:
pdadmin>group create group1 “cn=travel,c=us” Group1 Travel
pdadmin>group create group2 “cn=travel,c=us” Group2 Travel
Notes:
1. All new group container objects that you create appear under the default
/Management/Groups container. To create a container at another sublevel, use a
relative path name for the group_container variable.
2. The group create command does not allow you to create a group container
object without a group.
3. To add a new group to the object space, the administrator must have create (N)
permission on the ACL governing the associated group container object.
If no group container object is specified, the administrator ACL entry (with the
create permission) must be specified in the ACL governing the
/Management/Groups container.
At installation, a single default ACL (default-management), which is attached to
/Management, defines the permissions on all groups and group containers. You
must add explicit ACLs to customize this control.
4. You can add multiple groups to a single group container.
The ACL on the group container object controls (through inheritance) all groups
located under the container object. The container object and its groups are now
the domain of the administrator with the delegated responsibilities.
5. The placement of a new group in the object space is fixed on creation.
As soon as a group is created, you can move its position only by deleting the
group from the object space (but not LDAP) and then importing the group to a
new location (users in the group are maintained).
For more information about the group create command, see the IBM Tivoli Access
Manager for e-business: Command Reference.
ACL policies affecting group management
Authorization to control a group of users is obtained by attaching an appropriate
ACL to the group object or group container object.
The ACL, constructed and attached by a higher-level administrator, should contain
the appropriate permissions for the actions that must be performed by the
delegated administrator of that group (or groups).
If the group is located under the /Management/Groups section of the object space,
the ACL must be attached to /Management/Groups or the group itself.
If the group is located under a group container object, the ACL must be attached to
the group container object or the group itself. If you attach the ACL to the
/Management/Groups container object, the ACL would impact all other group
container objects located below /Management/Groups in the object space.
The ACL that is attached to one of these locations (or inherited from above)
determines:
v Who controls the group object and the users in the group
v What actions can be performed on the group and its users
Chapter 16. Delegated administration
191
The following operations and ACL permissions are appropriate for group
management:
Operation
Permission
create (a new group) import (group data from the user
registry)
N (create)
delete (a group)
d (delete)
show (group details)
v (view)
modify (group description)
m (modify)
add (an existing user to a group)
A (add)
remove (a user member of the group)
A (add)
You can use the pdadmin utility or Web Portal Manager to perform these
operations.
Attention:
The add (A) permission allows you to add any existing user to your groups. If an
outside user is placed in a group, the administrator of that group has control of the
user (and might share control of the user with administrators of other groups
where that user is a member). This permission is should be granted only to
high-level administrators who are responsible for user and group organization and
corporate policy.
Use caution when assigning an administrator the A permission. A delegated
administrator with the A permission should not have m, W, N, or d permissions.
Notes:
1. The create (N) permission must be located in an ACL that is attached to
/Management/Groups or on a group container object.
2. All other permissions listed can be located in an ACL attached to
/Management/Groups, a group container object, or the group object itself.
ACL policies affecting user management
The group administrator can perform an action on a user if the administrator has
the appropriate permission defined on any of the groups where that user is a
member.
The following operations and ACL permissions are appropriate for user
management:
Operation
192
Permission
create (a new user within one or more specified
groups) import (user data from the user registry)
N (create)
delete (a user)
d (delete)
show (user details)
v (view)
modify (user description)
m (modify)
account valid
m (modify)
reset password
W (password)
password-valid
W (password)
Administration Guide
You can use the appropriate pdadmin utility or Web Portal Manager to perform
these operations.
Notes:
1. The create (N) permission (in the group ACL or group container ACL) allows
you to create or import a user and enter that user into the groups you control.
user create user1 “cn=user1,c=us” user1 user1 adcde group1
user import user2 “cn=user2,c=us” group1
2. You can also create a user without designating a group. In this case, however,
the create (N) permission must be located in an ACL on the /Management/Users
container object.
3.
4.
5.
6.
The ACL attached to /Management/Users defines the permissions for all users
(whether they are members of a group or not).
A group administrator can perform an operation on a user if that administrator
has the appropriate permission defined in any group where that user is a
member.
If a user is not a member of any group, an administrator must have
appropriate permissions in an ACL on /Management/Users to perform
operations on that user.
The password (W) permission is appropriate for help desk operators who must
assist users who have forgotten their passwords.
The operator can reset the forgotten password to some known value, and then
set user modify password-valid (pdadmin) to no. This action forces the user to
change the password at the next login. Setting user modify password-valid to
no for a user does not indicate if the password is not valid due to the
max-password-age policy, which is a global setting. The policy set
max-password-age command sets the maximum time before a password
expires.
The view (v) permission is used to control the output of user list, user list-dn,
user show groups, group list, and group list-dn commands. The view
permission is used to filter the output of these commands. If the user does not
have view permission on a group or user that is being returned by the
command, that group or user is filtered from the output.
Security policy for delegated administration
The previous sections described how to delegate administration of security policy
for protecting resources and delegating management of the users who access those
resources. These two aspects of delegated administration often need to be
combined to establish a complete delegated administration security policy.
Be careful which permissions you grant in combination with each other.
For example, the A permission should never be granted together with the m, W, or
d permissions except to the most trusted administrators. The consequence of
granting both A and W to administrators is that the administrators can add any
user to the group for which they have these permissions and then change that
user’s password. Any user can be chosen, including a more senior administrator or
even sec_master. In this way, a malicious administrator could gain full access to
the system by logging in as the senior user.
The consequence of granting the A and m permissions together are similar except
that an administrator with both of these permissions needs only this combination
to disable any account in the group. The consequence of granting the A and d
Chapter 16. Delegated administration
193
permissions together are similar except that an administrator with both of these
permissions needs only this combination to delete any user ID in the group.
You must establish groups that you use to delegate user management tasks. These
tasks include creating new users, deleting users and resetting passwords.
Administrators that perform user administration tasks should have the N, d, m, W,
and v permissions to create, delete, modify (disable or change description), reset or
invalidate passwords, and view users they are responsible for managing. These
groups are used only for delegating user management. These groups should not be
used for protecting other resources in the domain.
You must also establish groups that you use to delegate management of a security
policy for protected resources within the domain. Administrators controlling
security policy for these groups should have the A and v permissions but none of
the N, d, m, or W permissions. These groups are used to control access to
resources that need protecting.
Example:
Suppose that you have a Web space accessible to the Internet with resources that
should be:
v Publicly accessible
v Accessible only to customers and employees
v Accessible only to employees
The space can be structured as follows:
/WebSEAL/
www.company_ibm.com/
customers/
sales/
An ACL at the root of the www.company_ibm.com Web space allows public access to
everything in the Web space. An ACL at customers allows access to customers and
sales people. Another ACL at sales allows access only to sales people. These ACLs
might look like the following example:
public-access
user sec_master
any-other
unauthenticated
customer-access
user sec_master
group customers
group sales
any-other
unauthenticated
sales-access
user sec_master
group sales
any-other
unauthenticated
abcTdmlrx
Tlrx
Tlrx
abcTdmlrx
Tlrx
Tlrx
abcTdmlrx
Tlrx
These ACLs would be attached, respectively, to the following objects:
/WebSEAL/www.company_ibm.com
/WebSEAL/www.company_ibm.com/customers
/WebSEAL/www.company_ibm.com/sales
Suppose that you have the following delegated user administration policy. Sales
people (members of the sales group) are allowed to create new accounts for
194
Administration Guide
customers and grant them access to the customers portion of the Web space. Only
administrators (members of the sales-admin group) are allowed to manage
accounts for new sales people.
The following group structure implements this policy:
/Management/
Groups/
sales
<- ACL sales-admin
sales-users
<- ACL sales-users-admin
customers
<- ACL customers-admin
customers-users <- ACL customers-users-admin
The sales-admin ACL is used to administer membership of the sales group, which
in turn, is used to control access to the sales-people-only portion of the Web
space. The only permission required is for the sales-admin group to be able to add
and remove users from this group. The view (v) permission is also useful to
administrators to allow them to view group membership and users in the group.
sales-admin
group super-admin
group admin
Tabc
TAv
The sales-users-admin ACL, by attachment to the sales-users group, controls who
can manage users who are members of the sales-users group (this is the
sales-admin group again).
sales-users-admin
group super-admin
group admin
Tabc
TNWdmv
Similarly, the customers-admin ACL is used to administer membership to the
customers group, which in turn, is used to control access to the customers-only
portion of the Web space.
customers-admin
group super-admin
group sales
Tabc
TAv
The customers-users-admin ACL, by attachment to the customers-users group,
controls who can manage the members of the customers-users group (this the
sales group again). Members of the sales-admin group can manage customers.
customers-users-admin
group super-admin
group sales
group admin
Tabc
TNWdmv
TNWdmv
In each ACL, a super-admin group entry is granted attach, browse, and control
permissions. Members of the super-admin group are responsible for administering
these ACLs.
Chapter 16. Delegated administration
195
196
Administration Guide
Chapter 17. Diagnostics and auditing
Tivoli Access Manager provides ways to collect events that you can use for
diagnostic and auditing purposes of the servers. Events for diagnostics and
auditing pertain to the operations of the Tivoli Access Manager servers. These
events do not pertain to the installation of the these servers.
To enable diagnostics and auditing, you define which types of events to capture.
When events are captured, they can be written to log files, to the standard output
(STDOUT) device, to the standard error (STDERR) device, or to a combination of
these destinations. Beyond these destinations, when events are captured, they can
be redirected to a remote server or redirected to an application for processing
using log agents.
During the installation of the Tivoli Access Manager servers, the installation logs
capture all messages for that specific installation. When using the installation
wizard, each server has its own log file. When using a native installation, the
installation uses the operating system logs. For information about installation logs,
see the IBM Tivoli Access Manager for e-business: Troubleshooting Guide.
Diagnostic events
For diagnostics, define which message events and which trace events to capture.
These events can help you troubleshoot problems.
To configure diagnostic events, define statements in the server-specific routing files.
Each server has an associated routing file. The statements in these routing files are
for both message events and trace events. You define the statements for message
events by severity level. You define the statements for trace events by trace level
and optionally by component.
For additional information about message and trace events, see the IBM Tivoli
Access Manager for e-business: Troubleshooting Guide.
Auditing events
For auditing purposes, define which audit, statistic, or other type of events to
capture. These events allow you to create snapshots of a variety of server activities.
You can log audit events using either the native Tivoli Access Manager approach
or IBM Common Auditing Service.
To configure auditing events, define stanza entries in the configuration files.
Depending on your desired approach, define different stanza entries in different
configuration files. For native Tivoli Access Manager auditing, you define logcfg
entries in the appropriate stanza of the server-specific configuration files. For the
Common Auditing Service, define entries in the [cars-filter] stanza.
For additional information about audit events, see the IBM Tivoli Access Manager for
e-business: Auditing Guide.
© Copyright IBM Corp. 1999, 2010
197
198
Administration Guide
Appendix A. Guidelines for changing configuring files
These guidelines are provided to help you make changes to the Tivoli Access
Manager configuration files. The guidelines are divided into the following
categories:
v
v
v
v
v
v
v
General guidelines
Default values
Strings
Defined strings
File names
Integers
Boolean values
General guidelines
Use the following general guidelines when making changes to the configuration
settings:
v Use the config modify command in the pdadmin command line interface to
update configuration files for Tivoli Access Manager. See "config modify" in the
IBM Tivoli Access Manager for e-business: Command Reference for more information
and instructions for using these commands.
– To modify a single key/value pair, use the pdadmin (local login) config
modify command with the set option. The following command is an example
that modifies the dynamic-groups-enabled value in the uraf-registry stanza
of the activedir.conf file on a Windows platform:
pdadmin> login local
pdadmin local> config modify keyvalue set "C:\Program Files\Tivoli\Policy
Director\etc\activedir.conf" "uraf-registry" "dynamic-groups-enabled" yes
– To modify multiple key/value pairs, use the pdadmin (local login) config
modify command with the append option. The following command is an
example that modifies multiple values for the domain option in the
uraf-registry stanza of the activedir_ldap.conf file on a Windows platform.
pdadmin> login local
pdadmin local> config modify keyvalue append "C:\Program Files\Tivoli\Policy
Director\etc\activedir_ldap.conf" "uraf-registry" "domain"
"dc=my_ad_domain, dc=com|myhost.my_ad_domain.com
pdadmin local> config modify keyvalue append "C:\Program Files\Tivoli\Policy
Director\etc\activedir_ldap.conf" "uraf-registry" "domain"
"dc=my_ad_domain2, dc=com|myhost2.my_ad_domain2.com
v There is no order dependency or location dependency for stanzas in any
configuration file.
v Stanza entries are marked as required or optional. When an entry is required,
the entry must contain a valid key and value.
v Do not change the names of the keys in the configuration files. Changing the
name of the key might cause unpredictable results for the servers.
v Stanza entries and key names are case-sensitive. For example, usessl and UseSSL
are treated as different entries.
v Spaces are not allowed for names of keys.
© Copyright IBM Corp. 1999, 2010
199
v For the key value pair format of key = value, the spaces surrounding the equal
sign (=) are not required, but they are recommended.
v Non-printable characters (such as tabs, carriage returns, and line feeds) that
occur at the end of a stanza entry are ignored. Non-printable characters are
ASCII characters with a decimal value less than 32.
Default values
Use the following guidelines when changing default configuration settings:
v Many values are created or modified only by using configuration programs. Do
not manually edit these stanzas or values.
v Some values are filled in automatically during configuration. These values are
needed for the initialization of the server after the configuration.
v The default values for a stanza entry might be different, depending on the server
configuration. Some key value pairs are not applicable to certain servers and are
omitted from the default configuration file for this server.
Strings
Some values accept a string value. When you manually edit the configuration file,
use the following guidelines to change configuration settings that require a string:
v String values are expected to be characters that are part of the local code set.
v Additional or different restrictions on the set of allowable string characters
might be imposed. For example, many strings are restricted to ASCII characters.
Consult each stanza entry description for any restrictions.
v Double quotation marks are sometimes, but not always, required when you use
spaces or more than one word for values. Refer to the descriptions or examples
for each stanza entry when in doubt.
v The minimum and maximum lengths of user registry-related string values, if
there are limits, are imposed by the underlying registry. For example, for Active
Directory the maximum length is 256 alphanumeric characters.
Defined strings
Some values accept a string value, but the value must be one of a set of defined
strings. When you manually edit the configuration file, make sure that the string
value you type matches one of the valid defined strings values.
For example, the [aznapi-configuration] stanza section contains the following
entry:
mode = {local|remote}
The value for mode is expected to be local or remote. Any other value is invalid
and results in an error.
File names
Some values are file names. For each stanza entry that expects a file name as a
value, the description of the stanza entry specifies which of the following
constructs are valid:
Filename
No directory path included.
200
Administration Guide
Relative filename
A directory path is allowed but not mandatory.
These files typically are expected to be located relative to the location of a
standard Tivoli Access Manager directory. The stanza entry for each
relative path name lists the root directory to which the file name is relative.
Fully qualified absolute path
An absolute directory path is required.
Some stanza entries allow more than one of the above choices.
The set of characters permitted in a file name can be determined by the file system
and by the local code set. For Windows operating systems, file names cannot have
a backward slash (\), a colon (:), a question mark (?), or double quotation marks
(").
Integers
Many stanza entries expect the value for the entry to be expressed as an integer.
When defining an entry with an integer, consider the following guidelines:
v Some stanza entries that take an integer value expect integer values within a
valid range. The range is described in terms of a minimum value and a maximum
value.
For example, in the [ivmgrd] stanza, the max-notifier-thread stanza entry has a
minimum value of 1 thread and a maximum value of 128 threads.
For some entries, the integer value must be positive, and the minimum value is
1. For other entries, a minimum integer value of 0 is allowed.
Use caution when setting an integer value to 0. For example, an integer value of
0 might disable the function that is controlled by that stanza entry. For example,
in the [ivacld] stanza, the entry tcp-req-port = 0 disables the port number. Or,
an integer value of 0 might indicate that the number is unlimited. For example,
in the [ldap] stanza, the entry max-search-size = 0 means there is no limit to
the maximum search size.
v For some entries requiring integer values, Tivoli Access Manager does not
impose an upper limit for the maximum number allowed. For example, there is
typically no maximum for timeout-related values, such as timeout = number in
the [ldap] stanza.
For this type of entry, the maximum number is limited only by the size of
memory allocated for an integer data type. This number can vary, based on the
type of operating system. For systems that allocate 4 bytes for an integer, this
value is 2147483647.
However, as the administrator, use a number that represents the value that is
most logical for the value you are trying to set.
v
Boolean values
Many stanza entries represent a Boolean value. Tivoli Access Manager recognizes
the Boolean values yes and no.
Some of the entries in the configuration files are read by other servers and utilities.
For example, many entries in the [ldap] stanza are read by the LDAP client. Some
of these other programs recognize additional Boolean characters:
v yes or true
v no or false
Appendix A. Guidelines for changing configuring files
201
Anything other than yes|true, including a blank value, is interpreted as no|false.
The recognized Boolean entries are listed for each stanza entry. Refer to the
individual descriptions to determine when true or false are also recognized.
202
Administration Guide
Appendix B. Configuration file reference
The operation of the Tivoli Access Manager servers is controlled through the use of
configuration files. Each configuration file contains sections that are called stanzas.
Server configuration files are ASCII text-based and contain stanza entries.
Configuration files are processed only when the servers start. The following
configuration files are currently used by Tivoli Access Manager:
pd.conf
The configuration file that is used by the authentication server to configure
the Tivoli Access Manager runtime. For details about the stanzas contained
in this configuration file, see “Tivoli Access Manager runtime configuration
file” on page 205.
ivacld.conf
The configuration file that is used to configure the Tivoli Access Manager
authorization server. For details about the stanzas contained in this
configuration file, see “Authorization server configuration file” on page
205.
ivmgrd.conf
The configuration file that is used to configure the Tivoli Access Manager
policy server. For details about the stanzas contained in this configuration
file, see “Policy server configuration file” on page 206.
pdmgrproxyd.conf
The configuration file that is used to configure the Tivoli Access Manager
policy proxy server. For details about the stanzas that are contained in this
configuration file, see “Policy proxy server configuration file” on page 206.
ldap.conf
The configuration file that is used by the LDAP-based server to configure
the LDAP-based user registry. For details about the stanzas that are
contained in this configuration file, see “LDAP server configuration file”
on page 207.
activedir_ldap.conf
The configuration file that is used to configure the Active Directory user
registry when it is used on a non-Windows platform. For details about the
stanzas that are contained in this configuration file, see “LDAP client with
Active Directory server configuration file” on page 207.
activedir.conf
The configuration file that is used by the Microsoft Active Directory server
to configure the Active Directory user registry. For details about the stanzas
that are contained in this configuration file, see “Active Directory server
configuration file” on page 207.
domino.conf
The configuration file that is used by the IBM Lotus Domino server to
configure the Domino-based user registry. For details about the stanzas
that are contained in this configuration file, see “Domino server
configuration file” on page 208.
amconf.properties
The configuration file that is used to configure Web Portal Manager. For
© Copyright IBM Corp. 1999, 2010
203
details about the stanzas contained in this configuration file, see “Web
Portal Manager configuration file” on page 208.
pdaudit.server.conf
The configuration file that is used to configure the Common Auditing
Service for each Tivoli Access Manager server or server instance. For
details about the stanzas that are contained in this template file, see
“Common audit service configuration files” on page 208.
The following server-specific configuration files are generated during the
configuration of the Common Auditing Service client:
pdaudit.pdmgr.conf
The configuration file that is used to configure the Common
Auditing Service for the Tivoli Access Manager policy server. Do
not confuse this configuration file with the ivmgrd.conf
configuration file.
pdaudit.pdproxymgr.conf
The configuration file that is used to configure the Common
Auditing Service for a Tivoli Access Manager policy proxy server.
Do not confuse this configuration file with the pdmgrproxyd.conf
configuration file.
pdaudit.pdacld.conf
The configuration file that is used to configure the Common
Auditing Service for the Tivoli Access Manager authorization
server. Do not confuse this configuration file with the ivacld.conf
configuration file.
pdaudit.instance-webseald-host.conf
The configuration file that is used to configure the Common
Auditing Service for a specific instance of a Tivoli Access Manager
WebSEAL server. Do not confuse this configuration file with the
webseald-instance.conf configuration file.
pdaudit.webpi.conf
The configuration file that is used to configure the Common
Auditing Service for a Tivoli Access Manager Plug-in for Web
Servers. Do not confuse this configuration file with the
pdwebpi.conf configuration file.
pdaudit.appsvr.conf
The template configuration file that is used to configure the
Common Auditing Service for any Tivoli Access Manager resource
managers. Do not confuse this configuration file with the
aznAPI.conf configuration file.
aznAPI.conf
A template configuration file that is used to configure any Tivoli Access
Manager resource manager. For details about the stanzas that are contained
in this template file, see “Resource manager configuration files” on page
209.
Location of configuration files
If you did not change the installation directories while installing Tivoli Access
Manager, the configuration files are located in one of the following
platform-specific directories:
204
Administration Guide
Linux and UNIX operating systems
/opt/PolicyDirector/etc
Windows operating systems
c:\program files\tivoli\policy director\etc
If you did not change the installation directories while installing the common audit
service, the templates for the configuration files are located in one of the following
platform-specific directories:
Linux and UNIX operating systems
/opt/PolicyDirector/etc/audit
Windows operating systems
c:\program files\tivoli\policy director\etc\audit
Tivoli Access Manager runtime configuration file
For Tivoli Access Manager servers, you must have the pd.conf configuration file.
Use this configuration file to automate server startup, to indicate whether the
Tivoli Access Manager runtime is configured, and specify information about the
user registry.
Stanza entries for automating server startup are located in the [pdrte] stanza of
the pd.conf configuration file.
This configuration file can include the following stanzas:
v
v
v
v
[meta-info]
[pdrte]
[ssl]
[manager]
The unconfiguration of the server using the pd.conf configuration file also queries
information from this configuration file.
Authorization server configuration file
When you use the Tivoli Access Manager authorization server, you must have the
ivacld.conf server configuration file. Use this configuration file to customize the
operation of each authorization server.
This configuration file can include the following stanzas:
v [meta-info]
v [ivacld]
v [ldap]
v [uraf-registry]
v [ssl]
v
v
v
v
v
v
[manager]
[authentication-mechanisms]
[aznapi-configuration]
[xmladi-attribute-definitions]
[aznapi-entitlement-services]
[aznapi-external-authzn-services]
Appendix B. Configuration file reference
205
v
v
v
v
[aznapi-pac-services]
[aznapi-cred-modification-services]
[aznapi-admin-services]
[configuration-database]
The unconfiguration of the server using the ivacld.conf configuration file also
queries information from this configuration file.
Policy server configuration file
When you use the Tivoli Access Manager policy server, you must have the
ivmgrd.conf server configuration file. Use this configuration file to customize the
operation of each policy server.
This configuration file can include the following stanzas:
v [meta-info]
v [ivmgrd]
v [ldap]
v [uraf-registry]
v [ssl]
v
v
v
v
v
v
[authentication-mechanisms]
[aznapi-configuration]
[xmladi-attribute-definitions]
[aznapi-entitlement-services]
[aznapi-pac-services]
[aznapi-cred-modification-services]
v
v
v
v
v
[aznapi-external-authzn-services]
[delegated-admin]
[configuration-database]
[domains]
[domain=domain_name]
The unconfiguration of the server using the ivmgrd.conf configuration file also
queries information from this configuration file.
Policy proxy server configuration file
When you use the Tivoli Access Manager policy proxy server, you must have the
pdmgrproxyd.conf server configuration file. Use this configuration file to
customize the operation of each policy proxy server.
This configuration file can include the following stanzas:
v [meta-info]
v [pdmgrproxyd]
v
v
v
v
v
206
Administration Guide
[ldap]
[uraf-registry]
[ssl]
[manager]
[authentication-mechanisms]
v
v
v
v
[aznapi-configuration]
[xmladi-attribute-definitions]
[aznapi-admin-services]
[configuration-database]
The unconfiguration of the server using the pdmgrproxyd.conf configuration file
also queries information from this configuration file.
LDAP server configuration file
When you use LDAP as the user registry for Tivoli Access Manager, use the
ldap.conf configuration file to customize the LDAP-based stanza entries.
This configuration file includes the following stanzas:
v [ldap]
v [meta-info]
v [ssl]
Note: The ldap.conf configuration file contains the following stanzas that contain
entries that are for internal use only:
v [ldap-generic-general]
v [ldap-generic-pwd-change-error-map]
v [ldap-generic-acls]
Do not modify any of the values that are defined in these stanzas.
The contents of the [ldap] stanza are different in the activedir.conf and
domino.conf configuration files.
LDAP client with Active Directory server configuration file
When you use an LDAP client to retrieve data for the Active Directory user
registry to which the Tivoli Access Manager policy server is configured, you must
have the activedir_ldap.conf configuration file. Use this configuration file to
customize the operation of each Active Directory user registry.
For example, you might have multiple platforms where the policy server is
configured to use the Active Directory user registry. Other blades, such as
WebSEAL on one platform, and the authorization server are configured to use the
LDAP client to retrieve data from that Active Directory user registry on another
platform.
This configuration file can include the following stanzas:
v [meta-info]
v [uraf-registry]
Active Directory server configuration file
When you use the Microsoft Active Directory server as your user registry for Tivoli
Access Manager, you must have the activedir.conf configuration file. Use this
configuration file to customize the operation of each Active Directory user registry.
Note: Active Directory is supported only on Microsoft Windows for the policy
server.
Appendix B. Configuration file reference
207
This configuration file can include the following stanzas:
v [uraf-registry]
v [meta-info]
v [configuration-database]
The unconfiguration of the server using activedir.conf also queries information
from this configuration file.
Also, you can set values for the [uraf-registry] stanza in the ivmgrd.conf and
ivacld.conf configuration files.
Domino server configuration file
When you use the Lotus Domino server as your user registry for Tivoli Access
Manager, you must have the domino.conf configuration file. Use this configuration
file to customize the operation of each Domino user registry.
This configuration file can include the following stanzas:
v [meta-info]
v [uraf-registry]
v [configuration-database]
The unconfiguration of the server using the domino.conf configuration file also
queries information from this configuration file.
You can set values for the [uraf-registry] stanza in the ivmgrd.conf and
ivacld.conf configuration files.
Web Portal Manager configuration file
When you use Web Portal Manager to perform administrative tasks, you must
have the amconf.properties configuration file. Use this configuration file to specify
customized images, whether the change-password pages are to be displayed, and
the authentication login method to use.
This configuration file includes only the [pdwpm] stanza.
Common audit service configuration files
When you use the common audit service for creating Tivoli Access Manager audit
reports, you must have a server-specific pdaudit.conf configuration file. Use this
configuration file to customize auditing operations for that Tivoli Access Manager
server.
This configuration file can include the following stanza:
v [cars-client]
v [cars-filter]
v [pdaudit-filter]
208
Administration Guide
Resource manager configuration files
Tivoli Access Manager provides a sample file that includes the more common
configuration stanzas needed by resource managers. Your documentation sources,
when implementing your own plug-in or security-enhanced application, include
the IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference
or IBM Tivoli Access Manager for e-business: Authorization Java Classes Developer
Reference.
When creating your own security resource manager or extending the functions
provided by Tivoli Access Manager, you can use the aznAPI.conf configuration file.
This file is included as a sample with the authorization ADK package in the
/example/authzn/demo/cpp subdirectory.
This configuration file can include the following stanzas:
v [aznapi-configuration]
v
v
v
v
v
v
[xmladi-attribute-definitions]
[ssl]
[ldap]
[uraf-registry]
[aznapi-entitlement-services]
[aznapi-pac-services]
v [aznapi-cred-modification-services]
v [aznapi-external-authzn-services]
v [aznapi-admin-services]
v [manager]
v [authentication-mechanisms]
Appendix B. Configuration file reference
209
210
Administration Guide
Appendix C. Configuration file stanza reference
Within configuration files, stanza labels appear within brackets, such as
[stanza-name]. For example, the [ssl] stanza in the ivmgrd.conf configuration file
defines the Secure Sockets Layer (SSL) configuration settings for the policy server.
The [ldap] stanza defines the configuration settings that are required by the policy
server to communicate with an LDAP-based user registry.
Each stanza in a Tivoli Access Manager configuration file contains one or more key
value pairs, which contain information that is expressed as a paired set of
parameters. Each stanza entry is a key-value pair in the following format:
key = value
You should not change the names of the keys in the configuration files. Changing
the name of the key might cause unpredictable results in the servers. Note that
spaces surrounding the equal sign (=) are not required but are recommended.
The initial installation of Tivoli Access Manager establishes many of the default
values. Some values are static and never change; other values can be modified to
customize server functionality and performance.
The following stanza descriptions provide a list of the valid stanza entries. Each
stanza entry consists of key value pairs. Each stanza entry includes a description of
its default behavior, when applicable.
[authentication-mechanisms] stanza
This stanza defines the libraries that are to be used for each form of authentication.
Tivoli Access Manager supports the following authentication forms:
v Password authentication
v Certificate authentication
Resource managers, such as WebSEAL, can support additional forms of
authentication.
The configuration entries in this stanza are required by the server to communicate
with a user registry. The resource manager can use either a User Registry Adapter
Framework (URAF) registry (Active Directory or Domino) or an LDAP registry.
Because a user registry is either a URAF registry or an LDAP registry, certain key
value pairs in the [authentication-mechanisms] stanza are mutually exclusive. The
following example shows how to configure the authentication mechanism for an
LDAP user registry:
passwd-ldap = fully_qualified_path
cert-ldap = fully_qualified_path
#passwd-uraf = fully_qualified_path
#cert-uraf = fully_qualified_path
In this example, the URAF registry items are commented out by using the pound
sign (#) before the stanza entry. The LDAP-oriented stanza entries are not
commented out.
© Copyright IBM Corp. 1999, 2010
211
The stanza entries for configuring the Tivoli Access Manager user registry are
located in the [authentication-mechanism] stanza of the following configuration
files:
v
v
v
v
The ivmgrd.conf configuration file for the policy server
The ivacld.conf configuration file for the authorization server
The pdmgrproxyd.conf configuration file for the policy proxy server
The configuration files for your resource managers
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating the configuration file for resource managers. Developers
of service plug-ins should provide the standard functions. Before implementing
service plug-ins, read and thoroughly understand the concepts discussed in the
IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference.
cert-ldap
Syntax
cert-ldap = fully_qualified_path
Description
Location of the library to use for LDAP certificate authentication.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This stanza entry is required when you use an LDAP user registry.
Comment out this stanza entry when you use a URAF user registry.
You can manually edit these values. No configuration utility is required.
Default value
The following list shows the default, server-dependent values:
AIX
/opt/PolicyDirector/lib/libcertauthn.a
HP-UX
/opt/PolicyDirector/lib/libcertauthn.sl
Linux /opt/PolicyDirector/lib/libcertauthn.so
Solaris
/opt/PolicyDirector/lib/libcertauthn.so
Windows
install_dir\bin\certauthn.dll
Example
Example for Solaris operating environments:
cert-ldap = /opt/PolicyDirector/lib/libcertauthn.so
& -cfgfile [/opt/PolicyDirector/etc/server_name.conf]
212
Administration Guide
cert-uraf
Syntax
cert-uraf = fully_qualified_path
Description
Location of the library to use for URAF certificate authentication.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This stanza entry is required when you use a URAF user registry.
Comment out this stanza entry when you use an LDAP user registry.
You can manually edit these values. No configuration utility is required.
Default value
The following list shows the default, server-dependent values:
AIX
/opt/PolicyDirector/lib/liburafcertauthn.a
HP-UX
/opt/PolicyDirector/lib/liburafcertauthn.sl
Linux /opt/PolicyDirector/lib/liburafcertauthn.so
Solaris
/opt/PolicyDirector/lib/liburafauthn.so
Windows
install_dir\bin\urafcertauthn.dll
Example
Example for Windows operating systems:
cert-ldap = C:\Program Files\Tivoli\Policy Director\bin\certauthn.dll
& -cfgfile [C:/pd/etc/server_name.conf]
passwd-ldap
Syntax
passwd-ldap = fully_qualified_path
Description
Location of the library to use for LDAP password authentication.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
Appendix C. Configuration file stanza reference
213
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This stanza entry is required when you use an LDAP user registry.
Comment out this stanza entry when you use a URAF user registry.
You can manually edit these values. No configuration utility is required.
Default value
The following list shows the default, server-dependent values:
AIX
/opt/PolicyDirector/lib/libldapauthn.a
HP-UX
/opt/PolicyDirector/lib/libldapauthn.sl
Linux /opt/PolicyDirector/lib/libldapauthn.so
Solaris
/opt/PolicyDirector/lib/libldapauthn.so
Windows
install_dir\bin\ldapauthn.dll
Example
Example for Solaris operating environments:
passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so
& -cfgfile [/opt/PolicyDirector/etc/server_name.conf]
passwd-uraf
Syntax
passwd-uraf = fully_qualified_path
Description
Location of the library to use for URAF password authentication.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This stanza entry is required when you use a URAF user registry.
Comment out this stanza entry when you use an LDAP user registry.
You can manually edit these values. No configuration utility is required.
Default value
The following list shows the default, server-dependent values:
214
Administration Guide
AIX
/opt/PolicyDirector/lib/liburafauthn.a
HP-UX
/opt/PolicyDirector/lib/liburafauthn.sl
Linux /opt/PolicyDirector/lib/liburafauthn.so
Solaris
/opt/PolicyDirector/lib/liburafauthn.so
Windows
install_dir\bin\urafauthn.dll
Example
Example for Windows operating systems:
passwd-uraf = c:\program files\tivoli\policy director\bin\urafauthn.dll
& -cfgfile [c:/pd/etc/server_name.conf]
[aznapi-admin-services] stanza
An administration service plug-in enables applications to perform
application-specific administration tasks. The administration service plug-in is
accessed by a calling application using one of the Tivoli Access Manager
administration interfaces.
The calling application can be an administrative utility such as the pdadmin utility
or Web Portal Manager, or the calling application can be a custom-built application
that uses the Tivoli Access Manager administration APIs.
The administration service maps the administration API calls to the corresponding
administration service API calls and carries out the requested action. Each
administration service plug-in is a standalone module that is dynamically loaded
into the authorization service.
The parameters for configuring Tivoli Access Manager administration service
plug-ins are declared in the [aznapi-admin-services] stanza of these configuration
files provided by Tivoli Access Manager:
v The ivmgrd.conf configuration file for the policy server
v The ivacld.conf configuration file for the authorization server
v The pdmgrproxyd.conf configuration file for the policy proxy server
v The configuration files for the configured administration service plug-ins for
your resource managers
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file.
Developers of service plug-ins should provide the standard functions. Before
implementing service plug-ins, read and thoroughly understand the concepts
discussed in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
service-id
Syntax
service-id = {short_name|path_to_dll}
[-pobj protected_object_hierarchy_name ] [& params]
Appendix C. Configuration file stanza reference
215
Description
Defines the authorization API service for functions that enable a plug-in to obtain
the contents of a defined portion of the protected object hierarchy, or to enable a
plug-in to define application-specific administration tasks that also return
commands that perform those tasks.
Each stanza entry defines different types of aznAPI service.
Options
Each entry has the following format.
service-id
Developer-specified ID of the administration service. An authorization API
application can register more than one administration service plug-in, but
each must have a unique service ID.
short_name|path_to_dll
The path to the dynamic link library (DLL) that contains the executable
code for the service executable.
If the DLL is located in a directory that is normally searched by the system
(for example, /usr/lib on Linux and UNIX operating systems or the value
of the PATH environment variable on Windows operating systems), do not
specify the full path to the DLL, specify the DLL name only. If you want a
platform-independent DLL name, so it can be loaded on any supported
platform, provide a short name. The short name is prepended and
appended with known library prefixes and suffixes for each platform, and
each possibility is searched in turn. For example, using a short name of
azn_ent_user, the following names are automatically searched for on each
platform:
AIX
libazn_ent_user.so
libazn_ent_user.a
HP-UX
libazn_ent_user.sl
Linux libazn_ent_user.so
Solaris
libazn_ent_user.so
Windows
azn_ent_user.dll
protected_object_hierarchy_name
Optional: The name of the protected object hierarchy. This option refers
either to the name of a protected object space (hierarchy) or to a protected
object. Protected object hierarchy names must be unique for each
administration service plug-in within the scope of an authorization API
application. To support failover, multiple authorization API application
instances can be registered to service the same protected object hierarchy
names. Failover support allows for the administration of an object space if
a particular authorization API application server fails.
params Optional: The additional initialization arguments that can be passed to the
external authorization service. The arguments must be preceded by the
ampersand (&); for example, & -server fred. The authorization service
does not process the characters after the ampersand. It passes these
characters directly to the administration service plug-in. The service
216
Administration Guide
definition is discussed in more detail in the IBM Tivoli Access Manager for
e-business: Authorization C API Developer Reference.
Usage
Optional
Default value
There is no default value.
Example
AZN_ADMIN_SVC_TRACE = pdtraceadmin
[aznapi-configuration] stanza
Tivoli Access Manager allows a highly flexible approach to authorization through
the use of the authorization API. The standards-based authorization API allows
applications to make calls to the centralized authorization service. Tivoli Access
Manager provides built-in support of user name and password authentication as
well through the authorization API.
The configuration key value pairs that are used for configuring audit files for
Tivoli Access Manager servers are located in the [aznapi-configuration] stanza of
each of the following configuration files:
v The ivmgrd.conf configuration file for the policy server
v The ivacld.conf configuration file for the authorization server
v The pdmgrproxyd.conf configuration file for the policy proxy server
v The configuration files for your resource managers
Other stanza entries that apply to the configuration files of your resource
managers are discussed in the IBM Tivoli Access Manager for e-business:
Authorization C API Developer Reference. Developers should read and thoroughly
understand these concepts so that they can provide the required standard
functions. A sample aznAPI.conf configuration file is provided with Tivoli
Access Manager to use as a guide for creating your own resource manager
configuration file.
audit-attribute
Syntax
audit-attribute = azn-attr
Description
Name of the access decision information (ADI) attribute to audit. An attribute can
establish accountability by providing information to help identify potentially
inappropriate access of assets. You can grant or deny access based on the rules that
are applied to attributes.
For example, the WebSEAL switch-user authentication feature provides a
mechanism to allow certain users to impersonate another user. When switch-user is
used, an authorization request is evaluated against an assumed identity rather than
the actual identity of the user. It is desirable to allow administrators to capture the
user's actual identity.
You can audit the names or descriptions of the Tivoli Access Manager policies
(ACL, POP, and authorization rule) that are applied to the object being accessed.
Appendix C. Configuration file stanza reference
217
Options
azn_attr
The authorization API attribute represents an alphanumeric string that is
not case-sensitive. String values are expected to be characters that are part
of the local code set.
Usage
Optional
Default value
There is no default value.
Example
The following example shows the configuration for WebSEAL:
audit-attribute = tagvalue_su-admin
azn-app-host
Syntax
azn-app-host = other_hostname
Description
Attribute that is used to specify the host name that the policy server should use
when communicating with the resource manager.
Options
For other_hostname, you can provide any valid internet host name. If this attribute
is not specified, the default host name is used. Examples of valid host names:
v mycomputer.city.company.com
v mycomputer
By default, this attribute is disabled. When disabled, the stanza entry is
commented out by using a pound sign (#) at the beginning of the stanza entry. The
following example shows a commented out entry:
#azn-app-host = libra
To enable this value, uncomment the entry by removing the pound sign. Be sure to
include a host name value.
Usage
Optional
Default value
There is no default value.
Example
azn-app-host = libra.dallas.ibm.com
azn-server-name
Syntax
azn-server-name = server–hostname
218
Administration Guide
Description
Unique name of the Tivoli Access Manager resource manager, the policy proxy
server, authorization server, or policy server, that is configured into the domain.
The hyphen (-) character is required.
Note: The host name is generated and set during configuration. Do not edit this
stanza entry.
cache-refresh-interval
Syntax
cache-refresh-interval = {disable|default|number_seconds}
Description
Poll interval (in seconds) between checks for updates to the master policy
database.
Note: The local cache is rebuilt only if an update is detected.
This stanza entry is not used in the ivmgrd.conf file. The policy server has its own
stanza entries for specifying the path to the master policy database.
Options
disable
The interval value in seconds is not set.
default
The default value of 600 seconds is used.
number_seconds
The exact time interval in number of seconds. This valid is between 0 and
the size of an unsigned integer. The unsigned integer is approximately 136
years.
Usage
Optional
Default value
default
Example
cache-refresh-interval = 500
cred-attributes-entitlement-services
Syntax
cred-attributes-entitlement-services =
{short_name_entitlement_service|path_to_dll}
Description
Service that provides the ability to add external information to the user credential
in the form of credential attributes and allows applications to use that information
in making access decisions. These extended attributes are stored in the user
registry.
Appendix C. Configuration file stanza reference
219
This service can also work with attributes using an API call. A list of authorization
API entitlement service IDs are queried by the azn_id_get_creds() interface to
compile a list of attributes to be added to the user credential while the credential is
being built.
A list of service identifiers, which can be found within the [aznapi-entitlementservices] stanza, is queried to compile a list of attributes. The attributes are added
to the user credential while the credential is being built. Each service ID is queried
in the order it is declared in the list. The attribute returned is inserted into the
credential attribute list of each credential that is built. The following example
shows two entries from the credential attribute list:
cred-attribute-entitlement-services = myEntSvcID
cred-attribute-entitlement-services = myOtherEntSvcID
Note: You cannot use this stanza entry to override read-only attributes in the
credential attribute list that include the principal name, principal UUID, and
others. The exception to this rule is for the azn_cred_groups attribute.
The IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference
lists the read-only attributes, contains more information about this service, and
explains why administrators who do not want this capability should ensure that
the azn_mod_rad service is not loaded by the application.
Usage
Optional
Default value
There is no default value.
Example
cred-attribute-entitlement-services = myEntSvcID
db-file
Syntax
db-file = fully_qualified_path
Description
Name and location of the resource manager policy database cache file. This value
must be specified, and each server provides its own value.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Required for each specified server.
Default value
There is no default value.
220
Administration Guide
Example
The following example sets the policy database using an absolute path on a
Windows operating system:
db-file = C:\pd\db\ivacld.db
The following example sets the policy database using a relative path on a Linux or
UNIX operating system:
db-file = ./authzn_demo.db
dynamic-adi-entitlement-services
Syntax
dynamic-adi-entitlement-services = entitlement_service
Description
Dynamic access decision information (ADI) retrieval entitlement service.
Options
entitlement_service
A string value for the container names of the required ADI. A list of
configured authorization API entitlements service identifiers (IDs) is
queried by the authorization rules engine when missing ADI is detected
during an authorization rule evaluation.
When ADI is found to be missing during a rule evaluation, each service in
this list is queried in the order defined in this entry. These stanza entries
must refer to existing entitlements services.
The service ID (for example, bank_A_ADI) are loaded by using service
entries in the entitlement service configuration [aznapi-entitlementservices] stanza or in an initialization attribute.
Refer to “dynamic-adi-entitlement-services” on page 136 and the IBM Tivoli
Access Manager for e-business: Authorization C API Developer Reference for
more information about rules processing and this service, respectively.
Usage
Optional
Default value
There is no default value.
Example
[aznapi-entitlement-services]
dynamic-adi-entitlement-services = bank_A_ADI
dynamic-adi-entitlement-services = bank_B_ADI
input-adi-xml-prolog
Syntax
input-adi-xml-prolog = prolog_attrs
Description
Prolog to be added to the top of the XML document that is created using the
Access Decision Information (ADI) needed to evaluate a Boolean authorization
rule.
Appendix C. Configuration file stanza reference
221
If a style sheet prolog is specified, that prolog is imported into the empty style
sheet. If no prolog is specified, a default prolog value is used instead. All of the
required prolog attributes are specified in the default prolog entries.
Note: If any of these attributes are changed or omitted from the entry, the
authorization client fails to start and returns an error.
Options
prolog_attrs
Prolog attributes that are required by the authorization engine and include
the following attributes:
<?xml version="1.0" encoding="UTF-8"?>
Refer to “input-adi-xml-prolog and xsl-stylesheet-prolog” on page 136 for
more information.
Usage
Optional
Example
input-adi-xml-prolog = <?xml version="1.0" encoding="UTF-8"?>
listen-flags
Syntax
listen-flags = {enable|disable}
Description
Indication of whether to turn on or off the reception of policy cache update
notifications.
Options
enable Activates the notification listener.
disable
Deactivates the notification listener.
Usage
Optional
Default value
disable
Example
listen-flags = enable
logcfg
Syntax
logcfg = audit.azn:[log-agent][[param[=value]] ...]
Description
Enables logging and auditing for the application. Category, destination, and other
parameters are used to capture Tivoli Access Manager auditing and logging events.
222
Administration Guide
Each server provides its own event logging setting in its corresponding
configuration file.
Options
audit.azn:log-agent
Category of auditing event. Also indicates that the destination where
log-agent is one of the following agents:
v stdout
v stderr
v file
v pipe
v remote
param=value
Allowable parameters. The parameters vary, depending on the category,
the destination of events, and the type of auditing you want to perform.
Refer to IBM Tivoli Access Manager for e-business: Troubleshooting Guide for
information about the log agents and the configuration parameters.
Usage
Optional
Default value
Remove the pound signs (#) at the beginning of the configuration file lines to
enable authentication or authorization auditing (or both) for the application.
Example
logcfg = audit.azn:file path=audit.log,flush_interval=20,log_id=audit_log
mode
Syntax
mode = {local|remote}
Description
Operating mode for the resource manager. This value cannot be changed after
resource manager configuration.
Note: This stanza entry is set during configuration. Do not change it.
Options
local
The resource manager uses a local policy cache.
remote
The resource manager uses a remote policy cache that is maintained by the
authorization server.
Some configuration attributes apply only to resource managers that are
configured to use local mode.
Usage
Required
Default value
local
Example
mode = remote
Appendix C. Configuration file stanza reference
223
pd-user-name
Syntax
pd-user-name = server_name/hostname
Description
Tivoli Access Manager user account for the resource manager server, either the
policy proxy server, authorization server, or policy server, that is configured into
the domain. The forward slash (/) character is required.
Note: The server name or host name is generated and set during configuration. Do
not edit this stanza entry.
pd-user-pwd
Syntax
pd-user-pwd = server_password
Description
Tivoli Access Manager user account password for the resource manager, which can
be the policy proxy server, authorization server, or policy server, that is configured
into the domain.
Note: The server password is generated and set during configuration. Do not edit
this stanza entry.
permission-info-returned
Syntax
permission-info-returned = {attribute1 attribute2 ...}
Description
Set of attributes that the caller wants to receive from the
azn_decision_access_allowed_ext() function in the permission information
attribute list. Before using this stanza entry and value, read and thoroughly
understand the concept as it is discussed in the IBM Tivoli Access Manager for
e-business: Authorization C API Developer Reference.
You can also define your own attributes. For example, you can set an attribute on
an ACL using the acl modify command with the set attribute option.
When you add an attribute name to the list, the attribute can be returned only as
permission information if it is applicable to the current decision call.
Options
For a list of the strings recognized by the authorization engine, refer to IBM Tivoli
Access Manager for e-business: Authorization C API Developer Reference.
Usage
Optional
Default value
No information is returned.
224
Administration Guide
Example
The following example returns permission information for all attributes in the list:
permission-info-returned = azn_perminfo_all_attrs
policy-cache-size
Syntax
policy-cache-size = size
Description
Maximum size of the in-memory policy cache. This size is configurable. The cache
consists of policy and the relationships between policy and resources. The
knowledge that a resource has no directly associated policy is also cached.
The maximum cache size should be relative to the number of policy objects
defined and the number of resources protected as well as the available memory.
As a starting point, use the following algorithm:
3 * (number of policy objects + number of protected resources)
This value controls how much information is cached. A larger cache potentially
improves the application performance, but uses additional memory as well.
Options
size
Size is specified as the number of entries.
Usage
Optional
Default value
32768
Example
policy-cache-size = 32768
resource-manager-provided-adi
Syntax
resource-manager-provided-adi = prefix
Description
Prefix that the authorization engine uses to determine the set of missing access
decision information (ADI) provided by the resource manager. To specify more
than one prefix, add multiple stanza entries.
These entries must refer to existing entitlements services that were loaded using
service entries in the [aznapi-entitlement-services] configuration stanza or that
were loaded using an initialization attribute. If an ADI is found to be missing
during a rule evaluation, each service in this list is queried in the order defined.
Options
prefix
A string prefix for its value. For example, if you want to notify the
authorization engine that any ADI beginning with sales_customer_ be
provided by the resource manager application, the stanza entry would be:
Appendix C. Configuration file stanza reference
225
resource-manager-provided-adi = sales_customer_
Refer to “resource-manager-provided-adi” on page 136 for more
information about rule processing.
Usage
Optional
Default value
There is no default value.
Example
The following example shows multiple stanza entries:
resource-manager-provided-adi = sales_item_
resource-manager-provided-adi = sales_customer_
xsl-stylesheet-prolog
Syntax
xsl-stylesheet-prolog = prolog_attrs
Description
The prolog to be added to the top of the XSL stylesheet that is created using the
XSL text that defines a Boolean authorization rule.
If a style sheet prolog is specified, that prolog is imported into the empty style
sheet. If no prolog is specified, a default prolog value is used instead. All of the
required prolog attributes are specified in the default prolog entries.
When not specified, the default XSL stylesheet prolog is:
!<-- Required for XSLT language -->
<?xml version="1.0" encoding=’UTF-8’?>
<xsl:stylesheet xmlns:xsl=
"http://www.w3.org/1999/XSL/Transform" version="1.0">
!<-- Required to constrain output of rule evaluation -->
<xsl:output method="text" omit-xml-declaration="yes"
encoding=’UTF-8’ indent="no" />
!<-- Need this to ensure default text node printing is
off -->
<xsl:template match="text()"></xsl:template>
Note: If any of the required prolog attributes are changed or omitted from the
entry, then the authorization client fails to start and returns an error.
Use caution when changing this setting. Refer to “input-adi-xml-prolog and
xsl-stylesheet-prolog” on page 136 for more information.
Options
prolog_attrs
Prolog attributes that are required by the authorization server.
Usage
Optional
226
Administration Guide
Example
See “Defining an XML namespace” on page 126 for a complete explanation of the
name space example.
[aznapi-cred-modification-services] stanza
A credential modification service plug-in enables authorization API applications to
perform modifications on a Tivoli Access Manager credential. The credentials
modification service can then return this modified credential for use by the calling
application. Applications can use this service to add additional information to a
user's credential. For example, this additional information could include the credit
card number and credit limit of the user. Each credential modification service
plug-in is a standalone module that is dynamically loaded into the authorization
service.
The parameters for configuring Tivoli Access Manager credential modification
service plug-ins are declared in the [aznapi-cred-modification-services] stanza
of each of the configuration files provided with Tivoli Access Manager:
v The ivmgrd.conf configuration file for the policy server
v The ivacld.conf configuration file for the authorization server
v The pdmgrproxyd.conf configuration file for the policy proxy server
v The configuration file for configured credentials modification service plug-ins for
your resource managers
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file.
Developers of service plug-ins should provide the standard functions. Before
implementing service plug-ins, read and thoroughly understand the concepts
discussed in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
service-id
Syntax
service-id = short_name|path_to_dll [ & params ...]
Description
Defines the authorization API service for the credentials attribute list modification
service. Each stanza entry defines different types of aznAPI service.
Options
Each entry has the following format:
service-id
Developer-specified ID of the credential modification service. The service
ID string must be unique.
short_name|path_to_dll
The path to the dynamic link library (DLL) that contains the executable
code for the service.
If the DLL is located in a directory that is normally searched by the system
(for example, /usr/lib on Linux and UNIX operating systems or the value
of the PATH environment variable on Windows operating systems), do not
specify the full path to the DLL, specify only the DLL name. If you want a
platform-independent DLL name, so it can be loaded on any supported
platform, provide a short name. The short name is appended with known
Appendix C. Configuration file stanza reference
227
library prefixes and suffixes for each platform, and each possibility is
searched in turn. For example, using a short name of azn_ent_user, the
following table shows the names that are automatically searched for on
each platform:
AIX
libazn_ent_user.so
libazn_ent_user.a
HP-UX
libazn_ent_user.sl
Linux libazn_ent_user.so
Solaris
libazn_ent_user.so
Windows
azn_ent_user.dll
params Optional: The parameters to pass to the service when it is initialized by the
aznAPI service. Parameters are considered to be all data following the
ampersand (&). The service definition is discussed in more detail in the
IBM Tivoli Access Manager for e-business: Authorization C API Developer
Reference.
Usage
Optional
Default value
There is no default value.
Example
AZN_MOD_SVC_RAD_2AB = azn_mod_rad
[aznapi-entitlement-services] stanza
An entitlement services plug-in enables authorization API applications to retrieve
the entitlements for a user from an entitlements repository. Each entitlement
services plug-in is a standalone module that is dynamically loaded into the
authorization service.
The stanza entries for configuring Tivoli Access Manager entitlement services
plug-ins are declared in the [aznapi-entitlement-services] stanza of each of these
configuration files provided by Tivoli Access Manager:
v The ivmgrd.conf configuration file for the policy server
v The ivacld.conf configuration file for the authorization server
v The pdmgrproxyd.conf configuration file for the policy proxy server
v The configuration file for configured entitlement services plug-ins for your
resource managers
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file.
Developers of service plug-ins should provide the standard functions. Before
implementing service plug-ins, read and thoroughly understand the concepts
discussed in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
228
Administration Guide
service-id
Syntax
service-id = {short_name|path_to_dll} [ & params ...]
Description
Defines the authorization API service for the entitlement services of the protected
objects. Each stanza entry defines different types of aznAPI service.
Options
Each entry has the following format:
service-id
Developer-specified ID by which the service can be identified by the
aznAPI client. The service ID string must be unique.
short_name|path_to_dll
The path to the dynamic link library (DLL) that contains the executable
code for the service.
If the DLL is located in a directory that is normally searched by the system
(for example, /usr/lib on Linux and UNIX operating systems or the value
of the PATH environment variable on Windows operating systems), do not
specify the full path to the DLL, specify only the DLL name. If you want a
platform-independent DLL name, so it can be loaded on any supported
Tivoli Access Manager platform, provide a short form library name. The
short name is appended with known library prefixes and suffixes for each
platform, and each possibility is searched in turn. For example, using a
short form library name of azn_ent_user, the following names that are
automatically searched for on each platform:
AIX
libazn_ent_user.so
libazn_ent_user.a
HP-UX
libazn_ent_user.sl
Linux libazn_ent_user.so
Solaris
libazn_ent_user.so
Windows
azn_ent_user.dll
params Optional: One or more parameters to pass to the service when it is
initialized by the aznAPI service. Parameters are considered to be all data
following the ampersand (&). The service definition is discussed in more
detail in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
Usage
Optional
Default value
There is no default value.
Example
credattrs_ent_svc = azn_ent_cred_attrs
Appendix C. Configuration file stanza reference
229
[aznapi-external-authzn-services] stanza
An external authorization service plug-in is an optional extension of the Tivoli
Access Manager authorization service that allows you to impose additional
authorization controls and conditions. You can use an external authorization
service plug-in to force authorization decisions to be made is based on
application-specific criteria that are not known to the Tivoli Access Manager
authorization service. Each external authorization service plug-in is a standalone
module that is dynamically loaded into the authorization service.
The parameters for configuring Tivoli Access Manager external authorization
service plug-ins are declared in the [aznapi-external-authzn-services] stanza of
this configuration file provided by Tivoli Access Manager:
v The ivmgrd.conf configuration file for the policy server
v The ivacld.conf configuration file for the authorization server
v The configuration file for configured external authorization service plug-ins for
your resource managers
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file.
Developers of service plug-ins should provide the standard functions. Before
implementing service plug-ins, read and thoroughly understand the concepts
discussed in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
policy-trigger
Syntax
policy-trigger = {short_name|path_to_dll} [-weight number]
[ & params ...]
Description
Defines the authorization API service for external authorization service definitions
that force authorization decisions to made based on application-specific criteria.
Each stanza entry defines different types of aznAPI service, and each entry is the
same format.
Options
policy-trigger
The policy trigger is the way that an external authorization service is
invoked. It is either a service ID or an access control list (ACL) action
string. For example, it can be my_service_1 or Trx. If the service is defined
an ID, the service ID is used as an extended attribute on a POP that
triggers the external authorization service when an object has this POP
attached to it. If the service is defined using an ACL action string, the
service is invoked when this ACL action mask is requested as part of an
authorization decision.
The policy trigger can be any string that is recognized as a valid key name.
The policy-trigger is case-sensitive, because the actions themselves are
case-sensitive. However, the policy trigger is not case-sensitive if the
trigger is a POP attribute.
short_name|path_to_dll
The path to the dynamic link library (DLL) that contains the executable
code for the service.
230
Administration Guide
If the DLL is located in a directory that is normally searched by the system
(for example, /usr/lib on Linux and UNIX operating systems or the value
of the PATH environment variable on Windows operating systems), do not
specify the full path to the DLL, specify only the DLL name. If you want a
platform-independent DLL name, so it can be loaded on any supported
platform, provide a short name. The short name is appended with known
library prefixes and suffixes for each platform, and each possibility is
searched in turn. For example, using a short name of azn_ent_user, the
following names that are automatically searched for on each platform:
AIX
libazn_ent_user.so
libazn_ent_user.a
HP-UX
libazn_ent_user.sl
Linux libazn_ent_user.so
Solaris
libazn_ent_user.so
Windows
azn_ent_user.dll
[-weight number]
Optional: A weighting that is assigned in the access decision process to the
particular external authorization service. This option is an unsigned size_t
value. This value signifies the weight that any decision that is returned by
this external authorization service should be given in the entire decision
process. The default value is 101.
params Optional: Additional initialization information to pass to the external
authorization service in the form of arguments. The arguments must be
preceded by the ampersand (&); for example, & -server fred. The service
definition is discussed in more detail in the IBM Tivoli Access Manager for
e-business: Authorization C API Developer Reference.
Usage
Optional
Default value
There is no default value.
[aznapi-pac-services] stanza
A PAC services plug-in gives authorization API applications the ability to move
Tivoli Access Manager credentials back and forth between the native Tivoli Access
Manager credentials format and an alternate format called privilege attribute
certificate (PAC). Each PAC services plug-in is a standalone module that is
dynamically loaded into the authorization service.
Identity information can be obtained from a PAC. Applications can convert user
credentials to PACs for use within other authorization domains. Applications can
then pass the PACs to a server in another authorization domain and perform an
operation.
The stanza entries for configuring Tivoli Access Manager PAC services plug-ins are
declared in the [aznapi-pac-services] stanza of each of these configuration files
provided by Tivoli Access Manager:
Appendix C. Configuration file stanza reference
231
v The configuration file for configured PAC services plug-ins for your resource
managers
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file. Developers
of service plug-ins should provide the standard functions. Before implementing
service plug-ins, read and thoroughly understand the concepts discussed in the
IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference.
service-id
Syntax
service-id = {short_name|path_to_dll}
[ & params ... ]
Description
Defines the authorization API service for the Tivoli Access Manager privilege
attribute certificate (PAC) encoding service. Each stanza entry defines different
types of aznAPI authorization service.
Options
Each entry has the following format:
service-id
Developer-specified ID of the PAC service that produces the PAC. The
service ID string must be unique.
short_name|path_to_dll
The path to the dynamic link library (DLL) that contains the executable
code for the service executable.
If the DLL is located in a directory that is normally searched by the system
(for example, /usr/lib on Linux and UNIX operating systems or the value
of the PATH environment variable on Windows operating systems), do not
specify the full path to the DLL, specify only the DLL name. If you want a
platform-independent DLL name, so it can be loaded on any supported
platform, provide a short name. The short name is appended with known
library prefixes and suffixes for each platform, and each possibility is
searched in turn. For example, using a short form library name of
azn_ent_user, the following names that are automatically searched for on
each platform:
AIX
libazn_ent_user.so
libazn_ent_user.a
HP-UX
libazn_ent_user.sl
Linux libazn_ent_user.so
Solaris
libazn_ent_user.so
Windows
azn_ent_user.dll
params Optional: Parameters to pass to the service when it is initialized by the
aznAPI service. Parameters are considered to be all data following the
ampersand (&). The service definition is discussed in more detail in the
IBM Tivoli Access Manager for e-business: Authorization C API Developer
Reference.
232
Administration Guide
Usage
Optional
Default value
There is no default value.
[cars-client] stanza
The [cars-client] stanza contains the configuration of the client for the common
audit service. The entries in this stanza specify the characteristics of the connection
to the common event Web service and how the client processes audit log events.
You must specify the doAudit and serverURL entries. If these entries are not
specified, the common audit service is not configured for use by Tivoli Access
Manager.
If secure communication with the common event Web service is required, you need
to specify the keyFilePath and stashFilePath entries.
The stanza entry for common audit processing is located in the [pdcars-filter]
stanza of the pdaudit.conf file.
compress
Syntax
compress = {yes|no}
Description
Indicates whether the data that is sent during a network transfer is compressed.
Options
yes
Compresses the data that is sent during a network transfer.
no
Does not compress the data that is sent during a network transfer. This is
the default value.
Usage
Optional
Default value
The default value is no.
Example
compress = yes
diskCachePath
Syntax
diskCachePath = fully_qualified_path
Description
Specifies the name and location of the file to be used to cache events. The file must
exist at the specified location.
When events are written to the disk cache file, a cache manager thread periodically
checks (using the setting of the rebindInterval entry) to determine whether the
Appendix C. Configuration file stanza reference
233
audit Web service can accept events. When the service is available, the cache
manager sends the events from the disk cache file.
The name of the disk cache file must be unique. If more than one server or server
instance is configured to use the same disk cache file, errors will occur.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This entry is used when the useDiskCache entry is set to auto or
always.
Default value
There is no default value.
doAudit
Syntax
doAudit = {yes|no}
Description
An indication of whether auditing using the Common Auditing Service is enabled
or disabled. When auditing is disabled, events are not forwarded to the audit
server.
After configuring the Common Auditing Service, you can start auditing using the
following steps:
1. Enter the following commands:
> pdadmin login -l
pdadmin local> config modify keyvalue set config_file cars-client doAudit yes
2. Restart the server.
To stop auditing, complete the following steps:
1. Enter the following commands:
> pdadmin login -l
pdadmin local> config modify keyvalue set config_file cars-client doAudit no
2. Restart the server.
Options
yes
Enables auditing using the common audit service.
no
Disables auditing for the common audit service. This is the default value.
Usage
Required
234
Administration Guide
Default value
The default value is no.
Example
doAudit = yes
clientPassword
Syntax
clientPassword = password
Description
Specifies the password for the WebSphere audit ID.
Usage
Conditional. This stanza entry is required only when using secure communications
with the Web service.
Default value
There is no default value.
clientUserName
Syntax
clientUserName = user_id
Description
Specifies the WebSphere audit ID used by the administrator. This ID is
authenticated with HTTP basic authentication.
Usage
Conditional. This stanza entry is required only when using secure communications
with the Web service.
Default value
There is no default value.
errorFilePath
Syntax
errorFilePath = fully_qualified_path
Description
Specifies the name and location of the error log file. If the file does not exist at the
specified location, it will be created by the server identity.
The name of the log file must be unique. If more than one server or server instance
is configured to use the same log file, errors will occur.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
Appendix C. Configuration file stanza reference
235
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Optional
Default value
There is no default value.
flushInterval
Syntax
flushInterval = interval
Description
Limits the time an event waits in the queue before being forwarded to the audit
server. When events are generated at a slow rate and the queue does not reach the
high water mark in a timely manner, use this entry to forward the events in the
queue at the designated interval.
Options
interval
Specifies the number of seconds that an event waits in the queue.
Usage
Conditional. This entry is used when the useDiskCache entry is set to auto or
never.
Default value
There is no default value.
Example
flushInterval = 600
keyFilePath
Syntax
keyFilePath = fully_qualified_path
Description
Specifies the SSL key file name and location. Use the SSL key file to handle
certificates that are used to communicate with the common event Web service. The
file extension can be anything, but the extension is usually .kdb.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
236
Administration Guide
Usage
Conditional. This stanza entry is required only when using secure communications
with the Web service.
Default value
There is no default value.
lowWater
Syntax
lowWater = number
Description
Specifies the low water mark for the number of events that can be in the queue
before events are no longer removed from the queue and written to the disk cache
file.
When the audit server is slow and the event queue fills up, events are removed
from the queue and written to the disk cache file until the number of the events is
queue is equal to or less than the low water mark. When this low water mark is
reached, queued events are sent directly to the audit server.
Usage
Conditional. This entry is used when the useDiskCache entry is set to auto.
Default value
The default value is 10.
hiWater
Syntax
hiWater = number
Description
Specifies the high water mark for the number of events that can be in the queue.
When this high water mark is reached, events are sent to the audit server.
Options
number
Indicates the maximum number of events that can be in the queue.
Usage
Optional. This entry is used when the useDiskCache entry is set to auto or never.
Default value
The default value is 20.
Example
hiWater = 30
maxCacheFiles
Syntax
maxCacheFiles = number
Appendix C. Configuration file stanza reference
237
Description
Specifies the maximum number of disk cache files that can be created. Unlike error
log and trace files, disk cache files can be used again.
After all of the events in the disk cache file are sent to the audit Web service, the
cache manager deletes that cache file.
Usage
Conditional. This entry is used when the useDiskCache entry is set to auto or
always.
Default value
The default value is 1000.
maxCacheFileSize
Syntax
maxCacheFileSize = size
Description
Specifies the maximum size in bytes of the disk cache file. When this size is
reached, the cache file rolls over and a new cache file is created. The maximum
size is 1 gigabyte (1,073,741,824 bytes).
Usage
Conditional. This entry is used when the useDiskCache entry is set to auto or
always.
Default value
The default value is 10485760.
maxErrorFiles
Syntax
maxErrorFiles = number
Description
Specifies the maximum number of error log files that can be created before the
oldest log file is used again.
Usage
Optional
Default value
The default value is 2.
maxErrorFileSize
Syntax
maxErrorFileSize = size
Description
Specifies the maximum size in bytes of the error log file. When this size is reached,
the log file rolls over and a new error log file is created. For additional information
about how log files roll over, see the IBM Tivoli Access Manager for e-business:
Administration Guide.
238
Administration Guide
Usage
Optional
Default value
The default value is 1000000.
maxTraceFiles
Syntax
maxTraceFiles = number
Description
Specifies the maximum number of trace files that can be created before the oldest
trace file is used again.
Usage
Optional
Default value
The default value is 2.
maxTraceFileSize
Syntax
maxTraceFileSize = size
Description
Specifies the maximum size in bytes of the trace log file. When this size is reached,
the log file rolls over and a new error log file is created. For additional information
about how log files roll over, see the IBM Tivoli Access Manager for e-business:
Administration Guide.
Usage
Optional
Default value
The default value is 1000000.
numberCMThreads
Syntax
numberCMThreads = number_of_threads
Description
Number of threads to create for the cache manager. These threads read events from
the disk cache files and sends them to the server.
Options
number_of_threads
Represents a numeric value.
Usage
Optional. This entry is used when the useDiskCache entry is set to auto or always.
Default value
The default value is 1.
Appendix C. Configuration file stanza reference
239
Example
numberCMThreads = 2
numberEQThreads
Syntax
numberEQThreads = number_of_threads
Description
Number of threads to create to service the event queue.
Options
number_of_threads
Represents a numeric value.
Usage
Optional. This entry is used when the useDiskCache entry is set to auto or never.
Default value
The default value is 1.
Example
numberEQThreads = 2
numberRetries
Syntax
numberRetries = number
Description
When an error occurs during a network transfer, specifies the number of attempts
to make to send the data.
Usage
Optional
Default value
The default value is 3.
queueSize
Syntax
queueSize = size
Description
Maximum number of audit events that can be queued.
Usage
Optional. This entry is used when the useDiskCache entry is set to auto or never.
Default value
The default value is 50.
240
Administration Guide
rebindInterval
Syntax
rebindInterval = seconds
Description
Specifies that number of seconds that the cache manager waits before attempting
to establish a connection to the audit Web service.
Usage
Conditional. This entry is used when the useDiskCache entry is set to auto or
always.
Default value
The default value is 10.
retryInterval
Syntax
retryInterval = seconds
Description
When an error occurs during a network transfer, specifies the number of seconds
to wait before another attempt is made to send the data.
Usage
Optional
Default value
The default value is 2.
serverURL
Syntax
serverURL = url
Description
Specifies the URL of the common auditing Web service. For secure communication,
use the following URL:
https://hostname:9443/CommonAuditService/service/Emitter
For nonsecure communication, use the following URL:
http://hostname:9080/CommonAuditService/service/Emitter
Options
url
The URL of the common auditing Web service.
Usage
Required
Default value
There is no default value.
Appendix C. Configuration file stanza reference
241
stashFilePath
Syntax
stashFilePath = fully_qualified_path
Description
Specifies the SSL password stash file name and location. The password is used to
protect private keys in the key file. The password might be stored encrypted in the
stash file. The file extension can be anything, but it is usually .sth.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This stanza entry is required only when using secure communications
with the Web service.
Default value
There is no default value.
traceLevel
Syntax
traceLevel = level
Description
Specifies the level of trace events to write to the trace log. The following settings
are valid:
1
Indicates that events resulting from error conditions only are written to the log.
2
Indicates that the following events only are written to the log file:
v Error conditions
v Entry and exit trace points
3
Indicates that events resulting from error conditions and from all trace points
in the code are written to the log.
Usage
Conditional. Required when traceFilePath is defined.
Default value
The default value is 1.
traceFilePath
Syntax
traceFilePath = fully_qualified_path
242
Administration Guide
Description
Specifies the name and location of the trace file. If the file does not exist at the
specified location, it will be created by the server identity.
The name of the trace file must be unique. If more than one server or server
instance is configured to use the same trace file, errors will occur.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Optional
Default value
There is no default value.
transferSize
Syntax
transferSize = size
Description
Number of audit events to send on each network transfer.
Usage
Optional
Default value
The default value is 10.
useDiskCache
Syntax
useDiskCache = {auto|always|never}
Description
Specifies whether to enable disk caching, and, when enabled, indicates how to
handle disk caching.
Options
always Indicates that audit events are always written directly to the disk cache on
the caller thread. There is no event queue.
never
Indicates that audit events are written to the event queue. There is no disk
cache.
auto
Indicates that audit events are written to the event queue except when the
server is down or the event queue is full. Under these conditions, the audit
events are written to disk cache.
Appendix C. Configuration file stanza reference
243
Usage
Optional
Default value
The default value is auto.
[cars-filter] stanza
The stanza entry for common audit filtering of the Tivoli Access Manager runtime
is located in the [cars-filter] stanza of the pdaudit.conf file.
auditevent
Syntax
auditevent = type, [outcome=outcome]
Description
Identifies the events to be captured for auditing. Events can be identified by event
type, application name, and outcome. If an event logged by an application matches
any configured filter entry (auditevent or outcome), it is forwarded to the Common
Auditing Service server.
For each event type to capture, the configuration file must include a separate
stanza entry.
To add event types to the event filter, use the config modify command with the
append option.
To remove event types from the event filter, use the config modify command with
the remove option.
Note: With the auditevent entry, do not use the config modify command with the
set option. Using the set option overwrites the first auditevent entry in the
configuration file.
Options
type
Specifies one of the following event types:
authn
Indicates authentication events. This event type can be used with
all Tivoli Access Manager servers.
authn_creds_modify
Indicates events that modify credentials for users. This event type
can be used with all Tivoli Access Manager servers.
authn_terminate
Indicates termination events. These types of events are the results
of a timeout, an administration terminating a session, or a
user-initiated log out. This event type can be used with all Tivoli
Access Manager servers.
authz
Indicates authorization events. This event type can be used with all
Tivoli Access Manager servers.
mgmt_config
Indicates configuration and other management events for a server.
This event type can be used with the policy server.
244
Administration Guide
mgmt_policy
Indicates events for security policy management, such as the
creation of an ACL. This event type can be used with the policy
server.
mgmt_registry
Indicates events for registry management, such as creating users
and groups, administrator-initiated password changes, and
modifying properties of users and groups. This event type can be
used with the policy server.
mgmt_resource
Indicates events for resource events. This event type can be used
with the policy server.
password_change
Indicates events for user-initiated password changes. This event
type can be used with the policy server, WebSEAL server, or the
plug-in for Web servers.
Administrator-initiated password changes are classified as registry
management events.
resource_access
Indicates events that record all accesses to a resource, such as a file
or HTTP request and response events outside of authorization
events. This event type can be used with the WebSEAL server or
the plug-in for Web servers.
runtime
Indicates runtime events, such as starting and stopping security
servers. Events generated from administrator-initiated tasks
classified as management tasks. This event type can be used with
all Tivoli Access Manager servers. Additionally, this event type can
be used for reporting WebSEAL statistics.
outcome=outcome
Specifies one of the following outcomes:
all
Records all outcomes. This is the default value.
success
Records successful outcomes only.
unsuccessful
Records unsuccessful outcomes only.
unknown
Records outcomes where success could not be determined. This
value applies to authz and resource_access event types only.
Usage
Required.
Default value
There is no default value.
Example
auditevent = authn, outcome=unsuccessful
auditevent = authz, outcome=unknown
Appendix C. Configuration file stanza reference
245
[configuration-database] stanza
The stanza entry defines the name and location of the Tivoli Access Manager
obfuscated password configuration file. Tivoli Access Manager creates a new
configuration file containing all the obfuscated entries. For example, All bind (log
in) passwords are obfuscated and placed in the configuration file. Both the existing
configuration file and the obfuscated configuration file have the same file name,
except that .obf is appended to the file name (for example, ivmgrd.conf.obf).
In addition, Tivoli Access Manager creates the [configuration-database] stanza, as
needed, whenever an obfuscated entry is automatically added to the obfuscated
configuration file. This stanza has a stanza entry that points to the name and
location of the obfuscated configuration file. The [configuration-database] stanza
can be located in every configuration file, including the pd.conf configuration file,
if an obfuscated value is added to the file.
You should never edit the entry in the [configuration-database] stanza. The one
exception might be if the file is to be moved permanently to a different location.
This scenario is the only circumstance where the file name and location should be
modified. Remember that whenever the configuration file is moved to a different
location, you must move the obfuscated file also.
file
Syntax
file = fully_qualified_path
Description
File name and location where the obfuscated configuration file information is
located.
Note: The obfuscated password is generated and set by the configuration utility.
Do not edit this stanza entry.
The name of the obfuscated configuration file is the same name as the related
configuration file name. The file extension can be anything, but the extension is
usually .conf.obf. For example, the obfuscated configuration file for ldap.conf is
ldap.conf.obf.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This stanza entry is required only if, during configuration, passwords
were obfuscated.
246
Administration Guide
Default value
The following table shows the default installation location by platform.
Platform
File name
Linux or UNIX
/opt/PolicyDirector/etc/server_name.conf.obf
Windows
c:\program files\tivoli\policy director\etc\server_name.conf.obf
Example
The following example of setting the location of the obfuscated configuration file
when using Microsoft Active Directory as the user registry on a Windows
operating system:
c:\program files\tivoli\policy director\etc\activedir.conf.obf
[delegated-admin] stanza
The Tivoli Access Manager configuration can require that the user be authorized to
view each group that is returned in the group list. Or, the user can be authorized
to return the list without authorizing first.
For delegated administration, you should use one type of interface throughout the
entire process for optimal results. Use either Web Portal Manager or the pdadmin
utility. This stanza relates only to the pdadmin utility.
The stanza entries for turning on or off the setting for authorization checks for the
delegated management of groups and users are located in the [delegated-admin]
stanza of the following configuration file:
v The ivmgrd.conf configuration file for the policy server
authorize-group-list
Syntax
authorize-group-list = {yes|no}
Description
Indication of whether authorization checks on the group list and group list-dn
commands should be made.
This keyword is provided as a performance feature.
Options
yes
Enables authorization checks.
no
Disables authorization checks.
Usage
Optional
Default value
no
Example
authorize-group-list = yes
Appendix C. Configuration file stanza reference
247
[domains] and [domain=domain_name] stanzas
The [domains] stanza contains a list of domains. Each domain specified under this
stanza must have its own [domain=domain_name] stanza. The following example
shows domains named d and mydomain:
[domains]
domain = d
domain = mydomain
[domain=d]
[domain=mydomain]
The stanza entries for configuring multiple domains are located in the [domains]
and the [domain=domain_name] stanzas of the following configuration file:
v The ivmgrd.conf configuration file for the policy server
allowed-registry-substrings
Syntax
allowed-registry-substrings = dn
Description
Distinguished name (DN) substring that restricts into which registry locations
users can be created in or be imported from.
The DN of the user being created or imported must contain the substring value
specified. The DN substring value restrictions are registry dependent. Most user
registries allow an alphanumeric string that is not case-sensitive. String values are
expected to be characters that are part of the local code set.
You can specify one or more relative DNs to use when creating users. By
specifying one or more substrings, you can restrict creating and importing users
and groups to the relative DNs that are identified by the substrings. For example,
you can specify the DN substring dc=mkt to restrict users who are created or
imported into a domain named Marketing:
As a management domain administrator, complete the following tasks:
1. Manually add the dn value for each domain created, except the Management
(policy server) domain.
2. Notify the domain administrator, after this key value pair is added, to add this
string to the DN option when creating and importing users or groups.
Options
dn
The distinguished name substring
Usage
Optional
Default value
There is no default value.
Example
allowed-registry-substrings = "dc=mkt"
248
Administration Guide
database-path
Syntax
database-path = fully_qualified_path
Description
File name and location of the policy database for the domain listed. The name of
the database is the same as the domain name. The file extension can be anything,
but the extension is usually .db.
Note: Editing this entry is not recommended.
Options
The fully_qualified_path value represents an alphanumeric string. String values are
expected to be characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the local
code set. For Windows operating systems, file names cannot have a backward slash
(\), a colon (:), a question mark (?), or double quotation marks ("). For Linux and
UNIX operating systems, path names and file names are case-sensitive.
Usage
Conditional. This stanza entry is required when the user creates at least one
domain.
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/var/PolicyDirector/db/domain_name.db
Windows
c:\program files\tivoli\policy director\db\domain_name.db
Example
The following example shows the setting of the database path on a Windows
operating system:
d:\programs\ibm\am\db\dname1.db
domain
Syntax
domain = domain_name
Description
Name of the domain that was created.
Options
The domain_name value is an alphanumeric, case-sensitive string. String values are
expected to be characters that are part of the local code set.
Usage
Conditional. This stanza entry is required when the user creates at least one
domain.
Default value
There is no default value.
Appendix C. Configuration file stanza reference
249
Example
domain = mydomain1
[ivacld] stanza
The stanza entries for configuring authorization server-related information are
located in the [ivacld] stanza in the following configuration file:
v The ivacld.conf configuration file for the authorization server
log-file
Syntax
log-file = fully_qualified_path
Description
Location and name of the log file. Messages are redirected from STDOUT and
STDERR and sent to the server log file as defined in the authorization server
routing file (pdacld_routing). The authorization server relies on the routing file to
determine the log file names and path.
At startup of the authorization server, a check is made to see if the routing file
exists. If it exists, the routing file is used and this stanza entry is ignored;
otherwise, this stanza entry is used.
Options
The fully_qualified_path value represents an alphanumeric string. String values are
expected to be characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the local
code set. For Windows operating systems, file names cannot have a backward slash
(\), a colon (:), a question mark (?), or double quotation marks ("). For Linux and
UNIX operating systems, path names and file names are case-sensitive.
During installation of Tivoli Access Manager, if you enabled Tivoli Common
Directory to specify one common directory location for all your base component
log files, the default installation directory is different. For example:
log-file = TCD/HPD/logs
/msg__pdacld_utf8.log
The 3-character identifier used in the example is HPD, which specifies that the log
files are for the Tivoli Access Manager common components.
Usage
Required
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/var/PolicyDirector/log/msg__pdacld_utf8.log
Windows
c:\program files\tivoli\policy director\log\msg__pdacld_utf8.log
Example
The following example sets the log file as Tivoli Common Directory on a Windows
operating system:
250
Administration Guide
log-file = C:\pd\log\msg__pdacld_utf8.log
The following example sets the log file as Tivoli Common Directory on a Linux or
UNIX operating system:
/PolicyDirector/TAMBase/HPD/logs/msg__pdacld_utf8.log
logcfg
Syntax
logcfg = audit.azn:{log-agent} path=path
flush_interval=interval log_id
Description
Enables logging and auditing for the authorization component.
Each server provides its own event logging setting in its corresponding
configuration file.
Options
audit.azn
Category that indicates auditing of the authorization component.
log-agent
Indicates that the destination where log-agent is one of the following
values:
v stdout
v stderr
v file
v pipe
v remote
path = path
Specifies the name and location of the log file that is used for the log-agent.
flush_interval = interval
Specifies the frequency for flushing log file buffers.
log_id
Specifies the identifier for directing events from additional categories to the
same log-agent.
Remove the pound signs (#) at the beginning of the configuration file lines to
enable authentication or authorization auditing (or both) for the application.
Usage
Optional
Default value
There is no default value.
Example
The following example shows the configuration for authentication and
authorization auditing:
logcfg = audit.azn:file path=/var/PolicyDirector/audit/
ivacld.log,flush_interval=20,log_id=PDAclAudit
logcfg = audit.authn:file log_id=PDAclAudit
Appendix C. Configuration file stanza reference
251
permit-unauth-remote-caller
Syntax
permit-unauth-remote-caller= {true|false}
Description
Indication of whether authorization API clients should be authorized by the
authorization server before their requests are processed.
Options
true
Authorization API clients should not be authorized.
Attention: Specifying true exposes the policy database in the domain for
all clients to read, not just those that were properly authorized with
membership in the remote-acl-users group. Depending on the nature of
the policy within the domain security, system planners must consider the
ability for any client to read system-defined policy to be a security
problem.
false
Authorization API clients should be authorized.
Usage
Optional
Default value
false
Example
permit-unauth-remote-caller= false
pid-file
Syntax
pid-file = fully_qualified_path
Description
Location and name of the PID file.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Required
Default value
The following table shows the default value by platform.
252
Platform
File name
Linux or UNIX
/var/PolicyDirector/log/ivacld.pid
Administration Guide
Platform
File name
Windows
c:\progra files\tivoli\policy director\log\ivacld.pid
Example
Example for a Windows operating system:
pid-file = C:\pd\log\ivacld.pid
tcp-req-port
Syntax
tcp-req-port = {0|port}
Description
Transmission Control Protocol (TCP) port on which the server is listening for
requests.
Options
0
Disable the port number.
port
Enable the port number. Use any valid port number. A valid port number
is any positive number that is allowed by TCP/IP and that is not currently
being used by another application. Use the default value, or use a port
over 1000 that is not currently being used.
Usage
Required
Default value
7136
Example
tcp-req-port = 7136
unix-user
Syntax
unix-user = user_name
Description
The Linux or UNIX user account for this server. The server will run as this user
account.
Options
The user_name value represents an alphabetic string for the name associated with
the user account.
Usage
Required
Default value
ivmgr
Example
unix-user = ivmgr
Appendix C. Configuration file stanza reference
253
unix-group
Syntax
unix-group = group_name
Description
The Linux or UNIX group account for this server. The server will run as this
account.
Options
The group_name value represents an alphabetic string for the group associated with
the user account.
Usage
Required
Default value
ivmgr
Example
unix-group = ivmgr
[ivmgrd] stanza
The stanza entries for configuring the policy server and policy database are located
in the [ivmgrd] stanza in this configuration file:
v The ivmgrd.conf configuration file for the policy server
provide-last-login
Syntax
provide-last-login = {yes|true|no|false}
Description
Use the provide-last-login option for reporting information about the last login
instance of a user.
To record the last login information for LDAP based registries, set [ldap]
enable-last-login to yes.
For Microsoft Active Directory registry, Tivoli Access Manager uses the Active
Directory user attribute lastLogonTimestamp to report the last login time of the
user. This attribute is a system attribute and is updated automatically by Active
Directory. Tivoli Access Manager has no control over this attribute except reporting
the value when required. This attribute is not updated every time a user logs in
successfully. When a user logs in successfully, this attribute is only updated if its
current value is older than the current time minus the value of the
msDS-LogonTimeSyncInterval attribute.
Thus the value that Tivoli Access Manager reports for the last login of a user might
not be the exact time that a user last logged in. The reported time might be the
actual last login time minus the configurable value of msDS-LogonTimeSyncInterval.
You can configure the default value of msDS-LogonTimeSyncInterval to suit the end
user domain policy.
254
Administration Guide
To leverage the lastLogonTimestamp attribute, the Active Directory domains must
be at Microsoft Windows 2003 domain functional level. For more information
about lastLogonTimestamp and msDS-LogonTimeSyncInterval, visit the Microsoft
support Web site.
Options
yes|true
Set the provide-last-login option to yes, to let the policy server report the
time of last login of a user.
no|false
Set the provide-last-login option to no, to disable reporting of the last
login information about a user.
provide-last-pwd-change
Syntax
provide-last-pwd-change = {yes|true|no|false}
Description
Use the provide-last-pwd-change option to permit reporting of information about
the last password change instance of a user.
Options
yes|true
Set the provide-last-pwd-change option to yes, to let the policy server
report the last password change instance of a user.
no|false
Set the provide-last-pwd-change option to no, to disable reporting of the
last password change instance of a user.
auto-database-update-notify
Syntax
auto-database-update-notify = {yes|true|no|false}
Description
Indication of automatic or manual update notification for policy database replicas.
Options
yes|true
Enable automatic update notification. This automatic setting is appropriate
for environments where database changes are few and infrequent. When
you configure update notification to be automatic, you must also correctly
configure the max-notifier-threads= and notifier-wait-time= stanza
entries.
no|false
Enable manual update notification.
Usage
Required
Default value
yes
Appendix C. Configuration file stanza reference
255
Example
auto-database-update-notify = yes
ca-cert-download-enabled
Syntax
ca-cert-download-enabled = {yes|no}
Description
The policy server always allows the download of the CA certificate. It is up to the
client application to allow whether the CA certificate can be downloaded.
Independent of the defined value, the policy server ignores this configuration
setting.
Usage
Ignored
database-path
Syntax
database-path = fully_qualified_path
Description
Location and name of the master policy database. The file extension can be
anything, but the extension is usually .db.
Note: Editing this stanza entry is not recommended.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Required
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/var/PolicyDirector/db/master_authzn.db
Windows
c:\program files\tivoli\policy director\db\master_authzn.db
Example
The following example set the path to the master policy database on a Windows
operating system:
database-path = C:\pd\db\master_authzn.db
256
Administration Guide
log-file
Syntax
log-file = fully_qualified_path
Description
Location and name of the log file. Messages are redirected from STDOUT and
STDERR and sent to the server log file as defined in the policy server routing file
(pdmgrd_routing). The policy server relies on the routing file to determine the log
file names and path.
At startup of the policy server, a check is made to see if the routing file exists. If it
exists, the routing file is used and this stanza entry is ignored; otherwise, this
stanza entry is used.
Options
The fully_qualified_path value represents an alphanumeric string. String values are
expected to be characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the local
code set. For Windows operating systems, file names cannot have a backward slash
(\), a colon (:), a question mark (?), or double quotation marks ("). For Linux and
UNIX operating systems, path names and file names are case-sensitive.
Usage
Required
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/var/PolicyDirector/log/msg__pdmgrd_utf8.log
Windows
c:\program files\tivoli\policy director\log\msg__pdmgrd_utf8.log
During installation of Tivoli Access Manager, if you enabled Tivoli Common
Directory to specify one common directory location for all your log files, the
default installation directory is different.
Example
The following example sets the log file on a Windows operating system without
Tivoli Common Directory:
log-file = C:\pd\log\msg__pdmgrd_utf8.log
The following example sets the log file on a Linux or UNIX operating system with
Tivoli Common Directory:
log-file = TCD_directory/HPD/logs/msg__pdmgrd_utf8.log
The 3-character identifier used in the example is HPD, which specifies that the log
files are for Tivoli Access Manager.
logcfg
Syntax
logcfg = audit.azn:{log-agent} path=path
flush_interval=interval log_id
Appendix C. Configuration file stanza reference
257
Description
Enables logging and auditing for the application. Category, destination, and other
parameters are used to capture Tivoli Access Manager auditing and logging events.
Each server provides its own event logging setting in its corresponding
configuration file.
Options
audit.azn
Category that indicates auditing of the authorization component.
log-agent
Indicates that the destination where log-agent is one of the following
values:
v stdout
v stderr
v file
v pipe
v remote
path = path
Specifies the name and location of the log file that is used for the log-agent.
flush_interval = interval
Specifies the frequency for flushing log file buffers.
log_id
Specifies the identifier for directing events from additional categories to the
same log-agent.
Remove the pound signs (#) at the beginning of the configuration file lines to
enable authentication or authorization auditing (or both) for the application.
Usage
Optional
Default value
There is no default value.
Example
The following example sets the configuration for authentication and authorization
auditing only :
logcfg = audit.azn:file path=/var/PolicyDirector/audit/
pdmgrd.log,flush_interval=20,log_id=PDMgrAudit
logcfg = audit.authn:file log_id=PDMgrAudit
#logcfg = audit.mgmt:file log_id=PDMgrAudit
max-notifier-threads
Syntax
max-notifier-threads = number_threads
Description
Maximum number of event notifier threads. The policy server is responsible for
synchronizing all database replicas in the secure domain. When a change is made
to the master database, notification threads do the work of announcing this change
to all replicas. Each replica then has the responsibility to download the new
information from the master.
258
Administration Guide
When the update notification stanza entry is set to yes, you must correctly
configure this stanza entry and also the notifier-wait-time= stanza entry.
Options
number_threads
Generally, this value should be set to equal the number of existing replicas.
Specify a valid, positive whole number. Valid range for the number of
threads is between 1 and 128.
Usage
Conditional. This stanza entry is required when auto-database-update-notify =
yes.
Default value
10
Example
max-notifier-threads = 20
notifier-wait-time
Syntax
notifier-wait-time = time_seconds
Description
Time in seconds that the authorization policy database is idle before notification is
sent to replicas. When the policy server is instructed to make a change to the
master policy database, it waits for a default period of time before sending out
notifications to database replicas. This time delay is reset with each subsequent
change to the database.
When the update notification stanza entry is set to yes, you must correctly
configure this stanza entry and also the max-notifier-threads= stanza entry.
Options
time_seconds
The number of seconds the authorization policy database is idle before
notification is sent to replicas.
Usage
Conditional. This stanza entry is required when the auto-database-update-notify
= yes.
Default value
15
Example
notifier-wait-time = 30
pid-file
Syntax
pid-file = fully_qualified_path
Description
Location and name of the PID file.
Appendix C. Configuration file stanza reference
259
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Required
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/var/PolicyDirector/log/ivmgrd.pid
Windows
c:\program files\tivoli\policy director\log\ivmgrd.pid
Example
Example for a Linux or UNIX operating system:
pid-file = /var/PolicyDirector/log/ivmgrd.pid
standby
Syntax
standby = {0|number}
Description
Number of standby policy servers
Note: The number of standby servers is generated and set by the configuration
utility. Do not edit this stanza entry.
Options
0
Zero indicates that no policy servers are standby servers.
number
The number of standby policy servers. Use a number that is a positive
whole number. Currently, this number is only 1.
Usage
Required
Default value
0
Example
standby = 1
260
Administration Guide
tcp-req-port
Syntax
tcp-req-port = {0|port}
Description
TCP port on which the server is listening for requests.
Options
0
Disables the port number.
port
Enables the port number. Specify any valid port number. A valid port
number is any positive number that is allowed by TCP/IP and that is not
currently being used by another application. Use the default port number,
or use a port number over 1000 that is currently not being used.
Usage
Required
Default value
8135
Example
tcp-req-port = 8135
unix-user
Syntax
unix-user = user_name
Description
The Linux or UNIX user account for this server. The server will run as this
account.
Options
user_name
Represents an alphabetic string for the name associated with the user
account.
Usage
Required
Default value
ivmgr
Example
unix-user = ivmgr
unix-group
Syntax
unix-group = group_name
Description
The Linux or UNIX group account for this server. The server will run as this
account.
Appendix C. Configuration file stanza reference
261
Options
group_name
Represents an alphabetic string for the group associated with the user
account.
Usage
Required
Default value
ivmgr
Example
unix-group = ivmgr
[ldap] stanza
This stanza defines configuration key value pairs that are required for the Tivoli
Access Manager servers to communicate with the server that is associated with an
LDAP user registry.
The value for the user registry stanza entry (ldap-server-config) is determined by
the pd.conf file. The pd.conf file is created when the Tivoli Access Manager
runtime component is configured.
The key value pairs that are used only for the LDAP registry server are located in
the ldap.conf configuration file in the [ldap] stanza. The LDAP server stanza
entries are described separately in “[ldap] stanza for ldap.conf” on page 278.
The key value pairs that are for the server configuration files are located in the
[ldap] stanza of each of the following configuration files:
v The ivmgrd.conf configuration file for the policy server
v The ivacld.conf configuration file for the authorization server
v The pdmgrproxyd.conf configuration file for the policy proxy server
v Your resource managers' configuration file for configured LDAP entries
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file.
Developers of service plug-ins should provide the standard functions. Before
implementing service plug-ins, read and thoroughly understand the concepts
discussed in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
enhanced-pwd-policy
Syntax
enhanced-pwd-policy = {yes|true|no|false}
Description
The LDAP registries Tivoli Access Manager uses provide password policy
enforcement for LDAP accounts. Tivoli Access Manager uses LDAP account
passwords for authentication. So Tivoli Access Manager is subject to LDAP registry
password policies. When the enhanced-pwd-policy option is enabled, Tivoli Access
Manager efficiently identifies the underlying LDAP registry password policy and
reacts appropriately. The Tivoli Access Manager password policy is enforced
concurrently and is not affected by the enhanced-pwd-policy option.
262
Administration Guide
This option is supported for Sun Directory Server 6.3.1 and Tivoli Directory Server.
For Tivoli Directory Server, Tivoli Access Manager versions older than 6.1.1
provide limited support for handling LDAP registry password policies. The
enhanced-pwd-policy option enhances such support.
When you set the auth-using-compare option to no, a user password is
authenticated by creating a connection to the LDAP registry and binding the
connection using the user password. Success or failure of the binding is noted and
the connection is closed. If you set the enhanced-pwd-policy option is set to yes
when auth-using-compare is set to no, the user password changes occur on the
connection used to authenticate the user.
Such behavior increases the duration of the connection and might cause the
number of simultaneous instances to increase. If the increase in simultaneous
connections is not acceptable, use the max-auth-connections option to limit the
number of simultaneous connections. For detailed information about the
max-auth-connections option, see the max-auth-connections section.
Note: Only Tivoli Directory Server supports enabling of the auth-using-compare
option. For other LDAP servers, Tivoli Access Manager considers this option
disabled.
Tivoli Access Manager WebSEAL 6.1.1 takes advantage of enhanced-pwd-policy.
The password policies and account states supported by Tivoli Access Manager are:
v Password reset
v
v
v
v
Locked accounts
Expired accounts
Grace login for expired accounts
Accounts whose passwords are going to expire
Options
yes|true
When the enhanced-pwd-policy option is set to true, Tivoli Access
Manager efficiently identifies the underlying LDAP registry password
policy and reacts appropriately.
no|false
When the enhanced-pwd-policy option is set to false, the behavior of
Tivoli Access Manager towards LDAP registry password policy
enforcement remains unchanged.
Default value
The default value of enhanced-pwd-policy is no|false
Example
An example of this feature is: LDAP reports that an account is expired and allows
grace login. The user is informed that the account is expired, and is provided a
grace login page and an option to change the password.
Using enhanced-pwd-policy with Tivoli Directory Server: If you enable
enhanced-pwd-policy for the Tivoli Directory Server when using Tivoli Directory
Server for the registry, you must:
v Manually update the access control lists (ACL) of the server so that users can
change their passwords.
Appendix C. Configuration file stanza reference
263
v Set auth-using-compare to no in each configuration file where you set
enhanced-pwd-policy to yes.
Complete the following steps to update LDAP access control lists:
v To ensure that users can change their passwords, suffixes that contain or will
contain Tivoli Access Manager user accounts must have an LDAP ACL that
permits users to change their passwords.
An example of the suffix that you create is o=ibm,c=us. An example of a suffix
that Tivoli Access Manager creates is secAuthority=Default. Each of these
suffixes requires an LDAP ACL to let the users change their passwords.
1. For the suffix that you created, create a file, for example, addacl1.ldif, that
contains the following:
dn:o=ibm,c=us
changetype:modify
add:aclEntry
aclEntry:access-id:cn=this:at.userPassword:rwsc
2. Run the command:
idsldapmodify -D "cn=root" -w "password"
-h your.ldap.host.name -f "addacl1.ldif"
Behavior of Tivoli Access Manager policy server LDAP accounts and policies: The
pwdMustChange option in the LDAP policy prevents the policy server from starting
during configuration.
The account used for configuration does not exist before the configuration starts.
So you cannot set a policy to override the global policy. To create Tivoli Access
Manager LDAP server accounts, you might have to temporarily disable the global
policies before configuration.
After you configure the Tivoli Access Manager server LDAP accounts and the
policy server, set a policy for each Tivoli Access Manager server LDAP account to
overrides any global policy that affects the use of the LDAP account.
max-auth-connections
Syntax
max-auth-connections = {0|unlimited number of simultaneous connections used for user
authentication|any number higher than 0|actual number of simultaneous
connections used for user authentication}
Description
Use the max-auth-connections option to determine how many simultaneous
connections to your LDAP server are permitted for user authentication. This option
has no effect if auth-using-compare is enabled. The benefit of the
max-auth-connections option is greater if enhanced-pwd-policy is enabled. See
enhanced-pwd-policy for details.
Options
0|unlimited number of simultaneous connections used for user
authentication
When you set max-auth-connections to 0 (zero), you can use unlimited
LDAP server connections simultaneously to authenticate users.
264
Administration Guide
any number higher than 0|actual number of simultaneous connections used for
user authentication
If you set max-auth-connections to a value greater than 0 (zero), the
number of simultaneous connections used for user authentication is limited
to the number you specify.
Default value
By default, max-auth-connections is set to 0 (zero.)
enable-last-login
Syntax
enable-last-login = {yes|true|no|false}
Description
For LDAP-based registries, each Tivoli Access Manager server that provides a login
service requires you to set the enable-last-login option to store the last login date
of a user in LDAP. Examples of such servers are:
v WebSEAL.
v Policy Server.
v Authorization Server.
v Local-mode authorization and Java Authorization applications that allow user
authentication directly to the registry.
Options
yes|true
Set the value of the enable-last-login option to yes if you want last the
login information of users to be recorded and displayed to users.
no|false
Set the value of the enable-last-login option to no if you do not want the
last login information of users to be recorded and displayed to users.
auth-using-compare
Syntax
auth-using-compare = {yes|true|no|false}
Description
Choice of whether ldap_compare() is used instead of the ldap_bind() call to verify
the password and authenticate the user. For those LDAP servers that allow it, a
compare operation might perform faster than a bind operation. The value for each
server can be different, depending on how that server is configured.
This option changes the method used by the following authorization API calls:
v azn_util_client_authenticate()
v azn_util_password_authenticate()
Options
yes|true
A compare operation is used to authenticate LDAP users.
no|false
A bind operation is used to authenticate LDAP users.
Appendix C. Configuration file stanza reference
265
Any value other than yes|true, including a blank value, is interpreted as
no|false.
For information on how to use this key value pair for performance tuning, see the
IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
Usage
Optional
Default value
The default values are server-dependent.
Example
auth-using-compare = yes
authn-timeout
Syntax
authn-timeout = {0|number_seconds}
Description
Amount of time (in seconds) that is allowed for authentication operations before
the LDAP server is considered to be down. If specified, this value overrides any
value set for the timeout entry for authentication operations.
Note: Do not specify this stanza entry in the ldap.conf server configuration file.
Options
0
No timeout (synchronous).
number_seconds
The number of seconds allowed for authentication operations. Specify a
positive whole number. There is no range limitation for timeout values.
Usage
Optional
Default value
0
Example
authn-timeout = 0
bind-dn
Syntax
bind-dn = LDAP_dn
Description
LDAP user distinguished name (DN) that is used when binding (signing on) to the
LDAP server. The LDAP_dn value is created, based on the server name that was
specified with the –n server_name option and the local host of the machine.
Use the svrsslcfg utility to set the LDAP_dn value.
266
Administration Guide
For information on how to use this key value pair for performance tuning, see the
IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
Options
LDAP_dn
Distinguished name that is used to bind to the LDAP server
Usage
Conditional. This stanza entry is required when using an LDAP user registry.
Default value
The default value is server-dependent.
Example
The following example sets the distinguished name for the policy server:
bind-dn = cn=ivmgrd/master,cn=SecurityDaemons,secAuthority=Default
cache-enabled
Syntax
cache-enabled = {yes|true|no|false}
Description
Indication of whether LDAP client-side caching is used to improve performance for
similar LDAP queries.
Options
yes|true
Enables LDAP client-side caching.
no|false
Disables LDAP client-side caching. This value is the default value.
Anything other than yes|true, including a blank value, is interpreted as
no|false.
For information on how to use this key value pair for performance tuning, see the
IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
Usage
Optional
Default value
no
Example
cache-enabled = no
cache-group-expire-time
Syntax
cache-group-expire-time = number_seconds
Description
Amount of time (in seconds) until a group entry in the cache is considered stale
and is discarded. This stanza entry is ignored if the cache is not enabled.
Appendix C. Configuration file stanza reference
267
Options
number_seconds
The amount of time specified in seconds. Specify a positive whole number.
Usage
Optional
Default value
300 (5 minutes)
Example
cache-group-expire-time = 600
cache-group-membership
Syntax
cache-group-membership = {yes|true|no|false}
Description
Indication of whether group membership information is cached. This stanza entry
is ignored if the cache is not enabled.
Options
yes|true
Group membership is cached.
no|false
Group membership is not cached. Anything other than yes|true, including
a blank value, is interpreted as no|false.
Usage
Optional
Default value
yes|true
Example
cache-group-membership = no
cache-group-size
Syntax
cache-group-size = group_entries
Description
Number of entries in the LDAP group cache. This stanza entry is ignored if the
cache is not enabled.
Options
group_entries
A positive whole number that represents the number of entries is the
LDAP group cache.
Usage
Optional
268
Administration Guide
Default value
64
Example
cache-group-size = 100
cache-policy-expire-time
Syntax
cache-policy-expire-time = number_seconds
Description
Amount of time in seconds until a policy entry in the cache is considered stale and
is discarded. This stanza entry is ignored if the cache is not enabled.
Options
number_seconds
The amount of time specified in number of seconds. Specify a positive
whole number.
Usage
Optional
Default value
30
Example
cache-policy-expire-time = 60
cache-policy-size
Syntax
cache-policy-size = policy_entries
Description
Number of entries in the LDAP policy cache. This stanza entry is ignored if the
cache is not enabled.
Options
policy_entries
A positive whole number that represents the number of entries is the
LDAP policy cache.
Usage
Optional
Default value
20
Example
cache-policy-size = 50
Appendix C. Configuration file stanza reference
269
cache-return-registry-id
Syntax
cache-return-registry-id = {yes|no}
Description
Indicates whether the LDAP cache returns the TAM user identity as it is stored in
the registry or the value entered by the user.
Note: Refer to Appendix A, “Guidelines for changing configuring files,” on page
199 for guidelines on changing configuration file properties.
Options
yes
Return the TAM user identity as it is stored in the registry. This option
returns the user identity exactly as it was created and preserved in the
registry.
no
Return the TAM user identity as the value is entered by the user.
Usage
Optional
Default value
no
Example
cache-return-registry-id = no
cache-use-user-cache
Syntax
cache-use-user-cache = {yes|true|no|false}
Description
Indication of whether to use the user cache information. This stanza entry is
ignored if the cache is not enabled.
Options
yes|true
Use user information from the cache.
no|false
Do not use user information from the cache. Anything other than yes|true,
including a blank value, is interpreted as no|false.
Usage
Optional
Default value
yes|true
Example
cache-use-user-cache = no
270
Administration Guide
cache-user-expire-time
Syntax
cache-user-expire-time = number_seconds
Description
Amount of time in seconds until a user entry in the cache is considered stale and
is discarded. This stanza entry is ignored if the cache is not enabled.
Options
number_seconds
The amount of time specified in number of seconds. Use a number that is
a positive whole number.
Usage
Optional
Default value
30
Example
cache-user-expire-time = 120
cache-user-size
Syntax
cache-user-size = user_entries
Description
Number of entries in the LDAP user cache. This stanza entry is Ignored if the
cache is not enabled.
Options
user_entries
A positive whole number that represents the number of entries is the
LDAP user cache.
Usage
Optional
Default value
256
Example
cache-user-size = 1000
default-policy-override-support
Syntax
default-policy-override-support = {yes|true|no|false}
Description
Indication of whether user-level policy support is allowed.
Appendix C. Configuration file stanza reference
271
Options
yes|true
User policy support is disabled, and only the global (default) policy is
checked. This option allows the user policy to not be checked, even if it is
specified.
no|false
User policy support is enabled. When a user policy is specified by the
administrator, it overrides the global policy. If no value is specified,
default-policy-override-support = no becomes the value.
For information on how to use this key value pair for performance tuning, see the
IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
Usage
Optional
Default value
no
Example
default-policy-override-support = yes
ldap-server-config
Syntax
ldap-server-config = fully_qualified_path
Description
Location of the ldap.conf configuration file.
Note: When the ldap-server-config entry is specified in the configuration file, the
values for enabled, host, port, max-search-size, and replica are obtained
from the ldap.conf file. If any of these entries exist in the configuration file,
their values are overridden by the values from the ldap.conf file.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
This stanza entry is required for ivmgrd.conf.
Default value
The following table shows the default value by platform.
272
Platform
File name
Linux or UNIX
/opt/PolicyDirector/etc/ldap.conf
Windows
c:\program files\tivoli\policydirector\etc\ldap.conf
Administration Guide
Example
The following example set the location of the LDAP server for a Linux or UNIX
operating system:
ldap-server-config = /opt/PolicyDirector/etc/ldap.conf
login-failures-persistent
Syntax
login-failures-persistent = {yes|no}
Description
Indicates whether the tracking of login failures is persistent (maintained in the
registry) or done in the local process cache.
Options
yes
Tracking of failures is maintained in the registry.
no
Tracking of failures is done in the local process cache.
Usage
Optional
Default value
no
Example
login-failures-presistent = yes
max-search-size
Syntax
max-search-size = [0|number_entries]
Description
Limit for the maximum search size, specified as the number of entries, that can be
returned from the LDAP server. The value for each server can be different,
depending on how the server was configured.
Options
0
The number is unlimited. There is no limit to the maximum search size.
number_entries
The maximum number of entries for search, specified as an integer whole
number. This value can also be limited by the LDAP server itself.
Usage
Optional
Default value
The default value is server-dependent, but defaults to 2048 if not configured.
Example
max-search-size = 2048
Appendix C. Configuration file stanza reference
273
port
Syntax
port = port
Description
Non-SSL IP port number that is used for communicating with the LDAP server.
Options
port
The port number configured for the LDAP server.
Usage
Required for the policy proxy server and authorization server; not required for the
policy server.
Default value
389
Example
port = 389
prefer-readwrite-server
Syntax
prefer-readwrite-server = {yes|true|no|false}
Description
Indication of whether the client can question the Read/Write LDAP server before
querying any replica Read-only servers that are configured in the domain.
The default value can be different. For example, the default value for ivmgrd.conf
is yes while the default value for ivacld.conf is no.
Options
yes|true
Enables the client to be able to question the Read/Write LDAP server.
no|false
Disables the client. Anything other than yes|true, including a blank value,
is interpreted as no|false.
Usage
Optional
Default value
There is no default value. The default value is server dependent.
Example
prefer-readwrite-server = no
search-timeout
Syntax
search-timeout = {0|number_seconds}
274
Administration Guide
Description
Amount of time in seconds that is allowed for search operations before the LDAP
server is considered to be down. If specified, this value overrides any value that is
set for the timeout entry for search operations.
Note: Do not specify this stanza entry in the ldap.conf server configuration file.
Options
0
No timeout (synchronous).
number_seconds
The number of seconds allowed for search operations. Specify a positive
whole number. There is no range limitation for timeout values.
Usage
Optional
Default value
0
Example
search-timeout = 0
ssl-enabled
Syntax
ssl-enabled = {yes|true|no|false}
Description
Indication of whether the Tivoli Access Manager server uses SSL to communicate
with the LDAP server. The value for each Tivoli Access Manager server can be
different, depending on how that server was configured. If this value is set to yes
and Federal Information Processing Standards (FIPS) mode is enabled
(ssl-enable-fips=yes), LDAP is told to use whatever secure communication
protocol it chooses for FIPS enablement.
If you specify that the authorization API (aznAPI) should use SSL to communicate
with the LDAP server, you must enable SSL using this stanza entry.
If you enable SSL communication, you must specify an SSL key file name and, if
there are multiple keys in the file, the key file DN.
Options
yes|true
Enables SSL communication.
no|false
Disables SSL communication. Anything other than yes or true, including a
blank value, is interpreted as no or false.
Usage
Required to enable SSL communication. When ssl-enabled = yes, the LdapSSL
entry in the ldap.conf file must be set to useSSL.
Default value
There is no default value. The default values are server-dependent.
Appendix C. Configuration file stanza reference
275
Example
ssl-enabled = yes
ssl-keyfile
Syntax
ssl-keyfile = ldap-ssl-key-filename
Description
SSL key file name and location. Use the SSL key file to handle certificates that are
used in LDAP communication. The file extension can be anything, but the
extension is usually .kdb.
The certificate files in a directory need to be accessible to the server user (or all
users). Make sure that server user (for example, ivmgr) or all users have permission
to access the .kdb file and the folder that contains the .kdb file.
Options
ldap-ssl-key-filename
A valid file name is an alphanumeric string that is not case-sensitive. String
values are expected to be characters that are part of the local code set. For
Windows operating systems, file names cannot have a backward slash (\),
a colon (:), a question mark (?), or double quotation marks. For Linux and
UNIX operating systems, path names and file names are case-sensitive.
Usage
Conditional. This stanza entry is required only when the LDAP server is
configured to perform client authentication (ssl-enabled = yes).
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/opt/PolicyDirector/keytab/server_name.kdb
Windows
c:\program files\tivoli\policy director\keytab\server_name.kdb
Example
The following example sets the SSL key file for a UNIX policy server:
ssl-keyfile = /ldap52kdb/a17jsun.kdb
ssl-keyfile-dn
Syntax
ssl-keyfile-dn = ldap-ssl-keyfile-label
Description
Key label of the client certificate within the SSL key file.
Options
ldap-ssl-keyfile-label
Identifies the client certificate that is presented to the LDAP server.
276
Administration Guide
Usage
Conditional. This stanza entry is required only when the LDAP server is
configured to perform client authentication.
Default value
If the default policy server key database is being used, the default client certificate
value is PDLDAP.
Example
ssl-keyfile-dn = "PDLDAP"
ssl-keyfile-pwd
Syntax
ssl-keyfile-pwd = ldap-ssl-keyfile-password
Description
Deprecated: The ssl-keyfile-pwd entry is deprecated in the [ldap] stanza.
Although this entry might exist in a configuration file, it will be ignored.
user-and-group-in-same-suffix
Syntax
user-and-group-in-same-suffix = {yes|true|no|false}
Description
Indication of whether the groups, in which a user is a member, are defined in the
same LDAP suffix as the user definition.
When a user is authenticated, the groups in which the user is a member must be
determined in order to build a credential. Normally, all LDAP suffixes are searched
to locate the groups of which the user is a member.
Options
yes|true
The groups that are assumed to be defined in the same LDAP suffix as the
user definition. Only that suffix is searched for group membership. This
behavior can improve the performance of group lookup, because only a
single suffix is searched. Use this option only if group definitions are
restricted to the same suffix as user definitions.
no|false
The groups might be defined in any LDAP suffix. Anything other than
yes|true, including a blank value, is interpreted as no|false.
For information on how to use this key value pair for performance tuning
purposes, see the IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
Usage
Optional
Default value
no
Example
user-and-group-in-same-suffix = yes
Appendix C. Configuration file stanza reference
277
[ldap] stanza for ldap.conf
This stanza defines the configuration key value pairs that are required for the
LDAP server. For example, you can find the configuration keys and values for
LDAP failover, including the use of master server and replica servers, in this
stanza.
The user registry type value is determined by the pd.conf file. The pd.conf file is
created when the Tivoli Access Manager runtime is configured.
For information on how to use the key value pairs in this stanza for performance
tuning, see the IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
cache-enabled
Syntax
cache-enabled = {yes|true|no|false}
Description
Indication of whether LDAP client-side caching is used to improve performance for
similar LDAP queries.
Options
yes|true
Enables LDAP client-side caching.
no|false
Disables LDAP client-side caching. This value is the default value.
Anything other than yes|true, including a blank value, is interpreted as
no|false.
For information on how to use this key value pair for performance tuning
purposes, see the IBM Tivoli Access Manager for e-business: Performance Tuning Guide.
Usage
Optional
Default value
no
Example
cache-enabled = no
connection-inactivity
Syntax
connection-inactivity = number_seconds
Description
Specifies the number of seconds of inactivity allowed on a given LDAP connection
before the connection is taken down.
This parameter is not available using the pdconfig utility. The parameter must be
modified manually using the pdadmin command line (local login). For more
information, refer to "pdadmin commands" in the IBM Tivoli Access Manager for
e-business: Command Reference.
278
Administration Guide
Options
number_seconds
The number of seconds of inactivity allowed on a given LDAP connection.
The valid range for this parameter is 0 to 31536000. A connection-inactivity
value of 0 indicates that connection inactivity is not tracked and the
connections, once established, are left connected permanently.
Usage
Optional
Default value
If this parameter is not specified, the default value is 0.
Example
connection-inactivity = 0
dynamic-groups-enabled
Syntax
dynamic-groups-enabled = {yes|true|no|false}
Description
Indication of whether dynamic groups are supported. This key value pair applies
to supported LDAP registries. Tivoli Access Manager supports dynamic groups
with IBM Tivoli Directory Server regardless of this setting.
Note: This stanza entry can be used only in the ldap.conf configuration file.
Options
yes|true
Tivoli Access Manager attempts to resolve dynamic group membership.
no|false
Tivoli Access Manager does not attempt to resolve dynamic group
membership. Anything other than yes|true, including a blank value, is
interpreted as no|false.
Usage
Optional
Default value
no
Example
dynamic-groups-enabled = no
enabled
Syntax
enabled = {yes|true|no|false}
Description
Indication of whether LDAP is being used as the user registry. Only one user
registry can be specified at a time.
Appendix C. Configuration file stanza reference
279
If enabled, other required stanza entries are an LDAP server host name, and port
with which to bind to the server, a bind user DN, and bind user password
(obfuscated).
Options
yes|true
Enables LDAP user registry support.
no|false
Disables LDAP user registry support and indicates that LDAP is not the
user registry being used. Anything other than yes or true, including a
blank value, is interpreted as no or false.
Usage
Conditional. This stanza entry is required when LDAP is the user registry.
Default value
The default value can be different, depending on how the server is configured.
Example
enabled = yes
host
Syntax
host = host_name
Description
Host name of the LDAP server. Valid values for host_name include any valid
Internet Protocol (IP) host name.
When LDAP is the configured user registry, use the svrsslcfg utility to set the
host_name value. The host that is specified by this entry is assumed to be a
readwrite type of server with a preference of 5. For a general description of server
types and preferences, see “replica” on page 283.
Options
host_name
The value is taken from the pd.conf file. The pd.conf file is created when
the Tivoli Access Manager runtime is configured.
Usage
Required
Default value
There is no default value. The value is taken from the pd.conf file.
Example
host = libra
host = libra.dallas.ibm.com
ignore-suffix
Syntax
ignore-suffix = suffix_dn
280
Administration Guide
Description
LDAP server suffix that is to be ignored when searching for user and group
information. By default, all defined suffixes in the LDAP server are searched when
acquiring User and group information.
Note: This stanza entry can be used only in the ldap.conf configuration file.
Options
suffix_dn
Specifies the suffix distinguished name (DN) that you want to be ignored.
Repeat this stanza entry for each suffix you want to be ignored. For
example, if you specify ignore-suffix = o=tivoli,c=us, any user or group
that includes o=tivoli,c=us as part of the DN is ignored.
Usage
Optional
Default value
All defined suffixes are searched.
Example
ignore-suffix = o=tivoli,c=us
max-search-size
Syntax
max-search-size = [0|number_entries]
Description
Limit for the maximum search size, specified as the number of entries, that can be
returned from the LDAP server. The value for each server can be different,
depending on how the server was configured.
Options
0
The number is unlimited. There is no limit to the maximum search size.
number_entries
The maximum number of entries for search, specified as an integer whole
number. This value can be limited by the LDAP server itself.
Usage
Optional
Default value
The default value is server-dependent, but it defaults to 2048 if it is not configured.
Example
max-search-size = 2048
max-server-connections
Syntax
max-server-connections = number_connections
Appendix C. Configuration file stanza reference
281
Description
Indicates the maximum number of connections that are allowed with the LDAP
server. The Tivoli Access Manager runtime maintains a pool of connections for
each LDAP server. From this pool, an available connection is chosen to perform
requests to the LDAP server. If all connections are busy, a new connection is
established with the LDAP server, up to the maximum server connection pool size.
This parameter is not available using the pdconfig utility. The parameter must be
modified manually using the pdadmin command line (local login). For more
information, refer to "pdadmin commands" in the IBM Tivoli Access Manager for
e-business: Command Reference.
Options
number_connections
The maximum number of connections allowed with the LDAP server. The
valid range for this parameter is 2-16. Values greater than 16 are set to 16.
Usage
Optional
Default value
If this parameter is not specified, the default pool size is 16.
Example
max-server-connections = 16
novell-suffix-search-enabled
Syntax
novell-suffix-search-enabled = {yes|true|no|false}
Description
When the Novell eDirectory LDAP server is used as the user registry, Access
Manager uses this option to determine whether to search the entire directory
namespace for user, group, and policy information using a baseless (global root)
search or to automatically determine the set of naming contexts hosted by the
LDAP server and search each defined naming context individually for user, group,
and policy information.
Options
yes|true
Access Manager performs naming context (suffix/partition) discovery and
searches each naming context for user, group, and policy information. The
optional ignore-suffix parameter(s) will be honored.
no|false
Access Manager performs a baseless (global root) search of the entire
namespace for user, group, and policy information. The optional
ignore-suffix parameter(s) will be ignored.
Usage
Optional; this stanza entry can be used only in the ldap.conf configuration file.
Default value
no
282
Administration Guide
Example
novell-suffix-search-enabled = no
port
Syntax
port = port
Description
Non-SSL IP port number that is used for communicating with the LDAP server.
Options
port
The value configured for the LDAP server.
Usage
Required
Default value
389
Example
port = 389
replica
Syntax
replica = ldap-server, port, type, pref
Description
Definition of the LDAP user registry replicas in the domain.
Options
ldap-server
The network name of the server.
port
The port number for the LDAP server. A valid port number is any positive
number that is allowed by TCP/IP and that is not currently being used by
another application.
type
Either readonly or readwrite.
pref
A number between 1 and 10, where 10 is the highest preference. The server
with the highest preference is chosen for LDAP operations. If multiple
servers have the same preference value, then load balancing occurs among
the least busy of the servers.
Usage
Optional
Default value
No replicas are specified.
Example
The following example shows one replica that is specified and two replicas that are
commented out:
Appendix C. Configuration file stanza reference
283
replica = freddy,390,readonly,1
#replica = barney,391,readwrite,2
#replica = benny,392,readwrite,3
secauthority-suffix
Syntax
secauthority-suffix = suffix
Description
Provides a suffix under which the secAuthorityInfo object is located; this parameter
serves as a starting search location for the secAuthorityInfo object when Tivoli
Access Manager is started. If this parameter is set, the specified suffix will be
searched first to locate the secAuthorityInfo object for the domain. If this
parameter is not set, or if the secAuthorityInfo object is not located within the
suffix specified by the parameter, then the entire set of suffixes will be searched.
Options
suffix
Suffix under which the secAuthorityInfo object is located.
Usage
Optional.
This parameter must be set manually using the pdadmin utility, as in the following
example:
>pdadmin login -l
>pdadmin local>config modify keyvalue set
"c:\Progra~1\Tivoli\Policy Director\etc\ldap.conf"
ldap secauthority-suffix "c=US"
Default value
No suffixes are specified.
Example
secauthority-suffix = c=US
ssl-port
Syntax
ssl-port = port
Description
SSL IP port that is used to connect to the LDAP server.
Options
port
Any valid port number. A valid port number is any positive number that is
allowed by TCP/IP and that is not currently being used by another
application.
Usage
Conditional. This stanza entry is required when the LDAP server is configured to
perform client authentication (ssl-enabled = yes).
Default value
636
284
Administration Guide
Example
ssl-port = 636
[manager] stanza
The stanza entries for configuring the master server settings are located in the
[manager] stanza of each of the following configuration files:
v The ivacld.conf configuration file for the authorization server
v The pd.conf configuration file when you use the authorization server
v The pdmgrproxyd.conf configuration file for the policy proxy server
management-domain
Syntax
management-domain = {default|domain_name}
Description
Name of the management domain. This value is created and set by one of the
following utilities:
v For the pd.conf file, the value is set using the bassslcfg utility.
v For other configuration files, the value is set using the svrsslcfg utility.
Note: The internal interface that Tivoli Access Manager uses to access the LDAP
server when "LDAP" is selected as registry type is called the IntraVerse
Registry API (IRA). Function call are required to accurately specify the target
domain for requests. If the IRA cannot determine the target domain from the
ira_local_domain or ira_authority options, the IRA uses the value of the
management-domain parameter in the pd.conf file. If the runtime has not
been configured, or if the management-domain parameter is missing, then the
management domain is assumed to be Default.
Options
Default
Specifies the Management domain. This value is the default value for all
servers.
domain_name
Specifies the user-specified domain. Use this value when you configure
your own name for the domain.
The domain_name value is an alphanumeric, case-sensitive string. String
values are expected to be characters that are part of the local code set.
Valid characters for domain names for U.S. English are the letters a-Z, the
numbers 0-9, a period (.), an underscore (_), a plus sign (+), a hyphen (-),
an "at" symbol (@), an ampersand (&), and an asterisk (*). You cannot use a
space in the domain name.
Usage
Required
Default value
Default
Example
management-domain = mymgmtdomain
Appendix C. Configuration file stanza reference
285
master-host
Syntax
master-host = server_hostname
Description
Host name of the Tivoli Access Manager server. The following host names are
valid:
v mycomputer.city.company.com
v mycomputer
Options
server_hostname
Represents the valid name for the host.
Usage
Required
Default value
There is no default value.
Example
master-host = ammaster
master-port
Syntax
master-port = port
Description
TCP port on which the server listens for requests. This value is created and set by
one of the following utilities:
v For the pd.conf file, the value is set using the bassslcfg utility.
v For all other configuration files, the value is set using the svrsslcfg utility.
Options
port
Any valid port number. A valid port number is any positive number that is
allowed by TCP/IP and that is not currently being used by another
application. Use the default port number value, or use a port over 1000
that is currently not being used.
Usage
Required
Default value
The default value is server-dependent.
Example
master-port = 7135
286
Administration Guide
[meta-info] stanza
The stanza entry for configuring Tivoli Access Manager version information is
located in the [meta-info] stanza of each of the following configuration files:
v The ivmgrd.conf configuration file for the policy server
v The ivacld.conf configuration file for the authorization server
v The pd.conf configuration file when you use the authorization server
v The pdmgrproxyd.conf configuration file for the policy proxy server
version
Syntax
version = number
Description
Version of Tivoli Access Manager in decimal format.
Note: This value is generated. Do not change it.
[pdconfig] stanza
This stanza defines the configuration key value pairs that are required for the
LDAP server. The entries in this stanza are for internal use only. Do not modify the
values in this file. To properly configure these entries, use the pdconfig utility.
LdapSSL
Syntax
LdapSSL = {ssl|nossl}
Description
Indication of whether to enable SSL communication on the LDAP server. If the
LDAP server is not SSL enabled, any Tivoli Access Manager server that is SSL
enabled cannot communicate with the LDAP server.
Note: The entries in this stanza are for internal use only. Do not modify the values
in this file. To properly configure these entries, use the pdconfig utility.
Options
ssl
Enables SSL communication. SSL is automatically configured.
nossl
Disables SSL communication. Anything other than ssl, including a blank
value, is interpreted as nossl.
Usage
Optional
Default value
The default value is server dependent.
Example
LdapSSL = nossl
Appendix C. Configuration file stanza reference
287
LdapSSLKeyFile
Syntax
LdapSSLKeyFile = ldap-ssl-key-filename
Description
SSL key file name and location. Use the SSL key file to handle certificates that are
used in LDAP communication. The file extension can be anything, but the
extension is usually .kdb.
The certificate files in a directory need to be accessible to the server user (or all
users). Make sure that the server user (for example, ivmgr) or all users have
permission to access the .kdb file and the folder that contains the .kdb file.
Note: The entries in this stanza are for internal use only. Do not modify the values
in this file. To properly configure these entries, use the pdconfig utility.
Options
ldap-ssl-key-filename
The file name and location that represents an alphanumeric string that is
not case-sensitive. String values are expected to be characters that are part
of the local code set. The set of characters permitted in a file name can be
determined by the file system and by the local code set. For Windows
operating systems, file names cannot have a backward slash (\), a colon (:),
a question mark (?), or double quotation marks ("). For Linux and UNIX
operating systems, path names and file names are case-sensitive.
Usage
Conditional. This stanza entry is required when LdapSSL = ssl.
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/opt/PolicyDirector/keytab/ivmgrd.kdb
Windows
c:\program files\tivoli\policy director\keytab\ivmgrd.kdb
Example
LdapSSL = ssl
LdapSSLKeyFile = /opt/PolicyDirector/keytab/ivmgrd.kdb
LdapSSLKeyFileDn
Syntax
LdapSSLKeyFileDn = keyLabel
Description
Key label of the client certificate within the SSL key file. This stanza entry is used
when the LDAP server is configured to perform client authentication.
Note: The entries in this stanza are for internal use only. Do not modify the values
in this file. To properly configure these entries, use the pdconfig utility.
288
Administration Guide
Options
keyLabel
Identifies the client certificate that is presented to the LDAP server.
Usage
Conditional. This stanza entry is required when LdapSSL = ssl.
Default value
There is no default value.
Example
LdapSSL = ssl
LdapSSLKeyFileDn = "PD_LDAP"
LdapSSLKeyFilePwd
Syntax
LdapSSLKeyFilePwd = ldap-ssl-keyfile-password
Description
Password to access the SSL key file.
Note: The entries in this stanza are for internal use only. Do not modify the values
in this file. To properly configure these entries, use the pdconfig utility.
Options
ldap-ssl-keyfile-password
The password that is associated with the SSL key file. The default SSL key
file is key4ssl.
Usage
Conditional. This stanza entry is required when LdapSSL = ssl.
Default value
There is no default value.
Example
LdapSSL = ssl
LdapSSLKeyFilePwd = mysslpwd
[pdaudit-filter] stanza
The stanza entry for Tivoli Access Manager auditing support is located in the
[pdaudit-filter] stanza of the pdaudit.conf configuration file.
logcfg
Syntax
logcfg = audit.azn:[log-agent][[param[=value]] ...]
Description
Enables logging and auditing for the application. Category, destination, and other
parameters are used to capture Tivoli Access Manager auditing and logging events.
Appendix C. Configuration file stanza reference
289
Each server provides its own event logging setting in its corresponding
configuration file.
Options
audit.azn:log-agent
Category of auditing event. Also indicates that the destination where
log-agent is one of the following agents:
v stdout
v stderr
v file
v pipe
v remote
param=value
Allowable parameters. The parameters vary, depending on the category,
the destination of events, and the type of auditing you want to perform.
Refer to IBM Tivoli Access Manager for e-business: Troubleshooting Guide for
information about the log agents and the configuration parameters.
Usage
Optional
Default value
Remove the pound signs (#) at the beginning of the configuration file lines to
enable authentication or authorization auditing (or both) for the application.
Example
logcfg = audit.azn:file path=audit.log,flush_interval=20,log_id=audit_log
[pdmgrproxyd] stanza
The stanza entries for configuring the policy proxy server are located in the
following configuration file:
v The pdmgrproxyd.conf configuration file for the policy proxy server
cache-database
Syntax
cache-database = {yes|no}
Description
Indication of whether in-memory caching of the policy database is enabled.
Options
yes
Enables in-memory caching of the policy database.
no
Disables in-memory caching of the policy database.
Usage
Required
Default value
no
Example
cache-database = yes
290
Administration Guide
log-file
Syntax
log-file = fully_qualified_path
Description
Location and name of the log file. Messages are redirected from STDOUT and
STDERR and sent to the server log file as defined in the policy proxy server
routing file (pdmgrproxyd_routing). The policy proxy server relies on the routing
file to determine the log file names and path.
At startup of the policy proxy server, a check is made to see if the routing file
exists. If it exists, the routing file is used and this stanza entry is ignored;
otherwise, this stanza entry is used.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Required
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/var/PolicyDirector/log/msg__pdmgrproxyd_utf8.log
Windows
c:\prograrm files\tivoli\policy director\log\
msg__pdmgrproxyd_utf8.log
During installation of Tivoli Access Manager, if you enabled Tivoli Common
Directory to specify one common directory location for all your log files, the
default installation directory is different.
Example
The following example shows a Windows operating system without Tivoli
Common Directory:
log-file = c:\pd\log\msg__pdmgrproxyd_utf8.log
The following example shows a Linux or UNIX operating system with Tivoli
Common Directory:
log-file = TCD_directory/HPD/logs/msg__pdmgrproxyd_utf8.log
The 3-character identifier used in the example is HPD, which specifies that the log
files are for the Tivoli Access Manager common component.
Appendix C. Configuration file stanza reference
291
pid-file
Syntax
pid-file = fully_qualified_path
Description
Location and name of the PID file.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Required
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/var/PolicyDirector/log/pdmgrproxyd.pid
Windows
c:\program files\tivoli\policy director\log\pdmgrproxyd.pid
Example
pid-file = c:\pd\log\pdmgrproxyd.pid
tcp-req-port
Syntax
tcp-req-port = {0|port}
Description
TCP port on which the server is listening for requests.
Options
0
Disables the port number.
port
Enables the port number. Use any valid port number. A valid port is any
positive number that is allowed by TCP/IP and that is not currently being
used by another application. Use the default port number value, or use a
port number over 1000 that is currently not being used.
Usage
Required
Default value
8138
Example
tcp-req-port = 8138
292
Administration Guide
unix-group
Syntax
unix-group = group_name
Description
The Linux or UNIX group account for this server. The group name and user name
are different items, and both can have the same value. The user name is set as the
group owner of the policy proxy server files. The validity of the group name
specified depends on the requirements of the specific Linux or UNIX operating
system.
Options
group_name
Represents an alphabetic string for the group associated with the user
account.
Usage
Conditional. This stanza entry is required when working with Linux or UNIX
group accounts.
Default value
ivmgr
Example
unix-group = ivmgr
unix-user
Syntax
unix-user = user_name
Description
The Linux or UNIX user account for this server. The group name and user name
are different items, but both can have the same value. The user name is set as the
user owner of the proxy manager files. The validity of the user name specified
depends on the requirements of the specific Linux or UNIX operating system.
Options
user_name
Represents an alphabetic string for the name associated with the user
account.
Usage
Conditional. This stanza entry is required when working with Linux or UNIX user
accounts.
Default value
ivmgr
Example
unix-user = ivmgr
Appendix C. Configuration file stanza reference
293
[pdrte] stanza
When the policy server is installed, the policy server automatically starts after each
system reboot. When the authorization server is installed, the authorization server
daemon automatically starts after each system reboot.
The stanza entries for automating server startup when using any of the user
registries are located in the [pdrte] stanza of the following configuration file:
v The pd.conf configuration file when you use the authorization server
When you use the Tivoli Access Manager authorization server, you must have the
pd.conf configuration file.
boot-start-ivacld
Syntax
boot-start-ivacld = {yes|no}
Description
Indication of whether to start the authorization server at system boot.
Options
yes
Start the authorization server at system boot.
no
Do not start the authorization server at system boot.
Usage
Conditional. This stanza entry is required for Linux and UNIX operating systems
only.
Default value
no
Example
boot-start-ivacld = yes
boot-start-ivmgrd
Syntax
boot-start-ivmgrd = {yes|no}
Description
Indication of whether to start the policy server at system boot.
Options
yes
Start the policy server at system boot.
no
Do not start the policy server at system boot.
Usage
Conditional. This stanza entry is required for Linux and UNIX operating systems
only.
Default value
no
294
Administration Guide
Example
boot-start-ivmgrd = yes
boot-start-pdproxyd
Syntax
boot-start-pdproxyd = {yes|no}
Description
Indication of whether to start the policy proxy server at system boot.
Options
yes
Start the policy proxy server at system boot.
no
Do not start the policy proxy server at system boot.
Usage
Conditional. This stanza entry is required for Linux and UNIX operating systems
only.
Default value
no
Example
boot-start-pdproxyd = yes
configured
Syntax
configured = {yes|no}
Description
Indication of whether the Tivoli Access Manager runtime package was configured.
Note: This value is generated. Do not change it.
tivoli_common_dir
Syntax
tivoli_common_dir = fully_qualified_path
Description
File name and location for message files and trace log files. Indicates whether
Tivoli Common Directory is used.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Appendix C. Configuration file stanza reference
295
Usage
Conditional. This stanza entry is required when you configure the IBM Tivoli
Access Manager Runtime for Java environment for Tivoli Common Directory
(TCD) logging.
Default value
Refer to IBM Tivoli Access Manager for e-business: Troubleshooting Guide for more
information about Tivoli Common Directory.
user-reg-host
Syntax
user-reg-host = hostname
Description
User registry host name.
Note: This value is generated during configuration. Do not change it.
user-reg-hostport
Syntax
user-reg-hostport = port
Description
Non-SSL IP port number that is used for communicating with the user registry
server.
Note: This value is generated during configuration. Do not change it.
user-reg-server
Syntax
user-reg-server = server_name
Description
User registry server name.
Note: This value is generated during configuration. Do not change it.
user-reg-type
Syntax
user-reg-type = {ldap|domino|active_directory}
Description
User registry type.
Note: This value is generated during configuration. Do not change it.
[pdwpm] stanza
The stanza entry for configuring Web Portal Manager information is located in the
[pdwpm] stanza of the amconf.properties configuration file.
296
Administration Guide
This configuration file is in the /classes subdirectory of one of the following
operating system-specific directories:
For Linux and UNIX operating systems
websphere_install_dir/WebSphere/AppServer/systemApps/isclite.ear/
iscwpm.war/
For Windows operating systems
websphere_install_dirProgram Files\IBM\WebSphere\AppServer\
systemApps\isclite.ear\iscwpm.war\
where websphere_install_dir is the directory where WebSphere is installed.
The /images/en subdirectory under the iscwpm.war directory contains the default
GIF files for English locales.
For changes to the amconf.properties file to take effect, restart the WebSphere
server.
For additional information about customizing Web Portal Manager, see
“Customizing the Web Portal Manager interface” on page 28.
aclMembership
Syntax
aclMembership = {true|false}
Description
Indicates whether the ACL Management tab is shown for the User and Group
properties page.
Usage
Required
Default value
true
authMethod
Syntax
authMethod = {FORM|BASIC|SSO|TAI}
Description
Specifies the authentication method.
Options
FORM
Use when FORM-based login is needed.
BASIC
Use when basic authentication is needed.
SSO
Use for single sign-on, when Web Portal Manager is junctioned behind
WebSEAL or when WebSphere Application Server security is in use.
TAI
Use when Web Portal Manager is junctioned behind WebSEAL and
WebSphere Application Server security is in use
Usage
Required
Appendix C. Configuration file stanza reference
297
Default value
FORM
Example
authMethod = BASIC
bannerFile
Syntax
bannerFile = file_name
Description
Specifies which JSP or HTML file is loaded.
Options
file_name
The name of the JSP or HTML file to load. The JSP or HTML file must in
one of the following directories:
For administration
/pdadmin.war
For delegate administration
/delegate.war
Usage
Required
Default value
top_banner.jsp
Example
bannerFile = top_banner.jsp
changePassword
Syntax
changePassword = {true|false}
Description
Indication of whether the password-change pages are displayed so that users can
change their passwords with Web Portal Manager.
Passwords for Web Portal Manager must adhere to the password policies that is set
by the administrator. By default, passwords must contain a minimum of eight
characters (consisting of at least one number and four letters) and a maximum of
two repeated characters.
Options
true
Display pages that allow Web Portal Manager users to change their
passwords.
false
Do not display pages that allow Web Portal Manager users to change their
passwords.
Usage
Required
298
Administration Guide
Default value
true
Example
changePassword = false
debug
Syntax
debug = {true|false}
Description
Determines whether the trace is permitted to be displayed to standard out (stdout)
when an exception is thrown.
Options
true
Allows the trace information to be displayed to standard output.
false
Does not allow the trace information to be displayed to standard output.
Usage
Required
Default value
false
Example
debug = true
infoBarGif
Syntax
infoBarGif = file_name
Description
Specifies which image is shown in the on the bottom right of the page.
Options
file_name
The name of the GIF file. The GIF file must in one of the following
directories under the /pdadmin.war directory for administration or
/delegate.war directory for delegate administration:
v /images
v /images/locale
Usage
Required
Default value
infobar_ibm.gif
Example
infoBarGif = infobar_ibm.gif
Appendix C. Configuration file stanza reference
299
jrteHost
Syntax
jrteHost = hostname
Description
Indicates the host name of the system where the Tivoli Access Manager Runtime
for Java package is installed and configured.
Note: This value is generated during configuration. Do not change it.
This stanza entry requires the jrteProps stanza entry.
jrteProps
Syntax
jrteProps = fully_qualified_path
Description
Indicates the file name and location of the properties file that is used by the Tivoli
Access Manager Runtime for Java environment. This stanza entry requires the
jrteHost stanza entry.
Note: This value is generated during configuration. Do not change it.
loginGif
Syntax
loginGif = file_name
Description
Specifies which image is shown on the login page.
Options
file_name
The name of the GIF file. The GIF file must in one of the following
directories under the /pdadmin.war directory for administration or
/delegate.war directory for delegate administration:
v /images
v /images/locale
Usage
Required
Default value
accessmanager.gif
Example
loginGif = accessmanager.gif
splashGif
Syntax
splashGif = file_name
300
Administration Guide
Description
Specifies which image is shown on the Welcome page, after the Login page
Options
file_name
The name of the GIF file. The GIF file must in one of the following
directories under the /pdadmin.war directory for administration or
/delegate.war directory for delegate administration:
v /images
v /images/locale
Usage
Required
Default value
accessmanager.gif
Example
splashGif = accessmanager.gif
wasEmbedded
Syntax
wasEmbedded = {true|false}
Description
Indicates whether only the User, Group, GSO, and Policy pages are displayed.
This stanza entry is for internal use only. Do not change it.
Usage
Required
Default value
false
[ssl] stanza
The [ssl] stanza in the configuration file defines the Secure Sockets Layer (SSL)
configuration settings for the Tivoli Access Manager servers. The stanza entries for
configuring Tivoli Access Manager SSL settings are located in the [ssl-info]
stanza of each of the following configuration files:
v
v
v
v
v
The ivmgrd.conf configuration file for the policy server
The ivacld.conf configuration file for the authorization server
The pd.conf configuration file when you use the authorization server
The pdmgrproxyd.conf configuration file for the policy proxy server
Your resource managers' configuration file for configured SSL entries
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file.
Developers of service plug-ins should provide the standard functions. Before
implementing service plug-ins, read and thoroughly understand the concepts
discussed in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
Appendix C. Configuration file stanza reference
301
ssl-authn-type
Syntax
ssl-authn-type = certificate
Description
Type of authentication.
Note: This value is created and its value set during configuration for the
authentication server and the policy proxy server. This stanza entry is not
used for the policy server.
Do not edit this stanza entry.
Default value
certificate
ssl-auto-refresh
Syntax
ssl-auto-refresh = {yes|no}
Description
Indication of whether automatic refresh of the SSL certificate and the key database
file password occur.
This value is created and its value set using one of the following utilities:
v For the ivmgrd.conf configuration file, it is set using the mgrsslcfg utility.
v For the pd.conf configuration file, it is set using the bassslcfg utility.
v For all other configuration files, it is set using the svrsslcfg utility.
Note: This value is set using a configuration utility. Do not edit this stanza entry.
Options
yes
Enables automatic certificate and password refresh.
no
Disables automatic certificate and password refresh.
ssl-cert-life
Syntax
ssl-cert-life = number_days
Description
Value for the lifetime in number of days of a certificate. Any issued or renewed
certificates must use this value.
For the ivmgrd.conf configuration file, set this value using the mgrsslcfg utility to
a value between 1 and 7299. (The default is 1460, or four years.) The name and
path are fixed for this configuration file. Use this utility to modify this value after
initial configuration.
To increase or decrease the value, change the value and restart the policy server.
The new value is in effect only for certificates that are issued or that are renewed
302
Administration Guide
from that point on. If both the certificate and the password to the key database file
that contains the certificate expire, the password must be refreshed first.
Notes:
1. Only the policy server uses this value.
2. The password value is set using the mgrsslcfg utility.
3. Do not edit this stanza entry.
ssl-enable-fips
Syntax
ssl-enable-fips = {yes|no}
Description
Determines whether Federal Information Process Standards (FIPS) mode is
enabled. If enable, set to yes, Transport Layer Security (TLS) version 1 (TLSv1) is
the secure communication protocol used. If not enabled, set to no, SSL version 3
(SSLv3) is the secure communication protocol used.
Options
yes
Indicates that TLSv1 is the secure communication protocol.
no
Indicates that SSLv3 is the secure communication protocol.
Usage
Required
Default value
There is no default value. This value is set by the configuration utility that is
associated with each server.
Example
ssl-enable-fips = no
ssl-io-inactivity-timeout
Syntax
ssl-io-inactivity-timeout = {0|number_seconds}
Description
Duration in seconds that an SSL connection waits for a response before timing out.
For certain administration request, such as looking up members in a large user
registry group over an SSL connection, you might receive the HPDBA0219E error
message when the timeout value is too small. To resolve this problem, increase this
timeout value in the pd.conf configuration file.
This timeout value is created, and the value is set using one of the following
utilities:
v For the ivmgrd.conf configuration file, it is set using the mgrsslcfg utility.
v For the pd.conf configuration file, it is set using the bassslcfg utility.
v For all other configuration files, it is set using the svrsslcfg.
Note: The timeout value is set using the configuration utility. Do not edit this
stanza entry.
Appendix C. Configuration file stanza reference
303
Options
0
No timeout is allowed.
number_seconds
Specifies the number of seconds that an SSL connection waits for a
response before timing out. There is no range limitation for this timeout
value.
Usage
Required
Default value
There is no default value. This value is set by the configuration utility that is
associated with each server.
Example
ssl-io-inactivity-timeout = 300
ssl-keyfile
Syntax
ssl-keyfile = key-path
Description
File name and location on the local system of the SSL key file. If the key-value pair
does not exist in the configuration file, the application fails. The file extension can
be anything, but it is usually .kdb. By default, the key file is located in one of the
following operating system-specific directories:
Linux and UNIX operating systems
/var/PolicyDirector/keytab
Windows operating systems
c:\program files\tivoli\policy director\keytab
The certificate files in a directory need to be accessible to the server user (or all
users). Make sure that server user (for example, ivmgr) or all users have permission
to access the .kdb file and the folder that contains the .kdb file.
This file is created, and the value is set using one of the following utilities:
v For the ivmgrd.conf configuration file, it is set using the mgrsslcfg utility.
v For the pd.conf configuration file, it is set using the bassslcfg utility.
v For all other configuration files, it is set using the svrsslcfg utility.
Note: The file name, including extension, is generated and set by the configuration
utility. Do not edit this stanza entry.
ssl-keyfile-label
Syntax
ssl-keyfile-label = label
Description
Label of key to use other than the default. Quotation marks surrounding the label
value are not permitted.
304
Administration Guide
This label is created, and the value is set using one of the following utilities:
v For the ivmgrd.conf configuration file, it is set using mgrsslcfg utility
v For the pd.conf configuration file, this entry does not apply.
v For all other configuration files, it is set using the svrsslcfg utility.
Note: The label is set by the configuration utility. Do not edit this stanza entry.
ssl-keyfile-stash
Syntax
ssl-keyfile-stash = stash-path
Description
File name and location of the SSL password stash file that is used to protect
private keys in the key file. The password might be stored encrypted in the stash
file.
The file extension can be anything, but it is usually .sth. By default, the key file is
located in one of the following operating system-specific directories:
Linux and UNIX operating systems
/var/PolicyDirector/keytab
Windows operating systems
c:\program files\tivoli\policy director\keytab
This file is created, and the value is set using one of the following utilities:
v For the ivmgrd.conf configuration file, it is set using the mgrsslcfg utility.
v For the pd.conf configuration file, it is set using the bassslcfg utility.
v For all other configuration files, it is set using the svrsslcfg utility. The path is
defined by the –d option, and the name is defined by the –n option.
Note: The file name, including extension, is generated and set by the configuration
utility. Do not edit this stanza entry.
ssl-listening-port
Syntax
ssl-listening-port = {0|port}
Description
TCP port to listen on for incoming requests.
Note: The policy server does not use this stanza entry.
Options
0
Disables listening. The value is specified during configuration by using the
svrsslcfg utility.
Note: Do not change this parameter directly; the parameter should be
modified only by issuing the scrsslcfg -chgport command so that
the policy server knows that the listening port has been changed.
Otherwise, the resource manager cannot receive policy update
notifications or pdadmin server task commands.
Appendix C. Configuration file stanza reference
305
port
Enables listening at the specified port number. The valid range for port is
any positive number that is allowed by TCP/IP and is not currently being
used by another application.
There is no one default value, because the configuration programs for each
daemon specify its own default value. For example, when configuring the
policy proxy server, the user is prompted for a port, with 8139 as the
default. This value is then used in the call to the SSL configuration utility.
Usage
Required, except for the policy server.
Default value
If not specified during configuration, the default value is 0. Otherwise, the value is
server-dependent.
Example
ssl-listening-port = 8139
ssl-local-domain
Syntax
ssl-local-domain = {Default|domain_name}
Description
The name of the local domain. The server runs on this domain. If this value is not
in the configuration file, then operations that rely on its presence fail.
The domain name value is created during configuration, but you can change it
using one of the following utilities:
v For the ivmgrd.conf configuration file, change it using the mgrsslcfg utility.
v For the pd.conf configuration file, change it using the bassslcfg utility.
v For all other configuration files, change it using the svrsslcfg utility.
Note: This value is set during configuration or set using the configuration utility.
Do not edit this stanza entry.
ssl-maximum-worker-threads
Syntax
ssl-maximum-worker-threads = number_threads
Description
Number of threads that can be created by the server to handle incoming requests.
Options
number_threads
Number of threads that can be specified. The valid range must be equal to
or greater than 1. The maximum number varies, because it is dependent on
available system resources.
Usage
Required
Default value
The default value is server-dependent.
306
Administration Guide
Example
ssl-maximum-worker-threads = 50
ssl-pwd-life
Syntax
ssl-pwd-life = number_days
Description
Password lifetime for the key database file, specified in the number of days. For
automatic password renewal, the value for the lifetime of a password is controlled
by the number_days value when the server is started.
The number of days between 1 and 7299 is created, and the value is set using one
of the following utilities:
v For the ivmgrd.conf configuration file, it is set using the mgrsslcfg utility.
v For the pd.conf configuration file, it is set using the bassslcfg utility.
v For all other configuration files, it is set using the svrsslcfg utility.
For manual password renewal, the value is dictated by the value supplied to the
svrsslcfg –chgpwd utility. This value is also written into the appropriate
configuration file.
Notes:
1. If a certificate and the password to the key database file containing that
certificate are both expired, the password must be refreshed first.
2. The password value is set using the configuration utility. Do not edit this
stanza entry.
ssl-v3-timeout
Syntax
ssl-v3-timeout = number_seconds
Description
Session timeout in seconds for SSL v3 connections between clients and servers.
This timeout value controls how often a full SSL handshake is completed between
Tivoli Access Manager clients and servers.
This timeout value is created, and the value is set using one of the following
utilities:
v For the ivmgrd.conf configuration file, it is set using the mgrsslcfg utility.
v For the pd.conf configuration file, it is set using the bassslcfg utility.
v For all other configuration files, it is set using the svrsslcfg. The path is defined
by the –d option, and the name is defined by the –n option.
Notes:
1. Tivoli Access Manager components might not function with small timeout
values in some network environments.
2. The timeout value is set using the configuration utility. Do not edit this stanza
entry.
Appendix C. Configuration file stanza reference
307
[ssl] stanza for ldap.conf
The ldap.conf configuration file defines the SSL configuration settings for the
LDAP server. The stanza entries for configuring SSL settings are located in the
[ssl] stanza of the following configuration file:
v The ldap.conf configuration file for the LDAP server
ssl-local-domain
Syntax
ssl-local-domain = {Default|domain_name}
Description
The name of the local domain. The server runs on this domain. If this value is not
set in the configuration file, operations that rely on its presence fail.
Note: This value is created and set by using the svrsslcfg utility. Do not edit this
stanza entry.
[uraf-registry] stanza
A User Registry Adapter Framework (URAF) stanza is required when the
configured registry type is not LDAP. The stanza entries for configuring
URAF-based registry settings for the server are located in the [uraf-registry]
stanza of the following configuration files:
v
v
v
v
The ivmgrd.conf configuration file for the policy server
The ivacld.conf configuration file for the authorization server
The pdmgrproxyd.conf configuration file for the policy proxy server
Your resource managers' configuration file for configured registry types that are
not LDAP
The aznAPI.conf configuration file that is provided with Tivoli Access Manager
is a sample file for creating configuration files for your own resource managers.
Developers of service plug-ins should provide the standard functions. Before
implementing service plug-ins, read and thoroughly understand the concepts
discussed in the IBM Tivoli Access Manager for e-business: Authorization C API
Developer Reference.
You can set additional stanza entries in the [uraf-registry] stanza of the
activedir.conf, activedir_ldap.conf, or domino.conf configuration files. The
configuration file that is used depends on the type of URAF user registry that you
configure.
Most information in this stanza is filled in during configuration, with the exception
of the cache-related items that must be manually updated by the Tivoli Access
Manager administrator. The cache-mode, cache-size, and cache-lifetime stanza
entries do not appear in ivmgrd.conf configuration file, because the policy server
object should not be cached.
Note: Do not place the following stanza entries in the [uraf-registry] stanza of
the activedir.conf, activedir_ldap.conf, or domino.conf configuration files:
v uraf-registry-config
v bind-id
308
Administration Guide
bind-id
Syntax
bind-id = server_id
Description
The login identity of the server administrator or of the user that is used to bind
(sign on) to the registry server. Only the server uses this ID.
If the ID belongs to a user rather than an administrator, the user must have
privileges to update and modify data in the user registry. For an IBM Lotus
Domino user registry, a Lotus Notes ID file provides the bind ID equivalent.
Note: This value is generated during configuration. Do not change it.
cache-mode
Syntax
cache-mode = {enabled|disabled}
Description
Mode for caching that represents the cache being either turned on or turned off.
Note: This stanza entry is not in the ivmgrd.conf configuration file, because you
do not want to cache the policy server object.
Options
enabled
Turns the cache on. You would enable the cache mode to improve the
performance of repetitive Read actions on a specified object, such as: login
performance that is done more than once a day. Performance for Write
actions would not be improved.
disabled
Turns the cache off. You would disable the cache mode for better security.
Caching opens a small window for users to go from server to server in
order to bypass the maximum number of failed login attempts.
Usage
Optional, normally provided for all Tivoli Access Manager servers, except the
policy server
Default value
enabled
Example
cache-mode = enabled
cache-lifetime
Syntax
cache-lifetime = number_seconds
Appendix C. Configuration file stanza reference
309
Description
Number of seconds that the objects are allowed to stay in the cache.
If cache-mode = enabled and this stanza entry is not used.
For performance tuning, the longer the time specified, the longer the repetitive
Read advantage is held. A smaller number of seconds negates the cache advantage
for user-initiated Reads.
Note: This stanza entry is not in the ivmgrd.conf configuration file, because you
do not want to cache the policy server object.
Options
number_seconds
The timeout specified in number of seconds between 1 and 86400.
Usage
Optional
Default value
30
Example
cache-lifetime = 63200
cache-size
Syntax
cache-size = {number_objects|object_type:cache_count_value;[...]}
Description
Maximum number of objects for a particular object type that can be in the cache at
one time without hash table collisions. Or, if it is not numeric, the value is a list of
one or more object types and their cache counts.
If cache-mode = enabled and this stanza entry is not used, the default value for
cache size is used.
Performance tuning depends on how much memory is dedicated to a cache or
how many objects you typically have repetitive read operations on (such as how
many users you have logging in a day). For example, a setting of 251 might not be
good if you have 1000 users logging in and out several times a day. However, if
only 200 of those users log in and out repetitively during the day, a setting of 251
might work well.
Note: This stanza entry is not in the ivmgrd.conf configuration file, because you
do not want to cache the policy server object.
Options
number_objects
Maximum number of objects (as a prime number) for the cache count
between 3 and a maximum number that is logical for the task and that
does not affect performance. Non-prime numbers are rounded up to the
next higher prime number. If the number fails, the default value is used.
310
Administration Guide
object_type:cache_count_value
List of one or more object types and their cache counts.
Usage
Optional
Default value
The default value is server-specific.
Example
The following example sets the cache to a total of 251 object:
cache-size = 251
The following example sets the cache to 251 objects for each of the user, group,
resgroup, resource, and rescreds objects:
cache-size = user:251;group:251;resgroup:251;resource:251;rescreds:251;
The following example sets the cache to 251 objects for each of the user and group
objects. The other object types are not cached.
cache-size = user:251;group:251;
uraf-registry-config
Syntax
uraf-registry-config = fully_qualified_path
Description
File name and location of the URAF registry configuration file for Tivoli Access
Manager.
Options
fully_qualified_path
Represents an alphanumeric string. String values are expected to be
characters that are part of the local code set. The set of characters
permitted in a file name can be determined by the file system and by the
local code set. For Windows operating systems, file names cannot have a
backward slash (\), a colon (:), a question mark (?), or double quotation
marks ("). For Linux and UNIX operating systems, path names and file
names are case-sensitive.
Usage
Conditional. This stanza entry is required for URAF user registries only.
Default value
The default value is server-specific. It is generated, but it can be changed. The
default URAF registry configuration files can be one of the following files:
v domino.conf
v activedir.conf
v activedir_ldap.conf
Example
The following Windows example uses an IBM Domino server as the user registry
from a Windows client:
uraf-registry-config = c:\program files\tivoli\policy director\etc\
domino.conf
Appendix C. Configuration file stanza reference
311
The following Windows example uses a Microsoft Active Directory server as a user
registry from Windows Active Directory Domain or from a client of an Active
Directory Domain.
uraf-registry-config = c:\program files\tivoli\Policy Director\etc\
activedir.conf
The following Windows example uses a Microsoft Active Directory server as a user
registry from a Windows 2003 client:
uraf-registry-config = c:\program files\tivoli\policy director\etc\
activedir_ldap.conf
The following example using an Microsoft Active Directory server as the user
registry from a UNIX client:
uraf-registry-config = /opt/PolicyDirector/etc/activedir_ldap.conf
[uraf-registry] stanza for domino.conf
The stanza entries for configuring an IBM Lotus Domino server as the URAF user
registry are located in the [uraf-registry] stanza of the following configuration
file:
v The domino.conf configuration file to configure IBM Lotus Domino as the user
registry server
enabled
Syntax
enabled = {yes|no}
Description
Indication of whether Domino is being used as the user registry.
When set to yes, the configuration file must set the following entities:
v server
v PDM
v NAB
Options
yes
Indicates that Domino is the user registry.
no
Indicates that Domino is not the user registry. Anything other than yes,
including a blank value, is interpreted as no.
Usage
Required
Default value
no
Example
enabled = yes
NAB
Syntax
NAB = nsf_filename
312
Administration Guide
Description
IBM Lotus Domino Name and Address Book (NAB) database.
Options
nsf_filename
The names.nsf file name conforms to the underlying operating system file
naming conventions of the Domino server. The database is set at
configuration time and cannot be changed. The file name extension must
always be .nsf.
Usage
Conditional. This stanza entry is required when enabled = yes.
Default value
names.nsf
Example
NAB = names.nsf
PDM
Syntax
PDM = nsf_filename
Description
Tivoli Access Manager meta-data database.
Options
nsf_filename
Represents a Domino database file name. The file name conforms to the
underlying operating system file naming conventions of the Domino
server. The database is created on the Domino server during configuration
and cannot be changed. The recommended file name extension is .nsf.
Usage
Conditional. This stanza entry is required when enabled = yes.
Default value
PDMdata.nsf
Example
PDM = PDMdata.nsf
server
Syntax
server = server_name
Description
Name of the IBM Lotus Domino server.
Options
server_name
Appendix C. Configuration file stanza reference
313
Represents an alphanumeric string that is not case-sensitive. String values
are expected to be characters that are part of the local code set. The
minimum and maximum lengths of the name are imposed by the
underlying registry.
Usage
Conditional. This stanza entry is required when enabled = yes.
Default value
There is no default value.
Example
server = grizzly/Austin/IBM
Where grizzly is the host name of the Domino server machine and the remainder
of the name is the Domino domain name.
uraf-return-registry-id
Syntax
uraf-return-registry-id
= {yes|no}
Description
Indicates whether the URAF registry returns the TAM user identity as it is stored
in the registry or the value entered by the user.
Note: Refer to Appendix A, “Guidelines for changing configuring files,” on page
199 for guidelines on changing configuration file properties.
Options
yes
Return the TAM user identity as it is stored in the registry. This option
returns the user identity exactly as it was created and preserved in the
registry.
no
Return the TAM user identity as the value is entered by the user.
Usage
Optional
Default value
no
Example
uraf-return-registry-id = no
[uraf-registry] stanza for activedir.conf
The stanza entries for configuring a Microsoft Active Directory server as the URAF
user registry are located in the [uraf-registry] stanza of the following
configuration file:
v activedir.conf to configure Microsoft Active Directory as the URAF user registry
dnforpd
Syntax
dnforpd = ad_dn
314
Administration Guide
Description
Distinguished name that is used by Active Directory to store Tivoli Access
Manager data.
Note: This stanza entry is set during configuration. Do not edit this entry.
domain
Syntax
domain = root_domain_name
Description
Active Directory root (primary) domain.
Note: This name is domain-dependent, based on what you selected during the
configuration of the Tivoli Access Manager runtime. Do not edit this entry.
dynamic-groups-enabled
Syntax
dynamic-groups-enabled = {yes|no}
Description
Indication of dynamic group support.
Note: Microsoft supports Active Directory dynamic groups only for Windows
Server 2003 and beyond. Do not change this value if Active Directory is not
capable of handling dynamic groups.
For information about setting up your environment to enable an Active
Directory registry to handle dynamic groups, consult the Microsoft Web site.
Options
yes
Tivoli Access Manager attempts to resolve dynamic group membership.
no
Tivoli Access Manager does not attempt to resolve dynamic group
membership.
Usage
Optional
Default value
no
Example
dynamic-groups-enabled = yes
enabled
Syntax
enabled = {yes|no}
Description
Indication of whether Active Directory is being used as the user registry.
Appendix C. Configuration file stanza reference
315
Options
yes
Indicates that Active Directory is the user registry.
no
Indicates that Active Directory is not the user registry. Anything other than
yes, including a blank value, is interpreted as no.
Usage
Conditional. This stanza entry is required when your user registry is Microsoft
Active Directory.
Default value
no
Example
enabled = yes
hostname
Syntax
hostname = host_name
Description
Active Directory DNS host name.
Note: This value is automatically filled in during the configuration of the Tivoli
Access Manager runtime. Do not edit this entry.
multi-domain
Syntax
multi-domain = {true|admd|false}
Description
Indication of whether the domain is a single domain configuration or a
multi-domain configuration. Selection is made during the configuration of the
Tivoli Access Manager runtime.
Note: This stanza entry is set during configuration. Do not edit it.
uraf-return-registry-id
Syntax
uraf-return-registry-id
= {yes|no}
Description
Indicates whether the URAF registry returns the TAM user identity as it is stored
in the registry or the value entered by the user.
Note: Refer to Appendix A, “Guidelines for changing configuring files,” on page
199 for guidelines on changing configuration file properties.
Options
yes
316
Administration Guide
Return the TAM user identity as it is stored in the registry. This option
returns the user identity exactly as it was created and preserved in the
registry, which is case-sensitive.
no
Return the TAM user identity as the value is entered by the user.
Usage
Optional
Default value
no
Example
uraf-return-registry-id = no
use-email-as-user-id
Syntax
use-email-as-user-id = {yes|no}
Description
Indicates whether support is enabled for using an alternate format for the
userPrincipalName registry attribute. This support ensures that Tivoli Access
Manager works with the Microsoft Active Directory registry when the
userPrincipalName attribute of the Active Directory user object is required to have
a non-default value.
Note: To fully enable this support, this option must be enabled in all Tivoli Access
Manager runtime configured environments.
Options
yes
Support is enabled for using an alternate format for the userPrincipalName
registry attribute.
no
Support for an alternate format userPrincipalName is disabled.
Usage
Conditional. This stanza entry is required when your user registry is Microsoft
Active Directory.
Default value
no
Example
use-email-as-user-id = no
useEncryption
Syntax
useEncryption = {true|false}
Description
Indication of whether encryption communication to Active Directory is being used.
Note: This value is specified during the configuration of the Tivoli Access Manager
runtime. Do not edit this entry.
Appendix C. Configuration file stanza reference
317
[uraf-registry] stanza for activedir_ldap.conf
When you use an LDAP client to retrieve data for the Active Directory user
registry that the Tivoli Access Manager server is configured to, you must have the
activedir_ldap.conf server configuration file. Use this configuration file to
customize the operation of each Active Directory registry server.
The stanza entries for configuring the Microsoft Active Directory as the user
registry on a Tivoli Access Manager server are located in the [uraf-registry]
stanza of the following configuration file:
v activedir_ldap.conf
change-pwd-using-ldap-api
Syntax
change-pwd-using-ldap-api = {yes|no}
Description
Indicates whether password change requests are performed using a direct LDAP
connection to the Active Directory server.
When this option is set to yes, the Policy Server does not need to be available to
process the password change request.
Notes:
1. To implement this functionality across an enterprise system, this option must be
enabled (set to yes) in every IBM Tivoli Access Manager run-time configured
environment in which change password requests are to be handled using
LDAP APIs rather than the Policy Server.
2. Before this option is enabled, Tivoli Access Manager must be configured for
Secure Socket Layer (SSL) for a connection between the LDAP client and the
Active Directory server. The Active Directory environment must also be able to
accept LDAP connections over SSL.
Options
yes
Indicates that password change requests are performed using a direct
LDAP connection to the Active Directory server; the Policy Server does not
need to be available.
no
Indicates that password change requests are performed using the Access
Manager Policy Server and are treated as password resets.
Usage
Conditional. This stanza entry is required when your user registry is Microsoft
Active Directory.
Default value
no
Example
change-pwd-using-ldap-api = no
dnforpd
Syntax
dnforpd = ad_dn
318
Administration Guide
Description
Distinguished name that is used by Active Directory to store Tivoli Access
Manager data.
Note: This stanza entry value is set during configuration. Do not change it.
domain
Syntax
domain = secondary_domain_name
Description
Name of Active Directory secondary or child domain host name. This host name is
in the same forest as the root domain, its host name, and zero or more replica host
names. This name is domain-dependent, based on what you select during the
configuration of the Tivoli Access Manager runtime.
For the Active Directory single domain configuration, either primary-domain= or
domain= can be used to enter the domain name information.
For the Active Directory multiple domain configuration, multiple domain name
entries are allowed.
Options
secondary_domain_name
An alphanumeric, case-sensitive string. String values are expected to be
characters that are part of the local code set. The maximum length for the
domain name is user registry dependent. For Active Directory that
maximum length is 256 alphanumeric characters.
Use the following format to specify a domain:
domain = nnn|hhh[|rrr1[|rrr2[|...]]]
Where:
nnn
The primary domain name. The name format can be either
child.ibm.com or dc=child,dc=ibm,dc=com.
hhh
The primary domain host name or IP address.
rrr
The primary domain replica host name or IP address.
Square brackets ([]) show entries that are optional and the required vertical
bar (|) acts as a separator.
Usage
Conditional. This stanza entry is required when your user registry is Microsoft
Active Directory and when the multi-domain entry is set to true or admd.
Default value
There is no default value.
Example
domain = dc=child,dc=ibm,dc=com|adhost.child.ibm.com|adhostreplica.child.ibm.com
Appendix C. Configuration file stanza reference
319
dynamic-groups-enabled
Syntax
dynamic-groups-enabled= {yes|no}
Description
Indication of dynamic group support.
Note: Before enabling dynamic group support on blade servers, you must first
enable dynamic group support on the policy server. Remember that while
dynamic group support must be enabled on the policy server, you can
disable this option for a blade server. If disabled, the blade server cannot
benefit from dynamic group support.
Options
yes
Tivoli Access Manager attempts to resolve dynamic group membership.
no
Tivoli Access Manager does not attempt to resolve dynamic group
membership.
Usage
Optional
Default value
no
Example
dynamic-groups-enabled = no
enabled
Syntax
enabled = {yes|no}
Description
Indication of whether Active Directory is being used as the user registry.
When set to yes, the following entries must be set:
v ssl-keyfile
v ssl-keyfile-pwd
Options
yes
Indicates that Active Directory is the user registry.
no
Indicates that Active Directory is not the user registry. Anything other than
yes, including a blank value, is interpreted as no.
Usage
Conditional. This stanza entry is required when your user registry is Microsoft
Active Directory.
Default value
no
Example
enabled = yes
320
Administration Guide
ldap-client-timeout
Syntax
ldap-client-timeout = {0|number_seconds}
Description
Amount of time that is allowed for to LDAP simple bind and LDAP searches
before the LDAP client is considered to be down.
Options
0
Unlimited amount of time for synchronous operations only.
number_seconds
Amount of time, in seconds, allowed for asynchronous operations. The
number of seconds is specified as a positive whole number. The suggested
range is between 240 to 900.
Usage
Required
Default value
0
Example
ldap-client-timeout = 520
max-connections-per-ad-domain
Syntax
max-connections-per-ad-domain = {2-16}
Description
Specifies the number of concurrent connections with each Microsoft Active
Directory domain.
Usage
Conditional. This stanza entry is required when your user registry is Microsoft
Active Directory.
Default value
16
Example
max-connections-per-ad-domain = 16
multi-domain
Syntax
multi-domain = {true|admd|false}
Description
Indication of whether the domain is a single-domain configuration or a
multi-domain configuration. Selection is during the configuration of the Tivoli
Access Manager runtime.
Note: This stanza entry is set during configuration. Do not edit it.
Appendix C. Configuration file stanza reference
321
primary-domain
Syntax
primary-domain = primary_domain_name
Description
Active Directory primary domain host name, and zero or more replica host names.
Only one primary domain entry is allowed. This name is domain-dependent, based
on what you select during the configuration of the Tivoli Access Manager runtime.
For the Active Directory multi-domain configuration, the primary domain entry
must contain the root domain information.
For the Active Directory single domain configuration, either the primary-domain =
entry or the domain = entry can be used for the domain information.
Options
primary_domain_name
An alphanumeric, case-sensitive string. String values are expected to be
characters that are part of the local code set. The maximum length for the
domain name is user registry dependent. For Active Directory that
maximum length is 256 alphanumeric characters.
Use the following format to specify a domain:
primary-domain = nnn|hhh[|rrr1[|rrr2[|...]]]
Where:
nnn
The primary domain name. The name format can be either ibm.com
or dc=ibm,dc=com.
hhh
The primary domain host name or IP address.
rrr
The primary domain replica host name or IP address.
Square brackets ([]) show entries that are optional and the required vertical
bar (|) acts as a separator.
Usage
Required
Default value
There is no default value.
Example
primary-domain = dc=ibm,dc=com|adprim.ibm.com|adprimreplica1.ibm.com
ssl-keyfile
Syntax
ssl-keyfile = ldap-ssl-key-filename
Description
SSL key file name and location. Use the SSL key file to handle certificates that are
used in LDAP communication. The file extension can be anything, but the
extension is usually .kdb.
322
Administration Guide
The certificate files in a directory need to be accessible to the server user (or all
users). Make sure that the server user (for example, ivmgr) or all users have
permission to access the .kdb file and the folder that contains the .kdb file.
The location and file name value represents an alphanumeric string that is not
case-sensitive. String values are expected to be characters that are part of the local
code set. The set of characters permitted in a file name can be determined by the
file system and by the local code set. For Windows operating systems, file names
cannot have a backward slash (\), a colon (:), a question mark (?), or double
quotation marks ("). The maximum string length for the Active Directory user
registry is 256 alphanumeric characters. For Linux and UNIX operating systems,
path names and file names are case-sensitive.
Usage
Conditional. This stanza entry is required when ssl-enabled = yes.
Default value
The following table shows the default value by platform.
Platform
File name
Linux or UNIX
/opt/PolicyDirector/keytab/server_name.kdb
Windows
c:\program files\tivoli\policy director\keytab\server_name.kdb
Example
ssl-keyfile = /opt/PolicyDirector/keytab/ivmgrd.kdb
ssl-keyfile-label
Syntax
ssl-keyfile-label = key_label
Description
Specifies the key label that is used to identify the client certificate. that is presented
to the LDAP server. It is the key label of the client certificate within the SSL key
file.
Options
key_label
An alphanumeric string that is not case-sensitive. String values are
expected to be characters that are part of the local code set. The minimum
and maximum lengths of the ID, if there are limits, are imposed by the
underlying registry. The key label must be enclosed in double quotation
marks.
Usage
Conditional. This stanza entry is required when the LDAP server is configured to
perform client authentication.
Default value
There is no default value.
Example
ssl-keyfile-label = "PDLDAP"
Appendix C. Configuration file stanza reference
323
ssl-keyfile-pwd
Syntax
ssl-keyfile-pwd = ldap-ssl-keyfile-password
Description
Password to access the SSL key file. The password associated with the default SSL
key file is key4ssl.
Usage
Conditional. This stanza entry is required when enabled = yes.
Default value
There is no default value.
Example
ssl-keyfile-pwd = key4ssl
uraf-return-registry-id
Syntax
uraf-return-registry-id
= {yes|no}
Description
Indicates whether the URAF registry returns the TAM user identity as it is stored
in the registry or the value entered by the user.
Note: Refer to Appendix A, “Guidelines for changing configuring files,” on page
199 for guidelines on changing configuration file properties.
Options
yes
Return the TAM user identity as it is stored in the registry. This option
returns the user identity exactly as it was created and preserved in the
registry.
no
Return the TAM user identity as the value is entered by the user.
Usage
Optional
Default value
no
Example
uraf-return-registry-id = no
use-email-as-user-id
Syntax
use-email-as-user-id = {yes|no}
Description
Indicates whether support is enabled for using an alternate format for the
userPrincipalName registry attribute. This support ensures that Tivoli Access
324
Administration Guide
Manager works with the Microsoft Active Directory registry when the
userPrincipalName attribute of the Active Directory user object is required to have
a non-default value.
Note: To fully enable this support, this option must be enabled in all Tivoli Access
Manager runtime configured environments. If this property is enabled
manually using the pdadmin utility, the ad-gc-server entry must also be
modified to add the hostname(s) for the global catalog server.
Options
yes
Support is enabled for using an alternate format for the userPrincipalName
registry attribute.
no
Support for an alternate format userPrincipalName is disabled.
Usage
Conditional. This stanza entry is required when your user registry is Microsoft
Active Directory.
Default value
no
Example
enabled = no
ad-gc-server
Syntax
ad-gc-server = gc_server_hostname
Description
Specifies the Active Directory hostname for the Global Catalog server. This value
must be set and in effect prior to enabling support for alternate UPNs. This
property accepts multiple values.
Options
gc_server_hostname
Active Directory hostname for the Global Catalog server.
Usage
Required when the use-email-as-user-id option is enabled (use-email-as-user-id
= yes).
Default value
none
Example
ad-gc-server = gc-server1.tivoli.com
ad-gc-server = gc-server2.tivoli.com
ad-gc-port
Syntax
ad-gc-port = {3268|3269}
Appendix C. Configuration file stanza reference
325
Description
Specifies the port number for the Active Directory Global Catalog on the Global
Catalog server.
Note: This value is automatically set and should not be modified manually.
Options
3268
Port number reserved by Microsoft Active Directory for Global Catalog in
a non-SSL environment.
3269
Port number reserved by Microsoft Active Directory for Global Catalog in
an SSL environment.
Usage
Required when the use-email-as-user-id option is enabled (use-email-as-user-id
= yes).
Default value
none
UseSSL
Syntax
UseSSL = {yes|no}
Description
Indication of whether to use SSL.
Options
yes
Specifies that you want to use SSL.
no
Specifies that you do not want to use SSL.
Usage
Required
Default value
yes
Example
usessl = no
[xmladi-attribute-definitions] stanza
The stanza entries for configuring the Access Decision Information Extensible
Markup Language (ADI XML) document attribute definitions are located in the
[xmladi-attribute-definitions] stanza. This stanza can be found or placed into
any of the Tivoli Access Manager configuration files, except for the pd.conf
configuration file.
The aznAPI.conf configuration file is provided with Tivoli Access Manager as a
sample file for creating your own resource manager configuration file. Developers
of service plug-ins should provide the standard functions. Before implementing
service plug-ins, read and thoroughly understand the concepts discussed in the
IBM Tivoli Access Manager for e-business: Authorization C API Developer Reference.
326
Administration Guide
AttributeName
Syntax
AttributeName = "AttributeValue"
Description
Definition of ADI XML document attributes that are inserted into the XML ADI
element start tag to enable attributes to be defined for the entire XML ADI
document and for all ADI defined in the XML ADI document.
The ADI XML model requires that the XML document contains the following
top-level XML element into which all target ADI for a particular rule evaluation is
inserted. The XMLADI element is created automatically as part of the rule
evaluation process
<XMLADI>
<!-- XML formatted ADI are inserted here.
</XMLADI>
-->
Usage
Required
Example
xmlns:myNS = "http://myURI.mycompany.com"
appID = ’"Jupiter" - Account Management Web Portal Server #1.’
The attribute value must be enclosed in either double or single quotation marks.
The following XMLADI element start tag defines these attributes:
<XMLADI xmlns:myNS="http://myURI.mycompany.com"
appID=’"Jupiter" - Account Management Web Portal Server #1.’>
For more information, see Chapter 10, “Authorization rules management,” on page
119.
Appendix C. Configuration file stanza reference
327
328
Administration Guide
Appendix D. User registry differences
Each user registry presents unique concerns when integrated with Tivoli Access
Manager. This release of Tivoli Access Manager supports LDAP and URAF user
registries.
Tivoli Access Manager supports the following LDAP user registries:
v Tivoli Directory Server
v IBM z/OS Security Server LDAP Server
v Novell eDirectory Server
v Sun Java System Directory Server
v Sun ONE Directory Server
v Microsoft Active Directory Application Mode (ADAM)
Tivoli Access Manager supports the following URAF user registries:
v Microsoft Active Directory Server
v Lotus Domino Server
General concerns
The following concerns are specific to all of the supported user registries:
v Avoid using the forward slash (/) character when defining the names for users
and groups when that name is defined using distinguished names strings. Each
user registry treats this character differently.
v Avoid using leading and trailing blanks in user and group names. Each user
registry treats blanks differently.
LDAP concerns
The following concerns are specific to all of the supported LDAP user registries:
v There are no configuration steps needed in Tivoli Access Manager to make it
support LDAP's own Password Policy. Tivoli Access Manager does not assume
the existence or non-existence of LDAP's own Password Policy at all.
Tivoli Access Manager enforces its own Password Policy first and foremost.
Tivoli Access Manager will attempt to update password in LDAP only when the
provided password passes Tivoli Access Manager's own Password Policy check.
After that Tivoli Access Manager tries to accommodate LDAP's own Password
Policy to the best of its ability using the return code that its get from LDAP
during a password related update.
If Tivoli Access Manager can map this return code without any ambiguity with
the corresponding Tivoli Access Manager error code, it will do so and will
return a proper error message.
v To take advantage of the multi-domain support in Tivoli Access Manager, you
must use an LDAP user registry. When using a URAF user registry, only a single
Tivoli Access Manager domain is supported.
v When using an LDAP user registry, the capability to own global sign-on
credentials must be explicitly granted to a user. After this capability is granted, it
© Copyright IBM Corp. 1999, 2010
329
can subsequently be removed. Conversely, users that are created in a URAF user
registry are automatically given this capability. This capability cannot be
removed.
v Leading and trailing blanks in user names and group names are ignored when
using an LDAP user registry in a Tivoli Access Manager secure domain. To
ensure consistent processing regardless of the user registry, define user names
and group names without leading or trailing blanks.
v Attempting to add a single duplicate user to a group does not produce an error
when using an LDAP user registry.
v The Tivoli Access Manager authorization API provides a credentials attribute
entitlements service. This service is used to retrieve user attributes from a user
registry. When this service is used with an LDAP user registry, the retrieved
attributes can be string data or binary data. However, when used with a URAF
user registry, the retrieved attributes can be string data, binary data, or integer
data.
Sun Java System Directory Server concerns
The following concerns are specific to Sun Java System Directory Server:
v If the user registry contains more entries than the defined look-through limit, the
directory server might return the following status that Tivoli Access Manager
treats as an error:
LDAP_ADMINLIMIT_EXCEEDED
When the directory server is installed, the default value is 5000. To modify this
value, perform the following steps from the Sun Java System Directory Server
Console:
1. Select the Configuration tab.
2. Expand the Data entry.
3. Select Database Settings.
4. Select the LDBM Plug-in Settings tab.
5. In the Look-through Limit field, type the maximum number of entries that
you want the server to check in response to the search, or type -1 to define
no maximum limit.
If you bind the directory as the Directory Manager, the look-through limit is
unlimited and overrides any settings specified in this field.
Microsoft Active Directory Application Mode (ADAM) concerns
The following concerns are specific to ADAM.
v Policy Server configuration allows you to select between a standard or minimal
data model for the user registry. Because ADAM allows only a single naming
attribute to be used when creating LDAP objects, ADAM requires the minimal
data model. Regardless of which data model is chosen during Policy Server
configuration, Access Manager always uses the minimal data model when
ADAM is selected as the user registry.
v The common name (cn) attribute is a single-value attribute and can store only
one value. The ADAM registry requires the value of cn to be the same as the cn
naming attribute in the distinguished name (dn) attribute. When creating a user
or group in Tivoli Access Manager, specify the same value for cn as the cn
naming attribute in the dn. Tivoli Access Manager ignores the value of the cn
attribute if it is different from the value of the cn naming attribute in the dn. For
330
Administration Guide
example, you cannot use the following command to create a user because the
value of the cn attribute, fred, is different from the cn naming attribute in the
dn, user1:
pdadmin user create user1 cn=user1,o=ibm,c=us fred smith password1
URAF concerns
The following concerns are specific to the supported URAF user registries:
v When using a URAF user registry, only one Tivoli Access Manager domain is
supported. To take advantage of the Tivoli Access Manager multidomain
support, use an LDAP user registry.
v Users created in a URAF user registry are automatically given the capability to
own global sign-on credentials. This capability cannot be removed. When using
an LDAP user registry, this capability must be explicitly granted. After this
capability is granted, it can subsequently be removed.
v The Tivoli Access Manager authorization API provides a credentials attribute
entitlements service. This service is used to retrieve user attributes from a user
registry. When this service is used with a URAF user registry, the retrieved
attributes can be string data, binary data, or integer data. However, when used
with an LDAP user registry, the retrieved attributes can be only string data or
binary data.
Lotus Domino Server concerns
In addition to the general URAF-specific concerns, the following concerns are
specific to Lotus Domino Server:
v Leading and trailing blanks in user names and group names are significant
when using Lotus Domino Server as the user registry in a Tivoli Access Manager
secure domain. To ensure consistent processing, regardless of the user registry,
define user names and group names without leading or trailing blanks.
v When creating names for users or groups and that name is defined with a
distinguished name string that contains a forward slash (/) character, you must
define that name using distinguished name designations. For example, to create
a user with the distinguished name string username/locinfo, use the following
command:
pdadmin user create myuser cn=username/o=locinfo test test testpwd
v When the following conditions occur, the lastLogin value reported by the
pdadmin user show command might not reflect the actual last login time of the
user:
– URAF cache is enabled on a Tivoli Access Manager blade server such as
WebSEAL.
– The provide-last-login property is set in the Policy Server configuration file
to show the last login time stamp,
The pdadmin command queries information directly from the registry while the
blade server keeps the lastLogin value in cache until the cache expires and user
activity exists. The lastLogin value in blade server cache and the registry might
not be synchronized. If the cache is disabled for a Tivoli Access Manager blade
server, the pdadmin user show command shows the latest lastLogin value.
Microsoft Active Directory Server concerns
In addition to the general URAF-specific concerns, the following concerns are
specific to Microsoft Active Directory Server:
Appendix D. User registry differences
331
v For Microsoft Active Directory registry, Tivoli Access Manager uses the Active
Directory user attribute lastLogonTimestamp to report the last login time of the
user. This attribute is a system attribute and is updated automatically by Active
Directory. Tivoli Access Manager has no control over this attribute except
reporting the value when required. This attribute is not updated every time a
user logs in successfully. When a user logs in successfully, this attribute is only
updated if its current value is older than the current time minus the value of the
msDS-LogonTimeSyncInterval attribute.
v For Microsoft Active Directory registry, Tivoli Access Manager uses the Active
Directory user attribute lastLogonTimestamp to report the last login time of the
user. This attribute is a system attribute and is updated automatically by Active
Directory. Tivoli Access Manager has no control over this attribute except
reporting the value when required. This attribute is not updated every time a
user logs in successfully. When a user logs in successfully, this attribute is only
updated if its current value is older than the current time minus the value of the
msDS-LogonTimeSyncInterval attribute.
v Users created in Active Directory may have an associated primary group. The
Active Directory default primary group is Domain Users.
But Active Directory does not add the primary group information to the user's
memberOf or the group's member attribute. This means that when Tivoli Access
Manager queries for a list of members of a group, the result does not include
any members for whom the group is the primary group. Additionally, when
Tivoli Access Manager queries for all the groups to which a user belongs, the
query result does not display the primary group of the user.
For this reason, avoid using a Tivoli Access Manager group as the Active
Directory primary group for Tivoli Access Manager users.
v Tivoli Access Manager does not support cross domain group membership or
universal groups. Tivoli Access Manager does not support importing these types
of groups.
v When Tivoli Access Manager imports a dynamic group, the ivacld-servers and
remote-acl-users groups apply read permission on each authorization store to
which the dynamic group belongs. This read permission enables Tivoli Access
Manager blade servers, such as WebSEAL, to have read permission to the
registry authorization store; thus, providing the blade server with the ability to
read dynamic group data, such as group membership for building Tivoli Access
Manager credentials. Manually removing this read permission while Tivoli
Access Manager is configured to the Active Directory registry results in adverse
behavior, such as inaccurate group membership.
v If the option to change a user's password using LDAP APIs is enabled in an
environment where:
– Tivoli Access Manager is configured to use the Active Directory
user registry
and
– Tivoli Access Manager blade servers use LDAP APIs to communicate with
the Active Directory server,
Tivoli Access Manager must be configured with Secure Socket Layer (SSL) to
allow connections between the LDAP client and the Active Directory server. The
Active Directory environment must also be enabled to accept LDAP connections
over Secure Socket Layer (SSL).
332
Administration Guide
v When using an Active Directory user registry in a Tivoli Access Manager
configuration with blade servers that use LDAP APIs to communicate with the
Active Directory server, Access Manager supports user password change
requests using either the Policy Server or LDAP APIs. Change user password
requests using the LDAP APIs do not require the Policy Server to be
up-and-running.
The use of LDAP APIs to communicate with the Active Directory Server for
blade servers is a multi-platform support that allows blade servers to be
installed on machines that are not clients of the same domain as the policy
server. In this configuration, the policy server must be installed and configured
on a Windows operating system.
v When using an Active Directory user registry, each user name and each group
name in a domain must be unique. User and group short name values that are
stored in the sAMAccountName attribute of Active Directory user objects and
group objects. Active Directory user objects and group objects both have the
sAMAccountName attribute as one of their attributes. Microsoft requires that the
sAMAccountName attributes be unique within an Active Directory domain.
v When using a multi-domain Active Directory user registry, multiple users and
groups can be defined with the same short name as long as they are located in
different domains. However, the full name of the user or group, including the
domain suffix, must always be specified to Tivoli Access Manager.
v Leading and trailing blanks in user names and group names are ignored when
using Microsoft Active Directory Server as the user registry in a Tivoli Access
Manager secure domain. To ensure consistent processing, regardless of the user
registry, define user names and group names without leading or trailing blanks.
v Tivoli Access Manager supports the use of an email address or other alternate
format of the userPrincipalName attribute of the Active Directory registry user
object as a Tivoli Access Manager user identity. This is an optional enhancement;
when it is enabled, both the default and the email address or other alternate
format of the userPrincipalName can co-exist in the Tivoli Access Manager
environment.
The default format of the userPrincipalName registry attribute is
user_id@domain_suffix, where domain_suffix is the Active Directory domain
where the user identity is created.
For example, johndoe@tivoli.com is the value of the userPrincipalName;
tivoli.com is the Active Directory domain where the user identity is created.
The Tivoli Access Manager user identity corresponding to the registry user in
this example is either johndoe@tivoli.com or johndoe, depending on whether
Tivoli Access Manager is configured to use Active Directory with multiple
domains or a single domain, respectively.
The alternate format of the userPrincipalName attribute is user_id@any_suffix,
where any_suffix can be any domain (Active Directory or non-Active Directory)
other than the Active Directory domain in which the user identity is created. For
example, if the registry user johndoe@other_domain.com is created in Active
Directory tivoli.com, and the registry user johndoe@tivoli.com is created in
Active Directory domain child_domain.tivoli.com. Both of these users can be
Tivoli Access Manager users, and their user identities are
johndoe@other_domain.com and johndoe@tivoli.com, respectively.
The alternate user principal name (UPN) support must be enabled in all Tivoli
Access Manager run-time environments to ensure that Tivoli Access Manager
user identities work properly with alternate UPNs.
Appendix D. User registry differences
333
Once the use of alternate UPN format as Access Manager user identity is
enabled, it cannot be reversed without breaking Tivoli Access Manager
functionalities.
v Although users and groups can be created with names that use a distinguished
name string that contain a forward slash (/) character, subsequent operations on
the object might fail. Some Active Directory functions interpret the forward slash
character as a separator between the object name and the host name. To avoid
the problem, do not use a forward slash character to define the user.
Length of names
The maximum lengths of various names that are associated with Tivoli Access
Manager vary depending on the user registry that is being used. See Table 7 for a
comparison of the maximum lengths that are allowed and the recommended
maximum length to use to ensure compatibility with all the user registries that are
supported by Tivoli Access Manager.
Table 7. Maximum lengths for names by user registry and the optimal length across user registries
IBM Tivoli
Directory
Server
IBM z/OS
Security
Server
Novell
eDirectory
Server
Sun Java
System
Directory
Server
Microsoft
Active
Directory
Server
Lotus
Domino
Server
Active
Directory
Application
Mode
(ADAM)
Optimal
length
First name
(LDAP CN)
256
256
64
256
64
960
64
64
Middle
name
128
128
128
128
64
65535
64
64
Last name
(surname)
128
128
128
128
64
960
64
64
Registry UID
(LDAP DN)
1024
1024
1024
1024
2048
255
1024
255
Tivoli Access
Manager
user identity
256
256
256
256
64
196 domain_
name_length
64
64
unlimited
unlimited
unlimited
unlimited
256
unlimited
128
256
1024
1024
64
64
1024
1024
240
60
1024
1024
Name
User
password
User
description
Group name
1024
256
256
256
Group
description
Single
sign-on
resource
name
Single
sign-on
password
334
64
196 domain_
name_length
1024
240
240
240
240
60
256
1024
Single
sign-on
resource
description
Single
sign-on user
ID
256
240
240
240
240
60
256
240
60
unlimited
unlimited
unlimited
unlimited
256
unlimited
unlimited
256
Administration Guide
Table 7. Maximum lengths for names by user registry and the optimal length across user registries (continued)
Name
IBM Tivoli
Directory
Server
IBM z/OS
Security
Server
Novell
eDirectory
Server
Sun Java
System
Directory
Server
Microsoft
Active
Directory
Server
Lotus
Domino
Server
Active
Directory
Application
Mode
(ADAM)
Optimal
length
Single
sign-on
group name
240
240
240
240
60
256
240
60
1024
1024
1024
Action name
1
1
1
Action
description,
action type
unlimited
unlimited
unlimited
Object name,
object
description
unlimited
unlimited
unlimited
Object space
name, object
space
description
unlimited
unlimited
unlimited
ACL name,
ACL
descriptions
unlimited
unlimited
unlimited
POP name,
POP
description
unlimited
unlimited
unlimited
Single
sign-on
group
description
Although the maximum length of an Active Directory distinguished name (registry
UID) is 2048, the maximum length of each relative distinguished name (RDN) is
64.
If you configure Tivoli Access Manager to use multiple Active Directory domains,
the maximum length of the user identity and group name does not include the
domain suffix. When using multiple domains, the format of a user identity is
user_id@domain_suffix. The maximum length of 64 applies only to the user_id
portion. If you use an email address or other alternate format for the Tivoli Access
Manager user identity in the Active Directory, the maximum name length remains
the same, but includes the suffix.
Although the lengths of some names can be of unlimited, excessive lengths can
result in policy that is difficult to manage and might result in poor system
performance. Choose maximum values that are logical for your environment.
Appendix D. User registry differences
335
336
Administration Guide
Appendix E. pdadmin to Web Portal Manager equivalents
This appendix shows the mapping of the administration pdadmin commands to
Web Portal Manager.
Information about the pdadmin utility can be found in the IBM Tivoli Access
Manager for e-business: Command Reference.
Table 8. Mapping between the pddamin utility and Web Portal Manager
pdadmin utility
Web Portal Manager
acl attach object_name acl_name
ACL → List ACL → click ACL name → Attach
tab → Attach → type protected object path →
Attach
acl create acl_name
ACL → Create ACL → fill in form → Create
acl delete acl_name
ACL → List ACL → select ACL names →
Delete
acl detach object_name
ACL → List ACL → click ACL name → Attach
tab → select protected object → Detach
acl find acl_name
ACL → List ACL → click ACL name → Attach
tab
acl list
ACL → List ACL
acl list acl_name attribute
ACL → List ACL → click ACL name →
Extended Attribute tab
acl modify acl_name delete attribute
attribute_name
ACL → List ACL → select ACL name →
Extended Attribute tab → select attributes →
Delete
acl modify acl_name delete attribute
attribute_name attribute_value
Not supported
acl modify acl_name description description
ACL → List ACL → click ACL name → modify
description → Set
acl modify acl_name remove any-other
ACL → List ACL → click ACL name → select
Any-other → Delete
acl modify acl_name remove group
group_name
ACL → List ACL → click ACL name → select
group name → Delete
acl modify acl_name remove
unauthenticated
ACL → List ACL → click ACL name → select
Unauthenticated → Delete
acl modify acl_name remove user user_name
ACL → List ACL → click ACL name → select
user name → Delete
acl modify acl_name set any-other
permissions
ACL → List ACL → click ACL name → select
Any-other → Create → select permissions →
Apply
acl modify acl_name set attribute
attribute_name attribute_value
ACL → List ACL → click ACL name →
Extended Attribute tab → Create → fill in
form → Apply
acl modify acl_name set group group_name
permissions
ACL → List ACL → click ACL name → Create
→ select Group → specify group name → select
permissions → Apply
© Copyright IBM Corp. 1999, 2010
337
Table 8. Mapping between the pddamin utility and Web Portal Manager (continued)
338
pdadmin utility
Web Portal Manager
acl modify acl_name set unauthenticated
permissions
ACL → List ACL → click ACL name → Create
→ select Unauthenticated → select
permissions → Apply
acl modify acl_name set user user_name
permissions
ACL → List ACL → click ACL name → Create
→ select User → specify user name → select
permissions → Apply
acl show acl_name
ACL → List ACL → click ACL name
acl show acl_name attribute attribute_name
ACL → List ACL → click ACL name →
Extended Attribute tab
action create name description action_type
ACL → List Action Groups → click primary
action group → Create → fill in form → Create
action create name description action_type
action_group_name
ACL → List Action Groups → click action
group → Create → fill in form → Create
action delete name
ACL → List Action Groups → click primary
action group → select actions → Delete
action delete name action_group_name
ACL → List Action Groups → click action
group → select actions → Delete
action group create action_group_name
ACL → Create Action Group → type group
name → Create
action group delete action_group_name
ACL → List Action Groups → select action
groups → Delete
action group list
ACL → List Action Groups
action list
ACL → List Action Groups → click primary
action group
action list action_group_name
ACL → List Action Groups → click action
group
admin show configuration
Not supported
authzrule attach object_name ruleid
AuthzRule → List AuthzRule → click
authorization rule name → Attach tab →
Attach → type protected object path → Attach
authzrule create ruleid {–rulefile filename |
ruletext} [–desc description] [–failreason
failreason]
AuthzRule → Create AuthzRule → fill in
form → Create
authzrule delete ruleid
AuthzRule → List AuthzRule → select
authorization rule name → Delete
authzrule detach object_name
AuthzRule → List AuthzRule → click
authorization rule name → Attach tab → select
object names → Detach
authzrule find ruleid
AuthzRule → List AuthzRule → click
authorization rule name → Attach tab
authzrule list
AuthzRule → List AuthzRule
authzrule modify ruleid {–rulefile filename |
ruletext rule_text | description description |
failreason failreason
AuthzRule → List AuthzRule → click
authorization rule name → modify fields →
Apply
authzrule show ruleid
AuthzRule → List AuthzRule → click
authorization rule name
config modify svrpassword config_file
password
Not supported
Administration Guide
Table 8. Mapping between the pddamin utility and Web Portal Manager (continued)
pdadmin utility
Web Portal Manager
config modify keyvalue set [–obfuscate]
config_file stanza key value
Not supported
config modify keyvalue append
[–obfuscate] config_file stanza key value
Not supported
config modify keyvalue remove config_file
stanza key value
Not supported
config modify keyvalue remove config_file
stanza key
Not supported
config show config_file stanza key
Not supported
context show
Not supported
domain create domain domain_admin_id
domain_admin_password [–desc description]
Secure Domain → Create Secure Domain →
fill in form → Create
domain delete domain [–registry]
Secure Domain → List Secure Domain →
select secure domain names → Delete
domain list
Secure Domain → List Secure Domain
domain modify domain description
description
Secure Domain → List Secure Domain →
click secure domain name → modify
description → Apply
domain show domain
Secure Domain → List Secure Domain →
click secure domain name
errtext error_number
Not supported
exit
Not supported
group create group_name dn cn
[group_container]
Group → Create Group → fill in form →
Create
group delete [–registry] group_name
Group → Search Groups → type pattern and
maximum results → Search → select group
names → Delete
group import group_name dn
[group_container]
Group → Import Group → fill in form →
Import
group list pattern max_return
Group → Search Groups → type pattern and
maximum results → Search
group list-dn pattern max_return
Not supported
Group → Search Groups → type pattern and
maximum results → Search → click group
group modify group_name add (user_1 user_2 name → Members tab → select users → Add
[... user_n])
group modify group_name add user
group modify group_name description
description
Group → Search Groups → type pattern and
maximum results → Search → click group
name → type description → Apply
group modify group_name remove user
Group → Search Groups → type pattern and
maximum results → Search → click group
name → Members tab → select user names →
Remove
group modify group_name remove (user_1
user_2 [... user_n])
group show group_name
Group → Search Groups → type pattern and
maximum results → Search → click group
name
group show-dn dn
Not supported
Appendix E. pdadmin to Web Portal Manager equivalents
339
Table 8. Mapping between the pddamin utility and Web Portal Manager (continued)
pdadmin utility
Web Portal Manager
group show-members group_name
Group → Search Groups → type pattern and
maximum results → Search → click group
name → Members tab
help {topic | command}
Not supported
login –a admin_id –p password [–d domain |
–m]
Not supported
login –l
Not supported
logout
Not supported
object access object_name permissions
Not supported
object create object_name description type
ispolicyattachable {yes | no}
Object Space → Create Object → fill in form
→ Create
The type field is not supported.
You can select the Can Policy be attached to
this object check box on the Protected
Object Properties page.
340
object delete object_name
Object Space → Browse Object Space →
expand and click object name → Delete
object exists object_name
Not supported
object list
Object Space → Browse Object Space →
expand
object list object_name
Object Space → Browse Object Space →
expand and click object name
object list object_name attribute
Object Space → Browse Object Space →
expand and click object name → Extended
Attributes tab
object listandshow object_name
Not supported
object modify object_name delete
attribute_name
Object Space → Browse Object Space →
expand and click object name → Extended
Attributes tab → select attribute → Delete
object modify object_name delete
attribute_name attribute_value
Not supported
object modify object_name set attribute
attribute_name attribute_value
Object Space → Browse Object Space →
expand and click object name → Extended
Attributes tab → Create → fill in form →
Apply
object modify object_name set description
description
Object Space → Browse Object Space →
expand and click object name → modify
description → Apply
object modify object_name
isPolicyAttachable {yes | no}
Object Space → Browse Object Space →
expand and click object name → select or
clear check box→ Apply
object modify object_name type type
Not supported
object show object_name
Object Space → Browse Object Space →
expand and click object name
object show object_name attribute
attribute_name
Object Space → Browse Object Space →
expand and click object name → Extended
Attributes tab
Administration Guide
Table 8. Mapping between the pddamin utility and Web Portal Manager (continued)
pdadmin utility
Web Portal Manager
objectspace create objectspace_name
Object Space → Create Object Space → fill in
form → Create
objectspace delete objectspace_name
Object Space → Browse Object Space → click
object space name → Delete
objectspace list
Object Space → Browse Object Space
policy get policy_name
User → Show Global User Policy
policy get policy_name –user user_name
User → Search Users → type pattern and
maximum results → Search → click user name
→ Policy tab
policy set policy_name policy_value
User → Show Global User Policy → modify
value → Apply
policy set policy_name policy_value –user
user_name
User → Search Users → type pattern and
maximum results → Search → click user name
→ Policy tab → modify value → Apply
pop attach object_name pop_name
POP → List POP → click POP name → Attach
tab → Attach → type protected object path →
Attach
pop create pop_name
POP → Create POP → fill in form → Create
pop delete pop_name
POP → List POP → select POP names →
Delete
pop detach object_name
POP → List POP → click POP name → Attach
tab → select object → Detach
pop find pop_name
POP → List POP → click POP name → Attach
tab
pop list
POP → List POP
pop list pop_name
POP → List POP → click POP name
pop list pop_name attribute
POP → List POP → click POP name →
Extended Attributes tab
pop modify pop_name delete attribute
attribute_name
POP → List POP → click POP name →
Extended Attributes tab → select attributes →
Delete
pop modify pop_name delete attribute
attribute_name attribute_value
Not supported
pop modify pop_name set attribute
attribute_name attribute_value
POP → List POP → click POP name →
Extended Attributes tab → Create → fill in
form → Apply
pop modify pop_name set audit-level {all |
none | audit_level_list}
POP → List POP → click POP name → select
or clear appropriate check boxes → Apply
pop modify pop_name set description
description
POP → List POP → click POP name → modify
description → Apply
pop modify pop_name set ipauth add
network netmask authentication_level
POP → List POP → click POP name → IP
Auth tab → Create → type the network, net
mask, and authentication level → Apply
pop modify pop_name set ipauth add
network netmask forbidden
POP → List POP → click POP name → IP
Auth tab → Create → type network and net
mask and select Forbidden check box →
Apply
Appendix E. pdadmin to Web Portal Manager equivalents
341
Table 8. Mapping between the pddamin utility and Web Portal Manager (continued)
pdadmin utility
Web Portal Manager
pop modify pop_name set ipauth
anyothernw authentication_level
POP → List POP → click POP name → IP
Auth tab → Create → select Any Other
Network check box and type authentication
level → Create
pop modify pop_name set ipauth
anyothernw forbidden
POP → List POP → click POP name → IP
Auth tab → Create → select Any Other
Network and Forbidden check boxes →
Create
pop modify pop_name set ipauth remove
network netmask
POP → List POP → click POP name → IP
Auth tab → select IP authorization entries →
Delete
pop modify pop_name set qop {none |
integrity | privacy}
POP → List POP → click POP name → select
appropriate quality of protection → Apply
pop modify pop_name set tod-access {anyday POP → List POP → click POP name → define
| weekday | day_list}:{anytime |
time of day access → Apply
time_spec-time_spec}[:utc | local]
pop modify pop_name set warning {yes |
no}
POP → List POP → click POP name → select
or clear Warn Only On Policy Violation
check box → Apply
pop show pop_name
POP → List POP → click POP name
pop show pop_name attribute
POP → List POP → click POP name →
Extended Attributes tab
quit
Not supported
rsrc create resource_name [–desc description]
GSO Resource → Create GSO → fill in form →
Create
rsrc delete resource_name
GSO Resource → List GSO → select resources
→ Delete
rsrc list
GSO Resource → List GSO
rsrc show resource_name
GSO Resource → List GSO → click resource
User → Search Users → Search → click user
rsrccred create resource_name rsrcuser
resource_userid rsrcpwd resource_pwd rsrctype name → GSO Credentials tab → Create → fill
{web | group} user user_name
in form → Create
rsrccred create resource_group_name rsrcuser User → Search Groups → Search → click user
resource_userid rsrcpwd resource_pwd rsrctype name → GSO Credentials tab → Create → fill
{web | group} user user_name
in form → Create
rsrccred delete resource_name rsrctype {web | User → Search Users → Search → click user
group} user user_name
name → GSO Credentials tab → select
credentials → Delete
342
rsrccred delete resource_group_name rsrctype
{web | group} user user_name
User → Search Groups → Search → click user
name → GSO Credentials tab → select
credentials → Delete
rsrccred list user user_name
User → Search Users → Search → click user
name → GSO Credentials tab
rsrccred modify resource_name rsrctype {web
| group} [–rsrcuser resource_userid]
[–rsrcpwd resource_pwd] user user_name
User → Search Users → Search → click user
name → GSO Credentials tab → Create →
modify form → Create
Administration Guide
Table 8. Mapping between the pddamin utility and Web Portal Manager (continued)
pdadmin utility
Web Portal Manager
rsrccred modify resource_group_name
rsrctype {web | group} [–rsrcuser
resource_userid] [–rsrcpwd resource_pwd] user
user_name
User → Search Groups → Search → click user
name → GSO Credentials tab → Create →
modify form → Create
rsrccred show resource_name rsrctype {web |
group} user user_name
User → Search Users → Search → click user
name → GSO Credentials tab
rsrccred show resource_group_name rsrctype
{web | group} user user_name
User → Search Groups → Search → click user
name → GSO Credentials tab
rsrcgroup create resource_group_name [–desc
description]
GSO Resource → Create GSO Group → fill
in form → Create
rsrcgroup delete resource_group_name
GSO Resource → List GSO Groups → select
resource groups → Delete
rsrcgroup list
GSO Resource → List GSO Groups
rsrcgroup modify resource_group_name add
rsrcname resource_name
GSO Resource → List GSO Groups → select
resource group → select members → Add
rsrcgroup modify resource_group_name
remove rsrcname resource_name
GSO Resource → List GSO Groups → select
resource group → select members → Remove
rsrcgroup show resource_group_name
GSO Resource → List GSO Groups → select
resource group
server list
Not supported
server listtasks server_name
Not supported
server replicate server_name
Not supported
server show server_name
Not supported
server task server_name {help | stats |
trace}
Not supported
server task server_name server_task
Not supported
For more information about the WebSEAL
server tasks and junction points, see the IBM
Tivoli Access Manager for e-business: WebSEAL
Administration Guide.
user create [–gsouser] [–no-passwordpolicy] user_name dn cn sn password [group1
[group2 ...]]
User → Create User → fill in form → Create
user delete [–registry] user_name
User → Search Users → type pattern and
maximum results → Search → select user
names → Delete
user import [–gsouser] user_name dn
[group_name]
User → Import User → fill in form → Import
user list pattern max_return
User → Search Users → type pattern and
maximum results → Search
user list-dn pattern max_return
Not supported
user modify user_name account-valid {yes |
no}
User → Search Users → type pattern and
maximum results → Search → click user name
→ select or clear check box → Apply
user modify user_name password password
User → Search Users → type pattern and
maximum results → Search → click user name
→ modify password→ Apply
Appendix E. pdadmin to Web Portal Manager equivalents
343
Table 8. Mapping between the pddamin utility and Web Portal Manager (continued)
344
pdadmin utility
Web Portal Manager
user modify user_name password-valid {yes
| no}
User → Search Users → type pattern and
maximum results → Search → click user name
→ select or clear check box → Apply
user show user_name
User → Search Users → type pattern and
maximum results → Search → click user name
user show-dn dn
Not supported
user show-groups user_name
User → Search Users → type pattern and
maximum results → Search → click user name
→ Groups tab
Administration Guide
Appendix F. Managing user registries
This chapter contains a subset of user registry tasks that are specific to the
installation of Tivoli Access Manager. For common administrative tasks for your
particular registry (tasks that are not specific to Tivoli Access Manager), refer to the
documentation that came with your user registry product.
This chapter contains the following sections:
v “LDAP-specific tasks”
v “Active Directory-specific tasks” on page 362
v “Novell-specific tasks” on page 368
LDAP-specific tasks
LDAP is a protocol that runs over TCP/IP. The LDAP protocol standard includes
low-level network protocol definitions plus data representation and handling
functionality. A directory that is accessible through LDAP is commonly referred to
as an LDAP directory. An example of an LDAP server product is the Tivoli
Directory Server, which is included with Tivoli Access Manager.
This section contains the following topics:
v “LDAP failover configuration”
v “Using valid characters for LDAP user and group names” on page 349
v “Applying Tivoli Access Manager ACLs to new LDAP suffixes” on page 350
LDAP failover configuration
The Lightweight Directory Access Protocol (LDAP) defines a standard method for
accessing and updating information in a directory. Directories are usually accessed
using the client/server model of communication. Any server that implements
LDAP is an LDAP server.
The LDAP distributed architecture supports scalable directory services with server
replication capabilities. Server replication improves the availability of a directory
service. Tivoli Directory Server replication is based on a master-subordinate model.
Sun Java System Web Server replication is based on a supplier/consumer model,
which Tivoli Access Manager still treats as a master-subordinate or peer-to-peer
relationship.
Active Directory Application Mode (ADAM) replication is based on membership in
a configuration set, which is a group of ADAM instances that share and replicate a
common configuration partition and schema partition. ADAM uses a multi-master
form of replication, which means that any instance in the configuration set is
writable and will propagate the changes to all other instances in the configuration
set.
Note: ADAM instances cannot replicate with Active Directory, and they replicate
on a schedule that is completely independent of the Active Directory
replication schedule, even when ADAM is running in an Active Directory
domain.
© Copyright IBM Corp. 1999, 2010
345
Tivoli Access Manager treats each ADAM instance in a configuration set as a
replica. The Access Manager directory partition that contains the secAuthorityInfo
subtree must be replicated to each of the ADAM instances in the configuration set.
Note that the default replication schedule for ADAM is once per hour. This
schedule can be changed, but the most frequent rate at which ADAM will replicate
is four times an hour; updates to one instance in a configuration set will not be
propagated for at least fifteen minutes. Therefore, when Tivoli Access Manager is
used with ADAM, it is recommended that one instance in the configuration set is
configured to have a higher read/write preference than all other instances. This
way, updates are directed to the ADAM instance with the highest preference and
no other instances will be used as failover unless the preferred instance is down.
For information about setting the ADAM replication schedule, refer to ADAM
documentation. For information about setting preference values, see “Setting
preference values for replica LDAP servers” on page 348.
Note: When using SSL, the same Certificate Authority should issue the ADAM
certificate for each instance in the configuration set. This way, Tivoli Access
Manager can validate the ADAM certificate from each instance. If the
ADAM instances in the configuration set are on the same system, the
instances can share the same certificate.
When using a generic LDAP server, the failover configuration depends on the
specific LDAP server. As long as this LDAP server recognizes the concept of
master-subordinate, Tivoli Access Manager can use this replication support. For
information about whether your LDAP server supports replication in this manner,
see the documentation for your LDAP server.
The combination of a master server and multiple replicated servers helps to ensure
that directory data is always available when needed. If any server fails, the
directory service continues to be available from another replicated server. Tivoli
Access Manager supports this replication capability.
The master-subordinate replication model
Replication involves two types of directories: master/peer and replica. LDAP refers
to the master as the master server and to the replica as the replica server. Even
when peer-to-peer replication is being used, the peer servers can be considered
“masters” for the Tivoli Access Manager perspective. All updates are made on the
master server and these updates are subsequently propagated to the replica
servers. Each replica server directory contains a copy of the data in the master
server directory.
Changes to the directory can be made only to a master server, which is always
used for write operations to the directory. For Tivoli Access Manager, these types
of servers are configured as readwrite servers. Either the master or the replicas can
be used for read operations. When the original master server is out of service for
an extended period of time, a replica server can be promoted as a master server to
allow write operations to the directory.
Tivoli Access Manager failover capability for LDAP servers
Tivoli Access Manager connects to the LDAP master server (indicated by the host
key in the ldap.conf configuration file) when it starts up. If the LDAP master
server is down for any reason, the Tivoli Access Manager server must be able to
connect to an available LDAP replica server for any read operations.For Tivoli
Access Manager, these types of servers are configured as readonly servers.
346
Administration Guide
Many operations, especially those from regular users, are read operations. These
include operations such as user authentication and signon to back-end junctioned
Web servers. After proper configuration, Tivoli Access Manager performs failover
to a replica server when it cannot connect to the master server.
You can find the configuration parameters for LDAP failover in the [ldap] stanza
of the ldap.conf configuration file:
This configuration file is in one of the following operating system-specific
locations:
On Linux and UNIX operating systems
/opt/PolicyDirector/etc/ldap.conf
On Windows operating systems
install_path\etc\ldap.conf
Master server configuration
Tivoli Directory Server supports the existence of a single read-write master LDAP
server or multiple peer-to-peer read/write servers. Sun Java System Web Server
supports multiple read-write LDAP servers. Tivoli Access Manager treats the Sun
Java System supplier server as the master server for configuration purposes.
The active configuration lines in the ldap.conf file represent the parameters and
values for this master LDAP server. You determine these values during Tivoli
Access Manager configuration. For example:
[ldap]
enabled = yes
host = outback
port = 389
ssl-port = 636
max-search-size = 2048
Entity
Description
enabled
Tivoli Access Manager uses an LDAP user registry. Values are yes
and no.
host
The network name of the machine where the LDAP master
server is located. This server is assumed to be a readwrite server
with a preference of 5.
port
The TCP listening port of the LDAP master server.
ssl-port
The SSL listening port of the LDAP master server.
max-search-size
The Tivoli Access Manager limit for an LDAP client search of
database items - such as a request for the Web Portal Manager to
list users from the LDAP database.
If you make a change to the LDAP database, such as adding a new user account
through the Web Portal Manager, Tivoli Access Manager uses the read-write
(master) LDAP server.
Replica server configuration
Tivoli Directory Server supports the existence of one or more read-only replica
LDAP servers. Sun Java System Web Server supports the existence of one or more
read-only replica LDAP servers referred to as consumers.
You must add lines to the [ldap] stanza that identifies any replica servers available
to Tivoli Access Manager. Use the following syntax for each replica:
Appendix F. Managing user registries
347
replica = ldap_server,port,type,preference
Entity
Description
ldap-server
The network name of the LDAP replica server.
port
The port this server listens on. Generally, use 389 or 636.
type
The functionality of the replica server, which is either readonly or
readwrite. Normally, use read-only. A read-write type would
represent a master server.
preference
A number from 1 to 10. The server with the highest preference
value is chosen for LDAP connections. See “Setting preference
values for replica LDAP servers.”
Example:
replica = replica1.ldap.tivoli.com,389,readonly,4
replica = replica2.ldap.tivoli.com,389,readonly,4
Changes to the ldap.conf file do not take effect until you restart Tivoli Access
Manager.
Setting preference values for replica LDAP servers
Each replica LDAP server must have a preference value (1 to 10) that determines
its priority based on one of the following selections:
v The primary read-only access server
v A backup read-only server during a failover
The higher the number, the higher the priority. If the primary read-only server fails
for any reason, the server with the next highest preference value is used. If two or
more servers have the same preference value, a least-busy load balancing
algorithm determines which one is selected.
Remember that the master LDAP server can function as both a read-only and a
read-write server. For read-only access, the master server has a hardcoded default
preference setting of 5. This preference setting allows you to set replica servers at
values higher or lower than the master to obtain the required performance. For
example, with appropriate preference settings, you could prevent the master server
from handling everyday read operations.
You can set hierarchical preference values to allow access to a single LDAP server
(with failover to the other servers), or set equal preferences for all servers and
allow load balancing to dictate server selection.
The Table 9 illustrates some possible preference scenarios. “M” refers to the master
(read-only/read-write) LDAP server; “R1”, “R2” and “R3” refer to the replica
(read-only) LDAP servers.
Table 9. Potential preference scenarios
M
5
348
Administration Guide
R1
5
R2
5
R3
5
Failover preference
All servers have the same preference values. Load balancing
determines which server is selected for each access
operation.
Table 9. Potential preference scenarios (continued)
M
R1
R2
R3
Failover preference
5
6
6
6
The three replica servers have the same preference value.
This value is higher than the master server value. Load
balancing determines server selection among the three
replicas. The master is used only if all three replica servers
become unavailable.
5
6
7
8
Server 3 (with the highest preference value) becomes the
primary server. If server 3 fails, server 2 becomes the
primary server because it has the next highest preference
value.
Preference values affect only read-only access to the LDAP database. Tivoli Access
Manager always uses the master (read-write) server when you need to make a
change to the LDAP database.
Also note that some Tivoli Access Manager daemons (such as the policy server)
override the preference settings in their configuration files to indicate that the
read-write server is preferred. This override occurs because those daemons usually
make update operations that should go to the master LDAP server.
Server polling
If an LDAP server does fail, Tivoli Access Manager continuously polls the server to
check for its return to active duty. The poll time is 10 seconds.
Using valid characters for LDAP user and group names
When using LDAP as the user registry, the set of valid characters allowed within a
user or group name is determined by the following Internet Engineering Task
Force (IETF) Request for Comments (RFC):
v 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of
Distinguished Names
v 2254 The String Representation of LDAP Search Filters
The specific LDAP server can also dictate the validity of these characters.
In general, you can use special characters within a distinguished name. However,
certain special characters require an additional escape character. The following
special characters must be escaped when used in a distinguished name:
v Plus sign (+)
v Semicolon (;)
v Comma (,)
For example, to create a user containing a semicolon using the pdadmin utility:
pdadmin> user create "user;one" "cn=user\;one,o=tivoli,c=us"
"user;one" "user;one" password1
Note: Avoid using the backward slash character (\) as part of a user or group
name. For more information, see "Characters disallowed for user and group
name" in Appendix A of the IBM Tivoli Access Manager for e-business:
Command Reference.
If you use special characters when using the pdadmin utility, enclose each
argument of the user or group command with double quotation marks. The double
Appendix F. Managing user registries
349
quotation marks allow the argument to be entered without being subject to
interpretation by the operating system shell command processor.
Due to the variability of special character handling in general, avoid using special
characters.
Applying Tivoli Access Manager ACLs to new LDAP suffixes
Generally, the LDAP naming model is maintained in a hierarchical namespace
known as the Directory Information Tree (DIT). Many LDAP server products, such
as Tivoli Directory Server, which is included with Tivoli Access Manager, and the
Sun Java System Web Server and Novell eDirectory, maintain the data of the DIT
in a hierarchical namespace that is often represented as a tree structure. The top of
the tree is referred to as a naming context. Sometimes, this naming context is called
a suffix, because it represents the ending portion of a distinguished name (DN). For
example, the c=us suffix might be created to represent country-specific data within
an organization. An entry within this suffix might have a DN similar to cn=Joe
Williams,ou=austin,o=ibm,c=us. The set of suffixes that is maintained by the
LDAP server can be configured using the vendor-specific LDAP administration
tools.
When the Tivoli Access Manager policy server is configured, it attempts to apply
appropriate access controls in the form of Access Control Lists (ACLs) to each
LDAP suffix that is in the LDAP server. This access control gives appropriate
permissions to allow Tivoli Access Manager to create and manage user and group
information in these suffixes.
Note: The Tivoli Access Manager policy server does not attempt to apply ACLs to
each LDAP suffix when ADAM is used as the user registry. Access to
ADAM registry entries is controlled by administration groups within
ADAM.
For LDAP server types other than ADAM, if an LDAP administrator adds an
LDAP suffix after Tivoli Access Manager is configured and wants Tivoli Access
Manager to manage users and groups in this new suffix, the appropriate ACLs
must be applied to the new suffix.
To apply the appropriate access controls to a newly created LDAP suffix, use the
ivrgy_tool utility with the add-acls parameter. For more information, see
"ivrgy_tool" in the IBM Tivoli Access Manager for e-business: Command Reference.
Alternately, you can manually apply the following ACLs to each new suffix:
cn=SecurityGroup,secAuthority=Default
v Full access
cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default
v read
v search
v compare
v write for the following attributes:
– secAcctValid
– secPwdFailCountTime
– secPwdFailures
– secPwdLastChanged
– secPwdLastFailed
– secPwdLastUsed
– secPwdUnlockTime
– secPwdValid
350
Administration Guide
cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default
v read
v search
v compare
v write for the following attributes:
– secAcctValid
– secPwdFailCountTime
– secPwdFailures
– secPwdLastChanged
– secPwdLastFailed
– secPwdLastUsed
– secPwdUnlockTime
– secPwdValid
When using a generic LDAP server, the same access controls should be given to
the specified groups. For information about how to set access control for a generic
LDAP server, see the documentation that is associated with the generic LDAP
server.
If a Tivoli Access Manager administrator created a domain other than the initial
\Management domain, which is created during the configuration of the policy
server, the following additional ACLs should be applied to the new suffix for each
domain:
cn=SecurityGroup,secAuthority=domain_name,cn=Subdomains,
secAuthority=Default
v Full access
cn=ivacld-servers,cn=SecurityGroups,secAuthority=domain_name,cn=Subdomains,
secAuthority=Default
v read
v search
v compare
v write for the following attributes:
– secAcctValid
– secPwdFailCountTime
– secPwdFailures
– secPwdLastChanged
– secPwdLastFailed
– secPwdLastUsed
– secPwdUnlockTime
– secPwdValid
cn=remote-acl-users,cn=SecurityGroups,secAuthority=domain_name,
cn=Subdomains,secAuthority=Default
v read
v search
v compare
v write for the following attributes:
– secAcctValid
– secPwdFailCountTime
– secPwdFailures
– secPwdLastChanged
– secPwdLastFailed
– secPwdLastUsed
– secPwdUnlockTime
– secPwdValid
Appendix F. Managing user registries
351
Where domain_name is the name of the additional administrative domain. For a list
of domains, use the domain list command.
Example procedures
The following example procedures can be used for either Tivoli Directory Server or
Sun Java System Web Server, depending on the LDAP server type being used. The
following example procedures assume the newly created c=fr suffix. Substitute
your newly created suffix for this value in the following procedures.
Tivoli Directory Server: This procedure describes how to apply the appropriate
Tivoli Access Manager access controls in Tivoli Directory Server for a newly
created suffix. This procedure uses the Tivoli Directory Server Web Administration
Tool and assumes that this tool is installed and configured into the WebSphere
Application Server.
1. Access the login page using a supported Web browser. The default login page
is the following URL:
http://server_name:12100/IDSWebApp/IDSjsp/Login.jsp
Where server_name is the host name of the application server where the Web
Administration Tool is installed.
If the list of console server contains the LDAP server to be administered, select its
host name and go to step 4. If this list does not contain the server, add it as a
console server.
2. Add an LDAP server to the list of console servers:
a. Log in as the Console Admin. The default Console Admin identity is
superadmin and the default password is secret.
b. In the navigation area on the left, click Console administration and
Manage console servers. This action presents a list of LDAP servers that
are currently configured for administration.
c. Click Add and type the host name and port number for the LDAP server
to be administered.
d. Click OK to add the server.
e. Click Close to complete the action.
f. From the navigation area, click Logout.
3. Access the login page using the URL in step 1 and select from the list the
LDAP server that you added.
4. In the Login window, type the LDAP server administrator in the Username
field (for example, cn=root) and password in the password field, and click
Login.
5. In the navigation area on the left, click Directory management and Manage
entries.
If you see the newly added suffix in the Manage entries window on the right, go
to step 7 on page 353. If you do not see the newly added suffix, add an entry for a
newly created suffix.
6. Add a suffix:
a. Click Add to display the Add an entry window.
b. Select the appropriate structural object class for the newly added suffix.
For the c=fr suffix, the appropriate object class is country.
c. Click Next to display the Select auxiliary object classes window where you
can add additional object classes appropriate for the entry type.
d. Because this example does not use other object classes, click Next to define
the selected structural object class.
352
Administration Guide
e. In the Relative DN field, type c=fr and leave the Parent DN field blank.
The only required attribute is c for country. Fill in the value fr, and click
Finish to return to the Manage entries window. You should now see the
newly added suffix in the list of top-level entries.
7. In the Manage entries window:
a. From the Select column, select the suffix.
b. From the Select Action list, select Edit ACL.
c. Click Go to display the Edit ACL window that shows the current ACLs on
the suffix.
8. In the Edit ACL window:
a.
b.
c.
9. In
a.
Click Non-filtered ACLs.
Ensure that the Propagate ACLs option is selected.
Click Add to display the Add access rights window.
the Add access rights window:
In the Subject DN (distinguished name) field, type
cn=SecurityGroup,secAuthority=Default.
b. Set the Add child right to grant.
c. Set the Delete entry right to grant.
d. Set the normal, sensitive, critical, system and restricted security classes to
grant for the read, write, search, and compare actions.
e. Click OK to return to the Edit ACL window.
10. In the Edit ACL window, click Add to display the Add access rights window.
11. In the Add access rights window:
a. In the Subject DN (distinguished name) field, type cn=ivacldservers,cn=SecurityGroups,secAuthority=Default.
b. Set the Subject Type to group.
c. Set the normal security classes to grant for the read, search, and compare
actions.
d. From the Attributes list, select secAcctValid and click Define. Repeat this
step for each of the following attributes:
v secPwdFailCountTime
v secPwdFailures
v secPwdLastChanged
v secPwdLastFailed
v secPwdLastUsed
v secPwdUnlockTime
v secPwdValid
e. After defining these attributes, set each of these attributes to grant for the
read, write, search, and compare actions.
f. Click OK to return to the Edit ACL window.
If you have other domains and need to add domain ACLs, continue to step 12. If
you have no further domains, this completes the access control. Go to step 17 on
page 354. This sample procedure has additional domains the require domain ACLs.
12. In the Edit ACL window, click Add to display the Add access rights window.
In the Add access rights window:
a. In the Subject DN (distinguished name) field, type
cn=SecurityGroup,secAuthority=domain_name,cn=Subdomains,
secAuthority=Default, where domain_name is the domain name being
protected.
Appendix F. Managing user registries
353
b. Set the Add child right to grant.
c. Set the Delete entry right to grant.
d. Set the normal, sensitive, critical, system and restricted security classes to
grant for the read, write, search, and compare actions.
e. Click OK to return to the Edit ACL window.
13. In the Edit ACL window, click Add to display the Add access rights window.
14. In the Add access rights window:
a. In the Subject DN (distinguished name) field, type cn=ivacldservers,cn=SecurityGroups,secAuthority=domain_name,cn=Subdomains,
secAuthority=Default, where domain_name is the domain name being
protected.
b. Set the Subject Type to group.
c. Set the normal security classes to grant for the read, search, and compare
actions.
d. From the Attributes list, select secAcctValid and click Define. Repeat this
step for each of the following attributes:
v secPwdFailCountTime
v secPwdFailures
v secPwdLastChanged
v secPwdLastFailed
v secPwdLastUsed
v secPwdUnlockTime
v secPwdValid
e. After defining these attributes, set each of these attributes to grant for the
read, write, search, and compare actions.
f. Click OK to return to the Edit ACL window.
15. In the Edit ACL window, click Add to display the Add access rights window.
16. In the Add access rights window:
a. In the Subject DN (distinguished name) field, type cn=remote-aclusers,cn=SecurityGroups,secAuthority=domain_name,cn=Subdomains,
secAuthority=Default, where domain_name is the domain name being
protected.
b. Set the Subject Type to group.
c. Set the normal security classes to grant for the read, search, and compare
actions.
d. From the Attributes list, select secAcctValid and click Define. Repeat this
step for each of the following attributes:
v secPwdFailCountTime
v secPwdFailures
v secPwdLastChanged
v secPwdLastFailed
v secPwdLastUsed
v secPwdUnlockTime
v secPwdValid
e. After defining these attributes, set each of these attributes to grant for the
read, write, search, and compare actions.
f. Click OK to return to the Edit ACL window.
This completes the addition of the access control for the suffix.
17. Click Close.
You do not need to restart the LDAP server for the changes to take affect.
354
Administration Guide
18. If you no longer need to use the Web Administration Tool, click Logout.
Sun Java System Web Server: The following procedure describes how to apply
the appropriate Tivoli Access Manager access controls to the newly created suffix
for Sun Java System Web Server. This procedure uses the Sun Java System Server
Console, version 5.2.
1. Start the Sun Java System Server Console using one of the following
commands:
v On Linux and UNIX operating systems, enter the following command from
the Sun Java System Web Server installation directory:
# ./startconsole
v On systems running the Solaris operating environment, when not using the
Solaris packaged version:
a. Change to the server root directory.
b. Enter the following command:
startconsole arguments
c. Type –h to display a usage message explaining command line
arguments.
v On Windows operating systems, select Start Programs Sun Java System
Server Products Sun Java System Server Console Version 5.2.
2. Log in to the Sun Java System Server Console:
a. Type the LDAP administrator ID, which is usually cn=Directory Manager
b. Type the password for this administrator.
c. Click OK.
3. Select the Sun Java System Domain to be used by Tivoli Access Manager.
4. Expand the server name and Server Group.
5. Select Directory Server to display the configuration information about the Sun
Java System Directory server.
6. Click Open to access the Sun Java System Directory server.
7. Click the Directory tab. If the newly created suffix is displayed on the left
pane, go to step 8. If the newly created suffix is not displayed, create an entry
for the new suffix before applying access controls to the suffix.
Note: These instructions assume an example suffix. Create the entry type and
name that corresponds to your actual suffix.
To create the entry:
a. Right-click the name of the server at the top of the directory tree, and
select Object → New Root Object to display a list of root suffixes.
b. Select c=fr from the list of root suffixes. The New Object selection window
is displayed.
c. In the New Object selection window, scroll down and select Country as
the new object entry type.
d. Click OK to display the Property Editor window.
e. In the Country field type fr, and click OK.
f. Select View → Refresh to display the new suffix.
8. Right-click c=fr in the left pane, and select Object → Set Access Permissions to
display the Manage Access Control for c=fr window.
9. Click New to display the Edit ACI for c=fr window.
10. In the Edit ACI for c=fr window:
Appendix F. Managing user registries
355
a.
b.
c.
d.
In the ACI name field, type SECURITY GROUP – ALLOW ALL.
Highlight All Users, and click Remove.
Click Edit Manually.
Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="*")
(version 3.0; acl "SECURITY GROUP – ALLOW ALL";
allow (all)
groupdn = "ldap:///cn=SecurityGroup,secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
11. Click New to display the Edit ACI for c=fr window.
12. In the Edit ACI for c=fr window:
a. In the ACI name field, type PD Servers GROUP – ALLOW READ.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="*")
(version 3.0; acl "PD Servers GROUP – ALLOW READ";
allow (read, search, compare)
groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups,
secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
13. Click New to display the Edit ACI for c=fr window.
14. In the Edit ACI for c=fr window:
a. In the ACI name field, type SECURITY GROUP– ALLOW WRITE.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="secAcctValid ||
secPwdFailCountTime || secPwdFailures || secPwdLastChanged ||
secPwdLastFailed || secPWDLastUsed || secPwdUnlockTime ||
secPwdValid")
(version 3.0; acl "SECURITY GROUP– ALLOW WRITE";
allow (read, search, compare)
groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups,
secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
15. Click New to display the Edit ACI for c=fr window.
16. In
a.
b.
c.
d.
356
Administration Guide
the Edit ACI for c=fr window:
In the ACI name field, type PD Remote ACL Users GROUP – ALLOW READ.
Highlight All Users, and click Remove.
Click Edit Manually.
Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="*")
(version 3.0; acl "PD Remote ACL Users GROUP – ALLOW READ";
allow (read, search, compare)
groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups,
secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
17. Click New to display the Edit ACI for c=fr window.
18. In the Edit ACI for c=fr window:
a. In the ACI name field, type SECURITY GROUP– ALLOW WRITE.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="secAcctValid ||
secPwdFailCountTime || secPwdFailures || secPwdLastChanged ||
secPwdLastFailed || secPWDLastUsed || secPwdUnlockTime ||
secPwdValid")
(version 3.0; acl "SECURITY GROUP– ALLOW WRITE";
allow (read, search, compare)
groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups,
secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
19. Click New to display the Edit ACI for c=fr window.
20. In the Edit ACI for c=fr window:
a.
b.
c.
d.
In the ACI name field, type PD Deny-Others.
Highlight All Users, and click Remove.
Click Edit Manually.
Replace the default ACI text with the following text:
(targetfilter="(secAuthority=Default)")
(version 3.0; acl "PD Deny-Others";
deny(all)
groupdn != "ldap:///cn=SecurityGroup,secAuthority=Default||
ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default||
ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
If you have no further domains, this completes the access control. You can skip to
step 33 on page 359. If you have additional domains and need to add domain
ACLs, continue with step 21.
21. Click New to display the Edit ACI for c=fr window.
22. In the Edit ACI for c=fr window:
a. In the ACI name field, type SECURITY GROUP – ALLOW ALL.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
Appendix F. Managing user registries
357
(target="ldap:///c=fr")(targetattr="*")
(version 3.0; acl "SECURITY GROUP - ALLOW ALL;
allow (all)
groupdn = "ldap:///cn=SecurityGroup,secAuthority=domain_name,
cn=Subdomains,secAuthority=Default";)
where domain_name is the name of the domain being protected.
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
23. Click New to display the Edit ACI for c=fr window.
24. In the Edit ACI for c=fr window:
a. In the ACI name field, type PD Servers GROUP – ALLOW READ.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="*")
(version 3.0; acl "PD Servers GROUP - ALLOW READ";
allow (read, search, compare)
groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups,
secAuthority=domain_name,cn=Subdomains,secAuthority=Default";)
where domain_name is the name of the domain being protected.
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
25. Click New to display the Edit ACI for c=fr window.
26. In the Edit ACI for c=fr window:
a. In the ACI name field, type SECURITY GROUP– ALLOW WRITE.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="secAcctValid ||
secPwdFailCountTime || secPwdFailures || secPwdLastChanged ||
secPwdLastFailed || secPWDLastUsed || secPwdUnlockTime ||
secPwdValid")
(version 3.0; acl "SECURITY GROUP– ALLOW WRITE";
allow (read, search, compare)
groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups,
secAuthority=domain_name,cn=Subdomains,secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
27. Click New to display the Edit ACI for c=fr window.
28. In the Edit ACI for c=fr window:
a. In the ACI name field, type PD Remote ACL Users GROUP – ALLOW READ.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
358
Administration Guide
(target="ldap:///c=fr")(targetattr="*")
(version 3.0; acl "PD Remote ACL Users GROUP - ALLOW READ";
allow (read, search, compare)
groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups,
secAuthority=domain_name,cn=Subdomains,secAuthority=Default";)
where domain_name is the name of the domain being protected.
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
29. Click New to display the Edit ACI for c=fr window.
30. In the Edit ACI for c=fr window:
a. In the ACI name field, type SECURITY GROUP– ALLOW WRITE.
b. Highlight All Users, and click Remove.
c. Click Edit Manually.
d. Replace the default ACI text with the following text:
(target="ldap:///c=fr")(targetattr="secAcctValid ||
secPwdFailCountTime || secPwdFailures || secPwdLastChanged ||
secPwdLastFailed || secPWDLastUsed || secPwdUnlockTime ||
secPwdValid")
(version 3.0; acl "SECURITY GROUP– ALLOW WRITE";
allow (read, search, compare)
groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups,
secAuthority=domain_name,cn=Subdomains,secAuthority=Default";)
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
31. Click New to display the Edit ACI for c=fr window.
32. In the Edit ACI for c=fr window:
a.
b.
c.
d.
In the ACI name field, type PD Deny-Others.
Highlight All Users, and click Remove.
Click Edit Manually.
Replace the default ACI text with the following text:
(targetfilter="(secAuthority=domain_name)")
(version 3.0; acl "PD Deny-Others";
deny(all)
groupdn != "ldap:///cn=SecurityGroup,secAuthority=Default||
ldap:///cn=SecurityGroup,secAuthority=domain_name,cn=Subdomains,
secAuthority=Default||
ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=domain_name,
cn=Subdomains,secAuthority=Default||
ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=domain_name,
cn=Subdomains,secAuthority=Default";)
where domain_name is the name of the domain being protected.
e. Click Check Syntax to ensure validate the text. Correct errors until the
syntax validates.
f. Click OK to return to the Manage Access Control for c=fr window.
If there are further domains, repeat steps 21 on page 357 to 32. For each domain.
When complete, continue with step 33.
33. Click OK to close the Manage Access Control for c=fr window.
34. Click Console → Exit to exit the console.
Appendix F. Managing user registries
359
IBM z/OS Security Server: This procedure describes how to apply the
appropriate Tivoli Access Manager access controls to the newly created suffix for
IBM z/OS Security Server after the Tivoli Access Manager policy server is
configured. Instead of using the manual process described below, you can use the
ivrgy_tool utility to update the ACLs on suffixes added after the initial policy
server configuration. For information about using this utility, see "ivrgy_tool" in the
Installation Guide.
These steps are specifically for the IBM z/OS Security Server LDAP Server version
1.4, the IBM z/OS Integrated Security Services LDAP Server Version 1.6, and the
IBM Tivoli Directory Server for z/OS Version 1.8. Hereafter, these LDAP servers
are referred to as the IBM z/OS LDAP Server.
To add a suffix for the IBM z/OS LDAP Server manually:
1. Add the new suffix to the LDAP server configuration file. See z/OS LDAP
Server Administration and Use for your version of z/OS LDAP for details on
how to update the server configuration file.
2. Restart the IBM z/OS LDAP Server.
3. To add an entry to the newly created suffix, perform the following steps:
a. Create an LDIF file. This example assumes the newly created suffix is
o=neworg,c=us:
dn: o=neworg,c=us
objectClass: organization
objectClass: top
o: neworg
b. Use the appropriate LDIF file as input to the ldapadd command:
ldapadd -h ldap_host -p ldap_port -D ldap_admin_dn -w ldap_admin_pwd
-v -f ldif_filename
4. To apply the appropriate Tivoli Access Manager access controls to the newly
created suffix (suffix), do either of the following tasks:
v If no additional Access Manager domains were created other than the initial
management domain, complete the following steps:
a. Create the following LDIF file:
dn: suffix
aclpropagate: TRUE
aclentry: group:cn=SecurityGroup,secAuthority=Default:object:ad:normal:\
rwsc:sensitive:rwsc:critical:rwsc:restricted:rwsc
aclentry: group:cn=ivacld-servers,cn=SecurityGroups,secAuthority=Defaul\
t:normal:rsc:at.secAcctValid:rwsc:at.secPwdFailCountTime:rwsc:at.secPwd\
Failures:rwsc:at.secPwdLastChanged:rwsc:at.secPwdLastFailed:rwsc:at.sec\
PwdLastUsed:rwsc:at.secPwdUnlockTime:rwsc:at.secPwdValid:rwsc
aclentry: group:cn=remote-acl-users,cn=SecurityGroups,secAuthority=Defau\
lt:normal:rsc:at.secAcctValid:rwsc:at.secPwdFailCountTime:rwsc:at.secPwd\
Failures:rwsc:at.secPwdLastChanged:rwsc:at.secPwdLastFailed:rwsc:at.secP\
wdLastUsed:rwsc:at.secPwdUnlockTime:rwsc:at.secPwdValid:rwsc
entryowner: LDAP_admin_dn
entryowner: group:cn=SecurityGroup,secAuthority=Default
ownerpropagate: TRUE
The backward slash ( \ ) at the end of a line indicates that this line
combines with the next line, without any spaces.
b. Apply the updates in the LDIF file by using it as input to the ldapmodify
command:
ldapmodify -h ldap_host -p ldap_port -D ldap_admin_dn
-w ldap_admin_pwd -v -f ldif_file
360
Administration Guide
v If a domain was created in addition to the initial management domain, and if
a new suffix is created, ACLs need to be applied for each added domain.
Complete the following steps:
a. Add ACLs to the default domain and added domain (added_domain) by
creating an LDIF file similar to the following one:
dn: suffix
aclentry: group:cn=SecurityGroup,secAuthority=Default:object:ad:normal\
:rwsc:sensitive:rwsc:critical:rwsc:restricted:rwsc
aclentry: group:cn=ivacld-servers,cn=SecurityGroups,secAuthority=Defau\
lt:normal:rsc:at.secAcctValid:rwsc:at.secPwdFailCountTime:rwsc:at.secP\
wdFailures:rwsc:at.secPwdLastChanged:rwsc:at.secPwdLastFailed:rwsc:at.\
secPwdLastUsed:rwsc:at.secPwdUnlockTime:rwsc:at.secPwdValid:rwsc
aclentry: group:cn=remote-acl-users,cn=SecurityGroups,secAuthority=Def\
ault:normal:rsc:at.secAcctValid:rwsc:at.secPwdFailCountTime:rwsc:at.se\
cPwdFailures:rwsc:at.secPwdLastChanged:rwsc:at.secPwdLastFailed:rwsc:a\
t.secPwdLastUsed:rwsc:at.secPwdUnlockTime:rwsc:at.secPwdValid:rwsc
aclentry: group:cn=SecurityGroup,secAuthority=added_domain,cn=Subdomai\
ns,secAuthority=Default:object:ad:normal:rwsc:sensitive:rwsc:critical:\
rwsc:restricted:rwsc
aclentry: group:cn=ivacld-servers,cn=SecurityGroups,secAuthority=added\
_domain,cn=Subdomains,secAuthority=Default:normal:rsc:at.secAcctValid:\
rwsc:at.secPwdFailCountTime:rwsc:at.secPwdFailures:rwsc:at.secPwdLastC\
hanged:rwsc:at.secPwdLastFailed:rwsc:at.secPwdLastUsed:rwsc:at.secPwdU\
nlockTime:rwsc:at.secPwdValid:rwsc
aclentry: group:cn=remote-acl-users,cn=SecurityGroups,secAuthority=add\
ed_domain,cn=Subdomains,secAuthority=Default:normal:rsc:at.secAcctVali\
d:rwsc:at.secPwdFailCountTime:rwsc:at.secPwdFailures:rwsc:at.secPwdLas\
tChanged:rwsc:at.secPwdLastFailed:rwsc:at.secPwdLastUsed:rwsc:at.secPw\
dUnlockTime:rwsc:at.secPwdValid:rwsc
aclpropagate: TRUE
entryowner: LDAP_admin_dn
entryowner: group:cn=SecurityGroup,secAuthority=Default
ownerpropagate: TRUE
b. Apply the updates in the LDIF file by using it as input to the ldapmodify
command:
ldapmodify -h ldap_host -p ldap_port -D ldap_admin_dn -w ldap_admin_pwd
-v -f ldif_file
Note: The ldapmodify command returns an error if the following attributes and
values are set by default for the newly added suffix:
aclpropagate: TRUE
entryowner: LDAP_admin_dn
ownerpropagate: TRUE
If the ldapmodify command returns the following error, remove these three
attribute and value pairs from the LDIF file and run the ldapmodify
command again:
ldapmodify: additional info: R004086 Entry ’suffix’ already contains
attribute ’attribute’ with value ’value’
Setting the password history policy
When using Tivoli Directory Server as your user registry, you can take advantage
of its password history policy. To enable this policy, complete the following steps:
1. Access the login page using a supported Web browser. The default login page
is the following URL:
http://server_name:12100/IDSWebApp/IDSjsp/Login.jsp
Where server_name is the host name of the application server where the Web
Administration Tool is installed.
Appendix F. Managing user registries
361
2. Select the LDAP Host name to be managed and log in as an LDAP
administrator (for example, cn=root). The Web Administration Tool starts.
3. In the navigation area, select Server administration Manage security
properties.
4. In the main window, select Password validation.
5. Set the minimum number of passwords that must be used before a password
can be reused. Enter a number from 0 to 30. If you enter zero, a password can
be reused without restriction.
6. Click Apply.
7. In the main window, click Password policy.
8. If not already enabled, set the Password policy enabled check box to enable
password policy.
9. Click OK.
For more information about setting the password policy that is used with Tivoli
Directory Server, see the IBM Tivoli Directory Server: Administration Guide.
Active Directory-specific tasks
Microsoft Active Directory is an infrastructure supported by Windows 2003 that
includes a network management of directory objects, and has the capability to
communicate with other directory services.
This section contains the following topics:
v “Setting up Microsoft Windows 2003 Domain Name System for Active
Directory”
v “Updating the Tivoli Access Manager schema” on page 363
v “Adding a Tivoli Access Manager user to the Active Directory system group” on
page 364
v “Using valid characters for Active Directory user, group, and distinguished
names” on page 364
v “Importing dynamic groups to Tivoli Access Manager” on page 366
v “Enabling change user password requests to be performed using LDAP APIs”
on page 366
Setting up Microsoft Windows 2003 Domain Name System for
Active Directory
Active Directory uses the Domain Name System (DNS) as a domain controller
location mechanism. DNS enables computers to find the IP addresses of the
domain controllers.
For multi-domain mode, at least two domains are required from these types of
domains:
v A primary domain
v A child domain of the primary domain
v A domain tree in the forest
For failover, at least two primary domain controllers are needed.
You can set up the DNS server before configuring the domain controllers or when
you configure the primary Active Directory domain controller. There are two ways
to set up DNS for Active Directory:
362
Administration Guide
1. Configure DNS on the forest root
2. Use a separate DNS server
If configuring DNS on the forest root, DNS is configured automatically on that
host if this is the first domain controller configured. This domain controller and its
replicas serve as the DNS servers.
The DNS server is not necessary on the host that is the domain controller in the
forest. You can use any DNS server. If you are not using a Windows-based DNS
server, contact your DNS administrator or a DNS server vendor to find out
whether your server supports the required standards. If the server does not
support the required standards or the zone cannot be configured to allow dynamic
updates, you need to modify the existing DNS infrastructure.
Adding a new domain name to a DNS
To add a new domain name to a DNS, do the following:
1. Click Start → Programs → Administrator Tools → DNS to open the DNS.
2. Expand the host name, and expand Forward Lookup Zones.
3. Create a new zone (new root domain) or child domain.
4. If using a separate DNS, open the domain properties and change the Allow
dynamic updates field to Yes.
Updating the Tivoli Access Manager schema
To perform all Tivoli Access Manager operations, you need to add a Tivoli Access
Manager schema on Active Directory. TheTivoli Access Manager schema needs to
be added to the schema master. The master schema is a root domain controller in
the forest. The Tivoli Access Manager schema is updated to the schema master
during the configuration of Tivoli Access Manager.
Note: Before updating the Tivoli Access Manager schema, verify that it is not
already on the schema master. The Tivoli Access Manager schema needs to
be updated only once in the forest.
To verify that the Tivoli Access Manager schema is updated on your system,
complete the following steps:
1. In your domain controller, go to Start → Programs → Administrative Tools →
Active Directory Users and Computers. The Active Directory Users and
Computers window is displayed.
2. In this window, expand the domain that contains the Users folder.
3. Right click the Users folder. A menu opens.
4. Click New in the menu. Another menu opens.
5. If a list of Tivoli Access Manager classes for Active Directory is displayed in the
menu in the URAF-xxx form, (for example, URAF-container), then the Tivoli
Access Manager schema is already on the schema master. You do not need to
update the Tivoli Access Manager schema.
To manually update the Tivoli Access Manager schema, complete the following
steps:
1. Install Tivoli Access Manager runtime on the root domain controller.
2. Run the following command:
aminstall_dir\sbin\adschema_update –u AMConfID –p AMConfPWD
where:
Appendix F. Managing user registries
363
v aminstall_dir is the directory that installs Tivoli Access Manager
v AMConfID is the Tivoli Access Manager configuration login ID
v AMConfPWD is the Tivoli Access Manager configuration login password
3. After you verify that the Tivoli Access Manager schema was added to the
schema master, you can uninstall Tivoli Access Manager runtime from the root
domain.
Note: The Tivoli Access Manager schema propagation takes approximately five
minutes from the schema master to add to the non-root domain controller.
Adding a Tivoli Access Manager user to the Active Directory
system group
To have sufficient access to modify user and group attributes, a Tivoli Access
Manager user must be added to the appropriate Active Directory system group. To
add a user to an Active Directory system group on a system where Active
Directory is configured as a Tivoli Access Manager user registry, and do the
following:
1. Log in as Administrator.
2. Go to Start → Programs → Administrative Tools.
3. Click Active Directory Users and Computers from the menu. The Active
Directory Users and Computers window is displayed.
4. On the left navigation panel, go to Tivoli PD Domains → default → system →
users, where the users container of the Tivoli Access Manager user registry
container is located.
5. From the list of users displayed, select the Tivoli Access Manager user that
you want to add to the Active Directory system group.
6. Right-click the Tivoli Access Manager user, and click Properties. The
Properties window for the selected Tivoli Access Manager user is displayed.
7. Click the Member Of tab.
8. Click Add. The Select Groups window is displayed.
9. Select the appropriate group that you want the Tivoli Access Manager user to
become a member of, and click Add.
10. Do one of the following:
v If the purpose is to modify user or group attributes for Active Directory
single domain, select the Domain Admins group.
v If Tivoli Access Manager is configured using Active Directory multiple
domain, select the Enterprise Admins group.
11. For each user you want to add to multiple groups, repeat the
add-user-to-group process.
12. Click OK to close all opened windows.
Using valid characters for Active Directory user, group, and
distinguished names
This section describes how to specify valid characters for Active Directory user
names, group names, and distinguished names (DNs). In version 6.0, Tivoli Access
Manager added support to handle special characters for DNs, (as described in RFC
1779 and RFC 2253).
364
Administration Guide
Attention: If you upgraded the policy server to Tivoli Access Manager, version
6.0, but did not upgrade the blade servers, you can create and import users
containing special characters. However, these users cannot authenticate at the
Tivoli Access Manager blade level (version 3.9, 4.1, or 5.1).
User and group names
Active Directory user and group names can contain all Unicode characters except
for the following characters:
v Forward slash (/)
v Backward slash (\)
v Left square bracket ([)
v Right square bracket (])
v Colon (:)
v Semicolon (;)
v Vertical bar (|)
v Equal sign (=)
v Plus sign (+)
v Asterisk (*)
v Question mark (?)
v Left angle bracket (<)
v Right angle bracket (>)
v Double quote (")
v At symbol (@)
Note: An "at" symbol (@) is not allowed unless it is used to specify the domain.
For example, user@mydomain.com is allowed; user@name@mydomain.com is
not allowed.
If you use special characters when using the pdadmin utility, enclose each
argument of the user or group command with double quotation marks. The double
quotation marks allow the argument to be entered without being subject to
interpretation by the operating system shell command processor.
Due to the variability of special character handling in general, avoid using special
characters.
User and group distinguished names
There are special characters that are not allowed in a distinguished name (DN)
unless the character is preceded by an additional escape character or is encoded in
hexadecimal. To encode in hexadecimal, replace the character with a backward
slash (\) followed by two hexadecimal digits.
The following characters must be escaped using the backward slash (\) character
before being used in a distinguished name:
v Pound sign (#) at the beginning of the string
v A space at the end of the string
v
v
v
v
v
v
Comma (,)
Plus sign (+)
Double quotation (")
Left angle bracket (<)
Right angle bracket (>)
Semicolon (;)
Appendix F. Managing user registries
365
Note: Due to differences in registries and command shell processors, avoid using
the backward slash character (\) in distinguished names. For more
information, see "Characters disallowed for distinguished names" in
Appendix A of the IBM Tivoli Access Manager for e-business: Command
Reference.
For other reserved characters, such as an equal sign (=), asterisk (*), or a non
UTF-8 character, the character must be encoded in hexadecimal.
Example 1
To create a user with a DN that contains a comma next to the separator:
pdadmin sec_master> user create "johndoe"
"cn=doe\,john,cn=users,dc=mydomain,dc=com" John Doe password1
Example 2
To create a user with a DN that contains a carriage return, which is a
reserved character:
pdadmin sec_master> user create "johndoe"
"cn=doe\ODJohn,cn=users,dc=mydomain,dc=com" John Doe password1
The hexadecimal representation of a carriage return is 0D.
Example 3
To create a user with a distinguished name that contains a number sign:
pdadmin sec_master>user create "#pounduser"
"cn=\#pounduser,cn=users,dc=mydomain,dc=com" "#pound" "user"
password1
Importing dynamic groups to Tivoli Access Manager
When importing an Active Directory group to Tivoli Access Manager, the Tivoli
Access Manager group short name/ID (not including the @domain suffix when
Tivoli Access Manager was configured to use Active Directory multiple domain)
must be the same as the dynamic group cn. This requirement is to ensure that only
one dynamic group can be mapped to a Tivoli Access Manager group object at any
give time.
For example, if you have an Active Directory group with cn = dyngroup1 and
distinguishedName = cn=dyngroup1,cn=AzGroupObjectContainermyAuthorizationStore,cn=myAuthorizationStore,cn=ProgramData,dc=domain,dc=com, the import command would be similar to one of the following:
v Tivoli Access Manager configured to an Active Directory registry single domain
environment:
pdadmin sec_master> group import dyngroup1
"cn=dyngroup1, cn=AzGroupObjectContainer-myAuthorizationStore,
cn=myAuthorizationStore,cn=Program Data,dc=domain,dc=com"
v Tivoli Access Manager configured to an Active Directory registry multiple
domain environment:
pdadmin sec_master> group import dyngroup1@domain.com
"cn=dyngroup1,cn=AzGroupObjectContainer-myAuthorizationStore,
cn=myAuthorizationStore,cn=Program Data,dc=domain,dc=com"
Enabling change user password requests to be performed
using LDAP APIs
Tivoli Access Manager can be configured to use LDAP APIs for user password
change requests in an environment that meets all of the following criteria:
v Tivoli Access Manager is configured to use an Active Directory user registry.
366
Administration Guide
v Blade servers communicate directly with the Active Directory server using
LDAP APIs.
To enable this functionality, use the pdadmin config modify command to update
the change-pwd-using-ldap-api property in the [uraf-registry] stanza of the
activedir_ldap.conf configuration file.
Note: After you enable this option, the Policy Server does not need to be
up-and-running to handle user change password requests.
The following lines show an example of how to enable the change user password
via LDAP APIs on Windows using Active Directory LDAP:
pdadmin> login local
pdadmin local> config modify keyvalue set
"c:\Program Files\Tivoli\Policy Director\etc\activedir_ldap.conf"
"uraf-registry" "change-pwd-using-ldap-api" yes
The following lines show an example of how to enable the change user password
via LDAP APIs on for Active Directory LDAP on AIX:
pdadmin> login local
pdadmin local> config modify keyvalue set
"/opt/PolicyDirector/etc/activedir_ldap.conf"
"uraf-registry" "change-pwd-using-ldap-api" yes
For more information, see change-pwd-using-ldap-api on page 318.
Enabling support for the use of email address or other
alternate format as user identity
Tivoli Access Manager can be configured to support the use of email address or
other alternate format of the userPrincipalName attribute of the Active Directory
registry user object for Access Manager user identity. This is an optional
enhancement; when it is enabled, both the default and the alternate format of the
userPrincipalName can co-exist in the Tivoli Access Manager environment.
For an existing Tivoli Access Manager environment, enabling this support allows
only new Access Manager user identities to use the alternate format. Existing
Access Manager user identities should not be modified.
To enable this support, use the pdadmin command utility to modify the registry
configuration file.
The following example demonstrates how to use the pdadmin utility to enable
support of alternate userPrincipalName natively for an Active Directory
environment:
pdadmin> login local
pdadmin local> config modify keyvalue set
"c:\Program Files\Tivoli\Policy Director\etc\activedir.conf"
"uraf-registry" "use-email-as-user-id" yes
The following example demonstrates how to use the pdadmin utility to enable
support of alternate userPrincipalName when using LDAP APIs on an AIX system:
pdadmin> login local
pdadmin local> config modify keyvalue set
"/opt/PolicyDirector/etc/activedir_ldap.conf"
"uraf-registry" "use-email-as-user-id" yes
Appendix F. Managing user registries
367
pdadmin local> config modify keyvalue set
"/opt/PolicyDirector/etc/activedir_ldap.conf"
"uraf-registry" "ad-gc-server" adgc.hostname.com
Note that the ad-gc-server entry in the previous example is a multi-value property;
if there are multiple Global Catalog servers, append them using the pdadmin
utility. For each additional Global Catalog server, use the config modify command
as in the previous example, but replace the set operation with append. For
example:
pdadmin> login local
pdadmin local> config modify keyvalue append
"/opt/PolicyDirector/etc/activedir_ldap.conf" "uraf-registry"
"ad-gc-server" adgc.hostname2.com
Novell-specific tasks
The Novell eDirectory can be configured for use as a Tivoli Access Manager user
registry. This section describes a few steps that are unique to this configuration.
Tasks to be performed include:
v Updating the eDirectory schema
v Novell eDirectory maintenance activities that can damage schema modifications
applied by Tivoli Access Manager
Updating the eDirectory schema
If you are installing a new Tivoli Access Manager secure domain, the Tivoli Access
Manager schema is installed on the Novell eDirectory Server (NDS) automatically
when the Tivoli Access Manager policy server is configured. However, prior to
configuring the policy server, there are several modifications to Novell eDirectory
that must first be performed using Novell’s ConsoleOne directory management
utility or iManager web-based administration console.
Note: The default Novell eDirectory schema assumes that the directory does not
use the X.500 object classes of inetOrgPerson or groupOfNames. By default,
these classes are mapped into the eDirectory classes of User and Group,
respectively. Because Tivoli Access Manager uses the inetOrgPerson and
groupOfNames object classes for creating its own users and groups,
modifications to the default eDirectory schema are required.
To update the eDirectory schema using the Novell eDirectory ConsoleOne
directory management utility, complete the following steps:
1. Start the Novell ConsoleOne directory management utility.
2. Select the organization object within your Novell eDirectory tree. A list of
objects is displayed on the right side of the ConsoleOne window.
3. Right click the LDAP group object (not LDAP server), and click Properties
from the menu.
4. Click the Class Map tab and the table of LDAP class names. The Novell
eDirectory class names are displayed.
5. Delete the entries with LDAP classes of inetOrgPerson and groupOfNames.
6. Click Apply, and then click Close.
7. Click the Attribute Map tab and the table of LDAP attribute names. The
Novell eDirectory attribute names are displayed.
8. Scroll through the table and find the Novell eDirectory attribute member. Check
the value of the corresponding LDAP attribute. If the LDAP attribute value is
368
Administration Guide
member, then no change is needed. If the attribute is showing the default value
of uniqueMember, you need to modify it as follows.
v Click Modify. The Attribute Mapping window is displayed.
v Change the Primary LDAP Attribute field from uniqueMember to member.
v Change the Secondary LDAP attribute field from member to uniqueMember.
v In the Attribute window, click OK to accept the changes.
9. If you are using Solaris, proceed to the next step. If you are using Windows
NT®, you might have to add another mapping for the LDAP attribute
ndsHomeDirectory as follows:
v On the right hand side of the Attribute Mappings window, click Add . The
Attribute Mapping window repaints and is displayed again.
v From the Novell eDirectory NDS Attribute field menu, click Home
Directory.
v In the Primary LDAP Attribute field, click ndsHomeDirectory.
v In the Attribute Mapping window, click OK to accept the changes.
10. In the Properties window, click OK.
To update the eDirectory schema using the Novell iManager Web-based
administration console, complete the following steps
1. Launch the iManager Web page and log in as the administrator for the Novell
eDirectory tree to be updated.
2. Click the Roles and Tasks icon at the top of the iManager window to open
the Roles and Tasks view.
3. In the Roles and Tasks navigation frame, expand the LDAP category.
4. In the expanded list, click the LDAP Options task.
5. On the LDAP Options page, click the LDAP Group listed.
6. Click Class Map to display the Novell eDirectory class to LDAP class
mappings.
7. Remove mappings to inetOrgPerson and groupOfNames.
v Scroll through the list and look for mappings of eDirectory classes to the
LDAP class inetOrgPerson.
v If a mapping exists, select the row and click the Remove Mapping icon to
remove the mapping.
v Click OK in the pop-up window to confirm the removal of the mapping.
v Click Apply to apply the changes.
v Repeat this step to remove a mapping for the LDAP class groupOfNames.
8. Click OK, to accept the changes that have been made.
9. Repeat steps 3-5 to return to the LDAP Group page.
10. Click Attribute Map to access the Novell eDirectory attribute to LDAP
attribute mappings.
11. Scroll through the table and find the Novell eDirectory attribute member.
Check the value of the corresponding LDAP attribute. If the LDAP attribute
value is member, no change is needed. If the attribute is showing the default
value of uniqueMember, you need to modify it as follows:
v Select the row and click the View/Edit Mapping icon.
v Change the Primary LDAP Attribute field from uniqueMember to member.
v Change the Secondary LDAP attribute field from member to uniqueMember.
v Click OK in the pop-up window to confirm the change.
Appendix F. Managing user registries
369
v Click Apply to apply the changes.
12. If you are using Solaris, proceed to the next step. If you are using Windows
NT, you might have to add another mapping for the LDAP attribute
ndsHomeDirectory. To add another mapping for the LDAP attribute
ndsHomeDirectory:
v Click the Add Mapping icon in the right side of the window. A pop-up
window to define the mapping is displayed.
v In the eDirectory Attribute field, select Home Directory.
v In the Primary LDAP Attribute field, type ndsHomeDirectory.
v Click OK to confirm the mapping and close the pop-up window.
13. Click OK in the Attribute Map window to accept the changes.
Novell eDirectory maintenance activities that can damage
schema modifications applied by Tivoli Access Manager
Novell eDirectory defines the object classes User and Group as part of its base
schema. Instances of these object classes are created by an eDirectory administrator
when defining a user or a group, respectively. Both of these object classes are
defined by eDirectory as leaf nodes. eDirectory adds an attribute
X-NDS_NOT_CONTAINER ’1’ to each of these object class definitions that specifies they
are not container objects. Not being a container object means that the objects
cannot be defined beneath instances of these object classes.
Tivoli Access Manager requires the ability to append its own objects beneath
pre-existing eDirectory users and groups in order to import them and make them
usable by Tivoli Access Manager. When Tivoli Access Manager adds its own object
class definitions to the eDirectory schema, it also redefines the eDirectory User and
Group object classes to allow instances of these classes to be container objects.
Novell eDirectory allows this change to its schema definition.
The following Novell eDirectory administrator actions cause Tivoli Access Manager
modification to the User object class to be undone. The Group object class is not
affected.
v Running the eDirectory database repair tool ndsrepair using the rebuild schema
option.
v Running Basic Repair from the iManager console and running local database
repair with the rebuild operational schema option.
v Applying a patch update to Novell eDirectory.
v Upgrading Novell eDirectory to a more recent version.
Should it be necessary to perform any of these operations after Tivoli Access
Manager was configured into the eDirectory server, run the following command
immediately to ensure that the definition of the User object class is restored.
ivrgy_tool(.exe) -h edir_server_name -p port -D edir_admin_dn
-w edir_admin_password schema
The ivrgy_tool utility can be found in one of the following Tivoli Access Manager
directories:
Linux and UNIX operating systems
/opt/PolicyDirector/sbin
Windows operating systems
c:\program files\tivoli\policy director\sbin
370
Administration Guide
Tivoli Access Manager does not add the /sbin directory to the system PATH. You
must run the ivrgy_tool utility from the /sbin directory.
Appendix F. Managing user registries
371
372
Administration Guide
Appendix G. 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 374
v “Receiving weekly software updates” on page 374
v “Contacting IBM Software Support” on page 375
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
v
v
v
v
IBM downloads
IBM Redbooks®
IBM developerWorks®
Forums and news groups
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. 1999, 2010
373
http://www.ibm.com/software/support
2. 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/support
2. 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/support
2. 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
374
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.html
v For IBM eServer™ software products (including, but not limited to, DB2 and
WebSphere products that run in System z®, 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
1.
2.
3.
contact IBM Software support, follow these steps:
“Determining the business impact”
“Describing problems and gathering information” on page 376
“Submitting problems” on page 376
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 G. Support information
375
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.
376
Administration Guide
For more information about problem resolution, see “Searching knowledge bases”
on page 373 and “Obtaining fixes” on page 373.
Appendix G. Support information
377
378
Administration Guide
Appendix H. 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 may 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. 1999, 2010
379
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 was 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
IBM, IBM logo, AIX, DB2, DB2 Universal Database, developerWorks, Domino,
eServer, iSeries, Lotus, Passport Advantage, pSeries, Redbooks, SecureWay™, Tivoli,
Tivoli logo, WebSphere, zSeries®, and z/OS are trademarks or registered
trademarks of International Business Machines Corporation in the United States,
other countries, or both.
Lotus and Domino are trademarks of International Business Machines Corporation
and Lotus Development 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.
Microsoft and Windows are trademarks of Microsoft Corporation in the United
States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or
both.
380
Administration Guide
Other company, product, or service names may be trademarks or service marks of
others.
Appendix H. Notices
381
382
Administration Guide
Glossary
This glossary defines the technical terms and
abbreviations that are used in Tivoli Access
Manager. If you do not find the term or
abbreviation for which you are looking, refer to
the IBM Terminology Web site at the following
Web address:
http://www.ibm.com/ibm/terminology
The following cross-references are used among
terms:
Contrast with
Refers the reader to a term that has an
opposed or substantively different
meaning.
See
Refers the reader to a term that is the
expanded form of an abbreviation or
acronym or to a synonym or more
preferred term.
See also
Refers the reader to a related term.
Obsolete
Indicates that the term should not be used
and refers the reader to the preferred
term.
A
access control. In computer security, the process of
ensuring that only authorized users can access the
resources of a computer system in authorized ways.
access control list (ACL). In computer security, a list
with an object that identifies all the subjects that can
access the object and their access rights. For example,
an access control list is a list that is associated with a
file that identifies the users who can access the file and
identifies the users' access rights to that file.
access decision information (ADI). The data and
attributes that are used by the authorization engine to
evaluate a rule. Authorization API attributes are
name-value pairs, form the basis of all ADI that can be
referenced in a rule or presented to the authorization
engine.
access permission. The access privilege that applies to
the entire object.
account. Information about an identity.
ACL. See access control list.
© Copyright IBM Corp. 1999, 2010
ACL entry. Data in an access control list that specifies
a set of permissions.
ACL policy. Part of the security policy that contains
ACL entries that control who can access which domain
resources and perform which actions. See also
authorization rule and protected object policy.
action. An access control list (ACL) permission
attribute. See also access control list.
action group. A set of actions that are explicitly
associated with a resource or set of resources.
ADI. See access decision information.
ADK. See application development kit
administration service. An authorization API runtime
plug-in that can be used to perform administration
requests on a Tivoli Access Manager resource manager
application. The administration service responds to
remote requests from the pdadmin command to
perform tasks, such as listing the objects under a
particular node in the protected object tree. Customers
may develop these services using the authorization
ADK.
application development kit (ADK). A set of tools,
APIs, and documentation to assist with the
development of software in a specific computer
language or for a particular operating environment.
attribute. A characteristic or trait of an entity that
describes the entity. An attribute can have a type,
which indicates the range of information given by the
attribute, and a value, which is within a range. In XML,
for example, an attribute consists of a name-value pair
within a tagged element and modifies a feature of an
element.
attribute list. A linked list that contains extended
information that is used to make authorization
decisions. Attribute lists consist of a set of name-value
pairs.
audit event. A record of an operation in the audit log
or change history; for example, an audit entry is
created when a resource is modified.
audit level. The types of user actions that are
currently being audited for the entire system or for
specific users on the system. Actions that can be
audited include authority failures and restoring objects.
A record of each action is written to the audit journal.
audit trail. A chronological record of events that
enables the user to examine and reconstruct a sequence
383
of events. Audit trails are useful for managing security
and for recovering lost transactions.
audit trail file. The file that contains the audit trail.
authentication. In computer security, the process that
verifies identity. Authentication is distinct from
authorization; authorization is concerned with granting
and denying access to resources. See also multi-factor
authentication, network-based authentication, and
step-up authentication.
authorization. In computer security, the process that
grants or denies access to resources. Security uses a
two-step process: after authentication has verified the
identity, authorization allows the resource or process
access to various resources based on its identity.
authorization API. The Tivoli Access Manager
component that passes requests for authorization
decisions from the resource manager to the
authorization evaluator. See also authorization server
and authorization service.
authorization evaluator. The decision-making process
that determines whether a client can access a protected
resource based on the security policy. The evaluator
makes its recommendation to the resource manager,
which, in turn, responds accordingly.
authorization rule. Part of the security policy that
define conditions that are contained in authorization
policy. An authorization rule is used to make access
decisions based on attributes such as user, application,
and environment context. See also ACL policy and
protected object policy.
authorization server. The Tivoli Access Manager
component that runs the authorization service. See also
authorization service.
authorization service. A dynamic or shared library
that can be loaded by the authorization API runtime
client at initialization time to perform operations that
extend a service interface in the Authorization API.
B
BA. See basic authentication.
basic authentication. An authentication method that
verifies identity using a user name and password.
bind. To relate an identifier to another object in a
program; for example, to relate an identifier to a value,
to an address, or to another identifier or to associate
formal parameters to actual parameters.
blade. A component that provides application-specific
services and components.
Boolean. A binary numbering system that is named
after mathematician George Boole in which zero and
384
Administration Guide
one are the only two values that can be returned; a
value of zero represents false while a value of one
represents true.
business entitlement. The supplemental attribute of a
user credential that describes the fine-grained
conditions that can be used in the authorization
process.
C
CA. See certificate authority.
CDAS. Obsolete. See external authentication C API.
CDMF. See cross domain mapping framework.
certificate. In computer security, a digital document
that binds a public key to the identity of the certificate
owner, thereby enabling the certificate owner to be
authenticated. A certificate is issued by a certificate
authority.
certificate authority (CA). An organization that issues
certificates. A CA creates digital signatures and
public-private key pairs. The CA guarantees the
identity of the individual who is granted the unique
certificate and guarantees the services that the owner is
authorized to use, to issue new certificates, and to
revoke certificates that belong to users and
organizations who are no longer authorized to use the
services. The role of the CA s to authenticate the
entities (users and organizations) involved in electronic
transactions. Because the CA guarantees that the two
parties that are exchanging information are really who
they claim to be, the CA is a critical component in data
security and electronic commerce.
CGI. See common gateway interface.
cipher. A cryptographic algorithm that is used to
encrypt data that is unreadable until it is converted into
plain data (decrypted) with a predefined key.
common gateway interface (CGI). An Internet
standard for defining scripts that pass information from
a Web server to an application program, through an
HTTP request, and vice versa. A CGI script is a CGI
program that is written in a scripting language, such as
Perl.
configuration. The manner in which the hardware
and software of a system, subsystem, or network are
organized and interconnected.
connection. (1) In data communication, an association
established between functional units for conveying
information. (2) In TCP/IP, the path between two
protocol applications that provides reliable data stream
delivery service. In the Internet, a connection extends
from a TCP application on one system to a TCP
application on another system. (3) In system
communication, a line over which data can be passed
between two systems or between a system and a
device.
console log agent. A log agent that writes events to
standard error or standard output. See also file log
agent, pipe log agent, and remote log agent.
container object. A structural designation that
organizes the object space into distinct functional
regions.
cookie. Information that a server stores on a client
machine and accesses during subsequent sessions.
Cookies allow servers to remember specific information
about clients.
credentials. Detailed information, acquired during
authentication, that describes the user, any group
associations, and other security-related identity
attributes. Credentials can be used to perform a
multitude of services, such as authorization, auditing,
and delegation.
credentials modification service. An authorization
API runtime plug-in which can be used to modify a
Tivoli Access Manager credential. Credentials
modification services developed externally by
customers are limited to performing operation to add
and remove from the credentials attribute list and only
to those attributes that are considered modifiable.
cross domain authentication service (CDAS).
Obsolete. See external authentication C API.
cross domain mapping framework (CDMF). A
programming interface that allows a developer to
customize the mapping of user identities and the
handling of user attributes when WebSEAL
e-Community SSO function are used.
D
daemon. A system process that runs unattended to
perform continuous or periodic system-wide functions,
such as network control. See also service.
data store. A storage area for data, such as a database
system, directory, or file.
delegate. A user who is authorized to work for
another user. The authorization can be made by a user
or by an administrator.
demilitarized zone (DMZ). In network security, a
computer or network that uses a firewall to be isolated
from, and to serve as a neutral zone between, a trusted
network (for example, a private intranet) and an
untrusted network (for example, the Internet). One or
more secure gateways usually control access to the
DMZ from the trusted or the untrusted network.
digital signature. Information that is encrypted with a
private key and is appended to a message to assure the
recipient of the authenticity and integrity of the
message. The digital signature proves that the message
was signed by the entity that owns, or has access to,
the private key or shared secret symmetric key.
directory schema. The valid attribute types and object
classes that can appear in a directory. The attribute
types and object classes define the syntax of the
attribute values, which attributes are required, and
which attributes are optional.
distinguished name (DN). (1) The name that uniquely
identifies an entry in a directory. A distinguished name
is made up of an attribute-value pairs, separated by
commas. (2) A set of name-value pairs (such as
cn=common name and c=country) that uniquely
identifies an entry in a digital certificate.
DMZ. See demilitarized zone.
DN. See distinguished name.
domain. (1) A logical grouping of resources in a
network that share common administration and
management. (2) A part of a network that is
administered with a common protocol. See also domain
name.
domain administrator. The administrator for a
domain who can assign any of the roles in that domain
to subdomains. After assigning roles to subdomains,
administrators in that subdomain can assign
subdomain users these roles.
domain name. In the Internet suite of protocols, the
name of a host system. A domain name consists of a
sequence of subnames that are separated by a delimiter
character. For example, if austin.ibm.com is the fully
qualified domain name (FQDN) of a host system, both
austin.ibm.com and ibm.com® are domain names.
dynamic group. A group that is defined using a
search expression. When an attribute is added to a
directory entry that causes it to match the search
expression, the entry automatically becomes a member
of the group.
E
EAS. See external authorization service.
encryption. In computer security, the process of
transforming data into a cipher.
entitlement. A data structure that contains
externalized security policy information. Entitlements
contain policy data or capabilities that are formatted in
a way that is understandable to a specific application.
entitlement service. An authorization API runtime
plug-in which can be used to return entitlements from
Glossary
385
an external source for a principal or set of conditions.
Entitlements are normally application specific data that
will be consumed by the resource manager application
in some way or added to the principal's credentials for
use further on in the authorization process. Customers
may develop these services using the authorization
ADK.
entity. In object-oriented design, an item that can be
treated as a unit and, often, as a member of a particular
category or type. An entity can be concrete or abstract.
event. Any significant change in the state of a system
resource, network resource, or network application. An
event can be generated for a problem, for the resolution
to a problem, or for the successful completion of a task.
event pool. A set of events recognized by an activity.
Each activity has its own event pool. The event pool is
initialized when the activity is created and is deleted
when the activity is deleted.
extended attribute. Additional information that the
system or a program associates with an object. An
extended attribute can be any format, such as text, a
bitmap, or binary data.
external authentication C API. A C API that enables
you to write custom authentication modules that
replace or extend the functionality of the built–in
authentication process. The identity information is
returned through the authentication module interface.
Contrast with external authentication HTTP interface.
external authentication HTTP interface. An interface
that enables you to extend the functionality of the
built-in authentication process to allow a remote service
to handle the authentication process. The identity
information in the HTTP response headers is used to
generate user credentials. Contrast with external
authentication C API.
external authorization service (EAS). An
authorization API runtime plug-in that can be used to
make application- or environment-specific authorization
decisions as part of the authorization decision chain.
Customers can develop these services using the
authorization ADK.
Extensible Markup Language (XML). A standard
meta-language for defining markup languages that is
based on Standard Generalized Markup Language
(SGML).
Extensible Stylesheet Language (XSL). A language for
specifying style sheets for XML documents. XSL
Transformation (XSLT) is used with XSL to describe
how an XML document is transformed into another
document. See also Extensible Stylesheet Language
Transformation.
386
Administration Guide
Extensible Stylesheet Language Transformation
(XSLT). An XML processing language that is used to
convert an XML document into another document in
XML, PDF, HTML, or other format. See also Extensible
Stylesheet Language.
F
file log agent. A log agent that writes events to a file.
See also console log agent, pipe log agent, and remote
log agent.
file transfer protocol (FTP). In the Internet suite of
protocols, a protocol that can use Transmission Control
Protocol (TCP) and Telnet services to transfer files
between machines.
FTP. See file transfer protocol
G
global sign-on (GSO). A flexible single sign-on
solution that enables the user to provide alternative
user names and passwords to the back-end Web
application server. Through a single login, global
sign-on grants users access to the computing resources
they are authorized to use. Designed for large
enterprises consisting of multiple systems and
applications within heterogeneous, distributed
computing environments, GSO eliminates the need for
users to manage multiple user names and passwords.
See also single sign-on.
group. A named list of users by which access levels to
corporate directories, databases, and servers are
assigned. Two or more individual users who are
categorized for the purpose of assigning database
security settings; for example, administrators must
assign individuals to groups before assigning roles.
GSO. See global sign-on.
H
host. A computer that is connected to a network and
provides an access point to that network. The host can
be a client, a server, or both a client and a server
simultaneously.
HTTP. See hypertext transfer protocol.
hypertext transfer protocol (HTTP). In the Internet
suite of protocols, the protocol that is used to transfer
and display documents.
I
inheritance. An object-oriented programming
technique that allows the use of existing classes as a
basis for creating other classes.
Internet protocol (IP). In the Internet suite of
protocols, a connectionless protocol that routes data
through a network or interconnected networks. IP acts
as an intermediary between the higher protocol layers
and the physical network.
Internet suite of protocols. A set of protocols
developed for use on the Internet and published
through the Internet Engineering Task Force (IETF).
interprocess communication (IPC). (1) The process by
which programs communicate data to each other and
synchronize their activities. Semaphores, signals, and
internal message queues are common methods of
interprocess communication. (2) A mechanism of an
operating system that allows processes to communicate
with each other within the same computer or over a
network.
the sender uses the public key to encrypt the message,
and the recipient uses the private key to decrypt the
message. When the key pair is used for signing, the
signer uses the private key to encrypt a representation
of the message, and the recipient uses the public key to
decrypt the representation of the message for signature
verification. Because the private key holds more of the
encryption pattern than the public key, the key pair is
called asymmetric.
key ring. See key file.
keystore file. A key file that contains both public keys
stored as signer certificates and private keys stored in
personal certificates.
keytab file. See key table.
IPC. See interprocess communication.
key table. In the Kerberos protocol, a file that contains
service principal names and secret keys. The secret keys
should be known only to the services that use the key
table file and the key distribution center (KDC).
J
key-value pair. Information that is expressed as a
paired set.
junction. A logical connection that is created to
establish a path from one server to another.
L
K
LDAP. See lightweight directory access protocol.
IP. See Internet protocol.
KDC. See key distribution center.
Kerberos. An authentication system that enables two
parties to exchange private information over an
otherwise open network. It works by assigning a
unique key, called a ticket, to each user that logs on to
the network. The ticket is then embedded in messages
that are sent over the network. The receiver of a
message uses the ticket to authenticate the sender.
Kerberos ticket. A transparent application mechanism
that transmits the identity of an initiating principal to
its target. A simple ticket contains the identity, a session
key, a timestamp, and other information that is sealed
using a secret key.
key. In computer security, a sequence of symbols that
is used with a cryptographic algorithm for encrypting
or decrypting data. See private key and public key.
key database file (KDC). See key file.
key distribution center. In the Kerberos protocol, the
central server, which includes the authentication server
and the ticket-granting server. The KDC is sometimes
referred to as the Kerberos server.
key file. In computer security, a file that contains
public keys, private keys, trusted roots, and certificates.
key pair. In computer security, a public key and a
private key. When the key pair is used for encryption,
leaf node. A node that has no children before it in the
directory tree.
lightweight directory access protocol (LDAP). An
open protocol that uses TCP/IP to provide access to
directories that support an X.500 model and that does
not incur the resource requirements of the more
complex X.500 Directory Access Protocol (DAP). For
example, LDAP can be used to locate people,
organizations, and other resources in an Internet or
intranet directory.
lightweight third party authentication (LTPA). An
authentication protocol that users cryptography to
support security across a set of Web servers in a
distributed environment.
LTPA. See lightweight third party authentication.
M
management domain. The default domain in which
Tivoli Access Manager enforces security policies for
authentication, authorization, and access control. This
domain is created when the policy server is configured.
See also domain.
management interface. The interface that a domain
administrator can use to manage security policy. In
Tivoli Access Manager, an administrator can use Web
Portal Manager or the pdadmin commands to apply
security policy to resources.
Glossary
387
management server. Obsolete. See policy server.
master server. In a network environment, the server
that has permissions to run commands on all other
machines in the environment. The master server is
designed to manage the network, clients, and resource
objects in the network database. Contrast with replica
server
metadata. Data that describes the characteristics of
stored data.
migration. The installation of a new version or release
of a program to replace an earlier version or release.
MPA. See multiplexing proxy agent.
multi-factor authentication. A protected object policy
(POP) that forces a user to authenticate using two or
more levels of authentication. For example, the access
control on a protected resource can require that the
users authenticate with both user name/password and
user name/token passcode.
multiple tenancy server. A server that permits the
hosting of multiple customers on a single server instead
of multiple client machines. See also protected object
policy.
multiplexing proxy agent (MPA). A gateway that
accommodates multiple client access. These gateways
are sometimes known as Wireless Access Protocol
(WAP) gateways when clients access a secure domain
using a WAP. Gateways establish a single authenticated
channel to the originating server and tunnel all client
requests and responses through this channel.
N
namespace. (1) In XML, a uniform resource identifier
(URI) that provides a unique name to associate with all
the elements and type definitions in a schema. (2)
Space reserved by a file system to contain the names of
its objects.
network-based authentication. A protected object
policy (POP) that controls access to objects based on the
Internet protocol (IP) address of the user. See also
protected object policy.
notification thread. The synchronization mechanism
that the policy server uses to inform all database
replicas of a change to the master policy database.
O
object. (1) In object-oriented design or programming,
a concrete realization (instance) of a class that consists
of data and the operations associated with that data.
An object contains the instance data that is defined by
the class, but the class owns the operations that are
associated with the data. (2) Any digital content that a
388
Administration Guide
user can manipulate as a single unit and perform a
task. An object can appear as text, an icon, or both. (3)
A named storage space that consists of a set of
characteristics that describe the space and, in some
cases, data. An object is anything that occupies space in
storage, can be located in a library or directory, can be
secured, and on which defined operations can be
performed. Some examples of objects are programs,
files, libraries, and stream files.
object space. A virtual representation of the resources
to be protected. See also namespace.
object type. A categorization or group of object
instances that share similar behavior and characteristics.
P
PAC. See privilege attribute certificate.
PDCA. See Policy Director Certificate Authority
permission. The ability to access a protected object,
such as a file or directory. The number and meaning of
permissions for an object are defined by the access
control list (ACL). See also access control list.
pipe log agent. A log agent that writes events as
standard input to another program. See also console log
agent, file log agent, and remote log agent.
policy. A set of rules that are applied to managed
resources.
policy database. The database that contains the
security policy information for all resources in the
domain. Each domain has its own policy database.
Policy Director Certificate Authority (PDCA). A
trusted certificate that is created during the
configuration of the policy server and that is used to
sign all other Tivoli Access Manager certificates. A
PDCA certificate is stored in the master policy
database.
policy enforcer. A component of a resource manager
that directs requests to the authorization service for
processing after authorization is granted. Traditional
applications bundle the policy enforcer and the
resource manager as one process.
policy server. The Tivoli Access Manager component
that maintains the master policy database, replicates
this policy information throughout the secure domain,
and updates database replicas whenever a change is
made to the master policy database. The policy server
also maintains location information about other Tivoli
Access Manager and non-Tivoli Access Manager
resource managers that are operating in the secure
domain.
polling. The process by which databases are
interrogated at regular intervals to determine if data
needs to be transmitted.
Q
POP. See protected object policy.
quality of protection. The level of data security,
determined by a combination of authentication,
integrity, and privacy conditions.
portal. A single point of access to diverse information
and applications. Users can customize and personalize
a portal.
R
principal. (1) An entity that can communicate securely
with another entity. (2) An authenticated user. A
principal is identified by its associated security context,
which defines its access rights.
private key. In computer security, a key that is known
only to its owner. Contrast with public key.
privilege attribute certificate (PAC). A digital
document that contains a principal's authentication and
authorization attributes and a principal's capabilities.
privilege attribute certificate service. An
authorization API runtime client plug-in which
translates a PAC of a predetermined format in to a
Tivoli Access Manager credential, and vice-versa. These
services could also be used to package or marshall a
Tivoli Access Manager credential for transmission to
other members of the secure domain. Customers may
develop these services using the authorization ADK.
See also privilege attribute certificate.
protected object. The logical representation of an
actual system resource that is used for applying ACLs
and POPs and for authorizing user access. See also
protected object policy and protected object space.
protected object policy (POP). A type of security
policy that imposes additional conditions on the
operation permitted by the ACL policy to access a
protected object. It is the responsibility of the resource
manager to enforce the POP conditions. See also ACL
policy, authorization rule, protected object, and
protected object space.
protected object space. The virtual object
representation of actual system resources that is used
for applying ACLs and POPs and for authorizing user
access. See also protected object and protected object
policy.
proxy server. A server that receives requests intended
for another server and that acts on behalf of a client to
obtain the requested service. A proxy server is often
used when the client and the server are incompatible
for direct connection. For example, a client cannot meet
the security authentication requirements of the server
but should be permitted some services.
public key. In computer security, a key that is made
available to everyone. Contrast with private key.
record. (1) The storage representation of a single row
of a table or other data in a database. (2) A group of
related data, words, or fields treated as a unit.
registry. The datastore that contains access and
configuration information for users, systems, and
software.
remote cache mode. An operational mode in which a
resource manager uses the functions that are provided
by the authorization API to communicate to the remote
authorization server.
remote log agent. A log agent that sends events to a
remote server for recording. See also console log agent,
file log agent, and pipe log agent.
replica server. A server that contains a copy of the
directory or directories of another server. Replicas back
up master servers or other replica servers to enhance
performance or response times and to ensure data
integrity. Contrast with master server.
resource. A hardware, software, or data entity that is
managed.
resource group. A group of resources that can include
business objects such as contracts or a set of related
commands. In access control policies, resource groups
specify the resource to which the policy authorizes
access.
resource manager. (1) An application, program, or
transaction that manages and controls access to shared
resources, such as memory buffers and data sets. (2)
Any server or application that uses the authorization
API to process client requests for access to resources.
resource object. The representation of an actual
network resource, such as a service, file, and program.
response file. An ASCII file that can be customized
with the setup and configuration data that automates
an installation. The setup and configuration data has to
be entered during an interactive installation, but with
the response file, the installation can proceed without
user interaction. See also silent installation.
role. A definition of the access permissions that a user
or process has and the specific resources that the user
or process can modify at those levels. Users and
processes are limited in how they can access resources
when that user or process does not have the
appropriate role.
Glossary
389
role activation. The process of applying access
permissions to a role.
role assignment. The process of assigning a role to a
user, such that the user has the appropriate access
permissions for the object defined for that role.
root container object. The top-level container object in
the hierarchy or resource objects.
root domain. Name servers that have authoritative
control of all the top-level domains.
routing file. An ASCII file that contains commands
that control the configuration of messages.
routing table. A collection of path information
through which hosts or networks can communicate
with each other.
security context. The digitally signed token that
identifies a principal, lists the roles and access rights
for the principal, and contains information about when
the token expires.
security management. The software discipline that
addresses how an organization can control access to
mission critical applications and data.
security policy. (1) A written document that defines
the security controls that you institute for your
computer systems. A security policy describes the risks
that you intend to minimize and the actions that
should be taken if someone breaches your security
controls. (2) In Tivoli Access Manager, the combination
of ACL policies, authorization rules, and protected
object policies attached to objects to make them
protected objects. See also ACL policy, authorization
rule, and protected object policy.
RSA. A public-key encryption technology that was
developed by RSA Data Security, Inc., and used by
GSKit. The acronym stands for Rivest, Shamir, and
Adleman, the inventors of this encryption technique.
self-registration. The process by which a user can
enter required data and become a registered user
without the involvement of an administrator.
RSA encryption. A system for public-key
cryptography used for encryption and authentication.
The security of the system depends on the difficulty of
factoring the product of two large prime numbers.
service. Work performed by a server. A service can be
a simple request for data to be sent or stored (as with
file servers, HTTP servers, or e-mail servers), or it can
be for more complex requests (as with print servers or
process servers). See also daemon.
rule. A set of logical statements that enable a server to
recognize relationships among events and to perform
automated responses accordingly.
session. A series of requests to a server or application
that originate from the same user at the same browser.
rules evaluator. The component responsible for
evaluating an authorization rule.
run time. The time period during which a computer
program is running.
runtime environment. A subset of an application
development kit (ADK) that contains the executable
files and other supporting files that comprise the
operational environment of the platform.
single sign-on (SSO). The mechanism that allows a
user to logon once and access multiple applications
through a single authorization challenge. Using SSO, a
user does not need to log on to each application
separately. See also global sign-on.
SSL. See Secure Socket Layer.
S
SSO. See single sign-on.
scalability. The ability of hardware, software, or a
distributed system to maintain performance levels as it
increases in size and increases in the number of users
who access resources.
schema. The set of statements, expressed in a data
definition language, that completely describes the
structure of data that is stored in a database, directory,
or file.
Secure Sockets Layer (SSL). A security protocol that
provides communication privacy. SSL enables
client/server applications to communicate in a way that
is designed to prevent eavesdropping, tampering, and
message forgery.
390
silent installation. An installation that does not send
messages to the console but instead stores messages
and errors in log files. Also, a silent installation can use
response files for data input. See also response file.
Administration Guide
stanza. A group of lines in an ASCII file that together
have a common function or define a part of a system.
Stanzas are usually separated by blank lines or colons,
and each stanza has a name.
stash file. The local copy of the master key file that
resides in an encrypted format on the local disk.
step-up authentication. A protected object policy
(POP) that relies on a preconfigured hierarchy of
authentication levels and enforces a specific level of
authentication according to the policy set on a resource.
The step-up authentication POP does not force the user
to authenticate using multiple levels of authentication
to access any given resource, but it requires the user to
authenticate at a level at least as high as that required
by the policy protecting a resource. See also protected
object policy.
suffix. A distinguished name that identifies the top
entry in a locally held directory hierarchy. Because of
the relative naming scheme used in Lightweight
Directory Access Protocol (LDAP), this suffix applies to
every other entry within that directory hierarchy. A
directory server can have multiple suffixes, each
identifying a locally held directory hierarchy.
T
ticket. See Kerberos ticket.
token. A sequence of bits (symbol of authority) that is
passed successively along a transmission medium from
one device to another to indicate the device that is
temporarily in control of the transmission medium.
Each device can acquire and use the token to control
the medium.
W
Web Portal Manager (WPM). A Web-based graphical
application used to manage Tivoli Access Manager
security policy in a secure domain. An alternative to
the pdadmin command line interface, this GUI enables
remote administrator access and enables administrators
to create delegated user domains and assign delegate
administrators to these domains.
Web resource. Any one of the resources that are
created during the development of a Web application;
for example, Web projects, HTML pages, JSP files,
servlets, custom tag libraries, and archive files.
WebSEAL. A high performance, multi-threaded Web
server that applies a security policy to a protected
object space. WebSEAL can provide single sign-on
solutions and incorporate back-end Web application
server resources into its security policy.
Web session. See session.
trusted root. In the Secure Sockets Layer (SSL), the
public key and associated distinguished name of a
certificate authority (CA). See also Secure Socket Layer.
WPM. See Web Portal Manager.
U
XML. See Extensible Markup Language.
uniform resource identifier (URI). The character
string used to identify an abstract or physical resource
on the Internet. A URI typically describes how to access
the resource, the computer that contains the resource,
and the name of the resource. The most common form
of URI is the Web page address, which is a particular
subset or URI called uniform resource locator (URL).
See also uniform resource locator.
uniform resource locator (URL). A character string
that represent resources on a computer or in a network,
such as the Internet. The URL includes the abbreviated
name of the protocol used to access the information
resource and the information used by the protocol to
locate the resource.
X
XML transform. A standard that uses XSL stylesheets
to transform XML documents into other XML
documents or fragments or to transform XML
documents into HTML documents.
XSL. See Extensible Stylesheet Language.
XSL stylesheet. Code that describes how an XML
document should be rendered (displayed or printed).
XSLT. See Extensible Stylesheet Language
Transformation.
URI. See uniform resource identifier.
URL. See uniform resource locator.
user. Any person, organization, process, device,
program, protocol, or system that uses a service
provided by others.
user registry. See registry.
V
virtual hosting. The capability of a Web server that
allows it to appear as more than one host to the
Internet.
Glossary
391
392
Administration Guide
Index
Special characters
AttributeName entry 327
policy-trigger entry 230
service-id entry
aznapi-admin-services stanza 215
service-id entry
aznapi-cred-modification-services stanza
aznapi-entitlement-services stanza 229
aznapi-pac-services stanza 232
A
access control list
See ACLs
access control lists
See ACLs
access decision information
See ADI
accessibility xiii
accessmanager.gif file 28
accountability 4
accounts, user and group 145
acl commands
attach 88
create 84
delete 90
detach 89
find 89
list 85
list attribute 94
modify 85, 90, 91, 92
modify delete attribute 95
modify set attribute
creating extended attributes 93
modifying extended attributes 93
show 85, 86, 90, 91, 92
show attribute 94
ACL entries
creating for ACL policy 90
custom permissions 81
default permissions 80
definition 78
ID attribute 79
modifying permissions 91
permissions attribute 79
removing from ACL policy 91
representation of custom permissions 82
type attribute 79
ACL policies
attaching 88
cloning 86
creating 84
creating ACL entries 90
definition 77
definition of 37
deleting 89
detaching 88
evaluating 39
explicit 50
© Copyright IBM Corp. 1999, 2010
227
ACL policies (continued)
exporting
all 86
multiple 87
one 87
extended attributes
creating 92
deleting 94
deleting values 95
listing 93
modifying 93
finding 89
importing 86
inheritance 50
listing 85
management tasks 83
modifying description 84
modifying entry permissions 91
operations on an object 38
policies 38
purpose
security considerations 77
removing ACL entries 91
versus authorization rules 40
viewing 85
viewing extended attributes 94
ACL policies, defining 11
ACL policy
definition of 12
ACL policy administrator 43
aclMembership entry 297
ACLs 45
ACL entries 78
ACL policies 77
applying policies to different object types
control permission 48
default administration ACL 51
default config ACL 52
default domain ACL 53
default GSO ACL 52
default management ACL 52
default policy ACL 52
default proxy ACL 53
default replica ACL 52
default root ACL 51
explicit versus inherited 47
group management policies 191
management permissions 53
managing 77
managing ACL permissions 53
resolving request 49
user management policies 192
action bits
See permissions
action commands
create 98
delete 98
group create 96
group delete 97
group list 96
list 98
50
393
action create command 98
action delete command 98
action group commands
create 96
delete 97
list 96
action group create command 96
action group delete command 97
action group list command 96
action groups
creating 96
creating new permissions 97
custom 81
custom scenario 82
deleting 97
deleting permissions 98
guidelines 95
listing 96
listing permissions 98
management tasks 95
primary group 80
when to create 81
action list command 98
actions
See also permissions
managing Action permissions 54
Active Directory
enabling dynamic groups 158
Active Directory server
activedir.conf 207
configuration file with LDAP client 207
activedir_ldap.conf configuration file 207
activedir.conf configuration file 207, 208
ad-gc-port entry 325
ad-gc-server entry 325
ADI
containers and container names 123
definition of 119
determining what is missing 136
dynamic retrieval entitlement services 136
name/value pair attributes 124
request from the resource manager 133, 135
retrieval entitlements service 121
source 121
XML document model 122
XML document model restriction 123
administration
delegate role 185
enterprise domain 183
multiple domains 184
roles 185
superdomain 183
administration ACL (default) 51
administration API 4
administration groups 187
administration users
creating 43
administration users and groups
defaults 43
administrator
multiple domains 184
superdomain 183
tasks 186
administrators
administrator 184
domain 184
enterprise domain 183
394
Administration Guide
administrators (continued)
predefined 184
sec_master 183
senior 184
support 185
Tivoli Access Manager 184
types 184
algorithm, network-based authorization 110
allowed registry substring 181
allowed-registry-substrings entry 248
amconf.properties configuration file 208
any-authenticated type attribute
See any-other
any-other
adding ACL entry to ACL policy 90
authenticated requests 39
modifying permissions 91
removing ACL entries from ACL policies 91
type attribute 79
unauthenticated requests 39
any-other user 38
app_context attribute list 120
application context information 120
applying ACL policies 50
attribute lists
app_context 120
permission_info-returned 135
attribute name, XML 124
attribute pairs (name/value) 119
attributes
ACL ID 79
ACL permissions 79
ACL type 79
azn_cred_groups 131
azn_cred_principal_name 131
azn_cred_registry_id 131
azn_engine_requested_actions attribute 120
azn_engine_target_resource 120
azn_init_set_perminfo_attrs 133
azn_perminfo_reason_rule_failed 135
azn_perminfo_rules_adi_request 133, 136
POPs 101
audit-attribute entry 217
auditevent entry 244
auditing
disabling, common audit service 234
enabling, common audit service 234
auditing events 197
auth-using-compare entry 265
authenticated
authenticated requests 39
unauthenticated requests 39
authenticated requests 39
authentication
applying step-up policy 115
configuring levels of step-up 115
introduction 2
levels 114
multi-factor authentication 116
step-up 114
authentication-mechanisms stanza
cert-ldap entry 212
cert-uraf entry 213
description 211
passwd-ldap entry 213
passwd-uraf entry 214
authMethod entry 297
authn-timeout entry 266
authorization
evaluation process 18
introduction 2
step-by-step process 13
authorization API
introducing 14
local cache mode 16
remote cache mode 15
standard 5
authorization API attributes 119
authorization database
replicating 174
authorization evaluator
overview 9
authorization model
conceptual model 6
authorization policy database 9
Authorization rule language
languages 122
authorization rules 13
attaching to an object 142
changing 139
cloning 140
creating 138
definition of 37
deleting 144
delimiters 128
detaching 143
differing from ACL policies and POPs 40
evaluator 128
examples
ADI from dynamic ADI retrieval services
ADI from entitlement data 131
ADI from resource manager 131
exporting
all 141
multiple 141
one 141
finding 143
Format and constraints 129
importing 140
listing 140
management tasks 119, 137
managing rule permissions 58
modifying 139
overview 119
policies 40
policies for 46
when to use 41
authorization server
configuration file 205
ivacld.conf 205
key and stash files 161
pdacld server process 167
preventing automating startup 173
starting 170
authorization service 6
authorization API 10
benefits 7
extending 17
interfaces 10
overview 8, 9
authorize-group-list entry 247
authzrule attach command 142
authzrule commands
attach 142
132
authzrule commands (continued)
create 139
delete 144
detach 143
find 143
list 140
modify 139
authzrule create command 139
authzrule delete command 144
authzrule detach command 143
authzrule find command 143
authzrule list command 140
authzrule modify command 139
auto-database-update-notify entry 174, 255
automatic certificate and password refresh 161
azn_cred_groups attribute 131
azn_cred_principal_name attribute 131
azn_cred_registry_id attribute 131
azn_decision_access_allowed_ext () method 120
azn_decision_access_allowed_ext() method 135
azn_decision_access_allowed() method 133
azn_engine_requested_actions attribute 120
azn_engine_target_resource attribute 120
azn_entitlement_get_entitlements() call 136
azn_entitlement_get_entitlements() method 129
azn_init_set_perminfo_attrs attribute 133
azn_init_set_perminfo_attrs initialization parameter 135
azn_perminfo_reason_rule_failed attribute 135
azn_perminfo_rules_adi_request attribute 133, 136
azn-app-host entry 218
azn-server-name entry 218
aznapi-admin-services stanza
service-id entry 215
description 215
aznapi-configuration stanza
audit-attribute entry 217
azn-app-host entry 218
azn-server-name entry 218
cache-refresh-interval entry 219
cred-attributes-entitlement-services entry 219
db-file entry 220
description 217
dynamic-adi-entitlement-services entry 221
input-adi-xml-prolog entry 221
listen-flags entry 222
logcfg entry 222
mode entry 223
pd-user-name entry 224
pd-user-pwd entry 224
permission-info-returned entry 224
policy-cache-size entry 225
resource-manager-provided-adi entry 225
xsl-stylesheet-prolog entry 226
aznapi-cred-modification-services stanza
service-id entry 227
description 227
aznapi-entitlement-services stanza
service-id entry 229
description 228
aznapi-external-authzn-services stanza
policy-trigger entry 230
description 230
aznapi-pac-services stanza
service-id entry 232
description 231
aznAPI.conf configuration file 209
Index
395
B
bannerFile entry 298
bassslcfg -config command 165
benefits of authorization service 7
bind-dn entry 266
bind-id entry 309
books
see publications ix, xii
boot-start-ivacld command 173
boot-start-ivacld entry 294
boot-start-ivmgrd command 173
boot-start-ivmgrd entry 294
boot-start-pdmgrproxyd command 174
boot-start-pdproxyd entry 295
C
CA
See certificate authority
ca-cert-download-enabled entry 256
cache-database entry 290
cache-enabled entry
ldap stanza, ivacld.conf 267
ldap stanza, ivmgrd.conf 267
ldap stanza, ldap.conf 278
ldap stanza, pdmgrproxyd.conf 267
cache-group-expire-time entry 267
cache-group-membership entry 268
cache-group-size entry 268
cache-lifetime entry 309
cache-mode entry 309
cache-policy-expire-time entry 269
cache-policy-size entry 269
cache-refresh-interval entry 219
cache-return-registry-id entry 270
cache-size entry 310
cache-use-user-cache entry 270
cache-user-expire-time entry 271
cache-user-size entry 271
CARS
See common audit service
cars-client stanza
clientPassword entry 235
clientUserName entry 235
compress entry 233
description 233
diskCachePath entry 233
doAudit entry 234
errorFilePath entry 235
flushInterval entry 236
hiWater entry 237
keyFilePath entry 236
lowWater entry 237
maxCacheFiles entry 237
maxCacheFileSize entry 238
maxErrorFiles entry 238
maxErrorFileSize entry 238
maxTraceFiles entry 239
maxTraceFileSize entry 239
numberCMThreads entry 239
numberEQThreads entry 240
numberRetries entry 240
queueSize entry 240
rebindInterval entry 241
retryInterval entry 241
serverURL entry 241
396
Administration Guide
cars-client stanza (continued)
stashFilePath entry 242
traceFilePath entry 242
traceLevel entry 242
transferSize entry 243
useDiskCache entry 243
cars-filter
description 244
cars-filter stanza
auditevent entry 244
centralized management 4
cert-ldap entry 212
cert-uraf entry 213
certificate authority
See also CA
definition 159
determining trust 162
certificates
automatic refresh 161
FTP 164
initial configuration 160
management tasks 159
revocation 164
update utilities 161
change-pwd-using-ldap-api entry
uraf-registry stanza, activedir_ldap.conf
changePassword entry 298
chgcert option of svrsslcfg command 164
clientPassword entry 235
clientUserName entry 235
cloning
POPs 106
commands
acl attach 88
acl create 84
acl delete 90
acl detach 89
acl find 89
acl list 85
acl list attribute 94
acl modify 85, 90, 91, 92
acl modify delete attribute 95
acl modify set attribute
creating extended attributes 93
modifying extended attributes 93
acl show 85, 86, 90, 91, 92
acl show attribute 94
action create 98
action delete 98
action group create 96
action group delete 97
action group list 96
action list 98
authzrule attach 142
authzrule create 139
authzrule delete 144
authzrule detach 143
authzrule find 143
authzrule list 140
authzrule modify 139
bassslcfg -config 165
config modify 158
domain create 62
domain delete 64
domain list 63
domain modify 63
group create 155, 157
318
commands (continued)
group create command 190
group import 157
group list 156, 193
group list-dn 193
login 61
object create 72
object create command 189
object delete 75
object list 73
objectspace create 66
objectspace delete 69
objectspace list 67
pdadmin group import 156
policy set
all users 153
single user 151
pop attach 108
pop create 104
pop delete 109
pop detach 109
pop find 109
pop list 105
pop modify set ipauth 113
pop modify set ipauth add 113
pop modify set ipauth remove 114
pop show 104, 105
server replicate 175
svrsslcfg -unconfig 164
user create 147, 154
user import 154
user list 148, 193
user list-dn 193
user modify password 149
user show groups 193
common audit service
disabling audit 234
enabling audit 234
common problems
reporting
describing problem 376
determining business impact 375
gathering information 376
submitting problems 376
communication
FIPS mode 2
SSL 2
TLS 2
compress entry 233
config ACL (default) 52
config option
bassslcfg command 165
configuration
server files 172
configuration entries
dynamic-adi-entitlement-services 136
input-adi-xml-prolog 136
resource-manager-provided-adi 136
xsl-stylesheet-prolog 136
configuration files
Active Directory server 207
activedir_ldap.conf 207
activedir.conf 207
amconf.properties 208
authorization server 205
aznAPI.conf 209
Boolean values 201
configuration files (continued)
common audit service 208
default location 204
default values 200
defined strings 200
Domino server 208
domino.conf 208
file names 200
general guidelines 199
integer values 201
ivacld.conf 205
ivmgrd.conf 206
LDAP client with Active Directory server 207
LDAP server 207
ldap.conf 207
pd.conf 205
pdaudit.conf 208
pdmgrproxyd.conf 206
policy proxy server 206
policy server 206
resource managers 209
runtime 205
string values 200
Web Portal Manager 208
configuration stanzas
See stanzas
configuration-database stanza
description 246
file entry 246
configurations
managing Config permissions 55
configured entry 295
configuring
initialization attributes 135
levels for step-up authentication 115
connection-inactivity entry
ldap stanza, ldap.conf 278
constraints, authorization rules 129
container names
for ADI containers 123
limitations of 123
container objects 34, 189
security considerations 77
containers for ADI 123
context information
application 120
authorization engine 120
control permission 48
conventions
typeface xiv
core technologies 1
count() function 132
creating
group container objects 189
cred-attributes-entitlement-services entry 219
credential entitlements 120
custom action groups
representation in ACL entries 82
scenario 82
custom permissions
represented in ACL entries 82
customer support
contacting 375
obtaining fixes 373
receiving updates from 374
registering with 374
searching information centers 373
Index
397
customer support (continued)
searching knowledge bases 373
searching the Internet 373
submitting problems 376
D
data integrity or redundancy 177
database
path for user registry 181
database-path entry
domain=domain_name stanza 249
domains stanza 249
ivmgrd stanza 256
db-file entry 220
debug entry 299
default
administration ACL 51
administration users and groups 187
config ACL 52
domain ACL 53
GSO ACL 52
management ACL 52
policy ACL 52
proxy ACL 53
replica ACL 52
root ACL 48, 51
security policy 43
default proxy ACL 53
default-policy-override-support entry 271
defining
security policy 45
delegate administrator, illustrated 184
delegate role
administration 185
delegated administration
administration users and groups 43
group ACL permissions 192
group container objects 189
managing policy 193
object space management 186
user management 192
delegated management
administration users and groups 187
group management 188
delegated-admin stanza
authorize-group-list entry 247
description 247
delimiters, authorization rules evaluator 128
dependencies
server 169
Deployment Administrator 43
diagnostic events 197
directory names, notation xiv
diskCachePath entry 233
dnforpd entry
uraf-registry stanza, activedir_ldap.conf 318
uraf-registry stanza, activedir.conf 314
doAudit entry 234
document model for ADI 122
domain
administrator (sec_master) 36
administrators 184
changing description 62
creating 61
deleting 64
enterprise 183
398
Administration Guide
domain (continued)
listing 63
logging in 61
modifying 62
multiple 184
subdomain, described 183
superdomain 183
domain ACL (default) 53
domain administrator 145
domain commands
create command 62
delete command 64
list command 63
modify command 63
domain entry
domain=domain_name stanza 249
domains stanza 249
uraf-registry stanza, activedir_ldap.conf 319
uraf-registry stanza, activedir.conf 315
domain=domain_name stanza
allowed-registry-substrings entry 248
database-path entry 249
description 248
domain entry 249
domains
definition of 33
managing domain permissions 59
domains stanza
allowed-registry-substrings entry 248
database-path entry 249
description 248
domain entry 249
Domino server
domino.conf 208
domino.conf configuration file 208
dynamic ADI 121
dynamic ADI retrieval entitlement services 136
dynamic group support 36, 156
dynamic groups
Active Directory 158
enabling 158
LDAP registry 158
dynamic-adi-entitlement-services 136
dynamic-adi-entitlement-services configuration entry
dynamic-adi-entitlement-services entry 221
dynamic-groups-enabled entry
ldap stanza, ldap.conf 279
uraf-registry stanza, activedir_ldap.conf 320
uraf-registry stanza, activedir.conf 315
E
education
see Tivoli technical training xiii
enable-last-login entry 265
enabled entry
ldap stanza, ldap.conf 279
uraf-registry stanza, activedir_ldap.conf
uraf-registry stanza, activedir.conf 315
uraf-registry stanza, domino.conf 312
encryption
supported ciphers 2
enhanced-pwd-policy
Tivoli Directory Server 263
enhanced-pwd-policy entry 262
enterprise domain 183
entitlement example, XML 125
320
136
entitlements
retrieval entitlement services 121
user credential 120
entries
AttributeName 327
policy-trigger 230
service-id
aznapi-admin-services stanza 215
aznapi-cred-modification-services stanza 227
aznapi-entitlement-services stanza 229
aznapi-pac-services stanza 232
aclMembership 297
ad-gc-port 325
ad-gc-server 325
allowed-registry-substrings 248
audit-attribute 217
auditevent 244
auth-using-compare 265
authMethod 297
authn-timeout 266
authorize-group-list 247
auto-database-update-notify 255
azn-app-host 218
azn-server-name 218
bannerFile 298
bind-dn 266
bind-id 309
boot-start-ivacld 294
boot-start-ivmgrd 294
boot-start-pdproxyd 295
ca-cert-download-enabled 256
cache-database 290
cache-enabled
ldap stanza, ivacld.conf 267
ldap stanza, ivmgrd.conf 267
ldap stanza, ldap.conf 278
ldap stanza, pdmgrproxyd.conf 267
cache-group-expire-time 267
cache-group-membership 268
cache-group-size 268
cache-lifetime 309
cache-mode 309
cache-policy-expire-time 269
cache-policy-size 269
cache-refresh-interval 219
cache-return-registry-id 270
cache-size 310
cache-use-user-cache 270
cache-user-expire-time 271
cache-user-size 271
cert-ldap 212
cert-uraf 213
change-pwd-using-ldap-api
uraf-registry stanza, activedir_ldap.conf 318
changePassword 298
clientPassword 235
clientUserName 235
compress 233
configured 295
connection-inactivity
ldap stanza, ldap.conf 278
cred-attributes-entitlement-services 219
database-path
domain=domain_name stanza 249
domains stanza 249
ivmgrd stanza 256
db-file 220
entries (continued)
debug 299
default-policy-override-support 271
diskCachePath 233
dnforpd
uraf-registry stanza, activedir_ldap.conf
uraf-registry stanza, activedir.conf 314
doAudit 234
domain
domain=domain_name stanza 249
domains stanza 249
uraf-registry stanza, activedir_ldap.conf
uraf-registry stanza, activedir.conf 315
dynamic-adi-entitlement-services 221
dynamic-groups-enabled
ldap stanza, ldap.conf 279
uraf-registry stanza, activedir_ldap.conf
uraf-registry stanza, activedir.conf 315
enable-last-login 265
enabled
ldap stanza, ldap.conf 279
uraf-registry stanza, activedir_ldap.conf
uraf-registry stanza, activedir.conf 315
uraf-registry stanza, domino.conf 312
enhanced-pwd-policy 262
errorFilePath 235
file 246
flushInterval 236
hiWater 237
host 280
hostname 316
ignore-suffix 280
infoBarGif 299
input-adi-xml-prolog 221
jrteHost 300
jrteProps 300
keyFilePath 236
ldap-client-timeout 321
ldap-server-config 272
LdapSSL 287
LdapSSLKeyFile 288
LdapSSLKeyFileDn 288
LdapSSLKeyFilePwd 289
listen-flags 222
log-file
ivacld stanza 250
ivmgrd stanza 257
pdmgrproxyd stanza 291
logcfg
aznapi-configuration stanza 222
ivacld stanza 251
ivmgrd stanza 257
pdaudit-filter stanza 289
login-failures-persistent 273
loginGif 300
lowWater 237
management-domain 285
master-host 286
master-port 286
max-connections-per-ad-domain
uraf-registry stanza, activedir.conf 321
max-notifier-threads 258
max-search-size
ldap stanza, ivacld.conf 273
ldap stanza, ivmgrd.conf 273
ldap stanza, ldap.conf 281
ldap stanza, pdmgrproxyd.conf 273
318
319
320
320
Index
399
entries (continued)
max-server-connections
ldap stanza, ldap.conf 281
maxCacheFiles 237
maxCacheFileSize 238
maxErrorFiles 238
maxErrorFileSize 238
maxTraceFiles 239
maxTraceFileSize 239
mode 223
multi-domain
uraf-registry stanza, activedir_ldap.conf
uraf-registry stanza, activedir.conf 316
NAB 312
notifier-wait-time 259
novell-suffix-search-enabled
ldap stanza, ldap.conf 282
numberCMThreads 239
numberEQThreads 240
numberRetries 240
passwd-ldap 213
passwd-uraf 214
pd-user-name 224
pd-user-pwd 224
PDM 313
permission-info-returned 224
permit-unauth-remote-caller 252
pid-file
ivacld stanza 252
ivmgrd stanza 259
pdmgrproxyd stanza 292
policy-cache-size 225
port
ldap stanza, ivacld.conf 274
ldap stanza, ivmgrd.conf 274
ldap stanza, ldap.conf 283
ldap stanza, pdmgrproxyd.conf 274
prefer-readwrite-server 274
primary-domain 322
provide-last-login 254
provide-last-pwd-change 255
queueSize 240
rebindInterval 241
replica 283
resource-manager-provided-adi 225
retryInterval 241
search-timeout 274
secauthority-suffix 284
server 313
serverURL 241
splashGif 300
ssl-authn-type 302
ssl-auto-refresh 302
ssl-cert-life 302
ssl-enable-fips 303
ssl-enabled 275
ssl-io-inactivity-timeout 303
ssl-keyfile
ldap stanza 276
ssl stanza 304
uraf-registry stanza, activedir_ldap.conf
ssl-keyfile-dn 276
ssl-keyfile-label
ssl stanza 304
uraf-registry stanza, activedir_ldap.conf
ssl-keyfile-pwd 324
ldap stanza 277
400
Administration Guide
321
322
323
entries (continued)
ssl-keyfile-stash 305
ssl-listening-port 305
ssl-local-domain
ssl stanza, ivacld.conf 306
ssl stanza, ivmgrd.conf 306
ssl stanza, ldap.conf 308
ssl stanza, pd.conf 306
ssl stanza, pdmgrproxyd.conf 306
ssl-maximum-worker-threads 306
ssl-port 284
ssl-pwd-life 307
ssl-v3-timeout 307
standby 260
stashFilePath 242
tcp-req-port
ivacld stanza 253
ivmgrd stanza 261
pdmgrproxyd stanza 292
tivoli_common_dir 295
traceFilePath 242
traceLevel 242
transferSize 243
unix-group
ivacld stanza 254
ivmgrd stanza 261
pdmgrproxyd stanza 293
unix-user
ivacld stanza 253
ivmgrd stanza 261
pdmgrproxyd stanza 293
uraf-registry-config 311
uraf-return-registry-id 314
uraf-registry stanza, activedir_ldap.conf 324
uraf-registry stanza, activedir.conf 316
use-email-as-user-id
uraf-registry stanza, activedir.conf 317, 324
useDiskCache 243
useEncryption 317
user-and-group-in-same-suffix 277
user-reg-host 296
user-reg-hostport 296
user-reg-server 296
user-reg-type 296
UseSSL 326
version 287
wasEmbedded 301
xsl-stylesheet-prolog 226
environment variables, notation xiv
errorFilePath entry 235
evaluation process, authorization 18
evaluator, authorization rules 128
events
auditing 197
diagnostic 197
messages 197
statistics 197
trace 197
examples
custom permissions 81
external authorization service 18
explicit ACL 47
explicit policy 12
extended attributes
ACL policies
creating 92
deleting 94
extended attributes (continued)
ACL policies (continued)
deleting values 95
listing 93
modifying 93
viewing 94
Extensible Markup Language
See XML
Extensible Style Language
See XSL
external authorization service
deploying 20
implementing 20
introduction 17
F
failover configuration 345
Federal Information Processing Standards
See FIPS
file entry 246
files
accessmanager.gif 28
configuration 205
Active Directory server 207
activedir_ldap.conf 207
activedir.conf 207
amconf.properties 208
authorization server 205
aznAPI.conf 209
common audit service 208
default location 204
Domino server 208
domino.conf 208
ivacld.conf 205
ivmgrd.conf 206
LDAP client with Active Directory server
LDAP server 207
ldap.conf 207
pdaudit.conf 208
pdmgrproxyd.conf 206
policy proxy server 206
policy server 206
resource managers 209
Web Portal Manager 208
key
renewal guidelines 165
renewing 161
regAdmin.jsp 29
regControl.jsp 29
regProp.jsp 29
runtime 205
stash
renewal guidelines 165
FIPS
communication 2
fixes, obtaining 373
flushInterval entry 236
format, authorization rules 129
FTP 164
G
GIF files
accessmanager.gif
207
Global Sign-On
See GSO
group
dynamic 156
importing 156
group accounts 145
group commands
create 155, 190
delete 157
import 157
import command 156
list 156
group container objects
creating 189
group create command 190
group list command 193
group list-dn command 193
group management 191
groups
accounts 145
adding ACL entry to ACL policy 90
creating 155, 190
definition 145
delegating management 188
deleting 157
dynamic 36
enabling dynamic 158
iv-admin 36
iv-admin group 43
ivmgrd-servers 43
listing 155
management tasks 145
managing groups permissions 57
modifying permissions 91
removing ACL entries from ACL policies
searching 155
type attribute 79
GSO
managing GSO permissions 58
GSO ACL (default) 52
guidelines
for secure object space 41
key file renewal 165
stash file renewal 165
91
H
HACMP
environment 177
guidelines for cluster 177
hacmp.log file 179
high availability
log files 179
management 178
policy server setup 178
standby policy server 178
High Availability Cluster Multiprocessing
See HACMP
hiWater entry 237
host entry 280
hostname entry 316
I
28
IBM Directory
345
Index
401
IBM Directory Server user registry
See LDAP server
ID attribute 79
ignore-suffix entry 280
infoBarGif entry 299
information centers, searching 373
inherited ACL 47, 50
inherited policy 12
initialization attributes 135
dynamic-adi-entitlement-services 136
input-adi-xml-prolog 136
resource-manager-provided-adi 136
xsl-stylesheet-prolog 136
input-adi-xml-prolog configuration entry 136
input-adi-xml-prolog entry 221
integrity of data 177
Internet, searching 373
introduction 1
IP addresses
adding network-based authorization for POPs 113
deleting network-based authorization for POPs 114
forbidding network-based authorization for POPs 113
specifying for POPs 113
iPlanet
See Sun ONE
iv-admin group 36, 43
ivacld stanza
description 250
log-file entry 250
logcfg entry 251
permit-unauth-remote-caller entry 252
pid-file entry 252
tcp-req-port entry 253
unix-group entry 254
unix-user entry 253
ivacld.conf configuration file 205
ivacld.kdb key file 161
ivacld.sth stash file 161
ivmgrd stanza
auto-database-update-notify entry 255
ca-cert-download-enabled entry 256
database-path 256
description 254
log-file entry 257
logcfg entry 257
max-notifier-threads entry 258
notifier-wait-time entry 259
pid-file entry 259
provide-last-login entry 254
provide-last-pwd-change entry 255
standby entry 260
tcp-req-port entry 261
unix-group entry 261
unix-user entry 261
ivmgrd-servers group 43
ivmgrd.conf configuration file 206
ivmgrd.kdb key file 161
ivmgrd.sth stash file 161
J
jrteHost entry 300
jrteProps entry 300
JSP files
regAdmin.jsp 29
regControl.jsp 29
regProp.jsp 29
402
Administration Guide
K
key files
definition 159
ivacld.kdb 161
ivmgrd.kdb 161
pd.kdb 161
pdmgrproxyd.kdb 161
renewal guidelines 165
renewing 161
keyFilePath entry 236
keystores, definition 159
knowledge bases
information centers 373
searching 373
the Internet 373
L
LDAP
configuration
ldap.conf 278
failover configuration 345
LDAP client
activedir_ldap.conf 207
LDAP failover
preference values 348
LDAP registry
enabling dynamic groups 158
LDAP server
ldap.conf 207
LDAP servers
failover 177
ldap stanza
auth-using-compare entry 265
authn-timeout entry 266
bind-dn entry 266
cache-enabled entry
ldap stanza, ivacld.conf 267
ldap stanza, ivmgrd.conf 267
ldap stanza, pdmgrproxyd.conf 267
ldap.conf 278
cache-group-expire-time entry 267
cache-group-membership entry 268
cache-group-size entry 268
cache-policy-expire-time entry 269
cache-policy-size entry 269
cache-return-registry-id entry 270
cache-use-user-cache entry 270
cache-user-expire-time entry 271
cache-user-size entry 271
connection-inactivity entry
ldap.conf 278
default-policy-override-support entry 271
description
ivacld.conf 262
ivmgrd.conf 262
ldap.conf 278
pdmgrproxyd.conf 262
dynamic-groups-enabled entry
ldap.conf 279
enable-last-login entry 265
enabled entry
ldap.conf 279
enhanced-pwd-policy entry 262
host entry 280
ignore-suffix entry 280
ldap stanza (continued)
ldap-server-config entry 272
login-failures-persistent entry 273
max-search-size entry
ivacld.conf 273
ivmgrd.conf 273
ldap stanza, ldap.conf 281
pdmgrproxyd.conf 273
max-server-connections entry
ldap stanza, ldap.conf 281
novell-suffix-search-enabled entry
ldap stanza, ldap.conf 282
port entry
ldap stanza, ivacld.conf 274
ldap stanza, ivmgrd.conf 274
ldap stanza, ldap.conf 283
ldap stanza, pdmgrproxyd.conf 274
prefer-readwrite-server entry 274
replica entry 283
search-timeout entry 274
secauthority-suffix entry 284
ssl-enabled entry 275
ssl-keyfile entry 276
ssl-keyfile-dn entry 276
ssl-keyfile-pwd entry 277
ssl-port entry 284
user-and-group-in-same-suffix entry 277
LDAP_ADMINLIMIT_EXCEEDED 330
ldap-client-timeout entry 321
ldap-generic-acls (internal use) 207
ldap-generic-general (internal use) 207
ldap-generic-pwd-change-error-map (internal use)
ldap-server-config entry 272
ldap.conf 347
ldap.conf configuration file 207
LdapSSL entry 287
LdapSSLKeyFile entry 288
LdapSSLKeyFileDn entry 288
LdapSSLKeyFilePwd entry 289
legal
notices 379
trademarks 380
levels for step-up authentication 115
limitations, container names 123
limitations, network-based authorization 110
Linux servers
See UNIX servers
listen-flags entry 222
local cache mode 14, 16
log files
hacmp.log 179
high availability 179
log-file entry
ivacld stanza 250
ivmgrd stanza 257
pdmgrproxyd stanza 291
logcfg entry
aznapi-configuration stanza 222
ivacld stanza 251
ivmgrd stanza 257
pdaudit-filter stanza 289
login-failures-persistent entry 273
loginGif entry 300
look-through limit 330
Lotus Domino server
See Domino server
lowWater entry 237
M
207
management ACL (default) 52
management delegation 186, 188
management domain 33
management interface 10
management region
permissions 53
management tasks
authorization rules 137
management-domain entry 285
Management/ACL permissions 53
management/Action permissions 54
Management/Config permissions 55
Management/Domain permissions 59
Management/Groups permissions 57
Management/GSO permissions 58
Management/Policy permissions 56
Management/POP permissions 55
Management/Proxy permissions 59
Management/Replica permissions 56
Management/Rule permissions 58
Management/Server permissions 55
Management/Users permissions 56
manager stanza
description 285
management-domain entry 285
master-host entry 286
master-host port entry 286
managing
ACL permissions 53
Action permissions 54
Config permissions 55
delegated administration policy 193
domain permissions 59
groups permissions 57
GSO permissions 58
object space 65
policy permissions 56
POP permissions 55
proxy permissions 59
replica permissions 56
rule permissions 58
server permissions 55
servers 167
users permissions 56
manuals
see publications ix, xii
mapping, pdadmin CLI to WPM 337
master authorization policy database 9
master-host entry 286
master-port entry 286
max-connections-per-ad-domain entry
uraf-registry stanza, activedir.conf 321
max-notifier-threads entry 175, 258
max-search-size entry
ldap stanza, ivacld.conf 273
ldap stanza, ivmgrd.conf 273
ldap stanza, ldap.conf 281
ldap stanza, pdmgrproxyd.conf 273
max-server-connections entry
ldap stanza, ldap.conf 281
maxCacheFiles entry 237
maxCacheFileSize entry 238
maxErrorFiles entry 238
maxErrorFileSize entry 238
maxTraceFiles entry 239
maxTraceFileSize entry 239
Index
403
messages 197
meta-info stanza
description 287
version entry 287
mode entry 223
model of authorization 6
model, document 122
modes
authorization API local cache 16
authorization API remote cache 15
multi-domain entry
uraf-registry stanza, activedir_ldap.conf
uraf-registry stanza, activedir.conf 316
multi-factor authentication 116
multiple domain 184
example 184
illustrated 184
multiple-tenancy policy server 181
N
NAB entry 312
network-based authorization
adding for POPs 113
algorithm 110
deleting for POPs 114
forbidding or POPs 113
limitations 110
specifying IP addresses and ranges
notation
environment variables xiv
path names xiv
typeface xiv
notices 379
notification delay time 176
notifier-wait-time entry 176, 259
novell-suffix-search-enabled entry
ldap stanza, ldap.conf 282
numberCMThreads entry 239
numberEQThreads entry 240
numberRetries entry 240
O
object commands
create 72, 189
delete 75
list 73
object create command 72, 189
object delete command 75
object list command 73
object space
definition of 34
delegating management 186
management tasks 65
object spaces
browsing 67
copying 67
creating 65
deleting 69
exporting 68
importing 68
listing 67
objects
creating 71
deleting 74
404
Administration Guide
113
321
objects (continued)
exporting 74
importing 73
listing 73
management tasks 71
objectspace commands
create 66
delete 69
list 67
objectspace create command
objectspace delete 69
objectspace list 67
online publications
accessing xii
ordering publications xii
overview 1
66
P
passwd-ldap entry 213
passwd-uraf entry 214
password
troubleshooting 185
Password policy
LDAP 329
passwords
automatic refresh 161
changing 148
management tasks 159
path names, notation xiv
pd_start utility
displaying server status 171
restarting servers 171
starting servers 170
stopping servers 171
pd-user-name entry 224
pd-user-pwd entry 224
pd.conf configuration file 205
pd.kdb key file 161
pd.sth stash file 161
pdacld server process
authorization server 167
starting 170
pdadmin command interface 4
pdaudit-filter stanza
description 289
logcfg entry 289
pdaudit.conf configuration file 208
PDCA
reconfiguring policy server 163
PDCA certificate
See certificates
pdconfig stanza
description
ldap.conf 287
LdapSSL entry 287
LdapSSLKeyFile entry 288
LdapSSLKeyFileDn entry 288
LdapSSLKeyFilePwd entry 289
PDM entry 313
pdmgr
See policy server
pdmgrd server process
policy server 167
starting 170
pdmgrproxyd server process
policy proxy server 167
pdmgrproxyd server process (continued)
starting 170
pdmgrproxyd stanza
cache-database entry 290
description 290
log-file entry 291
pid-file entry 292
tcp-req-port entry 292
unix-group entry 293
unix-user entry 293
pdmgrproxyd.conf configuration file 206
pdmgrproxyd.kdb key file 161
pdmgrproxyd.sth stash file 161
pdrte stanza
boot-start-ivacld entry 294
boot-start-ivmgrd entry 294
boot-start-pdproxyd entry 295
configured entry 295
description 294
tivoli_common_dir entry 295
user-reg-host entry 296
user-reg-hostport entry 296
user-reg-server entry 296
user-reg-type entry 296
pdwpm stanza
aclMembership entry 297
authMethod entry 297
bannerFile entry 298
changePassword entry 298
debug entry 299
description 296
infoBarGif entry 299
jrteHost entry 300
jrteProps entry 300
loginGif entry 300
splashGif entry 300
wasEmbedded entry 301
permission_info attribute list 135
permission-info-returned entry 224
permissions
/Management/ACL permissions 53
/management/Action permissions 54
/Management/Config permissions 55
/Management/Domain permissions 59
/Management/Groups permissions 57
/Management/GSO permissions 58
/Management/Policy permissions 56
/Management/POP permissions 55
/Management/Proxy permissions 59
/Management/Replica permissions 56
/Management/Rule permissions 58
/Management/Server permissions 55
/Management/Users permissions 56
ACL entries
modifying 91
adding ACL entry to ACL policy 90
administration users 43
control (c) 48
creating in action group 97
custom 81
custom, example 81
defaults 80
deleting from action group 98
iv-admin group 43
listing for action group 98
roles 185
sec_master 43
permissions (continued)
traverse (T) 48
permissions attribute 79
permissions attrribute
represented in ACL entries 82
permit-unauth-remote-caller entry 252
pid-file entry
ivacld stanza 252
ivmgrd stanza 259
pdmgrproxyd stanza 292
policies
authorization rules 40, 46
managing policy permissions 56
POPs 40
policy ACL (default) 52
policy commands
set
all users 153
single user 151
policy database 9
policy enforcer 6
policy proxy server
configuration file 206
introducing 168
key and stash files 161
pdmgrproxyd server process 167
pdmgrproxyd.conf 206
preventing automating startup 174
starting 170
policy server
configuration file 206
high availability setup 178
ivmgrd.conf 206
key and stash files 161
overview 9
pdmgrd server process 167
preventing automating startup 173
reconfiguring PDCA 163
standby server 178
starting 170
policy-cache-size entry 225
pop attach command 108
POP attributes 45, 101
audit level 111
configuring 111
management tasks 102
setting 111
time of day 112
warning mode 111
pop commands
attach 108
create 104
delete 109
detach 109
find 109
list 105
show 104, 105
pop create command 104
pop delete command 109
pop detach command 109
pop find command 109
pop list command 105
pop modify set ipauth add command 113
pop modify set ipauth command 113
pop modify set ipauth remove command 114
POP policies, defining 11
pop show command 104, 105
Index
405
POPs
adding network-based authorization 113
attaching to object 108
attributes of 45
cloning 106
configuring attributes 111
creating 102
definition of 13, 37
deleting 109
deleting network-based authorization 114
detaching from object 108
exporting
all 107
multiple 107
one 107
finding where attached 109
forbidding network-based authorization 113
importing 106
introducing 101
listing 105
management tasks 102
managing POP permissions 55
modifying 104
network-based authorization 110
policies 40
Quality of Protection 114
showing 105
specifying IP addresses and ranges 113
versus authorization rules 40
port entry
ldap stanza, ivacld.conf 274
ldap stanza, ivmgrd.conf 274
ldap stanza, ldap.conf 283
ldap stanza, pdmgrproxyd.conf 274
prefer-readwrite-server entry 274
preference values (LDAP failover) 348
preventing automating startup
authorization server 173
policy proxy server 174
policy server 173
primary group
default permissions 80
primary-domain entry 322
prolog statements 136
protected object policies
See POPs
protected object policy
See POPs
protected object space 34
guidelines 41
protected objects
management tasks 71
Protected Resource Administrator 43
provide-last-login entry 254
provide-last-pwd-change entry 255
proxies
managing proxy permissions 59
proxy ACL (default) 53
publications ix
accessing online xii
ordering xii
Q
QoP
See Quality of Protection
406
Administration Guide
Quality of Protection
introduction 2
setting 114
queueSize entry 240
R
RAID
See Redundant Array of Independent Disks
reason codes
rule failure 135
rebindInterval entry 241
redundancy of data 177
Redundant Array of Independent Disks 177
refresh, certificates and passwords 161
regAdmin.jsp file 29
regControl.jsp file 29
regProp.jsp file 29
remote cache mode 14, 15
renewals
key files 161
stash files 161
replica 347
replica ACL (default) 52
replica entry 283
replicas
managing replica permissions 56
replicate authorization database 174
replication 10
resolving ACL request 49
resource manager 6
requesting ADI 133
resource managers
aznAPI.conf 209
configuration file 209
resource objects 34
resource requests 18
resource-manager-provided-adi configuration entry
resource-manager-provided-adi entry 225
responsibilities
Deployment Administrator 43
Protected Resource Administrator 43
Security Policy Administrator 43
restarting servers 171
restriction, ADI XML document model 123
retrieval entitlement services 136
retrieval entitlements service 120, 121
retryInterval entry 241
roles
assigning role assignment 186
defined 185
delegate 185
permissions 185
role activation 186
role assignment 186
role creation 186
root ACL (default) 48, 51
rule failure reason code 135
runtime
configuration file 205
pd.conf 205
reconfiguring secure communication 163
136
S
scalability 3, 10
search-timeout entry 274
sec_master 183
sec_master domain administrator 36
sec_master user 36, 43
secauthority-suffix entry 284
secure communication
reconfiguring runtime 163
Secure Socket Layer
See SSL
security
policy 185
security considerations
ACL policies 77
container objects 77
security policy 37
default 43
defining 45
implementing 11
overview 5
Security Policy Administrator 43
server
replicating 175
server entry 313
server replicate command 175
servers
automating startup 173
configuration files 172
dependencies for 169
displaying status 171
HACMP cluster 177
LDAP servers 177
management of 167
managing server permissions 55
primary and standby 177
restarting using the pd_start utility 171
starting and stopping for UNIX 170
starting and stopping for Windows 171
starting manually 170
starting using the pd_start utility 170
stopping using the pd_start utility 171
serverURL entry 241
shared disk arrays 177
software updates, receiving 374
sources for ADI 121
sparse ACL model 47
splashGif entry 300
SSL
communication 2
reconfiguring runtime 163
ssl stanza
description
ivacld.conf 301
ivmgrd.conf 301
ldap.conf 308
pd.conf 301
pdmgrproxyd.conf 301
ssl-authn-type entry 302
ssl-auto-refresh entry 302
ssl-cert-life entry 302
ssl-enable-fips entry 303
ssl-io-inactivity-timeout entry 303
ssl-keyfile entry 304
ssl-keyfile-label entry 304
ssl-keyfile-stash entry 305
ssl-listening-port entry 305
ssl stanza (continued)
ssl-local-domain entry
ldap.conf 308
ssl stanza, ivacld.conf 306
ssl stanza, ivmgrd.conf 306
ssl stanza, pd.conf 306
ssl stanza, pdmgrproxyd.conf 306
ssl-maximum-worker-threads entry 306
ssl-pwd-life entry 307
ssl-v3-timeout entry 307
ssl-authn-type entry 302
ssl-auto-refresh entry 302
ssl-cert-life entry 302
ssl-enable-fips entry 303
ssl-enabled entry 275
ssl-io-inactivity-timeout entry 303
ssl-keyfile entry
ldap stanza 276
ssl stanza 304
uraf-registry stanza, activedir_ldap.conf 322
ssl-keyfile-dn entry 276
ssl-keyfile-label entry
ssl stanza 304
uraf-registry stanza, activedir_ldap.conf 323
ssl-keyfile-pwd entry 324
ldap stanza 277
ssl-keyfile-stash entry 305
ssl-listening-port entry 305
ssl-local-domain entry
ssl stanza, ivacld.conf 306
ssl stanza, ivmgrd.conf 306
ssl stanza, ldap.conf 308
ssl stanza, pd.conf 306
ssl stanza, pdmgrproxyd.conf 306
ssl-maximum-worker-threads entry 306
ssl-port entry 284
ssl-pwd-life entry 307
ssl-v3-timeout entry 307
standby entry 260
stanza entries
See entries
stanzas
authentication-mechanisms 211
aznapi-admin-services 215
aznapi-configuration 217
aznapi-cred-modification-services 227
aznapi-entitlement-services 228
aznapi-external-authzn-services 230
aznapi-pac-services 231
cars-client 233
cars-filter 244
configuration-database 246
delegated-admin 247
domain=domain_name 248
domains 248
general format 211
ivacld 250
ivmgrd 254
ldap
ivacld.conf 262
ivmgrd.conf 262
ldap.conf 278
pdmgrproxyd.conf 262
ldap-generic-acls (internal use) 207
ldap-generic-general (internal use) 207
ldap-generic-pwd-change-error-map (internal use)
manager 285
Index
207
407
stanzas (continued)
meta-info 287
pdaudit-filter 289
pdconfig
ldap.conf 287
pdmgrproxyd 290
pdrte 294
pdwpm 296
ssl
ivacld.conf 301
ivmgrd.conf 301
ldap.conf 308
pd.conf 301
pdmgrproxyd.conf 301
uraf-registry
activedir_ldap.conf 318
activedir.conf 314
domino.conf 312
ivacld.conf 308
ivmgrd.conf 308
pdmgrproxyd.conf 308
xmladi-attribute-definition 326
starting servers
UNIX 170
using the pd_start utility 170
using the Windows Services Control Panel
Windows 171
stash files
definition 160
ivacld.sth 161
ivmgrd.sth 161
pd.sth 161
pdmgrproxyd.sth 161
renewal guidelines 165
renewing 161
stashFilePath entry 242
statistics 197
status, server 171
step-up authentication
applying 115
configuring 115
versus multi-factor authentication 116
stopping servers
UNIX 170
using the pd_start utility 171
using the Windows Services Control Panel
Windows 171
string identifiers 129
subdomain 183
sum() function 132
Sun Java System Directory Server
LDAP_ADMINLIMIT_EXCEEDED 330
look-through limit 330
superdomain 183
support
See customer support
svrsslcfg -unconfig command 164
T
tasks
role activation 186
role administration 186
role assignment 186
role creation 186
roles 185
types 186
408
Administration Guide
172
tcp-req-port entry
ivacld stanza 253
ivmgrd stanza 261
pdmgrproxyd stanza 292
Tivoli Access Manager runtime package
Tivoli Information Center xii
Tivoli technical training xiii
Tivoli user groups xiii
tivoli_common_dir entry 295
TLS
communication 2
reconfiguring runtime 163
trace data 197
traceFilePath entry 242
traceLevel entry 242
trademarks 380
training, Tivoli technical xiii
transferSize entry 243
Transport Layer Security
See TLS
traverse permission 48
trust determination, certificates 162
type attribute
any-authenticated 79
any-other 79
categories 79
group 79
unauthenticated 79
user 79
typeface conventions xiv
types of
Tivoli Access Manager servers 167
Tivoli Access Manager utilities 170
161
U
172
unauthenticated
adding ACL entry to ACL policy 90
modifying permissions 91
removing ACL entries from ACL policies
type attribute 79
unauthenticated requests 39
unauthenticated user 38
UNIX servers
starting and stopping 170
unix-group entry
ivacld stanza 254
ivmgrd stanza 261
pdmgrproxyd stanza 293
unix-user entry
ivacld stanza 253
ivmgrd stanza 261
pdmgrproxyd stanza 293
update-notifier threads 175
uraf-registry stanza
ad-gc-port entry 325
ad-gc-server entry 325
bind-id entry 309
cache-lifetime entry 309
cache-mode entry 309
cache-size entry 310
change-pwd-using-ldap-api entry
activedir_ldap.conf 318
description
activedir_ldap.conf 318
activedir.conf 314
domino.conf 312
91
uraf-registry stanza (continued)
description (continued)
ivacld.conf 308
ivmgrd.conf 308
pdmgrproxyd.conf 308
dnforpd entry
activedir_ldap.conf 318
activedir.conf 314
domain entry
activedir_ldap.conf 319
activedir.conf 315
dynamic-groups-enabled entry
activedir_ldap.conf 320
activedir.conf 315
enabled entry 312
activedir_ldap.conf 320
activedir.conf 315
hostname entry 316
ldap-client-timeout entry 321
max-connections-per-ad-domain entry
activedir.conf 321
multi-domain entry
activedir_ldap.conf 321
activedir.conf 316
NAB entry 312
PDM entry 313
primary-domain entry 322
server entry 313
ssl-keyfile entry
activedir_ldap.conf 322
ssl-keyfile-label entry
activedir_ldap.conf 323
ssl-keyfile-pwd entry 324
uraf-registry-config entry 311
uraf-return-registry-id entry 314
activedir_ldap.conf 324
activedir.conf 316
use-email-as-user-id entry
activedir.conf 317, 324
useEncryption entry 317
UseSSL entry 326
uraf-registry-config entry 311
uraf-return-registry-id entry 314
uraf-registry stanza, activedir_ldap.conf 324
uraf-registry stanza, activedir.conf 316
use-email-as-user-id entry
uraf-registry stanza, activedir.conf 317, 324
useDiskCache entry 243
useEncryption entry 317
user
credential entitlements 120
listing 147
searching 147
user accounts 145
user commands
create 147
delete 154
import 154
list 148
modify password 149
user groups, Tivoli xiii
user list command 193
user list-dn command 193
user management 192
user policies
modifying for a user 149
setting for a user 149
user registries
Active Directory server 207
Active Directory with LDAP client 207
Domino server 208
LDAP server 207
user registry
differences 329
maximum values 334
user show groups command 193
user-and-group-in-same-suffix entry 277
user-reg-host entry 296
user-reg-hostport entry 296
user-reg-server entry 296
user-reg-type entry 296
users
accounts 145
adding ACL entry to ACL policy 90
administrator 36
administrator, administrator 184
administrator, domain 184
administrator, sec_master 183
administrator, senior 184
administrator, support 185
administrator, Tivoli Access Manager 184
changing passwords 148
creating 146
definition 145
delegate 185
deleting 154
importing 153
management tasks 145
managing users permissions 56
modifying permissions 91
removing ACL entries from ACL policies 91
sec_master 36, 43
setting user policy
modify user policy 149
type attribute 79
UseSSL entry 326
utilities 170
manual certificate updates 161
V
variables, notation for
version entry 287
xiv
W
wasEmbedded entry 301
Web Portal Manager 4
accessing online help 27
amconf.properties 208
common tasks 26
configuration file 208
customizing 28
customizing images 28
logging in 27
rebranding 28
signing off 27
starting for administration 26
Windows
starting and stopping servers 171
Index
409
X
XML
ADI containers and container names 123
ADI document model 122
ADI document model restriction 123
ADI name/value pair attributes 124
authorization rules 122
entitlement document example 125
prolog statements 136
xmladi-attribute-definition stanza
AttributeName entry 327
definition 326
XSL
authorization rules 122
prolog statements 136
xsl:template statement 129
xsl:when statement 131
xsl-stylesheet-prolog configuration entry 136
xsl-stylesheet-prolog entry 226
xsl:template statement 129
xsl:when statement 131
410
Administration Guide
Printed in USA
SC23-6504-01
Download PDF
Similar pages
IBM Tivoli Netcool Configuration Manager: Installation and