search

gssapi / mod_auth_gssapi

GSSAPI Negotiate module for Apache
Other
96 stars 40 forks source link

Kerberos fails through a VPN tunnel #153

Closed mortenn closed 7 years ago

mortenn commented 7 years ago

Hi,

I've ran into a bit of an issue with accessing internal applications through a citrix netscaler VPN tunnel. DNS resolves "foo.apps.domain.com" into "farm.domain.com" with an IP "10.0.4.210". Internally, this works fine.

When a client connects to the VPN, DNS results are identical, but trying to access the application, a username and password prompt pops up.

apache error log:

[Mon Oct 09 15:42:06.243642 2017] [auth_gssapi:error] [pid 17994] [client REDACTED] gss_accept_sec_context() failed: [Unspecified GSS failure.  Minor code may provide more information (Request ticket server HTTP/foo.apps.domain.com@DOMAIN.COM not found in keytab (ticket kvno 3))]

gssapi config in apache:

AuthType GSSAPI
AuthName "Apps"
GssapiBasicAuth Off
GssapiAllowedMech krb5
GssapiUseSessions Off
GssapiSSLonly Off
GssapiCredStore keytab:/etc/httpd/krb/pa.keytab
require valid-user

keytab:

# klist -k /etc/httpd/krb/pa.keytab
Keytab name: FILE:/etc/httpd/krb/pa.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 HTTP/farm.domain.com@DOMAIN.COM
   3 HTTP/farm.domain.com@DOMAIN.COM
   3 HTTP/farm.domain.com@DOMAIN.COM
   3 HTTP/farm.domain.com@DOMAIN.COM
   3 HTTP/farm.domain.com@DOMAIN.COM

mod_auth_gssapi-1.4.0 is installed on apache httpd-2.4.6-45.el7.centos.4.x86_64

mortenn commented 7 years ago

Ticket on client connected via VPN:

#4>     Client: USER @ DOMAIN.COM
        Server: HTTP/foo.apps.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 10/9/2017 15:27:42 (local)
        End Time:   10/10/2017 1:27:37 (local)
        Renew Time: 10/16/2017 15:27:37 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: PDC.domain.com

Ticket on a client connected to LAN:

#7>     Client: USER @ DOMAIN.COM
        Server: HTTP/farm.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 10/9/2017 14:53:01 (local)
        End Time:   10/10/2017 0:53:01 (local)
        Renew Time: 10/16/2017 14:53:01 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0
        Kdc Called: PDC.domain.com
mortenn commented 7 years ago

Unless someone can think of something else, this might well be netscaler interfering. But this only happens to the apache server, another server running IIS operates fine via the VPN.

Though, in that case, the hostname matches the server in the ticket.

frozencemetery commented 7 years ago

I think you'd really need to sniff network traffic to see what's going on here... interference is certainly a possibility.

simo5 commented 7 years ago

Internally the record is a CNAME, externaly an A NAME, in either case it is not a mod_auth_gssapi bug.

mortenn commented 7 years ago

externally isn't relevant, the vpn resolves the hostname using the internal DNS, so it gets the cname.

simo5 commented 7 years ago

the point is that when libkrb5 gets a CNAME it uses the "canonical name" it points to instead of the original name, so that's why it gets a ticket for the "internal" name. You can turn off the "dns canonicalize hostname" option in krb5.conf on the client to check if this is the case. With that off CNAMEs are treated like A names and the target name is not changed.

mortenn commented 7 years ago

It should use the internal name, but it isn't. dns indicates the client should use farm.example.com, but the server log says foo.apps.example.com

I do not have, nor want to have, keys for each application on the farm servers.

mortenn commented 7 years ago

The client is running windows, btw.