Windows Server 2003 Configure Routing and Remote Access User Authentication

  • Print Article |
  • Send to a Friend |
  • |
  • Add to Google |

Configure Routing and Remote Access User Authentication: Configure Remote Access Authentication Protocols As you may recall, I earlier said that there are two conditions under which you can configure user accounts to control access through remote access policies. One is when the account used for access is local to the network access server, and the other is when the domain account is part of a domain in the proper functional level. When a domain is in mixed mode, meaning domain controllers from NT4, Windows 2000 and Windows Server 2003 are supported, the domain accounts can not be configured to control access through remote access policy.

In that case, the button itself will be dimmed, as will the associated configuration options. All that you will be able to do in that case is define on a case-by-case basis whether remote access is allowed or denied, with the default condition being denied.

When you CAN use remote access policies, however, life as a RAS admin is very nice! In order to use control access through remote access policy for domain accounts, the domain must either be in Windows 2000 Native or Windows Server 2003 mode. With remote access policies, you can control access based on the time of day, day of the week, type of computer, group membership and so on. The possibilities, while not truly endless, sometimes seem that way!

In addition, there are also the Dial-in permissions that you will need to configure. So, before we get into remote access policies, let's take a look at the dial-in permissions tab of a user account.

As you can see, there are five areas that you can configure. Under Remote Access Permission (Dial-in or VPN), you can allow, deny or control access through remote access policy.

You can also use caller ID to verify that the number being used to make the connection is the same as what is configured in the account properties. This option is very secure, though limits users to a single set of computers in their home or a mobile computer with a built in cellular modem. Callback options allow you to set no callback, have the caller always callback to a particular number, or allow the caller to set the callback number. Having the caller set the callback number is not an option that is used for security purposes; rather, it to allows the user to reverse the charges.

Always callback to can be used as a security method, however, as access will not be granted until the network access server calls back the computer and it responds on the number configured in the user account. You can assign a static address to a caller, which will override the settings in a remote access policy if one is used. Likewise, you can assign static routes for a caller in their account properties. Note that when the account is a domain account and the mode is Windows 2000 Mixed, only the callback options and allow or deny are available. If the domain is Windows 2000 Native or Windows Server 2003, all options are available. What we have explored thus far is just the account properties side of permissions. This is really considered to be separate, however, from the permissions that are part of a remote access policy (shades of printers vs. print devices, eh?).   

Configure Routing and Remote Access Policies to Permit or Deny Access: Once you have defined that a user account will have remote access controlled through remote access policies, you need to ensure that there is a policy in place that meets the requirements for that access. With remote access policies, access is very cut and dried. You either are allowed, or you are not. As with other permission types, unless you are explicitly allowed, you are denied. What is somewhat different between remote access policy processing and other permission processing is that once an allow determination is made, no further processing occurs. Thus, if you have 3 policies, two being the default and one being a custom that you have defined, and the custom is first in the processing order, then any access attempt which meets the conditions defined in the policy will be allowed.

[Light bulb please] Remember that the default policy setting is to deny everyone at all times of the day!
A remote access policy is made of three elements:
• Conditions
• Permissions
• Profile.

Conditions are policy elements that include settings such as time of day, calling station ID, day of week and even the groups that a user is a member of. When processing a policy, condition is evaluated first. If the conditions for a policy are not met, then processing moves to the next policy in the processing order. If it is the last policy in the processing order, then the result is an implicit deny because the calling station did not meet any of the conditions of access. When conditions for a policy ARE met, the policy processing moves to the next stage-permissions evaluation. Permissions are policy elements that are evaluated as soon as a condition is met. For example, there is a second default remote access policy. This policy states that the Everyone group is denied access at all times of the day on all days of the week. So, if users attempt a connection with the default remote access policy unmodified, they will meet the conditions of second default remote access policy. As a result, policy processing will determine the permission applied under those conditions -- in this case, "deny access" will be applied. Remember that once an allow or a deny is reached, no further processing occurs! This is where you would edit or add conditions, edit the profile and define grant or deny remote access permission.In the conditions section, you can add as many separate conditions as you would like. Remember that policy processing is an AND operation in a single policy, and an OR operation between policies. 

