Hi Francois,
At first, thanks for your time & response.
FYI, trying to execute dltmqm command failed with misleading AMQ7064:Log path not valid or inaccessible, given that log path was there on the exact the same path defined at qm.ini) and directory/file permissions were also valid for the UID (but there were no log files underneath..) Also, even after trying to delete the (Windows) QM paths and registry entries related to the specific QM (i.e.Computer\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphere MQ\Installation), nothing good happened..
The UID (and its associated SID) was member of mqm group and it is the same valid UID, still used to administer the other QMs hosted on the same Windows MQ Server.
In general, any mqm cmd (i.e. endmqm, strmqm, dltmqm, ...) with the specific UID (SID) against the specific QM, was unsuccessful, whereas its was working perfectly on the administration of the other QMs hosted on the same Windows MQ host, made me treat that QM as corrupted.
So, relying on corrupted QM's circular logging mode and its logging definitions in qm.ini (no of primary/secondary logs, log file size, etc) i was able to place (not replace something not existing) the recovery (active) logs and the managed to start (after transaction log replay) the QM using the same UID/SID and then endmqm, dltmqm successfully.
So, at last, yes this log (re) placement was the only way worked for me!!
Cheers, Nick.
------------------------------
Nick Dakoronias
------------------------------
Original Message:
Sent: Mon September 30, 2024 01:44 AM
From: Francois Brandelik
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hi Nick,
If you just wanted to get rid of the qmgr, you could have preserved the ini file (keep the parameters, deleted the qmgr and log folders and run rmvmqinfo to remove the entry from mqs.ini (and registry? for windows).
What you did was a substitution of the logs, which would have permittet a restart with all the persistent messages saved. Once the restart was done running a checkpoint with rcdmqimg is in order if you are running with linear logs.
Hope it helps
------------------------------
Francois Brandelik
Original Message:
Sent: Fri September 27, 2024 04:24 AM
From: NICK DAKORONIAS
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hi Pål Magne,
Apologies for my delayed response.
Yes, i actually managed to solve the problem by recreating the QM in another machine using the same definitions included in qm.ini . For instance the same QM name, the same no of primary and secondary log files, the same log fie size, .. After creating successfully the QM (via crtmqm command not via MQ Explorer), i have started the QM and then active (recovery) logs have been created. Then I have copied all active (recovery) logs to the original machine where the original QM was hosted. I was then able to start QM successfully. At last, after stopping the original QM, I was able to delete it and recreated it successfully, since the initial symptom (with SID mismatch) was caused by internal QM corruption (recorded at FDC files as internal errors on MQ processes). So the whole scope of this workaround was to try to delete the corrupted QM and recreate it from scratch. Then what is missing was to import the QM configuration from backup or exported dump file.
Hoping the above to assist you.
Cheers, Nick
------------------------------
Nick Dakoronias
Original Message:
Sent: Mon January 15, 2024 08:59 AM
From: Pål Magne Anthonsen
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hi Nick.
Did you ever solve this problem?
------------------------------
Pål Magne Anthonsen
Original Message:
Sent: Tue February 02, 2021 06:49 AM
From: NICK DAKORONIAS
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hi Francois,
The qm.ini had the default settings (except max channels value which has been changed), so OAM was not checking global group membership.
I have enabled the global group check via qm.ini [Security Stanza]: GroupModel=GlobalGroups, and restart QM to take effect, but unfortunately
the problem still remains.
Rgds, Nick.
------------------------------
NICK DAKORONIAS
Original Message:
Sent: Mon February 01, 2021 08:59 AM
From: Francois Brandelik
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hi Nick,
As you are on windows, please check your qm.ini. Do you have the GroupModel entry in the Security stanza?
------------------------------
Francois Brandelik
Original Message:
Sent: Fri January 29, 2021 10:38 AM
From: NICK DAKORONIAS
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hi Neil,
At first thanks for your tips and response.
After cross-checking with Bank's AD team, there wasn't any change (move, update) related to my account (e63254) at Central domain and it is not corrupted. FYI,
I am capable of accessing other Queue Managers in the CENTRAL domain from the same MQ client, as well as, a test Queue Manager on the same machine, which makes me suspicious about specific Queue Manager's corruption.
Btw, I have submitted a ticket to Bank's AD support team for further investigation and confirmation about e63254@Central account/SID integrity.
Then I have executed the following commands (cmd prompt) on QM: MQNBGQA to verify my SID:
D:\>whoami
central\e63254
D:\>whoami /user
USER INFORMATION
----------------
User Name SID
============== =============================================
central\e63254 S-1-5-21-816530017-2240465312-872180193-23427
Also run setmqaut -u SID to remove "problematic" SID from ΟΑΜ entries:
D:\>setmqaut -m MQNBGQA -t qmgr -u S-1-5-21-816530017-2240465312-872180193-23427 -remove
Then restart the QM and add the e63254@central user again (since it has been removed), but the problem still remains.
I am afraid that I have to delete & restore (via runmqsc) QM: MQNBGQA using the "last known good" mqsc backup (taken via dmpmqcfg).
If there is any other option you can think of, pls let me know.
Cheers Nick.
------------------------------
NICK DAKORONIAS
Original Message:
Sent: Thu January 28, 2021 01:26 AM
From: Neil Casey
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hi Nick,
I would recommend checking with your AD people on whether they might have performed a reorganization which has moved these ids around into different org units and perhaps led to a change of their SIDs.
When an OAM record is created on Windows, the SID of the authorised user is recorded in MQ at that time. If the SID subsequently changes, the permission grants have to be done again (or you could turn of SID checking if you don't care about that level of validation). The other thing that can happen is that if the domain isn't provided when the permission is granted, MQ will basically assume one, and if that's wrong, you can get unexpected rejections when you connect from the intended account, but that doesn't really look like the case here.
The account name with the truncated domain value looks like it has been taken from the wrong field in the channel. There are a couple of different fields in the channel information during connection that can contain userid information. One of them is only 12 characters (commonly used by unix environments) while the other permits longer values to be used. It looks like the message has taken the value from the short user field which has caused it to be truncated at 12 characters. I don't understand why this would be happening though.
Regards,
------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-20
+61 (0) 414 615 334
Original Message:
Sent: Wed January 27, 2021 10:53 AM
From: NICK DAKORONIAS
Subject: AMQ8074W: Authorization failed as the SID 'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
Hello MQ community Users,
Any advise on the following will be much appreciated:
When I am trying to connect to remote Queue Manager (QM:MQNBGQA) at AD Domain Central from Windows client using IBM MQ Explorer tool, with Domain userID e63254@CENTRAL or userID e63254@BANK (Central, Bank are trusted domains), the following error msg prompts on MQ Explorer:
---
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Severity: 10 (Warning)
Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.
---
Looking into the target MQ Server error log, the following exceptions are listed:
---
27/1/2021 17:17:14 - Process(6876.28) User(MQNBGQA) Program(amqzlaa0.exe)
Host(V000010255) Installation(MQNBGQA)
VRMF(9.1.5.0) QMgr(MQNBGQA)
Time(2021-01-27T15:17:14.486Z)
RemoteHost(10.1.100.155)
CommentInsert1(S-1-5-21-816530017-2240465312-872180193-23427)
CommentInsert2(e63254@centr)
AMQ8074W: Authorization failed as the SID
'S-1-5-21-816530017-2240465312-872180193-23427' does not match the entity 'e63254@centr'.
EXPLANATION:
The Object Authority Manager received inconsistent data - the supplied SID does not match that of the supplied entity information.
ACTION:
Ensure that the application is supplying valid entity and SID information.
------
27/1/2021 17:16:42 - Process(6876.27) User(MQNBGQA) Program(amqzlaa0.exe)
Host(V000010255) Installation(MQNBGQA)
VRMF(9.1.5.0) QMgr(MQNBGQA)
Time(2021-01-27T15:16:42.103Z)
RemoteHost(10.1.100.155)
CommentInsert1(S-1-5-21-783752929-4063248335-57074302-1354159)
CommentInsert2(e63254@bank)
AMQ8074W: Authorization failed as the SID
'S-1-5-21-783752929-4063248335-57074302-1354159' does not match the entity 'e63254@bank'.
EXPLANATION:
The Object Authority Manager received inconsistent data - the supplied SID does not match that of the supplied entity information.
ACTION:
Ensure that the application is supplying valid entity and SID information.
----
Both principals (Domain UIDs) are included in QM access list with proper authroizations and used to access QM objects without any issues before (previous days).
FYI, there are also channel rules enabled for the principals.
(i.e. SYSTEM.ADMIN.SVRCONN -> ADDRESS MAP FOR E63254@CENTRAL
SYSTEM.AUTO.SVRCONN -> ADDRESS MAP FOR E63254@CENTRAL)
Btw, where this SID entry "e63254@centr" comes from?
It seems to me that there might be an SID corruption in OAM..
If this is the case, how the SID can be fixed and be recovered?
What might be the problem? Any workarounds?
Thanks in advance for your time and support,
Cheers Nick.
------------------------------
NICK DAKORONIAS
------------------------------