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.
The group of users defined in Active Directory, the VPNUsers group, Group scope: Global, Group Type: Security, has a couple of members:
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:
However, the user john, can successfully connect to the VPN server, although he is not a member of the VPNUsers group.
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:
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.
From Active Directory Users and Computers: Current domain functional level is Windows Server 2003, which is fine fine:
Let’s check the users’ Dial-in remote access permissions:
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:
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.