Bug 732468
| Summary: | ipa-client-install should set LDAPSASL_NOCANON when calling ipa-getkeytab | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Marko Myllynen <myllynen> |
| Component: | ipa | Assignee: | Rob Crittenden <rcritten> |
| Status: | CLOSED ERRATA | QA Contact: | Chandrasekar Kannan <ckannan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | benl, dpal, jgalipea, jhrozek, mkosek, nsoman, ssorce |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ipa-2.1.1-1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: When IPA client A/PTR DNS records does not match, /usr/sbin/ipa-getkeytab and /usr/sbin/ipa-join refuses to operate.
Consequence: If the client A/PTR records does not match, the client cannot be enrolled to IPA server and installation always fails. This is too strict requirement for client machine.
Fix: Do not require A/PTR match in /usr/sbin/ipa-getkeytab and /usr/sbin/ipa-join.
Result: IPA client can be enrolled to IPA server and ipa-client-install should succeed even when its A/PTR DNS records does not match.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-06 18:30:14 UTC | Type: | --- |
| 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: | 732935, 748866 | ||
| Bug Blocks: | |||
|
Description
Marko Myllynen
2011-08-22 14:51:02 UTC
We better change our binaries to set LDAP_OPT_X_SASL_NOCANON with ldap_set_option() With a flag, right? This is probably not a good default is it? (In reply to comment #3) > With a flag, right? This is probably not a good default is it? makes sense to do it with a flag. Upstream ticket: https://fedorahosted.org/freeipa/ticket/1693 Was this failing in ipa-join or just ipa-getkeytab? I think it was the ipa-getkeytab based on the mail thread but it might make sense to check both. > Was this failing in ipa-join or just ipa-getkeytab? Yes, there was an issue also with ipa-join, I can check the details later when connected to my test network. However, if this to be fixed with a flag as suggested in comment 4 then the flag should be used for SSSD configuration as well, see https://fedorahosted.org/sssd/ticket/978, otherwise this won't be very helpful. Thanks. The SSSD changes are independent of our setting an environment variable during the installer. Or in other words, we are going to need to modify the SSSD configuration regardless of how we fix this in IPA. > Yes, there was an issue also with ipa-join, I can check the details later when
> connected to my test network.
This was caused by an issue in current xmlrpc-c packages. With latest packages from Brew ipa-join works all ok.
Fixed upstream. master: a750ccb5a2c525e9c117f6139583a710ec4fb656 ipa-2-1: aad2aecb34b723cd322f46ea4aa7c349e9f5f465 To test: Set the IPA server's reverse DNS to a different host then try to enroll a client. Make sure the client doesn't have a host entry for the server in /etc/hosts. If the enrollment is successful then the bug is fixed. When starting: Server IP: 10.16.18.99 Client IP: 10.16.18.91 server has reverse zone: Zone name: 18.16.10.in-addr.arpa. Based on instructions above, tested following steps below: deleted - Zone name: 18.16.10.in-addr.arpa. added - Zone name: 19.16.10.in-addr.arpa. client doesn't have a host entry for the server in /etc/hosts Install was successful, was able to kinit. Verified forward record for this host is present To continue on: deleted - Zone name: 19.16.10.in-addr.arpa. added - Zone name: 18.16.10.in-addr.arpa. ..to come back to original install. Changed Client IP to be - 10.16.19.91 ...to put client in a different zone than ipa server. Install was successful, was able to kinit. But forward record for this host is not present in server. Unable to ssh client from ipa server. NeedInfo - is the behaviour in second scenario correct? are the first and second tests valid to verify this bug? Not sure I understand what you're testing here. The problem is when the A and PTR records do not match. The zone doesn't really matter. Verified using: ipa-server-2.1.2-2.el6.x86_64 Added a host with mismatched A/PTR records. Installed ipa-client....and was successful.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause: When IPA client A/PTR DNS records does not match, /usr/sbin/ipa-getkeytab and /usr/sbin/ipa-join refuses to operate.
Consequence: If the client A/PTR records does not match, the client cannot be enrolled to IPA server and installation always fails. This is too strict requirement for client machine.
Fix: Do not require A/PTR match in /usr/sbin/ipa-getkeytab and /usr/sbin/ipa-join.
Result: IPA client can be enrolled to IPA server and ipa-client-install should succeed even when its A/PTR DNS records does not match.
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. http://rhn.redhat.com/errata/RHSA-2011-1533.html |