Wildfire Messaging 2011 - WMQ FTE Lab Instructions

Transcrição

© Copyright IBM Corporation 2013. All rights reserved.
From Zero to z/Hero
IBM SWG Wildfire Workshops
WebSphere MQ
Advanced Message Security (AMS) for z/OS
Lab Version V1.3.0- Wildfire 2013
Mar 31, 2013
Change History
Vers. Datum
Änderung
1.3.0
1.2.0
1.1.0
1.0.1
1.0.0
Modifizierter Team-Ansatz: nur jeweils ein User (z, Win)
Erweiterung Übung 4 (Zertifikatsverwaltung) – nur EN Version
Upgrade nach WMQ 7.5 auf Windows
SW Stände: WMQ 7.1 – Korrektur Typos
SW Stände: WMQ 7.0.1, AMS 7.0.1.(1)
31.Mar..2013
11.Feb.2013
31.Jan.2013
27.Aug.2012
25.Jan.2012
Wildfire-WebSphere MQAMS
Seite 1 von 48
IBM WebSphere MQ Advanced Message Security
----
Erste Schritte-Lab auf z/OS
Inhaltsverzeichnis
Überblick…...............................................................................................................................3
Was für Sie vorbereitet wurde…...............................................................................................5
Allgemeine Anleitung TSO Logon und Einrichten von Mehrfach-Screens ….......................... 7
Übung 1 : Vorbereiten der Host (z/OS) Komponenten ......................................................... 12
1. Starten der AMS Started Tasks ….................................................................................... 12
2. Starten des z/OS Queue Managers …............................................................................. 13
3. Erster Gebrauch des MQ Explorers …............................................................................ 14
Übung 2 : Vorbereitung der Windows Komponenten …........................................................ 16
1. Starten des Windows Queue Managers (via MQ Explorer) …......................................... 16
2. Definieren zusätzlicher Objekte für den Windows Queue Manager …............................. 17
3. Erstellen der z/OS-seitigen Kanalobjekte und Starten der Kanäle …......................…..... 18
Übung 3 : Signierte Nachrichten - “Message Integrity” …..................................................... 20
1. Senden von Nachrichten aus Windows mit Sample Program amqsput …....................... 20
2 Lesen der Nachrichten im Host – Aktivieren der AMS “Integrity” Option …....................… 22
3 Aktivieren der ersten AMS Policy in Windows - signierte Nachrichten ….......................... 25
4 Signatur mit eingeschänkter Urheberschaft …................................................................... 31
Übung 4 : Verschlüsselte Nachrichten - “Message Privacy” …............................................. 35
1 Senden verschlüsselter Nachrichten von Windows nach z/OS …...................................... 35
2 Senden verschlüsselter Nachrichten von z/OS nach Windows …...................................... 43
Anhang: Erstellen und Handhaben der Zertifikate ….......................................................... 47
Seite 2 von 48
----
Überblick
Im Rahmen der hier angebotenen Übungen werden Sie die Gelegenheit haben,
“erste Schritte” mit dem Produkt WebSphere MQ Advanced Message Security
(WMQ AMS) auf z/OS zu unternehmen.
Die Instruktionen bieten Ihnen Anleitung:
•
die WMQ AMS Funktion sowohl auf z/OS als auch in einer WindowsUmgebung zu aktivieren;
•
WMQ AMS Policies für Signatur und Verschlüsselung auf beiden Plattformen
zu erstellen,
•
und deren Auswirkung anhand einfacher Anwendungs-Szenarien praktisch zu
erleben.
Die Übungs-Konfigurations im Überblick
Seite 3 von 48
----
Platzhalter-Sonderzeichen (#, $, %)
Zur Unterscheidung der Ressourcen der einzelnen Übungsteilnehmer sind deren
Namen (Userids, Dataset/ Filenamen etc.) suffiziert, wobei bis zu drei PlatzhalterSonderzeichen verwendet werden.
Diese werden durchgehend in derselben Weise verwendet, und Sie werden sich
leichter tun, wenn Sie die Zuordnung kennen und verstehen:
#
hat den Wert 1...4 und steht für die LPAR, auf der Sie arbeiten
$
ist eine Team-Kennung, entweder “3” oder “4”
%
bezeichnet den einzelnen Benutzer und ist auf “A” festgelegt
Hinweis zur Durchführung der Übungen im Zweier-Team
Generell sind die Übungen so gestaltet, dass sie von einer einzelnen Person
durchgeführt werden können.
Arbeiten im (Zweier-)Team ist durchaus sinnvoll und fördert durch den gegenseitigen
Austausch oft den Lerneffekt- und macht meist auch mehr Spaß … :-)
Falls dem Zweier-Team zwei Terminals zur Verfügung stehen, ist eine sinnvolle
“Arbeitsteilung” möglich, wenn ein Teammitglied die Windows-seitigen Aktivitäten
übernimmt, und das andere die Host (z/OS, TSO-) seitigen.
In diesem Fall würde nur der “Windows-Benutzer” den Queue Manager auf Windows
starten und die Windows-Anwendungsprogramme starten;
nur der “Host-Benutzer” würde eine TSO Session starten und Batch Jobs auslösen.
Der MQ Explorer kann und sollte von beiden Teammitgliedern genutzt werden- wobei
der “Host-Benutzer” dabei jedoch nur den z/OS Queue Manager erreichen kann und
keinen Zugriff zum Windows-Queue Manager des “Windows-Benutzers” hat.
Seite 4 von 48
----
Was für Sie vorbereitet wurde
… auf dem z/OS Host
• Die Workshop-Umgebung besteht aus 4 LPARs, auf denen je zwei Queue
Manager laufen. Die folgenden Namen sind vergeben:
LPAR
Queue Manager
SYS1
MQ13
WBI13A
MQ14
WBI14A
MQ15
WBI15A
MQ23
WBI23A
MQ24
WBI24A
SYS2
SYS3
SYS4
TSO User ID
MQ25
WBI25A
MQ33
WBI33A
MQ34
WBI34A
MQ35
WBI35A
MQ43
WBI43A
MQ44
WBI44A
MQ45
WBI45A
• WebSphere MQ for z/OS ist in der Version 7.1.0 installiert:



Target Libs: MQM.V710.SCSQ*
HFS:
/usr/lpp/mqm/V7R1M0 (HFS)
Zugang zu den ISPF WMQ Panels ist möglich, aber nicht vorgesehen;
Beschreibungen und Anleitungen beziehen sich auf den MQ Explorer.
• WMQ Advanced Message Security for z/OS ist in der Version 7.0.1 installiert


Target Libs: SYS1.MQAMS.V701.SDRQ*
HFS:
/usr/lpp/mqmese/V7R0M1
• die Arbeits-Datei mit den Vorgaben für Ihre Teilnehmer-Aktivitäten finden Sie in

WBI#$A.WMQAMS.CNTL (überwiegend JCL)
•
Weiterhin werden für die Übungen SDSF (Job Output) und evtl. die z/OS Unix
(OMVS) I-Shell verwendet.
•
eine Reihe von X.509 Zertifikaten (mittels RACF erstellt), auf die im Laufe der
Übungen gezielt aufmerksam gemacht wird.
Seite 5 von 48
----
… auf Ihrer Windows Workstation
• Für jeden Übungsteilnehmer bzw. jedes Teilnemerteam wurde eine Windows XP-
Umgebung in Form eines VMWare Images vorbereitet, auf dem folgende
Komponenten vorinstalliert sind:
• WebSphere MQ for Windows (V7.5) ist installiert im Verzeichnis
c:\Program Files\IBM\WMQv75
und enthält als integrierten Bestandteil WebSphere MQ Advanced Message
Security (MQ AMS)
• Eine CMS Keyring Datei mit Namen MQAMSkey.kdb im Verzeichnis
c:\AMSWork
Sie werden durch die Anleitungen darauf hingewiesen, wann und wie diese
Keyring Datei zum Tragen kommt.
• Der WebSphere MQ Explorer ist als Bestandteil von WebSphere MQ V7.5
installiert und startbar von einem Desktop Icon aus:

ein lokaler Windows-Queue Manager mit Namen WINMQ
ist vordefiniert und wird im Rahmen der Übungen
gestartet und mit den nötigen Objekten ausgestattet

