Friday, 20 June 2008

Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts

An area that I get involved with my 'day job' quite a lot is protecting Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) extranets with ISA Server. Depeding on the customer needs, and security policy, this often results in an architecture design that includes a one-way Microsoft Active Directory forest trust. The key concept of this model is to solve two things; namely functionality and security.

So, lets look at functionality first - this is the 'forest trust' bit:

By using a forest trust we have a way for both internal and external users to share extranet resources. By its very nature, a forest trust is often popular because it ensures that internal users will be able to access extranet information transparently. By this we mean that users will be able to use their normal Windows credendials (that they are normally logged in with) to access extranet resources without the user even realising that this is occuring.

Next, lets look at security next - this is the 'one-way' bit:

Placing external users into an internal Active Directory environement, the 'Intranet forest', is never really a good idea, as the forest is the only real security boundary in Active Directory. Subsequently, a common solution is to create an 'Extranet forest' that is used to host external user credentials and create an isoltation point or segmented boundary from internal users. This makes the security people happy, and by way of a forest trust, this makes the users happy because it 'just works'. However, to make the security people even happier and to protect against account compomise in the Extranet forest, we ensure that the trust relationship between these two 'zones' is configured such that the Externet forest trusts the Intranet forest, but the Intranet forest DOES NOT trust the Extranet forest; hence the term 'one-way'. In this scenario, the Intranet forest would be termed 'Trusted' and the Extranet forest termed 'Trusting'.

So, what does this have to do with ISA then? Well, in addition to creating logical separation with forest boundaries, the model also normally includes some form of physical segmentation. This often results in the Extranet forest being placed into a perimeter network away from the internal network. In order to create this boundary and define the perimeter network, ISA Server is an ideal choice as the border firewall between these two security zones.

When you consider the communications that are required in order to support a forest trust, you will soon realise that you need a good application-layer firewall, ideally one that is able to inspect and control RPC traffic as this protocol is notoriously difficult to secure with most firewalls. If you combine this with the level of protection ISA Server can provide specifically for MOSS/WSS, it is not difficult to understand why ISA Server is often a key component in the overall security landscape for MOSS/WSS extranet solutions.

Obviously, I have over simplified things quite a bit and there are lots of other potential models (like the External Collaboration Toolkit for SharePoint for example) which could be used. However, a one-way forest trust model architetcure doesn't have to be just for extranets, they can pop up all over the place! You can also find a similar model in our old friend the Windows Server System Reference Architecture document set.

An overview of the architecture and concept being discussed is provided below:






So the the aim of this blog entry is to provide an overview of how to configure ISA Server to support this one-way forest trust architecture and define the necessary firewall policy rules and associated protocols to make it all work. This blog entry is by no means a 'ground up' walkthrough, but just gives a good overview of how ISA should be configured to allow for trust creation, validation and successful operation. In addition, I have tried to make my examples a little more generic by using a Web server, as opposed to SharePoint, but the overall concepts apply to lots of difference scenarios where a one-way forest trust is used across firewall boundaries.

One of the first things to realise with forest trusts is that they are not supported with Network Address Translation (NAT), hence your ISA Server will need a route relationship between the Extranet network and the Intranet network (or the other way around, as route relationships are bi-directional). Assuming this is in place, we now look at the necessary firewall policy rules to get it all working!

Like most security people, I like least privilege :-) Consequently, I will always create more firewall policy rules than are necessarily needed, just to ensure that we have sufficient granularity to provide a minimal set of communications by disabling certain rules that we don't need all the time.

A lot of the communications or protocols defined in this blog entry are based upon the following whitepaper and KB article. However, I found that these articles weren't clear enough in places and needed 'improving' based upon real-world findings from using ISA Server as part of the solution with customers.

As we have a route relationship between our networks, we gain little advantage of using ISA Server server publishing in this particluar example, and therefore all firewall policy rules are defined as access rules. The RPC filter is also one of the only application filters that works with access rules, so this makes the decision the correct one in my opinion.

Please Note: ISA Server SP1 now allows for RPC UUID filtering even when using access rules, which historically required server publishing to be used. With this change, RPC access rules are now as powerful as RPC server publishing rules, which is nice!. Consequently, it is possible to extend the current solution even further by defininig a specific list of UUIDs used for forest trusts. However, this is going to take a fair bit of testing, so I think I will leave it for a future blog post!

So, based upon the above, we can summarise the necessary firewall policies as follows:

  • AD Forest Trust: Allow Access for Forest Trust Creation/Validation
  • AD Forest Trust: Allow Access for Conditional DNS Forwarding
  • AD Forest Trust: Allow Access for Kerberos Client Authentication
  • AD Forest Trust: Allow Access for NTLM Client Authentication
  • AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)
  • AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)
  • AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

