Port-Based Authentication

Transcription

1 Port-Based Authentication WHITE PAPER CSS is introducing its port-based authentication offering in order to take advantage of underutilized, highly effective features of Microsoft Windows and Active Directory. These features enable an enterprise to block all unauthorized IP access, both from inside the firewall and out, on a connection-by-connection basis. This white paper discusses securing network infrastructure using the RADIUS protocol (IAS), Active Directory, Certificate Services, 802.1X (wireless and wired), Extensible Authentication Protocol (EAP) and VPN.

2 2 Table of Contents Introduction...1 History...4 IP Threats to a LAN...5 Solution Overview...6 Solution Components...6 Written Acceptable Use Policies...7 Requiring Authentication for Any IP Based Connection...8 Identity Based Segmentation...9 Technical Details...10 Protocols...10 RADIUS X...11 EAP...13 Components...15 Clients...15 Wireless Access Points...16 Switches...17 VPN...18 IAS Server...18 Directory Server...19 Certificate Authority...19 Remote Access Policy Processing...19

3 3 Identity Based Segmentation...23 VLAN ID Reuse...24 Multiple Group Membership...27 Glossary...29

4 4 Introduction History The nature of early networking protocol and technology development has left today s computing environment with many challenges. Early networks had very few nodes and often had limited interconnection to other networks. Considering the cost and rarity of computers, it was assumed that all nodes were trusted. Early protocols assumed this type of environment was secure and often had little or no obfuscation of usernames, passwords or other data. Unfortunately many of those protocols are still used today. In a world of inexpensive laptops, widespread network access and increasingly savvy users, it can no longer be assumed that data crossing a network is confidential or will reach its destination unaltered. As the number of threats and level of threat awareness has increased, a great deal of focus has been placed on blocking access to networks from the outside, via firewalls and VPN. This focus has left the state of LAN connections and security almost completely forgotten. Networking hardware manufacturers and standards organizations have worked to address LAN security issues, but many organizations still believe that having a good firewall means their IP infrastructure is protected. Often the only LAN security that is used is router ACLs which merely limit exposure based on a physical port location with no regard to what or who is connected. IPSec is being used occasionally, but it is complex, can put a significant load on processors, and may not work well in a heterogeneous environment. IPSec design, implementation and upkeep can be very costly. It can be difficult to make a business case for requiring IPSec for all LAN traffic. Even if most LAN traffic is encrypted and router ACLs are used, a fair amount of data can be gathered from an open port. The value of the data may be minimized, but not entirely removed. Most of today s security technologies assume a user or device has unrestricted access to the network medium. Authentication and authorization take place across the medium with no consideration ever being taken to whether the user or device should have ever been allowed access to IP network. This universally granted access allows the user to take part in the realm or domain security model, or to attempt to circumnavigate or disrupt it, with complete anonymity. While server authentication and authorization mechanisms are effective, allowing any network access to an unknown party is an unneeded risk. Imagine if a bank were to not bother locking its doors at night because the vault and safety deposit boxes all have locks on them. The vault may be strong, but is there any reason to

5 5 allow a thief overnight access to analyze it? Would it be prudent to remove an organization s firewalls because server ACLs are in place? Many organizations have had policies banning certain types of devices or network access, but have lacked the technical controls to enforce the policy or audit and provide appropriate behavior modification. Faced with an onslaught of usernames and passwords, users tend to reuse passwords or write them down on sticky notes. This often weakens a system that implements protocols to provide otherwise secure authentication. It is therefore in the best interest of security to tie any new access-control systems to an existing directory service. Tying all network access to a principal s existing Active Directory (AD) credentials allows administrators to implement stronger proactive security measures without the burden of maintaining an additional user directory and the problems that go along with adding yet another set of credentials. IP Threats to a LAN On a LAN there are many possible threats. In the past, LAN access and security were often thought of only in terms of identity management and ACLs. Hackers were assumed to be stopped at the firewall and only internal users with valid IDs were able to create mischief. In recent times we ve seen that many threats on the LAN are independent of identity. Worms such as Code Red and MSBlast exploited weakness in IP stacks and had no tie to identity; the only requisite for them to wreak their havoc was IP access. Often the threats come from visitors such as consultants, contractors and vendors. An environment that has strong change control and configuration processes can still be negatively affected by these unmanaged hosts. This can come in the form of a virus infected machine looking for other hosts to infect as well as nosey or curious guests. These threats occur completely outside the realm of a standard domain or realm s server security model. Another threat to a LAN comes from employees installing unauthorized workstations and network gear. Unpatched machines with no anti-virus and rogue access points are often found on networks despite what written policy dictates. Clearly it is in a company s best interest to block any unauthorized access to its IP infrastructure, whether it originates on a LAN, WAN, wireless or from the internet. The most efficient way to achieve this is by enforcing polices with technical controls on an automatic port-by-port basis. Managing ports manually is too time consuming and ultimately gets lost in day to day business. Designing a

