<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I had a happy, working 2.2 FreeIPA installation humming along last week. I had to do some maintenance so I shut everything down. When I brought everything up, I can no longer log into the web admin tool. I get a "Kerberos ticket is no longer valid" error.<div><br></div><div>Using the troubleshooting pages on the wiki as a guide, I can kinit successfully and see the tickets using klist. I can use the ldapsearch tool using GSSAPI to authenticate as well and can return results from the ldap server. 'ldapsearch -Y GSSAPI -b "dc=dcc,dc=mobi" uid=admin' returns a valid ldap recors for my admin user. I ran this command kinit from multiple kerberos principals/users and each worked.</div><div><br></div><div>I verified my config settings again with firefox and they are still set correctly (auth.delegation-uris, auth.trusted-users both set to my domain .dcc.mobi). The cert was accepted (no warnings about the cert not being trusted because I had already set it to trusted). I turned on the NSPR logging as described in the documents, and didn't see an error, although I can't tell if this is correct:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>492291904[7f4d1d31f6a0]: using REQ_DELEGATE</div></div><div><div>492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi</div></div><div><div>492291904[7f4d1d31f6a0]: using negotiate-gss</div></div><div><div>492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI()</div></div><div><div>492291904[7f4d1d31f6a0]: Attempting to load gss functions</div></div><div><div>492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init()</div></div><div><div>492291904[7f4d1d31f6a0]: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]</div></div><div><div>492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken()</div></div><div><div>492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0]</div></div><div><div>492291904[7f4d1d31f6a0]: Sending a token of length 1394</div></div></blockquote><div><br></div><div>There is nothing in /var/log/httpd/error_log. /var/log/httpd/access_log does have a few entries:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ca/ocsp HTTP/1.1" 200 2298 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0"</div></div><div><div>10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json HTTP/1.1" 401 -</div></div><div><div>10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos HTTP/1.1" 401 1861</div></div><div><div>10.1.1.10 - <a href="mailto:admin@DCC.MOBI">admin@DCC.MOBI</a> [16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos HTTP/1.1" 200 -</div></div><div><div>10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json HTTP/1.1" 401 -</div></div></blockquote><div><br></div><div>The 401's aren't surprising here since somehow, something is not properly authenticating.</div><div><br></div><div>I also looked in /var/log/krb5kdc.log and see the following line when authenticating:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1 etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18 tkt=18 ses=18}, <a href="mailto:admin@DCC.MOBI">admin@DCC.MOBI</a> for <a href="mailto:krbtgt/DCC.MOBI@DCC.MOBI">krbtgt/DCC.MOBI@DCC.MOBI</a></div></div></blockquote><div><br></div><div>I don't believe this describes an error, but I'm not an expert reading that log type.</div><div><br></div><div>From what I can tell, the problems seem to be between the apache server and the browser. Both worked fine together last week. Is there something I can turn on in Apache (perhaps in the ipa.conf or auth_kerb.conf files) that can help debug this? Or better yet, anyone else seen this and have an answer? Is there some key/ticket/etc associated with the http server that might be "wrong" now (somehow whacked during the reboot)?</div><div><br></div><div>Thanks,</div><div><br></div><div>Brian</div><div><br></div></body></html>