on 18-Jul-2018 14:51
As promised in my last article which discussed configuring the BIG-IP as an SSH Jump Server using smart card authentication, I wanted to continue the discussion of F5's privileged user access with additional use cases. The first follow on article is really dedicated to all those customers who ask, "how do I use a smart card to authenticate to the BIG-IP TMUI?" While yes, I did provide a guide on how to do this natively, I'm here to tell you I think this is a bit easier but don't take my word for it. Try them both!
To reduce duplicating content, I am going to begin with the final configuration deployed in the previous article which has been published at https://devcentral.f5.com/s/articles/configuring-the-big-ip-as-an-ssh-jump-server-using-smart-card-authentication-and-webssh-client-31586. If you have not completed that guide, please do so prior to continuing with the Traffic Management User Interface (TMUI). With that, let's begin.
https://devcentral.f5.com/s/articles/configuring-the-big-ip-as-an-ssh-jump-server-using-smart-card-authentication-and-webssh-client-31586
Now you may be asking yourself why would I need this? Well, if any of you have attempted this in the past you will notice you will receive an ACL error when trying to access the management IP directly from a portal access resource. Because of this, we will need to complete this step and point our portal access resource to the IP of our virtual server.
Now you have successfully configured SSO to the BIG-IP TMUI using forms based authentication. I'm sure many of you are wondering how it is possible to perform forms based authentication when I provided no password in this entire article. This is possible because of the ability for the F5 PUA solution to generate a one-time password on behalf of the user and present it to the application. Thanks for following and I will continue with additional use cases and capabilities of the F5 BIG-IP.
If for any reason you attempt to logout of TMUI and are logged back in immediately, it is likely because of middle ware you have in place on your workstation though no need to worry, there's an iRule for that! Simply add the following iRule to the Webtop virtual server and you will be good to go.
when HTTP_REQUEST { #log local0. "[HTTP::uri]" switch -glob [HTTP::uri] { "*/tmui/logout.html" { HTTP::respond 200 content "Logged Out. Close Browser." } default { } }
}
Hi Steve
I've been looking at the authentication logic and was wondering if you could help me out understand it a little bit better.
I can see the iRules creates a subtable with hashed credential information but I don't seem to be able to find where that information is lookup, can you point me in the right direction?
So, I may not fully understand your question but I will try and at least shed some more light.
The password is stored as a session variable which can be seen below.
within the ephemeral_config DG is where you can configure additional requirements for your OTP. password complexity rules variables
pwrulesLen - integer - optional - Password Complexity, minimum password length/characters. Example 8 (default)
pwrulesUpCaseMin - integer - optional - Password Complexity, minimum upper case characters. Example 1 (default)
pwrulesLwrCaseMin - integer - optional - Password Complexity, minimum lower case characters. Example 1 (default)
pwrulesNumbersMin - integer - optional - Password Complexity, minimum numeric characters. Example 1 (default)
pwrulesPunctuationMin - integer - optional - Password Complexity, minimum punctuation/special characters. Example 1 (default)
Aaah nice. I didn't realize that the ldap proxy only intercepted relevant requests.
Back to my question. I think I understand it now, you transfer the ephemeral password to a session variable which is used in the SSO.
I haven't tried to implement it yet but I'm sure your guide will make it quite easy for me to do though it is in a nice package.
I like to know a little about the logic before I use it as it is a rather complex solution and troubleshooting it would not be easy, that and that I'm not strong in iLX. I might dissect it and use parts of it as it enables some crazy implementations options. And no competitor can do anything like this (not even close!) so a presales setup would make sense.
If this functionality could be baked into the product I would prefer that, the solution has many moving parts. Maybe a iAppLX package could do it?
Anyway thanks for the elaboration of the implementation.
This appears to mostly work right off the bat - assuming you have a PUA iRulesLX environment working already. The main problem I have is that it drops the user to an 'Authentication Required' screen initially but if they click on the IP link to essentially refresh the page, then the GUI displays.
Why you didn't apply the access policy you created in the Virtual Server?
Will this solution be applicable for SSO of Multiple BigIP TMUI using Remote LDAP Authentication for username and password?