ISA Server 2006 as remote access VPN server and its RRAS created default remote access policies vs user’s Dial-in remote access permissions

You’ve enabled the VPN server on ISA Server 2006 SE SP1, ISA a domain member, ms-chapv2 for example is used for user authentication. You’ve specified a domain group of users for which remote access is allowed.

isa_users

The group of users defined in Active Directory, the VPNUsers group, Group scope: Global, Group Type: Security, has a couple of members:

vpn_users_prop_1

vpn_users_prop_2

Expectations: remote access is allowed only for the members of the VPNUsers group. Other users should not be allowed to connect to the VPN server:

not_allowed

However, the user john, can successfully connect to the VPN server, although he is not a member of the VPNUsers group.

john

And the user anna receives the Error 659 from above.

What’s happening ?

ISA’s remote access VPN functionality is provided by RRAS. ISA provides the advanced “firewall functionality”. Let’s take a look on ISA at the RRAS console. As can be seen from the bellow picture, there is a default remote access policy created by ISA, and we can spot within this remote access policy our domain group for which remote access is allowed and also we can spot two additional remote access policy:

rras_1

Now let’s take a look at these two Microsoft articles:
- http://technet.microsoft.com/en-us/library/cc785162.aspx, Accepting a connection attempt
- http://technet.microsoft.com/en-us/library/cc738142.aspx, Dial-in properties of a user account

Form the first article, we can see how remote access policies are processed, and that a remote access policy can be configured with a Ignore-User-Dialin-Properties attribute. If this attribute is not set to true, and the remote access policy’s conditions matches the user’s connection attempt, the Dial-in remote access permissions of the user account are checked.

From the second article we learn more about the Dial-in properties of an user account, and the Ignore-User-Dialin-Properties attribute, a new feature in Windows 2003, we are linked to this article:
http://technet.microsoft.com/en-us/library/cc778259.aspx#accounts
and we also learn about the domain level functionality, the level needed to have access to the Control access through Remote Access Policy option, that is either Windows 2000 native(unlikely these days) or Windows Server 2003, and we are presented with a link to read more about Domain and forest functionality:
http://technet.microsoft.com/en-us/library/cc738670.aspx

Let’s click the Edited Profile… button on the default policy created by ISA and head over the Advanced tab, as can be seen there, the Ignore-User-Dialin-Properties attribute is not present.

rras_2

From Active Directory Users and Computers: Current domain functional level is Windows Server 2003, which is fine fine:

domain level

Let’s check the users’ Dial-in remote access permissions:

user_1

user_2

user_3

user_4

And we can see that anna’s Dial-in remote access permissions are set to Deny access, while john’s ones are set to Allow access. adrian’s and diana’s remote access permissions are set to Control access through Remote Access Policy.
The users adrian and diana can successfully connect(as they should), only the users anna and john do not “behave” as expected.

 

Assuming you have read carefully the above Microsoft’s documents, let’s proceed.

 

Question: So why John is allowed to connect ?

Answer: Because the two other remote access policies on the RRAS server “allow” this combined with john’s Dial-in remote access permissions. Delete these two remote access policies and the user john will not be able to connect. The first remote access policy is processed(ISA’s default policy, the policy with the number 1), and the conditions do not match user john’s connection attempt, so the second remote access(the one with number 2) is processed. And now a “match” for conditions appears, the Ignore-User-Dialin-Properties attribute is not set, john’s dial-in remote access permissions are set to Allow access, the profile properties match, so remote access will be allowed for the user john. If you delete only the number 2 remote access policy, the number 3 remote access policy conditions will “match” john’s connection attempt, the Ignore-User-Dialin-Properties attribute is not set, and combined with john’s dial-in remote access permissions and the profile properties, one more time remote access will be allowed for user john. If you delete them both, the default ISA’s remote access policy conditions will not match john’s connection attempt, and remote access will be implicitly denied for user john. I’ve noticed that if I delete the two remote access policies(with the 2 and 3 numbers), they will not be re-created when the ISA Server 2006 SE SP1 machine is rebooted or when the firewall service is restarted. More about these two policies here:
http://technet.microsoft.com/en-us/library/cc773343.aspx
Note that if you configure ISA to use RADIUS authentication for VPN remote users authentication, say IAS on Windows Server 2003, and on the IAS you do not delete the two “guilty” remote access default policies, the same “effect” will be obtained:
ias ias2

 

