Ten Reasons your RADIUS Server Needs a Refresh:

Transcription

1 : Ensuring authentication, authorization, and audit across your network 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. The emergence of wired and wireless 802.1X network authentication, combined with NAC, has outstripped the capabilities of the current -generation RADIUS servers. The emergence of wired and wireless 802.1X network authentication, combined with NAC, has outstripped the capabilities of the current-generation RADIUS servers. Fortunately, Identity Engines has built the future of RADIUS servers in its next-generation, hardened RADIUS appliance, the Ignition Server. 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. i d e n g i n e s. c o m Page 1

2 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. Page 2

3 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 12 th 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. Page 3

4 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. 2. Networks are heterogeneous; your RADIUS server should be too. Chances are your remote access VPN gateways, firewalls, Ethernet switches, and WLAN APs are not from the same vendor. Even if they are, each type of device speaks RADIUS in a different way; they ask different questions and expect different responses. For example, in an authorization-enabled network, a VPN gateway might want to know what IPsec profile to apply to a user, an Ethernet switch might need a VLAN identifier to segment traffic, a WLAN AP might need key information about the endpoint, and a firewall might want an access control list. RADIUS allows these different conversations through a flexible mechanism known as RADIUS attributes and RADIUS vendor-specific attributes (VSAs). Most RADIUS servers support some limited attribute and VSA functionality, but, since these RADIUS servers focus primarily on authentication, this functionality is neither easy to use nor robust. For example, one RADIUS server s VSA handling requires importing VSA definitions from an external database manually. Page 4

5 Ignition Server was built to perform authorization for all types of network gear and includes robust attribute and VSA handling. A built-in vendor library provides attribute definitions for all the popular vendors and equipment. This means the Ignition Server is multi-lingual; it speaks the Cisco VPN 3000 concentrator s language, and at the same time it speaks the Juniper firewall s dialect. New vendors, products, and VSAs can be added easily, and you can create templates that aggregate several commonly used attributes into a single object for use throughout the system, for both inbound and outbound RADIUS communication. Identity Engines does not tie your IT operation into proprietary solutions for a specific network infrastructure. As standards evolve and network enforcement players come and go, Identity Engines will be ready with standards-based support for all the popular gear and deployments. Ignition s policy authoring framework, based on the dominant XACML industry standard, is likewise engineered to accommodate changes in the years to come. 3. Not everyone has just one user directory. For many organizations, the promise of a central user directory is quite compelling: having a single source from which to retrieve all the attributes and groups of your user community promises manageability, consistency, and auditability. In reality though, whether through mergers and acquisitions, business division politics, or the natural evolution of most IT departments, many mid-size and nearly all larger organizations will end up supporting more than one directory. Multiple directories create a unique set of challenges. How do you integrate your RADIUS infrastructure with your directories? How do you know where to find a given set of users when they try to authenticate to the network? Do the users need to specify the directory via RADIUS realms? What happens when your wireless users are in Microsoft s Active Directory but you have a legacy VPN infrastructure authenticating against LDAP? Addressing those questions often leads the IT team to consider two options for its RADIUS deployment. The first option is to sacrifice functionality, with the result that some users will wind up unable to use some services, or some systems will suffer reduced security to accommodate the lack of flexibility. The second option is to deploy and manage multiple RADIUS servers. For example, the organization might deploy one RADIUS server for the VPN and another for the WLAN. Both options leave much to be desired. What s needed, instead, is a common RADIUS infrastructure that provides authentication for the organization s many network-edge devices switches, APs, VLANs, and so on and connects to the organization s many directories to perform the user lookup and credential checking. Ignition Server supports this with its powerful identity routing feature. Identity routing allows organizations to deploy a single RADIUS service and integrate it with any number and type of user directories. Network administrators can write sophisticated rules that route the user lookup to a directory based on the user s domain, location, access method, credential type or any other parameter. Ignition Server acts as an arbitration point between, on the one hand, all your network devices that require users to authenticate and, on the other hand, all your user directories that ultimately verify users credentials. You can even set up Ignition Server to use portions of more than one directory in the same authentication request. For example, you might want to authenticate critical users with a hardware token. Using an ordinary RADIUS server, all the information about the user would need to be stored in the same place the token is validated. By contrast, Ignition Server can validate the token password against the token server but still use your LDAP directory for all the group and attribute information about the user. This avoids costly data synchronization between the two directories or worse sacrificing RADIUS functionality because the data requested isn t available. Page 5