6 6 system that has little or no long-term administrative overhead is key to having the system work in the real world. Solution Overview Port based authentication is the process of blocking traffic through network ports until the identity of the principal requesting access has been established. Whether it is a physical port such as an RJ-45 connection on a switch or a logical port such as an or VPN port, each individual port can be authenticated. Using IAS (Internet Authorization Service), Microsoft s implementation of RADIUS (Remote Authentication Dial-In User Service), we can tie a principal s Active Directory credentials to the principal s ability to connect to the LAN, VPN, wireless, or dial-in. IAS gives us the capability to grant or deny access to network ports based on defined rule sets known as Remote Access Policy. Internet Authorization Service ships with all Microsoft Server platforms, as do the client pieces for authenticating wired, wireless, dial-in and VPN connections on Windows 2000 XP and 2003 Server. Many existing switches, wireless access points and VPN solutions already support port-based authentication. These factors make port-based authentication a low-cost, high-value proposition. Solution Components Understanding the components involved is key to understanding how port-based authentication works. Some of the components have different names depending on context. Figure 1 Port Based Authentication Components

7 7 Written Acceptable Use Policies While the hardware and software components in a system may seem compelling or interesting to administrators, the driving force behind adoption should be the business case. Port-based authentication can be used to technically enforce a documented set of policies. This will help guide designers and administrators in understanding the business needs of those who use the network systems. An Acceptable Use Policy (AUP) is not likely to have a great deal of technical depth, but it can provide a base to build upon. Losing sight of the business case, which is stronger security at a minimal cost, is likely to cause disruptions. Client The client machine is often referred to as the supplicant or supplicant port access entity (PAE). The client device requests access to the network, either in the security context of the AD machine account or the user account. The client may access the network via a wireless network interface card (NIC), wired NIC, VPN adapter or modem. Depending on the access type, the client may require third party software to create the connection. This may be third party VPN software or 802.1X supplicant software. Windows 2000 and XP systems come with native VPN and 802.1X capabilities X is the IEEE standard that allows for portbased authentication for switches and Wireless APs. Network Access Server A network access server (NAS) is a device that allows the client to access the network. It is often referred to as the authenticator PAE or RADIUS client. The NAS can be a switch, access point, VPN concentrator, dial-in device, etc. The RADIUS client has no say in granting or denying access to the network, it merely passes authentication data to the authentication server and enforces the access decision returned to it. The access decision may be as simple as allow all access or it may include restrictions such as date and time, inactivity timeout, IP filtering restrictions, bandwidth restrictions, etc. Authentication Server The authentication server, also know as a RADIUS server or IAS server, determines which clients are granted access to the network. The remote access policy is housed by the IAS server. The IAS server checks AD to validate the identity of the principal, then parses remote-access policy to determine whether or not the connection should be authorized. Once this determination is made, it sends a message to the NAS rejecting or accepting the connection request. Directory Server

