To incorporate per-user ACLs, IAS leverages remote access policies that apply settings based on AD group information. IAS checks the remote access policy conditions in the order in which the policies are listed in the Internet Authentication Service snap-in; users will use the first policy that applies to them regardless of whether the policy grants or denies remote access. To change the order in which the policies are listed, simply right-click a particular remote access policy, then choose Move up or Move down from the context menu.
To configure per-user ACLs, use the Internet Authentication Service snap-in to create a new remote access policy. Right-click the Remote Access Policies container in the left pane, then choose New. Enter the name of the policy, then click Next. In the next screen that appears, specify the conditions that you want to apply to this policy. For example, by clicking Add and selecting Windows-Groups, you can apply this policy to any group that exists in AD. Note that you can't apply remote access policies directly to individual users. You can, however, place a user in a new group and apply the policy to that group. Although per-user ACLs is a bit of a misnomer in this situation, all Cisco documentation uses that name to refer to this capability.
After you specify the conditions for the new policy, choose Next and select Grant remote access permission in the next screen. Click Edit Profile to open the Edit Profile dialog box, then select the Advanced tab. In the tab's Parameters portion, you'll see the default settings for Point-to-Point Protocol (PPP) connections. Click Add to add the per-user ACLs. In the Add Attribute window, choose Cisco-AV-Pair. The Cisco-AV-Pair option is preconfigured in IAS to use attribute 26 with Cisco's vendor code of 9. In the Multivalued Attribute Information window, click Add to create an ACL entry. To list the ACLs, you must use the following format:
ip:inacl#N=permit <prot> <source>
<smask> <destination> <dmask>
where N must increment, prot is the protocol to control, source is the source network, smask is the wildcard mask (or inverse mask), destination is the destination network, and dmask is the wildcard mask. For example
ip:inacl#1=permit ip 192.168.254.0 0.0.0.255 192.168.200.0 0.0.0.255
ip:inacl#2=permit ip 192.168.254.0 0.0.0.255 192.168.201.0 0.0.0.255
permits access to the 192.168.200.0 and 192.168.201.0 networks from dial-up clients given IP addresses from the 192.168.254.0 subnet. Although this example configures an inbound ACL, you can also configure an outbound ACL. Simply replace the inacl keyword with outacl. When you configure any ACL for use with Cisco IOS, it's important to remember that all traffic not explicitly permitted is implicitly denied. After you add all the desired ACL entries, confirm each dialog box to complete the creation of the remote access policy. For more information about basic ACL configuration for Cisco IOS, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt3/scdacls.htm.
Applying Time-Based Restrictions
After you create and name a new remote access policy, you can set conditions on that policy to control when remote users can connect. From the Conditions dialog box, click Add to add a new condition. From the Select Attribute dialog box, choose Day-And-Time-Restrictions to open the Time of Day Constraints dialog box. Select the time ranges during which remote users can connect. Make sure that you add the Windows-Group or another condition so that your policy will apply only to the users you choose to affect.
Endless Possibilities
IAS and AAA are both flexible tools. When combined correctly as a RADIUS-based authentication server and NAS, they can increase the security and manageability of deployed dial-up and VPN solutions. Although I can't detail all the potential scenarios in this article, I hope this exposure will give you a taste of the many possibilities and help you further leverage IAS and AAA within your network.
End of Article
Prev. page
1
2
3
[4]
next page -->
