Wenn Sie mit IBM WebSphere MQ (jetzt als IBM MQ bekannt) ein "Nicht" -Fehler auf Windows erhalten, bedeutet dies mit ziemlicher Sicherheit, dass Sie auf ein mqrc_not_authorized stoßen Fehler.

Hier ist eine Aufschlüsselung dessen, was das bedeutet und wie man es behebt:

Was MQRC_NOT_Authorisierte (oder Ursache Code 2035) bedeutet:

Dies ist der häufigste Autorisierungsfehler in MQ. Es zeigt an, dass die Benutzer -ID (oder der Benutzerkontext, unter dem die Anwendung ausgeführt wird) * nicht * über die erforderlichen Berechtigungen verfügt, um die Aktion auszuführen, die sie auf einer bestimmten MQ -Ressource ausführen soll. Stellen Sie sich vor, der Versuch, ohne die erforderlichen Lese-/Schreibberechtigungen auf eine Datei auf Ihrem Computer zuzugreifen.

Gemeinsame Szenarien und Ursachen:

1. Falschem Benutzer -ID -Kontext:

* als anderer Benutzer ausführen: Die Anwendung wird möglicherweise unter einem anderen Windows -Benutzerkonto ausgeführt als das, von dem Sie denken, dass es sie ist. Dies kann passieren, wenn Sie Servicekonten, geplante Aufgaben geändert haben oder die Anwendung aus einer Eingabeaufforderung mit erhöhten Berechtigungen ausführen (z. B. "als Administrator ausgeführt").

* falscher Benutzer für COM+ -Anwendungen: Wenn Ihre Anwendung COM+ Services verwendet, ist die für die COM+ -Anwendung konfigurierte Identität von entscheidender Bedeutung. Stellen Sie sicher, dass es ein Konto mit MQ -Berechtigungen verwendet.

* WebSphere Application Server (wurde) Probleme: Wenn Ihre Anwendung auf dem WebSphere Application Server bereitgestellt wird, stellen Sie sicher, dass die für die Datenquelle konfigurierte Benutzer -ID und die Sicherheitsrolle der Anwendung in MQ ordnungsgemäß autorisiert sind.

2. fehlende oder falsche MQ -Objektberechtigungen:

* Warteschlangenzugriff: Der Benutzer hat nicht `+get`,`+put`, `+shrowse` oder andere erforderliche Berechtigungen in der spezifischen Warteschlange, auf die die Anwendung zugreift. `+Connect`- und`+Infragestellungen werden ebenfalls häufig benötigt.

* Warteschlangenmanagerzugriff: Der Benutzer hat nicht `+Connect` Autorität für den Warteschlangenmanager selbst. Dies ist eine grundlegende Anforderung.

* Kanalzugriff: Wenn die Anwendung remote eine Verbindung herstellt, hat der Benutzer keine `+connect` -Autorität für den Server Connection Channel (SVRCNN). Möglicherweise benötigen Sie auch Berechtigungen, den Kanal wie `+Altuser` oder`+setAll` zu verwenden, je nachdem, wie die Kanalauthentifizierungsdatensätze (ChlAuth) konfiguriert sind.

* Prozessdefinition (Prozess) Zugriff: Wenn die Anwendung Triggermonitore verwendet, benötigt der Benutzer "+Get` -Autorität" in der Initiationswarteschlange und den geeigneten Zugriff auf die Prozessdefinition.

* Themenzugriff: Für die Veröffentlichung/Abonnement -Anwendungen benötigt der Benutzer das entsprechende Abonnement und Veröffentlichungsberechtigungen zu Themen oder Themenzeichenfolge.

3. ChlAuth -Datensätze (Kanalauthentifizierungsdatensätze):

* Blockierte Kanäle: ChlAuth -Datensätze können bestimmte Benutzer -IDs oder IP -Adressen explizit von der Verwendung bestimmter Kanäle blockieren. Wenn ein ChlAuth -Datensatz den Benutzer daran hindert, eine Verbindung herzustellen, wird der Fehler als `mqrc_not_authorized` angezeigt.

* McAuser -Attribut: Das Attribut "McAuser" im Serververbindungskanal (SVRCNN) gibt die Benutzer -ID an, die verwendet wird, wenn ein Client eine Verbindung herstellt. Wenn "McAuser" falsch eingestellt oder nicht ordnungsgemäß konfiguriert ist, kann dies zu Autorisierungsproblemen führen.

4.