8 8 The directory server can be any Active Directory Global Catalog server. The selection of which GC server to use is determined automatically. By default it is the nearest GC server. A directory server is always checked to verify the identity of the user or computer requesting access, as well as to verify that the account is active and that the account is a member of any necessary groups. Often the Authentication server and Directory server will reside on the same box in order to limit the amount of authentication traffic crossing the network. Certificate Authority The certificate authority is used to issue and validate server, computer and user certificates. Depending on the scope of the installation, the use of certificates can be minimized or eliminated. If IAS is being used to authenticate wireless connections, it is required that the IAS server have a certificate in order to protect the authentication process. The IAS server s certificate can also be used to validate the server, allowing for mutual authentication, which is highly recommended in a wireless environment. Remote Access Policy Remote access policy allows for granular, rules-based control over the authorization process. Once identity is established via Active Directory and/or PKI, remote-access policy is applied to determine whether the connection should be authorized. A NAS (Network Access Server) is a device such as a VPN concentrator, switch, etc, that can be used to allow network access. The remote-access policy can take into account NAS MAC address, connecting device MAC address, Time/Day, Group membership, Media type and more. If all policy conditions are met, then the appropriate policy will be applied. The policy can be as simple as granting access to the port or it can return configuration values to assign the connection to a specific VLAN, IP filter set, throttled connection speed, etc. Requiring Authentication for Any IP Based Connection Using a single unified remote-access policy,an enterprise can manage all access to its IP infrastructure (Figure 2). This can allow for conditional access by type, such as VPN, dial-in, wireless or wired. It can allow for connections based on location, such as wireless APs only on certain floors, assuming there has been proper documentation of NAS locations. Building-perimeter AP s can be locked down during non-business hours to further limit parking-lot sniffers. VPN access can be granted only when a valid certificate is used. The flexibility of remoteaccess policy allows for a high degree of control over how IP is accessed.

9 9 Figure 2 Controlling all IP access via a single Remote-Access Policy Even if an enterprise is unable to integrate all of its IP access with remote-access policy, it can still benefit from controlling specific types of access. While most third-party VPN concentrator vendors support RADIUS authentication, some of their advanced features may not be supported when using RADIUS. Each piece of hardware has to be reviewed on a case-by-case basis. Identity Based Segmentation Very restrictive router ACLs have always looked good on paper but have proved unrealistic in an ever-changing real-world environment. With proper design, identity-based segmentation can greatly restrict IP access with no long term overhead. In an environment that is rapidly changing, it is likely to save a tremendous amount of time in re-design and re-configuration. Using dynamic VLAN assignment, the possibility arises to begin segmenting a network not based on the physical location of a principal, but based on its identity. In the past, router ACLs had to be calculated based on who was likely to use an area or might have been used to block access for a legitimate purpose. In addition, if groups moved areas in a facility, the ACLs had to be adjusted or the VLANs moved to different ports or switches. In the end, it is often most expedient to have minimal router ACLs. Now that a principal s identity can determine which VLAN it is connected to, there is the opportunity to implement extremely tight ACLs.

10 10 In the past a principal s identity has been used mainly by server administrators to determine access to files, shares, web resources and the like. Now IP infrastructure designers and implementers can further reduce exposure to IP related incidents. One of the best examples of the use of this solution is in conference rooms. Even if a network has fairly tight ACLs, a conference room provides two challenges. First, it s the most likely place to find guests, so access should be tightly limited. Second, there can be a wide range of legitimate users booking the conference room, thus access needs to be fairly broad. These two goals are mutually exclusive. This illustrates why router ACLs are often unutilized or under utilized. With the ability to dynamically assign each port to a different VLAN, a salesman, an engineer and a guest can work in a single room with IP access to only the resources that are deemed necessary for each user. Another benefit of identity-based segmentation is reduced complexity during moves. Tight ACLs are often avoided due to frequent user moves. There is too much room for human error as well as too much time spent to continually reconfigure switches for moves. Once an identity-based segmentation model has been implemented, moves have no effect on router ACLs or individual port configurations. Technical Details Protocols RADIUS Remote Authentication Dial-In User Service is an Authentication, Authorization and Accounting (AAA) protocol used by network access devices. It creates a framework for allowing or blocking access to network assets as well as shaping the connection and tracking its usage. When a connection is requested to or through a Network Access Server (NAS) the NAS formats the request and passes it to the RADIUS server. The NAS is also known as the RADIUS client. The RADIUS protocol contains a large list of standard RADIUS attributes. These attributes are passed between the client and server to set up, tear down and monitor the connections that are granted to the NAS. The attributes can come from the client describing the nature of the NAS or the peer requesting the connection, such as the NAS type, NAS IP address, calling station Address, type of connection requested etc. These attributes may also be passed to the NAS to specify connection parameters such as idle timeout, maximum session length, IP filters, etc. The RADIUS protocol is extensible, allowing for custom attributes to

