Der Standard-Anmelde-Dialog wird immer dann durchgeführt, wenn die beiden folgenden Bedingungen erfüllt sind:
Für das Terminal ist kein automatisches KDCSIGN (= automatische Berechtigungsprüfung) generiert (siehe "Automatisches KDCSIGN").
Für den Standard-Anwendungsnamen (generiert in MAX APPLINAME), ist kein Anmelde-Vorgang generiert (siehe "Anmeldeverfahren mit Anmelde-Vorgängen").
Beim Standard-Anmelde-Dialog führt openUTM eine Berechtigungsprüfung durch (Zugangskontrolle). Dabei wird der Benutzer über UTM-Meldungen im Zeilenmodus aufgefordert, sich zu legitimieren.
Man kann bei der UTM-Generierung zwischen verschiedenen Varianten wählen, auch die Meldungstexte können verändert werden. Darüber hinaus ist dieses Verfahren jedoch nicht modifizierbar.
Die Berechtigungsprüfung kann unterschiedlich streng festgelegt werden. Eine Übersicht aller Möglichkeiten enthält die Abbildung in Abschnitt „Szenarien für die UTM-Berechtigungsprüfung".
openUTM fordert den Benutzer mit folgender Meldung zur Berechtigungsprüfung auf:
K002 Verbunden mit der Anwendung <anwendungsname> - Bitte KDCSIGN
Der Benutzer muss seine Berechtigung mit der folgenden Eingabe nachweisen:
KDCSIGN kennung [,password]
Im Kommando KDCSIGN kann password angegeben werden, wenn das Passwort für diesen Benutzer ohne Dunkelsteuerung generiert ist (KDCDEF-Anweisung USER...,PASS=).
openUTM prüft die Benutzerkennung und ggf. das Passwort. Ist das Ergebnis negativ, dann wird der Benutzer zur Wiederholung der KDCSIGN-Eingabe aufgefordert. Ist der Benutzer mit Passwort generiert, aber das Passwort wurde in dem Kommando KDCSIGN nicht angegeben, dann fordert openUTM das Passwort in einem zweiten Dialogschritt dunkel gesteuert an.
Dunkelsteuerung des Passworts
Wenn für die Benutzerkennung Dunkelsteuerung des Passworts generiert ist
(USER...,PASS=(password,DARK)), dann fordert openUTM den Benutzer mit einer Meldung auf, das Passwort in ein dunkel gesteuertes Feld einzugeben.
Dabei hat der Benutzer die Möglichkeit, ein neues Passwort einzugeben, welches das bisherige ersetzen soll, vorausgesetzt, die in der Generierung festgelegte minimale Gültigkeitsdauer erlaubt die Passwortänderung zu diesem Zeitpunkt. Das neue Passwort ist hierbei durch eine Wiederholung zu bestätigen. openUTM prüft das angegebene alte Passwort und ggf. das neue Passwort. Ist das alte Passwort nicht richtig, dann wird der Benutzer zur Wiederholung der KDCSIGN-Angabe aufgefordert. Stimmen die Angaben zum neuen Passwort nicht überein, dann wird der Benutzer mit einer UTM-Meldung informiert und zur Wiederholung der Eingabe aufgefordert.
Gültigkeitsdauer des Passwortes
Bei der Generierung der Benutzerkennung kann eine maximale und eine minimale Gültigkeitsdauer für das Passwort vereinbart werden:
USER ...,PROTECT-PW=(...,maxtime,mintime)
Die minimale Gültigkeitsdauer bedeutet, dass der Benutzer nach einer Passwort-Änderung die nächste Änderung erst nach Ablauf der festgelegten Zeit vornehmen kann. Die maximale Gültigkeitsdauer bedeutet, dass der Benutzer das Passwort jeweils innerhalb der angegebenen Zeitspanne ändern muss.
Wird das Passwort innerhalb der nächsten 14 Tage nach der Anmeldung ungültig, warnt openUTM den Benutzer mit einer K-Meldung, sofern die minimale Gültigkeitsdauer des Passworts eine Änderung zu diesem Zeitpunkt erlaubt. Ein Passwort kann der Benutzer wie unter „Dunkelsteuerung des Passworts“ beschrieben ändern.
Um zu verhindern, dass Benutzer, die längere Zeit nicht mit der Anwendung arbeiten, die Passwort-Änderung versäumen und sich dann an den Administrator wenden müssen, kann die UTM-Anwendung so konfiguriert werden, dass auch nach Ablauf des Passworts eine Anmeldung erlaubt wird, siehe Abschnitt „Grace-Sign-On".
openUTM überprüft bei der Passwortänderung, ob:
das neue Passwort sich von dem alten Passwort unterscheidet, wenn eine maximale Passwort-Gültigkeitsdauer generiert ist.
Wenn eine Passwort-Historie generiert ist (SIGNON ...,PW-HISTORY=n), dann wird das neue Passwort auch gegen die letzten n Passworte geprüft.das neue Passwort der Komplexitätsstufe entspricht, die für die Benutzerkennung generiert wurde (USER ...,PROTECT-PW=).
die Länge des Passwortes größer oder gleich der generierten Mindestlänge ist (USER ...,PROTECT-PW=).
Erfüllt das neue Passwort alle diese Punkte, nimmt openUTM die Passwortänderung vor. Die Gültigkeitsdauer des neuen Passwortes entspricht wieder dem generierten Wert.
Erfüllt das neue Passwort einen dieser Punkte nicht, so wird der Benutzer mit der folgenden Meldung aufgefordert, die KDCSIGN-Eingabe mit dem alten Passwort zu wiederholen:
K097 Angaben zum neuen Passwort sind nicht verwendbar - Bitte KDCSIGN
Ist die Gültigkeitsdauer des Passwortes bei der Anmeldung bereits abgelaufen und ist kein Grace-Sign-On generiert, so wird die Anmeldung mit der folgenden Meldung zurückgewiesen:
K120 Die Gueltigkeit des Passworts ist abgelaufen - Bitte KDCSIGN
Eine Anmeldung an die UTM-Anwendung unter dieser Benutzerkennung ist erst dann wieder möglich, wenn der UTM-Administrator der Kennung ein neues Passwort zugewiesen hat.
Grace-Sign-On
Ist die Gültigkeitsdauer des Passwortes bei der Anmeldung bereits abgelaufen und ist die Anwendung mit Grace-Sign-On generiert (SIGNON ...,GRACE=YES), so wird der Benutzer mit einer K-Meldung darauf hingewiesen, dass sein Passwort nicht mehr gültig ist. Gleichzeitig wird er aufgefordert, sein bisheriges Passwort und ein neues Passwort einzugeben. Zum Ändern muss auch ein eventuell bereits eingegebenes Passwort nochmals in das entsprechende dunkelgesteuerte Feld eingegeben werden.
KDCSIGN mit Ausweiskarte
Wenn für die Benutzerkennung per UTM-Generierung das Einlegen einer Ausweiskarte (Magnetstreifenkarte) vorgeschrieben ist, fordert openUTM den Benutzer mit einer Meldung auf, eine Ausweiskarte in den Ausweisleser einzulegen. Zeitgleich zu dieser Meldung wird die Tastatur des Terminals gesperrt. Die Sperre wird erst durch Einlegen des Ausweises aufgehoben. Ist kein Ausweis verfügbar, so kann die Tastatur ersatzweise mit der Taste K14 oder ESC : entsperrt werden.
openUTM prüft die Ausweisinformation, d.h. openUTM vergleicht die in der KDCDEF-Anweisung USER ...,CARD=(...) definierte Zeichenfolge mit der entsprechenden Zeichenfolge auf dem Ausweis. Fällt das Ergebnis negativ aus, so wird der Benutzer mit der Meldung K031 informiert und zur Wiederholung der KDCSIGN-Eingabe aufgefordert. Fällt das Ergebnis positiv aus, dann kann der Benutzer mit der Anwendung arbeiten.
Der Ausweis muss solange im Ausweisleser bleiben, wie der Benutzer unter dieser Benutzerkennung arbeiten möchte. Wird er früher herausgezogen, so erkennt openUTM dies spätestens bei der nächsten Dialogeingabe und erzeugt implizit KDCOFF. Sehen Sie dazu auch Abschnitt „Abmelden von der UTM-Anwendung".
Szenarien für die UTM-Berechtigungsprüfung
Das folgende Diagramm zeigt, welche Varianten der UTM-Berechtigungsprüfung möglich sind - abhängig von der KDCDEF-Generierung. Bei fehlerhaften Eingaben gibt openUTM eine spezifische Meldung aus und fordert den Benutzer zu einer neuen Eingabe auf. Werden von einem bestimmten Terminal aus oder unter einer bestimmten
Benutzerkennung nacheinander mehrere erfolglose Anmeldeversuche unternommen, dann erzeugt openUTM die Meldung K094 mit dem Standardziel SYSLOG (System-Protokolldatei). Die maximal zulässige Anzahl erfolgloser Anmeldeversuche bis zum Auslösen der Meldung K094 kann mit SIGNON ... SILENT-ALARM= bei der KDCDEF-Generierung festgelegt werden. Ein MSGTAC-Teilprogramm kann auf diese Meldung reagieren.
Bild 5: Szenarien der Berechtigungsprüfung bei Anwendungen mit Benutzerkennungen (Teil 1)
Bild 6: Szenarien der Berechtigungsprüfung bei Anwendungen mit Benutzerkennungen (Teil 2)
Bild 7: Szenarien der Berechtigungsprüfung bei Anwendungen mit Benutzerkennungen (Teil 3)