Question: So why Anna is not allowed to connect ?

Answer: Because the default remote access policy created by ISA does not include the Ignore-User-Dialin-Properties attribute set to True and Anna’s Dial-in remote access permissions are set to Deny access. The first remote access policy is processed(ISA’s default policy, the policy with the number 1), and it’s conditions will match user anna’s connection attempt, anna’s remote access permissions are checked because the Ignore-User-Dialin-Properties attribute is not present on this remote access policy and these permissions are set to Deny access, so remote access will be denied for the user anna. If this remote access policy was configured with the Ignore-User-Dialin-Properties attribute set to True, because the profile settings would have matched and the policy was set to Grant remote access permission, user anna would have been granted remote access.

So, if you want more power over your remote access policies, configure ISA to use a RADIUS server for VPN remote users authentication, for example the IAS(registered in Active Directory) from Windows Server 2003 will do just fine. Since ISA is a domain member, you can use the User Mapping feature to still have the group-based firewall access rules. We already discussed here how we can create “advanced” remote access policies on the IAS server to meet certain requirements.
How IAS works:
http://technet.microsoft.com/en-us/library/cc773343.aspx

 

Things to remember to check:

- the appropriate domain group(s) was(were) created and the required users are members of this(these) group(s).
- the users’ Dial-in remote access permissions and domain level functionality.
- the appropriate remote access policies must be created and ordered, make sure that another remote access policy does not grant accidentally remote access.
- if the user’s Dial-in remote permissions are not set to Control access through Remote Access Policy, and a remote access policy’s conditions match the user’s connection attempt while this remote access policy is not configured with the Ignore-User-Dialin-Properties set to True, then the user’s account Dial-in remote permissions will be checked and based on them access will be or not granted if the profile properties match.
- if the user’s Dial-in remote permissions are not set to Control access through Remote Access Policy, and a remote access policy’s conditions match the user’s connection attempt while this remote access policy is configured with the Ignore-User-Dialin-Properties set to True, then access will be granted per this remote access policy if the profile properties match, so if you want to allow access you will set the policy to Grant remote access permission.
- if the user’s Dial-in remote permissions are set to Control access through Remote Access Policy, and a remote access policy’s conditions match the user’s connection attempt while this remote access policy is not configured with the Ignore-User-Dialin-Properties set to True, then access will be granted per this remote access policy if the profile properties match, so if you want to allow access you will set the policy to Grant remote access permission.

Comments (2) -

  • Jason Jones

    4/30/2009 10:38:07 AM |

    Hi Adrian,

    Interesting article!

    Surely if you have a granular, user-level firewall policy that applies to the VPN clients it is not that important who is able to establish a connection? Even if connected, ISA will deny access unless users have been explicitly defined in an "allow" rule?

    Cheers

    JJ

    • adimcev

      4/30/2009 1:44:52 PM |

      Hi Jason,

      Yes, from a point of view, indeed. And it can be even better, for example if L2TP/IPsec is used, only machines that have a "machine" certificate can be used for VPN remote access, so the first authentication must be "passed".

      I saw that the topic "my group-based remote access permissions restriction does not work" a few times, so I decided to "expose" the "mystery" a little bit.

      From another point of view, some may consider this and break it into pieces:
      technet.microsoft.com/en-us/library/cc512578.aspx

      .....
      VPN server says: Who are you ?
      VPN user says: I'm a user that is supposed to be have remote access permission.
      service. Are you the real VPN server(in case it has not already asked that) ?
      VPN server says: Prove it. Yes, I am.
      VPN user says: Here is my proof. Your turn to prove it(in case it did not already verify the server's identity, depending on the VPN protocol and the authentication protocol used).
      VPN server says: Yes, you have remote access permission, you are "authorized" to access the VPN server. Connection successful. A log was created.
      VPN user says: You are the VPN server. Connection successful. I want to access an internal file sharing server.
      VPN server(ISA jumps in) says: Now let's see what resources you are authorized to access. Yes, you are authorized to access this file sharing server. Your session will be logged and inspected.
      ....

      So, if one decides, with ISA, for VPN users, it has the technical means to a certain extent, to break into the pieces and strengthen the identity, authentication and authorization.
      If you skip the "you are authorized to access the VPN server" step, you do more for nothing. Any consequences in doing that ? Why would one worry if he would not do that in the first place...

      Thanks,
      Adrian

Comments are closed