die Zugänge zu sämtlichen z/OS Queue Managern sind
vorkoniguriert
• Für den Host-Zugang ist IBM Personal Communications installiert, mit
entsprechend vorkonfigurierten 3270-Sessions
Der Desktop Ordner namens 3270 Links enthält
die “Shortcuts” für die PComm Sessions für die
vier Systeme des TMCC Böblingen ( SYS1 …
SYS4).
Wir empfehlen, das Icon für “Ihr” System auf
den Desktop zu kopieren!
• Der Firefox Browser enthält Bookmarks zu den aktuellen WMQ Information
Center im Netz und ermöglicht Ihnen somit jederzeit das Nachschlagen von z.B.
Kommando Syntax u.ä.
Seite 6 von 48
----
Allgemeine Anleitung
TSO Logon und Einrichten von Mehrfach-Screens
Sie werden sich das Arbeiten im TSO sehr erleichtern, wenn Sie der hier gegebenen
Anleitung folgen und sich für die Dauer der Übungen in Ihrer TSO Session eine
Split-Screen-Konfiguration aufbauen, so dass sie einfach und schnell zwischen
den verschiedenen Stellen, an denen Sie aktiv werden sollen, umschalten können.
Verbinden mit dem System z des TMCC Böblingen
― Durch Doppelklick auf das entsprechende Wildfire-SYS# (#=1...4) Symbol auf
Ihrem Windows Desktop starten Sie die 3270 Session mit dem Host
Der “VTAM Usstab Screen” stellt sich wie folgt dar (Darstellung für SYS3):
― geben Sie an der ursprünglichen Cursorposition, nach dem Pfeil, welches das
einzige Eingabefeld ist, TSO WBI#$A ein (nicht case-sensitiv),
wobei Sie die “#$” Zeichenfolge mit Ihrer ID-Kennung ersetzen, wie oben für
User/Team 33A dargestellt:
― und schließen mit der 3270-Eingabetaste, welches die Strg/Ctrl Taste Ihrer
Workstation ist, ab.
Dies wird Sie zum TSO Logon Screen bringen.
Seite 7 von 48
----
TSO Logon
― Im TSO Logon Screen geben Sie das Ihnen bekannt gegebene Passwort ein,
und betätigen erneut die 3270-Eingabetaste
◦ Ihre TSO Session wird aufgebaut.
●
wenn Sie die folgende Anzeige sehen, betätigen Sie nochmal die 3270Eingabetaste (Strg/Ctrl)
●
… und im folgenden Panel geben Sie an der Eingabestelle (Process Option.....)
eine “2” eine und betätigen abermals die 3270-Eingabetaste (Strg/Ctrl) – zweimal
◦ dies wird Sie zum SYSTEM MASTER APPLICATION MENU bringen.
Seite 8 von 48
----
Herstellen der “splitted screen” Anordnung
1. DSLIST (ISPF Option 3.4) für Edit und Job Submit
— Geben Sie im SYSTEM MASTER APPLICATION MENU als Option “3.4” ein
(ohne Anführungszeichen) ...
— … und im nachfolgenden Data Set List Utility Panel wählen Sie als Dsname
Level WBI#$A.WMQAMS* (wobei Sie anstelle von '#$A' Ihre User-Kennung
angeben), wie hier für WBI33A dargestellt (Groß-/Kleinschreibung muss auch
hier nicht beachtet werden):
Im folgenden Panel können Sie auf Ihre Datasets zugreifen- wir gehen davon
aus, dass Sie ab hier zurecht kommen ..
2. SDSF Screen für Job Output Kontrolle
— Platzieren Sie Im offenen (DSLIST) Screen den Cursor in der obersten Zeile
und drücken Sie entweder die F2 Taste (“Split Screen”) oder tippen Sie
einfach “start” (ohne Anführungszeichen) und drücken die Eingabetaste.
◦ Ein neuer SYSTEM MASTER APPLICATION MENU Screen tut sich auf.
— Wählen Sie hier die “sd” (für SDSF) (ohne Anführungszeichen, nicht casesensitiv)
— und im darauf folgenden SDSF PRIMARY OPTION MENU die Option “st” (für
Status)
◦ .. und Sie werden die laufenden -und später die abgeschlossenenProzesse (Jobs), die Ihr Team betreffen, aufgelistet sehen
◦ Hinweis: es sollte nicht nötig sein, die SDSF Einstellungen zu verändern!
Seite 9 von 48
----
Nun haben Sie die beiden Screens eingerichtet, zwischen denen Sie jederzeit durch
Betätigen der F9 Funktionstaste oder durch Eingabe von “swap 1” bzw “swap 2” an
der jeweiligen “Command Input” Stelle springen können.
Es ist von Vorteil, wenn man sich genau an diese Vorgaben gehalten hat, und
jederzeit klar ist:
•
“swap 1” bringt stets den Screen mit den JCL Vorgaben ==> “CNTL-Screen”
•
“swap 2” stets SDSF für Job Output Kontrolle, und
==> “SDSF-Screen”
In den folgenden Übungsanleitungen werden die entsprechenden Screens dann
ebenso benannt!
Sichtbar-machen der verwendeten Queue Manager im MQ Explorer
1.
2.
Starten Sie den MQ Explorer über das entsprechende Desktop-Icon
•
Warten Sie bis sich -auf der linken Seite des Explorer-Fensters- die Navigator
Ansicht gefüllt hat- das kann einige Momente dauern (vielleicht auch etwas
länger ...
•
Sie werden keine Queue Manager Einträge vorfinden –
alle verfügbaren z/OS Queue Managers sind jedoch vordefiniert, allerdings
verborgen (“hidden”)
Rechts-Klicken Sie den Queue Managers Navigator Eintrag, und wählen Sie
dann Show/Hide Queue Managers .
3. Wählen Sie aus der Liste der Hidden Queue Managers “Ihren” z/OS Qmgr aus,
den mit der (zweistelligen) “Nummer” Ihrer TSO Id, und klicken Sie auf den Show
Button – der Eintrag wird in der zuvor leeren Liste des oberen Panels erscheinen.
Seite 10 von 48
4.
----
Scrollen Sie bis an das Ende der Liste der “Hidden Queue Managers”.
•
dort finden Sie den Eintrag für den lokalen Queue Manager WINMQ. Klicken Sie auch
auf diesen Eintrag und dann wieder auf den Show Button- so dass auch der WINMQ
Eintrag nach oben, in die Darstellung der “Shown Queue Managers” “wandert”.
Für den User 33(A) muss dieser obere Eintrag danach so aussehen:
5.
Klicken Sie jetzt in Show/Hide Queue Managers Dialog auf Close- die beiden
ausgewählten Queue Manager werden jetzt auch in der MQ Explorer Navigator
Ansicht erscheinen;
Sie werden im Fortgang der Übung an entsprechender Stelle zum Starten des
lokalen Queue Managers und zum Starten der Verbindung zum z/OS Queue
Manager aufgefordert werden.
Seite 11 von 48
----
— Übung 1 :
Vorbereiten der Host (z/OS) Komponenten
Starten der AMS Started Tasks und des Queue
Managers in z/OS
Worum es in diesem Übungsteil geht
In diesem kurzen Schritt zu Beginn der WMQ AMS Übungen starten Sie die Hostseitigen Komponenten, als da sind:
• die WMQ AMS Data Services Task
• die WMQ AMS Main Task
• der z/OS Queue Manager
Für alle Adressräume sind die Prozeduren vorbereitet – die nachfolgenden
Instruktionen werden Sie auf einige besonders zu beachtende Vorkommnisse
hinweisen.
Anmerkung für Team-Arbeit:
Bis auf den letzten Teil (Schritt 3.) sind dies reine Host (TSO) Aktivitäten.
Wir gehen davon aus, dass Sie mit Ihrer Team-ID (WBI#$A) in TSO angemeldet
sind, und (möglichst) die Split-Screen-Konfiguration gemäß der Empfehlung auf Seite
9 eingerichtet haben.
1.
Starten der AMS Started Tasks
1.1.
Gehen Sie nach SDSF (“swap 2”) und öffnen Sie dort die STatus Anzeige für
alle aktiven und abgeschlossenen Jobs/Tasks Ihrer Auswahl (Eingabe “st” im
SDSF Command Input Feld).
Stellen Sie sicher, dass die Anzeige-Filter so gesetzt sind, dass diejenigen
Jobs/Prozesse sichtbar sind, welche
- Ihre zweistellige Team-ID im (Job)Namen haben;
- und gleichzeitig unter einem User laufen, der auch diese ID enthält
Für den Beispiel-User WBI33A müssen die Einstellungen also sein:
Prefix=*33*
….
owner=*33*
Falls dem nicht so ist, geben Sie die folgenden Kommandos in der SDSF
Kommandozeile ein- einer nach dem anderen. Die Eingabe ist nicht casesensitiv - '#$' ist mir Ihrer Team-ID zu ersetzen:
◦ pre
◦ owner
*#$*
+#$*
Höchstwahrscheinlich ist die Status-Liste bis auf einen Eintrag für Ihre TSO
Session (den TSO Adressraum) zu diesem Zeitpunkt leer.
Seite 12 von 48
1.2.
----
Starten Sie die WMQ AMS Data Task durch Eingabe von
/S MQ#$AMSD
im SDSF Command Input Feld – wobei Sie die Sonderzeichen (#$) durch den
numerischen Teil Ihrer Team-Kennung ersetzen, also z.B. /S MQ33AMSD
1.3.
Merken Sie sich die in der JobID Spalte erscheinende Kennung “Ihrer” AMSD
Started Task und öffnen Sie das z/OS System Log durch Eingabe von “log”
(ohne Anf'zeichen) im SDSF Command Input Feld.
1.4.
Können Sie im System Log die folgende Nachricht für “Ihre” STC ausmachen:
Diese zeigt an, dass der *AMSD Adressraum erfolgreich gestartet wurde.
1.5.
Starten Sie die WMQ AMS Main Task durch Eingabe von
/S MQ#$AMSM
im SDSF Command Input Feld – wobei Sie die Sonderzeichen (#$) durch den
numerischen Teil Ihrer Team-Kennung ersetzen, also z.B. /S MQ33AMSM
1.6.
Diesmal erkennen Sie die Syslog-Nachrichten “Ihrer” Task an der TeamKennung – wenn alles sauber gelaufen ist, sehen Sie eine Nachrichtenfolge
der folgenden Art:
Beachten Sie die letzte Nachricht: die AMS Task wartet auf “ihren” Queue
Manager.
2.
Starten des z/OS Queue Managers
2.1.
Starten Sie den Queue Manager- ebenfalls von der SDSF Command Input
Leiste. Der Startbefehl lautet (natürlich wieder unter Ersetzen der #$ Zeichen
mit Ihrer Team-ID – nicht case-sensitive):
/+MQ#$ START QMGR
2.2.
Verfolgen Sie das Hochfahren Ihres Queue Managers im z/OS System Log.
Wir gehen davon aus, dass dies schnell vonstatten geht, und Sie die
folgenden Nachrichten für Ihren QMgr zu sehen bekommen:
… und, da der Channel Initiator mit Listener automatisch mit gestartet wird,
auch diese – mit Angabe des Ports, auf welchem Ihr Queue Manager horcht:
Seite 13 von 48
2.3.
----
Suchen Sie im System Log -am besten von hinten, mit dem “find .. prev”
Kommando- nach dem String 'DRQMQ#$' (wobei Sie '#$' natürlich wieder
durch Ihre Team-ID ersetzen.
Sie dürften auf eine Nachricht dieser Art stoßen:
Diese besagt, dass die *AMSM Taks auf die Queue mit den Policies nicht
zugreifen konnte- und das stimmt auch, denn die muss erst noch angelegt
werden!
2.4.
Öffnen Sie im “Edit”-Screen (F9 oder “swap 1”) in Ihrer Arbeits-Library
WBI#$.WMQAMS.CNTL das Member CSQUTIL und submitten Sie den
enthaltenen Job (es sind keine Modifikationen erforderlich).
2.5.
Wechseln Sie wieder nach SDSF und überprüfen Sie den Job Output
(Jobname MQ#$DEF%).
Wir erwarten, dass der Job mit MAXCC=00 läuft und auch das MQ Command
Utility “..... 0 failed” meldet.
◦ Welche Objekte wurden angelegt ? (Auflösung folgt unten)
Um diese Objekte nun auch zu sehen, starten und konfigurieren Sie zum Schluss
dieses ersten Teils den MQ Explorer, um auf Ihren Host Queue Manager
zuzugreifen- diesen Schritt können bei einem Zweier-Team mit separaten
Terminals beide Team-Mitglieder durchführen.
3.
Erster Gebrauch des MQ Explorers
Wir gehen davon aus, dass Sie die Vorbereitung gemäß den Anleitungen auf
Seite 10 durchgeführt haben, und somit “Ihr” Host Queue Manager in der MQ
Explorer Navigationsansicht sichtbar ist.
3.1.
Verbindung zum z/OS Queue Manager starten
Rechts-klicken Sie den zuvor sichtbar gemachten Eintrag Ihres z/OS Queue
Managers, dann Connect anklicken (links)
Dadurch wird eine Client Kanalverbindung zu diesem z/OS Qmgr gestart
Seite 14 von 48
3.2.
----
Falls Sie das folgende Pop-up Fensterchen zu sehen bekommen, klicken Sie
einfach auf Yes – dann wird
die Verbindung aufgebaut (es
ist sehr wahr-scheinlich, dass
der z/OS Queue Manager
irgendwann seit Erstellung des
VMWare Images neu angelegt
worden ist)
Die Verbindung ist hergestellt, wenn das kleine Symbol links vom Queue
Manager Namen die Farbe wechselt (nach gelb) und links davon ein
Pluszeichen erscheint.
3.3.
Klicken Sie auf dieses Pluszeichen, dann können Sie auf die Ressourcen
dieses Queue Managers zugreifen …
Können Sie die vorher per Job angelegten AMS-Systemqueues darstellen ?
Hinweis: wir haben dazu ein Filter vorbereitet- und die Anzeige der
Systemobjekte muss aktiv sein.
Wir erwarten, die folgenden Queues zu
sehen- natürlich enthalten die Queues
zu diesem Zeitpunkt keine Messages:
3.4.
optional- da nicht wirklich notwendig- aber durchaus “interessant”:
Zugriff der AMS Main Task auf die SYSTEM.PROTECTION* Queues
Erinnerung: In Schritt 2.3. hat sich die *AMSM Task ja über die nicht
zugängliche AMS-Konfiguration “beschwert”.
Nachdem die Queues nun da sind, kann man die *AMSM Task zum
neuerlichen Zugriff veranlassen- mit demselben Befehl werden wir später
neue bzw. veränderte Policies aktivieren:
Geben Sie im SDSF Command Input Feld (TSO, “swap 2”) das folgende
Kommando ein (Platzhalter ersetzen):
/F MQ#$AMSM,REFRESH
Dass sich hierbei wirklich etwas tut, ist im Syslog durch die folgenden
Messages sichtbar (Screenshot wieder für MQ33):
Damit ist die z/OS-Seite systemmäßig vorbereitet als zweiten Schritt werden Sie nun die Windows-Seite
entsprechend ausstatten
Seite 15 von 48
—
----
Übung 2 :
Vorbereitung der Windows Komponenten
Starten des Windows Queue Managers; Herstellen und
Testen der z/OS <> Windows Kommunikation
Da wir ja gerne etwas “richtigen”, d.h. Praxis-gerechten Betrieb machen möchten,
sind die Übungen als Cross-Plattform Transfers zwischen Host (z/OS) und
Workstation (Windows) gestaltet.
Dazu benötigen wir aber pro Team bzw. pro Teilnehmer einen Windows-Queue
Manager, der mit dem (vorhandenen) Host Queue Manager kommuniziert.
Wir haben versucht, dafür so viel wie möglich vorzubereiten, weil diese
Aktivitäten ja nicht im eigentlichen Sinne Gegenstand des Workshops sind,
sondern eben notwendig, um die nachfolgenden “echten” Übungen auszuführen.
Daher soll auch dieser Teil möglichst zügig vonstatten gehen- Sorgfalt bei der
Eingabe der Team-spezifischen Namen bzw. Namensteile ist aber (um so mehr)
geboten.
Am Ende dieses Vorbereitungs-Schrittes haben Sie den Windows Queue
Manager mit dem z/OS Queue Manager verbunden und sicher gestellt, dass in
beide Richtungen Messages erfolgreich übertragen werden.
Wenn Sie als Zweier-Team arbeiten, sollte nur das “Windows-Teammitglied” die ersten beiden Schritte durchführen, und das “z/OSTeammitglied” den Schritt 3.
1.
Starten des Windows Queue Managers (via MQ Explorer)
Auch in diesem Übungsteil gelten die Platzhalterzeichen “#” (1...4), “$” (3 oder
4) – gemäß Ihrer TSO User-ID (WBI#$A) wie zuvor.
1.1.
Starten Sie den im Vorbereitungsschritt sichtbar gemachten Windows Queue
Manager WINMQ durch Rechtsklick > Start in der Navigator Ansicht des MQ
Explorers. Bestätigen Sie “Start as created” als Start Methode.
Das kleine Symbol (Icon) vor dem Queue Manager Namen wird sich in Form
und Farbe verändern, und ein Pluszeichen wird erscheinen, wenn der Queue
Manager erfolgreich hochgefahren ist.
Seite 16 von 48
----
1.2.
Verifizieren der WINMQ AMS System Queues
Vergewissern Sie sich, dass die beiden AMS System Queues im WINMQ
Queue Manager existieren- mit demselben Filter wie in Übung 1/ Schritt 3.3.
Wir erwarten, dass die beiden Queues da sind- in WMQ 7.5 gehören die AMS
Systemqueues zur “Standardausstattung” eines Queue Managers.
2.
Definieren zusätzlicher Objekte für den Windows Queue Manager
In diesem Teil werden die Objekte definiert, welche für die Kanalverbindung
mit dem z/OS Queue Manager erforderlich sind, außerdem die Anwendungsqueues für die nachfolgenden AMS Test-Szenarien.
2.1.
Öffnen Sie den Ordner C:\labfiles\AMS durch Doppel-Klick auf das
Desktop-Symbol AMS Labfiles, und starten Sie
darin das Script CreateMQDefs_130.cmd wiederum durch Doppel-Klick auf das
entsprechende Symbol.
Dadurch wird ein Command Fenster geöffnet, in welchem Sie aufgefordert
werden, Ihre 3-stellige Benutzer/Team-ID einzugeben:
2.2.
Geben Sie diese Nummer ein, und schließen Sie mit <Enter> ab.
Der erste Teil des dann startenden Scripts definiert einen Requester- und
einen Senderkanal einschließlich Transmisson Queue, zur Verbindung mit
Ihrem z/OS Queue Manager.
Das Command Fenster zeigt die
ausgeführten Kommandos an,
und fordert Sie zu wie folgt zu
einer Eingabe auf:
2.3.
“Press any key ...” - … dadurch wird der zweite Teil des Kommando-Scripts
gestartet, welches insgesamt sechs Queue Definitionen erstellt:
◦ drei lokale Queues mit Namen AMS.WIN.Q1, -Q2, -Q3
◦ drei Remote Queue Definitionen mit Namen AMS.HOST.Q1, -Q2, -Q3,
welche auf ebenso benamste Queues im z/OS Queue Manager verweisen
Wiederum werden die ausgeführten Kommandos angezeigt;
und die erfolgreiche Durchführung
des Scripts stellt sich wie folgt
dar:
Seite 17 von 48
----
2.4.
Press any key … (nochmals)
dadurch wird das Script beendet und das Command Fenster schließt sich.
2.5.
Stellen Sie die definierten Objekte im MQ Explorer dar- für Ihren Windows
Queue Manager.
Verwenden Sie für die Queues das Standard for Queues Filter, wobei Sie die
Show System Objects Option deaktivieren (so dass die Systemobjekte nicht
dargestellt werden).
Die Anzeige sollte wie folgt aussehen:
2.6.
Schauen Sie sich entsprechend auch die Kanäle des WINQM an.
Wir erwarten diese Anzeige als Ergebnis:
3.
Erstellen der z/OS-seitigen Kanalobjekte und Starten der Kanäle
3.1.
Öffnen (editieren) Sie im TSO (“swap 1”) das Member OBJDEFS in Ihrer
<TSO-id>.WMQAMS.CNTL Library.
◦ dieser Job definiert für Ihren Host-QMgr den Server- und Receiver-Kanal
als “Gegenstücke” zu den Kanälen auf Seiten des Windows Queue
Managers, und ebenso die lokalen und remote Queues.
◦ JCL und Definitions-Input sind komplett, sofern Sie sich auf der WindowsSeite an alle Namens-Vorgaben gehalten haben (ansonsten haben wir hier
ein kleines Problem …)
Submitten Sie den Job, mit welchem diese DEFINE Commands gegen Ihren
Queue Manager ausgeführt werden.
Wir erwarten, dass dieser Job sehr kurz läuft und mit RC=0 endet.
3.2.
Überprüfen Sie den Job Ouput in SDSF (Jobname ist MQ#$OBJ%).
Am Ende des Job Listings muss die folgende Nachricht erscheinen:
CSQU058I
9 commands issued and responses received, 0 failed
Seite 18 von 48
----
Falls Sie als Zweierteam mit verteilten Rollen arbeiten, ist diese letzte
Aktion ist nun vom “Windows-User” durchzuführen :
3.3.
Starten Sie nun die beiden Kanäle- Sender und Requester- manuell über den
MQ Explorer, aus dem Windows Queue Mgr heraus.
Wir erwarten, dass sich beide Kanäle starten lassen und in kurzer Zeit den
“Running” Status annehmen:
Der z/OS Benutzer “darf” natürlich das Anlaufen der Kanäle auf der z/OS
Seite im (sdsf) System Log und/oder seinem/ihrem MQ Explorer nachvollziehen.
Damit ist die Cross-Plattform “Konnektivität” auf Systemebene hergestellt;
nun kann der Anwendungs-Betrieb losgehen!
Seite 19 von 48
----
— Übung 3 :
Signierte Nachrichten - “Message Integrity”
Sie werden testweise Nachrichten (Messages) von Windows zum Host schicken,
und zunächst feststellen, welchen Effekt das Aktivieren einer WMQ AMS
Protection Policy hat.
Wir beginnen hier mit der einfachsten AMS Option: dem (sende-seitigen)
Signieren von Nachrichten.
Die Signatur
- kennzeichnet den Urheber der Nachricht eindeutig, und
- gewährleistet die inhaltliche Unversehrtheit der Nachricht.
Daher steht dafür auch der Begriff “Message Integrity”
Hinweis zum “Team-Working” :
In den folgenden Übungsteilen, in denen nun wirklich die AMS Funktionen anhand
einfacher Beispiel-Szenarien durchgespielt werden, lässt sich die vorgeschlagene
Aufgabenteilung gut praktizieren- ein Teammitglied “bedient” die Windows-Seite, das
andere die z/OS-Seite.
Wir verzichten im Weiteren auf entsprechende Hinweise innerhalb der Anleitungen.
1.
Senden von Nachrichten aus Windows mit Sample Program amqsput
1.1.
Auf Ihrem Windows Desktop ist wahrscheinlich der Ordner labfiles\AMS noch
offen- wenn nicht, öffnen Sie diesen (siehe Schritt 2.1. auf Seite 17) und darin
wiederum klicken Sie auf den Shortcut zum Ordner (c:\) AMSWork.
Hinweis: Dieser Ordner ist hier
platziert, um Ihnen in den
nachfolgenden Übungen das lästige
Tippen von langen Pfaden zu ersparen.
1.2.
In diesem Ordner öffnen Sie den Command Prompt Cmd-Alice.
Ein Command Fenster öffnet sich und zeigt die Ausführung der folgenden
Kommandos:
… an dieser Stelle müssen wir die spezielle Methode erläutern, mit welcher
wir gegenüber WMQ AMS das “Umschalten” zwischen verschiedenen
(Windows) Benutzern simulieren
Seite 20 von 48
1.3.
----
Öffnen Sie (per Doppelklick) die Keystore File (keystoreA.conf), die im
eben ausgeführten SET MQS_KEYSTORE Kommando angezogen wurde- sie
befindet sich ebenfalls im c:\AMSWork Verzeichnis.
Notepad wird den Dateiinhalt wie folgt anzeigen (bitte nichts ändern!)
Wichtiger Hinweis:
Gemäß den Regeln der WMQ AMS Konfiguration bezeichnet die System
(Umgebungs-)Variable MQS_KEYSTORE die Keystore-Konfigurationsdatei für
den aktiven Benutzer bzw. die aktive Session. Die Einträge in der Datei
bezeichnen die Keystore File selbst und das Label des zu verwendenden
Zertifikats, welches in dieser Keystore File enthalten sein muss.
Wir haben für verschiedenen fiktive Benutzer – Alice, Bob und Carlentsprechende Zertifikate hinterlegt. Der SET MQS_KEYSTORE Befehl, wie er
angezeigt und ausgeführt wurde, aktiviert für diese Command Session also
das “Alice” Zertifikat.
Dies ist somit eine einfache Methode, um in Verbindung mit WMQ AMS
unterschiedliche Benutzer zu simulieren
In einer realen Betriebsumgebung darf der Benutzer natürlich seine
MQS_KEYSTORE Variable nicht setzen dürfen bzw. auf keinen Fall darf er/sie
berechtigt sein, den Inhalt der Konfigurationsdatei zu verändern !
1.4.
Starten Sie nun in diesem “Cmd-Alice” Fenster das WMQ Beispiel-Program
amqsput, um Nachrichten auf die (remote) Queue AMS.HOST.Q1 zu
schreiben.
Machen Sie die folgenden Eingabe, und schließen Sie mit <Enter> ab:
amqsput AMS.HOST.Q1
Hinweis: Da Ihr Windows QMgr als Default Queue Manager aufgesetzt ist,
brauchen Sie den QMgr Namen nicht anzugeben.
Wenn Sie die folgende Anzeige sehen, ist das Programm angelaufen und hat
bereits erfolgreich ein OPEN auf die Queue gemacht, und erwartet die
Eingabe Ihrer Nachricht(en).
1.5.
Geben Sie 5 (fünf) kurze Text-Nachrichten ein (sorry- ein bisschen Tippen
muss jetzt eben sein ...), wobei Sie folgende Hinweise beachten:
Seite 21 von 48
◦
◦
◦
◦
----
“Alice” sollte in jeder Nachricht erscheinen;
versehen Sie jede Nachricht mit einer “laufenden Nummer” (1...5);
jede Nachricht wird durch die Enter/Eingabetaste abgeschlossen;
durch zweifaches Drücken von Enter/Eingabe beenden Sie das
Programm .
Ihre komplette Eingabe könnte z.B. so aussehen:
Das Cmd-Alice Fenster NICHT schließen !
1.6.
Wir erwarten, dass die Nachrichten sofort übertragen werden und auf der ZielQueue des z/OS Queue Managers zu sehen sind, wie nachfolgend gezeigtprüfen Sie dies nach!
1.7.
Optional:
Wenn Sie möchten, können Sie die Browse Messages Funktion des MQ
Explorers nutzen, um die Nachrichten auf der Queue anzuschauen.
Wir erwarten, dass die Nachrichten “ganz normal” aussehen, Sie also Ihre
eigegebenen Texte im Klartext zu sehen bekommen, sogar schon in der
“Message browser” Übersichts-Darstellung.
2
Lesen der Nachrichten im Host – Aktivieren der AMS “Integrity” Option
2.1
Lesen (MQGET) einer Nachricht per Batch
2.1.1
Öffnen Sie in Ihrem TSO-”Edit Screen” (“swap 1”) das Member JCLGET in
Ihrer *.WMQAMS.CNTL Library.
Diese JCL startet das z/OS Batch-Beispiel-Leseprogramm, und die Parameter
sind so eingerichtet, dass genau eine Nachricht von der Queue
AMS.HOST.Q1 (destruktiv) gelesen wird.
2.1.2 Submitten Sie den Job und wechseln Sie zum SDSF-Screen (“swap 2”) zur
Kontrolle des Job Output Listings.
Seite 22 von 48
----
Wir erwarten, dass die erste Nachricht erfolgreich gelesen wurde und Sie am
Ende des Listings dieses Protokoll zu sehen bekommen (natürlich mit dem
von Ihnen eingegebenen Nachrichtentext):
2.2
Aktivieren der ersten WMQ AMS Policy.
2.2.1
Wechseln Sie wieder zum ”Edit” Screen und öffnen Sie in der CNTL Library
das Member DRQUTIL .
Diese JCL startet das AMS für z/OS DRQUTIL Utility Programm.
Die JCL ist für die erste Ausführung komplett vorkonfiguriert, einschließlich
des WMQ AMS Kommandos in der SYSIN DD Sektion, mit welchem für die
Queue AMS.HOST.Q1 “Message Integrity” aktiviert wird, d.h. es wird
gefordert, dass alle Nachrichten dieser Queue signiert sind.
▪
▪
als (einfachster) Signatur-Algorithmus wird MD5 spezifiziert.
mit dem dspmqspl Kommando werden jeweils alle bestehenden AMS
Policies für den jeweiligen Queue Manager angelistet.
2.2.2 Submitten Sie den Job und überprüfen Sie die saubere Ausführung des Jobs
wieder via SDSF (“swap 2”)
Wir erwarten, dass der Job mit CC=00 läuft und die neu angelegte Policy
aufgrund des enthaltenen Display Befehls (dspmqspl) wie folgt im Job Listing
angezeigt wird:
2.2.3 Ändert dies etwas für lesende Anwendungen ?
Submitten Sie den JCLGET (MQ#$GET%) Job erneut, um eine weitere
Nachricht von der *.Q1 zu lesen, und überprüfen Sie den Job Output.
Wir erwarten, dass dieser Job genau gleich läuft wie der vorherige, und die
zweite Nachricht im Listing auch angezeigt wird:
Wie das ?
Erklärung: die Policy muss gezielt aktiviert werden, damit sie wirksam
wird- dies gilt für jede Änderung von WMQ AMS Policies auf z/OS.
Seite 23 von 48
2.3
----
Aktivierung der Policy-Änderung
2.3.1 Geben Sie an der SDSF Command Input Zeile das folgende Kommando ein
(wobei Sie '#$' natürlich wieder durch Ihre Kennung ersetzen):
/F MQ#$AMSM,REFRESH
Wir erwarten, dass die Eingabe mit der folgenden Anzeige “beantwortet” wird
(wieder für User/Team “33”)
RESPONSE=SYS3
DRQZS0304I (DRQMQ33) Modify REFRESH
command accepted.
2.3.2 Wechseln Sie jetzt wieder zum CNTL-Screen (“swap 1”) und submitten Sie
den JCLGET (MQ#$GET%) Job erneut, um eine weitere Nachricht von der
*.Q1 zu lesen.
Wir erwarten nun ein anderes Ergebnis als zuvor, nämlich
2.3.3 Überprüfen Sie den Job Output in SDSF.
Beachten Sie diese Meldungen zu Beginn (ganz oben) im Job Listing:
DRQZS0224E (WBI33A) Message verification error from queue
AMS.HOST.Q1, message length of 00000019 too small.
DRQZS0209I (WBI33A) Message for AMS.HOST.Q1 sent to error
queue SYSTEM.PROTECTION.ERROR.QUEUE, reason
◦ ferner zeigt das Anwendungsprotokoll, dass die Message von der Queue
nicht an das Lese-Programm ausgeliefert wurde:
Diese Messages zeigen eindeutig: “AMS hat zugeschlagen!”
Erklärung dieses Verhaltens
◦ Die aktivierte AMS Policy für die Queue AMS.HOST.Q1 fordert, dass alle
Nachrichten dieser Queue signiert werden müssen.
◦ Die auf der Queue befindlichen Nachrichten sind nicht signiert
Daher werden sie vom WMQ AMS Interceptor als “unzulässig” erkannt.
◦ Für die lesende (Batch) Anwendung geht der MQGET Call mit
MQRC=2063 schief.
Tatsächlich ist die Nachricht aber bereits von der Queue entfernt wordenund so wird sie von der AMS Komponente in die
SYSTEM.PROTECTION.ERROR.QUEUE verschoben.
Seite 24 von 48
----
Noch ein Detail, welches an dieser Stelle nicht unbedingt offensichtlich ist:
◦ Für Ihre TSO UserID, unter der Ihr JCLGET Job lief, ist beim Zugriff
(MQOPEN) auf die AMS-geschützte Queue ein Keyring und ein gültiges
“persönliches” Zertifikat ermittelt worden.
Wäre das nicht so gewesen, wäre bereits der MQOPEN Call schief
gegangen.
Folgerung:
◦ Wenn die “Server”/”Consumer” Seite eine Signatur für Nachrichten einer
Queue anfrodert, muss dies -natürlich- auf der Sende/Ursprungs-Seite
bekannt sein und eine entpsrechende AMS Policy muss für die
sendenden Anwendungen bzw. deren Umgebungen aktiviert sein.
2.3.4 Entfernen der “ungültigen” Messages
Da sich die verbleibenden (2) Nachrichten auf der Queue ja offensichtlich
nicht mehr regulär lesen lassen:
Submitten Sie den JCLGET (MQ#$GET%) Job noch zwei weitere Male, um
die Queue zu leeren (wobei wir wissen, dass die Nachrichten in die AMS Error
Queue verschoben werden).
Hinweis: Um ganz sicher zu gehen, dass keine Nachrichten mehr auf der
Queue stehen, können Sie den Job auch so oft laufen lassen, bis Sie den
MAXCC=2033 (“Queue empty”) zu sehen bekommen.
3
Aktivieren der ersten AMS Policy in Windows - signierte Nachrichten
Gute Nachricht: für die verteilten Plattformen können die WMQ AMS Policies
mit der GUI Oberfläche des MQ Explorer gepflegt werden!
3.1
Definieren der Policy für “Message Integrity”
3.1.1
Rechts-Klicken Sie auf das Security Policies Symbol für Ihren Windows QMgr,
und wählen Sie dann New > Security Policy
3.1.2
Anzulegen ist eine Policy für die Queue AMS.HOST.Q1 - “good practice” ist
es, diesen Namen nicht einzutippen, sondern im folgenden Panel aus der
angezeigten Auswahl von (Queue-)Namen auszuwählen- damit werden
Tippfehler zuverlässig vermieden.
Seite 25 von 48
----
Die AMS.HOST.Q1 wird
wahrscheinlich die
erste/oberste in der
Auswahlliste sein.
3.1.3
Behalten Sie die voreingestellten Optionen “Sign”
und “Apply this … to all
messages” bei,
und klicken Sie dann auf
Next .
3.1.4
Wählen Sie im nächsten Panel MD5 als den zu verwendenden SignaturAlgorithmus;
- und lassen Sie die voreingestellte Auswahl “Accept … from any originator”
aktiv;
- klicken Sie dann wiederum Next ,
so dass die “Summary” Anzeige
Ihre Eingabe wie folgt darstellt:
3.1.5
Schließen Sie jetzt mit Finish ab, und stellen Sie sicher, dass die neu
angelegt Policy im MQ Explorer nun so aussieht:
Hinweis: auf den verteilten Plattformen sind die Policies durch das Anlegen
(bzw. Ändern) sofort aktiv; es bedarf keines separaten “Refreshs”.
3.2
Senden von signierten Nachrichen
3.2.1
Kehren Sie zum Cmd-Alice Windows Command Fenster zurück (das dürfte
von zuvor noch offen sein- wenn nicht, wiederholen Sie die Aktivität in Schritt
1.2.).
Wiederholen Sie nun den Programmaufruf vom Schritt 1.4.).
amqsput AMS.HOST.Q1
Hinweis: Mit der Pfeil-nach-oben-Taste” können Sie den letzten Befehl wieder
zurück holen, so dass Sie überflüssiges Tippen vermeiden können.
Seite 26 von 48
----
Wir erwarten, dass das Ergebnis für Sie genau gleich aussieht wie beim
ersten Mal, die Anwendung also Ihre Eingaben erwartet
3.2.2 Geben Sie nun wieder -wie zuvor- drei kurze Textnachrichten- mit “Urheber”
und Nummern-Kennung- ein, entsprechend dem Schritt 1.5. auf Seite 21, also
z.B. so:
Hinweis: die “Retrieve” Funktion mit der “Pfeil-nach-oben” Taste funktioniert
auch für die Eingaben; Sie brauchen dann nur noch die laufende Nummer zu
ändern.
Denken Sie daran, am Ende zweimal <Eingabe / Enter> zu drücken, um die
Anwendung zu beenden.
Cmd-Alice Command Fenster offen lassen - nicht schließen !
3.2.3 Überprüfen Sie, ob die Nachrichten auf der Ziel-Queue -im z/OS Queue
Manager!- angekommen sind; ggf. ist der Sender-Kanal Ihres Windows-QMgrs
neu zu starten (sollte eigentlich noch laufen … )
Die “current queue depth” der AMS.HOST.Q1 sollte “3” anzeigen.
3.2.4
Versuchen Sie, die Nachrichten auf der Ziel-Queue AMS.HOST.Q1 mit der
MQ Explorer Browse Messages Funktion anzuschauen.
Das sollte funktionieren- aber Sie sollten etwas “Besonderes” zu sehen
bekommen:
◦ die Nachrichten sind erheblich länger als Ihre Text-Eingabe und sie
beginnen alle mit “PDMQ...”
Überrascht ? - beides ist Folge der aktvierten AMS Policy:
◦ Die Nachrichten sind um die “Alice” Signatur und das “AMS Envelope”
erweitert worden, daher sind sie größer geworden.
◦
“PDMQ” ist der “Eye-Catcher” des AMS Headers (vom Vorgänger-Produkt
“geerbt”)
Seite 27 von 48
----
3.2.5 Doppel-Klicken Sie auf das erste (gelbe) Umschlags-Symbol in der Position
Spalte- damit greifen Sie auf die erste Nachricht inhaltlich zu;
- Klicken Sie auf die unterste Auswahl (Data) und bewegen Sie den unteren
Balken im Message data bytes Bereich ganz nach rechtsm so dass Sie die
Zeichen-mäßige Darstellung des Nachrichteninhaltes sehen können.
- Sie sollten
die lesbaren
Teile des
AliceZertifikats
identifizieren
können,
UND auch
die TextNachricht,
die Sie zuvor
eingegeben
haben (wie
hier links
gezeigt)
3.2.6 Für diejenigen, die sich jetzt fragen:
“Wie kann es sein, dass wir diese -AMS geschützte- Nachricht so ohne
Weiteres mit dem MQ Explorer abgreifen und darstellen können ?”
Antwort: Der MQ Explorer ist eine Java Client Anwendung, die via MQI
Server-Connection Kanal mit dem z/OS Queue Manager verbunden ist.
Mit den aktuellen Softwareständen (WMQ V7.5 auf Windows und V7.1 auf
z/OS, und WMQ AMS V7.0.1 auf z/OS) werden Zugriffe auf die Host-Queues
mittels Java Client nicht von WMQ AMS abgefangen, d.h. AMS “greift” hier
nicht.
Dies ist eine bekannte und dokumentierte Restriktion von WMQ (AMS) V7.5:
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg27027476
Abhilfe ist versprochen ...
3.2.7 Beenden Sie die MQ Explorer Browse Messages Funktion.
3.3
Lesen der signierten Nachrichten
3.3.1 Versuchen Sie, eine Nachricht von der AMS.HOST.Q1 zu lesen, indem Sie –
wie zuvor – die JCL im Member JCLGET Ihrer *.CNTL Library submitten.
Wir erwarten, dass der Job schnell und mit CC=00 zu Ende kommt.
3.3.2 Überprüfen Sie den Job Output in SDSF (“swap 2”).
Hier sollte sich bestätigen, dass alles glatt gelaufen ist: die erste von Ihnen im
Schritt 3.2.2 eingegebene Textnachricht erscheint im Leseprotokoll des
Batch-Programms- in unserem Fall sieht das so aus:
Seite 28 von 48
----
… und von AMS merken wir in diesem Fall nichts- und so soll's auch sein:
“transparent to the application”.
3.4
Senden (Schreiben) von Nachrichten mit veränderten Identitäten
3.4.1 Starten Sie im (wahrscheinlich noch offenen) (c:\)AMSWork-Ordner in
Windows das Command Fenster Cmd-Bob durch Doppelklick auf das
entsprechende Symbol.
Es wird sich gleich verhalten wie das “Alice” Fenster zuvor: eine bestimmte
Keystore Konfigurationsdatei wird bezeichnet, und über diese wird für die
Aktivitäten in diesem Fenster das “Bob” Zertifikat wirksam.
3.4.2 Wiederholen Sie dies mit dem Command Fenster Symbol für Cmd-Carl und öffnen Sie somit ein drittes Windows Command Fenster.
Sie haben nun drei Command Fenster offen (cmd-Alice, cmd-Bob und cmd-Carl), in
denen die AMS Umgebungsvariable für die Keystore Konfig.-Datei so gesetzt ist,
dass jeweils das Zertifikat für “Alice”, “Bob” bzw. “Carl” herangezogen wird.
***
Lassen Sie diese Command Fenster geöffnet!
***
3.4.3 Schreiben Sie nun in den beiden “Bob” und “Carl” Command Fenstern jeweils
eine Nachricht- in derselben Art wie zuvor (Schritt 3.2.2 )- Starten des
Beispiel-Programms mittels Eingabe von
amqsput AMS.HOST.Q1
und anschließendem Schreiben je einer Textnachricht, möglichst mit
“Absender-Kennung und “laufender Nummer”, etwa so:
3.4.4
Stellen Sie sicher, dass die Nachrichten auf der Host Ziel-Queue
AMS.HOST.Q1 angekommen sind.
Wenn Sie streng den Anleitungen gefolgt sind, stehen jetzt vier (4)
Nachrichten auf der Queue.
3.4.5
Optional: Wenn Sie möchten, können Sie wieder mit dem MQ Explorer “in die
Nachrichten hineinschauen”- um festzustellen, dass die ersten beiden von
“Alice” stammen, die dritte von “Bob” und die vierte von “Carl”.
Seite 29 von 48
----
3.5
Lesen der signierten Nachrichten
3.5.1
Öffnen/Editieren Sie in Ihrer TSO CNTL-Session das Member JCLGET und
ändern Sie den “Lesezähler” in Zeile 000100 auf (mindestens) 4, wie hier
dargestellt:
3.5.2 Submitten Sie nun den Job erneut und schauen Sie das Job Output Listing in
SDSF an.
Wir erwarten, dass alle Nachrichten gelesen worden sind und im Leseprotokoll
des Batch-Programms aufgelistet erscheinen – etwa wie folgt:
Ein wichtiger Hinweis an dieser Stelle:
Signierte Nachrichten können nur dann an eine lesende Anwendung ausgeliefert
werden, wenn die Validierung der Signaturen erfolgreich ist.
Dazu muss jeweils die “Cerificate Authority”, von welcher die Signatur stammt,
auf der Empfangsseite bekannt sein.
Technisch bedeutet dies, dass (zumindest) der öffentliche Teil des SignerZertifikats im Zielsystem vorhanden und zum AMS-Keyring (drq.ams.keyring)
der User ID connected sein muss, unter welcher die WMQ AMS Data Service
Started Task (*AMSD) läuft.
Für diese Übung sind auch die Zertifikate der Windows-User “Alice”, “Bob” und
“Carl” unter RACF mit demselben Root CA Zertifikat signiert worden wir die
persönlichen Zertifikate der TSO User IDs – das CA Zertifikat trägt das Label
“MQAMS_CA” - siehe die RACF Command Syntax im Anhang dieses Dokuments.
Diese Zuordnung lässt sich RACF-seitig so darstellen:
Seite 30 von 48
4
----
Signatur mit eingeschänkter Urheberschaft
Vorbemerkung:
Die “nächste Stufe” der WMQ AMS Security Funktion ist die, dass für eine
Queue nicht nur die Signatur an sich gefordert wird, sondern gleichzeitig über
eine “List of authorized Authors” festgelegt werden kann, wer als Urheber
(Autor) einer Nachricht akzeptiert wird.
Dafür nutzen wir nun die zweite Host-Queue (AMS.HOST.Q2)- ansonsten
verwenden Sie die bereits bekannten Mimiken, so dass die Durchführung der
Übung leicht von der Hand gehen sollte.
4.1
Erstellen der zweiten AMS Policy im Host.
4.1.1
Öffnen Sie im TSO ”Cntl” Screen (“swap 1”) in Ihrer CNTL Library das
Member DRQUTIL .
▪
Kopieren Sie den kompletten setmqspl Befehl (3 Zeilen) des //SYSIN2
Bereichs in den //SYSIN DD * Bereich, wo die auszuführenden
Kommandos stehen müssen
▪
den vorhandenen setmqspl Befehl im //SYSIN DD Bereich können Sie
stehen lassen oder auch entfernen; behalten Sie aber auf jeden Fall den
dspmqspl (Display) Befehl als letzten bei!
Hinweis:
Diese Policy bewirkt, dass nur Nachrichten mit der Signatur von (entweder)
“Alice” oder “Carl” von dieser Queue ausgeliefert werden.
Die “Identitäten” müssen dabei mit ihrem vollen “Subject Distinguished Name”
(subject DN) beschrieben werden, wie dieser im Zertifikat erscheint.
Die bereitgestellten Strings entsprechen exakt den benutzten Zertifikaten- nur
so funktioniert es … - und deswegen sind sie hier als Kopiervorlage
angeboten, so dass sie nichts ”tippen” müssen.
4.1.2 optional durchzuführen – sonst eine weitere Information:
Wenn Sie das IBM Key Management Tool kennen, das mit
WMQ auf Windows mitkommt, können Sie damit die
Windows User Zertifikate zugreifen und z.B. die besagten
“distinguished name” Strukturen nachschauen.
- das Tool können Sie über die Windows Start Liste starten;
- die Key DB ist c:\AMSwork\MQAMSkey.kdb
- das Passwort ist “mqams”
Der “subject DN” Teil des
“Alice” Zertifikats wird
wie folgt aussehen:
- dies entspricht genau
dem String für die AMS
Policy
Seite 31 von 48
----
4.1.3 Submitten Sie die DRQUTIL JCL und überprüfen Sie den Job Output mit
SDSF.
Wir erwarten, dass der Job mit CC=00 läuft und die neu angelegte Policy
aufgrund des enthaltenen Display Befehls (dspmqspl) nun zusammen mit der
bereits vorhandenen wie folgt im Job Listing angezeigt wird:
4.2
Aktivieren der Policy-Änderung …
… mit dem bereits bekannten Kommando als SDSF Command (natürlich sind
die Sonderzeichen wieder durch Ihre Kennung ersetzen):
/F MQ#$AMSM,REFRESH
Das unmittelbare Ergebnis sollte gleich aussehen wie zuvor (im Schritt 2.3.1):
DRQZS0304I (DRQMQ33) Modify REFRESH command accepted.
4.3
Definieren der AMS.HOST.Q2 Policy in Windows
4.3.1
Erstellen Sie mit dem WMQ Explorer eine zweite AMS Policy für die
AMS.HOST.Q2 (Remote) Queue Definition Ihres Windows Queue Manager,
wobei Sie dem Vorgehen für die erste Queue Schritt für Schritt folgen könnensiehe Schritte 3.1.1 bis 3.1.5 auf Seite 25 / 26.
◦ Diese Policy wird also genau gleich aussehen wir die erste
Das ist deswegen so, weil die “List of authorized authors” nur lese-seitigim Ziel-System- geprüft wird; auf der Sende/Schreib-Seite ist sie nicht
schädlich, aber ohne Effekt.
Daher genügt es für unsere Übung, in der Windows Umgebung auch für
die **Q2 Queue einfach nur die Signatur zu fordern, genauso wie für die
**Q1 Queue zuvor.
4.3.2
Stellen Sie sicher, dass die Security Policies des Windows Queue Managers
danach im MQ Explorer wie folgt aussehen:
4.4
Senden von Nachrichten aus Windows
Wir gehen davon aus , dass die drei Command Fenster für “Alice”, “Bob” und
“Carl” in Ihrem Windows Image immer noch aktiv/offen sind.
4.4.1 Lösen Sie nun in jedem der drei Fenster das amqsput Beispielprogramm
nochmals aus, um jeweils EINE Nachricht auf die Queue AMS.HOST.Q2 zu
scheiben
Seite 32 von 48
----
▪
und zwar in der Reihenfolge (1) Alice” - (2) Bob” - (3) Carl
▪
kennzeichnen Sie wieder den “Urheber” in der Nachricht – wie z.B. unten
für “Carl” dargestellt:
Hinweis: die amqsput Syntax kann per “Pfeil-nach-oben”-Taste in den
Command Fenstern wieder aufgerufen werden- Sie brauchen dann nur
den Queue Namen von *.Q1 nach *.Q2 zu verändern.
4.4.2 Vergewissern Sie sich, dass die Nachrichten auf der Ziel-Queue im Host
angekommen sind- es sollten jetzt drei Nachrichten auf der AMS.HOST.Q2
Queue stehen.
4.4.3 Optional- kennen Sie schon:
Wenn Sie möchten, können Sie die Nachrichten über die Browse Messages
Funktion des MQ Explorers anschauen- siehe Seite 27 (Schritt 3.2.4).
4.5
Lesen der Nachrichten z/OS-seitig
4.5.1 Öffnen (editieren) Sie wiederum das JCLGET Member Ihrer CNTL Library in
TSO, und ändern Sie die Angaben im PARM String (Zeile 000100) wie folgt:
◦ Ändern Sie den Queue Name (2. Parameter) nach AMS.HOST.Q2
◦ Ändern Sie den “Lese-Zähler” (3. Parameter) nach 0003
4.5.2 Submitten Sie den Job – was passiert ?
Wir erwarten, dass der Job mit CC=2063 endet – warum ?
4.5.3 Wechseln Sie (“swap”) nach SDSF, um das Job Output Listing anzusehenhier sollten wir erkennen, was genau geschehen ist.
Beachten Sie die folgenden Messages:
◦ Zu Beginn des Listings (4.Zeile) erscheint eine WMQ AMS System
Message:
DRQZS0209I (WBI33A) Message for AMS.HOST.Q2 sent to
error queue SYSTEM.PROTECTION.ERROR.QUEUE, reason 2063.
◦ Am Ende des Listings finden Sie (wie zuvor) das Protokoll der lesenden
Anwendung:
4.5.4 Überprüfen Sie, wieviele Nachrichten aktuell auf der AMS.HOST.Q2 Queue
drauf sind.
Wir erwarten, dass eine (1) Nachricht auf der Queue verblieben ist.
Seite 33 von 48
----
4.5.5 Können Sie (selbst) erklären, was geschehen ist und warum ?
Für alle Fälle- hier die Erklärung:
◦ Die erste Nachricht (von Alice) wurde regulär ausgeliefert
◦ Die zweite Nachricht (von Bob) wurde von AMS als eine erkannt, die
gegen die Security Policy verstößt, weil Bob kein “authorized author” ist.
Die “Bob-Nachricht” wurde also von der Queue entfernt, aber nicht an das
JCLGET-Programm ausgeliefert, sondern auf die AMS Error Queue
verschoben- begleitet vom MQRC=2063
◦ Das JCLGET Beispiel Programm ist so gestaltet, dass es nach jedem
Return Code ungleich “0” (MQRC_OK) terminiert, und somit wurde die
dritte Nachricht (von Carl) nicht angefasst und blieb auf der Queue stehen.
4.5.6 Submitten Sie den JCLGET Job erneut.
Er wird jetzt mit MAXCC (MQRC)=2033 enden – was bedeutet, dass die
Queue leer gelesen wurde.
4.5.7 Wechseln Sie nochmals nach SDSF und sehen Sie sich den Job Output
dieses Laufs an- Sie können direkt ans Ende des Listings springen.
Sie werden etwas in dieser Art sehen:
4.5.8 Sind Sie mit diesem Ergebnis “zufrieden” - Sie sollten es sein …
Nur wieder “für alle Fälle”- hier die Erklärung:
◦ die letzte verbliebene Nachricht auf der Queue – von Carl – konnte regulär
verarbeitet, d.h. gelesen werden, da Carl zu den “authorized authors”
gehört.
◦ Da die Parameter für das Leseprogramm so eingestellt waren, dass (bis
zu) drei Nachrichten gelesen werden sollten, hat das Programm nach dem
erfolgreichen Lesen dieser Nachricht einen weiteren MQGET Zugriff
versucht- und dieser brachte als Ergebnis die “Queue leer” Bedingung
( MQRC=2033) - was nichts mit AMS Security zu tun hat(te).
Seite 34 von 48
----
— Übung 4 :
Verschlüsselte Nachrichten - “Message Privacy”
… die Verschlüsselung von Nachrichten (Messages), um die Nutzdaten nur
bestimmten, im Voraus bezeichneten Benutzern zugänglich zu machen.
Auf der Sende- und Empfangsseite müssen die Verschlüsselungs-Option an sich
und die verwendete Verschlüsselungsmethode (Algorithmus) spezifiziert werden.
Die Liste der potentiellen Empfänger, für welche die Verschlüsselung
durchgeführt werden soll, muss streng genommen nur auf der Policy der
Sendeseite hinterlegt werden- empfangsseitig “ergibt” es sich, dass die
Entschlüsselung nur für diese Benutzer (Identitäten) möglich ist und somit nur
diese in der Lage sind, die Nachrichten von der Ziel-Queue zu lesen und sie zu
verarbeiten.
Es werden zwei Übungen angeboten- Sie werden u.U. in der verfügbaren Zeit
nur eine davon durchführen können, daher etwas Information dazu vorab:
• als erstes dürfen Sie versuchen, wie gehabt, Nachrichten von Windows zum
Host zu verschicken.
Es werden zusätzliche Maßnahmen erforderlich sein, damit dies funktioniert.
• in der zweiten Übung sind die Rollen der Benutzer umgedreht: “Alice”,”Bob”
und “Carl” sind nicht Absender/Urheber, sondern nun Empfänger der
Nachrichten- d.h. der Nachrichtenfluss ist z/OS
Windows.
Die beiden Übungsteile (1. und 2.) sind unabhängig voneinander und können
auch in umgekehrter Reihenfolge angegangen werden (die erste Übung ist die
umfangreichere).
1
Senden verschlüsselter Nachrichten von Windows nach z/OS
1.1
Erstellen der AMS Policy für AMS.HOST.Q3 in Windows
Erstellen Sie im MQ Explorer eine neue Security Policy für Ihren Windows
Queue Manager, mit folgenden Angaben- wenn nötig, können Sie auf die
Screenshots auf Seite 25 zurückgreifen.
◦ Queue/Policy-Name: AMS.HOST.Q3
◦ dies ist eine Policy für Sign and encrypt da wir ja Verschlüsselung aktivieren möchten
◦ Signaturalgorithmus: MD5
◦ die Urheber der Nachrichten sollen nicht eingeschränkt werden
◦ Verschlüsselungsalgorithmus: RC2
◦ berechtigte Empfänger: nur einer, die TSO ID WBI#$A,
wobei diese durch die folgenden Zertifikats-Struktur zu identifizieren ist:
(Eingaben kritisch- genau so und case-sensitive, daher Hinweis auf der
Folgeseite beachten!):
▪ WBI#$A: CN=WBI#$A,OU=zHero,O=IBM,L=Hamburg,C=DE
Seite 35 von 48
----
Hinweis: Sie finden diesen “Distinguished Name String” im Member DRQUTIL
Ihrer *.CNTL Library im Host unter SUBJDN DD- von hier können Sie den
Ausdruck für den WBI**A User in das Fenster der Add (Distinguished Name)Funktion im Policy Wizard kopieren.
Das Summary Panel des Policy
Creation Wizards wird so
aussehen (dargestellt wieder für
das Team 33) – hier schließen
Sie mit Finish ab bzw. gehen für
Korrekturen zurück, wenn nötig:
1.2
Erstellen der AMS Policy für AMS.HOST.Q3 in z/OS
1.2.1 Wie zuvor, editieren Sie im Cntl-Screen Ihrer TSO Session das Member
DRQUTIL , um für die Queue AMS.HOST.Q3 eine AMS Policy mit der
passenden Spezifikation zu definieren.
Kopieren Sie dazu den setmqspl Befehl unter //SYSIN3 DD in den für das
Utility wirksamen //SYSIN DD Bereich hinein.
Die Befehlssyntax (mit Platzhalter im Qmgr Namen) ist:
setmqspl -m MQ#$ -p AMS.HOST.Q3 -s MD5 -e RC2
-r “CN=Dummy”
◦ Dieser Befehl erstellt die Policy, mit welcher die Queue AMS.HOST.Q3 als
AMS-geschützt markiert, mit “MD5” als Signatur und “RC2” als
Verschlüsselungsalgorithmus- entsprechend der Windows-seitigen Policy.
◦ Die -e Option macht die Angabe von -r (List of recipients) zwingend
erforderlich. Um jedoch deutlich zu machen, dass diese empfangsseitig
nicht zum Tragen kommt, machen wir hier diese “Dummy” Angabe.
◦ Wie zuvor, können Sie die bereits vorhandenen setmqspl Kommandos
unter //SYSIN DD beibehalten, auf jeden Fall aber den dspmqspl
(Display) Befehl am Ende der Befehlsfolge.
1.2.2 Submitten Sie die DRQUTIL JCL und überprüfen Sie den Job Output in SDSF.
Wir erwarten, dass der Job sauber läuft (MAXCC=00) und dass am Ende des
Listings die
neue Policy als
Ergebnis des
dspmqspl
Befehls wie
folgt angezeigt
wird:
Seite 36 von 48
1.3
----
Aktivieren der Policy-Änderung ...
/F MQ#$AMSM,REFRESH
Das unmittelbare Ergebnis sollte gleich aussehen wie zuvor :
DRQZS0304I (DRQMQ33) Modify REFRESH command accepted.
1.4
Versuch, verschlüsselte Nachrichten von Windows zu senden
1.4.1
Versuchen Sie nun, wie gehabt, aus einem der drei Windows Command
Fenster eine Nachricht auf die Queue AMS.HOST.Q3 zu schreiben (“Alice”,
“Bob” und “Carl” werden sich hier identisch verhalten), durch die bekannte
Eingabe
amqsput AMS.HOST.Q3
1.4.2 Was geschieht ?
Wir erwarten, dass
dies an dieser Stelle
schief geht- so wie
nebenstehend
dargestellt.
1.4.3 Sie wollen sicherlich wissen, was genau geschehen ist- sie sollen es erfahren:
◦ MQRC=2063 haben wir bereits als WMQ AMS Return Code kennen
gelernt, also hat der Fehler offensichtlich etwas mit der AMS Policy für die
angesprochene Queue zu tun (das sollte nicht überraschen …)
◦ Im Log File des Windows Queue Managers schlägt sich dieses Geschehen
wie folgt nieder:
AMQ9021: An error occurred during the certificate
import for the following DN:
CN=WBI33A,OU=zHero,O=IBM,L=Hamburg,C=DE, result: 57
EXPLANATION:
The distinguished name is not present in the keystore
or invalid.
◦ Erklärung: aufgrund der Security Policy, in der “Verschlüsselung” gefordert
wird, hat der AMS Code versucht, den Public Key für den Empfänger (es
ist in unserem Fall ja nur einer) zu laden, mit welchem die Verschlüsselung
ja durchgeführt werden soll. Aber dieses Zertifikat (“CN=WBI33A.....”) ist in
Windows Keystore Datei nicht vorhanden.
1.5
Transfer (Download) des z/OS User Zertifikats nach Windows
Was Sie hier tun und warum: Die “Public Keys” der TSO User -d.h. die
öffentlichen Teile ihrer Zertifikate- müssen dahin transferiert werden, wo die
Verschlüsselung stattfinden soll- also auf Ihr Windows Image- und dann in die
Keystore DB geladen werden, mit der WMQ AMS arbeitet.
Hinweis: Die Durchführung der folgenden Schritte (1.5.1 bis 1.5.4 ) ist
optional.
Seite 37 von 48
----
Die Public Key Zertifikate sind tatsächlich in Ihrer Windows Umgebung
schon bereit gestellt. Wenn Sie also abkürzen wollen, können Sie mit
Schritt 1.6 weiter machen.
1.5.1
Öffnen (editieren) Sie in TSO das CERTEXP Member Ihrer CNTL ArbeitsLibrary. Dies enthält die JCL zum “Exportieren” eines Public Key in eine
sequentielle Datei.
Beachten Sie die Syntax des benutzten RACDCERT EXPORT Kommandos.
◦ Das LABEL ist eine eindeutige Bezeichnung des interessierenden
Zertifikats;
◦ Das Ziel-Dataset wird mit dem angegebenen Namen (DSN) erstellt. Dies
muss demnach lediglich ein gültiger Dataset Name sein, und die
ausführende User ID muss zum Anlegen dieses Datasets berechtigt sein.
◦ Mit der FORMAT Angabe PKCS7DER werden nur die öffentlichen Teile
des Zertifikats angesprochen und nur diese werden extrahiert und
exportiert.
1.5.2 Submitten Sie den Job
Wir erwarten, dass er “sauber” mit MAXCC=0 läuft- wenn dem so ist, ist es
auch nicht nötig, den Output zu kontrollieren.
◦ Wenn Sie möchten, können Sie nachsehen, ob das “Export” Dataset mit
dem spezifizierten Namen (WBI#$%.WMQAMS.EXPORT) nun da ist.
1.5.3
Transferieren Sie das Export Dataset nun in das c:\AMSWork Verzeichnis
Ihrer Windows Umgebung. Dazu führen Sie einen binären File Transfer durch.
Am Ende des CERTEXP JCL Member Inhaltes finden Sie Befehls-Syntax,
die Sie per Copy&Paste für den ftp Transfer heranziehen können.
◦ Verwenden Sie einen der offenen Windows Command Fenster (Alice,
Bob, Carl ), um eine ftp Session mit dem z/OS System zu starten- mit dem
folgenden Kommando
ftp
172.16.36.24$
- wobei “$” entsprechend ersetzt wird
◦ Geben Sie Ihre TSO User ID und Passwort ein (nacheinander, wie
angefordert – beides ist an dieser Stelle nicht case-sensitiv!)
◦ Geben Sie
binary
ein, um einen binären Transfer anzuzeigen
Ihr Command Fenster sollte zu diesem Zeitpunkt so aussehen (für die
Darstellung wird wieder der WBI33A User verwendet):
Seite 38 von 48
----
1.5.4 Geben Sie nun den ftp Befehl zum Starten des Transfers (mit entsprechend
modifizierten Platzhaltern) ein- denken Sie an das Copy&Paste Angebot von
oben- hier steht “Ihr” Kommando mit den korrekten Adressen und Namen.
get 'WBI#$%.WMQAMS.EXPORT' WBI#$%.p7b
1.6
•
Wenn der Transfer ausgeführt wird, wird die Export-File mit Erweiterung
“p7b” in das Windows Verzeichnis c:\AMSWork herunter geladen.
•
Hinweis: Es ist möglich, dass der Transfer aufgrund von Netzwerk/Firewall
Restriktionen nicht funktioniert.
Wenden Sie in diesem Fall keine Zeit für “Fehleranalyse” auf- sondern
machen Sie einfach mit dem nächsten Schritt weiter und greifen dabei auf
die Key Datei zu, die bereits in der Windows Umgebung bereit gestellt
wurde.
Untersuchen des Public Key Inhalts
1.6.1 Lokalisieren Sie mit dem Windows Explorer die Public Key *.p7b Datei ◦ wenn sie den ftp Transfer durchführen konnten, ist dies
c:\AMSWork\WBI#$%.p7b
◦ Sonst finden Sie sie als c:\AMSWork\keydir\wbi#$%.p7b
1.6.2 Doppel-Klicken Sie auf das Symbol für die *.p7b File
Die *.p7b Datei-Erweiterung ist Windows “bekannt” und somit wird ein
“Certificate Viewer” Programm starten, mit welchem der Zertifikats-Inhalt
angezeigt wird.
Dieser sollte sich wie folgt darstellen (für die Beispiel-ID WBI33A)
Wie Sie sehen, enthält die Export-Datei nicht nur das “persönliche” WBI#$A
Benutzer-Zertifikat, sondern auch das Signer (Issuer/CA) Zertifikat .
1.6.3 Doppel-Klicken Sie auf den WBI#$% Eintrag, und wählen Sie dann Details
und dort per Doppel-Klick den “Subject” Eintrag, wie hier gezeigt.
◦ Kommen Ihnen die angezeigten Inhalte
bekannt vor?
… möglich- denn es ist genau die
“Distinguished Name” Struktur,
mit der dieser User innerhalb von
AMS Policies identifziert wird.
◦ Schließen Sie den “Certificate viewer”
Seite 39 von 48
----
1.7
Hinzufügen des Public Key zur AMS Keystore File
1.7.1
Starten Sie über die Windows Start Funktion (Windows Bildschirm ganz unten
links) das IBM Key Management
tool, und öffnen Sie die Übungs
DB Key File
c:\AMSWork\MQAMSkey.kdb,
wie bereits im Schritt 4.1.2 auf
Seite 31 beschrieben (und evtl.
praktiziert)
Das Passwort ist “mqams”.
Zunächst werden Sie dort die bestehenden “persönlichen” Zertifikate unserer
drei fiktiven Windows Benutzer sehen.
1.7.2
Wechseln Sie über die Auswahlleiste unter der Überschrift “key database
content” von “Personal Certificates” nach “ Signer Certificates, und klicken Sie
dann auf den Add Button rechts oben- dies ist die Funktion, mit welcher
“echte” Signer-(CA)-Zertifikate, und eben auch Public User Keys in die lokale
Key DB importiert werden.
1.7.3
Machen Sie im folgenden Dialog die *.p7b Datei für Ihre TSO ID ausfindigim c:\AMSWork\keydir Verzeichnis stehen die bereitgestellten Keys, im
c:\AMSWork Verzeichnis Ihr
selbst transferierter;
dann klicken Sie Open,
dann OK.
Hinweis: um die *.p7b Files
für den Zugriff sichtbar zu
machen, müssen Sie die
“Files of Types” Angabe
nach “All Files” ändern.
1.7.4 Aus der dann erscheinenden Liste, welche Ihnen die DN Strukturen des
persönlichen TSO User Zertifikats und der CA mit dem “Common Name”
MQAMS_CA anzeigt, wählen Sie die erstere und klicken dann OK.
1.7.5 Als nächstes werden Sie nach einem Label gefragt, welches dem neu hinzugefügten (Public) Key zugeordnet werden soll.
Beachten Sie, dass das Label stets eine lokale Kennung und an dieser Stelle
frei wählbar ist- es muss nur eindeutig sein innerhalb der Key DB.
Seite 40 von 48
----
Geben Sie einen sinnvollen Label Namen ein und
schließen Sie das Hinzufügen des Schlüssels durch
Klicken von OK ab.
1.7.6 Prüfen Sie nach, ob Ihr neu hinzugefügter Schlüssel (Zertifikat) nun in der
Liste der Signer Certificate mit dem von Ihnen vergebenen Label erscheint.
Die vorhandenen Schlüssel sind nach Label-Namen alphabetisch geordnetsomit hängt es vom gewählten Label Namen ab, an welcher Position Ihr
Zertifikat erscheint.
1.7.7 Schließen Sie das Key Management Tool (Key Database File > Exit) –
Änderungen werden automatisch gesichert.
1.8
Senden verschlüsselter Nachrichten von Windows nach z/OS
Zweiter Versuch
1.8.1 Wechseln Sie zum Cmd-Alice Command Fenster (welches immer noch offen
sein sollte- ansonsten öffnen Sie es neu über das gleichnamige Script im
Verzeichnis c:\AMSWork).
Verwenden Sie wie zuvor- im Schritt 1.4.1 dieser Übung- das amqsput
Beispiel-Programm zum Senden einer einfachen Text Nachricht auf die Queue
AMS.HOST.Q3
Die Syntax, zur Erinnerung (höchstwahrscheinlich kann Ihnen die “Pfeil-nachoben-Taste gute Dienste leisten):
amqsput AMS.HOST.Q3
Der Nachrichtentext sollte wieder etwas in der Art
“private message from Alice - 1”
sein.
1.8.2 Wenn der Zugriff auf die Queue klappt und Sie eine Nachricht schreiben/
senden konnten, legen Sie noch eine zweite nach, und beenden dann das
Programm durch zweifaches <Enter>.
1.8.3 Führen Sie die entsprechende Sende-Aktion für zwei Nachrichten von den
beiden anderen Command Fenstern, Cmd-Bob und Cmd-Carl, aus- und
kennzeichnen Sie die Nachrichten entsprechend.
1.8.4 Prüfen Sie den Füllstand der AMS.HOST.Q3 Queue im z/OS Queue Manageres sollten nun sechs (6) Messages auf der Queue stehen.
1.8.5 optional- wie schon zuvor:
Sie können die Browse Messages Funktion des MQ Explorers nutzen, um
diese Nachrichten auf der Queue anzuschauen.
Hinweis: Im Gegensatz zu den nur signierten Nachrichten im Schritt 3.2.5
(Seite 28) können Sie jetzt die von Ihnen eingegebenen Messagetexte nicht
mehr im Klartext erkennen- die Daten sind verschlüsselt !
1.8.6 Wechseln Sie nach TSO und öffnen/editieren Sie nun wieder das JCLGET
Member Ihrer CNTL Library.
Seite 41 von 48
----
Stellen Sie sicher, dass im PARM String (Zeile 000100) AMS.HOST.Q3 als
die zu lesende Queue angegeben ist, und ändern Sie den Lese-Zähler nach
“0001”, so dass nur eine Nachricht gelesen wird.
1.8.7 Submitten Sie den Job- und überprüfen Sie den Output in SDSF.
◦ Ist der Job sauber gelaufen, mit MAXCC=0000 ?
Dies erwarten wir- und dann dürften Sie im Anwendungsprotokoll des SDSF
Job Output die gelesene (erste) Nachricht wie folgt im Klartext sehen
können- das heißt, die Entschlüsselung mit dem privaten Schlüssel Ihrer
TSO User ID hat funktioniert !
1.8.8 Um die Übung sauber zu beenden- submitten Sie den JCLGET job nochmals,
wobei Sie den “Lesezähler” auf (mindestens) 5 (fünf) setzen- denn soviele
Nachrichten stehen noch auf der AMS.HOST.Q3 Queue- und überprüfen Sie
den Job Ouput anschließend in SDSF.
Wir erwarten, dass alle Nachrichte an das Leseprogramm ausgeliefert werden
und sich diese im Job Listing wie folgt darstellen (natürlich mit Ihren Texten)
Seite 42 von 48
----
2
Senden verschlüsselter Nachrichten von z/OS nach Windows
2.1
Erstellen der AMS Policy für den Windows Queue Manager
Erstellen Sie im MQ Explorer eine neue Security Policy für Ihren Windows
Queue Manager, mit folgenden Angaben:
◦ Queue/Policy-Name: AMS.WIN.Q3
(sauber arbeiten: Queue Namen via Select aus der Liste auswählen !)
◦ Security Funktion: Signieren und Verschlüsseln (Sign and encrypt);
▪ mit dem Message signing algorithm “MD5”
▪ und dem Message encryption algorithm “RC2”
◦ Ein Distinguished name of permitted message recipients muss zwar
spezifiziert werden, aber diese
Angabe wird nicht ausgewertet,
solange von der Queue nur gelesen
wird- also dürfen Sie hier einen
“Dummy” Eintrag vornehmen, wie
nebenstehend dargestellt.
Das Summary Panel des Policy Creation Wizards wird so aussehen
(dargestellt wieder für das Team 33) –
hier schließen Sie mit Finish ab
bzw. gehen für Korrekturen zurück,
wenn nötig:
2.2
Erstellen der AMS Policy für den z/OS Queue Manager
Editieren Sie im Edit-Screen Ihrer TSO Session das Member DRQUTIL .
◦ der WMQ AMS Befehl mit Verschlüsselungsoption steht unter
//SYSIN3W DD ausgeschrieben bereit.
▪ als Verschlüsselungsalgorithmus ist “RC2” spezifiziert;
▪ “Bob” und “Carl” sind die (einzigen) berechtigten Empfänger
◦ Kopieren Sie den kompletten setmqspl Befehl nach //SYSIN DD
(behalten Sie den dspmqspl Befehl bei)
◦ Submitten Sie den Job
Wir erwarten eine kurze Laufzeit und CC=00
Seite 43 von 48
2.3
----
Überprüfen Sie den Job Output in SDSF (“swap 2”).
Wir erwarten, dass sich die neue Policy als Ergebnis des Display Befehls wie
folgt zeigt :
2.4
Aktivieren der Policy-Änderung ...
/F MQ#$AMSM,REFRESH
2.5
Zum Schreiben (Senden) von Nachrichten auf die Queue AMS.WIN.Q3 öffnen
Sie das Member JCLPUT in Ihrer *.CNTL Library.
◦ die JCL ruft ein Batchprogramm auf, welches drei (“SET MSGS=3”)
identische Nachrichten auf die bezeichnete Queue schreibt.
Die Daten für die Nachricht werden von dem Dataset geladen, auf welches
das //MSGIN DD Statement zeigt- und dies ist das MSGTEXT Member
dieser Library.
Submitten Sie den Job- wenn er (wie erwartet) mit CC=00 endet, verzichten
wir diesmal auf das Überprüfen des SDSF Listings.
2.6
Stellen Sie sicher, dass die drei (3) Nachrichten auf der Ziel-Queue
angekommen sind - AMS.WIN.Q3 in Ihrem Windows QMgr; ggf. ist der
Requester-Kanal zu starten.
2.7
Lesen der Nachrichten als “Bob”
2.7.1
Starten Sie im dem Cmd-Bob Command Fenster Ihres Windows Desktops
das Lese-Beispiel-Programm amqsget, durch die folgende Befehlseingabe:
amqsget AMS.WIN.Q3
Wir erwarten, dass alle Nachrichten gelesen werden und dies nach
Programmende wie folgt angezeigt wird (amqsget liest die Queue leer, zeigt
dabei die Messagetexte an und wartet danach noch einige Sekunden auf
weitere Nachrichten, bevor es terminiert):
2.8
Submitten Sie den JCLPUT Job unverändert zwei weitere Male, um weitere
Nachrichten auf die Queue AMS.WIN.Q3 zu schreiben.
Wir erwarten, dass die Jobs genauso schnell und fehlerfrei laufen wie zuvor.
2.9
Vergewissern Sie sich wieder mit Hilfe des MQ Explorers, dass die sechs (6)
Nachrichten auf der AMS.WIN.Q3 Queue auf Windows angekommen sind.
Seite 44 von 48
----
2.10
Lesen der Nachrichten als “Alice”
2.10.1 Geben Sie jetzt den amqsget Befehl von zuvor (2.7.1) im Cmd-Alice Fenster
ein, so dass der Lesezugriff unter “Alice” erfolgt.
amqsget AMS.WIN.Q3 <enter>
2.10.2 Was geschieht ?
Wir erwarten, dass dies schief geht – mit der folgenden Anzeige:
◦ Details zu dieser Situation finden sich im Error Log des Windows Queue
Managers:
AMQ9017: WebSphere MQ security policy internal error:
message could not be unprotected: GSKit error code 851968,
reason 43.
EXPLANATION:
The WebSphere MQ security policy interceptor could not
verify or decrypt a message because the indicated GSKit
error occurred. This can happen for several reasons, all of
which are internal failures: (1) the message is not a valid
PKCS#7 message; (2) the sender's certificate does not have
the required key usage bit to be able to encrypt the
message; (3) the sender's certificate was not recognized as
a trusted certificate; (4) receiver is not among the
recipients of the message.
und außerdem …
AMQ9044: The WebSphere MQ security policy interceptor
has put a defective message on error handling queue
SYSTEM.PROTECTION.ERROR.QUEUE.
▪ Hinweis/Kommentar dazu:
“internal error” ist hier etwas irritierend, aber die EXPLANATIONs
beschreiben als Möglichkeit (4) die tatsächliche Ursache:
“Alice” ist in der sendeseitigen (z/OS) Policy nicht als Empfänger für
Nachrichten dieser Queue angegeben worden- nur “Bob” und “Carl” siehe 2.2. - nur für diese ist die Entschlüsselung möglich.
Die AMQ9044 Nachricht besagt, dass die (erste) Nachricht auf die
SYSTEM.PROTECTION.ERROR.QUEUE verschoben wurde.
▪ Das amqsget Beispielprogramm ist so gestaltet, dass es bei jedem
Fehlercode terminiert; es sollten also noch fünf (5) Nachrichten auf der
AMS.WIN.Q3 Queue stehen.
(optional) Lesen der Nachrichten als “Carl”
2.11.1 Starten Sie das amqsget Leseprogramm im Cmd-Carl Fenster- mit
demselben Befehl wie zuvor:
amqsget AMS.WIN.Q3 <enter>
2.11
Seite 45 von 48
----
Wir erwarten, dass die Nachricht(en) erfolgreich gelesen und angezeigt
werden, da “Carl” ja einer der berechtigten Empfänger ist:
Eine abschließende kurze Erklärung:
Warum war es möglich, aus der z/OS-Umgebung die Verschlüsselung für
die (fiktiven) Windows-User “Bob” und “Carl” durchzuführen?
Antwort: die “public Keys” dieser User müssen dem WMQ AMS Keyring
(drq.ams.keyring) des Started Task Users für die AMS Data Task (*AMSD)
zugeordnet (connected) sein- dies ist hier die MQ#$MSTR User ID.
Diese Zuordnung lässt sich darstellen mit dem RACF Befehl (für MQ33)
RACDCERT ID(MQ33MSTR) LISTRING(drq.ams.keyring)
In unserem speziellen Fall sind die Zertifikate für die (fiktiven) Windows
User mittels des lokalen RACF erstellt worden (siehe Anhang), so dass kein
“Transfer” nötig war, sondern wirklich nur das “Connecten” der Zertifikate
mit der Kennung “SITE” als “Usage option”.
Wenn die “Alice”, “Bob” und “Carl” -Zertifikate irgendwo anders. z.B. auf
Windows, erstellt worden wären, hätten die Public Keys exportiert und nach
z/OS transferiert werden müssen- genauso, wie dies im 1. Teil der Übung 4
für das Zertifikat des z/OS (TSO) Users in die andere Richtung gemacht
wurde.
End of WMQ AMS Exercises
Seite 46 von 48
----
— Anhang:
Erstellen und Handhaben der Zertifikate
Die folgenden Auszüge dokumentieren, wie die für die vorstehenden Übungen
benutzten Zertifikate erstellt und konfiguriert wurden, um die ÜbungsKonfiguration zu unterstützen.
Alle Jobs, Listings, Screenshots etc., die hier sind für die Umgebung des Lab
Teams “33” dargestellt sind, existieren für die anderen Teams entsprechend.
1.
Erstellen des CA Root Zertifikats
(damit werden/wurden alle anderen Zertifikate signiert)
RACDCERT CERTAUTH GENCERT +
SUBJECTSDN(CN('MQAMS_CA') O('IBM') OU('SWG') +
T('MQAMS CA Root Certificate') L('Stuttgart') C('DE')) +
NOTBEFORE(DATE(2012-01-15)) NOTAFTER(DATE(2015-12-31)) +
WITHLABEL('MQAMS_CA')
2.
Erstellen der “persönlichen” Zertifikate für die Host (TSO) User
(eines pro TSO User ID)
RACDCERT ID(WBI33A) GENCERT +
SUBJECTSDN(CN('WBI33A') O('IBM') OU('zHero') +
C('DE') L('Hamburg')) +
WITHLABEL('WBI33A.zHero') +
SIGNWITH(CERTAUTH LABEL('MQAMS_CA')) +
KEYUSAGE(HANDSHAKE DATAENCRYPT DOCSIGN)
3.
Erstellen der “persönlichen” Zertifikate für die (fiktiven) Windows User
Alice, Bob und Carl
RACDCERT ID(WFWBI) GENCERT +
SUBJECTSDN(CN('Alice') O('IBM') OU('zHero') +
C('DE') L('Augsburg')) +
WITHLABEL('Alice.Win') +
SIGNWITH(CERTAUTH LABEL('MQAMS_CA')) +
KEYUSAGE(HANDSHAKE DATAENCRYPT DOCSIGN)
Hinweis: der RACF/TSO User WFWBI , für den diese Zertifikate formal erstellt
wurden, dient lediglich als “Strohmann” und spielt beim bzw. nach dem Export
des Zertifikats nach Windows (oder irgendeine andere Plattform) keine Rolle
mehr.
Seite 47 von 48
4.
----
Erstellen des Keyrings für den AMS Data Task User und Zuordnen
(“connect”) der Zertifikate zu diesem
RACDCERT ID(MQ33MSTR) ADDRING(drq.ams.keyring)
RACDCERT ID(MQ33MSTR) CONNECT(CERTAUTH LABEL('MQAMS_CA') +
RING(drq.ams.keyring))
RACDCERT ID(MQ33MSTR) CONNECT(ID(WFWBI) –
LABEL('Alice.Win') RING(drq.ams.keyring) USAGE(SITE))
… entsprechend genauso für “Bob” und “Carl”
5.
Erstellen des Keyrings für den z/OS (TSO) User Zuordnen (“connect”)
des persönlichen Zertifikats
RACDCERT ID(WBI33A) ADDRING(drq.ams.keyring)
RACDCERT ID(WBI33A) CONNECT(ID(WBI33A)
LABEL('WBI33A.zHero') +
RING(drq.ams.keyring) DEFAULT USAGE(PERSONAL))
6.
Exportieren der Zertifikate für die Windows User (mit privatem Schlüssel)
RACDCERT ID(WFWBI) EXPORT (LABEL('Alice.Win')) +
DSN('WFWBI.SSLEXP.CARL')
+
FORMAT(PKCS12DER) PASSWORD('mqams')
… entsprechend genauso für “Bob” und “Carl”
7.
Exportieren der Zertifikate der TSO (z/OS) User – nur die öffentlichen
Teile- der öffentliche Schlüssel der signierenden CA wird der ExportDatei automatisch hinzugefügt
RACDCERT ID(WBI33A) EXPORT (LABEL('WBI33A.zHero')) +
DSN('WFWBI.WMQAMS.EXP33A')
+
FORMAT(PKCS7DER)
Hinweis:
In beiden EXPORT Beispielen (6. und 7.) ist das Export Dataset eine Datei mit
beliebigem Namen, die (binär) zum Zielsystem zu transferieren ist, und dort in eine
Zertifikats-Datenbank (Keystore DB/File) “importiert” wird- dies geschieht in aller
Regel mit Hilfe eines entsprechenden Tools, z.B. dem IBM Security Toolkit.
Seite 48 von 48

Wildfire Messaging 2011 - WMQ FTE Lab Instructions

Transcrição

Documentos relacionados

Titel Implacementstiftung JUST (JUgendSTiftung) – AMS SLBG

Infoblatt Auszahlung von finanziellen Leistungen des AMS

Allgemeine Information

Frauen-Netzwerkcafé

irtschaftsch

Gesamtübersicht Universitätsklinikum Würzburg

Das offizielle Voxamps Forum des deutschen Vertriebes

Lageplan Universitätsklinikum Würzburg

Frankreich