SecSignID 2FA: Radius Proxy

The SecSignID 2FA authentication overview for RADIUS:

1. User logs into a service which is protected with a RADIUS server (for example VPN, Cisco ASA etc.)
2. Usually the VPN server now sends a RADIUS request to the RADIUS server in order to authenticate and authorize the user. Since we integrate 2FA, all requests will be sent to the SecSignID RADIUS Proxy
3. The SecSignID RADIUS Proxy just forwards the RADIUS request to the RADIUS forward server
4. The RADIUS forward server uses the primary authentication (for example Active Directory) to determine if the user credentials are valid. Primary authentication returns authentication success to the RADIUS forward server
5. The RADIUS forward server crafts a RADIUS response and sends it back to the proxy
6. The SecSignID RADIUS Proxy requests the SecSignID of the user from the Active Directory based on the user name. If a SecSign ID is assigned it is transmitted back to the SecSign ID RADIUS Proxy. If you do not want to change your AD Schema, you can also utilize an on-premise ID Server or use a text file with the user mapping (for testing)
7. The SecSign ID RADIUS Proxy contacts the ID Server with the determined SecSign ID to perform the two-factor authentication. The proxy constantly asks the SecSignID Server, if the ID is authenticated
8. The user gets a notification on his smartphone that an authentication session is pending. The user logs into the app via PIN code, fingerprint or face recognition, can see the pending login and taps on the correct access pass symbol.
9. The SecSign ID RADIUS Proxy gets a response from the ID Server, that the two factor authentication was successful and a RADIUS confirmation is sent to the VPN server
10. The VPN server grants access to the client for the VPN

When your users login, they usually authenticate with user name and password first. After that, the second factor will be requested. So how does the mapping of user name and SecSignID work?

You have several options to assign a SecSign ID to a user:

• The most comfortable solution is an on-premise ID Server that will handle the mapping. It saves the user names in an internal database and performs the two-factor authentication. You have full control of user data, enrollment policies and naming patterns.
• If you don’t need the advanced functions of an on-premise ID server, you can add an attribute to the user profiles in your Active Directory quite easily. See here how it works. Adding the SecSignID mapping into Active Directory makes it easy to manage and administer user accounts
• A simple text file can also handle the mapping. It’s recommended for testing purposes only, since this method is error prone and does not support advanced enrollment features

Please contact us, if you do not want to modify Active Directory user profiles. We offer ID – Username mapping with our on-premise SecSignID server. Mapping via text file is not recommended but possible.

1. Java VM

As the SecSign ID RADIUS proxy is written in Java it can be run on any operating system with Java support like for example Windows or Linux. So the first step of the installation is to install a recent Java virtual machine preferable with 64 bit available at Oracle’s web site.

2. SecSign ID RADIUS proxy files

The directory SecSignIDRadiusProxy contains the application code in a JAR file and its configuration file. This directory has to be copied to the system that shall run the SecSign ID RADIUS proxy.

3. Setup Environment

We assume, that you already have a working setup, where a VPN (or other service) utilizes RADIUS to validate user credentials against Active Directory.

To integrate the SecSignID RADIUS Proxy, we have to change the endpoints. The VPN server already got the RADIUS server address, which needs to be changed to the RADUS Proxy address.

The Radius server already got the client configuration of the VPN server. The only client the RADIUS server needs to know is the RADUS Proxy.

The VPN and RADIUS server do not need to know each other, they just need to know the Radius Proxy, which sits in between the two

Configuration of the SecSign ID RADIUS proxy

The configuration file secradiusproxy.properties needs to be edited:

The default port number of RADIUS is 1812. If necessary, if different value may be set here:

If the SecSign ID RADIUS proxy shall only bind to a specific IP address it may be specified here. The default is to bind to all IP addresses the machine has.

For each RADIUS client (for example a Microsoft Windows Server) the proxy needs to know the IP address and the shared secret. The list of RADIUS clients starts with the index ‘0’ and may have any number of entries which are consecutitvely numbered.

The proxy also needs to know where to forward the RADIUS access requests for validation of the primary authentication credentials (user name and password). This forward RADIUS server may be for example another Microsoft Windows Server or even the same as the RADIUS client.

For each Windows user whose log-in shall be secured in the SecSign ID the Active Directory must contain an attribute containing the SecSign ID user name of this user. The proxy uses an LDAP connection to query the SecSign ID user name in the Active Directory. For this LDAP connection it needs the name and password of a technical user with read access to the users branch of the Active Directory. Furthermore, the base DN will tell the proxy where to find the users branch in the LDAP tree. The recommended full name of this technical user is SecSign ID Radius Proxy and its descrption: Technical user to allow AD LDAP queries for the SecSign ID RADIUS proxy.

The proxy will keep a copy of each received RADIUS packet for a certain time in order to recognize duplicate packets. The proxy will also remember the Windows user names for whom it is waiting for the completion of the SecSign ID log-in. The proxy will not start a new log-in session for such users if requested by the RADIUS client. The time out for both list entries can be specified here.

In order to initiate a SecSign ID log-in the SecSign ID RADIUS proxy needs the host name of the SecSign ID server and optionally of fallback SecSign ID servers:

The connection to the SecSign ID server is TLS encrypted. Therefore, a DER encoded trusted certificate of the SecSign ID server may be configured. If the server uses a certificate issued on its official DNS name by a regular trustcenter this configuration entry is not necessary.

A timeout value be set after which the proxy tries to send its request to the next fallback SecSign ID server:

The SecSign ID RADIUS proxy may use a HTTP proxy to send requests to the SecSign ID server. The HTTP proxy has the following settings:

If certain hosts can be reached without the general HTTP proxy they can be named here:

The SecSign ID RADIUS proxy may write a log file. It contains all messages whose severity is equal to or above a specified level.

The levels are:

• 0: Error
• 10: Warning
• 20: Standard
• 30: Usage
• 40: Event
• 50: Debug
• 60: Verbose

The proxy may begin a new log file each day:

The proxy can be started with:

The proxy will output messages like:

Pressing ^C in the terminal window will end the proxy.