From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Description of problem: We recently upgraded to RHEL 4 and as well upgraded kerberos, apache, and mod_auth_kerb. After configuring mod_auth_kerb to work with the new configuration (as explained on the http://modauthkerb.sourceforge.net/ website), we started to notice that we would be asked our username and password repeatedly. Sometimes, it wouldn't even ask us our credentials and just give us a unauthorized access error page. Looking at the popup box, we can see that we have not left the domain at all, and we haven't closed the browser or cleared out anything in cache. There is one page that gets us everytime and it is an apache directory listing of our develpement zone. I have looked online for any information and they all talk about this being a problem with kerberos 1.2.x, yet we are running krb5-server-1.3.4-12. Here is an example of the help: http://sourceforge.net/mailarchive/forum.php?thread_id=5181374&forum_id=9893. I have looked at the log files and have noticed some funny occurences. It seems as if every now and then, kerberos forgets who we are. I have those attached. Version-Release number of selected component (if applicable): mod_auth_kerb-5.0-1 How reproducible: Always Steps to Reproduce: 1. Go to our secure website and log in 2. Go to the apache directory listing of our dev zone Actual Results: We are asked to log in, and sometimes up to 4 or 5 times. Expected Results: We should already have the correct credentials. Additional info: These are packages that could be relevant. The kerberos server is on a different server than the apache server, but both are running RHEL 4. krb5-server-1.3.4-12 mod_auth_kerb-5.0-1 httpd-2.0.52-9.ent
Created attachment 114169 [details] Apache ssl error log This is what shows up when we access a page that asks us to re log in.
Created attachment 114170 [details] Kerberos log file This is what kerberos shows when we have to re log in.
Created attachment 114171 [details] The packets on the network This is the output from tethereal that shows what is being sent back and forth. The command I used is tethereal -R 'kerberos'.
Thanks for the report. Could you give the mod_auth_kerb configuration you're using?
Created attachment 114183 [details] mod_auth_kerb configuration The actual config has other users, but they are written all the same.
Before looking further into exactly why the requests are failing: I'm confused about the nature of the failure case: In that configuration you should never get username/password prompts since the server is not using Basic authentication; it should either succeed or just display the 401 error page. But you say, the browser is really displaying standard pop-up username/password dialogs? What browser is this?
I get the username/password prompts because I have explicitly turned off KrbMethodNegotiation. So, it has to prompt me for my credentials. I am using FF 1.0.3, and 1.0.2.
Also, we configured it using http://modauthkerb.sourceforge.net/configure.html as a guide, and it says to use Kerberos as the AuthType. We haven't even tried with Basic Authentication.
Sorry for the repeated comments, but I just tried with Basic Authentication, and all we get is an error page. We don't get anything after we log in. When I change back to Kerberos Authentication and restart apache, we get in fine, but still have the repeated username/password requests.
Sorry, I misread your config. This configuration *is* using Basic authentication, to transmit the Kerberos username and password across the wire. I believe it's inevitable that in this configuration you risk getting replay errors due to the fact that the server has to repeatedly reauthenticate the user credentials. The recommended configuration is to enable the use of "Negotiate"-based authetication, which does a GSSAPI exchange with the client rather than just passing the username/password over the wire: KrbMethodNegotiate on KrbMethodK5Passwd off This requires support for Negotiate in the browser, which is present in the RHEL4 Firefox and Mozilla packages.
Yes, we have been looking into getting the Negotiate Method going. As for turning off K5Passwd, I don't think that will work for us, since we are using the Krb5 module. If I am not mistaken, turning it off, means we need to start using Krb4, which wouldn't work for us. But what confuses me, is that it worked fine before the upgrade and now has problems. Looking over at the mailarchive for mod_auth_kerb, they say that this should only happen if I am using version 1.2.x of Krb, or if KRB5_AUTH_CONTEXT_DO_TIME is being passed into a function. I have downloaded the rpm src from redhat, but it is slightly different than the current code in modauthkerb (I believe you guys made changes to make it more stable). You can take a look at where I am getting this: http://sourceforge.net/mailarchive/forum.php?thread_id=5181374&forum_id=9893. I would like to not have to just use the Negotiate Method, since some of us do not use Firefox/Mozilla.
I've been investigating this further; I can fairly easily reproduce the replay errors using the "Negotiate Off, Password On" configuration, on both: - RHEL4 standard mod_auth_kerb, 5.0-rc4-based (krb5 1.3) - FC4 with mod_auth_kerb, 5.0-rc6-based, and also 5.0-rc6 unpatched (krb5 1.4) What mod_auth_kerb/krb5 versions were you using before, that didn't see this problem?
Unfortunately, I have no idea for mod_auth_kerb. I do know that it was version 4.x, since our config file also had to be changed because of the new configurations that 5.x uses. But as for specific versions, I don't really know. Looking at the rpmpkgs log file, it looks like we had krb5-server-1.2.7-38.
I had the same problem in our production environment. After few days of troubleshooting we've discovered the fix. We set kdc_timesync = 0 under [libdefaults]. For more information, check this link: http://sourceforge.net/mailarchive/forum.php?thread_name=87irc8urzs.fsf%40kosh.bigo.ensc.de&forum_name=modauthkerb-help
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.