An overview of each rule is provided below:

AD Forest Trust: Allow Access for Forest Trust Creation/Validation

This rules allows the necessary communication required to initially setup and validate the trust relationship. Once the trust has been established, this rule can be disabled unless it is necessary to recreate/revalidate the trust for troubleshooting purposes. Following a least privilege approach, this step is strongly recommeneded for day-to-day operations.

AD Forest Trust: Allow Access for Conditional DNS Forwarding

This rule allows DNS servers in the Extranet forest to communication with DNS servers in the Intranet forest (and vice sersa). This is a based upon the use of conditional DNS forwarding which is needed to provide underlying name resolution services between the two AD environments.

Please Note: This is one of the few examples where using server publishing would have some security benefit as this would allow ISA Server to inspect and filter DNS as necessary. However, for this example an access rule is used for simplicity.

AD Forest Trust: Allow Access for Kerberos Client Authentication

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using Kerberos authentication. If Kerberos is not required, this rule is not required and should be disabled in order to adhere to least privilege.

AD Forest Trust: Allow Access for NTLM Client Authentication

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using NTLM authentication. It is very likely that this rule will need to remain enabled continuously and cannot be disabled, even in the event of using Kerberos.

AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)

This rule is needed to allow resources in the Intranet forest to be defined or 'picked' from the Extranet-Web server(s) themselves. For example within MOSS the object picker would be used to define SharePoint security permissions to a user or group in the Intranet forest. Without this rule, it will not be possible to select resources from the Intranet forest. Ideally this rule should be disabled most of the time and only enabled when adminiistrative changes are required.

AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)

This rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the Extranet Domain Controllers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

Again, this rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the ISA Servers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

So, now that we know what firewall polices are required to map the key communications required for everthing to function, we now need to look at the required policy objects in more detail. Before approaching this, it is worthwhile defining a few elements of the example environement that will be used as part of firewall policies:

Extranet-Web => Computer object for the Web server located in the Extranet forest. This would be running MOSS 2007 in our SharePoint analogy.

Extranet-DC1 => Computer object for the First Domain Controller in the Extranet forest.

Extranet-DC2 => Computer object for the Second Domain Controller in the Extranet forest

Intranet-DC1 => Computer object for the First Domain Controller in the Intranet forest.
Intranet-DC2 => Computer object for the Second Domain Controller in the Intranet forest.

Extranet Domain Controllers => Computer set for the Extranet Domain Controller computers.

Extranet Web Servers => Computer set for the Extranet Web server computers.

Intranet Domain Controllers => Computer set for the Intranet Domain Controller computers.

Internal Clients => Computer set to represent Intranet machines that are allowed access to the Extranet Web Servers. In reality, this may be all Intranet clients.

Based upon the firewall polices discussed above, the following pictures show a more detailed view of the rules including the necessary source, destination and protocol definitions for each set of communications (click to enlagre the pictures)


AD Forest Trust: Allow Access for Forest Trust Creation/Validation



AD Forest Trust: Allow Access for Conditional DNS Forwarding



AD Forest Trust: Allow Access for Kerberos Client Authentication



AD Forest Trust: Allow Access for NTLM Client Authentication



AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)



AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)



AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)


Please Note: Based upon real-world testing and experience it was necessary to add both UDP and TCP transports for some protocols in order to prevent the object picker from experiencing delays during Intranet resource browsing tasks. Without both transports, it often became quite painful to administer Intranet resources whilst waiting for components to timeout and use an alternative transport. It was also necessary to add the 'LDAP GC (Global Catalog)' to the object picker firewall policy rules for everything to function correctly, but this deosn't appear to be documented in any of the Microsoft documents I have seen.

So, that should be all you need to get the trust established and have a fully functioning one-way forest trust. With this platform in place, it is now possible to start using ISA Server web publishing to provide secure access to Extranet web services. If you got everything correct, users should be able to authenticate to ISA Server using either Intranet or Extranet forest credentials by way of the forest trust.

Friday, 13 June 2008

Publishing Certificate Revocation Lists with ISA Server 2006 - Part 2: Applying the HTTP Filter

Continuing on from Publishing Certificate Revocation Lists with ISA Server 2006 - Part 1: Creating the Publishing Rule this blog entry covers Part 2 which extends the existing publishing rule to include a more secure implementation of the HTTP filter configuration.

As discussed in a previous blog entry the use of the HTTP filter in this example introduces the concept of 'least privilige' to ensure that only the necessary HTTP protocol features are permitted by ISA Server in order to protect access to the CRLs located on the published web servers.

Using the example from Part 1 of this blog series, we can access the HTTP filter configuration by right-clicking on the Publish Certificate Revocation List rule and selecting the Configure HTTP option from the context menu.

