Seamless athentication to Webtop

The simplest way to do this is with client side (AAA) Kerberos authentication. In 11.4 and above you can also do native NTLM, but that configuration is a bit trickier.

Sure - you can use Kerberos or NTLM. Check out this article for details:

https://devcentral.f5.com/articles/leveraging-big-ip-apm-for-seamless-client-ntlm-authentication

Thanks for the responses. I have had a look at that article and it goes into great depth for setting up seamless auth for domain joined machines where SAML resources are being accessed. I guess to prevent a double login and make the BigIP aware of the user trying to access the SAML resource (via NTLM) instead of prompting for credentials when the iDP is called?

We dont access any SAML resources directly via SP links (although we could and some users do). They are presented as applications within our webtop, after an initial login to the webtop is made and the user is challenged for credentials. At that point when accessing SAML resources, it becomes seamless for us...

What I cant figure out is how I would configure the Webtop for seamless login so the end user experience would be as follows:

1)User Logs into domain joined machine 2)User browses to web top 3)Seamless log in to webtop, as APM should know who the user is because the user has already authenticated to the domain 4)List of applications (Portal Access, SAML Resources, Webtop Links etc etc) presented to user automatically and dynamically via AD Group Membership as APM already knows who the user is 5)User clicks a SAML enabled applications, that is also seamless, as the APM already knows who the user is.

Is this user journey possible?

Not sure when SAML was introduced to the conversation, but that shouldn't matter. You can very simply create a client side Kerberos AAA authentication (401 and Kerberos Auth) at the beginning of the access policy evaluation).

1. The user contacts the APM VIP.
2. The APM VIP responds with a 401 Unauthorized message and WWW-Authenticate Negotiate header.
3. The domain-joined user contacts its local DC/KDC to get a ticket for this service, and then returns to the VIP with a Kerberos ticket.
4. The Kerberos Auth agent validates the Kerberos ticket and allows access.
5. The access policy assigns the webtop and additional resources to the user.

You can do more or less the same thing with NTLM on the client side, but again it's a little more involved. Once the user is authenticated and has a webtop, there's also a session variable stored in the access policy, session.logon.last.logonname, that contains the user's AD UPN (ie. bill.user@mydomain.com). You can use this to do server side authentication, IdP-initiates SAML, etc.

Kevin,

Thanks for the detailed response... it looks like this exactly what I need to achieve.

Couple of questions:

• Would using NTLM or Kerberos both result in session.logon.last.logonname being stored as a session variable that can be used for SAML?

   

• I'm trying to find the steps to follow to set both of these methods up for testing... Should I look further at the document Michael linked me too, or do you know of any easier to follow document that covers this particular scenario?

   

Would using NTLM or Kerberos both result in session.logon.last.logonname being stored as a session variable that can be used for SAML?

I believe so. I haven't done enough with client side NTLM to have it emblazoned forever in my noggin, but it certainly does create this value in client side Kerberos.

I'm trying to find the steps to follow to set both of these methods up for testing... Should I look further at the document Michael linked me too, or do you know of any easier to follow document that covers this particular scenario?

Michael's doc on client side NTLM is probably the best resource out there. As for client side Kerberos, there's a few "official" resources, including this one:

http://support.f5.com/content/kb/en-us/products/big-ip_apm/manuals/product/apm-aaa-auth-config-11-4-0/_jcr_content/pdfAttach/download/file.res/BIG-IP%C2%AE_Access_Policy_Manager%C2%AE_Authentication_Configuration_Guide.pdf

I'm going to caveat the above with an observation that the official guides aren't that great when it comes to Kerberos. Read through it and if you have any questions, please ask.

Hi Kevin,

If we are plugged into a AD domain, would there be any reason why we would potentially want to use NTLM over Kerberos?

If using Kerberos, the BIG IP can seamlessly collect the users credentials to then pass onto other resources presented by the dynamic Webtop once accessed, to provide a seamless SSO experience all the way onto the hosted resources then I see no need for NTLM or any other authentication method for the WebTop (unless needing a failback option)

... but then again, I could be looking at this very simplistically!

To do seamless authentication to the webtop in a Windows environment, your only two real options are Kerberos and NTLM (as these are the only two types of authentication tokens that Windows natively supports). It's important to understand though that neither of these methods exposes a user password. So once you've successfully authenticated a user on the client side of APM and exposed the webtop objects, the only usable attribute you have from that client side authentication is the user's username and domain. You cannot do server side NTLM because you'd need a password. You could technically do client side NTLM or Kerberos, but you'd be limited to Kerberos on the server side.

I think this is starting to make sense... Once I have done Kerberos on the client side of the APM and exposed my webtop objects, could I then do SAML (on the webtop objects that support it) on the server side... without needing to collect the users password?

noting the end result here I am trying to validate is that I have logged into my domain joined machine.. I fire up a browser and go to my webtop, it lets lets me straight in, because I have aleady logged into the domain. From there I am presented a link to an application that authenticates me using SAML (via an iDP linked to the same AD I logged into my workstation with).. when I click that link, again I should go straight in as it should recognise due to the credentials I have already logged into my machine with.

That would be sort of a dual authentication thing I think, albeit still transparent. You're going to log in to the APM webtop seamlessly by virtue of Kerberos authentication from your domain-joind workstation. The webtop can have links that point to SAML-based resources that will redirect to an IdP that also does seamless authentication via Kerberos and passes back a valid SAML assertion. This should definitely work. You could also technically perform the IdP functions in APM so that the links either send an IdP-initiated request to the application, or the SAMLRequest from the resource comes back to APM and is auto-authenticated by virtue of the existing session.