Hier volgt een overzicht van wat dit betekent en hoe u dit kunt oplossen:

Wat MQRC_NOT_AUTHORIZED (of redencode 2035) betekent:

Dit is de meest voorkomende autorisatiefout in MQ. Het geeft aan dat het gebruikers-ID (of de gebruikerscontext waaronder de toepassing wordt uitgevoerd) *niet* over de benodigde machtigingen beschikt om de actie uit te voeren die het probeert uit te voeren op een specifieke MQ-bron. Zie het als een poging om toegang te krijgen tot een bestand op uw computer zonder de vereiste lees-/schrijfrechten.

Veelvoorkomende scenario's en oorzaken:

1. Onjuiste gebruikers-ID-context:

* Uitvoeren als een andere gebruiker: De toepassing wordt mogelijk uitgevoerd onder een ander Windows-gebruikersaccount dan u denkt. Dit kan gebeuren als u serviceaccounts heeft gewijzigd, taken heeft gepland of de toepassing uitvoert vanaf een opdrachtprompt met verhoogde bevoegdheden (bijvoorbeeld 'Uitvoeren als beheerder').

* Onjuiste gebruiker voor COM+-applicaties: Als uw toepassing COM+-services gebruikt, is de identiteit die voor de COM+-toepassing is geconfigureerd van cruciaal belang. Zorg ervoor dat er een account wordt gebruikt met MQ-machtigingen.

* Problemen met WebSphere Application Server (WAS): Als uw applicatie is geïmplementeerd in WebSphere Application Server, zorg er dan voor dat het gebruikers-ID dat is geconfigureerd voor de gegevensbron en dat de beveiligingsroltoewijzingen van de applicatie correct zijn geautoriseerd in MQ.

2. Ontbrekende of onjuiste MQ-objectrechten:

* Toegang tot wachtrij: De gebruiker heeft geen `+GET`, `+PUT`, `+BROWSE` of andere vereiste machtigingen voor de specifieke wachtrij waartoe de toepassing toegang probeert te krijgen. De machtigingen `+CONNECT` en `+INQUIRE` zijn ook vaak nodig.

* Toegang tot wachtrijbeheerder: De gebruiker heeft geen `+CONNECT`-bevoegdheid voor de wachtrijbeheerder zelf. Dit is een fundamentele vereiste.

* Kanaaltoegang: Als de applicatie op afstand verbinding maakt, heeft de gebruiker geen `+CONNECT`-bevoegdheid voor het Server Connection Channel (SVRCONN). Mogelijk heeft het ook machtigingen nodig om het kanaal te gebruiken, zoals `+ALTUSER` of `+SETALL`, afhankelijk van hoe de Channel Authentication Records (CHLAUTH) zijn geconfigureerd.

* Procesdefinitie (PROCESS) Toegang: Als de applicatie triggermonitors gebruikt, heeft de gebruiker '+GET'-autoriteit nodig voor de initiatiewachtrij en de juiste toegang tot de procesdefinitie.

* Toegang tot onderwerp: Voor toepassingen voor publiceren/abonneren heeft de gebruiker de juiste abonnements- en publicatiemachtigingen voor het onderwerp of de onderwerpreeks nodig.

3. CHLAUTH-records (kanaalauthenticatierecords):

* Geblokkeerde kanalen: CHLAUTH-records kunnen bepaalde gebruikers-ID's of IP-adressen expliciet blokkeren voor het gebruik van specifieke kanalen. Als een CHLAUTH-record verhindert dat de gebruiker verbinding maakt, wordt de fout weergegeven als `MQRC_NOT_AUTHORIZED`.

* MCAUSER-kenmerk: Het `MCAUSER` attribuut op het Server Connection Channel (SVRCONN) specificeert de gebruikers-ID die zal worden gebruikt wanneer een client verbinding maakt. Als `MCAUSER` verkeerd is ingesteld of niet goed is geconfigureerd, kan dit tot autorisatieproblemen leiden.

4. Configuratieproblemen met Object Authority Manager (OAM):

