Bug 27452 - AD-Connector sollte IMHO besser shadowMax berücksichtigen statt es zu löschen
AD-Connector sollte IMHO besser shadowMax berücksichtigen statt es zu löschen
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: AD Connector
UCS 3.0
Other Linux
: P5 enhancement (vote)
: ---
Assigned To: Connector maintainers
:
Depends on:
Blocks: 42524
  Show dependency treegraph
 
Reported: 2012-06-05 14:23 CEST by Arvid Requate
Modified: 2016-10-11 08:02 CEST (History)
1 user (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 Arvid Requate univentionstaff 2012-06-05 14:23:50 CEST
Wenn im AD ein Passwort geändert wird, dann aktualisert der AD Connector in UCS das sambaPwdLastChange Attribut und entfernt shadowMax, shadowLastChange und krb5PasswordEnd. Dies tut er, weil er nicht die aktuelle UDM-Policy auswertet und daher nicht den aktuellen Wert für das Passwort-Ablaufintervall kennt.

Dies führt dazu, dass erstens UDM kein Passwort-Ablaufdatum mehr am Benutzerkonto anzeigt und dass zweitens ein Benutzer dann spänter bei abgelaufenem Samba-Passwort unbegrenzt z.B. ssh-Login nutzen kann.

Meiner Meinung nach wäre es in diesem Fall vorzuziehen, den exisiterenden Wert für shadowMax zu berücksichtigen, als den Passwortablauf vollständig zu deaktivieren. Ein exisiterendes shadowMax-Attribut am Benutzerkonto zeigt an, dass zu einem früheren Zeitpunkt explizit im UDM ein Passwortablaufdatum für dieses Konto erstens definiert und zweitens effektiv angewendet wurde. Für mich stellt es eine stärkere Regression dar, wenn diese dann plötzlich nicht mehr berücksichtigt wird, als der Fall, in dem diese Policy in der Zwischenzeit erstens umdefiniert und zweitens *nicht* per UDM-Passwortänderung am Benutzerobjekt effektiv angewendet wurde und also ein veralteter shadowMax-Wert am Benutzerobjekt Verwendung findet.

IMHO sollte dieses Verhalten daher per UCR anpassbar sein.
Comment 1 Stefan Gohmann univentionstaff 2016-09-28 08:31:12 CEST
It seems to be still valid, We fixed it in the S4 Conenctor, see Bug #36317.
Comment 2 Stefan Gohmann univentionstaff 2016-10-11 08:02:22 CEST
This issue has been filed against UCS 3.0.

UCS 3.0 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please reopen.