WebSphere MQ, das unter einem lokalen Konto/einer lokalen Gruppe ausgeführt wird, kann die Gruppenmitgliedschaften für Active Directory-Benutzer nicht lesen. Problemumgehung oder alternative Lösung?

WebSphere MQ, das unter einem lokalen Konto/einer lokalen Gruppe ausgeführt wird, kann die Gruppenmitgliedschaften für Active Directory-Benutzer nicht lesen. Problemumgehung oder alternative Lösung?

Ich entwickle eine Anwendung, die WebSphere MQ v6.0 verwendet. WebSphere MQ funktioniert derzeit aufgrund des folgenden Problems nicht:

  • Der WebSphere MQ-Dienst wird unter dem lokalen Benutzer „MUSR_MQADMIN“ in der lokalen Gruppe „mqm“ ausgeführt.
  • Ich versuche, den Dienst mit meinem eigenen Konto BIZ\noahz zu nutzen
  • MUSR_MQADMIN muss prüfen, ob BIZ\noahz in der lokalen Gruppe „mqm“ ist
  • MUSR_MQADMIN hat keine Berechtigung zum Lesen der Active Directory-Gruppenmitgliedschaft von BIZ\noahz
  • Der folgende Fehler erscheint in der MQ-Protokolldatei:

----- amqzfubn.c : 3582 -----------------------------------------------------------

31.01.2011 18:51:32 - Prozess (704.1105) Benutzer (MUSR_MQADMIN) Programm (amqzlaa0.exe) AMQ8079: Beim Versuch, Informationen zur Gruppenmitgliedschaft für den Benutzer „noahz@biz“ abzurufen, wurde der Zugriff verweigert.

ERKLÄRUNG: WebSphere MQ, das mit der Berechtigung des Benutzers „musr_mqadmin@noahz-biz“ ausgeführt wurde, konnte keine Informationen zur Gruppenmitgliedschaft für den angegebenen Benutzer abrufen. AKTION: Stellen Sie sicher, dass die Active Directory-Zugriffsberechtigungen dem Benutzer „musr_mqadmin@noahz-biz“ erlauben, Gruppenmitgliedschaften für den Benutzer „noahz@biz“ zu lesen. Um Informationen zur Gruppenmitgliedschaft für einen Domänenbenutzer abzurufen, muss MQ mit der Berechtigung eines Domänenbenutzers ausgeführt werden.

----- amqzfubn.c : 3582 -----------------------------------------------------------

Weitere Informationen habe ich hier auf der IBM-Website gefunden: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqtac.doc/wq10830_.htm

Ich habe keine Active Directory-Administratorrechte für meinen Windows-Rechner, daher lautet meine Frage:

Gibt es sonst noch etwas, das ich tun kann, um dieses Problem zu beheben (oder zu umgehen) und WebSphere MQ wieder zum Laufen zu bringen? Kann ich beispielsweise diese Sicherheitsüberprüfung in WebSphere MQ deaktivieren?

AKTUALISIERENHier ist die Antwort, die ich vom IBM-Support erhalten habe:

Normalerweise weisen diese Fehler auf ein Problem mit der Benutzer-ID hin, unter der der MQ-Dienst in dcom ausgeführt werden soll. Wenn Sie sich nicht sicher sind, welche Benutzer-ID dies ist, können Sie Folgendes überprüfen:

Öffnen Sie eine Eingabeaufforderung und geben Sie ein: dcomcnfg. Sobald die Komponentendienste-MMC geöffnet ist, doppelklicken Sie auf „Komponentendienste“, doppelklicken Sie auf „Computer“, doppelklicken Sie auf „Arbeitsplatz“, doppelklicken Sie auf „DCOM-Konfiguration“. Suchen Sie im Fenster nach „IBM MQSeries Services“, klicken Sie mit der rechten Maustaste darauf und wählen Sie dann „Eigenschaften“. Klicken Sie auf die Registerkarte „Identität“. Es sollte „dieser Benutzer“ gefolgt von einer ID angezeigt werden.

Stellen Sie sicher, dass die MQ-Service-ID (aus der Registerkarte „Identität“ oben) lokal über die erforderlichen Rechte verfügt. Erteilen Sie ihr alle fehlenden Rechte für Folgendes:

Öffnen Sie Start->Programme->Verwaltung->Lokale Sicherheitseinstellungen.

Öffnen Sie „Lokale Richtlinien“ und dann „Zuweisen von Benutzerrechten“. Überprüfen Sie durch Doppelklicken, ob die folgenden Rechte festgelegt sind:
- Anmelden als Batch-Job
- Anmelden als Dienst
- Herunterfahren des Systems
- Debuggen von Programmen
- Erhöhen von Kontingenten
- Handeln als Teil des Betriebssystems
- Umgehen der Traverse-Prüfung
- Ersetzen eines Tokens auf Prozessebene

Das Endergebnis war, dass meine IT-Abteilung und InfoSec entschieden, dass WebSphere MQ eine „Serversoftware“ sei und daher auf einzelnen Arbeitsstationen nicht zulässig sei. Daher kam ich nicht einmal dazu, die obige Lösung zu testen!