Some key conditions that you will likely be using are:
• Authentication-Type, which defines the authentication protocol.
• Day-And-Time-Restrictions, which defines when access is allowed OR denied.
• Tunnel-Type, which defines the tunneling protocol.

If you are configuring a VPN link between two RRAS servers, for example, you must be sure that both are using the same tunneling protocol.

Windows-Groups, which defines which groups are allowed or explicitly denied access.
A remote access profile can be used to override the settings on the network access server, placing restrictions in a number of areas as shown below: 

As you can see, just on the Dial-in Constraints tab there is a number of configuration options. You will find that some condition elements are duplicated here. Since the conditions and permissions are processed before the profile, you may find that some contradictory settings still work. What you should do, however, is make the setting in one place or the other. If, for example, you want to control access based on time, then set that as a condition rather than a profile element. Remember that conditions and permissions are evaluated first, while the profile is applied only after an access attempt is authorized. 

Configuring a policy is done using the RRAS Management console. Once you have configured and enabled RRAS on a server, whether it is to be used for LAN routing or Remote Access/VPN, there will be a section under that server called Remote Access Policies in the tree view portion of the console. Choose that object, and the policies defined on that server will be shown in the details pane. To edit a policy, you can double-click on it, select it and right-click, or select properties from the action menu. From the context (right-click) or action menu, you can also move a policy up or down in the processing order, as well as delete or rename a policy.

When the remote access policies object is selected, you can add a new policy or modify the view of that portion of the management console. 

Configure Internet Authentication Service (IAS) to Provide Authentication for Routing and Remote Access Clients Windows Server 2003 IAS, or Internet Authentication Service, is an industry standard RADIUS implementation. So, before we get into configuring IAS for RRAS clients, let's take a look at what RADIUS is.

RADIUS stands for Remote Authentication Dial-In User Service. As the name suggests, it is used for dial-up type access-which includes VPN. The purpose of RADIUS is to provide centralized authentication, accounting and access control for remote users. It has been in use with ISPs for quite some time, but has been gaining popularity with use in corporate networks as a means of better managing remote access. Consider using RADIUS in medium to large networks with a fairly significant remote user population.

There are three main components to a RADIUS solution:
• RADIUS Server
• RADIUS Client
• RADIUS Proxy.

These names are not quite as self-explanatory as they seem! It is very important that you differentiate between the client and server components. Now, let's look at each of the components.

A RADIUS Server is a server that handles authentication and accounting services. The server or servers use a centralized database that can be a Kerberos realm, a flat file or a directory service. When using a file-based system, keep in mind that all RADIUS servers need to use the same file so that access is consistent. It is, after all, a means for centralized authentication! 

A RADIUS client is an RRAS server-the server that actually provides the access. When an access attempt is made, the RADIUS client will send the authentication request to the configured RADIUS server or servers, rather than checking its local database. This can also be a WAP, or a RADIUS proxy. Anything that falls in the realm of remote access can be a RADIUS client, providing it has the necessary hardware and software/firmware.

A RADIUS client is similarly an access server, but one that is configured as a go-between. Often this is used in solutions where there are multiple RADIUS servers that a RADIUS client can use. By pointing the RADIUS client to the RADIUS proxy, you can offload logic processing on the client to the proxy, thereby freeing up resources for what the client does best-providing access.

Now let's look at IAS itself. Note that while RRAS is installed automatically, IAS is not. To install it, you must choose Internet Authentication Service from the Network Services portion of Add Windows Components in Add/Remove Programs. One of the biggest advantages to using IAS is centralized policies. When using remote access policies, they are stored on each RRAS server. If you have a couple of remote access servers, it is not too big of a deal to duplicate policies. If you have a large number of them, however, things can get kind of rough! IAS can solve this for you because you can use the IAS server as the central policy holder. Bear in mind that if you do configure RRAS to use an IAS server, any policy on the RRAS server will no longer be used. 