Using the guidance provided in the Micorosft article titled HTTP Filtering in ISA Server 2004 it is possible to apply a Baseline Web Publishing HTTP Policy as a starting point. Once this policy has been applied, and tested, we can then modify additional HTTP parameters to further control/restrict the level of security provided by the filter.

The Baseline Web Publishing HTTP Policy provided by Microsoft in the above article is shown below in HTTP Policy XML format:

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="true" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="260" MaxQueryLength="4096"><Extensions AllowCondition="2"><Extension Value=".exe" Description=""/><Extension Value=".bat" Description=""/><Extension Value=".cmd" Description=""/><Extension Value=".com" Description=""/><Extension Value=".htw" Description=""/><Extension Value=".ida" Description=""/><Extension Value=".idq" Description=""/><Extension Value=".htr" Description=""/><Extension Value=".idc" Description=""/><Extension Value=".shtm" Description=""/><Extension Value=".shtml" Description=""/><Extension Value=".stm" Description=""/><Extension Value=".printer" Description=""/><Extension Value=".ini" Description=""/><Extension Value=".log" Description=""/><Extension Value=".pol" Description=""/><Extension Value=".dat" Description=""/></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="GET" Description=""/><Verb Value="HEAD" Description=""/><Verb Value="POST" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures><Signature Name=".." Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[..]" FormatIsText="true" Enabled="true"/><Signature Name="./" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[./]" FormatIsText="true" Enabled="true"/><Signature Name="\" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[\]" FormatIsText="true" Enabled="true"/><Signature Name=":" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[:]" FormatIsText="true" Enabled="true"/><Signature Name="%" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[%]" FormatIsText="true" Enabled="true"/><Signature Name="&amp;" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[&amp;]" FormatIsText="true" Enabled="true"/></DeniedSignatures></Configuration>

This can be applied in the same way as covered in the
previous blog entry using the HTTPFilterConfig.vbs script.

Using the baseline policy as a starting point, this can be extended to further restrict the following General features:

  • Block high bit characters
  • Block responses containing Windows executable content

The resulting configuration is shown below:

Using the baseline policy as a starting point, this can be extended to further restrict the Methods to:

  • GET

The resulting configuration is shown below:

Using the baseline policy as a starting point, this can be extended to further restrict Extensions to:

  • .crl
  • Block requests containing ambiguous extensions

The resulting configuration is shown below:

Using the baseline policy as a starting point, the default baseline list of blocked signatures can remain as shown below:

Based upon the parameters defined in the above HTTP filter parameters, it is therefore possible to define a HTTPFilterConfig XML policy as follows:

CRL HTTP Filter XML Policy

<Configuration BlockExecutables="true" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="true" AllowHighBitCharacters="false" BlockDotInPath="true" MaxLength="260" MaxQueryLength="4096"><Extensions AllowCondition="1"><Extension Value=".crl" Description=""/></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="GET" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures><Signature Name=".." Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[..]" FormatIsText="true" Enabled="true"/><Signature Name="./" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[./]" FormatIsText="true" Enabled="true"/><Signature Name="\" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[\]" FormatIsText="true" Enabled="true"/><Signature Name=":" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[:]" FormatIsText="true" Enabled="true"/><Signature Name="%" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[%]" FormatIsText="true" Enabled="true"/><Signature Name="&amp;" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[&amp;]" FormatIsText="true" Enabled="true"/></DeniedSignatures></Configuration>

This can be applied as discussed in a previous blog entry using the HTTPFilterConfig.vbs script.

I hope you have enjoyed these two blog entries and have a better understanding of publishing and protecting CRL web servers with ISA Server.

Publishing Certificate Revocation Lists with ISA Server 2006 - Part 1: Creating the Publishing Rule

More and more applications are beginning to include some form of Public Key Infrastructure (PKI) requirements as part of the core infrastructure dependencies. Based upon this drive, more customers are now beginning to consider PKI as a core infrastructure component in the same way as services like Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) services. Therefore, having some form of PKI, or certificate service, is a growing need for most environments that I encounter. PKI is one those areas where it is perceived as a 'scary' technology area which contains a lot of new concepts for most people and a fair share of new acronyms to learn!

The aim of this blog entry is not to explain PKI concepts, but to provide detail about how to use ISA Server to protect one important aspect of any PKI implementation; namely external access to Certificate Revocation Lists (CRLs).

CRLs are a key foundation of most PKI implementations and serve a critical purpose of maintaining a list of all certificates that have been revoked. Unlike Active Directory, which is able to determine dynamically at logon point whether a user account has been disabled, a similar mechanism hadn't really existed in the PKI world until the introduction of the Online Certificate Status Protocol (OCSP), but this has not been available natively within Microsoft Certificate Services until Windows Server 2008.

