I'm trying to create IBM MQ subs via command line on a linux installation and I get:
AMQ8135: Not authorized.
My logs show:
AMQ8009: Entity '' has insufficient authority to access topic string 'WW/XX/YY'.
EXPLANATION: The specified entity is not authorized to access the required topic.
The following permissions were requested: altusr/ctrl
It looks like the command line isn't getting the entity value from where ever it was trying to find, not sure where that is!
But the confusing part is that creating of other mq objects(queues/topics) work just fine on command line and even the create subs works from MO71 and failing on cmd.
File permission look good and env variable also looked fine to me unless!
cmd- DEFINE SUB('ABC.1') TOPICSTR('xx/yy/zz') DEST('lq.abc')
Anyone one ran into such/fixed such issue?
In order to successfully run a DEFINE SUB command, the user ID that you are running it with requires the following authorities (you can work these out from looking at the whole of the AMQ8009 message in your AMQERR01.LOG, specifically the EXPLANATION: section).
ctrl on the nearest administrative topic object
put on the named destination queue
Also read
IBM Knowledge Center: Authorizations for commands
IBM Knowledge Center: MQSUB - Usage Notes (for authority for output - put - needed for subscription)
As an example, let's assume:-
TOPIC(XYZ) is defined with TOPICSTR('xx/yy/zz')
QUEUE(LQ.ABC) exists
The non-privileged user ID running the command is a member of the group mqgemadm
Then you need to set the following two privileges (over and above whatever you might have already set for this group in order to be able to issue commands in general):-
SET AUTHREC PROFILE(XYZ) OBJTYPE(TOPIC) GROUP('mqgemadm') AUTHADD(ctrl)
SET AUTHREC PROFILE(LQ.ABC) OBJTYPE(QUEUE) GROUP('mqgemadm') AUTHADD(put)
If you believe that your user id already has these permissions and the reason it is failing is because the user id is not making it to the command, you could try adding the SUBUSER field to the command.
DEFINE SUB('ABC.1') TOPICSTR('xx/yy/zz') DEST(LQ.ABC) SUBUSER('mqgemusr')
If this works, but without SUBUSER still fails, suggest you report the defect to IBM via a PMR/support case.
Related
I have the following topics which are created on IBM MQ docker version:
dev/test/sys1 dev/test/sys2
I am trying to create subscriber from XMS .NET APIs using the following code:
destination = sessionWMQ.CreateTopic("dev/test/#");
The following exception appears, it is related to permissions based "Reason: 2035", but I am not able to figure out what is the permission I have to grant and from where
XMSException caught: IBM.XMS.IllegalStateException: Failed to
subscribe to topic dev/# using MQSUB. There may have been a problem
creating the subscription due to it being used by another message
consumer. Make sure any message consumers using this subscription are
closed before trying to create a new subscription under the same name.
Please see the linked exception for more information.
If you receive an error 2035 (MQRC_NOT_AUTHORIZED) there will be a corresponding message in the queue manager error log AMQERR01.LOG. It will say something like this:-
AMQ8009: Entity 'mqgusr1' has insufficient authority to access topic string
'dev/test/#'.
EXPLANATION:
The specified entity is not authorized to access the required topic. The
following requested permissions are unauthorized: sub
ACTION:
Ensure that the correct level of authority has been set for this entity against
appropriate topic objects, or ensure that the entity is a member of a privileged
group.
Specifically this error message will tell you the user id, the object name, and the missing authorization. Using this information, you can almost construct the command you need. You do need one more peice of information and that is the group name that the user is in that you wish to grant the authority on. It is always recommended that you use group names and not user names when granting authorities or you may end up with too many authorities to manage, or perhaps worse, more users than you expected gaining the authority you granted as a result of the primary group of the user being something like 'staff'.
Here's the command, assuming that 'mqgusr1' in my error message, is in the group 'mqgapp' and that group is suitable for being granted authority to subscribe to a topic.
SET AUTHREC PROFILE(SYSTEM.BASE.TOPIC) OBJTYPE(TOPIC) GROUP('mqgapp') AUTHADD(SUB)
It is worth mentioning at this point that adding topic related authorities to the SYSTEM.BASE.TOPIC results in the group in question being able to use any topic available - this object represents the root of the topic tree. If you wish to restrict access to only certain parts of the topic tree (recommended), then you should instead create a topic object for the section of the topic tree you want to use, and then grant authority there instead, thus the following commands:
SET AUTHREC PROFILE(SYSTEM.BASE.TOPIC) OBJTYPE(TOPIC) GROUP('mqgapp') AUTHRMV(SUB)
DEFINE TOPIC(DEV.TEST) TOPICSTR('dev/test')
SET AUTHREC PROFILE(DEV.TEST) OBJTYPE(TOPIC) GROUP('mqgapp') AUTHADD(SUB)
I have a little java program that reads a db2 table via jdbc. This program is invoked via "tso bpxbatch myjavatool".
I wonder if there is the possibility to "pass" the username/password of my TSO user to the JDBC driver?
For example, if I connect to DB2 with a simple REXX script I don't have to specify my username/password again and DB2/RACF checks if my user is allowed to execute the SQLs.
Now my java tool is not running in my TSO address space but under the control of the J9 in the USS address space...
Is there also a way to automatically log in to DB2 with the current TSO user?
I don't know too much about BPXBATCH, but I assume you are still running under your own userid in the USS-address-space.
In your java-code you should be able to get your userid via
String user = System.getProperty("user.name");
As for the password you could try using RACF-Passtickets instead. There is a library IRRRacf.jar in /user/include/java_classes and the corresponding javadoc in IRRRacfDoc.jar in the same directory. the code for generating the Passticket is rather simple:
IRRPassTicket generator = new IRRPassTicket();
String ptkt = generator.generate(user,applid);
then just pass the passticket instead of the password and you should be fine.
Alas, there's several aspects you have to make sure of before using this approach:
Set up RACF to use Passtickets for DB2 - it might already be configured, else you'll have to set up proper profiles in the PTKTDATA-class (See RACF-documentation for more details)
Make sure each user running the code has the proper RACF authorization to use the r_ticketserv callable service (again, see RACF documentation)
Find the correct application-name (applid) for your DB2-system. See the DB2-documentation about using passtickets.
I know that the currently logged on windows user can be detected via WiseScript using:
Get System Information, Retrieve: Windows Logon Name
But purely in WiseScript, is there a way to get the user name executing a running process?
There is an important difference here because you could be logged on as 'Bob', but do a run as on MyDBInterface.exe with 'Sally', and MyDBInterface.exe must ran with Bob's rights.
Note: I know that I can do this with an external C# application that talks back to wise, but rather do it in Wise if there is a built in method.
You could call the command line tool "tasklist" to get the username of a running process, and output it to a text file. Then use WiseScript to parse the file to get the exact username.
When I tried to start an FTE agent in the command prompt , it displays the error message as "An internal error has occurred. Unable to complete the command because the agent directory does not exist".
What would be the reason for this? It was working fine until yesterday. And is there any way to start an agent in MQ FTE itself? I use fteStartAgent in command prompt each time to start an agent.
Kindly advise me on this....
There are a few possible reasons for this. It is possible that the default properties were changed and now point to an invalid location. This usually happens when the different components are installed and you select to provide the connection details again rather than to reuse the existing configuration.
Another possibility is that the default properties have been changed to point to a different Coordination QMgr. Sometimes people want to run Prod and Dev agents on the same host and set up connectivity to more than one Coordination QMgr. The result is that the default properties can point to only one at a time and so some agent directories are found while others are not. The trick to making this work is to use the -P option to select the proper Coordination QMgr.
I realise there are some similar questions on here already but I couldn't see one that matched my problem so I'm afraid I had to ask a new question.
I have a webservice running on a server, which is throwing a ORA-12154: TNS:could not resolve the connect identifier specified" error. However when I log onto the said server i am able to tnsping the entry successfully, and connect to it via sqlplus, but not through the webservice.
If anyone has any suggestions as to things to look for then I would greatly appreciate it.
Cheers
Some other things to look at include:
If you're using a service name instead of SID, are you specifying the entire service name?
If you're using the ORACLE_SID environmental variable, check the case (mydb vs MYDB)
Check for a sqlnet.log file
If you're using a username/password#SID connect string, you may need to quote your password if it contains special characters (like an # symbol).
The webservice can't find tnsnames.ora which usually means that you didn't set up Oracle's environment properly when starting the process. This usually means you didn't source oraenv.sh in the shell script which starts it.
So your interactive login works - what is different between your interactive login and the user that runs your web service?
Are they the same user? If not then you will need to update some of your configs in order to make the Oracle client files available to the webservice.
Details like Operating System, Oracle Version, etc are always a help.