11 11 be created by vendors to support additional features on their NASs. These Vendor-Specific Attributes (VSA) are easily entered into IAS. Not every standard RADIUS attribute is supported by every NAS, so it is important to review the NAS documentation before assuming that an attribute that is being passed will be applied or processed. A NAS will generally ignore any attributes that it doesn t understand. The RADIUS client and RADIUS server communicate using a pre-defined shared secret key. The RADIUS protocol, like most shared secret protocols, is subject to offline attacks. It is a best practice to use long randomly generated keys, 16 or more characters. Each RADIUS client is configured separately in the server, so each should have a different key. In addition, whenever possible the RADIUS traffic should be protected by IPSec ESP or other encryption X RADIUS authentication has been around for many years and is generally understood in the realm of VPN and dial-in access X was created to expand the RADIUS-like controls to the switch level. While 802.1X development has been driven by the need for wireless security, it is a misconception that 802.1X is a wireless protocol X is a protocol that is defined inside layers 1 and 2 of the OSI model. It works on wired connections as well as wireless. While the solutions herein document the use of RADIUS, 802.1X does not require RADIUS. Standalone 802.1X devices are rare and, without a centralized directory to authenticate against, are of limited value in the enterprise X initially places all ports in an unauthorized state. In its unauthorized state the only traffic that the port will accept is EAPOL (Extensible Authentication Protocol Over LAN). This is authentication traffic. The only authentication protocol supported in 802.1X is EAP. There are two separate conversations that take place during authentication. The first part of the conversation is between the supplicant and the authenticator. This conversation takes place at layer 2; therefore no IP addressing is involved. The second part of the conversation is between the authenticator and the authentication server. This conversation is RADIUS traffic which maps to layer 5. The RADIUS protocol uses UDP datagrams. The RADIUS exchange is protected by a shared secret key. The RADIUS client (authenticator) and the RADIUS server must be configured with each other s IP addresses and have the same key in order for authentication to be processed. These are import security designs. The authenticator creates a logical connection from the supplicant to the authentication server to complete the authentication process, but the supplicant has no control over where the authenticator (NAS) sends the authentication data.

12 12 This is determined by the setup of the NAS. This negates the possibility of the supplicant creating a tunnel to some other location. While 802.1X data is passed by the RADIUS protocol, there are different terminologies for the same devices. This can be confusing when describing the overall connection process. See Figure 1 and Table 1 for a comparison of the terms. Table 1 Terminology Cross Reference Device 802.1X and EAP RADIUS Supplicant PAE Authenticator PAE User Peer RADIUS Client NAS Authentication Server RADIUS server Figure 3 illustrates a successful 802.1X authentication. All of the EAP traffic on the left half corresponds with the RADIUS traffic on the right. We see that the layer 2 EAP Response/Identity is packaged by the authenticator into a layer 5 RADIUS-Access-Request and sent to the authentication server (IAS). Then we see the RADIUS-Access-Challenge is returned to the authenticator where it is changed to an EAP-Request-Challenge and sent to the supplicant. The conversions done by the authenticator make the connection between the supplicant and authentication server logical. There is no open port to the authentication server. A better description would be that there is a RADIUS tunnel to the authentication server. The port remains in the locked (unauthorized) state until the Authenticator receives the RADIUS-Access-Accept. At that point the port is authorized and all traffic is allowed to pass.

13 13 Figure X Authentication Process If the authentication server had returned a RADIUS-Access-Reject, the port would have remained in the unauthorized state and been prepared for the next authentication attempt. The authenticator doesn t need to know the specifics of the EAP traffic that it is passing, such as the authentication type being used, etc. The authenticator just needs to properly format and forward the EAP traffic to the authentication server. The responsibility of interpreting the EAP traffic and making decisions on whether to grant access lies with the authentication server and the directory server. EAP Extensible Authentication Protocol was originally designed to extend authentication methods for PPP connections such as dial-up, but has since been adapted to frame-based connections as well. EAP provides a framework for passing additional types of authentication through a NAS to the RADIUS server without the NAS having to support each individual type of authentication. With the addition of two RADIUS attributes, EAP-Message and Message- Authenticator, the NAS and RADIUS servers are able to pass authorization data. There is no standardized framework defined for how a RADIUS server passes and processes the authorization data to the directory server and/or certificate authority. This is left up to the RADIUS implementer. Microsoft integrates the IAS with Active Directory in order to achieve this.

