Univention Bugzilla – Bug 50202
s4-connector changes userexpiry += 1 day in a loop on certain timezones
Last modified: 2021-12-08 14:56:58 CET
Admin makes this change to user schein113182 (note: shadowExpire): START DN: uid=cxp113182,cn=users,dc=schein,dc=usa ID: 38895801 Modifier: cn=admin,dc=schein,dc=usa Timestamp: 12.09.2019 21:06:07 Action: modify Old values: shadowExpire: 19309 krb5ValidEnd: 20221112000000Z sambaKickoffTime: 1668236400 entryCSN: 20190912205903.308901Z#000000#000#000000 modifyTimestamp: 20190912205903Z New values: shadowExpire: 19310 krb5ValidEnd: 20221113000000Z sambaKickoffTime: 1668322800 entryCSN: 20190912210607.568366Z#000000#000#000000 modifyTimestamp: 20190912210607Z END Then, 7 minutes later, admin makes another change to the same UID (note: shadowExpire): START DN: uid=cschein113182,cn=users,dc=schein,dc=usa ID: 38896909 Modifier: cn=admin,dc=schein,dc=usa Timestamp: 12.09.2019 21:13:50 Action: modify Old values: shadowExpire: 19310 krb5ValidEnd: 20221113000000Z sambaKickoffTime: 1668322800 entryCSN: 20190912210607.568366Z#000000#000#000000 modifyTimestamp: 20190912210607Z New values: shadowExpire: 19311 krb5ValidEnd: 20221114000000Z sambaKickoffTime: 1668409200 entryCSN: 20190912211350.010460Z#000000#000#000000 modifyTimestamp: 20190912211350Z END This is happening hundreds of times per day on the same UID, and this is also happening to hundreds of different users. All users with this issue are set 'Deactivated'. For additional logfiles, please see the ticket attachements. This issue could be related to Bug 41574 The customer needs a workaround, so the database will not burst with nonsense entries soon.
This might be a duplicate of Bug #46349, not sure.
It could also be Bug #46546.
This issue does not seem to be the timezone Bug #41574 or Bug #46349. The logs show multiple sync_from_ucs for the same objects following each other, without a sync_to_ucs inbetween. First, shadowExpire is set from an int which is representing the expiration date of the Account to 1, which means the Account is disabled. Then the next sync_from_ucs happens where shadowExpire is set from 1 to the expiration date + 1 day. My best guess at the moment is, that one of the extended Attributes univentionFreeAttribute20': [u'10.09.19'] univentionFreeAttribute19': [u'1'], u'description': [u'AutoTermed on 10/09/2019'] is mapped to existing attributes and causing a conflict if the user is expired. Without looking into the mapping of the Customer, I can't confirm this theory though.
I would like to get remote access to the system or see the output of the following commands on the system: univention-check-templates cat /etc/timezone; date; date --utc cat /etc/univention/connector/s4/mapping.py univention-ldapsearch -LLL univentionObjectType=settings/extended_attribute univention-ldapsearch -b "uid=cxp113182,cn=users,$(ucr get ldap/base)" ps aufx (In reply to Julia Bremer from comment #3) > This issue does not seem to be the timezone Bug #41574 or Bug #46349. > > The logs show multiple sync_from_ucs for the same objects following each > other, without a sync_to_ucs inbetween. > First, shadowExpire is set from an int which is representing the expiration > date of the Account to 1, which means the Account is disabled. > Then the next sync_from_ucs happens where shadowExpire is set from 1 to the > expiration date + 1 day. We receied two logfiles. I can see both a sync_from_ucs and a sync_to_ucs for the user from comment #0 on different days. Can you tell which logfile at which time and which user? > My best guess at the moment is, that one of the extended Attributes > > univentionFreeAttribute20': [u'10.09.19'] > univentionFreeAttribute19': [u'1'], u'description': [u'AutoTermed on > 10/09/2019'] > > is mapped to existing attributes and causing a conflict if the user is > expired. So your idea is that "univentionFreeAttribute20" is mapped to "userexpiry"? If this would be true, this is an unsupported scenario. I doubt this a little bit: For me the description "AutoTermed on ..." looks like that there is a service which deactivates the user when that certain date (in german notation) is reached. This could of course also be the component which changes the user over and over again.
Created attachment 10221 [details] fix_conversion_between_userexpiry_and_accountExpires.patch I was able to trigger this on my VM by using: ===================================================================== root@master10:~# timedatectl set-timezone UTC root@master10:~# timedatectl Local time: Mi 2019-10-09 17:27:08 UTC Universal time: Mi 2019-10-09 17:27:08 UTC RTC time: Mo 2019-10-28 15:13:06 Time zone: UTC (UTC, +0000) Network time on: yes NTP synchronized: yes RTC in local TZ: no root@master10:~# /etc/init.d/univention-s4-connector restart root@master10:~# udm users/user create --set username=user6 \ --set lastname=last1 \ --set password=univention \ --set userexpiry="30.10.19" WARNING: The object is not going to be created underneath of its default containers. Object created: uid=user6,dc=ar41i1,dc=qa ===================================================================== Also reproducable with America/Denver (utc-6) and Pacific/Pago_Pago (utc-11). The attached patch should fix this and consider that the value of shadowExipre excludes the day, while Active Directory sets accountExpires to the timestamp at the end of the day (see Bug 41574 Comment 10). FYI: The Active Directory Users and Computers GUI tool shows the accountExpires value converted to localtime, i.e. if you use the tool to set the account expiry date to 30.10.19 then it stores this as a value corresponding to "30.10.2019 23:00:00 UTC" in accountExpires, but it shows 31.10.2019 00:00:00 MEZ in the GUIs. Using localtime in the GUI may be the user experience that the Admin expects and that's what my patch for Bug 41574 wanted to implement in UDM/UMC too. Let's use Bug 41574 to fix the UDM users/user behavior in a separate step.
515a665eea Bug #50202: Yaml 622c211ac8 Bug #50202: version bump 4e1b1e0e00 Bug #50202: Merge branch 'jbremer/50202' into 4.4-2 21073b4c29 Bug #50202: Test to check if userexpiry increments in a s4connector loop in certain timezones 73695b3806 Bug #50202: Fix userexpiry timezone Loop Successful build Package: univention-s4-connector Version: 13.0.2-57A~4.4.0.201910291818 Branch: ucs_4.4-0 Scope: errata4.4-2 Due to errors in unix2s4time and s42unixtime, userexpiry was incremented indefinitely in certain timezones. This problem has been fixed. It is still not clear if the customer had this exact issue and/or other problems.
*** Bug 46546 has been marked as a duplicate of this bug. ***
OK: problem reproduced OK: problem fixed (86400 seconds are appended to userexpiry) OK: test case OK: YAML
<http://errata.software-univention.de/ucs/4.4/330.html>