[Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot

[Petr Spacek]

On 19.9.2014 23:15, Genadi Postrilko wrote:
> The DNS server service of AD is running.
> I am able to resolve with nslookup command.
>
> I have just restarted the named service and i am able to kinit again.
> It looks like the named deamon, cannot recognize that the forwarder is back
> online.
> Is there some caching mechanism implemented for the forwarders?

'IPA forwarders' are exactly the same as normal 'BIND forward zone' so they 
involve normal DNS cache.

Which type of forwarder do you have configured? Is your 'forwarding policy' 
set to 'first' (default) or 'only'?

Forwarding policy 'first' (combined with cache) could be the cause of your 
problem. 'First' policy instructs BIND to contact the configured server and if 
it fails (because of timeout) BIND will re-try the same query using normal 
recursion.

Depending on your network configuration, the normal DNS recursion can return 
different results than forwarding(^1). In this case BIND can cache e.g. 
NXDOMAIN answer from some other server and this answer will stay in cache for 
TTL value in the given answer.

As a result, IPA could get cached NXDOMAIN instead of correct SRV records for 
AD until the TTL in cache expires.

This is of course a wild guess. Detailed logs from named (log level 5 or 
higher+querylog) could tell us what exactly happened.

Have a nice day!

(^1) I would argue that this points to a flaw in network configuration...

Petr^2 Spacek

> 2014-09-19 23:40 GMT+03:00 Alexander Bokovoy <abokovoy at redhat.com>:
>
>> On Fri, 19 Sep 2014, Genadi Postrilko wrote:
>>
>>> I have recreated the "problem".
>>> Rebooted the AD and now cannot kinit with AD users.
>>>
>>> [root at ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM
>>> [22865] 1411157693.26121: Resolving unique ccache of type KEYRING
>>> [22865] 1411157693.26167: Getting initial credentials for Yoni at BLUE.COM
>>> [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM
>>> kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting
>>> initial credentials
>>>
>>> The AD configured as forwarder:
>>>
>>> [root at ipaserver1 ~]# ipa dnsconfig-show
>>>   Global forwarders: 192.168.227.60
>>>
>>> i can ping the AD machine.
>>>
>> If you rebooted AD DC, it takes time to start up its services. If
>> Kerberos library cannot resolve SRV records for BLUE.COM, it means DNS
>> service on AD DC didn't start up yet and cannot respond to DNS queries.
>>
>>
>>
>>
>>> 2014-09-16 10:28 GMT+03:00 Sumit Bose <sbose at redhat.com>:
>>>
>>>   On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote:
>>>>> Hello all !
>>>>>
>>>>> I have deployed test environment for AD trust feature, the environment
>>>>> contains :
>>>>> Windows Server 2008 - AD Server.
>>>>> RHEL 7 - IPA 3.3 Server.
>>>>> RHEL  6.2 - IPA Client.
>>>>>
>>>>> I have established the trust as IPA in the sub domain of AD.
>>>>> AD DNS domain - blue.com
>>>>> IPA DNS domain - linux.blue.com
>>>>>
>>>>> All was working fine as i was able to kinit with AD users:
>>>>>
>>>>> [root at ipaserver1 ~]# kinit Yoni at BLUE.COM
>>>>> Password for Yoni at BLUE.COM:
>>>>>
>>>>> [root at ipaserver1 ~]# klist
>>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE
>>>>> Default principal: Yoni at BLUE.COM
>>>>>
>>>>> Valid starting       Expires              Service principal
>>>>> 09/16/2014 01:00:25  09/16/2014 11:00:25  krbtgt/BLUE.COM at BLUE.COM
>>>>>          renew until 09/17/2014 01:00:20
>>>>>
>>>>> But after i rebooted the Windows Server Machine, i could not kinit with
>>>> AD
>>>>> users anymore:
>>>>> [root at ipaserver1 ~]# kinit Yoni at BLUE.COM
>>>>> kinit:  Cannot resolve servers for KDC in realm "BLUE.COM" while
>>>> getting
>>>>> initial
>>>>
>>>> The only IPA component used for kinit is the DNS server. How did you
>>>> configure DNS (glue records? forwarder?). To get more details about what
>>>> is failing you can call:
>>>>
>>>> KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM
>>>>
>>>> HTH
>>>>
>>>> bye,
>>>> Sumit
>>>>
>>>>>
>>>>> I have checked if all the IPA services where UP:
>>>>>
>>>>> [root at ipaserver1 ~]# ipactl status
>>>>> Directory Service: RUNNING
>>>>> krb5kdc Service: RUNNING
>>>>> kadmin Service: RUNNING
>>>>> named Service: RUNNING
>>>>> ipa_memcached Service: RUNNING
>>>>> httpd Service: RUNNING
>>>>> pki-tomcatd Service: RUNNING
>>>>> smb Service: RUNNING
>>>>> winbind Service: RUNNING
>>>>> ipa-otpd Service: RUNNING
>>>>> ipa: INFO: The ipactl command was successful
>>>>>
>>>>> After i restarted IPA services (ipactl restart), i was able to to kinit
>>>>> again.
>>>>> Restarting smb service would do the job as well (?).
>>>>>
>>>>> Just wanted to know if it is a know issue, or the AD should be re
>>>>> discovered if it reboots.
>>>>> I think i seen an issue about it in the mailing list some time ago (not
>>>>> sure).
>>>>>
>>>>> I did not increase the debug level and got the logs.
>>>>> But i can share the ipa and sssd version:
>>>>>
>>>>> rpm -qa | grep ipa
>>>>> ipa-server-3.3.3-28.el7_0.1.x86_64
>>>>> python-iniparse-0.4-9.el7.noarch
>>>>> libipa_hbac-1.11.2-68.el7_0.5.x86_64
>>>>> ipa-admintools-3.3.3-28.el7_0.1.x86_64
>>>>> ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64
>>>>> ipa-python-3.3.3-28.el7_0.1.x86_64
>>>>> sssd-ipa-1.11.2-68.el7_0.5.x86_64
>>>>> iniparser-3.1-5.el7.x86_64
>>>>> libipa_hbac-python-1.11.2-68.el7_0.5.x86_64
>>>>> ipa-client-3.3.3-28.el7_0.1.x86_64
>>>>>
>>>>> rpm -qa | grep sssd
>>>>> sssd-krb5-common-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-ldap-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-common-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-common-pac-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-ad-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-krb5-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-1.11.2-68.el7_0.5.x86_64
>>>>> python-sssdconfig-1.11.2-68.el7_0.5.noarch
>>>>> sssd-ipa-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-proxy-1.11.2-68.el7_0.5.x86_64
>>>>> sssd-client-1.11.2-68.el7_0.5.x86_64
>>>>>
>>>>>   Thanks for all the helpers.