14 14 IAS currently supports three EAP types, EAP-MD5, EAP-TLS and PEAP. The first type, EAP-MD5 is not supported in a wireless environment because it uses a challenge/response mechanism based on an MD5 hash of the principal s password. This exchange is subject to offline attack. If the password were short or found on a word list, it would be easily compromised. EAP-TLS uses certificates to identify the user. This is the strongest form of authentication. Protected EAP (PEAP) uses a TLS tunnel based on the IAS server s certificate to protect authentication either using MS-CHAP v2 or EAP-TLS. Other EAP types exist that are not supported natively by IAS. EAP-TTLS uses a TLS tunnel to pass a variety of supported credentials. While PEAP using TLS seems similar to EAP-TTLS, they are not the same. Tunneled Transport Layer Security (EAP-TTLS) is a proprietary protocol which was developed by Funk Software and Certicom, and is supported by Agere Systems, Proxim, and Avaya. EAP-TTLS is not natively supported by Windows client OSs. LEAP (Lightweight Extensible Authentication Protocol) is a proprietary protocol which was developed by Cisco and has very little third party support. LEAP should be avoided wherever possible as it is fundamentally flawed and can expose the principal s credentials during the authentication process. Cisco has given an endof-life notice on LEAP and is moving to use PEAP. EAP-FAST (Flexible Authentication via Secure Tunneling) was created as a stop gap solution while transitioning from the flawed LEAP to PEAP. FAST is yet another protocol that uses a secure tunnel to pass credentials. With FAST, the credentials are username/password. The tunnel can be created using a pre-shared key or using a Diffie-Hellman key agreement. Table 2 Comparison of IAS Supported EAP types Feature EAP-MD5 PEAP EAP-TLS Mutual Authentication No Yes Yes Rotating keys for Wireless (Rekeying) Generated during Not allowed for wireless authentication Generated during authentication Security technology level Strong password-based authentication Strongest passwordbased authentication Strongest authentication User credential Hash sent in clear (subject to dictionary Protected by Transport Layer Security (TLS) Certificate-based

15 15 protection and brute-force attacks) tunnel authentication Ease of implementation Widely supported and offered natively in Windows clients. Not supported for wireless. Widely supported and offered natively in Windows clients (2000 and XP). Requires a Public Key Infrastructure (PKI). Widely supported and offered natively in Windows clients (2000 and XP). Credentials flexibility Username/password only Any approved EAP in TLS tunnel, including EAP - MSCHAPv2 based passwords Only digital certificates Components Clients The type of device connecting to the IP infrastructure can greatly influence design. Clients may be servers, workstations, or IP devices such as printers or cameras. The device s available authentication type may depend on OS, drivers or firmware. The type of connection is also important. VPN authentication options are highly dependent on the VPN solution being used. Microsoft s Routing and Remote Access (RRAS) supports all of IAS s authentication types. Many third-party VPN solutions and dial-in solutions may only support MS-CHAP v2 or weaker. The level of risk must be evaluated for weaker auth types. Dial-in connections, for instance, are a point-to-point connection. If the dial-in NAS is managed internally, passing credentials in the clear is not likely to be a risk. On the other hand, if the NAS is outsourced, it may be necessary to evaluate how the outsourcer handles and logs connection information. When using 802.1X with switches, some devices such as networked printers may not have supplicant software. If this is the case, the ports for these types of devices will need to be configured with 802.1X turned off and tightly limited ACLs applied. It is also advised not to use DHCP on these VLANs. By turning off DHCP, the usefulness of the port is limited to the average user. In addition, use of static IP addresses will allow for tighter ACLs. Windows 2000 and XP natively support 802.1X authentication, PPTP and L2TP. If 802.1X is used by Windows 2000 or XP for wireless connections, the

