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 <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
[22865] 1411157693.26121: Resolving unique ccache of type KEYRING
[22865] 1411157693.26167: Getting initial credentials for y...@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@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
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 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
AD
users anymore:
[root@ipaserver1 ~]# kinit y...@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 y...@blue.com

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

Reply via email to