ACE admin security configuration with queue-based authorization and LDAP authentication step-by-step

Creating System Groups and Users at OS Level (meaning on your local machine)

Please note that these users are not the webui users. They are just dummy users whose privileges will be inherited by the webui users you will create later or feed via LDAP. If you don’t want to create these dummy users, you can use your own system user and group.

In this example, I am creating 3 local users and groups.

Users:
iibadm ==> for administrators
iibdev ==> for developers
iibusers ==> for standard users

Groups:
inodeadmgrp ==> for administrator group
inodedevgrp ==> for developers group
stdusersgrp ==> for standard users group

OPTIONAL – Delete users and groups if already existent

sudo userdel –remove iibadm
sudo userdel –remove iibdev
sudo userdel –remove iibusers

sudo groupdel inodeadmgrp
sudo groupdel inodedevgrp
sudo groupdel stdusersgrp

Create the 3 system level users and groups
sudo useradd iibadm
sudo useradd iibdev
sudo useradd iibusers
sudo groupadd inodeadmgrp
sudo groupadd inodedevgrp
sudo groupadd stdusersgrp

Add users to their respective groups

sudo usermod -a -G inodeadmgrp iibadm
sudo usermod -a -G inodedevgrp iibdev
sudo usermod -a -G stdusersgrp iibusers

Verify that users are in their respective groups
id -a iibadm
uid=1014(iibadm) gid=1016(iibadm) groups=1016(iibadm),1019(inodeadmgrp)
id -a iibdev
uid=1015(iibdev) gid=1017(iibdev) groups=1017(iibdev),1020(inodedevgrp)
id -a iibusers
uid=1016(iibusers) gid=1018(iibusers) groups=1018(iibusers),1022(stdusersgrp)

1. Creating the default system queues
Some of the default system queues are no longer created by default. However, a script called iib_createqueues.sh is provided in the /opt/IBM/ace.0.0.x/server/sample/wmq to help you create those system queues easily. You should always first check and make sure that these system queues are not already created. Here is the list of the system queues created by the script.

SYSTEM.BROKER.TIMEOUT.QUEUE
SYSTEM.BROKER.AGGR.REQUEST
SYSTEM.BROKER.AGGR.CONTROL
SYSTEM.BROKER.AGGR.REPLY
SYSTEM.BROKER.AGGR.TIMEOUT
SYSTEM.BROKER.AGGR.UNKNOWN
SYSTEM.BROKER.SEQ.GROUP
SYSTEM.BROKER.SEQ.NUMBER
SYSTEM.BROKER.SEQ.EXPIRY
SYSTEM.BROKER.EDA.COLLECTIONS
SYSTEM.BROKER.EDA.EVENTS
SYSTEM.BROKER.WS.INPUT
SYSTEM.BROKER.WS.REPLY
SYSTEM.BROKER.WS.ACK
SYSTEM.BROKER.MB.TOPIC
SYSTEM.BROKER.ADAPTER.PROCESSED
SYSTEM.BROKER.ADAPTER.FAILED
SYSTEM.BROKER.ADAPTER.NEW
SYSTEM.BROKER.ADAPTER.INPROGRESS
SYSTEM.BROKER.ADAPTER.UNKNOWN
SYSTEM.BROKER.MODEL.QUEUE
SYSTEM.BROKER.CD.MODEL
SYSTEM.BROKER.FTE.MODEL
SYSTEM.BROKER.DC.RECORD
SYSTEM.BROKER.DC.BACKOUT
SYSTEM.BROKER.DC.AUTH
SYSTEM.BROKER.AUTH

These system queues can also be created manually via the MQ command prompt. To manually create the system queues, run the command below replacing the OBJECT_NAME with the name of the system queue to be created. Please remember to execute the command must be run for each required system queue.

runmqsc YOURQUEUEMANAGER
define qlocal (OBJECT_NAME)

