[Freeipa-users] IPA, kerberos ticket issue for web admin.

[Rob Crittenden]

Nathan Lager wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've got an ipa server setup on RHEL6.  I have a Fedora 16 client,
> which i joined to the IPA domain using the ipa-client-install utility.
>
> When i attempt to authenticate to my ipa server's web admin portal, i
> get a generic error:
> Your kerberos ticket is no longer valid.
> And it goes on to tell me to configure my browser if this is my first
> time accessing.  I've done so, and the error remains.  It also tells
> me to re-run kinit if i havent done so aleady, which i've also done.
>
> Kinit returns no errors.  I've tried authing as my user (which is in
> the admin group) and as the admin user.  Both give me the same result.
>
> While googling for the error, i found some helpful information about
> enabling debug logging both on the ipa server, and my browser
> (firefox).  Doing so, i found the following errors:
>
> On the server:
> [Thu Apr 19 16:56:02 2012] [debug] src/mod_auth_kerb.c(1578): [client
> xx.xx.xx.xx] kerb_authenticate_user entered with user (NULL) and
> auth_type Kerberos, referer: https://(my.ipa.server)/ipa/ui/
>
> And from my browser:
> - -1713670336[7fd299b24590]: nsHttpNegotiateAuth::ChallengeReceived URI
> blocked
>
> These have shed little to no light on the situation, other than, it
> sounds like something is getting blocked.
>
>
> I was able to join this same client to a different IPA domain (a non
> production version of this same domain), which worked properly.  I
> used the ipa-client-install --uninstall command to clean up ipa before
> re-joining this system to the production ipa domain.  I also rebooted
> for good measure.
>
> One major difference between the two domains is that the IPA server
> for dev lives on a much more open network.  Our development network,
> and the production ipa domain lives on a production auth network,
> which is much more locked down.  I believe i have all of the proper
> ports open.
>
> nmap scans give me the following for tcp and udp.
>
> PORT    STATE SERVICE
> 22/tcp  open  ssh
> 80/tcp  open  http
> 88/tcp  open  kerberos-sec
> 389/tcp open  ldap
> 443/tcp open  https
> 464/tcp open  kpasswd5
> 636/tcp open  ldapssl
>
> 123/udp open     ntp
>
>
> Any direction here would be most useful.  Thanks!

Are you going through a proxy? They often times mess up Negotiate 
headers. I've never seen a URI blocked error in the browser.

The (NULL) user is expected. The first request comes in with no 
authentication from the browser and this is the server asking "who are 
you?" The next request should include the authentication header.

rob