Forum Discussion
NimbostratusPer-App-VPN using Kerberos Constrained Delegation and Protocol Transition...HELP!
First a picture of what I'm trying to do:
Now for a brief description: We are trying to implement per-app-vpn (AIRWATCH). We stood up a "VPN only" BigIp appliance "VPN1" that hosts the vpn address (apm.mycompany.com). We authenticate the client device with a certificate. The client device destination is work.mycompany.local which is hosted internally on a different BigIP appliance "INSIDE1".
The client device cannot get a Kerberos service ticket...this is a long and painful story. So, I was hoping for a better option. I think there is with Kerberos Constrained Delegation and Protocol Transition, but I'm unable to figure out where to get my hooks in to make it work. The access policy for apm.mycompany.com on VPN1 has the certificate and user's upn (user@realm) but I don't know if it has the destination url work.mycompany.local. INSIDE1 doesn't have the certificate or the user's upn.
Just for fun, I set up an iRule that logs the responses back to the client and I don't see any 401's.
So for the 64K question(s): Is this design plausible? If so, where does the SSO happen? It makes sense that it would have to happen on INSIDE1 and I'd have to send some sort of token to tell and access policy on work.mycompany.local that this was a per-app-vpn connection, but then I'd have to do this for every endpoint the client wants to connect to instead of one centralized location. I'm happy to send logs and more diagrams, but I'm hoping this is enough to get the gist.
4 Replies
- Kerberos Constrained Delegation won't work without the client getting its own ticket. But if per-app vpn authenticating client certificate is working, and the client certificate has the kerberos username, you should be able to do kerberos sso with it
- Kevin_Stewart
Employee
The APM SSO process is going to end with the production of a Kerberos service ticket (AP_REQ) embedded in an HTTP request Authorization header, and that header is going to come from the device that performs the rest of the Kerberos negotiation. It's not impossible to do of course, but an SSL VPN generally doesn't perform SSO functions. The initiation of the VPN is the end state. What you'd need to do is to transmit the user's information to a separate access policy, potentially even the internal device, and then let it do the Kerberos SSO.
Michael_Koyfma1Cirrus
Yes, this should definitely be plausible. You would need to setup a layered internal virtual server that matches the destination of INSIDE1's IP address, enable it to listen only on the Per-App VPN tunnel(that would really be the connectivity profile created for your Per-App VPN policy), and assign Access Policy and Kerberos SSO to it.
- Michael_Koyfma1
Yes, this should definitely be plausible. You would need to setup a layered internal virtual server that matches the destination of INSIDE1's IP address, enable it to listen only on the Per-App VPN tunnel(that would really be the connectivity profile created for your Per-App VPN policy), and assign Access Policy and Kerberos SSO to it.
