I recently had to implement an SSL-VPN solution with a customer who was using the radius PassGo Defender solution (now Quest). I thought I would share my results as I had some struggles with the implementation.
Overview: There are two type of token based challenge response modes that can be invoked using tokens. The first is called synchronous. In this case the token is used in response only mode. The end-user logs in and uses their ID and some form of password which is either just the token response, token plus LDAP password, token plus pin, token plus defender password - all dependent on radius configuration.
The second is called asynchronous. In this case the token is used in a challenge / response mode. The end-user logs and uses their ID and if desired a password (LDAP or defender). They then receive a second login screen which presents the Defender challenge. This is then entered into the token which generates a response which is then entered into the second login screen for authentication. This second response can again include the challenge and a LDAP or Defender password concatenated onto it.
Sychronous Token: I have tested this scenario with the Defender solution. This is a piece of cake. Simply configure the radius information as usual on the SSL-VPN - server, port, shared secret. The SSL-VPN will pass whatever the user keys into the password field over to the raidus server and the authentication will occur.
Asynchronous Token: I also tested this scenario with the Defender solution. This solution is VERY dependent on the backend radius server. The Defender component consists of the token code and may or may not include a radius server. The standard radius Windows server implementation works exactly the same as the synchronous solution. User logs in with ID and or ID/Password. SSL-VPN automatically returns with response and prompt for challenge entry. Challenge entry and/or challenge entry with concatenated password can then be made.
If using other back-end radius servers the SSL-VPN requires some additional configuration. The test environment that I used had the radius authentication being handled by OpenRadius, an open-source based Linux implementation. In order to get the second login screen with the displayed reponse and a prompt for challenge/password entry I had to do a bit of extra work.
In this case it was necessary to build a "custom radius authentication rule" - the rule was quite simple. If an incoming packet type was AccessChallenge then create a rule based on the radius attribute of Reply-Message and do an expression match of "(.*)" --- enter this without the quotes.
Then take the action of "show GENERIC LOGIN page"
Other radius server backends make look for different expression strings. A Juniper KB refers to another string of "([0-9a-zA-Z/+=]+)" again, entered without the quotes. This DID NOT work with the OpenRadius backend.
If you read the documentation you might think that you could do a packet capture and enter in the expression that the radius server returns as the expression - This is incorrect. I also tried the other actions with various expressions and again, only what I refer to in the prior paragraph with work correctly.
I spent some quality time troubleshooting this problem and trying every permutation out there and this solution, derived at with help from JTAC works.
I hope somewhere down the road that this may be of assistance to other community members.
