Description of problem: after getting a kerberos ticket either through kinit admin or logging in to a system configured as an ipa client, configuring firefox for sso, and importing certs from the IPA server, i am still unable to access the web ui. the information displayed on the web page is "Kerberos login failed.", "Permission Denied", and "you do not have permission to access this page." if i enable KrbMethodK5Passwd on the ipa website, and attempt to access it w/o a kerberos ticket, it lets me in after prompting for user and password. the negotiate log from firefox showed no errors, but i did get some in the apache log: error.log gets these entries: [Mon Nov 30 17:40:44 2009] [error] [client 192.168.0.11] Cannot store delegated credential (gss_krb5_copy_ccache: An unsupported mechanism was requested (, Unknown error)) [Mon Nov 30 17:40:44 2009] [error] [client 192.168.0.11] Cannot store delegated credential (gss_krb5_copy_ccache: An unsupported mechanism was requested (, Unknown error)), referer: https://daedalus.poolofdespair.net/ipa/ui (this error repeats 6 times) [Mon Nov 30 17:40:44 2009] [error] [client 192.168.0.11] Cannot store delegated credential (gss_krb5_copy_ccache: An unsupported mechanism was requested (, Unknown error)), referer: https://daedalus.poolofdespair.net/ipa/ui/static/css/style_platform.css (This error repeats 4 times) and access log gets: 192.168.0.11 - admin [30/Nov/2009:18:08:52 -0700] "GET /ipa/ui/static/images/template/background-sidebar.png HTTP/1.1" 304 - with small variations to the URL Version-Release number of selected component (if applicable): 1.2.2-2 How reproducible: Every time Steps to Reproduce: 1. setup FreeIPA server 2. get a krb ticket for admin on a different machine 3. configure firefox for sso 4. go to the webui of the ipa server, accepting encryption certs 5. Get denied access Actual results: Unable to access the web ui Expected results: should be able to access the web ui Additional info: This is on a Fedora 12 x86_64 system, only the @Core group was installed from disc, very few things were added removed: added postfix, removed sendmail added vim, bind, bind-utils, dhcp, openssh-clients sso seems to work fine connecting to the FreeIPA server through ssh
Can you set the Apache LogLevel to Debug and restart the httpd service and try again, we should get additional debugging information that might be useful. Basically this error is saying that mod_auth_kerb can't store away a copy of the TGT you delegated from the browser. I have no idea why this would happen. Can you also provide the output of `klist -fea` so we can see the TGT that is being delegated?
Created attachment 375265 [details] apache debug log trying to access the free ipa web ui
here is the klist -fea output from before and after trying to access the web ui: [mike@minibox ~]$ klist -fea Ticket cache: FILE:/tmp/krb5cc_500 Default principal: admin Valid starting Expires Service principal 12/01/09 18:12:45 12/02/09 18:12:42 krbtgt/POOLOFDESPAIR.NET Flags: FIA, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC Addresses: (none) [mike@minibox ~]$ firefox [mike@minibox ~]$ klist -fea Ticket cache: FILE:/tmp/krb5cc_500 Default principal: admin Valid starting Expires Service principal 12/01/09 18:12:45 12/02/09 18:12:42 krbtgt/POOLOFDESPAIR.NET Flags: FIA, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC Addresses: (none) 12/01/09 18:19:31 12/02/09 18:12:42 HTTP/daedalus.poolofdespair.net Flags: FAT, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC Addresses: (none) [mike@minibox ~]$
Gah, sorry, can you set LogLevel to debug in /etc/httpd/conf.d/nss.conf and try again? Do you have SELinux enabled? Are you seeing any related AVCs in /var/log/audit/audit.log? Your tickets look ok.
Created attachment 375643 [details] apache nss debug log
selinux is enabled, the only related entries i saw in audit.log were successes, tried the web ui again after doing setenforce 0, but the result was identical
Just so we're all on the same page, the firefox client is also an F12 box?
yes, i have also tried with firefox on an F11 box, same results.
I've duplicated this with Firefox 3.5 on F9 as the client against ipa-server-1.2.2-2.fc12.x86_64 Oddly enough the command-line client works as does curl: % curl -kv --negotiate -u : https://ipaserver.example.com/ipa/ui I tested curl both on the F-12 box and from the F-9 box and both invocations worked.
Can you get me packet dumps of the clients' requests to the server? I'm guessing that firefox is sending an SPNEGO token while curl is sending a Kerberos token.
Created attachment 376249 [details] tcpdump output of all traffic between the client running firefox nad the ipa server
i know the file extension is .txt, but it's actually a packet data (tcpdump -w...)
Aaargh. Of course, we're using TLS, so the negotiate data that the client sends to the server is encrypted.
Okay, I'm pretty sure it's an SPNEGO-specific problem. Can you test the scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=1863336 and report on whether updating it on the server (and probably restarting the service with 'ipactl restart') makes things work as expected again?
Created attachment 377006 [details] backtrace of httpd core file httpd is dropping core both from FF 3.5 on a F9 client and with curl on the local machine.
Well, on the bright side, that seems to be happening elsewhere, in the labeling code that Dan and I were looking at last week. It looks like either selabel_lookup() failed but returned successful status, or there was an error initializing label lookup. I'm adding an extra check to avoid this, though I'd like to also figure out why it's happening. Meanwhile, please give http://koji.fedoraproject.org/koji/taskinfo?taskID=1863614 a try.
httpd no longer segfaults but it also doesn't correct the problem. We are back to where we started: works with curl, fails with Firefox.
That's because I backed the patch out for Raw Hide, and then built that as the scratch package, so the change that should have fixed it wasn't even in that second build. Third time's the charm, maybe? http://koji.fedoraproject.org/koji/taskinfo?taskID=1865577
That did the trick for me. I was able to log in from FF 3.5 and curl.
Fixed it here too, shall i close the bug?
Please leave it open; I'd like to push an update to F12 to fix this, and I can use this bug to track it. I'd like to hear if upstream has a more correct fix, as I'm not 100% sure that the way the patch does it is in keeping with the way the gssapi library is supposed to be doing things.
krb5-1.7-14.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/krb5-1.7-14.fc12
krb5-1.7-14.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update krb5'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13539
krb5-1.7-15.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.