Thanks for that.

I have an issue with NTP but I have got around that and spent many a happy hour 
updating the times on my clients. The errors were in /var/log/krb5kdc.log as 
"clock skew too great". It's only when I got rid of them, and there were many, 
could I clearly see the normal operation

Terry John

>Check time an date on all involved servers/workstations - if the difference is 
>more than 300 seconds , Kerberos might not work correctly. Apply the same time 
>to all involved >servers/workstations.

>Gerald

>> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The 
>> problem manifests itself as no authentication, and no DNS.
>> It seems Kerberos just stops responding to requests and requests just
>> get queued up # netstat -tuna | grep SYN_RECV Active Internet
>> connections (servers and established)
>> Proto Recv-Q Send-Q Local Address               Foreign Address             
>> State
>> tcp        0             0           <server IP>:88               <client1 
>> IP>:55440         SYN_RECV
>> tcp        0             0           <server IP>:88               <client 2 
>> IP>:40076        SYN_RECV
>> tcp        0             0           <server IP>:88               <Client 3 
>> IP>:41525        SYN_RECV
>> tcp        0             0           <server IP>:88               <Client4 
>> IP>:53958         SYN_RECV
>> tcp        0             0           <server IP>:88               <Client5 
>> IP>:54240         SYN_RECV
>> Looking at /var/log/krb5kdc.log
>> The normal activity of AS_REQ and TGS_REC messages just stops. No error 
>> messages. Just  no new messages.
>> In /var/log/messages the named server reports messages like Mar  1
>> 00:00:23 freeipa named[18989]: LDAP error: Can't contact LDAP server
>> Mar  1 00:00:23 freeipa named[18989]: connection to the LDAP server
>> was lost Mar  1 00:00:23 freeipa named[18989]: bind to LDAP server
>> failed: Can't contact LDAP server
>> The command "kinit" is totally unresponsive and will time out if you wait 
>> long enough.
>> If I try to restart ipa with "service ipa restart", it hangs on the first 
>> stage, trying to stop DIRSRV.
>> I have to do a "ps ax" and look for this line.
>> 2758 ?        Sl     2:13 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MY-REALM 
>> -i /var/run/dirsrv/slapd-MY-REALM.pid -w 
>> /var/run/dirsrv/slapd-MY-REALM.startpid
>> Then I have to a "kill -9" on the pid
>> Then I can do "service ipa restart"
>> After that it works ok for a while. "A while" may be a few minutes or 
>> several hours.
>> The filesystem is only 58% used and "free" shows no swap in use so there 
>> seems to be plenty of RAM available.
>> "top" shows CPU(s) 96% idle with "dirsirv" typically using about 3%CPU  at 
>> most


Cox Automotive group of companies within the UK comprises: Cox Automotive UK 
Limited (registered number: 03183918), Manheim Limited (registered number: 
00448761), Cox Automotive Retail Solutions Limited (registered number: 
02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time 
Communications Limited (registered number: 04277845). Each of these companies 
is registered in England and Wales with the registered office address of 
Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group 
of companies within the UK operates under various brand/trading names including 
Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime 
and Closeit.

V:0CF72C13B2AD



-- 
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