The findings included in this document are based on Windows 2003

• How to register a VPN/PPTP server in DNS?

• How do RRAS remote access policies combine with ISA VPN definitions?

• How are RRAS remote access policies evaluated?

How to register a VPN/PPTP server in DNS?

It is recommended not to configure a VPN/PPTP server to automatically register its connection address in DNS. In some cases, especially when the PPTP server also acts as DNS server, this could cause conflicts with dynamic registration from VPN clients (see also Q292822).

It is crucial though that both the A and PTR records for the internal interface of the PPTP server are properly registered in DNS. So carefully configure these entries manually.

When the registration of a PPTP server is not executed properly PPTP sessions might not be authenticated correctly and/or the PPTP server might not be able to failover to another DC in case the first one breaks down.

How do RRAS remote access policies combine with ISA VPN definitions?

VPN access can be defined through the ISA management console. This results in a Remote Access Policy in RRAS (Routing and remote Access) with the name “ISA Server Default Policy”.

This policy can be changed in RRAS, but most changes are overwritten by ISA again after applying any change in ISA.

In RRAS you can add additional policies though, as long as they have a different name. These policies are not changed by ISA, but the ISA Server Default Policy is always put on top of the list.

Very often you might not like what ISA generates for you in its default policy. It allow for example the very weak 40 bit encryption, without offering a way to change that, while changes in this area on RRAS level will be overwritten again.

Therefore it is often advisable to not use the default policy generated by ISA. It cannot be deleted (it would be recreated again), but we can make in un-effective by having this policy grant access to a dummy local group, not containing any users.

You can then add your own remote Access policies through the RRAS interface underneath the ISA Server Default Policy.

How are RRAS remote access policies evaluated?

When deciding whether a user will be granted Remote Access permission RRAS will use the following rules:

•  If the “Deny Access” option is set in the Dial-in properties of the user account, no remote access will be allowed, irrespective of the remote access policies defined in RRAS.

•  If the “Allow Access” option is set in the Dial-in properties of the user account, RRAS will go through its list of Remote Access policies from top to bottom. As soon as a policy is found where the Policy Conditions match the user account, the user is granted access, even when the Remote Access Permission is set to “Deny”.

•  If the “Control access through Remote Access Policy” option is set in the Dial-in properties of the user account, RRAS will go through its list of Remote Access policies from top to bottom. The first policy where the Policy Conditions match the user account defines whether access is granted. When the Remote Access Permission of that policy is set to Granted, the user is allowed access, if it is set to Deny, the user is not allowed access.

Notice that the Policy Conditions could contain many types of criteria. If a policy should apply to all users you could set the Day-and-Time-restrictions to match all times (this might be useful when using SecurID tokens for user authentication, while all token users may use the VPN facility).

The list of Policy Conditions cannot be empty though. If a policy should apply to no users at all you could set the Windows Group in the policy condition to a local Windows group not containing any users (this is a simple way to make the default policy that might be generated by ISA un-effective).

If a Policy Condition contains multiple criteria, all criteria must match before the policy is applicable ("and" relationship).