Moreover, when you execute the mqsicreatebroker command to create an integration node with an associated queue manager, the system queue SYSTEM.BROKER.DC.AUTH is automatically created after successful execution of the command. In addition, the integration server authorization queue SYSTEM.BROKER.AUTH.IS is created (if it did not already exist), where IS is the name of the integration server when you run mqsicreateexecutiongroup command to create an integration server on an integration node for which you have enabled queue-based administration security. The queue SYSTEM.BROKER.AUTH is created when you use the mqsichangeauthmode command to enable queue-based administration security (mq mode) on the integration node.

Please, node that if you enable the admin security configuration in the yaml file then you should create these system queues if they don’t already exist. Also, the SYSTEM.BROKER.AUTH.IS is not created by the script. In case you did not run the mqsicreateexecutiongroup command to create the Integration Server, then you should manually create this queue.

To execute the script, run
./iib_createqueues.sh YOURQUEUEMANAGER PrimaryUNIXSystemLevelGroup

Please, note that PrimaryUNIXSystemLevelGroup can be any UNIX system group created. In our case, this group can be inodeadmgrp, or inodeadmgrp, or any dummy group.

2. Setting Up Role-Based Security

Run the following MQ commands to grant full administrative access to all broker resources for the group inodeadmgrp.
setmqaut -m YOURQUEUEMANAGER -t qmgr -g inodeadmgrp +connect +inq
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.AUTH -t queue -g inodeadmgrp -all +inq +put +set
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.DC.AUTH -t queue -g inodeadmgrp -all +inq +set
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.AUTH.IS -t queue -g inodeadmgrp -all +inq +put +set

Replace IS by the name of your IS. You should have multiple lines of of the setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.AUTH.IS -t queue -g inodeadmgrp -all +inq +put +set if you have multiple ISs or use the wild card (*) character as in SYSTEM.BROKER.AUTH.*.
If you would like to know how to create permission for multiple EGs, click here.

Verify your configuration
dmpmqaut -m YOURQUEUEMANAGER -g inodeadmgrp

Run the following MQ commands to grant full administrative access to all broker resources for the group inodedevgrp.
setmqaut -m YOURQUEUEMANAGER -t qmgr -g inodedevgrp +connect +inq
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.AUTH -t queue -g inodedevgrp -all +inq +put +set
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.DC.AUTH -t queue -g inodedevgrp -all +inq +set
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.AUTH.IS -t queue -g inodedevgrp -all +inq +put +set

Verify your configurations
dmpmqaut -m YOURQUEUEMANAGER -g inodedevgrp

Run the following MQ commands to grant standard access to all broker resources for the group stdusersgrp.
setmqaut -m YOURQUEUEMANAGER -t qmgr -g stdusersgrp +connect +inq
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.AUTH -t queue -g stdusersgrp -all +inq
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.DC.AUTH -t queue -g stdusersgrp -all +inq +set
setmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER.AUTH.IS -t queue -g stdusersgrp -all +inq

Verify your configuration
dmpmqaut -m YOURQUEUEMANAGER -g stdusersgrp

For a complete list of the permissions, read the Setting queue-based permissions on Linux, UNIX, and Windows systems article.

Refresh the MQ security settings
runmqsc YOURQUEUEMANAGER
REFRESH SECURITY (*)

2. (OPTIONAL) Use the dspmqaut command to check administrative security settings on each system queue for all 3 groups

For example:

dspmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER. AUTH -t queue -g inodeadmgrp

dspmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER. AUTH -t queue -g inodedevgrp

dspmqaut -m YOURQUEUEMANAGER -n SYSTEM.BROKER. AUTH -t queue -g stdusersgrp

1. Validate LDAP User Authentication Outside of ACE

You need to make sure your LDAP user can successfully authenticate against the LDAP server outside ACE. There is a java standalone tool provided on the Internet to help you accomplish that. Click here to download the tool.

We defined 3 users in the LDAP server as below:

“Ldap host” = ldap://localhost:389
“binding userid” : uid=myAceAdmin,ou=IIBAdmins,dc=afritec,dc=tg
“binding password” : passw0rd
“Ldap baseDN” : dc=afritec,dc=tg
“Ldap uid attr” : uid
“Admin userid” : myAceAdmin
“Admin passwd” : passw0rd

“Ldap host” = ldap://localhost:389
“binding userid” : cn=’My Dev,ou=finance,dc=afritec,dc=tg’
“binding password” : passw0rd
“Ldap baseDN” : dc=afritec,dc=tg
“Ldap uid attr” : cn
“Admin userid” : ‘My Dev’
“Admin passwd” : passw0rd

“Ldap host” = ldap://localhost:389
“binding userid” : cn=stdUsers,ou=IIBStdUsers,dc=afritec,dc=tg
“binding password” : passw0rd
“Ldap baseDN” : dc=afritec,dc=tg
“Ldap uid attr” : cn
“Admin userid” : stdUser
“Admin passwd” : passw0rd

Note that binding userid for myAceAdmin is uid=myAceAdmin,ou=IIBAdmins,dc=afritec,dc=tg and for the other users, it starts with cn. Though this is completely fine, it is not recommended as this might create a lot of trouble when setting up the ldapUrl in ACE.

Moreover, if your user failed to authenticate using the LDAP tool that means it would not work in ACE neither. At this point you need to engage your LDAP admin for further assistance because support for LDAP configuration is not ACE support team responsibility.

Finally, you should inquire from your OS admin which escape character applies to the underlying OS. Improperly escaping you LDAP configuration values might result in binding failure. If you notice in this example on Redhat 7, the escape character for values that include space is ‘ as in cn=’My Dev,ou=finance,dc=afritec,dc=tg’ or ‘My Dev’

2. Set the LDAP URL

The syntax for this task is outlined in the ACE knowledge center.
To use command, click here for instructions.

If you prefer to edit the node.conf.yaml file then click here.

mqsichangeproperties ACE11NODE -b webadmin -o server -n ldapUrl -v \”ldap://localhost:389/dc=afritec,dc=tg?cn\”
or
mqsichangeproperties ACE11NODE -b webadmin -o server -n ldapUrl -v \”ldap://localhost:389/dc=afritec,dc=tg?uid\”

Note: You should ONLY do steps 3 through 6 if you are going to authenticate a single user because once you set those binding credentials in the mqsisetdbparms security identity, ACE will always attempt to use those binding credentials no matter what other user credentials you provide. All servers that previously used anonymous bind by default start to use the details defined in an ldap::adminAuthentication entry. To make things easy, leave those as default, and you can authenticate as many users as defined on the LDAP server.

3. Set the LDAP Security Identity Using mqsisetdbparms Command

mqsisetdbparms ACE11NODE -n ldap::adminAuthentication -u uid=myAceAdmin,ou=People,dc=afritec,dc=tg -p passw0rd

4. Verify that the security identity is set correctly with mqsireportdbparms

mqsireportdbparms ACE11NODE -n ldap::adminAuthentication

5. Set the ldapBindDn

mqsichangeproperties ACE11NODE -b webadmin -o server -n ldapBindDn -v ldap::adminAuthentication

6. Set the ldapBindPassword

mqsichangeproperties ACE11NODE -b webadmin -o server -n ldapBindPassword -v ldap::adminAuthentication

In some cases, you would find that the binding userid and binding password are different than those of the LDAP baseDN and your LDAP password.

For example:

“Ldap host” = ldap://cisnet.mylearning.org:389
“binding userid” : CN=AFRITECDEV,OU=Service Accounts,OU=_Special Accounts,DC=corp,DC=tec,DC=com
“binding password” : “hU@t9^g4”
“Ldap baseDN” : OU=_People,DC=corp,DC=tec,DC=com
“Ldap uid attr” : emSaleDevOps
“Admin userid” : koliko
“Admin passwd” : ‘BD#4!#gu