Antwort1

Obwohl ich die oben genannten DCOM-Einträge (bezogen auf V7.1?) nicht finden konnte, konnte ich mithilfe des zuvor erwähnten Runas-Tipps einen lokalen Windows V7.1 Qmgr erstellen, starten und mich damit verbinden, ohne Zugriff auf Active Directory zu haben. So habe ich es gemacht:

  • Ändern Sie das Passwort für den Benutzer MUSR_MQADMIN im lusrmgr von Windows
  • Überprüfen Sie, ob der MQService gestoppt wurde
  • Ändern Sie in der Dienstliste auch das Passwort für den Benutzer MUSR_MQADMIN
  • Öffnen Sie eine DOS-Box und führen Sie Folgendes aus: C:> runas /user:MUSR_MQADMIN "crtmqm QMGR1" C:> runas /user:MUSR_MQADMIN "strmqm QMGR1" (beachten Sie, dass Sie für jeden Befehl das Passwort eingeben müssen)
  • Klicken Sie mit der rechten Maustaste auf das MQ-Symbol in der Taskleiste und wählen Sie „WebSphere MQ Explorer“
  • Der MQ Explorer öffnet sich und sollte den Qmgr „QMGR1“ mit einem roten Pfeil nach unten anzeigen. Klicken Sie mit der rechten Maustaste auf dieses Symbol und wählen Sie „Starten...“
  • Wählen Sie im Popup „Interaktiv starten“ und klicken Sie auf „OK“.
  • Das QMGR1-Symbol sollte jetzt einen grünen Pfeil nach oben haben (gestartet) und sein Quadrat sollte gelb sein (verbunden).
  • Erstellen Sie im MQ Explorer eine Warteschlange mit dem Namen TEST1 und legen Sie deren Standardpersistenz fest.
  • In der DOS-Box führen Sie aus:
    C:\amqsput\TEST1\QMGR1 Geben Sie eine Nachricht ein ... und dann eine leere Zeile, um das Beispielprogramm zu beenden
  • Prüfen Sie nun im MQ Explorer, ob Ihre Nachricht da ist!

Tipp: MQ-Returncodes können schnell mit dem Befehl "mqrc" überprüft werden, z. B. C:>mqrc 2085

Antwort2

WebSphere MQ muss immer die Gruppenmitgliedschaft jeder ID abrufen, die versucht, seine Komponenten auszuführen oder den Zugriff auf seine Ressourcen zu autorisieren. Wenn diese IDs nicht lokal sind, benötigt MQ Rechte, um SAM-Mitgliedschaftssuchen in der Domäne durchzuführen, der die ID gehört. Es gibt einige Workarounds:

  1. Verwenden Sie eine lokale ID. MQ kann immer in der lokalen SAM-Datenbank nachschlagen, da es von einem Administrator installiert worden sein muss und sich während der Installation die entsprechenden lokalen Rechte zugewiesen hat. Es muss nicht MUSR_MQADMIN sein, aber es muss sich in der MQM-Gruppe befinden, wenn es den QMgr ausführen soll.
  2. Verwenden Sie WMQ Explorer, um den QMgr zu starten. Jede aktuelle Version von WMQ Explorer fordert verschiedene Optionen an, darunter die Möglichkeit, den QMgr unter der ID zu starten, der der Dienst gehört. Sobald er gestartet ist, können Sie mit Ihrer normalen ID auf Warteschlangen und Themen zugreifen.

AKTUALISIEREN:
Ich wünschte, ich hätte daran gedacht, bevor Ihre IT-Abteilung durchgegriffen hat, aber es ist möglich, den Object Authority Manager zu deaktivieren. Das ist die Komponente, die die Suche in der AD-Domäne durchführt. Ich weiß, dass durch die Deaktivierung alles eine Verbindung zum QMgr herstellen kann, ohne dass es Probleme mit den Domänenberechtigungen gibt. Ich binziemlich sicherDadurch kann Ihre ID auch die Prozesse ausführen, die den QMgr ausführen.

Antwort3

Ich entwickle auch Anwendungen mit Websphere Message Broker. Derzeit habe ich eine „Entwickler“-Edition. Ich habe eine Möglichkeit gefunden, dies zu umgehen, indem ich MQ mit deaktivierter SAM-Mitgliedschaftssuche installiere.

Dazu habe ich „Websphere MQ Launchpad“ (Setup.exe unter Windows ausführen) aus dem Installationsverzeichnis (Websphere_MQ_V7.5) ausgeführt. Auf der Registerkarte „Netzwerkkonfiguration“ gibt es eine Option zum Deaktivieren der Benutzer-ID-Konfiguration. Wählen Sie „Nein“ und führen Sie die Installation durch.

Beachten Sie, dass dies für Produktions- und QA-Umgebungen möglicherweise nicht die beste Option ist.

Antwort4

Ich denke, der beste Versuch ist,Rennen wieSo führen Sie es als MQ-Benutzer aus:

runas /user:MUSR_MQADMIN "strmqm <qmgr-name>"

verwandte Informationen