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
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
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...
2014-09-19 23:40 GMT+03:00 Alexander Bokovoy <aboko...@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@ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit y...@blue.com
 1411157693.26121: Resolving unique ccache of type KEYRING
 1411157693.26167: Getting initial credentials for y...@blue.com
 1411157693.28577: Sending request (156 bytes) to BLUE.COM
kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting
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 <sb...@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
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 y...@blue.com
Password for y...@blue.com:
[root@ipaserver1 ~]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE
Default principal: y...@blue.com
Valid starting Expires Service principal
09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/blue....@blue.com
renew until 09/17/2014 01:00:20
But after i rebooted the Windows Server Machine, i could not kinit with
[root@ipaserver1 ~]# kinit y...@blue.com
kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while
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 y...@blue.com
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
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
I did not increase the debug level and got the logs.
But i can share the ipa and sssd version:
rpm -qa | grep ipa
rpm -qa | grep sssd
Thanks for all the helpers.
Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project