The process of revoking a certificate is similar to disabling a user account, such that you are expressing that this entity is no longer trusted, and consequently cannot be used to authenticate, sign or be trusted for identification. In order for a user, client or application to validate that a certificate has not been revoked, and consequently is still a valid, trustworthy entity, it is necessary to contact an appropriate CRL to determine this.

Form an internal perspective, access to the CRLs is often overlooked as 'it just works', especially as most deployments will include some form of Active Directory integration which provide a CRL access method based upon LDAP. However, access to the CRL for Internet-connected systems is becoming increasingly more important.

Rather than re-invent the PKI wheel, I am going to rely on Microsoft's Windows Server System Reference Architecture (WSSRA) documentation to provide an excellent blueprint for a well designed PKI example that is based on Windows Server 2003 Certificate Services.

Looking at this design, it can be seen that access to CRLs for the 'Internet scenario' is fully supported and includes the following features:

  • CRLs will be located on Web servers which are Internet facing.
  • CRLs will be accessed using the HTTP retrieval protocol.
  • CRLs will be accessed using an external URL of http://dp1.pki.contoso.com/pki

Please Note: To make things a little simpler for the purposes of this blog entry, and follow my own best practice, the URL used for CRLs will be changed to http://pki.msfirewall.org.uk/pki within the examples and walkthroughs.

So, based upon the above scenario we can now look at how to provide secure access to the CRL web servers using ISA Server. After all that talking, we can now get to the point of this blog entry, namely to provide an ISA Server web publishing walkthrough!

Using the ISA Server management console, select the Publish Web Sites task from the Firewall Policy Tasks pane.

Provide a suitable rule name, I have used Publish Certificate Revlocations Lists as shown below:

Select Allow

Select Publish a single Web site of load balancer. Alternativelly, if you plan to have several web servers hosting the CRLs select the Publish a server farm of load balanced Web servers option.

Select Use non-secured connections to connect to the published Web server or server farm

In the Internal site name field, enter the Fully Qualified Domain Name(FQDN) of the web server that hosts the CRLs. If this name is not fully resolveable by ISA Server, you will need to add the correct computer name or IP address in the second input field.

At this stage, leave the Path (optional) input field blank; we will amend this part of the rule later.

Enter the external FQDN which will be included within the CRL field of issued certificates. Using the WSSRA example, this would be dp1.pki.contoso.com, however in our example this is pki.msfirewall.org.uk

On the Select Web Listener page, click New...

Enter an appropraite name for the web listener. I have used CRL Listener (Internet Anonymous)

Select Do not require SSL secured connections with clients

Tick the External network and then click Select IP Addresses...

Please Note: If you are using a Single Network Adapter ISA Server (unihomed) you will need to select the Internal network object, as opposed to the External network object.

Select Specified IP addresses on the ISA Server computer in the selected network and then choose the appropriate available IP address followed by Add >

Select No Authentication from the drop down box.

Click Next when returned to the Select Web Listener page and ensure that the Web listener drop down box shows CRL Listener (Internet Anonymous) listener, or the alternate name used during creation.

Select No delegation, and client cannot authenticate directly

Click Next

Click Finish to complete the New Web Publishing Rule Wizard

Once complete, you should have a newly created rule in your Firewall Policy window.

