Remote Access Policies

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Hi all,

More stuff that should make sense on the 70-215 but doesnt. Could anyone confirm the following:

On a request for remote access, after permission is granted on the user account, whether more than one remote access policy is checked to grant access?

The book I am using (Syngress) contradicts itself by saying:
If the 1st policy does not allow access then futher policies are NOT checked.

Then later it shows a flowchart showing if the condition of the policy does not match the connection attempt, it goes on to check the next policy!!

I would have thought it would check all the policies until there was a contradiction and refuse at that point. If no contradiction then it would allow.

Anyone fancy tackling this one?

Thanks in advance, guys....

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

On first read, this would suggest to me that "Deny" is in place. Which is not the same as

...which merely suggests that it hasn't encountered an "Allow" in a policy yet.

Sorry if thats less than clear, but I'm already a bit rusty on the 215, and not yet up to speed with 218. I'll try and help a bit more later.

Besides, the Big Guns will be around shortly ....

 

Hi Cartman,

I think What your book is actually saying is if when running through the acces policies it hits a specific deny then it doesn't bother looking any further, the user is denied access,end of story. If on the other hand a user doesn't match the the first policy but isn't actually denied by the first policy it goes on to check the next policy and so on until it reaches the last policy. If I remember correctly, if the user doesn't match any policy allowing them access then they are denied access.

 

Thanks for the replies guys.

Damn confusing for something that on first sight seems straightforward. Guess that is MS for you then.

Seems the default policy (which there has to be at least one) works giving a condition of any time or any day - but it seems to work whether you grant access from the condition or deny it!!! Dear oh dear.

 

Remote Access Policies have 2 different types of access control, for want of a better descritpion, the first one is the CONDITION.

If a user connects to a RAS Server then the policies are checked, starting from top to bottom in list.
The first thing that is checked is the condition of the policy. There are approx 20 different conditions which can be applied, ranging from day and time right through to the top of remote connection (e.g. ISDN, VPN).

If the connection attempt does not match the conditions then the next policy is checked. Worth pointing out, if there are no more policies to check the connection attempt is rejected.

If the connection attempt meets the condition then the next stage of access control comes into play. This is the PROFILE.

The profile also allows you to configure time and date restrictions along with approx 75 other restrictions (although many of these are vendor specific). If the connection attempt does not match the profile the connection is rejected and the user is disconnected.
If the same user re-dialed back in exactly the same procedure would happen.

A quick recap

CONDITION not met = Next Policy
(if no more policies connection attempt is rejected)

CONDITION met = Check Profile

PROFILE not met = Reject connection

PROFILE met = Allow Access

The above is a simple overview of remote access policies.

There is a lot more to discover relating to Users dial-in profile, Allow or Deny access on conditions etc. But I hope the above may help to clear the fog.

 

It's called a parse and that means it will read the rules (policies) down the list from top to bottom, as soon as it finds a rule that matches the user (grant access or deny) it will exit the list. So a specific allow or deny will be processed and no further policies will be read. (deny is always written to the top of all lists).