Univention Bugzilla – Bug 54724
Self password change not possible if future account expiry date is set to a date later than 2038-01-20
Last modified: 2023-06-07 12:14:12 CEST
If an account has a expiry date in the future (like 1/1/2099) it is not possible the change the password via the Self-Service password change, instead the errorcode 13: 'The account is expired and can not be used anymore.' is thrown. Workaround is to delete the expiry date as it is not reached while doing the password change, but this does not scale for automatically provisioned environments.
Only happens to users which userexpiry is set to later then 2038-01-20. a kinit of that user already says the user were expired. krb5ValidEnd: 20380120000000Z shadowExpire: 24856 Y2038 problem in heimdal?
Does it also happen with Samba 4 being installed?
(In reply to Florian Best from comment #2) > Does it also happen with Samba 4 being installed? No samba uses windows time to calculate user expiry
I reduced the "user pain" categories, as the described situation is not the default for new accounts -- and from my point of view I don't see the benefit of an expiry date which is >15 years in the future.
On the one hand the problem does affect many, if not all customers, but I would go along with the rating as there is no expiry date +15 years in most environments, thats true. But I am unsure about the bug type: For the customer experiencing the bug it will be a deal breaker if this won't be fixed soon as the user lifecycle depends on a working self-service. Origin of this procedure is that the leading system has school bound validities whereas we have an account bound validity - To connect both there is a middleware which calculates expiry dates. The term 01.01.2099 has it's origin in the leading system, so all workarounds would breach parity between both systems. If we cannot provide a fix before the productive usage starts there will be many users experiencing this and I would tend to say that the initial Onboarding is a key scenario for this kind of environment.
(In reply to Jan-Luca Kiok from comment #5) > On the one hand the problem does affect many, if not all customers, but I > would go along with the rating as there is no expiry date +15 years in most > environments, thats true. > But I am unsure about the bug type: For the customer experiencing the bug it > will be a deal breaker if this won't be fixed soon as the user lifecycle > depends on a working self-service. > Origin of this procedure is that the leading system has school bound > validities whereas we have an account bound validity - To connect both there > is a middleware which calculates expiry dates. The term 01.01.2099 has it's > origin in the leading system, so all workarounds would breach parity between > both systems. > > If we cannot provide a fix before the productive usage starts there will be > many users experiencing this and I would tend to say that the initial > Onboarding is a key scenario for this kind of environment. I assume it is way easier to have a UDM hook that removes expiry dates > 2037 in one customer environment then to debug, fix and maintain a bugfix in heimdal for all customers.