6 Today s AAA Access Situation Identity Engines Ignition Solution 4. You re deploying virtualization to consolidate mission-critical services. So why are you still maintaining multiple RADIUS servers? Besides the aforementioned one-radius-server-per-directory limitation imposed by incumbent RADIUS servers, there are a number of other limitations that force organizations to deploy more RADIUS servers than they ought to. A lack of RADIUS-server flexibility is the most common cause. This happens when the RADIUS server lacks the flexibility to serve multiple types of switch gear simultaneously, forcing the IT team to install many RADIUS servers, each in a dedicated, single-purpose deployment. For example, using most existing RADIUS servers, if you get RADIUS authentication working fine for your VPN, adding WLAN support on the same RADIUS server can be a painful process. Unlike traditional RADIUS servers, the Ignition Server is designed to accommodate disparate types of switchgear in a single installation. Ignition Server supports over 200 virtual RADIUS servers within a single, highly-available appliance form factor. Each virtual instance supports its own credential types, policy rules, and identity routing. Many Identity Engines customers consolidate their RADIUS deployments to achieve an immediate savings in manpower that paves the way for a robust, rolebased access control deployment. With Ignition Server, you can achieve the original goal of a RADIUS deployment having a single, authoritative authentication and authorization broker while also gaining the deployment flexibility that today s heterogeneous networks demand. 5. You treat your DNS, DHCP, and routing protocols like critical infrastructure. It s time you added RADIUS to that list. There are plenty of services on your network that are essential. The minute one of these services fails, your network functionality is compromised. In an authenticated network, RADIUS is one of these essential services. If your RADIUS server is down, incoming users can t log on, and users with current sessions can t re-authenticate. So why is your RADIUS server treated like a second-class citizen in terms of reliability and availability? Ignition Server provides an appliance form factor built from the ground up for high availability. To ensure your RADIUS deployment remains running around the clock, simply link two Ignition Servers using the dedicated HA interface, and your network access policies and RADIUS configuration are immediately synchronized. Page 6

7 6. Groups haven t been consistently named since, well, the invention of groups. One of the challenges in dealing with multiple user directories in an organization is inconsistency in group naming. This is problematic for RADIUS deployments because it means Engineering-Group isn t always Engineering-Group. Consider a policy that says: All engineers in the entire organization have access to the test lab wireless network. Page 7

8 The policy looks pretty straightforward. But what happens if you have multiple directories? One directory groups its engineers in the Development Group while another groups its engineers in the Engineering-Group. You d have to write two rules to enforce that simple policy. Add another directory, and now three rules are required. Then, when you finally get around to consolidating the groups and directories, you have to edit your rules to use the new group-naming scheme. With Ignition Server, all the groups and attributes in your policy are mapped to a common naming scheme controlled by the Ignition Server administrators. This feature, called a virtual group, lets you create one Engineering group you can use to represent dozens of groups across dozens of directories. This feature also lets you aggregate groups under a common name. For example, if there are seven external projects that include contractors, the directory may group contractor s user accounts by project name, but not under a single contractor group. Using Ignition Server, if a contractor group is needed to support a policy, it can be easily created as a virtual group. The virtual group can be set up to reference all seven groups in the directory and all without the involvement of the applications teams or directory teams in your organization. Page 8

