RADIUS Accounting And Keyshield SSO

RADIUS Accounting has been a standard for many years for - accounting! Whenever you authenticate to an internet service provider, your client sends the RADIUS Accounting packet START. Once the provider receives this packet, they start to charge you immediately. When you disconnect, your client starts the procedure by sending a RADIUS Accounting STOP packet, asking the provider to stop charging. If you lose the connection, then the provider will stop charging you after a time-out period, because the expected RADIUS Accounting KEEP_ALIVE packet didn’t arrive within the period.

Each RADIUS Accounting packet is encrypted by a  pre-shared key (which the user/administrator had to enter as a part of the client configuration) and contains user identification. This is the basis of RADIUS Accounting and also shows that RADIUS Accounting is something totally different from RADIUS.  Because of the described functionality, a wide variety of Network Appliances support RADIUS Accounting authentication; a firewall receives the START packet, authenticates you and let’s you communicate to the internet for example.

A RADIUS Accounting network device can support two modes - client or server. A client basically reports the identity of its user or users. Of course, this can only happen if the client “knows” the pre-shared secret. Without it, nothing can be delivered to the server.

Servers receive RADIUS Accounting packets and handle them in various ways. User accounts can be provisioned on the fly or the RA packet information must match an existing user account. Servers also accept group membership information which is the way to control user rights. Being a member of NO_INTERNET_ACCESS group doesn’t make users happy as much as their boss!

Two use scenarios then are:

  • User authenticates to a WiFi AP and this device authenticates them seamlessly to the firewall and web content manager in order to let the user go out
  • Users authenticates via a VPN from the outside and the firewall authenticates them seamlessly to an IdP (identity provider) or second firewall which protects access to the LAN.

Why not? The majority of firewalls today offer far much more secure IPSEC VPN 2FA (group and user) authentication than standard desktop systems. If there is no such integration, the user has to authenticate twice …  These scenarios look really useful, right?

But, what is the traffic which should pass the firewall for example? Packets. The packet doesn’t contain any info like - “I’m from Joe”! So, RADIUS Accounting authentication connects the user with their actual IP address. Whatever comes from this address belongs to Joe and is handled in accordance with Joe’s rights.

This is why many existing solutions are a bit strange because they need to learn the user’s IP address when they already know about their AD or eDIR identity, or they work through an encrypted channel handled by either a browser or VPN client. Thus you can find solutions checking the PDC log or eDirectory network_address attribute. Because anything like that is not reliable and secure enough, many funny (or sad, it depends if you are an employee or a boss) situations may occur.

Of course, if you use a RADIUS client with RADIUS Accounting functionality, you are OK. It’s just that your users are not happy with that. It’s not convenient at all and they will try whatever they can to circumvent such a solution.

RADIUS Accounting is not RADIUS!
RADIUS (Remote Authentication Dial-In User Service) is a networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA or Triple A) management for users who connect and use a network service.  Originally developed for dial-up services the protocol is currently defined in RFC 2865.
RADIUS Accounting is specified in RFC 2866. This describes a standard method for communicating accounting data from a network device to a RADIUS Accounting server which could be a database or even a text file.

There is also another issue with anything driven by just a client - users often do not shut down their devices for weeks. They don’t switch off and on daily nor regularly. They just disconnect or click a sleep button. That means that the authenticated session has to be logged out by time-out. This can lead to a serious risk – an IP address is authenticated but not owned by the user.  Browser dependent IdP class authentication solutions (well known as “SSO”) are exposed to very similar threads. But let’s leave this for another article.

The conclusion is easy - network appliance authentication is very important in today’s world, it brings security, control and compliance. If your users are students or pupils, you need this twice over to protect them against unwanted content. They should be placed in a different group from adults in a school’s web content manager. But the implementation can be painful for both admins and users as common solutions can’t work with IP addresses nor outside a browser.

Solution

KeyShield SSO (Single Sign On), used by Micro Focus for SSO authentication to browser and non-browser based protocols, has a solution for RADIUS Accounting. For those of you who already use KeyShield SSO for GroupWise, Vibe, Filr or NSD, this can be a surprise – a bonus out of the box. KeyShield SSO supports virtually an unlimited number of servers and clients as shown in figure 1.

34-radius-1-400x425
Figure 1: Keyshield supports unlimited servers and clients

Each client configuration works with a specific server, firewall, web content manager, proxy server etc. The RADIUS Accounting configuration is easy, refer to figure 2 where both the Target host and port point to the RADIUS Accounting interface of the device.

34-radius-2-400x415
Figure 2: Client configuration

The shared secret is the code entered on both sides and the username attribute is from where KeyShield SSO reads the value - username - provided to the device. x-filr is a default alias for names for Micro Focus Filr and it serves great for RADIUS Accounting too.  For other parameters refer to the description above. On the server (firewall side) the configuration is even easier as shown in figure 3 – using in this case a FortiWifi RA SSO.

34-radius-3-600x202
Figure 3: Server configuration

In reverse, KeyShield SSO can accept information about the user’s identity from a trusted source; a properly and securely configured firewall. The configuration shown in figure 4 looks similar but in this case the server address is the address from which RADIUS Accounting packets are received. The pre-shared secret works in the same manner as before but in this case KeyShield SSO decrypts and validates incoming packets.

34-radius-4-400x401
Figure 4: Server address is the source

Last but not least is a user source connector which is used for user lookups. While client mode can be used with unlimited number of sources (connectors) thanks to the attribute alias function, here only one user source can be used because of the risk of duplication.

Conclusion

With more and more hosted services and in cloud installations, firewall and other network appliances authentication becomes more important. RADIUS Accounting authentication is a fast, reliable and secure way which can help you to access Micro Focus and virtually any services outside your LAN or WAN.  It makes the life of your travelling users significantly easier; once they authenticate to the VPN, they can read their emails, work with their files and their projects without any further time consuming authentication.

 

This article was first published in OHM issue 34, 2016/3, p12-13

Leave a Reply