16 16 supplicant will not allow a connection to be created that does not include encryption. The supported encryption types vary widely by equipment vendor. Windows 2000 and XP also support two different connection security contexts. When the computer first boots, it will attempt to authenticate in the context of the machine account. If the machine account has not been added to an appropriate Windows group, one that matches a remote access policy, then the computer will not be granted access to the IP network. This means that machine group policy will not be refreshed and the machine will not be available to be managed by systems such as SMS. If the machine account is granted access by remote access policy then it will be granted access and available for remote management, etc. When a user logs onto the machine, the context of the connection is switched to the user s security context. The user s context may cause the connection to be closed, reopened in the user s context or assigned to a different VLAN. Wireless Access Points In the realm of wireless access, authentication is not the only concern. The confidentiality of the data also becomes of concern. While many APs support 802.1X authentication only, this is not an acceptable level of security unless the radio frequency (RF) environment is adequate to contain all data being transmitted wirelessly and local users can all be trusted not to eavesdrop on each other s data as it crosses the airwaves. This is highly unlikely. RADIUS has additional attributes that can pass dynamic keys to APs after access has been granted. It is vital that these techniques be used. By using dynamic keying, the possibility of a properly authenticated session being hijacked is eliminated. Hijacking an unencrypted session is a fairly simple process, but by also requiring the correct key, it is nearly impossible. Until recently, most APs that used 802.1X did not support dynamic VLAN assignment, but recently many vendors have begun selling APs with this option. These APs are often referred to as wireless switches. Wireless switches are vital for creating a guest-friendly wireless network that is still highly secure. Access point selection is the most critical decision that is made during a wireless rollout. While all current and proposed enterprise authentication mechanisms are based on 802.1X, not all APs and wireless clients support the plethora of encryption types and key distribution methods. It is important to select the strongest possible security that will work in a given environment. Currently Wireless Protected Access (WPA) using Advanced Encryption Standard (AES) is the most secure widely used standard, however few currently installed APs support it and even fewer installed wireless client adapters support WPA-AES. WPA-TKIP is much more widely supported in APs and is supported natively in

17 17 Windows XP. However, Windows 2000 requires a third-party client or driver to support WPA-TKIP. WPA2 and 802.1i compatible security protocol is poised to take off, but in the ever changing technology world, is not likely to last forever. An AP that supports WPA, and whose firmware can be flashed to support upcoming changes, is a good long-term choice. The scores of other important factors that shape buying decisions for a wireless deployment are outside the scope of this document. Switches Nearly all of the managed switches sold today, as well as those sold recently, support 802.1X authentication. Some older gear may require firmware upgrades to support 802.1X. When planning for the use of 802.1X compliant switches, there are a few key factors to take into account. First is whether or not the environment can or will support dynamic VLAN assignment. The second is whether the guest VLAN option is supported. Lastly, if guest VLANs are supported, in what fashion do they operate. Guest VLAN assignment is not part of the 802.1X standard, so it is handled differently by different manufacturers. Some OSs, such as Windows 2000 and XP, support a guest logon feature using the domain guest account. The Windows solution bypasses the need for the switch to support a guest VLAN by attempting to authenticate the connection as the domain guest user if initial authentication fails. This solution still requires the switch to support dynamic VLAN assignment. The guest VLAN is accomplished by simply having a remote access policy that grants access to the guest user, but on a different VLAN. This, however, doesn t address the needs of non-ms clients. Networking gear that natively supports a guest VLAN can work in one of two ways. The first type assigns the connection to a guest VLAN only if no 802.1X authentication is attempted. This is based on the assumption that the device connecting has no available supplicant software. The second type works like the MS solution, granting access to the guest VLAN if authentication fails. Some gear only supports one option, some gear supports both. It is most useful to have hardware support for clients that attempt no 802.1X authentication. This reduces the number of ports that must have 802.1X completely turned off. By operating at the Link Layer, 802.1X tightly controls access to and through wired ports. The enabled 802.1X port always starts in the unauthorized state. In the unauthorized state the port ignores all traffic except for EAP Over LAN (EAPOL). As soon as a device is connected to the port, it initiates authentication by sending an EAP-Request/Identity. If the authentication process completes successfully, the port is changed to the authorized state and all traffic is allowed to pass. If, for any reason, the physical connection is lost, the port immediately