* Onjuist OAM-beleid: De OAM is verantwoordelijk voor het handhaven van het beveiligingsbeleid. Onjuist beleid kan onbedoeld de toegang tot MQ-bronnen weigeren.

* Groepslidmaatschap: De gebruiker is mogelijk lid van een Windows-groep, maar aan de groep zijn niet de benodigde MQ-machtigingen verleend.

5. Onjuiste codeerpraktijken:

* Inloggegevens niet correct doorgeven: Als de applicatie is ontworpen om gebruikersgegevens ter autorisatie door te geven aan MQ, zorg er dan voor dat deze gegevens correct worden doorgegeven (bijvoorbeeld door het veld 'UserId' in de MQMD of de structuur 'SecurityParameters' te gebruiken bij het verbinden).

* De standaardgebruikerscontext verkeerd gebruiken: Het vertrouwen op de standaardgebruikerscontext kan problematisch zijn, vooral in architecturen met meerdere lagen. Het expliciet opgeven van de gebruikers-ID is vaak betrouwbaarder.

Stappen voor probleemoplossing:

1. Identificeer de gebruikers-ID:

* Uit applicatielogboeken: Controleer de logboeken van de applicatie op berichten met betrekking tot de MQ-verbinding of autorisatie. Het foutbericht bevat mogelijk de gebruikte gebruikers-ID.

* Uit MQ-foutlogboeken: Bekijk de MQ-foutenlogboeken (AMQERR01.LOG) op de wachtrijbeheerserver. Deze logboeken bieden gedetailleerde informatie over de autorisatiefout, inclusief de gebruikers-ID, het object waartoe toegang wordt verkregen en de machtigingen die ontbreken.

* Van toepassingscode: Debug de applicatiecode om te bepalen hoe de gebruikers-ID wordt bepaald en doorgegeven aan MQ.

* Windows Process Explorer (Sysinternals): Gebruik Process Explorer om de gebruikerscontext te identificeren waaronder de applicatie draait. Dit is met name handig voor services of applicaties die onder verschillende accounts draaien.

2. Verifieer MQ-objectrechten:

* Het gebruik van `dspmqaut` (Display MQ Authority): Deze opdracht is uw primaire hulpmiddel. Voer het uit om de machtigingen weer te geven die aan een specifieke gebruiker of groep zijn verleend voor een specifiek MQ-object (wachtrijbeheerder, wachtrij, kanaal, enz.).

* Voorbeeld:`dspmqaut -m QMGRNAME -t qmgr -p USERID` (Toont machtigingen voor `USERID` in de wachtrijbeheerder `QMGRNAME`)

* Voorbeeld:`dspmqaut -m QMGRNAME -t wachtrij -n QUEUENAME -p USERID` (toont machtigingen voor `USERID` in de wachtrij `QUEUENAME`)

* Voorbeeld:`dspmqaut -m QMGRNAME -t channel -n CHANNELNAME -p USERID` (Toont rechten voor `USERID` op het kanaal `CHANNELNAME`)

* MQ Explorer (GUI): U kunt objectmachtigingen ook bekijken en wijzigen via de MQ Explorer GUI (klik met de rechtermuisknop op het object, selecteer "Eigenschappen" en ga vervolgens naar het tabblad "Authoriteitsrecords").

3. CHLAUTH-records onderzoeken:

* Het gebruik van `dspmqchauth` (Display Channel Authentication Records):

* Voorbeeld:`dspmqchauth -m QMGRNAME -t chlauth -n CHANNELNAME` (Toont alle CHLAUTH-records voor kanaal `CHANNELNAME`)

* MQ Explorer: U kunt CHLAUTH-records ook bekijken en beheren in de MQ Explorer GUI (klik met de rechtermuisknop op de wachtrijbeheerder, selecteer "Eigenschappen" en ga vervolgens naar het tabblad "Kanaalauthenticatierecords").

* Controleer op blokkeringsregels: Zoek naar CHLAUTH-records die mogelijk expliciet de gebruikers-ID, het IP-adres of de clientnaam blokkeren.

