The kerberos principal expiration time is expressed as a UTC timestamp. When a user authenticates with kinit, the timezone is properly processed, but ldapbind does not seem to do the same processing.
[frenaud] it looks like the issue comes from daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c, in the ipapwd_pre_bind method. The method is using mktime() and comparing to the current time obtained with time(NULL). According to its man page, mktime is considering the time as local time:
The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation.
while time(NULL) is expressing the time since the epoch.
Other parts of the code are using timegm() for converting struct tm * values to time_t. timegm() takes the input value to be Coordinated Universal Time (UTC).
[ab] so instead of mktime() we probably should use timegm(). The problem is that it is non-standard GNU extension and it is recommended (in the man page for timegm(3)) to avoid its use. An alternative is to set TZ=UTC, call mktime(), unset TZ, but since we are running in a multi-threaded environment this is problematic.
On the other hand, we already rely on GNU extensions and enable them with -D_DEFAULT_SOURCE=1, so use of timegm() is enabled already.
The fix, therefore, would be to use timegm() instead of mktime() in daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c in two places where we first do 'strptime()' with Zulu time zone (in ipapwd_pre_bind() and ipapwd_write_krb_keys()).
Metadata Update from @frenaud: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1826659
PR: https://github.com/freeipa/freeipa/pull/4775
Metadata Update from @abbra: - Issue assigned to abbra
master:
ipa-4-6:
ipa-4-8:
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @abbra: - Custom field changelog adjusted to LDAP authentication now handles Kerberos principal and password expiration time in UTC time zone. Previously, a local server time zone was applied even though UTC was implied in the settings.
Login to comment on this ticket.