När du får ett "inte" -fel på Windows med IBM WebSphere MQ (nu känd som IBM MQ), betyder det nästan säkert att du stöter på en
mqrc_not_authorized fel.
Här är en uppdelning av vad det betyder och hur man felsöker det:
Vad MQRC_NOT_AUTHORIZED (eller orsakskod 2035) betyder:
Detta är det vanligaste auktoriseringsfelet i MQ. Det indikerar att användar -ID (eller användarkonteksten enligt vilket applikationen körs) * inte * har de nödvändiga behörigheterna för att utföra åtgärden det försöker göra på en specifik MQ -resurs. Tänk på det som att försöka komma åt en fil på din dator utan de nödvändiga läs-/skrivbehörigheter.
Vanliga scenarier och orsaker:
1. Felaktig användar -ID -kontext:
* Kör som en annan användare: Applikationen kan köras under ett annat Windows -användarkonto än det du tror att det är. Detta kan hända om du har ändrat servicekonton, schemalagda uppgifter eller kör applikationen från en kommandotolk med förhöjda privilegier (t.ex. "Kör som administratör").
* Felaktig användare för COM+ Applications: Om din applikation använder COM+ -tjänster är identiteten som är konfigurerad för COM+ -applikationen avgörande. Se till att det använder ett konto som har MQ -behörigheter.
* WebSphere Application Server (var) Problem: Om din applikation distribueras i WebSphere Application Server, se till att användar -ID är konfigurerat för datakällan och applikationens säkerhetsrollkartläggningar är korrekt godkända i MQ.
2. saknas eller felaktiga MQ -objektbehörigheter:
* könsåtkomst: Användaren har inte `+get`,`+put`, `+bläddra` eller andra nödvändiga behörigheter i den specifika köen som applikationen försöker komma åt. `+Connect` och`+Fråga "behörigheter behövs också ofta.
* köhanterare Tillgång: Användaren har inte '+Connect' myndighet till själva köhanteraren. Detta är ett grundläggande krav.
* kanalåtkomst: Om applikationen ansluter på distans har användaren inte `+Connect` myndighet till serveranslutningskanalen (SVRCONN). Det kan också behöva behörigheter för att använda kanalen, till exempel `+altuser`, eller`+setall` beroende på hur kanalautentiseringsposterna (Chlauth) är konfigurerade.
* Process Definition (Process) Access: Om applikationen använder triggermonitorer behöver användaren `+få 'myndighet för initieringskön och lämplig åtkomst vid processdefinitionen.
* Ämneåtkomst: För att publicera/prenumerera applikationer behöver användaren lämplig prenumeration och publiceringsbehörigheter i ämnet eller ämnet.
3. Chlauth -poster (kanalautentiseringsposter):
* Blockerade kanaler: Chlauth -poster kan uttryckligen blockera vissa användar -ID eller IP -adresser från att använda specifika kanaler. Om en Chlauth -post hindrar användaren från att ansluta, kommer felet att visas som `mqrc_not_authorized`.
* McAuser -attribut: Attributet "MCAUSER" på serveranslutningskanalen (SVRCONN) anger användar -ID som kommer att användas när en klient ansluter. Om "mcauser" ställs in felaktigt eller inte konfigureras korrekt kan det leda till auktorisationsfrågor.
4. Object Authority Manager (OAM) Konfigurationsfrågor:
* Felaktiga OAM -policyer: OAM ansvarar för att upprätthålla säkerhetspolicyn. Felaktig policy kan oavsiktligt förneka tillgången till MQ -resurser.
* Gruppmedlemskap: Användaren kan vara medlem i en Windows -grupp, men gruppen har inte beviljats nödvändiga MQ -behörigheter.
5. Felaktig kodningspraxis:
* inte passerar referenser korrekt: Om applikationen är utformad för att skicka användaruppgifter till MQ för godkännande, se till att dessa referenser skickas korrekt (t.ex. med hjälp av "userid" -fältet i MQMD eller "SecurityParameters" -strukturen vid anslutning).
* Använda standardanvändarekontext felaktigt: Att förlita sig på standardanvändarens sammanhang kan vara problematiskt, särskilt i flerskiktade arkitekturer. Att specificera användar -ID är ofta mer tillförlitligt.
Felsökningssteg:
1. Identifiera användar -ID:
* Från applikationsloggar: Kontrollera applikationens loggar för alla meddelanden relaterade till MQ -anslutningen eller auktorisationen. Felmeddelandet kan innehålla användar -ID som används.
* Från MQ -felloggar: Undersök MQ -felloggarna (AMQERR01.LOG) på köhanterarservern. Dessa loggar ger detaljerad information om auktorisationsfel, inklusive användar -ID, objektet som nås och de behörigheter som saknas.
* Från applikationskod: Debugga applikationskoden för att bestämma hur användar -ID bestäms och skickas till MQ.
* Windows Process Explorer (sysinternals): Använd Process Explorer för att identifiera användarens sammanhang under vilket applikationen körs. Detta är särskilt användbart för tjänster eller applikationer som körs under olika konton.
2. Verifiera MQ -objektbehörigheter:
* med `DSPMQAUT` (Display MQ Authority): Detta kommando är ditt primära verktyg. Kör den för att visa de behörigheter som beviljas till en specifik användare eller grupp på ett specifikt MQ -objekt (köhanterare, kö, kanal, etc.).
* Exempel:`dspmqaut -m qmgrname -t qmgr -p userid` (visar behörigheter för` userid` på köhanteraren 'qmgrname')
* Exempel:`dspmqaut -m qmgrname -t kö -n queuename -p userid` (visar behörigheter för` userid` i köen `queuename '))
* Exempel:`dspmqaut -m qmgrname -t kanal -n kanalnamn -p userid` (visar behörigheter för` userId` på kanalen `kanalName ')
* mq Explorer (GUI): Du kan också visa och ändra objektbehörigheter genom MQ Explorer GUI (högerklicka på objektet, välj "Egenskaper", gå sedan till fliken "Authority Records").
3. Undersök Chlauth -poster:
* med `DSPMQCHAUTH` (Display Channel Authentication Records):
* Exempel:`dspmqchauth -m qmgrname -t chlauth -n kanalnamn '(visar alla chlauth -poster för kanal` kanalnamn')
* mq Explorer: Du kan också visa och hantera Chlauth-poster i MQ Explorer GUI (högerklicka på köhanteraren, välj "Egenskaper", gå sedan till fliken "Channel Authentication Records").
* Kontrollera för blockeringsregler: Leta efter Chlauth -poster som uttryckligen kan blockera användar -ID, IP -adress eller klientnamn.
* Verifiera `mcauser` attribut: Kontrollera attributet `McAuser 'på SVRCONN -kanalen. Är det inställt på rätt sätt? Om det använder ett generiskt användar -ID, se till att användar -ID har nödvändiga behörigheter.
4. beviljande behörigheter (med `setMqaut`):
* När du har identifierat de saknade behörigheterna, använd kommandot `setMqaut` för att ge dem.
* Exempel:`setMqaut -M qmgrname -t qmgr -n +connect -g" domän \ gruppnamn "` (ger anslutning tillåtelse till köhanteraren till den angivna domängruppen)
* Exempel:`setMqaut -M qmgrname -t kö -n queuename -g" domän \ gruppnamn " +get +put +bläddra" (bidrag get, put och bläddra till tillstånd till köen till den angivna domängruppen)
* Exempel:`setMqaut -M qmgrname -t kanal -n kanalnamn -p userid +connect` (bidrag anslutning tillåtelse till kanalen till en specifik användare)
5. Uppdatera säkerhet:
* Efter att ha gjort ändringar i objektbehörigheter eller Chlauth -poster, uppdatera säkerheten genom att utfärda kommandot:`Uppdatera säkerhetstyp (Connauth)` för ändringar i anslutningsautentisering. Om detta inte fungerar, försök att starta om köhanteraren.
6. Förenklade och testar:
* Test med `AmqSputC` och` AMQSGETC`: Använd provprogrammen `AmqSputC` (för att sätta ett meddelande) och` AmqsgetC` (för att få ett meddelande) för att verifiera den grundläggande anslutningen och auktorisationen. Dessa är utmärkta för att isolera problemet. Kör dem från samma server som MQ -servern initialt. Om det fungerar, kör dem från en klientmaskin.
* Minska komplexiteten: Börja med den enklaste möjliga konfigurationen och lägg gradvis komplexitet. Anslut till exempel initialt till köhanteraren utan Chlauth aktiverad, lägg sedan gradvis till och förfina Chlauth -regler.
7. Konsultera dokumentation och IBM -stöd:
* IBM MQ -dokumentation: IBM MQ -dokumentationen är din bästa källa för detaljerad information om auktorisation, chlauth och andra säkerhetsfunktioner.
* IBM -stöd: Om du fortfarande är fast, överväg att öppna ett stödfall med IBM. De har experter som kan hjälpa dig att diagnostisera och lösa komplexa auktorisationsproblem.
Nyckelöverväganden:
* grupper kontra enskilda användare: Det är i allmänhet bästa praxis att bevilja behörigheter till Windows -grupper snarare än enskilda användare. Detta gör administrationen mycket enklare, särskilt i större miljöer.
* minst privilegium: Ge endast de minsta nödvändiga behörigheterna till varje användare eller grupp.
* Revision: Aktivera revision av säkerhetsrelaterade evenemang som hjälper dig att spåra auktorisationsfel och identifiera potentiella säkerhetsfrågor.
Genom att systematiskt följa dessa felsökningssteg och noggrant granska felloggarna och MQ -konfigurationen, bör du kunna diagnostisera och lösa det "inte auktoriserade" felet i din IBM MQ -miljö. Kom ihåg att exakt identifiering av användar -ID och en grundlig förståelse av MQ -säkerhetskoncept är avgörande för framgång.
