Univention Bugzilla – Bug 53012
S4 Connector calculates wrong expire Date
Last modified: 2022-02-09 10:28:07 CET
Created attachment 10670 [details] Testing change of account expire date If you change the expiry date of a user, a wrong timestamp reaches samba. To reproduce simply change the expiry date of a user and verify timestamp in samba with Active Directory Users and Computers Tool in Windows or check timestamp in s4 by univention-s4search cn=testuser,cn=users,$(ucr get ldap/base) accountExpires and calculate timestamp however you want; the date will be different to the ldap attribute krb5ValidEnd. Find my test in attached video.
Can you attach the timezones of your UCS and AD server? Can you attach an LDIF of both objects (AD, UCS).
AFAIR Samba/AD interprets the userexpiry as "will expire after $expirydate", in UCS it is interpreted as "will expire at $expirydate". thats why we add/substract a day to the expirydate in the s4connector. Did you test that the user actually expired at different times in Samba vs UCS?
Created attachment 10671 [details] user in ldap
Created attachment 10672 [details] user in samba
(In reply to Florian Best from comment #1) > Can you attach the timezones of your UCS and AD server? There is no AD; I use a joined windows client for Active Directory Users and Computers. It has the same timezone as my UCS system (Berlin UTC+1) Also we are not talking about 3 or 4 hours, we are talking about a complete day. > Can you attach an LDIF of both objects (AD, UCS). There is no AD or do you mean samba? I attached ldif of my testuser of ldap and s4 (In reply to Julia Bremer from comment #2) > AFAIR Samba/AD interprets the userexpiry as "will expire after $expirydate", > in UCS it is interpreted as "will expire at $expirydate". > > thats why we add/substract a day to the expirydate in the s4connector. > Did you test that the user actually expired at different times in Samba vs > UCS? The customer reported that it happened, that the enduser was expired with their windows accounts before the in UCS configured expire date was reached. I did not test that, but I can/will do. I set UCS expire to 7.4.2021 so I should be able to use the account on 6.4.2021. The timestamp in samba is set to 132621408000000000 what means it will be expire on 6.4.2021 0:00. Looking at that timestamps, I expect the result of the customer reporting. I can not set it earlier; holiday...sorry. Also I tried to solve the problem by removing the -86400 in unix2s4_time of /usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py but the result was more confusing me.
(In reply to Julia Bremer from comment #2) > Did you test that the user actually expired at different times in Samba vs > UCS? Did the test now again; and yes I can login in UMC or use simple ldapbind: reiherwald.intranet / 1,54 / 12:28:04 / ✓ root@dc0:~ # ldapsearch -LLL -x -D "uid=ablauf,cn=users,dc=reiherwald,dc=intranet" -W uid=ablauf dn Enter LDAP Password: dn: uid=ablauf,cn=users,dc=reiherwald,dc=intranet but no longer via windows client or via kinit: reiherwald.intranet / 1,54 / 12:28:44 / ✓ root@dc0:~ # kinit ablauf ablauf@REIHERWALD.INTRANET's Password: kinit: krb5_get_init_creds: Clients credentials have been revoked
Another Customer complaint that.
And another customer reported the problem. Ticketnumber and customer ID added.
Created attachment 10872 [details] bug53012.patch In my test with a UCS 4.4-8 primary node this seemed to do the right thing. I quickly checked the behavior of the MS ADUC GUI: * If I select "today" (2021-12-08) then it interprets this as end of day localtime and writes: accountExpires: 132834780000000000 which is GMT: Wed, 08 Dec 2021 23:00:00 GMT Your time zone: Thu Dec 09 2021 00:00:00 GMT+0100 (Central European Standard Time) So it's just the MS desktop GUI that behaves weird. Surprise. But this also means that administrators may get confused by the difference between the date shown in MS ADUC and UMC (which in my example is "09.12.2021") or UDM (userexpiry: 2021-12-09). I guess we should use Bug 41574 to find a better way regarding the UDM/UMC UI and maybe also allow to specify a timezone.
Have tested the patch. Worked for me; did not find a pitfall. So removed waiting Support flag and set flag patch available.
I am not into the topic and therefore wondering a little bit about the patch. Do I understand this correctly, that the patch fixes (or extends) Bug #50202 / git:73695b3806873e8ed65c146baa6262d7e5ab5ee0 by reverting it partly? The patch changes the time conversion functions from prior UTC date-based to now a local-timezone-date-based. I hadn't looked up, what's done with the return value (probably given directly to UDM or S4-LDAP). I think that UDM still stores a local-timezone-date in LDAP instead of UTC (which is imho wrong) and we should better adjust UMC so it converts from UTC to the browsers local-time and vice-versa for appearance issues.
> The patch changes the time conversion functions from prior UTC date-based to now a local-timezone-date-based. That is correct. Because I saw a 2 hour offset between the Windows filetime (100 nanosecond) timestamp in accountExpires when written by ADUC as compared to what we write. > I hadn't looked up, what's done with the return value (probably given directly to UDM or S4-LDAP). Let me read that code for you: modlist.append((ldap.MOD_REPLACE, 'accountExpires', [str(unix2s4_time(ucs_admin_object['userexpiry'])).encode('ASCII')])) and ucs_admin_object['userexpiry'] = s42unix_time(int(ldap_object_ad['accountExpires'][0])) My patch fixes the current issue of the customer environment, which one could consider to be an improvement. If we fix the UDM timezone issue (Bug 46349) and decide upon Bug 54227, we probably will also need to adjust this patch accordingly, that's right.
Applied patch for s4 connector: 508ed36024 Bug #53012: update YAML for univention-s4-connector ae5f216544 Bug #53012: Include test case for athentication accountExpires on s4 connector 1dba2d1457 Bug #53012: update of s4 to unix parser date functions Include YAML adivisor Include changelog * The discrepancy of one day between the expiry in UCS and Samba has been removed.
I adjusted the advisory wording and rebuilt ucs-test Test: OK Patch applied: OK expiry synchronous: OK Yaml: OK Verified.
<https://errata.software-univention.de/#/?erratum=5.0x203>