9 7. Your RADIUS server is security sensitive. Treat it that way. By far the most common method of deploying a RADIUS server is to install it on a general purpose PC. This is the same approach that was common in the mid-1990s for deploying firewalls. Today nearly everyone deploys appliance-based firewalls, instead, simplifying ongoing maintenance and security for the device. The same problems that afflicted PC-based firewall deployments now afflict PC-based RADIUS deployments. Deploying RADIUS on an insecure operating system means you need to secure the operating system and maintain it while also maintaining the RADIUS server software. That s two sets of logs to look at, two sets of patches to watch out for, and lots more exposure to possible attacks. Hardening a general purpose OS is getting easier, but it is still a laborintensive process. Ignition Server is built from the ground up as an appliance. It uses a stripped-down and hardened BSD kernel with an encrypted file system to keep sensitive user data and policies safe. The tamperevident physical hardware alerts you to possible intrusions. There s only one set of firmware to maintain and the system is locked-down by default. Logs can be viewed locally or exported in CSV format or via syslog for importing into the security information management (SIM) tool of your choice. 8. Authenticating employees against LDAP is fine, but what about your guests? RADIUS was built to check passwords for dial-in users, but today there is a huge variety in types of users. The type that is growing most significantly is temporary users. Temporary users come in many forms: vendors, contractors, trainees, customers, partners, and more. A common thread among temporary users is their need for some form of network access, but only for a specified period of time. Using traditional RADIUS solutions, supporting temporary users is a daunting task. Yes, someone with administrative access to the RADIUS server can create local users, but that makes IT the bottleneck every time a visitor needs a few hours access to the Internet. Identity Engines Ignition Guest Manager (IGM) relieves this bottleneck. Built as an extensible J2EE web application, IGM communicates with the Ignition Server and provides a simple web interface built for the task of maintaining guest accounts. Guests may be restricted to specific zones of the network and to specific time periods, and they may be required to connect via specific access methods. All of this is accomplished with a delegated administration model that allows staff such as front desk receptionists to create accounts. IT sets the rules that determine what sort of guests may be created and what parts of the network they can use, and the organization takes it from there. IGM also provides a full audit trail of who created the user, and when and where the user connected. 9. It s not user or device; it s user and device. Increasingly, organizations are tasked with authenticating devices as well as users. Existing RADIUS offerings can handle this, but without much grace. Many allow you to authenticate a machine based on its MAC address as a way to bypass user authentication, but just checking that an address is on a list represents a huge sacrifice in functionality compared with the precise rules you can write in a user policy. The most common requirement that cannot be met using existing RADIUS servers is an assigned-device policy. This sort of policy allows the user to connect only if he or she has successfully authenticated and is using a company-provided laptop or other device. Page 9

10 Using the Ignition Server, it s easy to set up device access policies and assigned-device policies. The access rules you write can evaluate attributes of the device and/or the user. This is a huge leap beyond what s offered by legacy systems that can only ask, Is the device registered? In contrast, the Ignition Server lets you write policies that state which assets can connect to which parts of your network and, optionally, which users may connect using which devices. If, for example, you have stock traders working with sensitive information, you might want to require your secure trading network to accept connections only from traders using secured PCs that have been configured for trading. Ignition Server also makes it easy to merge the policies of users and devices to ensure that only specific types of users can use specific assets at specific times of the day and from prescribed network locations. The policy might be: Point-of-sale terminals can only be connected to the secure retail sales network and only when operated by sales personnel between the hours of 10AM and 9PM. At all other times no one is allowed on the retail sales network. Ignition Server accommodates such business policies, reducing the risk of unauthorized individuals accessing the network. Page 10