* Verifieer het kenmerk `MCAUSER`: Controleer het kenmerk `MCAUSER` op het SVRCONN-kanaal. Is het correct ingesteld? Als er een algemene gebruikers-ID wordt gebruikt, zorg er dan voor dat de gebruikers-ID over de benodigde machtigingen beschikt.

4. Machtigingen verlenen (met `setmqaut`):

* Nadat u de ontbrekende rechten heeft geïdentificeerd, gebruikt u het `setmqaut` commando om ze te verlenen.

* Voorbeeld:`setmqaut -m QMGRNAME -t qmgr -n +connect -g "Domain\GroupName"` (Verleent toestemming om verbinding te maken met Wachtrijbeheer voor de opgegeven domeingroep)

* Voorbeeld:`setmqaut -m QMGRNAME -t wachtrij -n QUEUENAME -g "Domein\Groepsnaam" +get +put +browse` (Verleent toestemming voor het ophalen, plaatsen en bladeren van de wachtrij aan de opgegeven domeingroep)

* Voorbeeld:`setmqaut -m QMGRNAME -t kanaal -n KANAALNAAM -p GEBRUIKERSID +connect` (Verleent verbindingsrechten voor het kanaal aan een specifieke gebruiker)

5. Vernieuw de beveiliging:

* Nadat u wijzigingen heeft aangebracht in objectmachtigingen of CHLAUTH-records, vernieuwt u de beveiliging door het commando 'REFRESH SECURITY TYPE(CONNAUTH)' te geven voor wijzigingen in de verbindingsauthenticatie. Als dit niet werkt, probeer dan Wachtrijbeheer opnieuw te starten.

6. Vereenvoudigen en testen:

* Test met `amqsputc` en `amqsgetc`: Gebruik de voorbeeldprogramma's `amqsputc` (om een ​​bericht te plaatsen) en `amqsgetc` (om een ​​bericht te krijgen) om de basisconnectiviteit en autorisatie te verifiëren. Deze zijn uitstekend geschikt om het probleem te isoleren. Voer ze in eerste instantie uit vanaf dezelfde server als de MQ-server. Als dat werkt, voer ze dan uit vanaf een clientcomputer.

* Verminder de complexiteit: Begin met de eenvoudigst mogelijke configuratie en voeg geleidelijk de complexiteit toe. Maak bijvoorbeeld eerst verbinding met de wachtrijbeheerder zonder dat CHLAUTH is ingeschakeld en voeg vervolgens geleidelijk CHLAUTH-regels toe en verfijn deze.

7. Raadpleeg documentatie en IBM-ondersteuning:

* IBM MQ-documentatie: De IBM MQ-documentatie is uw beste bron voor gedetailleerde informatie over autorisatie, CHLAUTH en andere beveiligingsfuncties.

* IBM-ondersteuning: Als u nog steeds vastzit, kunt u overwegen een ondersteuningsaanvraag bij IBM te openen. Ze beschikken over experts die u kunnen helpen bij het diagnosticeren en oplossen van complexe autorisatieproblemen.

Belangrijke overwegingen:

* Groepen versus individuele gebruikers: Het is over het algemeen het beste om machtigingen te verlenen aan Windows-groepen in plaats van aan individuele gebruikers. Dit maakt het beheer veel eenvoudiger, vooral in grotere omgevingen.

* Minste privilege: Verleen alleen de minimaal noodzakelijke machtigingen aan elke gebruiker of groep.

* Controle: Maak auditing van beveiligingsgerelateerde gebeurtenissen mogelijk, zodat u autorisatiefouten kunt opsporen en potentiële beveiligingsproblemen kunt identificeren.

Door deze stappen voor probleemoplossing systematisch te volgen en zorgvuldig de foutenlogboeken en de MQ-configuratie te bekijken, zou u de "niet geautoriseerde" fout in uw IBM MQ-omgeving moeten kunnen diagnosticeren en oplossen. Houd er rekening mee dat nauwkeurige identificatie van de gebruikers-ID en een grondig begrip van MQ-beveiligingsconcepten cruciaal zijn voor succes.