In addition, if your IAS server is a domain member, it will use domain credentials only, which provides a single sign on solution.

The authentication processing flow, when using RADIUS/IAS, is only slightly more complicated than that of a more traditional Windows solution. First, the user instantiates the access attempt with the network access server-which is also the RADIUS/IAS client. Then the client sends the authentication request to the RADIUS/IAS server or proxy, as the case may be. From there, either the proxy forwards the request to the server or the server uses its configured database to process the authentication request. If the server is a domain member, then it will send the authentication request to a domain controller. After authentication occurs or fails, the server responds to the client request with either an access-accept or an access-reject.

If there are policies in place on the server, then the same processing method that you learned earlier applies. The authentication occurs,and then the conditions are evaluated. Once there is a matching set of conditions, the permissions for that condition are evaluated. Once the permissions are determined to be "allow", the profile (if any) is added to the mix, after which the information is returned to the client.

While this seems like a lot of overhead, it doesn't really add that much time to an access request and in the long run will save you time by providing a centralized management infrastructure for RRAS administration. 

In order to use Active Directory, an IAS server must be authorized in Active Directory-much the same way a DHCP or RIS server is. If you do, as part of the process, the IAS Server computer account will be added to the RAS and IAS Servers security group. Don't remove them, because these groups have the necessary rights to access Active Directory user information. As you may notice, this IAS server is not configured to process requests for any RADIUS clients, as there are no clients configured yet.
 
Adding a client is done much the same way you have done everything else so far. Right-click on RADIUS clients or choose it, then click on the Action menu. From there, you choose to add a client.

When adding a RADIUS client, you need to specify (in order):
1. On the first screen of the wizard, you will configure:
a. Client Friendly Name - this is the name you will have this IAS server display in the IAS console.

b. Client Address - this can be either the IP address or DNS name of the client.
2. On the second screen of the wizard, you will configure:

a. Client Vendor - you have a drop down list where you choose the RADIUS client vendor. The default is standard, but you can specify a different vendor if necessary.

b. Shared Secret/Confirm Shared Secret - this is where you configure the password that a RADIUS client will use so that it can be authenticated by the IAS server. The shared secret can be up to 255 characters long, and as with any password longer is more secure.

c. Request must contain the Message Authenticator attribute - here you can choose whether or not the RADIUS client includes a digital signature for PAP, CHAP and MS-CHAP authentication. IAS always requires the signature for EAP authentication, so if you are using EAS make sure to check this option.

On the RRAS server providing network access, or any other server type performing the same function, you will need to configure it to point to the IAS server you just configured. To do that with RRAS, click on the server name of the RRAS server, then either right-click or action and then properties. Click on the security tab, and instead of Windows Authentication change it to RADIUS. Having chosen RADIUS for authentication (and optionally accounting as well), you will then need to configure the RADIUS server or servers to use. To do this, you will click on configure and then add. Fill in the IP address,

configure the shared secret, and you are good to go!
[Light bulb please] Important! After configuring RRAS to use RADIUS for authentication, you will need to restart the service. Click on action, restart to restart the RRAS service.

Deborah Timmons is a Microsoft Certified Trainer and Microsoft Certified Systems Engineer. She came into the Microsoft technical field after six years in the adaptive technology field, providing technology and training for persons with disabilities. She is the President and co-owner of Integrator Systems Inc.

Article Rating (1.5 stars):
  • article full star
  • article no star
  • article no star
  • article no star
  • article no star
Rate this Article:
  • Article Word Count: 2519
  • |
  • Total Views: 1469
  • |
  • permalink
  • Print Article |
  • Send to a Friend |
  • |
  • Add to Google |
>