In-Depth

RAP Traps

Remote access policies are at the heart of remote access--and at the root of most problems. Learn how they work and avoid the mistakes that can lock out your remote users.

• By Todd Logan
• November 01, 2004

Sandy's getting ready for a critical sales call, the one that could land the huge new account. She's on the road, trying to log on to the company intranet to retrieve some documents, when she gets an "access denied" error message. She's logged onto the VPN every day for a year, and never had this happen before. She desperately calls IT, trying to figure out what's going on.

Your phone rings. It's Sandy on the other line. You can sense she's near a nervous breakdown. What do you do?

If you know how to troubleshoot remote access to your internal network, you help Sandy avoid a hospital trip, and help your company land the new account. Remote access in Windows 2000 Server and Windows Server 2003 is a complicated undertaking; any number of seemingly small things can go wrong, making your users slam into a brick wall when trying to establish a connection.

The biggest obstacle is usually a misconfigured remote access policy (RAP), which is the key to the remote access kingdom. Learning the ins and outs of how to configure RAPs, and how they work in practice, can help you ensure users have secure, efficient remote access to Win2K or Windows 2003 remote access servers.

RAP Components
RAPs provide a granular, centralized means of ensuring you provide secure access to a remote access server. They consist of three components, all of which must be satisfied before a user can gain access:

• Conditions. Conditions include attributes such as time of day and day of the week, user or group membership, and caller ID numbers.
• Profile. The profile includes settings such as authentication and encryption protocols, maximum session time, and allowing access only through specific media such as wireless, Ethernet, DSL or VPN.
• Permissions. "Allow" or "deny" permissions can be assigned on an individual basis. Right-click on a user account in Active Directory Users and Computers, select Properties, then select the dial-in tab, as shown in Figure 1.

Figure 1. The dial-in tab is used to configure remote access permissions.

This can be laborious in a large organization. To save time, you can configure the dial-in permissions for all remote access attempts in one fell swoop by using a RAP. This is a two step-process: first, configure dial-in permission for a user account to "Control access through Remote Access Policy," as shown in Figure 1. (Note the "Control access" option is only available when a domain using Win2K domain controllers [DCs] is running in Native mode, or a domain using Windows 2003 DCs is running in Windows 2000 native functional level or higher.)

To complete the second step, either grant or deny remote access permission by right-clicking on a RAP in the Routing and Remote Access console, then select Properties, as shown in Figure 2.

Figure 2. This server will grant remote access permission to anyone meeting the conditions shown in the window.

At this point, all users who meet the basic conditions will either be allowed or denied remote access depending on the RAP "Grant" or "Deny" setting in Figure 2. But there's a safeguard built in: the user account remote access permission overrides the RAP permission settings. So user Todd from Figure 1 would be denied access to the network, even though he meets the basic conditions, because his dial-in permission attribute has the "Deny access" button selected. This allows you to create exceptions by setting the permissions on a RAP to grant remote access permissions for most users, but deny dial-in access for specific user accounts. You can also create exceptions through the use of multiple remote access policies (discussed later).

Proper Protocol
A common cause of denied connection attempts is a mismatch between a RAP setting and an incoming remote access connection. For example, if a RAP profile is configured to only use EAP-TLS as its authentication protocol, and the incoming remote connection attempt is configured to only use MS-CHAPv2, the remote connection attempt will be denied. In these situations the error message will read, "The account does not have permissions to dial-in." This can be frustrating, since the admin has probably already double-checked the dial-in permissions to verify that the user has remote access permission.

The fun doesn't stop there. Conflicts can also occur between the authentication protocols of the RAP and remote access server that hosts the RAP. If MS-CHAPv2, for example, is the only authentication protocol configured for the profile of a RAP and the remote access server only has MS-CHAPv1 enabled, the remote access client will be denied access. In conflicts between the authentication protocol settings within a RAP profile and the remote access server, the profile settings take precedence. Thus, you need to ensure remote access clients, servers and RAPs share at least one authentication protocol.

