On 2013-12-13 04:23, Juergen Obermeyer wrote:
Hello everybody,
I'm rewriting to this list because my problems with the user
authentication persist: all my users have to authenticate either with a
Kerberos Ticket or with username/password. This authentication fails
sometimes - please see the following two examples:
(1) Client 1, Windows 7 with Firefox, basic authentication
1386845741.085 438915 <client_1> TCP_MISS/200 23228 CONNECT
outlook.office365.com:443 <user_1> DIRECT/132.245.210.6 -
1386845741.142 54 <client_1> TCP_DENIED/407 1657 CONNECT
outlook.office365.com:443 - NONE/- text/html
After the first (successful) authentication, some milliseconds later
the
failure (same user!). Apparently, no authentication data is provided.
Yes. Consider this:
* two packets leave your gateway router. Which comes from client_1 and
which comes from some attacker spoofing client_1 IP ?
There is no way to tell the difference if the request does not contain
credentials.
It is also highly unsafe for your clients software to send their
credentials until they are sure they have reached the server they were
trying to connect to. Information about the server and its
authentication credentials is provided by 407 messages in HTTP.
So what you are seeing is normal.
(2) Client 2, Ubuntu 12.04 with Firefox, Kerberos
1386845730.212 50 <client_2> TCP_MISS/302 896 GET
http://www.google.com/search? <user@REALM> DIRECT/173.194.32.212
text/html
1386845743.861 145 <client_2> TCP_DENIED/407 1738 GET
http://bits.wikimedia.org/de.wikipedia.org/load.php? - NONE/- text/html
1386845743.948 231 <client_2> TCP_MISS/200 33809 GET
http://bits.wikimedia.org/de.wikipedia.org/load.php? <user@REALM>
DIRECT/91.198.174.233 text/css
Here we have a chain of success/failure/success (same user).
No. You have a chain of "success / new connection + needs credentials /
success ". 403 status is used for authentication _failure_.
If you decode the time stamps, you will see that there differences are
only about some milliseconds.
Is anybody out there with an idea?
Yes. This is normal HTTP traffic.
Check whether you have client persistent connections enabled. When that
is working the client traffic will all be sent over connections it
already knows need authentication, so you should see far less 407 from
the proxy.
Amos
