Bug 1290731
| Summary: | [RFE] Support Host Keytab renewal | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Martin Kosek <mkosek> | ||||
| Component: | adcli | Assignee: | Sumit Bose <sbose> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.7 | CC: | enewland, pkis, qe-baseos-security, sbose, stefw | ||||
| Target Milestone: | rc | Keywords: | FutureFeature | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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 21:14:28 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1288485 | ||||||
| Bug Blocks: | 1272422, 1290761, 1310877 | ||||||
| Attachments: |
|
||||||
|
Description
Martin Kosek
2015-12-11 09:19:43 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? 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. https://rhn.redhat.com/errata/RHEA-2016-0828.html |