Univention Bugzilla – Bug 18750
Sperrung des Benutzerkontos nach X erfolglosen Anmeldeversuchen
Last modified: 2018-11-27 14:12:12 CET
Pro UCS-System sollte konfiguriert werden können, nach wie viel erfolglosen Anmeldeversuchen der Benutzer gesperrt wird.
Vom Prinzip her erfüllt pam_tally die Anforderungen. Allerdings werden per Default die SSH-Anmeldeversuche nicht gespiechert, hier müsste ggf. die ssh-Konfiguration angepasst werden.
Mit geänderten SSH-Einstellungen funktioniert der Zähler, sshd_config: ChallengeResponseAuthentication yes PasswordAuthentication no Zusätzlich muss pam_tally in den PAM-Stack aufgenommen werden: account required pam_tally.so auth required pam_tally.so per_user Damit wird der Counter erhöht und eine Anmeldung kann entsprechend verhindert werden.
Das Zurücksetzen eines Accounts kann im Moment nur per faillog -r <user> erfolgen. Hier wäre eine Abbildung im LDAP sinnvoll. - ein Gesperrt-Falg für shadowAccounts - im UDM wird das Attribut gesperrt dafür verwendet - dieses Flag muss von den DCs und Memberserver gesetzt werden können - Zurücksetzen erfolgt per Listener - Das Sperren erfolgt per Listener - root sollte per Default ausgenommen werden, das sollte per UCR anpassbar sein, besser ist es, wenn der root-Login allgemein nicht erlaubt ist Fraglich ist, wie das Attribut im UDM gesetzt wird? Direkt aus dem PAM Stack oder per Cron oder per inotify.
(In reply to comment #3) > - ein Gesperrt-Falg für shadowAccounts Eine Alternative wäre locked und disabled zusammenzuführen. Ein shadowAccount kann über das ! im Passwort-Hash gelockt werden. Im UDM ist die Abbildung des ! im Passwort-Hash derzeit auf disabled. Die Unterscheidung zwischen locked und disabled sind die Samba Flags L und D. Die könnten dann über UDM nicht direkt unterschieden werden. Falls die Unterscheidung benötigt wird, so könnte ein Extended Attribute angezeigt werden, welches die Samba Account Flags abbildet.
Das wurde jetzt entsprechend umgesetzt. - Per Default deaktiviert - Aktivierung per auth/faillog - Limit per auth/faillog/limit einstellbar - Per Default gilt das nicht für root (auth/faillog/root) - Optional kann auth/faillog/unlock_time für ein automatisches Entsperren gesetzt werden - Mit auth/faillog/lock_global kann veranlasst werden, das der Benutzer auch direkt im LDAP gesperrt wird, das ist per Default nicht aktiv - Beim Entsperren im LDAP wird der lokale Counter zurückgesetzt
Created attachment 2483 [details] Test-Skript Die Variante "nur POSIX" funktioniert nicht; ein Login ist weiterhin möglich: # udm users/user modify --dn uid=$NAME,cn=users,$ldap_base --set locked=windows ; ssh_login "$passwd" ma46 # udm users/user modify --dn uid=$NAME,cn=users,$ldap_base --set locked=none ; ssh_login "$passwd" ma46 # udm users/user modify --dn uid=$NAME,cn=users,$ldap_base --set locked=posix ; ssh_login "$passwd" ma46 # udm users/user modify --dn uid=$NAME,cn=users,$ldap_base --set locked=all ; ssh_login "$passwd" Permission denied (publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive).
Problem ist folgendes, Heimdal wertet die Samba Account Flags aus, das bedeutet: locked: all pam_krb5 -> failed pam_ldap -> failed locked: windows pam_krb5 -> failed pam_ldap -> success locked: posix/ldap pam_krb5 -> success pam_ldap -> failed Ich würde jetzt vorschlagen einfach die Bezeichnung in Windows/Kerberos ändern.
Ich habe den Text jetzt angepasst.
Die Implementierung wurde auf i386(2.3->2.4), i386(2.4) und amd64(2.3->2.4) getestet. Leider gibt es gewisse Querabhängigkeiten zwischen Shadow, Ldap, Windows und Kerberos, die nicht ganz einfach zu überblicken sind. Diese sollten noch dokumentiert werden (Siege Bug #18836 Comment 1). ChangeLog-Eintrag ist vorhanden.
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".