|
Home > Archive > 70-216 > July 2001 > Policy Order
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| trebor 2001-07-30, 5:09 am |
| I am trying to figure out the importance of the order in which Remote Access Policies are processed.
When a policy is found which alows a user access are the other (possibly more restrictive policies) then ignored? | |
| Joe Blacke 2001-07-30, 8:26 am |
| There are several parts to an RRAS policy.
The first is the conditions of the policy. For example, you can set the time of day, and/or the groups that are allowed to dial in. These are the conditions that are being checked when a user dials in. Either the RRAS server, or the IAS server goes through the individual conditions of a policy, starting with the first policy, to determine access. If no conditions match on the first policy, then the next policy is checked, and this continues until all policy conditions are checked. The conditions must match exactly, or the connection will be denied. If the remote user cannot match the conditions of a policy perfectly, the connection will be denied. Regardles of how many policies you have, only the first policy whose conditions match will be processed.
The second part of the RRAS policy, is the connection permissions (for lack of a better word). These are set on the user account. It can be set to either Allow or deny access. In a native mode domain, or a stand alone server, you can also use controll access through remote access policy.
Third is the actual paramaters of the policy. This is only applied if the remote user has met the conditions, and has been granted explicit dial in permission, either on his user account or on the remote access policy. The parameters, specify how long someone can be connected, or encyption settings. These controll the validated and authorized remote session. You have to meet the first two critera above, before these policy paramaters can be applied.
Lets take an example:
You want your sales department to be able to dial up to your network.
You create a new RRAS policy, that has the conditions that only the sales group, can dial in, and only after 7pm.
You then have to go to each user account within the sales group, and either choose Allow, or controll permissions through remote access policy. If you say to controll permissions through remote access policy, you are basically saying that if a persons meets the policy conditions, then let them create a connection. However, you still need to click the radial button on the RRAS policy to allow access.
You decide to leave the rest of the policy alone, and not configure maximun session time, or encryption.
When a user in the sales group dials in, the rras server will starting with the first policy to see if the connection matches the conditions of that policy. Since you want your sales group to be the only group to be able to dial in, you need to put this policy at the top of the policy list, because if they meet the conditions of another policy, they might be denied remote access. When the RRAS server finds a policy where the conditions of the policy match the conditions of the dial in session (remember the one we created was that you had to be a member of sales group, and it had to be after 7pm), it checkes the user account. Since all the users in the sales group were changed to allow access, the remote session is established and the user is connected.
I hope I confused you enough.
The best way to learn this is to enably routing and remote access on a pc. You can look at the policies and conditions, then disable RRAS. | |
| trebor 2001-07-30, 8:39 am |
| Wow Joe. That was impressive. Believe it or not I have RRAS enabled on my lil' server but am having trouble with this.
So in your example you are worried that the sales group might be denied access by a policy that was processed first. Why, if the policies will be looked at one after another to see if they meet the conditions of any one? | |
| Joe Blacke 2001-07-30, 11:04 am |
| Once the connection matches a RRAS policy conditions, no other policies will be checked. This includes the policy with the conditions that grants the user access. |
|
|
|
|