Red Hat Bugzilla – Bug 1290731
[RFE] Support Host Keytab renewal
Last modified: 2016-05-10 17:14:28 EDT
+++ This bug was initially created as a clone of Bug #1288485 +++
Description of problem:
Support Active Directory keytab renewal, so that clients can be configured to renew the keytabs periodically. This functionality is especially useful when client is joined to Active Directory with enforced maximum password life.
Windows machines do the renewal automatically, in RHEL we would like to use adcli to renew the keytab. The renewal can be triggered by cron in the start and by SSSD in the future.
--- Additional comment from Sumit Bose on 2015-12-04 06:53:23 EST ---
The feature is tracked upstream at https://bugs.freedesktop.org/show_bug.cgi?id=92908
The test is ready for this feature, I have one question though.
After join the test run
# adcli update --computer-password-lifetime=0 --domain-controller=<IP> <AD_DOMAIN>
but the keys are not updated unless the password is at least 1 minute old.
With other words --computer-password-lifetime=0 does not enforce password change only if at least a minute elapses since the last update.
Is this the expected behavior?
No, this is not expected. Code-wise, even if the lifetime is 0 there is a check based on the current time of the client. My guess is that there is a 1 minute time difference between the DC and your client. But I agree that this is not obvious and lifetime == 0 should be handled as a special case which always forace an update without a comparison with the current time.
You are right, the behavior depends on the time difference between the host and AD. And I got quite interesting result depending if the time on host in ahead or behind the server time:
time diff on host | seconds to wait before update works
-180 | 133
-120 | 88
-60 | 47
-10 | 8
0 | 0
30 | 0
60 | 0
120 | 0
121 | ERR
The error when the time on host is more than 120 seconds above the AD time is:
! Couldn't get change password ticket for computer account: RHEL6T$: Requested effective lifetime is negative or too short
adcli: updating membership with domain ad.example.com failed: Couldn't get change password ticket for computer account: RHEL6T$: Requested effective lifetime is negative or too short
This shows that there is different behavior depending if the time diff is negative or positive. I'm not sure if the behavior can be unified, but if yes, that would definitely result in better user experience.
Created attachment 1116285 [details]
Force renewal if password lifetime is 0 even with clock skew
Stef, can you review the attache patch and include it upstream if you agree?
Attachment 1116285 [details] pushed as 650e5d3 - Force renewal if password lifetime is 0 even with clock skew
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.