Perhaps the biggest single new feature in Windows 2000 RRAS is the ability to control access in a more granular fashion using Remote Access policies. Unlike group policy settings that are stored in Active Directory, RAS policies are stored on the RAS server on which they are created. Essentially, RAS policies allow you to control who can (or can’t) connect to the server (using groups), the properties of the connection (which can be different for different users), how long they can connect for, the protocols they must use, and so forth. Furthermore, there can be multiple policies per server, such that completely different policies apply to different groups of users. It is important to understand how these policies work, the elements involved, and why you would configure settings in a certain way.
Remote Access Policies are found in the section with the same name in the RRAS tool, as shown below. Note that by default a single policy, called ‘Allow access if dial-in permission is enabled’ exists by default.
This is important to note. If no policies exist in this list, then ALL remote access connection attempts to this RAS server will be denied. The default policy is very simple. Basically, it allows you remote access if your user account settings are set to ‘Allow access’, while all other connection attempts are denied. This very basic policy effectively emulates the way remote access settings worked in Windows NT 4.0 – either you are allowed access, or you’re not.
Windows 2000 Remote Access Policies are really made up of three distinct parts, and each must be considered when designing these policies. The three parts to RAS policy are the evaluation of:
1. Policy Conditions
This part can be a little confusing, so stay with me. Basically, the first thing that gets evaluated is the policy conditions, which you must meet in order for a policy to apply to you. As an example, I might make it such that a policy I create applies to the group called ‘Sales’. If this were the only policy that existed, and you were not part of Sales, then you would not be able to connect to this RAS server. Policy conditions are the basic parameters that must be met in order to be allowed to make a connection to the server. Double-clicking on a policy will show you the conditions of that policy, and whether meeting those conditions allow or deny you access.
Example of settings that can be used as conditions include Windows group membership, days and times, the phone number dialed by the user, and so forth.
The most important thing to remember is that the conditions of a policy are looked at according to their order in the list of policies. That means that if you don’t meet the conditions of the first policy, then the second policy is looked at, then the third, and so forth. However, as soon as you meet the conditions of a policy, that is the last policy evaluated. So, if 13 policies exist, and you meet the conditions of the 2nd, the remaining policies will not be evaluated, even if they were to give you a higher level of access. Remember that if you do not meet the conditions of any policy, then you are automatically denied access.
Permissions are evaluated once you meet the conditions of a policy. Permissions are the settings with respect to dial-in configured on your user account. Three settings exist: Allow Access, Deny Access, and Control Access through Remote Access Policy. If your account permissions are set to Allow Access, then the Profile settings are applied (as will be discussed in a moment). If your account permissions are set to Deny Access, then you are automatically denied access. If your account is set to Control Access through Remote Access Policy, then whether or not you are allowed to connect is controlled via whether you meet the conditions and profile settings. By default, if your domain is in mixed mode, all users are set to deny access. Once the domain is switched to native mode, all accounts are switched to Control Access through Remote Access Policy. This last setting offers the most flexibility, since multiple users could be granted access at once simply by setting up a policy that gives access to all users in the Sales group, which is obviously easier than setting the properties on many accounts individually
If your permissions allow you access, the final level of evaluation involves the application of profile settings. Profile settings are controlled via the ‘Edit Profile’ button in the properties of a policy. Quite simply, they constitute the settings you are given if you meet the conditions and have the permission use remote access. For example, you might be given a 2-hour connection time, be disconnected if idle for 30 minutes, and be required to use strong encryption. If for any reason you are not able to meet the requirements outlined in the profile, you are also denied access. While you should take the time to go through profile settings yourself (there are too many to describe here), you should be aware that they are categorized according to Dial-in Constraints, IP settings, Multilink properties, Authentication settings, Encryption settings, and Advanced settings (which can vary based on the dial-in equipment).
As you can see, controlling remote access in Windows 2000 is a much more granular task than in Windows NT. However, it is also provides for different levels of access for different groups of users, which makes it much more flexible.