on 12-Jul-2018 16:20
Based on the feedback I got when talking about this capability on social media, I figured I would write an article and expose everyone to what this solution actually looks like and how to deploy it. First off, I want to dig into the use case itself. While the use case for each organization could and is likely different, for a small group of us at F5 Networks had a requirement to smart card enable network devices. Well of course that statement alone comes with a lot of hesitation and questions from your network shop. One likely being "how the heck do you smart card enable something that doesn't support smart card authentication? Then if you can, how the heck to you configure putty to support smart cards without spending a billion dollars?" This is when you tell them, I'm glad you asked because you can't. However, with F5 being the magical software company it is we can enforce smart card authentication, OCSP validation, generate a one-time password (OTP) and present that to the device to authentication all while using your favorite browser. Sound impossible? I think not, so let's get to it!
Before getting to far ahead, I wanted to clarify, this is NOT a solution I developed but rather hoped to educate some folks on. The heavy lifting and development came from F5 all stars like Bill Church and Michael Coleman. So when you get done reading this article and want to thank someone, make sure to send them a note.
Alright, now that I have provided you with what my use case is lets go ahead and begin the deployment. From a browser, go ahead and navigate to https://github.com/billchurch/f5-pua to download the offline privileged user access zip file that contains all necessary components and for the most part deploys this solution for you. Yes....once again, thank you Bill Church! Once downloaded, extract the build_pua_offline.sh file from the zip.
If you are using a Windows box like myself, go ahead and either download or launch something like WinSCP so that you can transfer the shell executable to your BIG-IP. I simply transferred the .sh file to my /tmp directory as shown below. Once transferred, go ahead and close WinSCP.
Because we haven't deployed our WebSSH solution yet we are going to use putty to SSH to our BIG-IP and run the script. Once authenticated, navigate to the directory you stored the .sh file and run the command bash build_pua_offline.sh.
You will first be presented with a set of instructions regarding questions you will be asked during the running of this script. Press any key continue.
As the instructions imply, you will be providing several IP addresses for the required virtual servers. Please note, the only IP that can NOT be shared is the IP for the WebSSH proxy.
Once you have provided all of the necessary IP addresses you will be presented with an option to create a CA for testing purposes. In this guide, we will select N for this option.
After all profiles, virtual servers and policies have been created you will be presented with a question of whether or not to configure the BIG-IP to test Radius by configuring remote user authentication for Radius. We will select N for this option.
If the script completes successfully, this will be the last item you are prompted for. In our case we had a successful deployment of the build_pua_offline.sh script so let's take a look at the objects that were created.
Virtual Servers
LX Workspaces
LX Plugins
Access Policy
Portal Access List
Webtop List
HTTP Basic Auth Profile
When configuring the BIG-IP to use LDAP Authentication as you will see at the end of this article, you will need to include that user account in the ephemeral_LDAP_Bypass Data Group List.
While the script run at the beginning of this article does indeed create a portal access list with resources, we will go ahead and create one in order to show a bit more of the solution and its inner workings.
This policy was created for demo purposes only though it also provides a very good starting point for configuring our own policy to support smart card authentication.
When prompted to select the Auth Mode, select Require from the drop down menu and click Save.
We will configure the following variables based on F5 solution article K17063 found at https://support.f5.com/csp/article/K17063.
set upn [mcget {session.logon.last.upn}]; # if $upn contains @ symbol, extract the username, otherwise return $upn as-is. if { $upn contains "@" } { # Use string first to find index of the @ symbol, then return everything in-front of the @. return [string range $upn 0 [expr { [string first "@" $upn] - 1 } ] ]; } else { # Assume UPN only contains a username return $upn; }
set x509e_fields [split [mcget {session.ssl.cert.x509extension}] "\n"]; # For each element in the list: foreach field $x509e_fields { # If the element contains UPN: if { $field contains "othername:UPN" } { ## set start of UPN variable set start [expr {[string first " # Return the UPN, by finding the index of opening and closing brackets, then use string range to get everything between. return [string range $field $start [expr { [string first ">" $field $start] - 1 } ] ]; } } # Otherwise return UPN Not Found: return "UPN-NOT-FOUND";
When redirected to the LDAP Query Properties page, configure the following.
You have now completed the VPE portion of the access policy.
Navigate to System > Users > Select Remote Role Groups
For my validation testing, I created a DNS record for webtop.demo.lab pointing to my webtop virtual server.
If authentication is successful, you will be presented with a webSSH session as shown below.
While this wraps up an overview of deploying and accessing F5's WebSSH capability with integrated smart card authentication, I would like to continue this into a series which includes other network devices or applications, end point checks, restricting access to the management interface and more. If this benefits at least one of you out there this was well worth it for me. Until next time.
Hi Steve,
This looks awesome. One thing, is the code block for the customized variable assign "session.logon.last.upn" supposed to have newlines?
Another thing, could we modify the URL to use different IPs to reach other hosts?
Josh
Josh,
Sorry for the delayed response. I am not tracking your question 100% though I will still try and add some more color. So the custom variable assign does have new lines. As shown in the article I will use the "Add New Entry" for the UPN simply to extract it so we can perform the LDAP query against it later in order to gather the sAMAccountName. When I am normally doing variable assign for smart card auth and the UPN @ is different than the domains realm I often add the variable session.logon.last.domain though in this case it really is not needed. With that, adding custom variables are awesome because it allows you to make so many more access based decisions based on them.
In regards to the URL and different IP's, absolutely. In my example I simply used the BIG-IP because unfortunately I don't have a ton of other vendor equipment in my lab environment. There is even a document out there which I may write an article on to import a large number of devices to authenticate versus manually inputting each one. The thing to remember though when using other equipment is that if using LDAP or LDAPS you will need to point the device to the BIG-IP VS or the TACACS server to the BIG-IP as the LDAP server. Also, I didn't really get into it though if you notice there is a Radius Server VS created by the script. This also allows the BIG-IP to act as a radius server with authentication, authorization and accounting capabilities your normal radius server does not have.
There really is so much you can do with this solution so I will do my best to continue writing how to articles to expose the broader community to them. Hope this helps.
Steve
Was just starting to look at this and my use case would be to communicate through the f5 to other ssh devices in the url. You seem to indicate that is possible however for Authentication wondering if it is possible to send a Kerb token. Not really sure I understand how using the f5 as am ldap/radius proxy provides this.
Hi Scott. So the real intent of this solution was to support those that may not support smart card or Kerberos. With that, I don't see why configuring Kerberos SSO would be an issue. Create your own access policy with Kerberos SSO that still uses the WebSSH client. I will see if I can set this up in my lab and share.