| Author |
Message
|
| St!n0 |
 Posted: Mon Jun 24, 2019 5:35 am Post subject: unable to delete/revoke Authority records |
 |
|
Novice
Joined: 02 Jan 2019
Posts: 14
|
Hi,
we recently migrated a windows queue manager from a Win2K12 to a Win2K16 server.
With doing so we ended up with some authrecs with unkown identities, for example:
| Code: |
dis authrec profile(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
1 : dis authrec profile(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
AMQ8864: Display authority record details.
PROFILE(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
ENTITY(S-1-5-21-3583666158-2930633418-4140117601-1001)
ENTTYPE(UNKNOWN) OBJTYPE(QUEUE)
AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)
|
Most likely they are from local users on the old Win2012 server but that doesn't matter, this is a test queue manager so its totally possible that authority was added for local userid's but that is not the issue.
I would like to remove these entries from the DISPLAY AUTHREC output but keep failing to do so.
I have found that setmqaut can accept a windows SID by using the -u flag so I tried this command which, according to setmqaut, completes succesfully
| Code: |
c:\>setmqaut -m QIBESBTA -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -u S-1-5-21-3583666158-2930633418-4140117601-1001 -remove
The setmqaut command completed successfully.
|
But afterwards when using display authrec i can still see all authorisations for this unknown entity:
| Code: |
dis authrec profile(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
1 : dis authrec profile(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
AMQ8864: Display authority record details.
PROFILE(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
ENTITY(S-1-5-21-3583666158-2930633418-4140117601-1001)
ENTTYPE(UNKNOWN) OBJTYPE(QUEUE)
AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)
|
What am i doing wrong or what am i missing that these authorities are not removed / revoked? |
|
| Back to top |
|
 |
| hughson |
| Posted: Mon Jun 24, 2019 8:43 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
I don't know if it will help or not, but try:-
| Code: |
| setmqaut -m QIBESBTA -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -u S-1-5-21-3583666158-2930633418-4140117601-1001 -all |
This is a way of removing authorities from a profile, rather than removing the profile altogether which is what -remove does.
Suggest you open a PMR with IBM about the -remove though anyway, as it appears like you are doing the correct thing.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| St!n0 |
| Posted: Tue Jun 25, 2019 4:28 am Post subject: |
|
|
Novice
Joined: 02 Jan 2019
Posts: 14
|
| hughson wrote: |
I don't know if it will help or not, but try:-
| Code: |
| setmqaut -m QIBESBTA -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -u S-1-5-21-3583666158-2930633418-4140117601-1001 -all |
This is a way of removing authorities from a profile, rather than removing the profile altogether which is what -remove does.
Suggest you open a PMR with IBM about the -remove though anyway, as it appears like you are doing the correct thing.
Cheers,
Morag |
Thank you for your answer Morag.
But no success with "-all":
| Code: |
c:\>setmqaut -m QIBESBTA -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -u S-1-5-21-3583666158-2930633418-4140117601-1001 -all
AMQ7097: You gave an authorization specification that is not valid.
|
Also the ibm documentation on their website says this:
| Quote: |
-u SID
The SID for which authorities are to be removed. You can specify more than one SID, but each name must be prefixed by the -u flag.
This option must be used with either +remove or -remove .
This parameter is only valid on IBM MQ for Windows. |
So i need the '-remove' parameter when using '-u'
But i was just thinking out load (might be a stupid idea) but i have a lot, but really a lot of these authrecs with unknown entity and don't want to delete them all 1 by 1 manually. What if i use dmpmqcfg to dump all authrecs and then clear the SYSTEM.AUTH.DATA.QUEUE and afterwards redeploy that dump? All authrecs with unkown entity should fail and won't get added and the ones that are valid will be installed, or is this a totally dumb idea?
But in the mean time i'll try to start a pmr with ibm to check why the setmqaut command completes successfully but the entries are not removed. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 25, 2019 5:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well the usual way to remove these authorities would be
| Code: |
| setmqaut -m QIBESBTA -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -u S-1-5-21-3583666158-2930633418-4140117601-1001 +browse +chg +clr +dlt +dsp +get +inq +put +passall +passid +set +setall +setid +remove |
Hope this helps 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| St!n0 |
| Posted: Wed Jun 26, 2019 5:32 am Post subject: |
|
|
Novice
Joined: 02 Jan 2019
Posts: 14
|
| fjb_saper wrote: |
Well the usual way to remove these authorities would be
| Code: |
| setmqaut -m QIBESBTA -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -u S-1-5-21-3583666158-2930633418-4140117601-1001 +browse +chg +clr +dlt +dsp +get +inq +put +passall +passid +set +setall +setid +remove |
Hope this helps |
Thank you for your answer but no success, it still keeps saying that i gave an invalid authorisation specification:
| Code: |
c:\>setmqaut -m QIBESBTA -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -u S-1-5-21-3583666158-2930633418-4140117601-1001 +browse +chg +clr +dlt +dsp +get +inq +put +passall +passid +set +setall +setid +remove
AMQ7097: You gave an authorization specification that is not valid.
|
Even tried replacing every plus sign with a minus but didn't help :/ |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 26, 2019 5:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That's because the userid or sid that you are trying to remove no longer exists in the system. I fear that the only way of getting rid of it is to delete and recreate the queue manager. When you do that don't specify -u with a sid and the sid will get rejected.
Also be careful when dealing with an MI Queue manager. If your local mqm group contains even a single user that is not a domain user, the authorization will show up as a SID on the other side... Same if you have any local users authorized...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Jun 26, 2019 4:27 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| That's because the userid or sid that you are trying to remove no longer exists in the system. I fear that the only way of getting rid of it is to delete and recreate the queue manager. When you do that don't specify -u with a sid and the sid will get rejected. |
Please be careful with this advice. The whole point of the -u flag is to remove SIDs from QMgr config when they no longer exist in the O/S. What the OP is doing is quite correct. It should work.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| St!n0 |
| Posted: Thu Jun 27, 2019 4:41 am Post subject: |
|
|
Novice
Joined: 02 Jan 2019
Posts: 14
|
I submitted a PMR with IBM as Morag suggested and they quickly replied to me that this is a known issue in the version of mq that I am using (v9.0.0.0).
To resolve the issue I should install fixpack 7 and upgrade my MQ version to 9.0.0.7.
Here is the apar for this issue: https://www-01.ibm.com/support/docview.wss?uid=swg1IT28190
I will see if i can get permission to implement this fixpack and check if this actually solves the issue, afterwards i'll provide my feedback here. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 27, 2019 4:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
| fjb_saper wrote: |
| That's because the userid or sid that you are trying to remove no longer exists in the system. I fear that the only way of getting rid of it is to delete and recreate the queue manager. When you do that don't specify -u with a sid and the sid will get rejected. |
Please be careful with this advice. The whole point of the -u flag is to remove SIDs from QMgr config when they no longer exist in the O/S. What the OP is doing is quite correct. It should work. |
I stand corrected. apparently the feature snuck in at 8.0.
Although I never tried it. Before you had to rebuild the qmgr...
Can't imagine why it is not working unless some local users /vs domain users or local groups vs domain groups are authorized on an MI Qmgr...
Anytime you'd switch the other side's local users or groups would appear as SID-...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 27, 2019 7:48 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| apparently the feature snuck in at 8.0. |
Don't you just hate it when they sneak things in on you?
| fjb_saper wrote: |
| Can't imagine why it is not working ... |
At the same instance as you were typing this, the OP has found that there is an APAR for the very same.
| St!n0 wrote: |
| I submitted a PMR with IBM as Morag suggested and they quickly replied to me that this is a known issue in the version of mq that I am using (v9.0.0.0). |
Glad to hear there is an explanation - good luck with the testing of the fixpack - look forward to hearing if it resolved your issue.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| St!n0 |
| Posted: Thu Jul 04, 2019 6:31 am Post subject: |
|
|
Novice
Joined: 02 Jan 2019
Posts: 14
|
Bad news, i did not get the permission to deploy the fixpack from my teamlead.
I did not get the time/budget to create a package for this fixpack because the benefit does not outweigh the cost of creating a software deploy package (yes we must create packages for every piece of software because we are simply not allowed to do manual installs, i work at a bank and they have very strict requirements, we also have a lot of work/not enough time and tight budgets so those are the main reasons why)
It also seems that we have some re-invests coming up and we will be installing 9.1 anyway for those re-invests so that's why they decided not to deploy the fixpack for now.
So sorry if you were expecting an answer on the issue but I assume that as it is a know issue it would surely have been fixed with deploying that fixpack. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jul 04, 2019 8:52 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| St!n0 wrote: |
| So sorry if you were expecting an answer on the issue but I assume that as it is a know issue it would surely have been fixed with deploying that fixpack. |
All good. We understand how it is. You're right, I'm sure it is fixed with that FixPack - the person who originally discovered the bug and reported it will have told them if it didn't work!. All the best with the V9.1 deployment.
Cheers,
Morag
P.S. <VENDOR_PLUG> if you need any MQ V9.x.x education, see my sig file below</VENDOR_PLUG>
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
