Bug 1290731 - [RFE] Support Host Keytab renewal
[RFE] Support Host Keytab renewal
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: adcli (Show other bugs)
6.7
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Sumit Bose
Patrik Kis
: FutureFeature
Depends On: 1288485
Blocks: 1272422 1290761 1310877
  Show dependency treegraph
 
Reported: 2015-12-11 04:19 EST by Martin Kosek
Modified: 2016-05-10 17:14 EDT (History)
5 users (show)

See Also:
Fixed In Version: adcli-0.8.0-1.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 1288485
Environment:
Last Closed: 2016-05-10 17:14:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Force renewal if password lifetime is 0 even with clock skew (1.70 KB, patch)
2016-01-19 12:26 EST, Sumit Bose
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 92908 None None None Never

  None (edit)
Description Martin Kosek 2015-12-11 04:19:43 EST
+++ 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
Comment 3 Patrik Kis 2016-01-08 11:37:19 EST
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?
Comment 4 Sumit Bose 2016-01-08 12:18:27 EST
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.
Comment 5 Patrik Kis 2016-01-11 11:41:38 EST
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.
Comment 6 Sumit Bose 2016-01-19 12:26 EST
Created attachment 1116285 [details]
Force renewal if password lifetime is 0 even with clock skew
Comment 7 Sumit Bose 2016-01-19 12:27:32 EST
Stef, can you review the attache patch and include it upstream if you agree?
Comment 8 Stef Walter 2016-01-19 14:58:04 EST
Attachment 1116285 [details] pushed as 650e5d3 - Force renewal if password lifetime is 0 even with clock skew
Comment 11 errata-xmlrpc 2016-05-10 17:14:28 EDT
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.

https://rhn.redhat.com/errata/RHEA-2016-0828.html

Note You need to log in before you can comment on or make changes to this bug.