Authentication access policy for intranet site / APM Module

Meant to submit this as a discussion - oops!

Quick question.

Check for a currently logged in kerberos or NTLM session token in their session.

Kerberos is a per-site/name authentication mechanism. Though it would be technically possible (I believe) to do late-session Kerberos auth, the browser will generally either attempt Kerberos authentication with a server on initial access or it won't (when it first accesses a VIP for example). What would you expect initial access to look like, before going to the /secure URI?

Hi Kevin,

I'm expecting to have top level/root directory access to the site open to anonymous users, and only apply the access policy to a select collection of sub sites (three sub directories at the moment).

For instance, www.intranet.com would be open access, but a request for www.intranet.com/secure would call forth the access policy, log the user in with a SSO mechanism of some description, and if not possible (ie, the user doesn't fillfil the SSO criteria, OR they aren't using a domain joined computer) present a standard F5 managed login page securing access to the resource...

Essentially, we want particular users within our organisation to be able to access the /secure sites without having to resubmit their AD credentials, and everyone else to be presented with the login page. This would mean that users with rights can log in to the resource using manually entered credentials when they are offsite, but when they are on-site, it's a seamless SSO experience.

We've had one engineer try to implement this solution, but efforts have been fruitless so far. I'm taking over and I want to go back to basics to see what sort of mechanisms support this functionality. I'm open to all ideas!

You say that the browser will attempt kerberos authentication on initial connection. Could an access policy be created to cach their credentials at that point, and store them to be used later on in the session, if they request one of the 'secure' URLs?

Cheers,

Gavin

Anyone got any thoughts? This can't be that unusual a use case can it? Have we bought the wrong product? :S

Gavin

Apologies, haven't had a chance to explore some of the more detailed questions. The first, and probably easiest approach is to simply disable the access policy until the user requests a trigger URI. Assign your access policy to the VIP and use an iRule like the following:

when HTTP_REQUEST {    
    if { not ( [class match [stringt tolower [HTTP::uri]] starts_with my_uri_dg] ) } {
        ACCCESS::disable
    }
}    

The access policy evaluation will only happen once, so once the user triggers it with a special URI request, they'll have a session cookie available for any other special access URIs. Just configure the access policy as you normally would.

I'll be working on the second part of your question Monday morning (switching between Kerberos and form logon).

Thanks Kevin, that's great :)

So that iRule gives me the ability to call an access policy only when certain URLs are requested, all I need now is some semblance of an access policy...

I've been able to successfully implement a basic access policy using an F5 login page, AD auth and AD query before, it's mainly the Kerberos SSO element that I'm having difficulty with. I've been on the APM training, but this degree of SSO wasn't covered from memory (at least not in any detail)...

One other issue to add to the mix, is that my client needs the login page to be SSL but the majority of the content that it gives access to will be unencrypted. There might be some design considerations there also...

As you can see, I'm a little grey on this, so any and all suggestions are very gratefully received. I'm not afraid of reading if you know of any decent training guides in this area. Thanks again Kevin :)

Best Wishes,

Gavin Connell-Otten

I've been able to successfully implement a basic access policy using an F5 login page, AD auth and AD query before, it's mainly the Kerberos SSO element that I'm having difficulty with. I've been on the APM training, but this degree of SSO wasn't covered from memory (at least not in any detail)...

Just to be clear, are you talking about client side Kerberos (where the client presents a Kerberos ticket to APM), server side Kerberos (where APM performs Kerberos-based SSO to internal resources), or a combination of both?

One other issue to add to the mix, is that my client needs the login page to be SSL but the majority of the content that it gives access to will be unencrypted. There might be some design considerations there also.

There will absolutely be some design considerations with this one. Most important, once a user has authenticated and has a session cookie, they should continue to use HTTPS (even for non-auth resources). You could, technically, use path and/or secure attributes in the session cookie to guarantee it doesn't get exposed to clear text HTTP, but your very best and probably most secure (and easiest) option is to stay in an SSL session after authentication.

This is just an (untested) idea, but you could create TWO VIPs - one LTM HTTP VIP and one APM HTTPS VIP (same host name/IP and same pool), then simply redirect users to the HTTPS VIP if they request a specific URI (based on data group for example). Make sure that the secure option is set in the access profile so that cookie isn't accessible to the HTTP VIP.

Hi Kevin,

We just need the kerberos 'pickup' to be client side. The content servers aren't going to expect any authentication, they are firewalled off and only the F5 will be able to speak to them, so it's good enough to have the authentication happen when the client connects to the F5. All we need to verify is that the current user is a member of a particular 'OU', then the F5 should grant full access to the resource.

The two VIP idea is one we've experimented with for this solution already (just using a basic login page not kerberos), but we had some unexpected side effects. There are a couple of sub sites under this root web server which use SSL, but don't require authentication. As you'd expect, users trying to access those sites were all of a sudden prompted to log in.

I suppose we could disable the access policy for requests to those particular URLs\ using your suggested iRUle logic below?

when HTTP_REQUEST {

Cheers,

Gavin

More important I think, how are planning to switch between HTTP and HTTPS URLs without using two VIPs?

You're right, we do need two VIPs, one port 80 and one 443. I've just put together the following diagram of the logic flow. I hope this explains and reduces down the requirements a little. I'm mainly lacking an understanding of how to grab kerberos tickets on the client side and run an AD query agianst the credentials in them. All I need the APM to do is identify the user and then do a query in AD for group membership, so that might actually be a little easier than full kerberos delegated authentication?