11 10. RADIUS is just the beginning. When RADIUS was in its nascent stages, a typical deployment included a RADIUS server with a built-in database and a network access server that offered the modem connections. Those two entities were the entire solution. Today s networks are more functional and secure. They are also more complex. That s why RADIUS offerings that do not integrate with the other components of your network are very hard to manage. Beyond supporting new and complex configurations, your RADIUS infrastructure should be ready to support the 802.1X network authentication standard. The 802.1X standard has emerged as the key enabling technology for authenticated networks. The standard is tightly integrated with RADIUS and widely supported by today s network gear. However, 802.1X requires a client supplicant (the application that prompts the user for his or her credentials) and the negotiation of potentially complicated security parameters. This gets even more complicated if you try to communicate device health information over the same channel. Solving this problem requires more power than simple RADIUS server deployments can supply. Identity Engines lets you deploy 802.1X on today s complex networks. The integrated Ignition product suite simplifies deployment of a next generation, identity-enabled network: Ignition Guest Manager lets you authenticate and audit guest network sessions with the same level of security you apply to your other user accounts, and it lets front-desk staff safely manage these accounts. Ignition AutoConnect lets your end-users quickly configure their laptops and other devices to connect to the 802.1X-secured network, while minimizing calls to your support desk. Ignition Portal gives your non-802.1x capable devices a way to authenticate and connect using the same policies your 802.1X-enabled community uses. Ignition Posture Module is a NAP- and TNC-compatible agent that checks the health of connecting devices. It integrates tightly with the industry s most widely supported, open source 802.1X supplicant, the Open1X Xsupplicant. Ignition Reports gives you historical, audit-grade reporting of every network access event. Page 11

12 Why does your RADIUS deployment need a refresh? 1. You don t have an AAA server, you have an AA server. Legacy RADIUS servers lack the flexibility to provide rolebased authorization and system-wide reporting required by regulations and audit directives. 2. Networks are heterogeneous; your RADIUS server should be too. Devices across your heterogeneous network all communicate with RADIUS, but each in its own way, complicating systemwide authentication and authorization. 3. Not everyone has just one user directory. Existing RADIUS servers can t handle multiple directories. Ignition s identity routing feature searches multiple directories to find the user entry. Ignition then authenticates the user and, if needed, retrieves his user attributes and checks his group memberships. Authentication and attribute/group lookup may be split to allow, for example, SecurID token authentication with LDAP attribute lookup. 4. You re deploying virtualization to consolidate mission-critical services. So why are you still maintaining multiple RADIUS servers? Legacy RADIUS servers are often one-trick ponies, requiring a unique installation of the RADIUS server to support each type of authentication. (For example, one RADIUS server to support VPN, one for WLAN, and so on.) Ignition s support for most manufacturers RADIUS attributes as well as support for vendor-specific attributes (VSAs) means that a single Ignition installation supports all your means of network access. 5. You treat your DNS, DHCP, and routing protocols like critical infrastructure. It s time you added RADIUS to that list. When your RADIUS server is down, connecting users can t log on and currently connected users can t re-authenticate. Ignition s high availability mode ensures your RADIUS service is up and running, 24 x Groups haven t been consistently named since, well, the invention of groups. Multiple user directories usually mean multiple group names, resulting in a proliferation of access rules. Ignition s virtual groups let you iron out the differences in group names across directories, and its virtual attributes let you iron out differences in user attribute names. 7. Your RADIUS server is security sensitive. Treat it that way. Legacy RADIUS servers are hard to secure. By contrast, Ignition Server was built from the ground up as a secure appliance. 8. Authenticating employees against LDAP is fine, but what about your guests? Temporary workers require access to your network but represent a huge risk if they aren t properly authenticated and authorized. Ignition Guest Manager lets you authenticate guests with the same level of security you apply other users, and it lets front-desk staff safely manage these accounts. 9. It s not user or device; it s user and device. True security means evaluating both the user and the device to make the access decision a capability legacy RADIUS servers lack. Ignition authenticates both users and devices and, based on your policies, can evaluate attributes of the user and the device to make the access decision. 10. RADIUS is just the beginning. RADIUS is the foundation of network authentication, authorization, and accounting today, but traditional RADIUS servers lack the flexibility and power required to deploy 802.1X security in complex settings. Ignition has the flexibility to bring 802.1X security to your existing network infrastructure using your existing hardware without imposing additional overhead. For more information about Identity Engines products and solutions, call (outside the U.S.A., use ) or visit our website at About Identity Engines Identity Engines develops scalable, identity-centric solutions for securing enterprise networks. The company s solutions provide comprehensive identity services such as authentication, authorization, and auditing to distributed network devices while enabling centralized administration and policy management for improved access control and compliance. 6/07 Copyright 2007 Identity Engines, Inc. All Rights Reserved. Page 12