AD Cross domain authentication issue over RA IPSEC VPN on ASA

[Sami Abunasser]

Hi,

I have remote access setup for users connecting to an ASA 5540, the IPSEC policy is using RADUIS authentication through AD along with Certificates. Users authenticate fine, and can access everything on the domain with no issues. Lets say the domain is (X). We recently merged with another company running domain (Y), on the AD servers the two domains are setup as trust domains.

The problem we seem to be running into, is that when users connect to the VPN and authenticate on domain X,  then attempt to access resources on domain Y, it usually fails. They cannot consistently map drives by FQDN or IP, and vice versa also (when authenticating on domain Y, and attempting to access resources on domain X). It seems to work sometimes for some users, but more than often it doesn't. The actual IP connectivity is fine, the problem is that authentication fails.

Has anyone seen issues with passing Kerberos authentication through an IPSEC tunnel? When attempting to access these resources while locally connected to the network, there are no issues, so it seems to be only with remote access.

Any suggestions would be appreciated.

Thanks,

Sam

[Marcin Latosiewicz]

Sam,

Just from the top of my head.

VPN == overhead.

Kerberos == by default UDP as transport and occasional big packets.

overhead + UDP == possible fragmentation and Kerberos doesn't work well when fragmentation is involved.

I believe there is a way to switch Kerberos to TCP.

This is just something I run into once, I would actually see packet captures and fragmentations/reassambly statistics to know for sure ;-)

Marcin

[Sami Abunasser]

Marcin,

Thank you for the input. I already looked into the fragmentation problem, and it doesn't really seem to be the issue, or at least I am unable to determine that it's the cause. The mss adjust is set to 1200 just to be on the safe side, and I'm still seeing this random behavior.

I'm not too familiar with Kerberos, and AD Authentication. But what I was able to do is to setup a wireshark capture on the laptop I was testing from and was getting the following DNS errors:

37 4.026382 DNS Standard query SRV _kerberos._tcp.
38 4.951077 DNS Standard query response, No such name
39 5.013351 DNS Standard query SRV _kerberos._tcp.
40 5.014114 DNS Standard query response, No such name
41 5.423517 NBNS Name query NB .COM<1c>
42 5.423913 NBNS Name query response, Requested name does not exist

When attempting to access the shares from within the network, I don't see those errors. I am working with our AD engineers to see if we can figure out why this error is occurring, but I'm pretty sure that this is the reason the connection fails to authenticate to the shares. Also, I was thinking that if this is, it would explain the reason why the connection works sometimes and sometimes doesn't, since the kerberos ticket is valid for a time duration (not sure how long), so if you have a valid ticket you can access the share, and the issue occurs when your ticket expires and you need to renew it over the VPN connection.

Thanks,

Sami

[Marcin Latosiewicz · Accepted solution]

Sami,

Good catch!

The VPN host is looking for TCP capabale kerberos server to authenticate to it.

The server has to be associated with domain you .

If your kerberos/AD can talk TCP, it's just a question of adding those records to your local DNS server. (Note it is a SRV record not a IN A)

That being said I believe this doesn't have to be the default option and very often is used as fallback if UDP communication fails, but it may depend on config of client - I'm not intimately faimilar with this implementation on Microsoft systems.

Marcin