Defining User and Group Parameters for Preshared Keys
| The Quick Configuration enables you to configure minimal aspects for remote access connectivity; however, many VPN connections require additional parameters to be defined to function correctly or optimally. Most of these properties can be set by defining users and groups within the Configuration | User Management screens. Before delving into the configuration parameters, though, it is important to understand the characteristics of users and groups. The VPN 3000 Concentrator simplifies configurations by defining a base group, individual groups, and users. These three entities support a trickle-down approach for defining attributes to remote access connections. Users that are created are associated with either a particular group or the default base group. A user can belong to only one group and can inherit configuration parameters from the group in which it resides. Any user not explicitly assigned to a particular group is a member of the base group. Interestingly enough, created individual groups can also inherit attributes from the base group. It is recommended that you first define mutual parameters in the base group, which can trickle down to all individual groups and users. You should then create the individual groups and decide whether they should inherit those attributes of the base group or define unique parameters that apply to that group. Likewise is the case for users who are added to the individual groups or the base group. They, too, can define their own parameters or inherit them from the group in which they reside. Figure 4.6 illustrates this concept by portraying the base group and the individual groups as funnels. Parameters from the base group can trickle down to either individual groups or users that are assigned to the base group. Additionally, users can also inherit configuration attributes from individual groups to which they are assigned. Figure 4.6. Group and user configuration concept.
The following sections examine the configuration options for the base group because the parameters are practically identical to the individually created groups. Of course, this should be the first group you define because groups and users can inherit its attributes. To begin the base group configuration, click on the hyperlink for the Configuration | User Management | Base Group screen. At this point, you are presented with six tab divisions for base group configurations: General, IPSec, Mode/Client Config, Client Firewall, Hardware Client, and PPTP/L2TP. After you have completed the configurations for all tabs, click the Apply button to return to the Configuration | User Management Screen. Table 4.2 introduces the tabs and several of the parameters that you might encounter on each of them.
Base Group General Tab ParametersThe General tab is the initial tab displayed when you are modifying the base group attributes. Figure 4.7 exhibits the General tab for the base group configuration. The top portion of the screen is geared toward the group's access rights and privileges that should be in accordance to your company's security policy. Here you can define time restrictions and idle/connection timers that users in this group are allotted for remote access. Figure 4.7. Base group General tab.
Continuing the remote access example from the beginning of this chapter in conjunction with Figure 4.7, the administrator of the concentrator configures all users and individual groups that inherit the base group attributes to adhere to standard business hours for a login restrictions. Thus, Mr. Ed and any other user assigned to this group is required to initiate the VPN tunnel between the concentrator's hours of 9:00 a.m. and 5:00 p.m., in whichever time zone the concentrator resides. In the General tab, you also enforce login restrictions, such as password character lengths, for the VPN 3000 Concentrator's internal server. Additionally, a peculiar default concentrator option in regard to passwords is to enforce the passwords to be alphabetic. In practice, this should be unchecked to enforce strong passwords with alphanumeric characters. In the remote access example in Figure 4.7, this option has been unchecked to enforce stronger authentication. You may also apply an address or protocol filter for this group, which can be defined (along with other custom policies such as access hours) in the Configuration | Policy Management section of the concentrator (discussed in Chapter 6, "Software Client Firewall Features"). The middle portion of the General tab entails parameters for applicable primary and secondary DNS and WINS servers. These parameters are sent to the clients during IKE SA establishment and overwrite current values on the client's PC. Figure 4.7's example uses the same server of IP address 10.2.2.2 for both DNS and WINS for remote access users in this group. In addition, the General tab enables you to define SEP card assignments (not shown in Figure 4.7) if the concentrator has multiple SEP or SEP-E cards. It is recommended that you leave all SEPs assigned for redundancy purposes. The bottom of the page enables you to define the supported tunneling protocols for the base group. If users are going to use only a particular tunneling protocol, you can deselect the other tunneling protocols that will not be used. The General tab also allows the VPN Concentrator to forward only usernames rather than a username and a realm for services to an external AAA server, as well as to the concentrator's internal database. For instance, if user Mr Ed was part of the group, Not-So-Human Resources, he may authenticate as Mr Ed@Not-So-Human Resources. With this "Strip Realm" feature, the realm (Not-So-Human Resources) is stripped after the delimiter (@). Thus, only the username, Mr Ed, is passed to the authenticating servers. The final aspect of this configuration tab is to configure the DHCP Network scope that allows you to define the networks that will be leased via a DHCP server to remote access users in the group (if that functionality is provided). Base Group IPSec Tab ParametersIf you are using IPSec for a tunneling protocol, you must define the settings in this tab, which are displayed in Figure 4.8. This tab is divided into two sections: IPSec Parameters and Remote Access Parameters. Figure 4.8. Base group IPSec tab.
The IPSec Parameters section of the IPSec tab determines the factors that are negotiated during the tunnel establishment. Particularly, the IPSec SA field enables you to choose the Security Associations that will be proposed during IKE negotiations for remote access users (site-to-site tunnels ignore this field). You can select from the predefined SAs that entail different types of encryption and authentication combinations, or you can apply your own Security Association created from the Configuration | Policy Management | Traffic Management | Security Associations screen (discussed later in the "IPSec Security Association Activation" section). The values defined in this SA have to match the remote access client's SA to form a VPN tunnel. In the example, the concentrator's administrator is enforcing a predefined SA that is using 128-bit AES for an encryption algorithm with SHA-1 as the data authentication algorithm. The next IPSec parameter defines whether IKE enforces identity validation in certificates. In other words, when remote access clients are utilizing digital certificates for authentication, certain fields in the certificate are used to identify the device, such as IP addresses, distinguished names (DN), or fully qualified domain names (FQDN). This feature can obligate the concentrator to compare the identity data it receives during IKE Phase 1 with the certificate's identity fields. If they do not match, the tunnel is not established. You can require this validation, turn off this feature altogether, or use the default, which allows the tunnel to be established regardless. In instances where the concentrator has an established tunnel with another Cisco device, it can make use of IKE keepalives to ensure the remote peer is still present. A variant of this keepalive feature is known as Dead Peer Detection, or DPD. With DPD, the Cisco devices maintain an idle timer. When there is no data being sent and the timer expires, the tunnel can be torn down to save resources. Cisco enables you to set this idle timer in the Confidence Interval for Easy VPN Clients field, which is defaulted to 5 minutes for remote access and 10 seconds for LAN-to-LAN tunnels. The last field in this section of the IPSec tab is where you define what type of tunnel this group is to use. Here you select whether this group uses a LAN-to-LAN tunnel to another IPSec gateway device, or remote access tunnels to hardware or software clients. Thus, if this group is being utilized for a site-to-site Intranet or business-to-business extranet, this selection should be set to LAN-to-LAN. If users in this group are remote access clients, then choose Remote Access in this field. Because these parameters are defined for our remote access user, Mr. Ed, the default value of remote access is sufficient. If you set this attribute to LAN-to-LAN, you can ignore the rest of the IPSec tab. The second portion of the IPSec tab is where you select specific remote access settings and is only necessary when IPSec is used for remote access. For instance, Group Lock enforces the client's group names to coincide with the concentrator's configuration. If they do not match, the concentrator can refuse the session. By default, this option is disabled.
The VPN 3000 Concentrator is capable of offering all three AAA services. Those services are Authentication, Authorization, and Accounting. In the next few options of the IPSec tab, two of those functions can be applied to users contained in the base group. Authentication of users, as discussed before, can be handled by the internal server of the concentrator or delegated to external RADIUS, SDI, NT, and Active Directory/Kerberos servers. Authorization of resources, on the other hand, can only be off-loaded to RADIUS and LDAP servers. In cases where authorization is being implemented with digital certificates, the Distinguished Name field should reflect the attribute within a digital certificate that will act as the username for the LDAP and RADIUS servers. In this Remote Access section of the IPSec tab, you are given the option to enable compression of IP traffic for the group. The compression algorithm that is used by the concentrator is Lempel-Ziv. Compression should be utilized on groups that might connect at low speeds, such as modem users. When compression is used on higher-speed links, the processing impact on the concentrator is significant and can affect performance. The Default Preshared Key option is actually unique to base groups only. This field enables you to define a preshared key for clients that do not use or understand the concept of groups. The chosen default preshared key for the remote access example is ahorseisahorse. During an IPSec remote access session, the IKE SA might expire and a rekey will need to take place. The "Reauthentication on Rekey option" forces the concentrator to redo the IKE XAUTH function and prompt the client for a username and password again. If the SA lifetime is brief, this may be an inconvenience to the end-user.
The last parameter on the IPSec tab is enabled by default. Mode Configuration is an extremely useful option in which the concentrator can push several policies and configurations down to the connecting clients during SA establishment. Some examples of those particular pieces of information are IP addresses, DNS server addresses, WINS server addresses, split tunneling policies, and so on. The Client Config/Mode Config tab (discussed in the following section) further defines those parameters and can be bypassed if you de-select this option.
Base Group Client Config or Mode Config TabThe next base group tab name reflects either Mode Config in older software versions or Client Config (Figure 4.9) in newer releases. For simplicity, it is addressed as the Client Config tab for the remainder of this book. This portion of the base group configuration enables you to define configuration and policies that can be pushed down to the clients during tunnel establishment, thus eliminating a great deal of configuration for the remote clients. This tab is also broken down in accordance to the type of clients supported in the group. Figure 4.9. Base group Client Config tab.
The top of the Client Config tab pertains to Cisco client's configurations, beginning with a login banner option to display a message up to 510 characters. Be sure to avoid any legal liabilities by abstaining from words such as "welcome," which might inadvertently allow hackers to avoid legal prosecution if apprehended. The banner is followed by a check box in which the concentrator enables remote clients to store their usernames and passwords locally. This poses an obvious security hazard and typically should not be enabled. The example in Figure 4.9 illustrates a stern warning that will be displayed when Mr. Ed connects uses the Cisco Unity software client to connect to the concentrator. In addition, to keep Mr. Ed's password from being compromised, the local client password storage is disabled. When clients are connecting to the concentrator through a router or firewall that is already performing NAT, connections are doomed to fail because NAT changes the source address of the IP header. Because significant bits are changed in the IP header, this violates any data integrity authentication, which results in the remote peer dropping the packets. Similarly, when the original IP header is encrypted via the ESP protocol, the NAT device cannot access those IP addresses in the original IP header, which disables any address translation functionality. Cisco has chosen several workarounds for this problem, one of which is to encapsulate IPSec and IKE traffic in UDP to a specific port number (default is 10,000). This process of encapsulating IPSec and IKE into another header is known as NAT transparency. It is possible to define a port number for each group to avoid conflicts, but IPSec over UDP has a possible limitation in which only one client may be able to initiate a tunnel behind the same firewall. In the example, Mr. Ed is not passing through an intermediary device performing NAT, so this function does not need to be enabled. One versatile function for Cisco hardware or software clients is to utilize backup servers, in which the clients can connect to up to ten backup concentrators if the primary becomes unavailable. This relatively new feature for the concentrator, if utilized, enables you to define those backup concentrators centrally and push them out to the clients. If the clients have hard-coded their own backup servers, the concentrator overrides the client's list. For instance, the example in Figure 4.9 demonstrates that three backup concentrators have been defined for users in the group. If Mr. Ed contained any configured backup servers on his software client, they would be overwritten by these pushed parameters defined on the central concentrator. Notably, the backup functionality can be disabled altogether from the concentrator, which forces the clients to clear any locally configured server lists and disallows them to input any entries in the software.
The next section of the Client Config tab is especially reserved for Microsoft clients that belong to this group. These fields, which appear in more recent software versions, enable the concentrator to intercept DHCP messages and provide the clients with a subnet mask, domain name, and unique to Windows XP provide classless static routes for the tunnel IP address. This is useful in environments where you want to enable split tunneling for Windows XP clients and a DHCP server is not being used. The remaining section of the Client Config tab entails features that are common among all clients and may apply to members of this group. One prominent feature on the Client Config tab is the capability to perform traffic management via a split tunneling policy. Configured on the central concentrator, a split tunneling policy is pushed to clients to define specifically what traffic is to be sent over the encrypted tunnel, and which traffic is allowed to traverse out to the public Internet as clear text. This does expose a security threat because the client can be compromised while having a direct tunnel to the corporate network. For this very reason, the default parameter for split tunneling is to disable it (Tunneling Everything) so that all traffic (including traffic for the client's local network and the Internet) will be sent over the encrypted tunnel. After the traffic traverses the tunnel, routing decisions at the central site can direct the traffic to the private network or out the main office's Internet access. There are two different ways to configure these split tunneling policies if the company's network security policy permits it. You can select pre-configured network lists (discussed later in the "Network Lists" section) consisting of networks that are excluded from the client's encryption and, thus, receive data in clear text. If the traffic destination is not in the list, it is encrypted and sent over the tunnel. When this option (Allow the Networks in List to Bypass the Tunnel) is selected, you can choose a configured network list or a default network list named VPN Client Local LAN. This local LAN option enables the concentrator to push an access control list to the VPN client, which specifies the local resources on the client's LAN that will receive clear text data. Any traffic that is not destined for the local LAN is sent over the secure tunnel. The local LAN feature can be turned off on the Cisco VPN Unity client if the client is connected to an insecure network, such as a wireless or a hotel network. The Only Tunnel Networks in List option is similar to the first option; however, you explicitly define the network destinations that are to receive encrypted traffic through the tunnel. If traffic is destined for the networks in the list, it is encrypted. Traffic destined for any other network is sent in clear text to the client's LAN.
Figure 4.10 depicts a common scenario in which Mr. Ed's connecting client receives a split tunneling policy from the head-end concentrator. This example coincides with the configuration displayed back in Figure 4.9. This split tunneling policy mandates that all traffic destined for the concentrator's network of 10.2.2.0 be encrypted and sent over the tunnel. The 10.2.2.0 network is actually specified in a network list called The Farm and is selected as the only network to which the client sends encrypted traffic. Traffic destined for the client's local LAN, as well as the Internet (such as the www.examcram.com Web server), is sent in unencrypted clear text. Figure 4.10. Split tunneling scenario.
The final options on the Client Config tab entail DNS properties for members of this group. Specifically, you can define the default domain name that is applied to the virtual adapter in clients for packets that are sent over the tunnel. In addition, later releases support split DNS in which DNS resolution for the specified domains is sent over the tunnel and to the corporate DNS server. Remaining DNS queries are sent to your provider's public DNS servers. Base Group Client FW and HW Client TabsIn these two tabs, you can define parameters that apply to the enhanced firewall features and the configuration attributes for the Cisco 3002 Hardware Clients. These two tabs are discussed in later chapters in their respective context. Base Group PPTP/L2TP TabFigure 4.11 depicts the final tab of the base group in which you can configure PPTP/L2TP properties for users contained in this group. This configuration is necessary only if these tunneling protocols were checked in the General Tab. Figure 4.11. Base group PPTP/L2TP tab.
The first option in this tab is to permit clients to assign their own IP addresses. Again, this diminishes the centralized control of IP addressing and security and should be used sparingly. If selected, the "Use Client Address IP" assignment method should also be enabled from the Quick Configuration or the Configuration | System | Address Management | Assignment screen. In the options that follow, the PPTP tunneling protocol parameters are tuned in accordance to the company's security policy. Namely, a number of different authentication protocols, such as PAP, CHAP, MSCHAP, and EAP, can be employed to authenticate peers during tunnel establishment. You can also set requirements for PPTP encryption and Microsoft's MPPC compression. The last fields enable you to define similar services for L2TP tunneling protocol. Specifically, you can define the same peer authentication, encryption, and compression parameters that are available for PPTP. |
EAN: 2147483647
Pages: 185