krn.CheckUserAccount
Dieser Job überprüft, ob der angegebene Benutzer sich am System anmelden kann. Das übergebene Passwort wird geprüft — ein falsches Passwort kann zur Sperrung des Accounts führen (gleiche Kriterien wie im enaio® enterprise-manager).
Der Job kehrt mit einem Fehler zurück, wenn der Benutzer sich nicht am System anmelden kann.
Der Job läuft auf der bestehenden Session und öffnet keine Session für den geprüften Benutzer — er liefert keine SessionGUID, sondern ausschließlich das Prüfergebnis.
1. Eingabeparameter
| Name | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
INT |
Ja |
Muss |
|
STRING |
Ja |
Anmeldename des Benutzers. Wird ohne Beachtung der Groß-/Kleinschreibung aufgelöst. |
|
STRING |
Ja |
Verschlüsseltes Passwort — gleiches Format wie krn.SessionLogin/ |
Password ist ein Pflichtparameter. Ein Aufruf ohne diesen Parameter — etwa als reine Existenzprüfung des Benutzernamens — wird mit -1043332470 („A required parameter was not specified: Password.") abgewiesen.
|
2. Ausgabeparameter
| Name | Typ | Abhängigkeit | Beschreibung |
|---|---|---|---|
|
INT |
— |
Ergebnis der Anmeldeprüfung: |
|
INT |
nur bei |
Gültigkeit des Passworts: |
|
STRING |
nur bei |
Interner Benutzername in der Schreibweise, in der der Server ihn aufgelöst hat, z. B. |
|
STRING |
nur bei |
Authentifizierungsverfahren, z. B. |
3. Rückgabe
(INT): 0 = Job erfolgreich, sonst Fehlercode.
In der Praxis tritt nur Action = 0 auf: Die in der Tabelle dokumentierten Fehlerfälle 2, 3, 4 und 5 kommen stattdessen als Fehlercode zurück — passend dazu, dass der Job mit einem Fehler zurückkehrt, wenn der Benutzer sich nicht anmelden kann.
| Code | Server-Meldung | Entspricht Action |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
— (Aufrufer nicht berechtigt) |
-1042218019 wird sowohl für einen manuell gesperrten Account als auch für einen durch Fehlanmeldungen gesperrten Account geliefert, und zwar auch bei korrektem Passwort. Die beiden Fälle sind aus der Antwort dieses Jobs nicht unterscheidbar; das Benutzerattribut locked (siehe Sperrverhalten) und ein Kontextwechsel auf den Benutzer (siehe Ursachencodes im Fehlerstack) unterscheiden sie.
|
Als Erfolg dürfen nur |
4. Benötigte Systemrolle
|
Der aufrufende Benutzer benötigt die Systemrolle
Die Rolle ist notwendig und ausreichend und von allen anderen Rollen unabhängig: Ein Benutzer, der ausschließlich diese Rolle besitzt, ist erfolgreich; ein Benutzer mit den 71 anderen Rollen scheitert mit Die dem aufrufenden Benutzer zugewiesenen Systemrollen lassen sich mit mng.GetUserRoles ermitteln; eine Übersicht aller Rollen findet sich unter Systemrollen. |
5. Sperrverhalten
Fehlversuche zählt der Server pro Account im Attribut logincount; andere Accounts sind nicht betroffen. Was ein Fehlversuch bewirkt, steuert die Sicherheitsstufe Login\SecurityLevel (Standard 0 = keine Einschränkung; die übrigen Stufen schließen die Anwendung bzw. sperren den Account nach drei Fehlversuchen). Für Benutzer mit Zwei-Faktor-Authentifizierung gilt die Einstellung nicht.
Verlauf auf einem Server, der nach drei Fehlversuchen sperrt:
| Aufruf | logincount |
locked |
Rückgabe |
|---|---|---|---|
1. falsches Passwort |
|
|
|
2. falsches Passwort |
|
|
|
3. falsches Passwort |
|
|
|
jeder weitere Aufruf, auch mit korrektem Passwort |
|
|
|
-
Der dritte Fehlversuch sperrt den Account, antwortet aber weiterhin mit
-1042218021. Wer auf-1042218019wartet, um das Zuschnappen der Sperre zu erkennen, verpasst den Moment. -
Ein erfolgreicher Aufruf setzt
logincountauf0zurück, solange die Sperre noch nicht zugeschnappt ist — abwechselnd korrekte und falsche Prüfungen lösen sie daher nie aus. Ist der Account gesperrt, wird auch das korrekte Passwort abgewiesen und der Zähler bleibt auf seinem Maximum; dann hilft nur ein administratives Zurücksetzen (siehe unten). -
Der Schwellwert ist über die API nicht lesbar — Einträge wie
Security\PwdLockCount,MaxLoginAttemptsoderLoginRetriesexistieren nicht (krn.REGetRegValue liefert-1042218742). Lesbar ist mitName=Login\SecurityLevellediglich, ob Fehlversuche sperren — nicht, nach wie vielen. Aufrufer müssen ihre Versuche selbst begrenzen.
5.1. Sperre erkennen und aufheben
Das Benutzerattribut locked unterscheidet die beiden Sperrarten: 1 = manuell durch einen Administrator gesperrt, 2 = durch Fehlanmeldungen gesperrt. Beide Werte liefern mng.GetUserAttributes und mng.GetUserList.
|
Die Markierung |
Maßgeblich für die Sperre ist logincount, nicht locked — ein Schreiben von locked = 0 allein hebt sie nicht auf. Entsperrt wird der Account, indem mng.SetUserAttributes mit einer vollständigen UserInfo des Accounts und logincount="0" aufgerufen wird; unmittelbar danach meldet dieser Job wieder Action = 0.
6. Zugehörige Einstellungen
| enaio® enterprise-manager | Registry-Eintrag | Standard | Wirkung auf diesen Job |
|---|---|---|---|
Gültigkeitszeitraum für Passwörter |
|
|
|
Hinweis auf den Ablauf des Gültigkeitszeitraums |
|
|
steuert die Warnung von enaio® selbst, nicht |
Einmal-Passwort |
|
|
neue Accounts melden |
Sicherheitsstufe |
|
|
ob Fehlversuche den Account sperren; als einziger der hier genannten Einträge über krn.REGetRegValue lesbar |
7. Siehe auch
-
krn.SessionLogin — tatsächliche Anmeldung einer Session
-
krn.VerifyPassword — Prüfung eines Passworts gegen die Passwortsyntax-Regel (keine Prüfung von Anmeldedaten)
-
mng.GetUserAttributes — Benutzerattribute inklusive
lockedundchangepwd -
mng.SetUserAttributes — Zurücksetzen von
logincountzum Aufheben einer Sperre