Bug 1256071 - IPv6 only host with a dual stack IPA server tries to use IPv4 on a kinit
IPv6 only host with a dual stack IPA server tries to use IPv4 on a kinit
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5 (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Robbie Harwood
BaseOS QE Security Team
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2015-08-23 16:26 EDT by Matt Willsher
Modified: 2016-03-14 16:49 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-03-14 16:49:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
matt: needinfo-

Attachments (Terms of Use)

  None (edit)
Description Matt Willsher 2015-08-23 16:26:52 EDT
Description of problem:

IPA server is configured with IPv4 and IPv6 addresses and those address in DNS.
kinit admin on a client with only IPv6 addresses tries to use the IPv4 address and fails. 

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1. Install IPA on a machine with IPv4 and IPv6 addresses
2. Install client on a machine with only IPv6 addresses
3. Run kinit admin.
4. Get error: kinit: Cannot contact any KDC for realm 'MY.REALM' while getting initial credentials

Actual results:
KRB5_TRACE=/dev/stdout kinit admin
[11314] 1440361393.657162: Getting initial credentials for admin@MY.REALM
[11314] 1440361393.657457: Sending request (175 bytes) to MY.REALM
[11314] 1440361393.658737: Initiating TCP connection to stream
kinit: Cannot contact any KDC for realm 'MY.REALM' while getting initial credentials

Expected results:
kinit uses the hosts IPv6 address to connect when IPv4 addresses aren't used.

Additional info:
Comment 2 Matt Willsher 2015-08-24 01:16:07 EDT
A reboot of the servers in question caused this to start working as expected. I'll monitor for a while and see if the issue comes back.
Comment 3 Petr Vobornik 2015-08-24 04:36:34 EDT
I'll closed this bug, given that it works as expected. If it comes back please check your network setup and if IPA server is listening on the expected ports, i.e. if KDC is running.  Please reopen the bug if all is in order and kinit still doesn't work.
Comment 4 Matt Willsher 2015-08-24 08:20:20 EDT
I've had the issue come back. To check just IPv6, I removed the IPv4 address from the IPA master's DNS entry. It all worked fine. After adding the IPv4 address back in it worked ok for a while then it stopped working after a few hours and tries to use the IPv4 address on the IPv6 only machine.

To work around the issue I'll use IPv6 only for now (and feel like I'm living in the future :) ).

Let me know if there is any other output needed.
Comment 6 Sumit Bose 2015-09-01 04:01:53 EDT
I wonder if this only happens with kinit? What about calling ssh on the IPv6 client to log in to a host which has IPv4 and IPv6 entries in DNS as well?

I think the resolve is a more suitable level to solve this. Does it help to add 'options inet6' to /etc/resolve.conf?
Comment 7 Matt Willsher 2015-09-28 07:31:49 EDT
I did try options inet6 to no affect. 

I don't have the system to check SSH at the moment but will revisit in the future and try that then. I do recall that it only seemed to be a problem with kinit. Other tools I was using (e.g. yum) worked fine.
Comment 8 Robbie Harwood 2015-10-21 16:09:56 EDT
(Please remove needinfo when you have the SSH information.  Thanks!)
Comment 10 Robbie Harwood 2016-01-06 09:01:34 EST
(I assume flags were poked by accident since nothing else about the bug has changed.)
Comment 11 Matt Willsher 2016-01-06 09:55:51 EST
Flags were poked because I get an email pestering me for an update when I have no update to give. I don't mind reminders, just no quite so frequently!
Comment 12 Matt Willsher 2016-03-14 16:03:09 EDT
It's unlikely I'll get back to this, and so won't be able to provide further information.

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