Bug 50202 - s4-connector changes userexpiry += 1 day in a loop on certain timezones
s4-connector changes userexpiry += 1 day in a loop on certain timezones
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-2-errata
Assigned To: Julia Bremer
Florian Best
:
: 46546 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-17 14:19 CEST by Christina Scheinig
Modified: 2021-12-08 14:56 CET (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.229
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support: Yes
Flags outvoted (downgraded) after PO Review:
Ticket number: 2019091221001038
Bug group (optional):
Max CVSS v3 score:


Attachments
fix_conversion_between_userexpiry_and_accountExpires.patch (1.23 KB, patch)
2019-10-28 16:37 CET, Arvid Requate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2019-09-17 14:19:26 CEST
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.
Comment 1 Florian Best univentionstaff 2019-10-23 13:05:09 CEST
This might be a duplicate of Bug #46349, not sure.
Comment 2 Florian Best univentionstaff 2019-10-23 13:41:20 CEST
It could also be Bug #46546.
Comment 3 Julia Bremer univentionstaff 2019-10-25 11:11:22 CEST
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.
Comment 4 Florian Best univentionstaff 2019-10-25 14:51:42 CEST
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.
Comment 5 Arvid Requate univentionstaff 2019-10-28 16:37:54 CET
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.
Comment 6 Julia Bremer univentionstaff 2019-10-29 18:48:19 CET
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.
Comment 7 Florian Best univentionstaff 2019-10-30 12:57:56 CET
*** Bug 46546 has been marked as a duplicate of this bug. ***
Comment 8 Florian Best univentionstaff 2019-10-30 15:33:35 CET
OK: problem reproduced
OK: problem fixed (86400 seconds are appended to userexpiry)
OK: test case
OK: YAML
Comment 9 Arvid Requate univentionstaff 2019-11-06 14:41:02 CET
<http://errata.software-univention.de/ucs/4.4/330.html>