Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot [SOLVED]
The NetworkManager service was overriding the /etc/resolv.conf, so kinit couldn't resolve with the right DNS server. After stopping the NetworkManager and canceling its start up on boot, i can kinit with no problem. Didn't even had to change to forward-policy=only. Thank you for the help, and sorry i haven't noticed it sooner. -- 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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
2014-09-22 9:29 GMT+03:00 Petr Spacek pspa...@redhat.com: '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'? I have default forwarding policy: [root@ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 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. This the named log after i increased the debug level to 5 and enabled querylog: https://gist.github.com/anonymous/89308cbca3b07252674c Have a nice day! (^1) I would argue that this points to a flaw in network configuration... The test involvement is just bunch of VMs in NAT configurations. Petr^2 Spacek Thank you for the help. -- 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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
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. 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 -- 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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
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 -- 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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
I have configured the DNS with the AD as a forwarder (ipa-server-install --forwarder), just as explaine in RHEL 7 Windows Integration guide - 5.3.1. Setting up Trust with IdM as a DNS Subdomain of Active Directory. To use KRB5_TRACE ill need to recreate the issue. 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 -- 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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
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 -- 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
[Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
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 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
