Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157238 - Repeated username/password requests during a browser session
Summary: Repeated username/password requests during a browser session
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mod_auth_kerb
Version: 4.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-09 17:41 UTC by Trevan
Modified: 2012-06-20 15:55 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 15:55:59 UTC


Attachments (Terms of Use)
Apache ssl error log (deleted)
2005-05-09 17:44 UTC, Trevan
no flags Details
Kerberos log file (deleted)
2005-05-09 17:45 UTC, Trevan
no flags Details
The packets on the network (deleted)
2005-05-09 17:46 UTC, Trevan
no flags Details
mod_auth_kerb configuration (deleted)
2005-05-09 20:53 UTC, Trevan
no flags Details

Description Trevan 2005-05-09 17:41:36 UTC
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

Comment 1 Trevan 2005-05-09 17:44:19 UTC
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.

Comment 2 Trevan 2005-05-09 17:45:09 UTC
Created attachment 114170 [details]
Kerberos log file

This is what kerberos shows when we have to re log in.

Comment 3 Trevan 2005-05-09 17:46:19 UTC
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'.

Comment 4 Joe Orton 2005-05-09 18:51:22 UTC
Thanks for the report.  Could you give the mod_auth_kerb configuration you're using?


Comment 5 Trevan 2005-05-09 20:53:44 UTC
Created attachment 114183 [details]
mod_auth_kerb configuration

The actual config has other users, but they are written all the same.

Comment 6 Joe Orton 2005-05-09 21:13:52 UTC
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?

Comment 7 Trevan 2005-05-09 21:19:27 UTC
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.

Comment 8 Trevan 2005-05-09 21:20:56 UTC
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.

Comment 9 Trevan 2005-05-09 21:23:42 UTC
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.

Comment 10 Joe Orton 2005-05-10 10:22:39 UTC
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.

Comment 11 Trevan 2005-05-10 18:45:49 UTC
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.

Comment 12 Joe Orton 2005-05-10 20:33:17 UTC
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?

Comment 13 Trevan 2005-05-11 19:28:38 UTC
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.


Comment 15 Marek Mahut 2008-04-10 20:08:50 UTC
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

Comment 16 Jiri Pallich 2012-06-20 15:55:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.