RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1290731 - [RFE] Support Host Keytab renewal
Summary: [RFE] Support Host Keytab renewal
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: adcli
Version: 6.7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On: 1288485
Blocks: 1272422 1290761 1310877
TreeView+ depends on / blocked
 
Reported: 2015-12-11 09:19 UTC by Martin Kosek
Modified: 2016-05-10 21:14 UTC (History)
5 users (show)

Fixed In Version: adcli-0.8.0-1.el6
Doc Type: Enhancement
Doc Text:
Clone Of: 1288485
Environment:
Last Closed: 2016-05-10 21:14:28 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 92908 0 None None None Never
Red Hat Product Errata RHEA-2016:0828 0 normal SHIPPED_LIVE adcli bug fix and enhancement update 2016-05-10 22:40:59 UTC

Description Martin Kosek 2015-12-11 09:19:43 UTC
+++ 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 16:37:19 UTC
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 17:18:27 UTC
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 16:41:38 UTC
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 17:26:45 UTC
Created attachment 1116285 [details]
Force renewal if password lifetime is 0 even with clock skew

Comment 7 Sumit Bose 2016-01-19 17:27:32 UTC
Stef, can you review the attache patch and include it upstream if you agree?

Comment 8 Stef Walter 2016-01-19 19:58:04 UTC
Attachment 1116285 [details] pushed as 650e5d3 - Force renewal if password lifetime is 0 even with clock skew

Comment 11 errata-xmlrpc 2016-05-10 21:14:28 UTC
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.