Bug 18838 - ucs-test: Sperrung des Benutzerkontos nach X erfolglosen Anmeldeversuchen
ucs-test: Sperrung des Benutzerkontos nach X erfolglosen Anmeldeversuchen
Status: CLOSED FIXED
Product: UCS Test
Classification: Unclassified
Component: General
unspecified
Other Linux
: P5 enhancement (vote)
: ---
Assigned To: Stefan Gohmann
Philipp Hahn
:
Depends on: 18750 18840
Blocks: 18776 18825 18835 18836 18837 19100 19888
  Show dependency treegraph
 
Reported: 2010-06-30 07:05 CEST by Stefan Gohmann
Modified: 2023-03-25 06:50 CET (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
WIP Version (4.73 KB, text/plain)
2010-07-01 20:40 CEST, Philipp Hahn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2010-06-30 07:05:09 CEST
Dafür sollte es einen automatisierten Test geben.


+++ This bug was initially created as a clone of Bug #18750 +++

Pro UCS-System sollte konfiguriert werden können, nach wie viel erfolglosen
Anmeldeversuchen der Benutzer gesperrt wird.
Comment 1 Stefan Gohmann univentionstaff 2010-06-30 11:02:08 CEST
Ein erster kleiner Test ist implementiert scripts-00_base/47faillog. Hier könnte noch deutlich mehr geprüft werden, u.a. root Login, admin-auth usw.
Comment 2 Philipp Hahn univentionstaff 2010-07-01 20:40:35 CEST
Created attachment 2478 [details]
WIP Version

1. s/oldauth/old_auth/
2. rm -f "$fake_passwd" "$passwd"
3. Quoting

TODO:
4. Das Skript überprüft am Anfang "current_ucs_version_greater_equal 2.4", das reicht nicht: Bei einer Neuinstallation läuft das Skript durch, bei einem upgegradeded System sind die Einstellungen Password- und ChallendeResponseAuthentication genau invertiert, was zu einer unterschiedlichen Anzahl der Login-versuche führt:
5. Das Skript setzt am Ende die UCR-Variablen auf die "alten" Werte zurück. Waren diese vorher jedoch nicht gesetzt, so enthalten die Variablen danach die leere Zeichenkette. Das führt dazu, daß in "/etc/univention/templates/files/etc/pam.d/common-auth.d/30univention-pam_local" der Aufruf von
   baseConfig.get('auth/faillog/limit', '5')
nur die leere Zeichenkette zurückliefert und deswegen in der /etc/pam.d/common-auth
   auth    required        pam_tally.so per_user per_user deny=
steht, was in /var/log/auth.log angeprangert wird:
  pam_tally(sshd:auth): bad number supplied: deny=
Comment 3 Stefan Gohmann univentionstaff 2010-07-01 21:50:43 CEST
(In reply to comment #2)
> 1. s/oldauth/old_auth/

fixed

> 2. rm -f "$fake_passwd" "$passwd"

fixed

> 3. Quoting
> 
> TODO:
> 4. Das Skript überprüft am Anfang "current_ucs_version_greater_equal 2.4", das
> reicht nicht: Bei einer Neuinstallation läuft das Skript durch, bei einem
> upgegradeded System sind die Einstellungen Password- und
> ChallendeResponseAuthentication genau invertiert, was zu einer
> unterschiedlichen Anzahl der Login-versuche führt:

Die Variablen werden jetzt am Anfang passend gesetzt und am Ende wieder zurückgesetzt.

> 5. Das Skript setzt am Ende die UCR-Variablen auf die "alten" Werte zurück.
> Waren diese vorher jedoch nicht gesetzt, so enthalten die Variablen danach die
> leere Zeichenkette. Das führt dazu, daß in
> "/etc/univention/templates/files/etc/pam.d/common-auth.d/30univention-pam_local"
> der Aufruf von
>    baseConfig.get('auth/faillog/limit', '5')
> nur die leere Zeichenkette zurückliefert und deswegen in der
> /etc/pam.d/common-auth
>    auth    required        pam_tally.so per_user per_user deny=
> steht, was in /var/log/auth.log angeprangert wird:
>   pam_tally(sshd:auth): bad number supplied: deny=

Sollte jetzt auch passen.
Comment 4 Philipp Hahn univentionstaff 2010-07-02 10:25:52 CEST
Weitere Problem waren das unglückliches Zusammenspiel von "univention-ssh -timeout X ssh -o NumberOfPasswordPrompts=Y". Das wurde inzwischen behoben.

Bei den Tests ist auch noch ein Problem mit Umlauten im Benutzernamen entdeckt worden, was an Bug #18750 korrigiert wurde.

Skript wurde auf 2.3->2.4_i386, 2.3->2.4_amd64 und 2.4_i386 getestet und läuft da jetzt durch. Das 2.4_amd64 ISO ist derzeit kaputt (Bug #18891), deswegen wurde das nicht explizit getestet.