Zarafa Slave / Kontoanmeldung wird nicht deaktiviert

Apps & App Center
#21

Beim Ausführen erhalte ich folgende Meldugn :

[code]root@ucs:~# ./lockacc2.py
File “./lockacc2.py”, line 89

                                                     ^

IndentationError: expected an indented block
[/code]

#22

Auf der WebSVN Seite ist oben ein Download Link. Bitte den verwenden und die Datei speichern. Der IndentationError deutet auf ein Kopieren via Browser hin.

Hoffe das hilft.

#23

Ja, hat geholfen.

Die Konten werden auch deaktiviert, allerdings nach Änderung des Passworts durch den User über der Weboberfläche steht kein Passwortablaufdatum mehr drin (Richtlinie ist aber noch hinterlegt.)

#24

Hallo

[quote=“Fiddler”]Ja, hat geholfen.

Die Konten werden auch deaktiviert, allerdings nach Änderung des Passworts durch den User über der Weboberfläche steht kein Passwortablaufdatum mehr drin (Richtlinie ist aber noch hinterlegt.)[/quote]

Nur noch einmal kurz das Szenario:
[ul]
[li] Passwort ist laut Passwort-Ablaufdatum abgelaufen[/li]
[li] Das Script hat den Account (posix) gesperrt[/li]
[li] Anmeldung an Zarafa ist nicht mehr möglich[/li]
[li] Anmeldung an der UMC mit dem gesperrten Benutzer hat funktioniert und führt direkt zu einem Passwort-Wechsel, das Passwort wurde hier dann neu gesetzt[/li]
[li] Anmeldung an Zarafa funktioniert wieder, das Ablaufdatum ist aber nicht mehr gesetzt.[/li][/ul]

Sind die Attribute shadowMax und shadowLastChange am Benutzer gesetzt?

-> univention-ldapsearch uid=$UID_DES_BENUTZERS shadowLastChange shadowMax

Die Richtlinie ist auch noch verknüpft?

[code]-> univention-policy-result -D “$(ucr get ldap/hostdn)” -y /etc/machine.secret “$DN_DES_BENUTZERS” | grep -A 2 -B 2 univentionPWExpiryInterval

Policy: cn=test1,cn=pwhistory,cn=users,cn=policies,dc=fff,dc=ggg
Attribute: univentionPWExpiryInterval
Value: 1[/code]

Falls shadowMax und shadowLastchange gesetzt sind, sollte der UDM auch ein entsprechendes Ablaufdatum anzeigen.

udm users/user list --filter username=test1| grep passwordexpiry
#25 
univention-policy-result -D "$(ucr get ldap/hostdn)" -y /etc/machine.secret "uid=testuser,cn=users,dc=domain,dc=de" | grep -A 2 -B 2 univentionPWExpiryInterval

Policy: cn=default-settings,cn=pwhistory,cn=users,cn=policies,dc=mydomain,dc=de
Attribute: univentionPWExpiryInterval
Value: 90

udm users/user list --filter username=testuser | grep passwordexpiry
passwordexpiry: None

Anscheinend funktioniert die Verknüpfung nicht?

Außerdem : Wird beim Konto das Anmeldeverfahren “nur POSIX/LDAP” gesperrt,somit kann keine Passwortänderung vollzogen werden,da der User sich nicht bei der Weboberfläche anmelden kann.

Und : Wenn das beim User das Häckchen “Passwort bei der nächsten Anmeldung ändern” gesetzt ist, kann er sich trotzdem mit dem alten Passwort anmelden,dass sollte auch nicht so sein. Also beim aktivem Hacken - Sperrung bei Zarafa bzw. ThirdParty Applikation.

#26

Hallo,

leider sind im Zusammenhang mit der Sperrung des Kontos beim Ablauf des
Passworts noch weitere Probleme aufgetreten, u.a. das von Ihnen beobachtete
Verhalten, dass das Passwort-Ablaufdatum beim Ändern des Passworts entfernt wird,

https://forge.univention.org/bugzilla/show_bug.cgi?id=36317

das die Anmeldung an der UMC u.U. nicht funktioniert

https://forge.univention.org/bugzilla/show_bug.cgi?id=36319

und das der Passwort-Lock u.U. beim Passwort-Wechsel nicht zurückgenommen wird.

https://forge.univention.org/bugzilla/show_bug.cgi?id=36318

Diese drei Probleme im Zusammenhang mit der Sperrung des Kontos werden wir leider
nicht mehr zu UCS 3.2 beheben können. Die entsprechenden Erweiterungen bzw.
Anpassungen sind aber direkt im Anschluss an das Release von UCS 4.0 vorgesehen.

“Passwort bei der nächsten Anmeldung ändern” setzt die entsprechenden LDAP-Attribute richtig
(shadowMax, krb5PasswordEnd). Jedoch ist es für die Sperrung des Accounts (keine LDAP
Authentifizierung) nötig das oben genannte Script ausführen (dieses schaut sich die
entsprechenden Attribute am Benutzerobjekt an und sperrt dann ggf. die LDAP Authentifizierung).
Dies Script wird zukünftig über einen Cron-Job automatisch gestartet.

Mit freundlichen Grüßen
Felix Botner

Mastodon