18 18 returns to the unauthorized state. This mechanism makes it nearly impossible to hijack an authorized port. Some vendors can also support authenticating more than one MAC address per port, which allows for expansion using a hub while maintaining most of the integrity of the connection. The switch port has no mechanism to track the link state of the client s connection to the hub, so use of this type of option should be avoided in an environment that isn t considered physically secure. VPN Microsoft s RRAS is tightly integrated with IAS. RRAS can receive additional connection parameters from IAS beyond what standard RADIUS attributes would allow for. This can include required encryption type and IP filters. This allows for granular configuration of the user s connection based on remote access policy. Each third party VPN solution has a different set of standard and vendor specific RADIUS attributes that it can interpret and act on. Most third party VPN products will support EAP-TLS authentication, which is recommended for allowing VPN access. Administrative accounts should require two factor authentication such as is provided by smart cards. IAS Server Internet Authentication Service ships with the Windows 2000 and 2003 operating systems; however Windows 2003 Enterprise Edition has some advantages over the other OSs. In particular, Windows 2003 Enterprise supports unlimited RADIUS clients, whereas Windows 2003 Standard supports up to 50. Windows 2003 Enterprise supports creating RADIUS clients using a block of IP address, while Windows 2003 Standard requires that each RADIUS client be added separately. Windows 2003 also gives greater control over the specifics of EAP auth types. With Windows 2000, if auth type was selected, it was universally accepted. Windows 2003 IAS allows for remote access policy to have more granular control. Now a policy can specify the particular certificate that must be used or the Certificate Authority that must have issued the certificate. In addition, Windows 2003 IAS can parse a certificate s Enhanced Key Usage (EKU) properties to enforce the certificate s intended use. Some vendors ignore EKU information and use any certificate for which the principal has a private key. This can also be used to enforce stronger authentication methods, such as smart cards for administrative accounts, VPN, etc. IAS supports NASs that are compliant with RADIUS RFCs 2865 and 2866 and computers running MS RRAS. This standards-based support is what makes IAS a strong choice for integrating IP access with an existing directory.

19 19 Each IAS server is assigned to the RAS/IAS Server Group of its domain. This allows the IAS server to read each principal s account attributes to determine account status and group membership. If an IAS server must authenticate users from another domain, it must be placed in that domain s RAS/IAS Server group. Directory Server Microsoft s Active Directory (AD) is the framework for the required directory services. All access requests are checked against Active Directory in order to ascertain a principal s group memberships, account status and other relevant information. Due to IAS s constant communication with AD, it is recommended that IAS be run on a directory server. This will greatly reduce the amount of authentication traffic crossing the network. Certificate Authority Depending on the scope of the installation, a full Public Key Infrastructure (PKI) is not needed. Certificates are required on the IAS server for wireless connections and any connection that requires mutual authentication. For wireless connections, it is imperative that the authentication process be protected and that the client be able to verify the identity of the system to which it is authenticating. This can only be accomplished with public key technology. To best leverage PKI, it is recommended that certificate auto-enrollment be used. Windows 2000 supported auto-enrollment only for machine certificates, but Windows 2003 introduced user-certificate auto-enrollment. This, however, only works when used with Windows XP clients. Auto-enrollment allows for both certificate enrollment and certificate renewal. Requiring principals to present a certificate in order to connect to the network ensures that users don t share usernames and passwords. By default Windows 2000 and XP used cached user credentials to attempt 802.1X authentication, but the supplicant can be configured to use an alternate username and password. By default MS VPN connections ask for credentials, which could be shared. Requiring certificates and properly securing the provisioning process increases the strength of the authentication and eliminates the opportunity to share passwords. Remote Access Policy Processing Remote Access Policy is an ordered list of policies that are checked to see if a connection will be granted and, if so, determine the connection attributes to be returned to the NAS.

20 20 Figure 4 Remote Access Policy List example Each individual Remote Access Policy contains a list of Policy Conditions. When a connection request is made, it is compared to the first Remote Access Policy on the list. Only if all of the policy conditions are met is the Remote Access Policy applied to the connection. If any of the policy conditions are not met, the connection request is processed against the next Remote Access Policy. Figure 5 Policy Conditions When the connection request reaches a policy in which all the policy conditions are met, the connection is processed. Processing the connection first means