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

Fri Sep 19 21:15:44 UTC 2014

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?

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.
>>>
>>> > --
>>> > Manage your subscription for the Freeipa-users mailing list:
>>> > https://www.redhat.com/mailman/listinfo/freeipa-users
>>> > Go To http://freeipa.org for more info on the project
>>>
>>>
>>>
>  --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go To http://freeipa.org for more info on the project
>>
>
>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140920/8cd25a2c/attachment.htm>