Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Standard-Anmeldedialog

Der Standard-Anmeldedialog wird immer dann durchgeführt, wenn die beiden folgenden Bedingungen erfüllt sind:

  1. Für das Terminal ist kein automatisches KDCSIGN (= automatische Berechtigungsprüfung) generiert (siehe "Automatisches KDCSIGN").

  2. Für den Standard-Anwendungsnamen (generiert in MAX APPLINAME), unter dem sich der Benutzer angemeldet hat, ist kein Anmelde-Vorgang generiert (siehe "Anmeldeverfahren mit Anmelde-Vorgängen").

Beim Standard-Anmeldedialog führt openUTM eine Berechtigungsprüfung durch (Zugangskontrolle). Der Anmeldedialog ist 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".

Die Berechtigungsprüfung führt openUTM im Dialog mit dem Benutzer durch, wenn beim Start des entsprechenden Dialog-Terminalprozesses der Schalter -S angegeben wird. In diesem Fall fragt openUTM die Benutzerkennung ab und fordert - falls generiert- die Angabe eines Passworts an.

Wird der Schalter -S nicht angegeben, führt openUTM die Berechtigungsprüfung mit der Benutzerkennung durch, unter der sich der Benutzer beim System angemeldet hat. In diesem Fall kann in der UTM-Anwendung für die Benutzerkennung ebenfalls ein Passwort generiert werden, zu dessen Eingabe der Benutzer bei der Berechtigungsprüfung aufgefordert wird.

Zu beachten ist jedoch, dass ein Benutzer nicht unter einer Benutzerkennung gleichzeitig mit mehreren Dialog-Terminalprozessen arbeiten kann.

Eingabe des Passworts

Wenn für die Benutzerkennung ein Passwort generiert ist (KDCDEF-Anweisung USER...,PASS=password[, DARK]), dann wird das Passwort immer in ein Feld ohne Dunkelsteuerung eingegeben.

Bei jeder Anmeldung an die UTM-Anwendung hat der Benutzer die Möglichkeit, ein neues Passwort einzugeben, welches das bisherige ersetzen soll, vorausgesetzt, die minimale Gültigkeitsdauer erlaubt die Passwortänderung zu diesem Zeitpunkt. Das neue Passwort muss dann einmal in ein Feld ohne Dunkelsteuerung eingegeben werden. openUTM prüft das angegebene alte Passwort und ggf. das neue Passwort. Ist das alte Passwort nicht richtig, dann wird der Benutzer mit einer UTM-Meldung informiert und erneut zur Eingabe einer Benutzerkennung aufgefordert.

Gültigkeitsdauer des Passwortes

Bei der UTM-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 „Eingabe 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 nächste Seite, Abschnitt „Grace-Sign-On“.

openUTM überprüft bei der Passwortänderung, ob

  • das neue Passwort sich von dem alten Passwort unterscheidet, wenn eine maximale Passwortgültigkeitsdauer generiert ist.
    Wenn eine Passwort-Historie generiert ist (SIGNON ...,PW-HISTORY=n), dann wird 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 anmelden

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 anmelden

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.

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 3: Szenarien der Berechtigungsprüfung bei Anwendungen mit Benutzerkennungen (Teil 1)

Bild 4: Szenarien der Berechtigungsprüfung bei Anwendungen mit Benutzerkennungen (Teil 2)

Bild 5: Szenarien der Berechtigungsprüfung bei Anwendungen mit Benutzerkennungen (Teil 3)