IBM BS029ML Self Help Guide - Page 112

Recon security, 4.2.3 Change user IDs and passwords

Page 112 highlights

4.2.2 Reconfigure security In WebSphere Portal Version 6, the resource permissions are all keyed on the extId of the users or groups. This makes the security reconfiguration much more involved. The reason is that switching the LDAP server implies all extIds used for resource permissions will be invalid in the new LDAP server, if extIds are mapped to a unique attributes created by the LDAP system, such as ibm-entryUUID (IBM Tivoli Directory Server), or objectGUID (Microsoft Active Directory). Thus, the simple procedure of "disable-reenable" security may wipe out all of the Portal Access Control configuration. The solution is to have a full XMLaccess export on all protected resources in all domains. and a full XMLaccess of the users and groups before security reconfiguration, and import these XML files back to recreate the permission configuration. If Application Groups are used, they must be recreated by importing the users and groups XML file before the permissions can be recreated. Important: Do not run "disable-security" before you understand its consequences. If you are unsure, contact IBM WebSphere Portal support before taking any action. 4.2.3 Change user IDs and passwords For portal security configuration, there are mainly four user IDs and one group required in the LDAP. To successfully run the configuration task, however, you also need a couple of groups for WebSphere Web Content Management and Portal Document Manager. In this Redpaper, we only discuss the issues with Portal configuration and problem determination, and the users and groups used in Portal and WebSphere Application Server. The four user IDs and one group are referenced in wpconfig.properties as: WasUserid: This is the administrator user for WebSphere Application Server, sometimes called Server ID. You use this ID to start and stop the server, and to log on to the administrative console for any administration configuration on the application server. This user ID can be any user in the LDAP server. It does not necessarily have any rights in the LDAP. LDAPBindID: This is the user ID that WebSphere Application Server uses to bind to the LDAP server. It must be able to authenticate user IDs and have the necessary access rights (read/write/modify/delete) on the LDAP server, depending on how the application server is configured to use the LDAP server. PortalAdminId: This is the portal administrator user. It is the most important user in portal configuration, but this user can be any LDAP user that can be searched. Make sure you always specify the full user Distinguished Name (DN) on this line. PortalAdminGroupId: This is the portal administrator group. Any user IDs in this group should have the same administrative rights as the portal administrator user does. In some cases, you can disable the portal administrator user ID and only administrate your portal server using user IDs within this group LDAPAdminUId: This user ID is used by WebSphere Member Manager to bind to the LDAP server for its inquires to the LDAP. Like LDAPBindID, it should have the necessary access rights to be able to operate on the sub trees in the LDAP such that portal can make changes to the users and groups. Since these user IDs can be all different at one extreme or all the same at the other, when you make any changes to the users, you have to understand the implications. 98 IBM WebSphere Portal V6 Self Help Guide

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242

98
IBM WebSphere Portal V6 Self Help Guide
4.2.2
Reconfigure security
In WebSphere Portal Version 6, the resource permissions are all keyed on the extId of the
users or groups. This makes the security reconfiguration much more involved. The reason is
that switching the LDAP server implies all extIds used for resource permissions will be invalid
in the new LDAP server, if extIds are mapped to a unique attributes created by the LDAP
system, such as ibm-entryUUID (IBM Tivoli Directory Server), or objectGUID (Microsoft
Active Directory). Thus, the simple procedure of “disable-reenable” security may wipe out all
of the Portal Access Control configuration. The solution is to have a full XMLaccess export on
all protected resources in all domains. and a full XMLaccess of the users and groups before
security reconfiguration, and import these XML files back to recreate the permission
configuration. If Application Groups are used, they must be recreated by importing the users
and groups XML file before the permissions can be recreated.
4.2.3
Change user IDs and passwords
For portal security configuration, there are mainly four user IDs and one group required in the
LDAP. To successfully run the configuration task, however, you also need a couple of groups
for WebSphere Web Content Management and Portal Document Manager. In this Redpaper,
we only discuss the issues with Portal configuration and problem determination, and the
users and groups used in Portal and WebSphere Application Server.
The four user IDs and one group are referenced in wpconfig.properties as:
±
WasUserid: This is the administrator user for WebSphere Application Server, sometimes
called Server ID. You use this ID to start and stop the server, and to log on to the
administrative console for any administration configuration on the application server. This
user ID can be any user in the LDAP server. It does not necessarily have any rights in the
LDAP.
±
LDAPBindID: This is the user ID that WebSphere Application Server uses to bind to the
LDAP server. It must be able to authenticate user IDs and have the necessary access
rights (read/write/modify/delete) on the LDAP server, depending on how the application
server is configured to use the LDAP server.
±
PortalAdminId: This is the portal administrator user. It is the most important user in portal
configuration, but this user can be any LDAP user that can be searched. Make sure you
always specify the full user Distinguished Name (DN) on this line.
±
PortalAdminGroupId: This is the portal administrator group. Any user IDs in this group
should have the same administrative rights as the portal administrator user does. In some
cases, you can disable the portal administrator user ID and only administrate your portal
server using user IDs within this group
±
LDAPAdminUId: This user ID is used by WebSphere Member Manager to bind to the
LDAP server for its inquires to the LDAP. Like LDAPBindID, it should have the necessary
access rights to be able to operate on the sub trees in the LDAP such that portal can make
changes to the users and groups.
Since these user IDs can be all different at one extreme or all the same at the other, when you
make any changes to the users, you have to understand the implications.
Important:
Do not run “disable-security” before you understand its consequences. If you
are unsure, contact IBM WebSphere Portal support before taking any action.