Bug 8394 - Passwortablaufdatum bei pwdchangenextlogin verhält sich nicht eindeutig
Passwortablaufdatum bei pwdchangenextlogin verhält sich nicht eindeutig
Status: RESOLVED DUPLICATE of bug 46067
Product: UCS
Classification: Unclassified
Component: UMC - Users
UCS 4.3
All Linux
: P4 normal (vote)
: UCS 3.2-x
Assigned To: UMC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-01 09:15 CEST by Ingo Steuwer
Modified: 2018-04-13 13:29 CEST (History)
3 users (show)

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
Ablauf 30.05.07 (4.68 KB, text/plain)
2007-06-01 09:17 CEST, Ingo Steuwer
Details
Ablauf None (4.66 KB, text/plain)
2007-06-01 09:17 CEST, Ingo Steuwer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ingo Steuwer univentionstaff 2007-06-01 09:15:25 CEST
Aufgefallen bei der Schüleradministration in UMC, ein "Passwort-Reset" wird dort durch Setzen eines neuen Passworts und der Flags "changeonnextlogin" und "ignorepasswordhistory" vorgenommen.

Wird das wiederholt gemacht, gibt Univention Admin abwechselnd ein korrektes Passwortablaufdatum ("gestern") und "None" aus.

Beispiele als Attachment: Erst war Ablaufdatum 30.05.07, nach dem Setzen wird es als "None" angezeigt.

Target Milestone kann evtl. auf 2.0 gesetzt werden.
Comment 1 Ingo Steuwer univentionstaff 2007-06-01 09:17:01 CEST
Created attachment 698 [details]
Ablauf 30.05.07
Comment 2 Ingo Steuwer univentionstaff 2007-06-01 09:17:15 CEST
Created attachment 699 [details]
Ablauf None
Comment 3 Ingo Steuwer univentionstaff 2007-06-01 09:35:31 CEST
python2.4-univention-admin ist Version 0.48.10-1.373.200705301708
Comment 4 Felix Botner univentionstaff 2008-10-30 14:02:11 CET
Situation:

   * Benutzer mit Ablaufdatum, das abgelaufen ist
   * keine Richtlinie um Passwörter nach x Tagen zu ändern
   * jetzt will ich dem Benutzer ein neues Passwort und das Flag 
     "pwdChangeNextLogin=1", also Passwort ändern, geben

   -> udm users/user modify --dn uid=hans,dc=school \
      --set pwdChangeNextLogin=1 --set password=224gk4hg3hk4g

das UDM module users/user.py verhält sich wie folgt:

__init__:

es wird das Ablaufdatum ermittelt und auf "self.info['passwordexpiry']" gesetzt
(nur falls es shadowMax gibt)

open:

es wird geschaut, ob "self.info['passwordexpiry']" abgelaufen ist, und falls ja 
"self['pwdChangeNextLogin']='1'", was im Beispiel der Fall ist


_ldap_modlist:

hier wird geschaut, ob

if self.hasChanged('"') and self['pwdChangeNextLogin'] == '1':
      pwd_change_next_login == 1

aber "pwdChangeNextLogin" hat sich nicht geändert, es wurde ja schon in "open" auf 1 gesetzt und damit wird  "pwd_change_next_login" nicht gesetzt, 1. Problem

später wird (falls keine Policy vorhanden ist), 

ml.append(('shadowMax',self.oldattr.get('shadowMax', [''])[0], ''))

gesetzt, dann wird geschaut ob "pwdChangeNextLogin" gesetzt ist

if pwd_change_next_login == 1:

um noch einige Dinge darin zu regeln. Nehmen wir mal an, dass es das 1. 
Problem nicht gäbe und man in diesen Block kommt, dann wird
dort richtigerweise irgendwann

ml.append(('shadowMax',self.oldattr.get('shadowMax', [''])[0], shadowMax))

gesetzt (bei uns wäre beide shadowMax auf 1), aber in der ml gibt es ja schon
einen shadowMax Eintrag

print ml 
('shadowMax',1 , '')
...
('shadowMax',1 , '1')

shadowMax wird also von 1 auf nix gesetzt, kann dann aber nicht wieder auf 1 
gesetzt werden, da müsste wohl das alte shadowMax aus ml entfernt werden.


das ganze verhält sich nur so, wenn das Passwort und "pwdChangeNextLogin" gleichzeitig gesetzt werden, wenn man es nacheinander macht, dann wird beim 
Setzen des Passworts das Ablaufdatum gelöscht und man kann dann im 2. Schritt
"pwdChangeNextLogin" setzen.

das wurde nun auch im UMC school admin gemacht (ur ist das users/user.py Modul)

def _reset_passwords
...
ur.open()
ur['password'] = newPassword
ur['pwdChangeNextLogin'] = '1'
dn = ur.modify()
...
# if passwordMustChange:
ur = univention.admin.objects.get(self.usermodule, None, lo, None, dn)
ur.open()
ur['pwdChangeNextLogin'] = '1'
dn = ur.modify()
...




Comment 5 Florian Best univentionstaff 2018-01-22 18:43:10 CET

*** This bug has been marked as a duplicate of bug 46067 ***