Processing Remote Access Policies
To effectively configure or troubleshoot a RAP, you must understand how the components of a RAP are evaluated against an incoming remote access connection attempt. The process flows in the following order, and a connection must complete each step before passing to the next:

1. The first stop is the remote access policy on the remote access server. If there is no such policy, all incoming connection attempts will be denied, so be sure your remote access server has at least one RAP. (It does have one by default, but it can be deleted.)

2. RAP conditions are compared to the incoming connection attempt. For example, is the remote user in the marketing group, and is the connection attempt being made Monday through Friday between 8 a.m. and 7 p.m.? If no RAP contains a set of conditions that completely match the incoming remote connection attempt, access is denied.

3. If the user's remote access permission is set to Deny access, that's what happens. If not, the other settings are checked.

• If the permission is set to Allow access, the policy profile is applied.
• If the permission is set to Control access through Remote Access, the RAP permission settings are evaluated.
• If the RAP permission (not the user's access permission) is set to deny access, the user is denied access. If the RAP permission is set to grant access, the policy profile is applied.

4. RAP profile settings are applied to the incoming connection. If there are no conflicts between critical settings for the profile, remote access server, and remote access client, the connection attempt will be allowed.

Figure 3. A remote access server with multiple remote access policies installed. The policies are evaluated in order, starting with No. 1. (Click image to view enlarged version.)

Dealing wtih Multiple RAPs
We've focused so far on single RAPs, but you can apply different conditions to a variety of remote access users through the use of multiple RAPs. Say, for example, you need to control when the sales group can make remote access connections. You create a RAP with conditions that allow only members of the Sales group to connect and a profile setting that allows them access only on Monday through Friday from 7 a.m. to 6 p.m. You create another, generic RAP to permit remote access connections at all times for other users.

This creates a potential problem: How is the remote access server going to differentiate a sales user from other users, since sales group users are also domain members?

The answer is that RAPs are arranged in an ordered list. Each remote access connection attempt goes initially to the first RAP in the ordered list. If that first RAP's conditions don't match, the incoming connection attempt passes to the next policy in the list.

So, in the previous example, if the sales RAP is first in the ordered list and a non-sales user account attempts a remote connection, there won't be a 100 percent match in the conditions of the first policy—the user isn't a member of the sales group. So the next policy in the list is evaluated. In this example, that would be the generic RAP, and the user would be granted remote access since the conditions apply to all users.

If the order of these policies was reversed, members of the sales group would be inadvertently granted remote access. The generic RAP is now at the top of the ordered list, so the conditions would also match the Sales group members, since they're also domain users.

This is where you can get into trouble real fast. It's easy to spend a lot of time creating a RAP, double-checking its settings against those of the remote access server and the remote access client, only to grant or deny remote access based on the position of the RAP in the order list. As a general rule of thumb, it's best to place the RAP with the most specific conditions at the top of the list.

Acting Globally, Stored Locally
Something else to bear in mind is that RAPs are stored locally on the remote access server, not in Active Directory. So even though the word "policy" is used in remote access policy, it isn't a Group Policy Object that can be created in AD. This means if your organization uses multiple remote access servers, you'll have to create and manage the same RAPs on each of them. This can be a challenge if you have numerous servers, since it's easy to make a configuration mistake that can result in a user being granted or denied access in error.

However, you can centralize the management of RAPs by using a server configured with the Internet Authentication Service (IAS), which is a subcomponent of the networking services on a Win2K or Windows 2003 server. An IAS server will act as a Remote Authentication Dial-In User Service (RADIUS) server, effectively making the remote access servers RADIUS clients. In this configuration, an incoming remote access connection attempt will be passed from the RADIUS client to the RADIUS server to either grant or deny a remote access connection using the RAPs stored on the RADIUS server.

Now that you know how RAPs operate, you can nip remote access connection attempt problems in the bud. Sandy will thank you for it.