ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » Users with or without passwords

Post new topic  Reply to topic Goto page 1, 2  Next
 Users with or without passwords « View previous topic :: View next topic » 
Author Message
NickSz
PostPosted: Tue Oct 31, 2017 7:02 am    Post subject: Users with or without passwords Reply with quote

Novice

Joined: 26 Jul 2008
Posts: 12
Location: Zurich

Hello everbody,

i am a bit confused by all the posibility of restricting the right to connect and to the objects of MQ 8.
We are having MQ 8 running on an Appliance and need to have users with password but also need technical users without password due to older software connecting

What is the best approach to reach out to the Channels and Objects of the qms?

I have put up the following config:
Add user and groups
mqa(mqcli)# groupcreate -g gxyz
mqa(mqcli)# groupcreate -g gzyx
mqa(mqcli)# usercreate -u abc -d abc -g gxyz
mqa(mqcli)# usercreate -u cba -d cba -g gzyx

Non privileged user ID
DEFINE CHANNEL(CLIENT.SVRCONN) CHLTYPE(SVRCONN) SSLCAUTH(OPTIONAL) HBINT(30) REPLACE

SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('BackStop rule')
SET CHLAUTH('CLIENT.SVRCONN') TYPE (USERMAP) CLNTUSER(abc) USERSRC(MAP) MCAUSER(abc)
SET CHLAUTH('CLIENT.SVRCONN') TYPE (USERMAP) CLNTUSER(cba) USERSRC(MAP) MCAUSER(cba)

SET AUTHREC OBJTYPE(QMGR) GROUP('gxyz') AUTHADD(ALL)
SET AUTHREC OBJTYPE(QMGR) GROUP('gzyx') AUTHADD(ALLMQI)

SET AUTHREC OBJTYPE(QUEUE) PROFILE('**') GROUP('gxyz') AUTHADD(ALL)
SET AUTHREC OBJTYPE(QUEUE) PROFILE('**') GROUP('gxyz') AUTHADD(CRT)
SET AUTHREC OBJTYPE(QUEUE) PROFILE('**') GROUP('gzyx') AUTHADD(ALLMQI)

SET AUTHREC OBJTYPE(CHANNEL) PROFILE('**') GROUP('gxyz') AUTHADD(ALL)
SET AUTHREC OBJTYPE(CHANNEL) PROFILE('**') GROUP('gxyz') AUTHADD(CRT)
SET AUTHREC OBJTYPE(CHANNEL) PROFILE('**') GROUP('gzyx') AUTHADD(ALLMQI)
...

and so on.

Am i correct or am i missing something.

Best regards
Nicolaie
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Tue Oct 31, 2017 7:46 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Look at the provided mqccred exit that comes with IBM MQ V8.0, for your 'older software' - it may provide what you need.
_________________
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
View user's profile Send private message
zpat
PostPosted: Tue Oct 31, 2017 7:46 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

You first need to distinguish between application users/groups and administrative users/groups.

Don't grant application groups administrative access, don't allow them to create new MQ objects etc.

The only access an application group should need is ALLMQI, plus display and inquire and maybe clear where appropriate.

If you grant them +all to **, then you have no security. Always use object naming conventions to restrict access to relevant objects. (e.g. use PREFIX.**)
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
zpat
PostPosted: Tue Oct 31, 2017 8:14 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

exerk wrote:
Look at the provided mqccred exit that comes with IBM MQ V8.0, for your 'older software' - it may provide what you need.


Can't use exits on the MQ appliance.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Oct 31, 2017 9:36 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

zpat wrote:
exerk wrote:
Look at the provided mqccred exit that comes with IBM MQ V8.0, for your 'older software' - it may provide what you need.


Can't use exits on the MQ appliance.

No, but you can for connecting client applications...
_________________
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
View user's profile Send private message
NickSz
PostPosted: Tue Oct 31, 2017 9:37 am    Post subject: Re: Users with or without passwords Reply with quote

Novice

Joined: 26 Jul 2008
Posts: 12
Location: Zurich

NickSz wrote:
...
We are having MQ 8 running on an Appliance and need to have users with password but also need technical users without password due to older software connecting


Yeap, zpat, this is one point. On appliances there are no exits.

I need to have admin users, the master admins will be using certs.
Then i need developer who are quite powerfull but should only use username+password.
And there the app users which should remain working without password.
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Tue Oct 31, 2017 9:51 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Again, Client side security exit to insert user ID and password (mqccred)
_________________
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
View user's profile Send private message
zpat
PostPosted: Tue Oct 31, 2017 11:55 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

Don't permit update access to system queues. Only mqm should be able to do that and mqm doesn't need permissions.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
NickSz
PostPosted: Wed Nov 01, 2017 3:19 am    Post subject: Reply with quote

Novice

Joined: 26 Jul 2008
Posts: 12
Location: Zurich

Exerk, unfortunatelly this can not be used because we are using MQ Appliances. There are no exits on an appliances allowed.
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Wed Nov 01, 2017 3:48 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

NickSz wrote:
Exerk, unfortunatelly this can not be used because we are using MQ Appliances. There are no exits on an appliances allowed.


Ex-erk is correct, this exit is client side. It does not need to run on the appliance.

https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q114370_.htm
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
NickSz
PostPosted: Thu Nov 02, 2017 1:32 am    Post subject: Reply with quote

Novice

Joined: 26 Jul 2008
Posts: 12
Location: Zurich

Well, it needs at least a channel where scyexit is set:
See Using mccred at the end of this document: https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q114370_.htm
And see also the the restrictions on the Appliances where it is written that exit are rejected:
https://www.ibm.com/support/knowledgecenter/en/SS5K6E_1.0.0/com.ibm.mqa.doc/planning/pl00003_.htm
Cheers
Nicolaie
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Thu Nov 02, 2017 1:41 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

Quote:
mqccred is a security exit that runs on the same machine as your client application


It's really quite simple. The exit runs on the host where MQ client runs.

MQ client does not run on the appliance, it connects to the appliance. No exit is needed on the appliance.

You need to define the exit on the CLNTCONN definition - even if this definition is made on the appliance QM, it is not used on the QM - it is downloaded as a CCDT to the client machine.

If you don't follow - please read up on MQ in general.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
exerk
PostPosted: Thu Nov 02, 2017 2:13 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

zpat wrote:
Ex-erk is correct...

Put it in your diary, it doesn't happen often!
_________________
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
View user's profile Send private message
NickSz
PostPosted: Thu Nov 02, 2017 5:28 am    Post subject: Reply with quote

Novice

Joined: 26 Jul 2008
Posts: 12
Location: Zurich

Zpat, thank you.
I did not meant that you are wrong. I did not trust that the appliance not eventually blocking the creation of the table.
But after testing it here i saw that it is contained in the CCDT so it should work, as you said.
Now i have to find out if the developers here will adapt...
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Fri Nov 03, 2017 12:19 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

You don't have to create a CCDT on the Appliance QM in question. You can create it on any queue manager, or even create it without a QM.

Quote:
Client platforms at IBM MQ Version 8.0

You can create a CCDT on the client machine directly by using the runmqsc command with the -n parameter. The CCDT will be created in the location indicated by MQCHLLIB and with the filename indicated by MQCHLTAB which is AMQCLCHL.TAB by default.

Note, that if you specify the -n parameter, you must not specify any other parameter.

Each entry of a CCDT represents a client connection to a specific queue manager. A new entry is added when you define a client-connection channel using the DEFINE CHANNEL command, and the entry is updated when you alter the client-connection channels by using the ALTER CHANNEL command.

_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » IBM MQ Security » Users with or without passwords
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.