Find White Papers
Home About Contact Help
Free Membership Member Login
Search the Library                  Advanced Search

10 Reasons your RADIUS Server Needs a Refresh

Identity Engines
By : Identity Engines
INFORMATION
Published : Oct 15, 2007
Length : 12
Type : White Paper
 
Download Now
Save for Later
  Email This Page
Overview :
For over a decade now, RADIUS servers have been a mainstay of dial-up and VPN access control. The rather inconspicuous RADIUS server, perhaps better known as that beige, general-purpose PC collecting dust in the corner of your data center, has proved sufficient for performing basic duties like validating passwords and granting network access. But while these servers have been diligently chugging away at their tasks, the world of networking and security technology has evolved substantially, leaving the current generation of RADIUS servers in the dust.
View All Items By This Company
Browse Related Categories :

Access Control

,

Auditing

,

Authentication

,

Servers

,

VPN

 
1. You don’t have a AAA server, you have an AA server.
Accounting, authentication, and authorization are the cornerstones of a RADIUS server’s functionality. When you connect to a network, authentication validates who you are, authorization dictates what resources you can use, and accounting tracks what you have done. Frustratingly, for most networks today the middle “A,” authorization, is missing; feasible network authorization remains more dream than reality.
AAA only provides its promised benefits if all three parts are working together towards a common goal. In the past, this goal was merely to check the user’s password against a list, and authorization wasn’t required. With dial-up and VPN access control, the goal became to grant remote users the same access rights they would have, had they connected to the network by connecting directly to a network port on-site. Still, authorization was not part of the picture in most environments.
Now, IT teams aim to solve bigger problems when they roll out AAA. Current industry regulations and audit requirements demand two important evolutions in AAA server capabilities, far beyond what incumbent AAA servers can provide. The first new requirement is for the network to allow system-wide auditing of access events. This capability allows the AAA system to answer queries like, “When and from where has Karen Benning in finance accessed the network over the last 90 days?” or “Were finance users accessing critical finance resources from secure locations?” These types of queries simply cannot be answered unless the AAA infrastructure authenticates and authorizes every user session on your wired and wireless infrastructures, in addition to your dial-up and VPN.
The second new requirement is to manage access rights based on the role of an individual within an organization. Today, industry regulations and audit requirements demand that networks no longer provide one-size-fits-all access. For example, sales people should be able to access sales systems, but not engineering systems; finance employees are the only users who should be allowed access to the finance servers and, even then, only if their computers have up-to-date virus protection and a secure network connection.
Today’s unauthenticated networks and legacy RADIUS servers are incapable of performing such functions. Much like a country without Customs for Immigration, or a high-rise apartment with only a single lock on the front door to the building, the lack of authentication on most networks today means that, once past the “front door,” an adversary has the complete run of the place, leaving each application to fend for itself by providing its own layer of access control. This is clearly not secure; the new goal, therefore, is auditable, role-based access control to the network itself.
In order to provide authorization, a RADIUS server needs to have a more in-depth conversation with the network-edge device through which the user connects, and this conversation must be based on a far more in-depth policy. A simple policy for your existing platform might be:
Finance users may only access finance resources when they authenticate with a token, are within the building, and are on a secure connection. If they don’t authenticate using a token or enter via a secure connection, treat them like a normal user with no access rights to the finance network.
Today’s RADIUS servers simply can’t implement this policy. Identity Engines’ Ignition Server was built to consider such a policy routine.
At the heart of Ignition Server is a flexible policy engine based on the XACML standard. It allows you to write rules any way you want leveraging all the information available from network devices and all the work your applications group has put into your back-end user directories. Simple Boolean expressions can be linked together to form very complex policies such as:
Students enrolled in Calculus 201 should be disallowed access to the network when attempting access from Branham Hall on November 12th between the hours of two and four PM. Access at all other times and all other locations should be accepted with authorization rights of the “student” role.
Precise access policies like this one elevate the role and utility of the network within the organization and meet the requirements for system-wide auditing and role-based access enforcement. The Identity Engines Ignition Server enforces and audits such policies while leveraging your existing investment in network hardware.
Search the Library                  Advanced Search
About Us Contact Us List Your Papers Partner With Us Site Map