On Thu, 25 Sep 2014, Genadi Postrilko wrote:
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 forwar
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 sor
On 24.9.2014 18:00, Genadi Postrilko wrote:
2014-09-22 9:29 GMT+03:00 Petr Spacek :
'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 'o
2014-09-22 9:29 GMT+03:00 Petr Spacek :
> '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
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
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 forward
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 ini
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] 1411
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
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 i
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
Al
11 matches
Mail list logo
