Authentication access policy for intranet site / APM Module

In fact, we obviously already utilise two VIPs for this intranet, I'm just trying to figure how best to manage altering that exisiting LTM config for these APM requirements. We offload all SSL on the F5 by the way, everything internal is decrypted.

I've been noodling on this one and it occurred to me that:

1. A browser will not send a Kerberos ticket unless the server asks for one (via 401 response).

    

2. A browser that receives a 401 response, and cannot satisfy it with a Kerberos ticket, will generally prompt the user with a credential dialog box. There's no opportunity to fail over to a form page if Kerberos fails. You could very easily do Basic authentication since you're already getting a logon dialog though.

    

Another alternative is perhaps to switch client side SSO methods based on an attribute of the client. If external and internal clients have different IP ranges, you could prompt them differently. Of course if an internal user failed to present a Kerberos ticket after 401, they'd get a credential dialog.

Right. Well that's very interesting. In our case there is no authentication mechanism on the back end web servers, we're trying to get the credential 'pickup' and AD query managed by the APM entirely, I've been running on the assumption that the APM could manage that itself. Is that not a common use case?

I'm not referring to the back end authentication, but rather how the client browser responds to an authentication prompt. Let's say you could determine that a user, given their IP address, was coming from the internal network. You could send them a 401 response, hope for a Kerberos token, pull that Kerberos token apart, do some lookups, whatever you want, and then send the user down the right path. If the user came from an external network, you'd present a logon form, do some lookups, whatever you want, and then send them down the right path. This is all happening on the 443 VIP by the way. So the the question remains:

1. Can you differentiate internal from external users?
2. And if not, can you use a Basic dialog instead of a form page if Kerberos fails?

Oh I see what you mean now sorry. Yes, I can easily differentiate between internal and external users based on their IP address. So my two main access scenarios would be:

1) Domain joined user on internal IP range connects to HTTPS VIP and has a kerberos token in their session. Their token will be interrogated, a query ran, and access granted.

2) Non Domain joined user on external network connects up and is presented with the Forms based F5 login page. they authenticate via AAA, an AD query verifies they meet our access requirement, and they are granted access to the resource.

But there would be this odd case on occasion, when an internal user didn't have a kerberos ticket:

3) User connects on internal network without a kerberos ticket. Users browser is issued with a 401 response, but cannot respond with a ticket, so produces a basic login dialogue box.

In scenario 3, is is easy enough to have the APM accept the credentials supplied via Basic authentication from the browser? We could have this situation for a number of reasons being a university, non standard browsers, Mac or Linux computers not joined to our AD domain, etc...

Also, if a user does have a kerberos ticket, but after our AD query we find they don't have the desired authentication, would it be easy enough to pass the user to the forms based login? I'm assuming it would because at this stage in the access policy we would have moved from the kerberos pickup to an AD Query, and so we would get to decide the outcome?

In scenario 3, is is easy enough to have the APM accept the credentials supplied via Basic authentication from the browser?

Absolutely. It's built into the 401 response agent.

Also, if a user does have a kerberos ticket, but after our AD query we find they don't have the desired authentication, would it be easy enough to pass the user to the forms based login?

Yes, that would be pretty easy. But curious, if the Kerberos ticket they requested from the local KDC wasn't acceptable, what credentials would you expect in the logon form?

You're absolutely right, ignore that last comment, that would be a completely pointless configuration. I just wasn't thinking straight :)

I've updated my diagram to show a little more logic in the access policy area. I think it might be starting to come together into something I can test. What do you think?


So, I'm going to get building a POC based on that diagram, and when I'm at the point of building the Access Policy (in particular the Kerberos token picket parts) I'll run it by you again to get some advice. Is that OK?

Just wondering how you went with this one, I also am fiddling with the Kerberos auth and then needing to do an AD Query for Group membership. Did you manage to figure that bit out?

Just wondering how you went with this one, I also am fiddling with the Kerberos auth and then needing to do an AD Query for Group membership. Did you manage to figure that bit out?

A successful client side Kerberos authentication will produce a session.logon.last.username value in UPN format (ex. bob.user@mydomain.com). To do any form of AD/LDAP query against that value, you may need to break it apart, though it should already be the userPrincipalName value. Example SearchFilter:

userPrincipalName=%{session.logon.last.username}