Highlight the newly create rule and right-click to select Properties, followed by the Paths tab. As can be seen below, I have manully defined the Internal Path as /pki/* based upon the assumption that the pki virtual directory only contains CRL files.

However, if this is not the case, it is recommended to modify the paths entries to reference individual files, as opposed to all files in the pki virtual directory. An example of this is shown below using specific entries for the required CRL files.

Correcttion! - The internal path in the screenshot above should be /issuingca+.crl and not /issuingca.crl+. I will correct the screenshot in due course.

Both options will work equally as well, but in the event that the pki virtual directory contains files which you do not want to be published, then it is recommended to use specific file name entries to provide better security.

Once the paths entry has been defined, all that needs to be done is click OK and then apply the changes using the Apply button located above the firewall policy, to commit the new rule.

In order to test access to the CRLs, you can type the full CRL address directly into your web browser (e.g. http://pki.msfirewall.org.uk/pki/rootca.crl) and you should be prompted with an option to open or save the CRL file.

With a working rule in place, we will look at providing more advanced security in Part 2 with the addition of the HTTP filter, which I am quite keen on if you hadn't gathered by now!

Wednesday, 11 June 2008

HTTP Filter Settings for Microsoft Office SharePoint Server (MOSS) 2007

Following on from the HTTP Filter Settings for Microsoft Exchange Server 2007 blog entry it is possible to apply the same theory to other web-based applications. A common example for this is Microsoft Office SharePoint Server (MOSS) 2007 which can benefit from the same HTTP filter security advantages as Exchange 2007 when published behind ISA Server.

Again, by looking at the the policies defined within the default application optimisers of Microsoft Intelligent Application Gateway 2007 (which are supported) it is possible to determine that the following HTTP methods allow list should be sufficient for correct MOSS 2007 operation:

  • PROPFIND
  • OPTIONS
  • HEAD
  • POST
  • GET

Based upon the parameters defined in the above allow list, it is therefore possible to define a HTTPFilterConfig XML policy as follows:

MOSS HTTP Filter XML Policy

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="false" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="10240" MaxQueryLength="10240"><Extensions AllowCondition="0"></Extensions></UrlValidation><Verbs AllowCondition="1">tion=""/><Verb Value="PROPFIND" Description=""/><Verb Value="OPTIONS" Description=""/><Verb Value="HEAD" Description=""/><Verb Value="POST" Description=""/><Verb Value="GET" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures></DeniedSignatures></Configuration>

You simply need to copy and paste the above text into notepad and save the file as MOSS2007Policy.xml or something similarly descriptive.

Once applied (using the same HTTPFilterConfig.vbs script as described
previously) the HTTP filter configuration can be viewed by right-clicking on the respective firewall policy rule defined during the HTTPFilterConfig import and selecting the Configure HTTP option. If imported correctly, you should see the following:

HTTP Methods for MOSS 2007


Keep posted for further articles on troubleshooting the HTTP Filter, once it has been configured...

Tuesday, 10 June 2008

Using CMAK to Configure ISA Server VPN Clients - Part 2: Customising the CMAK Profile

Following on from Using CMAK to Configure ISA Server VPN Clients - Part 1: Creating the CMAK Profle this blog entry is part two of the series and will look at customising the profile to add some useful features, cater for a better user experience and improve security. This blog entry assumes that Part 1 has already been followed and the CMAK profile has been created.

In this entry I am going to discsuss the following CMAK profile customisations:


  • Modify the intial connection screen to hide unwanted and insecure elements.
  • Modify the support information to add a CMAK build number to aid versioning and troubleshooting.

  • Modify the Windows client to add support for NAT traversal (NAT-T) and facilitate ISA Server VPN gateways behind NAT devices.

  • Include custom login and logout scripts to provide VPN users with mapped drives whilst the VPN connection is active.
Although it is possible to use the CMAK wizard to make many different customisations, like adding graphics etc., these are pretty standard options and avaibale as part of the normal wizard driven process. The customisations defined in this blog entry are slightly more advanced, and in my opinion greatly improve the experience for frequent VPN users.

Modify the intial connection screen to hide unwanted and insecure elements

The connection screen can be modified by editing the [ShortSvcName].cms file located by default in the C:\Program Files\cmak\Profiles\[ShortSvcName] folder, where [ShortSVCName] is the File name parameter defined in part one of this blog series (ISAVPN in the screenshot examples).

Using our CMAK profile from Part one as an example, we need to edit the ISAVPN.cms file, as shown below:




For the scenario where we are using a simple Windows user name and passord, we will need to leave the default username, password and domain fields. However, it seems sensible to remove the Save password option to ensure that the user cannot select this feature. This is achieved by adding a HideRememberPassword=1 entry to the [Connection Manager] section of the ISAVPN.cms file as shown below:




Once these changes have been made, it is necessary to re-run the CMAK wizard without making any changes. This will re-read the manually modified ISAVPN.cms file and add the modifications to the self-extracting executable ISAVPN.exe. Once the updated connectoid has been installed, the connections screen result is shown below without the Save password option.



For the scenario where we are using certificates, we will no longer need to display the default username and domain fields as this information is stored within the Univeral Principal Name (UPN) of the certificate. In addition, the Save password option is not relevant in this particular scenario. These modifications are achieved by adding/editing the following entries in the [Connection Manager] section of the ISAVPN.cms file, as shown below:

HideDomain=1
HidePassword=1
HideInternetPassword=1
HideUserName=1
HideInternetUsername=1



Once these changes have been made, it is necessary to re-run the CMAK wizard without making any changes. This will re-read the manually modified ISAVPN.cms file and add the modifications to the self-extracting executable ISAVPN.exe. Once the updated connectoid has been installed, the connections screen result is shown below without the unnecessary fields.



Althouth not strictly necessary, in addition to the changes above, I also recommend modifying the default value for the ConnectionType entry in the [Connection Manager] section of the ISAVPN.cms file from 0 to 1 as shown below. This modification ensures that the connectoid will default to I am already connected to the Internet as oppsoed to Dial a phone number to connect option; which for a majority of cases is the correct option.



Modify the support information to add a CMAK build number to aid versioning and troubleshooting

This is a simple, yet effective, modification that allows you to determine the exact version of connectoid installed on a client machine. Over time, it is possible that the CMAK profile will be mofidied, or extended, to include new features, reflect infrastructure changes or simply fix problems. However, it is not always possible to ensure that all users are using the latest version of the CMAK profile, which can lead to inconsistent results between users. Consequently, by adding a CMAK build number to the Support Information field, this will allow users to provide this information, or assess whether they are running the latest profile themselves. I tend to use a build number that is a representation of the creation date e.g. 100508 would indicate a profile created on the 10th May 2008. An example of this modification is shown below using the Support Information page as part of the CMAK wizard.



Modify the Windows client to add support for NAT-T and facilitate ISA Server VPN gateways behind NAT devices

If your ISA VPN Server is located behind a NAT device, you may experience problems connecting the VPN as discussed in the following Microsoft KB articles:

L2TP/IPsec NAT-T update for Windows XP and Windows 2000 (KB926179)

How to configure an L2TP/IPsec server behind a NAT-T device in Windows Vista and in Windows Server 2008 (KB818043)

The common solution to both of these problems is to add a specific registry entry to the VPN client machine. These registry keys are:

For Vista:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule

For Windows XP:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec\AssumeUDPEncapsulationContextOnSendRule

Normally a value of 2 would be used for this entry to ensure the higest level of compatability for both NAT hidden client and servers.

Rather than having to add these registry entries manually, it makes much more sence to add these entries as part of the CMAK profile installation. This can be achieved by adding the following lines to the [Xnstall.AddReg.AllUsers] and [Xnstall.AddReg.Private] sections of the [ShortSvcName].inf file included as part of the profile.

"HKLM", "SYSTEM\CurrentControlSet\Services\IPSec", "AssumeUDPEncapsulationContextOnSendRule", 0x00010001,2

"HKLM", "SYSTEM\CurrentControlSet\Services\PolicyAgent", "AssumeUDPEncapsulationContextOnSendRule", 0x00010001,2

In our example, this will be ISAVPN.inf as shown below:

[Xnstall.AddReg.AllUsers] section of ISAVPN.inf


[Xnstall.AddReg.Private] section of ISAVPN.inf


Please Note: In order to add these registry keys, the user will require local administration rights or will need to utilise the Run As option when you install the CMAK profile.

As can be seen from the images above, I have added both Vista and Windows XP registry changes to the single ISAVPN.inf file, as I don't think it is possible to interpret the client OS and apply the appropriate entry automatically. This ensures that both operating system versions will have the correct registry entry, plus an unnecessary entry, which seems like an acceptable compromise to me.

Once these changes have been made, it is necessary to re-run the CMAK wizard without making any changes. This will re-read the manually modified ISAVPN.inf file and add the modifications to the self-extracting executable ISAVPN.exe. Once the updated connectoid has been installed, it is necessary to reboot the client machine for the registry changes to take affect.

Include custom login and logout scripts to provide VPN users with mapped drives whilst the VPN connection is active

The final customisation, and potentially the most visible to the VPN user, is to provide a login script which dynamically map drives once the VPN connection is active and removes them upon disconnetion.

The theory provided here can be used to run any script process and could easily be adapted to include more advanced features than mapping drives, as the concept will be the same.

This concept is based around the Custom Actions element of the CMAK wizard and is probably one of the most powerful elements of CMAK as it can be used to perform tasks (or actions) based upon VPN conditions like Pre-connect, Post-connect, Disconnect etc.

In my example we use the Post-connect condition to trigger a Run VPN Login Script task and the Disconnect condition to trigger a Run VPN Logout Script task, as shown below:

If we look a little closer at these tasks we can see that the each action includes Program to run and an Action type elements. As the files will be deployed by CMAK, the program path will need to be presented as a vairable-based service profile path as shown below:

It cannot be easily seen in the above, but the program path needs to be of the following format:

%APPDATA%\Microsoft\Network\Connections\Cm\[ShortSvcName]\[Program Filename]

In our ISAVPN example, this would threfore become:

%APPDATA%\Microsoft\Network\Connections\Cm\ISAVPN\VPNLogin.vbs

So with the configuration shown above, the VPNLogin.vbs file will be run once the VPN has been connected.

In a simar way for our second custom action:


In our ISAVPN example, this would therefore become:

%APPDATA%\Microsoft\Network\Connections\Cm\ISAVPN\VPNLogout.vbs

So with the configuration shown above, the VPNLogout.vbs file will be run once the VPN has been disconnected.


Please Note: It is worth noting that server names should ideally be included as Fully Qualified Domain Names (FQDNs) within the .vbs files to force DNS name resolution and avoid the use of WINS.

The only remaining element is to ensure that the actual VPNLogin.vbs and VPNLogout.vbs files are included within the Additional Files element of the CMAK wizard as shown below. However, this can also be achieved if you use the Include the custom action program with this service profile option in the custom actions images shown above.

I hope you have enjoyed these two blog entries and have discovered the power of CMAK! I will probably add more CMAK customisations in the future, as I develop new ones for customers.

HTTP Filter Settings for Microsoft Exchange Server 2007

One of the key benefits of ISA Server web publishing is the ability to use the HTTP filter to provide advanced security for web-based applications by defining very specific allow lists (whitelists) or deny lists (blacklists) for key HTTP elements like methods (verbs), extensions and signatures. This filter is very similar to the URLscan tool which was recommended for IIS, but it can be applied on a per-rule basis as opposed to per-system. The use of the HTTP filter in this example introduces the concept of 'least privilige' to ensure that only the necessary HTTP methods that are required by Exchnage 2007 are permitted.

With Exchange 2003, Microsoft released a
whitepaper which provided specific details of how to use the HTTP filter for securing Exchange 2003 services like Outlook Web Access, RPC/HTTP, ActiveSync etc. However, since the release of Exchange 2007 this whitepaper does not appear to have been updated or a replacement published. As Microsoft has not provided this information in an official document, I have been wary to utilise the existing HTTP filter parameters for customer deployments, just in case they have an adverse effect on functionality.

However, by looking at the the policies defined within the default application optimisers of Microsoft Intelligent Application Gateway 2007 (which are supported) it is possible to determine that the following HTTP methods allow list should be sufficient for correct Exchange 2007 operation:


Outlook Web Access (OWA) - HTTP Methods Allow List

  • BCOPY
  • BDELETE
  • BMOVE
  • BPROPPATCH
  • COPY
  • DELETE
  • GET
  • HEAD
  • LOCK
  • MKCOL
  • MOVE
  • OPTIONS
  • POLL
  • POST
  • PROPFIND
  • PROPPATCH
  • PUT
  • SEARCH
  • SUBSCRIBE
Exchange ActiveSync (EAS) - HTTP Methods Allow List

  • OPTIONS
  • POST
  • GET

HTTPFilterConfig.vbs is a free script provided by Microsoft on the ISA Server CD, located in the \sdk\samples\admin folder. This script can be used to import HTTP filter settings from custom XML files and assign them to individual firewall policy rules. Once a HTTP filter settings XML file has been created, it can then be imported using the following syntax:

HTTPFilterConfig.vbs import RuleName HTTPPolicyXmlFileName.xml

Based upon the parameters defined in the above allow lists, it is therefore possible to define HTTPFilterConfig XML policies as follows:

OWA HTTP Filter XML Policy

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="false" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="10240" MaxQueryLength="10240"><Extensions AllowCondition="0"></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="BCOPY" Description=""/><Verb Value="BDELETE" Description=""/><Verb Value="BMOVE" Description=""/><Verb Value="BPROPPATCH" Description=""/><Verb Value="COPY" Description=""/><Verb Value="DELETE" Description=""/><Verb Value="GET" Description=""/><Verb Value="HEAD" Description=""/><Verb Value="LOCK" Description=""/><Verb Value="MKCOL" Description=""/><Verb Value="MOVE" Description=""/><Verb Value="OPTIONS" Description=""/><Verb Value="POLL" Description=""/><Verb Value="POST" Description=""/><Verb Value="PROPFIND" Description=""/><Verb Value="PROPPATCH" Description=""/><Verb Value="PUT" Description=""/><Verb Value="SEARCH" Description=""/><Verb Value="SUBSCRIBE" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures></DeniedSignatures></Configuration>

You simply need to copy and paste the above text into notepad and save the file as Exchange2007OWAPolicy.xml or something similarly descriptive.

EAS HTTP Filter XML Policy

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="false" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="10240" MaxQueryLength="10240"><Extensions AllowCondition="0"></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="OPTIONS" Description=""/><Verb Value="POST" Description=""/><Verb Value="GET" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures></DeniedSignatures></Configuration>

You simply need to copy and paste the above text into notepad and save the file as Exchange2007EASPolicy.xml or something similarly descriptive.

Once applied, the HTTP filter configuration can be viewed by right-clicking on the respective firewall policy rule defined during the HTTPFilterConfig import and selecting the Configure HTTP option. If imported correctly, you should see the following:

HTTP Methods for OWA


HTTP Methods for EAS


Additional information on HTTP filtering which applies to both ISA Server 2004 and 2006 can be found here.

Keep posted for further articles on using the HTTP Filter for other applications like Microsoft Office SharePoint Server (MOSS) 2007 amongst others...

Using CMAK to Configure ISA Server VPN Clients - Part 1: Creating the CMAK Profile

Amongst the many benefits of using ISA Server as your VPN gateway, a key attribute is the fact that the VPN client software is built into Windows which negates the need to install any third-party VPN client. The VPN connection can easily be configured within Windows using the New Connection Wizard, however I have always preferred the more elegant solution of using the Connection Manager Administration Kit (CMAK). This is a free tool included with Windows Server 2003 which can be used to create a CMAK profile (connectoid) that contains all of the the VPN connection properties, including a whole heap of customisation to make life easier and more intuitive for for users.

This blog entry is the first of a two part series which provides a walkthrough of creating a CMAK profile which can be used for connecting to an ISA Server VPN gateway. Once the CMAK profile has been created, part two of the series will look at customising the profile to add some useful features, cater for a better user experience and improve security. The blog entry assumes that the VPN feature of ISA Server has already been enabled and the L2TP/IPSec protocol has been enabled.

CMAK can be installed using the Add or Remove Programs control panel applet and is included under the Add/Remove Windows Components, Management and Monitoring Tools component.

Please Note: I have omitted wizard steps that can remain at their default settings to reduce the number of screenshots. Steps that are not included below can simply be accepted using the Next button.

Once opened, the wizard begins as shown below:

On the Service and File Names page, enter the desired Service Name and File name (this is also called the Short Service Name):



On the VPN Entries page, click the Edit button:


Select the Security tab on the Edit Virtual Private Networking Entry window and then change the Security Settings drop down selection to Use advanced security settings:


Once selected, click Configure next to the Advanced security settings text.

If you are planning on using a simple authentication method comprising of a Windows user name and password, configure the Advanced Security Settings options as shown below.


These settings represent a baseline level of security for the VPN connection, but does not represent a high security or recommended deployment. In terms of authentication, many organisations require that VPN connections are subject to some form of two-factor authentication to mitigate the risks of static user names and passwords. In addition, although it is possible to choose the Only use Point to Point Tunneling Protocol (PPTP) option, I would no longer recommend using this method as many security/penetration tests now highlight PPTP as a poor VPN solution in terms of security. As we are using simple authentication, we are unlikely to be able to provide certificates for L2TP, so we need to use enable the Use a pre-shared key when using L2TP/IPSec option in this scenario.

If you are lucky enough to be able to provision certificates (due to the use of an internal Public Key Infrastructure (PKI) deployment perhaps) then the following Advanced Security Settings options are recommended as a more secure alternative to the above:


In this scenario, we are using certificates to enable user and machine authentication for the VPN connection, as this provides a much higher level of security. It is outside the scope of this entry to provide specific details of the necessary PKI infrastructure and certificates that are required, but if you would like to see these details, please leave comments and I will try and add more detail in future blog entries.

Please Note: In addition to these two options, it is also possible to integrate third-party authentication solution into CMAK. From personal experience, I have also used RSA SecurID which integrates well (after a little work!) to provide a seamless solution. More information on this option can be found here.

If you have chosen to define a pre-share key for L2TP/IPSec then the Pre-shared Key page will be displayed. Enter the required pre-share key into the Enter key field. In order to protect the key and ensure it is encrypted in the CMAK profile files, is it recommended to choose the Encrypt the pre-share key with a PIN option. Once enabled, this PIN will need to be entered by any user that wishes to install the CMAK profile (example of this later).

On the Phone Book page, deselect the Automatically download phone book updates as this is not required.


This final step of the completed wizard is shown below:


With the wizard completed, it is simply a matter of distributing the CMAK self-installing executable (defined in the path above) to users.

Once users receive the file, they can simply run the executable to receive the following prompt shown below. Click Yes to install the CMAK profile.


If you chose the Encrypt the pre-share key with a PIN option during the wizard, you will be asked to enter the PIN. Entering an incorrect PIN will cause the installation to terminate.

On the next step, I would recommend selecting the My use only option.


Once installed, a new Connection Manager pane will be shown within Network Connections (example shown below from Windows XP) which contains the new 'ISA Server VPN' VPN connectoid.



After successful installation, the VPN connection will also be initiated/connected and you will be presented with the following connection:



You will notice that the Save password option is enabled by default. For obvious reasons, this
represents a security risk which we will cover in the next blog entry.

So, we now have a basic CMAK profile defined and the VPN connectoid has been installed which provides a good platform for part two of this blog series. In part two, we will look at customising the CMAK profile to include some advanced features, add support for ISA Server VPN gateways behind NAT devices and improve security by disabling features like the Save password option shown above...

Additional information on the Connection Manager Administration Kit (CMAK) can be found here.