On 2010-08-03 21:41, Ginny Clark wrote:
>
> We have mod_auth_kerb installed on apache (Ubuntu) for a web app - this is a new install.
> When we access the web app from the outside via a remotevpn/citrix access gateway, Kerberos is working. The citrix access gateway is a Linux server and from what I am told it does not use a proxy and is "wide-open" (not sure what all that means).
> However, when we access the web app from an internal desktop - on the same network where the web app is (Windows XP), it does not work. The KDCs are Windows 2008.
>
> We have looked at the network messages on the two clients and on the apache server, via WireShark. When coming in from the outside, we can see where apache kicks off the messages to DNS and Kerb. When hitting the web app from the inside, we can see the initial hit on DNS (to resolve the web app name), but then Kerb is not called. We have looked at the apache logs, and see a difference, but can't really tell what is going on:
>
> >From VPN/Remote access (WORKS!):
> [Tue Aug 03 18:44:20 2010] [debug] src/mod_auth_kerb.c(1579): [client 10.24.10.223] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> [Tue Aug 03 18:44:20 2010] [debug] src/mod_auth_kerb.c(1023): [client 10.24.10.223] Using HTTP/iewebpoc1.mhc.net@... as server principal for password verification
This request over your VPN sent a HTTP basicauth username and
password, which the KDC then validated by requesting a ticket for
HTTP/iewebpoc1.mhc.net@... using the password. This means
the user either typed in a user and password or some software in IE
automatically supplied a user and password.
> >From the "internal" client (Doesn't Work):
> [Tue Aug 03 19:01:16 2010] [debug] src/mod_auth_kerb.c(1579): [client 10.21.10.91] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> [Tue Aug 03 19:01:16 2010] [debug] mod_deflate.c(619): [client 10.21.10.91] Zlib: Compressed 539 to 366 : URL /
> [Tue Aug 03 19:01:16 2010] [debug] src/mod_auth_kerb.c(1579): [client 10.21.10.91] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
> [Tue Aug 03 19:01:16 2010] [debug] src/mod_auth_kerb.c(1261): [client 10.21.10.91] Acquiring creds for HTTP@...
> [Tue Aug 03 19:01:16 2010] [error] [client 10.21.10.91] gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (Permission denied)
This user attempted to do HTTP negotiateauth and failed because the
user things the server's name is iewebc.mhc.net but it appears
(from your http basic attempt above) that the server thinks it's
name is iewebpoc1.mhc.net. My guess is that iewebc.mhc.net is a
DNS A record pointing at the same IP as iewebpoc1.mhc.net or
(probably more likely) iewebc.mhc.net is some sort of load balancer
which is redirecting the request back to iewebpoc1.mhc.net.
> Any ideas or thoughts on how to further debug? Thanks.
First, you should verify that your single-server Negotiate auth
works: to do that, point an internal machine at
http[s]://iewebpoc1.mhc.net and see if negotiate works. If it
does, then your fundamentals are correct (ie. your Kerberos and DNS
infrastructure work correctly) and then you should reconfigure your
apache by (I believe) setting
KrbServiceName HTTP@...
and you should generate a new kerberos principal named
HTTP/iewebc.mhc.net and stick the keys for that principal in the
same keytab your existing HTTP-iewebpoc1.mhc.net keys are in.
Glancing at a local configuration, I believe setting KrbServiceName
is optional.
--
Alec Kloss Email/Jabber IM: alec@...
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEBD1FF14
"I said, 'You gotta be kidding. Who the hell is the blue guy?'" -- Craig Finn
|