| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Which users are administrators in QManager? |
« View previous topic :: View next topic » |
| Author |
Message
|
| madmalkav |
 Posted: Thu Jun 20, 2019 12:04 am Post subject: Which users are administrators in QManager? |
 |
|
Novice
Joined: 03 Sep 2018
Posts: 17
|
I have several version 8 QManagers running in different Unix systems. I'm taking a look at the different security options at the moment, trying to understand better how everything works and looking for possible improvements on my setup.
I use the IDPW OS auth type at the moment. I'm trying to figure out the "Check client connections" option. If I set it to "Required for Administrators", it doesn't ask for password even to users that have priviledges to do anything on the QManager. We give the admins permissions with a MQSC file to a UNIX group.
In the past, I did some experiments with IDPW LDAP and if I set the same permissions for a LDAP group, the users members of that group were indeed asked for password when "Required for Administrator" was active.
So, I'm really curious about the mechanisms IBM MQ uses to determine if an user is considered an administrator or not. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Jun 20, 2019 4:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
How did you test this?
When were you prompted for password?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| madmalkav |
| Posted: Thu Jun 20, 2019 4:21 am Post subject: |
|
|
Novice
Joined: 03 Sep 2018
Posts: 17
|
I set permissions with a script similar to what IBM says in this link, just we do it with mqsc commandds instead of using setmqaut :
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q013750_.htm
I test by connecting with MQ Explorer . As I said, in a test I did some time ago, with those same permissions assigned to a LDAP group I'm member of on a QManager using IDW LDAP I was indeed prompted for my password while users with less permissions weren't. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 20, 2019 5:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I want to see exactly the permissions you set, not permissions that are similar.
| madmalkav wrote: |
| I test by connecting with MQ Explorer . |
So, MQExplorer fails to connect? What errors are logged in the AMQERR01.LOG on the qmgr?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| madmalkav |
| Posted: Thu Jun 20, 2019 5:46 am Post subject: |
|
|
Novice
Joined: 03 Sep 2018
Posts: 17
|
Perhaps I didn't explain my question well, I was asking about how IBM MQ determines an user is a admin in general terms, not for a debug of my particular problem.
But, as you offered to look deeper to my particular case, let's take advantage of that 
I have got some new info since your last message: some qmanagers have permissions for the administrators given by group, I assume this QManagers where installed on v7 and later migrated to v8, and other qmanagers that have permissions for administratros given per user, I assume this ones where v8 clean installs.
MQ Explorer connects OK without needing a password with "Required for Administrators" activated. This happens both in qmanagers that have permissions per user and the qmanagers that have permissions per group:
SET AUTHREC PROFILE('self') PRINCIPAL('UserID') OBJTYPE(QMGR) AUTHADD(ALTUSR,CHG,CONNECT,DLT,DSP,INQ,SET,SETALL,SETID,CTRL,SYSTEM)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(CLNTCONN) AUTHADD(CHG,DLT,DSP)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(CLNTCONN) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(QUEUE) AUTHADD(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(QUEUE) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(NAMELIST) AUTHADD(CHG,DLT,DSP,INQ)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(NAMELIST) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(PROCESS) AUTHADD(CHG,DLT,DSP,INQ,SET)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(PROCESS) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(CHANNEL) AUTHADD(CHG,DLT,DSP,CTRL,CTRLX)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(CHANNEL) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(AUTHINFO) AUTHADD(CHG,DLT,DSP,INQ)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(AUTHINFO) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(TOPIC) AUTHADD(CHG,CLR,DLT,DSP,PASSALL,PASSID,SETALL,SETID,CTRL,PUB,SUB,RESUME)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(TOPIC) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(COMMINFO) AUTHADD(CHG,DLT,DSP)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(COMMINFO) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(LISTENER) AUTHADD(CHG,DLT,DSP,CTRL)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(LISTENER) AUTHADD(CRT)
SET AUTHREC PROFILE('**') PRINCIPAL('UserID') OBJTYPE(SERVICE) AUTHADD(CHG,DLT,DSP,CTRL)
SET AUTHREC PROFILE('@class') PRINCIPAL('UserID') OBJTYPE(SERVICE) AUTHADD(CRT)
As I previously said, the only case where I got it to work -in some tests I did months ago- was using IDW LDAP and giving permissions per group . It didn't work giving permissions per users, I don't know why. I can try to reproduce that but it will take a little to find some time to do it. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jun 20, 2019 6:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
IBM MQ does NOT "...determines an user is a admin...", ever! You can give authority to a user to carry out administrative tasks, or map a user to 'mqm', but YOU then have to ensure that the entity connecting is from an authorised entry point, e.g. specific IP Address, SSLPEER value, etc. IBM MQ will then use the appropriate way of querying the LDAP or OS for that user (unless mapped).
Is your MQ Explorer caching the password, i.e. you have saved the password in the MQ Explorer?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| madmalkav |
| Posted: Thu Jun 20, 2019 6:46 am Post subject: |
|
|
Novice
Joined: 03 Sep 2018
Posts: 17
|
No caching at all.
If MQ doesn't check if an user is an admin or not in any way, what sense makes the "Required for Administrators" Check Client Connections options? |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jun 20, 2019 7:16 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| madmalkav wrote: |
| ...If MQ doesn't check if an user is an admin or not in any way, what sense makes the "Required for Administrators" Check Client Connections options? |
I suspect that all that 'switch' does is prompt the queue manager to query the appropriate mechanism for a password match to the presented entity.
I will temper my previous answer in regard to whether IBM MQ determines whether a user is an Admin or not - it does hold an internal list of 'default' privileged users, e.g. mqm, MUSR_MQADMIN.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| madmalkav |
| Posted: Thu Jun 20, 2019 7:22 am Post subject: |
|
|
Novice
Joined: 03 Sep 2018
Posts: 17
|
I was thinking about the possibility that this config option will only affect the default users you mentioned plus members of the mqm group too. But that doesn't match which what I observed when I tested IDW LDAP behavior.
Definitively I will setup a test QManager and try this combinations ASAP. |
|
| Back to top |
|
|
| markt |
| Posted: Thu Jun 20, 2019 8:32 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
The "who is considered an administrator" depends on platform and authorisation model. It's really a shorthand for "who automatically has full authority" for the qmgr.
Any other person/group CAN be granted full authority, but as that has to be done explicitly, it's not considered quite the same thing.
On Unix platforms, with the OS authorisation model, anyone in the "mqm" group is considered an automatic admnistrator. On Windows, it's anyone in the mqm group or a couple of Windows administration groups. Similar approaches for other platforms too - on z/OS it's the id associated with the qmgr task.
With the LDAP authorisation model, the only automatic administrator is the user who started the qmgr. The mqm group is not considered special - indeed there is not really any such thing in LDAP terms as users/groups are represented by Distinguished Names. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 20, 2019 4:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| madmalkav |
| Posted: Thu Jun 20, 2019 11:42 pm Post subject: |
|
|
Novice
Joined: 03 Sep 2018
Posts: 17
|
| Thanks for the link Peter. As I said, my problem with that is, it doesn't match with what I observed when using IDW LDAP. I will try to setup a test QManager with IDW LDAP and verify again just to be sure I didn't mess my previous tests. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