* Falsche OAM -Richtlinien: Das OAM ist für die Durchsetzung von Sicherheitsrichtlinien verantwortlich. Falsche Richtlinien können versehentlich den Zugriff auf MQ -Ressourcen verweigern.

* Gruppenmitgliedschaft: Der Benutzer ist möglicherweise Mitglied einer Windows -Gruppe, aber der Gruppe wurde die erforderlichen MQ -Berechtigungen nicht erteilt.

5. Falsche Codierungspraktiken:

* keine Anmeldeinformationen richtig übergeben: Wenn die Anwendung zur Übergabe von Benutzeranmeldeinformationen zur Autorisierung an MQ weitergeleitet wird, stellen Sie sicher, dass diese Anmeldeinformationen korrekt übergeben werden (z. B. unter Verwendung des Felds "userID" in der MQMD oder in der Struktur von "SecurityParameters" bei der Verbindung).

* Standard -Benutzerkontext fälschlicherweise: Das Verlassen auf den Standardbenutzerkontext kann problematisch sein, insbesondere in mehrstufigen Architekturen. Die explizit Angabe der Benutzer -ID ist oft zuverlässiger.

Schritte zur Fehlerbehebung:

1. Identifizieren Sie die Benutzer -ID:

* aus Anwendungsprotokollen: Überprüfen Sie die Protokolle der Anwendung auf alle Nachrichten, die sich auf die MQ -Verbindung oder -autorisierung beziehen. Die Fehlermeldung kann die verwendete Benutzer -ID enthalten.

* aus MQ -Fehlerprotokollen: Untersuchen Sie die MQ -Fehlerprotokolle (amQerr01.log) auf dem Warteschlangen -Manager -Server. Diese Protokolle liefern detaillierte Informationen zum Autorisierungsfehler, einschließlich der Benutzer -ID, dem aufgenommenen Objekt und den fehlenden Berechtigungen.

* vom Anwendungscode: Debuggen Sie den Anwendungscode, um festzustellen, wie die Benutzer -ID ermittelt und an MQ übergeben wird.

* Windows Process Explorer (Syssinternale): Verwenden Sie Process Explorer, um den Benutzerkontext zu identifizieren, unter dem die Anwendung ausgeführt wird. Dies ist besonders nützlich für Dienste oder Anwendungen, die unter verschiedenen Konten ausgeführt werden.

2. MQ -Objektberechtigungen überprüfen:

* Verwenden von `dspmqaut` (Anzeige MQ Authority): Dieser Befehl ist Ihr primäres Werkzeug. Führen Sie es aus, um die Berechtigungen anzuzeigen, die einem bestimmten Benutzer oder einer bestimmten Gruppe in einem bestimmten MQ -Objekt (Warteschlangenmanager, Warteschlange, Kanal usw.) erteilt wurden.

* Beispiel:`dspmqaut -m qmgrname -t qmgr -p userId` (Zeigt Berechtigungen für` userId` im Queue -Manager `qmgrname` an)

