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 is also the Dial-in permissions that you will need to configure. So, before we get into remote access policies, lets take a look at the dial-in permissions tab of a user account .Local user account, showing the dial-in tab of the account properties. 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.
RRAS User Dial-in: 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.
Under callback options, you can either set no callback, have the caller set the callback number or always callback to a particular number. Set by caller is not used for security, but rather to allow 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 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, the conditions on the second default remote access policy are that the everyone group, at all times of the day, on all days of the week, is denied access. So, if a user attempts a connection with the default remote access policy unmodified, they will meet the conditions of everyone group, time of day and day of week. As a result, policy processing will determine the permission applied under those conditions and in this case deny access. [Light bulb please] Remember that once an allow or a deny is reached, no further processing occurs!second default remote access policy.
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. In Figure 4.15 are the conditions that can be set.
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 Word Count: 1003
- Total Views: 982