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 <[email protected]>: > On Fri, 19 Sep 2014, Genadi Postrilko wrote: > >> I have recreated the "problem". >> Rebooted the AD and now cannot kinit with AD users. >> >> [root@ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit [email protected] >> [22865] 1411157693.26121: Resolving unique ccache of type KEYRING >> [22865] 1411157693.26167: Getting initial credentials for [email protected] >> [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@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 <[email protected]>: >> >> 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@ipaserver1 ~]# kinit [email protected] >>> > Password for [email protected]: >>> > >>> > [root@ipaserver1 ~]# klist >>> > Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE >>> > Default principal: [email protected] >>> > >>> > Valid starting Expires Service principal >>> > 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/[email protected] >>> > 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@ipaserver1 ~]# kinit [email protected] >>> > 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 [email protected] >>> >>> HTH >>> >>> bye, >>> Sumit >>> >>> > >>> > I have checked if all the IPA services where UP: >>> > >>> > [root@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 >
-- 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