In such case, you must implement step 3 through 6 as above. It is always recommended that you use the LDAP authenticator tool to determine the exact values for the configuration parameters.

For example:

java -jar LdapAuthentication.jar ldap://cisnet.mylearning.org:389 “CN=AFRITECDEV,OU=Service Accounts,OU=_Special Accounts,DC=corp,DC=tec,DC=com” “hU@t9^g4” “OU=_People,DC=corp,DC=tec,DC=com” emSaleDevOps koliko BD#4!#gu

If the command executes successfully, you should get something like below:

@WMBL3: successful bind
@WMBL3: successfull search
Starting Authentication
Found the user, DN is CN=Koliko Yomele,OU=Contractors,OU=_People,DC=corp,DC=tec,DC=com
@WMBL3 : check if the password is correct
@WMBL3: successful authentication
@WMBL3 : Commands for WebUI ldap authentication :

1. mqsisetdbparms ACENODE -n ldap:: adminAuthorization -u “cn= Koliko Yomele,OU=Contractors,OU=_People,DC=corp,DC=tec,DC=com” -p “hU@t9^g4”
Or
mqsisetdbparms ACENODE -n ldap::myLDAPServer -u “cn= Koliko Yomele,OU=Contractors,OU=_People,DC=corp,DC=tec,DC=com” -p “hU@t9^g4”

2. mqsichangeproperties ACENODE -b webadmin -o server -n ldapAuthenticationUri -v \”ldap://cisnet.mylearning.org:389/OU=_People,DC=corp,DC=tec,DC=com?emSaleDevOps\”

3. mqsiwebuseradmin ACENODE -c -u koliko -x -r

Now, you can directly edit the yaml file or run commands by implement steps 3 through 6 as above.

You can also update the yaml directly.

# Admin Security
# Authentication
basicAuth: true # Clients web user name and password will be authenticated when set true
ldapUrl: ldap:’ldap://cisnet.mylearning.org:389/OU=_People,DC=corp,DC=tec,DC=com?emSaleDevOps’ # ldap search url
ldapBindDn: ‘CN=AFRITECDEV,OU=Service Accounts,OU=_Special Accounts,DC=corp,DC=tec,DC=com’ # Resource alias
ldapBindPassword: ‘hU@t9^g4’ # Resource alias
# Authorization
adminSecurity: ‘active’ # Used to enable Authorization. Clients web user role will be authorized when set active
authMode: ‘mq’ # Set admin authorization mode. Choose 1 of : file or mq

If you do not want to provide the binding password in clear text, you must run the mqsisetdbparms command as below then use that DSN instead.

mqsisetdbparms ACE11NODE -n ldap::adminAuthentication -u “CN=AFRITECDEV,OU=Service Accounts,OU=_Special Accounts,DC=corp,DC=tec,DC=com” -p “hU@t9^g4”

Attention: If there is a special char in the password, it needs to be in quotes; single quotes or double quotes depend on your operating system.

Then if editing the yaml file directly, it should be similar to the below

# Admin Security
# Authentication
basicAuth: true # Clients web user name and password will be authenticated when set true
ldapUrl: ldap:’ldap://cisnet.mylearning.org:389/OU=_People,DC=corp,DC=tec,DC=com?emSaleDevOps’ # ldap search url
ldapBindDn: ldap::adminAuthentication # Resource alias
ldapBindPassword: ldap::adminAuthentication # Resource alias
# Authorization
adminSecurity: ‘active’ # Used to enable Authorization. Clients web user role will be authorized when set active
authMode: ‘mq’ # Set admin authorization mode. Choose 1 of : file or mq

1. (Optional) Creating the Integration Node

mqsicreatebroker ACE11NODE -q YOURQUEUEMANAGER

2. (OPTIONAL) Specify the Port Number to Be Used

