Hi Jan,
Please see my responses inline:
1. Once the VPN session has been established the user is further prompted for AD credentials when accessing an AD share for the first time. Once they provide the credentials the share can be accessed. Should the AD credentials not be passed through when the VPN connection is established? Or is this by design? What makes me think it's not be design is the fact that this could be related to problem 2.
AnyConnect will authenticate the user against AD based on the aaa-server/tunnel-group configuration on the ASA. This AnyConnect user authentication is a separate authentication from the user authentication required for access to a share on a server in the domain. In order to know that this is or isn't expected behavior you would want to compare a packet capture of the user's login attempt and share access attempt both on the local LAN and on the AnyConnect connection. For the AnyConnect session you could gather a capture on the inside interface of the ASA to be sure you're gathering unencrypted data.
2. Group Policy Update (windows gpupdate) fails. This again suggests to me that the full client/server relationship is not fully in tact.
To resolve this you'll need to make sure that the AnyConnect user has access to all Domain Servers that interact with the client during gpudate. Remember that the VPN session is only concerned with passing traffic based on the OSI Layer 3 IP address. This means that if you have split-tunneling enabled the user must have all the necessary AD servers in the split-tunnelled list. If you're not using split-tunneling (in either case really) be sure that each one of these servers has a route to the ip address allocated to the AnyConnect user. Again, ASA inside interface captures are your friend in determining where this problem could be
3. In order to get Outlook to connect to exchange I've had to change Outlooks security settings from Negotiate (which would naturally choose Keberors), to NTLM. Not sure if this is related or not.
What protocols and ports do you have configured for Kerberos and NTLM? Typically Kerberos uses UDP port 88, I think NTLM uses a dynamic high port - not sure if it's TCP or UDP. In either case, the critical thing to identify is the exchange server's IP address. Verify this ip address is reachable across the vpn connection. Then check to see if the ASA could be blocking this traffic or if it's maybe an inspection issue. You'll want to investigate this further with packet captures as well.
The most common problems are:
1) server not in split-tunnel list
2) no route between AnyConnect assigned ip address and server
3) Inspection not configured on ASA causing fixup issues of these protocols.
Did this answer your question? If so, please mark it Answered!
