Bug 36107 - Possible behaviour change in account expiration date (shadowExpire)
Possible behaviour change in account expiration date (shadowExpire)
Status: CLOSED WONTFIX
Product: UCS
Classification: Unclassified
Component: PAM
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.0
Assigned To: Felix Botner
Arvid Requate
: interim-3
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-09 12:03 CEST by Sönke Schwardt-Krummrich
Modified: 2014-11-26 06:54 CET (History)
2 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

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2014-10-09 12:03:07 CEST
While implementing a testscript for bug 35900 Ammar discovered a possible change in the expiration date behaviour:

> I discoverd what made my authentication fails under UCS-4.0 yesterday, that 
> expiration under UCS-4.0 is handled in a different way than in UCS-3.2:
> - in UCS-3.2: user still be able to authenticate if 
>   current date >= expiration date
> - in UCS-4.0: user is able to authenticate only if 
>   current date > expiration date

It should be checked if this affects UCS components negatively and/or if the manual has to be updated.

We should also implement a test if the behaviour change has been affirmed.
Ammars test script from bug 35900 may be used to also test UMC authentication if the following code fragment is added:
   UMCConnection(ucr.get('hostname')).auth(username, passwd)
Comment 1 Felix Botner univentionstaff 2014-10-22 12:35:49 CEST
> > I discoverd what made my authentication fails under UCS-4.0 yesterday, that 
> > expiration under UCS-4.0 is handled in a different way than in UCS-3.2:
> > - in UCS-3.2: user still be able to authenticate if 
> >   current date >= expiration date
> > - in UCS-4.0: user is able to authenticate only if 
> >   current date > expiration date

Yes, confirmed

UCS 3.2 and UCS 4.0

dn: uid=test1,cn=users,dc=w2k12,dc=test
shadowExpire: 16365

-> date
Mi 22. Okt 12:23:47 CEST 2014

UCS 3.2
-> su test1
test1@master:/root$

UCS 4.0
-> su test1
Ihr Konto ist abgelaufen. Wenden Sie sich an den Systemadministrator
su: Benutzerkonto ist abgelaufen


> It should be checked if this affects UCS components negatively 
i cant see how, but haven't really tested  

> and/or if the manual has to be updated.
no, the manual says

  "A date is specified in this input field on which the account will
   automatically be locked."


> 
> We should also implement a test if the behaviour change has been affirmed.
> Ammars test script from bug 35900 may be used to also test UMC
> authentication if the following code fragment is added:
>    UMCConnection(ucr.get('hostname')).auth(username, passwd)


Can Ammar do this?
Comment 2 Felix Botner univentionstaff 2014-10-29 14:47:20 CET
One more thing, in UCS 4.0 the account expires now if the expiration date is reached.

Posix account expired
UCS-3.2: expiration date > current date
UCS-4.0: expiration date >= current date

In contrast kinit still works if expiration date is reached.

Kinit:
UCS-3.2: expiration date > current date
UCS-4.0: expiration date > current date
Comment 3 Felix Botner univentionstaff 2014-10-31 11:13:05 CET
Nothing more to do here.
Comment 4 Arvid Requate univentionstaff 2014-11-04 13:46:58 CET
ok
Comment 5 Stefan Gohmann univentionstaff 2014-11-26 06:54:48 CET
UCS 4.0-0 has been released:
 http://docs.univention.de/release-notes-4.0-0-en.html
 http://docs.univention.de/release-notes-4.0-0-de.html

If this error occurs again, please use "Clone This Bug".