mqsichangeproperties ACE11NODE -b RestAdminListener -o server -n port -v 4253

3. Enabling admin security for the RestAdminListener

mqsichangeproperties ACE11NODE -b RestAdminListener -o server -n authMode -v mq
mqsichangeproperties ACE11NODE -b RestAdminListener -o server -n adminSecurity -v active
mqsichangeproperties ACE11NODE -b RestAdminListener -o server -n basicAuth -v true

mqsireportproperties ACE11NODE -b RestAdminListener -o server -r

RestAdminListener
adminSecurity=’active’
authMode=’mq’
basicAuth=’TRUE’
caPath=”
host=”
ldapBindDn=’ldap::adminAuthentication’
ldapBindPassword=’ldap::adminAuthentication’
ldapUrl=’ldap://localhost:389/dc=afritec,dc=tg?cn’
port=’4253′
requireClientCert=’FALSE’
sslCertificate=”
sslPassword=”

BIP8071I: Successful command completion.

If you set the ldapUrl= ldapUrl=’ldap://localhost:389/dc=afritec,dc=tg?uid’, any dn (Distinguish Name) that starts with cn will failed authentication. Only those that start with uid will successfully authenticate.

Therefore, I recommend for best practices that you instruct your LDAP admin to standardize the dn for all users on the ldap server. All dns should start with cn or uid, not mismatch.

4. Creating Web User Accounts

Now we will create the web admin users accounts. You can create as many users as you wish. If you do so, you don’t need to create a system user for each one of them. They all will inherent the same system user privileges using -r flag. Here, I only create one user for each group. Also keep in mind that IIB knowledge center repository does not have a documentation on how to set up LDAP with queue-based authorization. If you need assistance doing that, please, contact IBM services for further assistance.

Also, please, read the mqsiwebuseradmin article for more details on the flags that you can use with mqsiwebuseradmin command.

Create a user that inherits the system iibadm user privileges created earlier

mqsiwebuseradmin ACE11NODE -c -u myAceAdmin -x -r iibadm

Create a user that inherits the system iibdev user privileges created earlier

mqsiwebuseradmin ACE11NODE -c -u ‘My Dev’ -x -r iibdev

Create a user that inherits the system iibusers user privileges created earlier

mqsiwebuseradmin ACE11NODE -c -u aceStdUser -x -r iibusers

Run the Following Commands to List All Web Users Accounts Created

mqsiwebuseradmin ACE11NODE -l

BIP2837I: Web user ‘myAdmin’ is defined as having a role of ‘iibadm’. This user will be authenticated against a local password.
BIP2837I: Web user ‘myDev’ is defined as having a role of ‘iibdev’. This user will be authenticated against a local password.
BIP2837I: Web user ‘stdUser’ is defined as having a role of ‘iibusers’. This user will be authenticated against a local password.
BIP8071I: Successful command completion.

Stop and Restart the Broker

mqsistop ACE11NODE
mqsistart ACE11NODE

Note: If you experience any issue, remember to go back and make sure you have followed all the steps and have not skipped any. In addition, make sure that you have not forgotten to refresh MQ securities after configuring the security permissions.

When creating a webui user using queue-based authorization, remember that the -r must be followed by the system level user you have created at the beginning of this document, NOT the system level group that you have used in the setmqaut command. For instance, -r iibadm, -r iibdev, -r iibusers are all system users NOT groups. If you use a group instead of user, you will see the below error message.

Error

BIP2869E: The role ‘insert1’ is not authorized to perform the requested operation ‘insert2’ against the object ‘insert3’.
A user initiated a request to complete an action on an object. The request was rejected because the user’s role does not have the required authorization.
Set up authorizations for this object to grant the required authority to the role ‘insert1’.

Error like the one above is always related to queue permissions, so make sure you set your queue permissions properly and to the appropriate groups.

Another reason for this message to be displayed could be that you did not create the system queues. In such case creating the system queue and restarting the queue manager should fix this issue.