* Beispiel:`dspmqaut -m qmgrname -t queue -n queueName -p userId` (Zeigt Berechtigungen für` userId 'in der Warteschlange `queueName` an)

* Beispiel:`DSPMQAUT -M QMGRNAME -T -Kanal -n ChannelName -p userID` (Zeigt Berechtigungen für` userID` auf dem Kanal `ChannelName` an)

* MQ Explorer (GUI): Sie können auch Objektberechtigungen über die MQ Explorer-GUI anzeigen und ändern (klicken Sie mit der rechten Maustaste auf das Objekt, wählen Sie "Eigenschaften" und gehen Sie dann zur Registerkarte "Autoritätsunterlagen").

3. untersuchen Sie ChlAuth -Datensätze:

* Verwenden von `dspmqchAuth` (Kanalauthentifizierungsdatensätze anzeigen):

* Beispiel:`dspmqchAuth -m qmgrname -t ChlAuth -n ChannelName` (Zeigt alle ChlAuth -Datensätze für Channel` ChannelName` an)

* MQ Explorer: Sie können auch ChlAuth-Datensätze in der MQ Explorer-GUI anzeigen und verwalten (klicken Sie mit der rechten Maustaste auf den Warteschlangenmanager, wählen Sie "Eigenschaften" und wechseln Sie dann auf die Registerkarte "Channel-Authentifizierungsdatensätze").

* Auf Blockierungsregeln überprüfen: Suchen Sie nach ChlAuth -Datensätzen, die möglicherweise explizit die Benutzer -ID, die IP -Adresse oder den Client -Namen blockieren.

* `McAuser` -Attribut verifizieren: Überprüfen Sie das Attribut "McAuser" auf dem SvrConn -Kanal. Ist es richtig eingestellt? Wenn sie eine generische Benutzer -ID verwendet, stellen Sie sicher, dass die Benutzer -ID über die erforderlichen Berechtigungen verfügt.

4.

* Verwenden Sie nach Identifizierung der fehlenden Berechtigungen den Befehl "setMQAut", um sie zu gewähren.

* Beispiel:`setMqaut -m qmgrname -t qmgr -n +connect -g" Domain \ GroupName "` (Zuschüsse Connect -Genehmigung an den Warteschlangenmanager an die angegebene Domänengruppe)

* Beispiel:`setMqaut -m qmgrname -t Queue -n QueueName -g" Domain \ GroupName " +Get +Put +Browse` (Zuschüsse erhalten, platzieren und durchsuchen und die Warteschlange zur angegebenen Domänengruppe erhalten).

* Beispiel:`setMqaut -m qmgrname -t Kanal -n ChannelName -p userID +connect` (Zuschüsse Connect -Berechtigung zum Kanal an einen bestimmten Benutzer)

5. Sicherheit aktualisieren:

* Nachdem Änderungen an Objektberechtigungen oder ChlAuth -Aufzeichnungen vorgenommen wurden, aktualisieren Sie die Sicherheit, indem Sie den Befehl ausgeben:"Aktualisieren der Sicherheitstyp (ConnAuth)` Für Änderungen an der Verbindungsauthentifizierung. Wenn dies nicht funktioniert, starten Sie den Warteschlangenmanager neu.

6. vereinfachen und testen:

* Test mit `amqSputc` und` amqsgetC`: Verwenden Sie die Beispielprogramme `amqsputc` (um eine Nachricht einzulegen) und` amqsgetC` (um eine Nachricht abzuholen), um die grundlegende Konnektivität und Autorisierung zu überprüfen. Diese eignen sich hervorragend zum Isolieren des Problems. Führen Sie sie zunächst vom selben Server wie der MQ -Server aus. Wenn das funktioniert, führen Sie sie von einem Client -Computer aus.

* Komplexität reduzieren: Beginnen Sie mit der einfachsten möglichen Konfiguration und fügen Sie allmählich Komplexität hinzu. Stellen Sie sich beispielsweise zunächst eine Verbindung zum Warteschlangenmanager ohne Aktivierung von ChlAuth her und fügen Sie die CHLAUTH -Regeln nach und nach hinzu und verfeinern Sie allmählich.

7. Dokumentation und IBM -Unterstützung:

* IBM MQ -Dokumentation: Die IBM MQ -Dokumentation ist die beste Quelle für detaillierte Informationen zu Autorisierung, Chlauth und anderen Sicherheitsfunktionen.

* IBM -Unterstützung: Wenn Sie immer noch festsitzen, sollten Sie einen Support -Fall mit IBM eröffnen. Sie haben Experten, die Ihnen bei der Diagnose und Lösung komplexer Autorisierungsprobleme helfen können.

wichtige Überlegungen:

* Gruppen vs. einzelne Benutzer: Es ist im Allgemeinen Best Practice, Windows -Gruppen als einzelne Benutzer Berechtigungen zu erteilen. Dies erleichtert die Verwaltung erheblich, insbesondere in größeren Umgebungen.

* am wenigsten Privilegien: Gewähren Sie jedem Benutzer oder einer Gruppe nur die erforderlichen Mindestberechtigungen.

* Auditing: Aktivieren Sie die Prüfung von Sicherheitsbezogenen Ereignissen, um die Verfolgung von Autorisierungsfehlern zu verfolgen und potenzielle Sicherheitsprobleme zu identifizieren.

Durch systematischem Befolgen dieser Schritte zur Fehlerbehebung und sorgfältiger Überprüfung der Fehlerprotokolle und der MQ -Konfiguration sollten Sie in der Lage sein, den Fehler "nicht autorisiert" in Ihrer IBM MQ -Umgebung zu diagnostizieren und zu beheben. Denken Sie daran, dass eine genaue Identifizierung der Benutzer -ID und ein gründliches Verständnis der MQ -Sicherheitskonzepte für den Erfolg von entscheidender Bedeutung sind.