Archive

Author Archive

Further details and guidance regarding discontinuation of TMG Web Protection Services

December 15th, 2015 No comments

As discussed in the following blog, the Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015:-

http://blogs.technet.com/b/applicationproxyblog/archive/2015/11/02/important-reminder-for-forefront-threat-management-gateway-tmg-web-protection-services-customers.aspx

We wanted to provide some additional details on what this will affect and recommendations on actions you should be taking.

The services that will be affected by this are:-

– URL Categorization
– Malware Inspection

Importantly, the Microsoft Reputation Services that supports URL Filtering will be turned off on or shortly after the 31st December 2015.

To avoid service impacting issues due to these services no longer being available, or incorrect rule processing where rules rely on URL Categorization categories, we would strongly advise customers review and amend their TMG configurations as follows:-

Review and amend any rules based on URL Categorization categories in your TMG policy

Any Allow and Deny rules that currently use URL Categories or URL Category Sets must be changed to remove the usage of URL filtering categories.

Using URL Sets or Domain Name Sets may provide limited replacement functionality or you may also want to consider a 3rd party URL filtering plug-in or upstream proxy service to provide replacement URL filtering functionality.

Note – If you have rules that are using URL filtering to allow traffic – HTTP traffic can be totally blocked after the service shutdown. Equally, if you use URL Filtering to block access to certain categories then these may be allowed after the change. There is also a possibility that performance issues will be seen if URL Filtering is left enabled after the MRS service is taken offline.

Disable URL Filtering

After amending your TMG policy ensure you then disable URL Filtering. This can be done in the TMG Management Console in the Web Access Policy node by selecting URL Filtering and unchecking the “Enable URL Filtering” check-box. This is essential to avoid TMG trying to contact the MRS services after they go offline.

clip_image002

Malware Inspection may continue to work but would not receive updated signatures

We would recommend implementing an alternative Anti-Virus solution and to disable Malware Inspection once this is in place.

As noted in the previous blog, Forefront Threat Management Gateway 2010, remains under extended support until April 14, 2020.

For details on moving from TMG to our new web publishing solutions please visit this URL:

http://blogs.technet.com/b/applicationproxyblog/archive/2015/07/02/transitioning-to-application-proxy-from-uag-and-tmg.aspx

Some Frequently Asked Questions we’ve had regarding the change are:-

Q1. Is it possible to use the MRS Cache to continue to benefit from URL Filtering after 31st December 2015?

A1. No, the MRS cache is a temporary in-memory cache of the latest lookups intended to provide internal efficiency optimizations. It does not provide a full offline cache and cannot be used for this purpose. There is no mechanism to have an offline database.

Q2. Is it possible to extend our usage of Forefront Threat Management Gateway (TMG) Web Protection Services past 31st December 2015?

A2. No, this is not possible. These dates were announced in September 2012 in order to provide sufficient time for alternative solutions to be deployed.

For the original announcement of the Forefront product roadmap changes please refer to the following URL:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Categories: EMP, malware inspection, TMG, URL filtering, URLF Tags:

Further details and guidance regarding discontinuation of TMG Web Protection Services

December 15th, 2015 No comments

As discussed in the following blog, the Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015:-

http://blogs.technet.com/b/applicationproxyblog/archive/2015/11/02/important-reminder-for-forefront-threat-management-gateway-tmg-web-protection-services-customers.aspx

We wanted to provide some additional details on what this will affect and recommendations on actions you should be taking.

The services that will be affected by this are:-

– URL Categorization
– Malware Inspection

Importantly, the Microsoft Reputation Services that supports URL Filtering will be turned off on or shortly after the 31st December 2015.

To avoid service impacting issues due to these services no longer being available, or incorrect rule processing where rules rely on URL Categorization categories, we would strongly advise customers review and amend their TMG configurations as follows:-

Review and amend any rules based on URL Categorization categories in your TMG policy

Any Allow and Deny rules that currently use URL Categories or URL Category Sets must be changed to remove the usage of URL filtering categories.

Using URL Sets or Domain Name Sets may provide limited replacement functionality or you may also want to consider a 3rd party URL filtering plug-in or upstream proxy service to provide replacement URL filtering functionality.

Note – If you have rules that are using URL filtering to allow traffic – HTTP traffic can be totally blocked after the service shutdown. Equally, if you use URL Filtering to block access to certain categories then these may be allowed after the change. There is also a possibility that performance issues will be seen if URL Filtering is left enabled after the MRS service is taken offline.

Disable URL Filtering

After amending your TMG policy ensure you then disable URL Filtering. This can be done in the TMG Management Console in the Web Access Policy node by selecting URL Filtering and unchecking the “Enable URL Filtering” check-box. This is essential to avoid TMG trying to contact the MRS services after they go offline.

clip_image002

Malware Inspection may continue to work but would not receive updated signatures

We would recommend implementing an alternative Anti-Virus solution and to disable Malware Inspection once this is in place.

As noted in the previous blog, Forefront Threat Management Gateway 2010, remains under extended support until April 14, 2020.

For details on moving from TMG to our new web publishing solutions please visit this URL:

http://blogs.technet.com/b/applicationproxyblog/archive/2015/07/02/transitioning-to-application-proxy-from-uag-and-tmg.aspx

Some Frequently Asked Questions we’ve had regarding the change are:-

Q1. Is it possible to use the MRS Cache to continue to benefit from URL Filtering after 31st December 2015?

A1. No, the MRS cache is a temporary in-memory cache of the latest lookups intended to provide internal efficiency optimizations. It does not provide a full offline cache and cannot be used for this purpose. There is no mechanism to have an offline database.

Q2. Is it possible to extend our usage of Forefront Threat Management Gateway (TMG) Web Protection Services past 31st December 2015?

A2. No, this is not possible. These dates were announced in September 2012 in order to provide sufficient time for alternative solutions to be deployed.

For the original announcement of the Forefront product roadmap changes please refer to the following URL:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Categories: EMP, malware inspection, TMG, URL filtering, URLF Tags:

Further details and guidance regarding discontinuation of TMG Web Protection Services

December 15th, 2015 No comments

As discussed in the following blog, the Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015:-

http://blogs.technet.com/b/applicationproxyblog/archive/2015/11/02/important-reminder-for-forefront-threat-management-gateway-tmg-web-protection-services-customers.aspx

We wanted to provide some additional details on what this will affect and recommendations on actions you should be taking.

The services that will be affected by this are:-

– URL Categorization
– Malware Inspection

Importantly, the Microsoft Reputation Services that supports URL Filtering will be turned off on or shortly after the 31st December 2015.

To avoid service impacting issues due to these services no longer being available, or incorrect rule processing where rules rely on URL Categorization categories, we would strongly advise customers review and amend their TMG configurations as follows:-

Review and amend any rules based on URL Categorization categories in your TMG policy

Any Allow and Deny rules that currently use URL Categories or URL Category Sets must be changed to remove the usage of URL filtering categories.

Using URL Sets or Domain Name Sets may provide limited replacement functionality or you may also want to consider a 3rd party URL filtering plug-in or upstream proxy service to provide replacement URL filtering functionality.

Note – If you have rules that are using URL filtering to allow traffic – HTTP traffic can be totally blocked after the service shutdown. Equally, if you use URL Filtering to block access to certain categories then these may be allowed after the change. There is also a possibility that performance issues will be seen if URL Filtering is left enabled after the MRS service is taken offline.

Disable URL Filtering

After amending your TMG policy ensure you then disable URL Filtering. This can be done in the TMG Management Console in the Web Access Policy node by selecting URL Filtering and unchecking the “Enable URL Filtering” check-box. This is essential to avoid TMG trying to contact the MRS services after they go offline.

clip_image002

Malware Inspection may continue to work but would not receive updated signatures

We would recommend implementing an alternative Anti-Virus solution and to disable Malware Inspection once this is in place.

As noted in the previous blog, Forefront Threat Management Gateway 2010, remains under extended support until April 14, 2020.

For details on moving from TMG to our new web publishing solutions please visit this URL:

http://blogs.technet.com/b/applicationproxyblog/archive/2015/07/02/transitioning-to-application-proxy-from-uag-and-tmg.aspx

Some Frequently Asked Questions we’ve had regarding the change are:-

Q1. Is it possible to use the MRS Cache to continue to benefit from URL Filtering after 31st December 2015?

A1. No, the MRS cache is a temporary in-memory cache of the latest lookups intended to provide internal efficiency optimizations. It does not provide a full offline cache and cannot be used for this purpose. There is no mechanism to have an offline database.

Q2. Is it possible to extend our usage of Forefront Threat Management Gateway (TMG) Web Protection Services past 31st December 2015?

A2. No, this is not possible. These dates were announced in September 2012 in order to provide sufficient time for alternative solutions to be deployed.

For the original announcement of the Forefront product roadmap changes please refer to the following URL:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Categories: EMP, malware inspection, TMG, URL filtering, URLF Tags:

Missing BDA hook rules – impact and potential root cause

September 18th, 2014 No comments

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

clip_image001

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

clip_image002

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

clip_image003

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Categories: NLB, TMG Tags:

Missing BDA hook rules – impact and potential root cause

September 18th, 2014 No comments

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

clip_image001

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

clip_image002

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

clip_image003

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Categories: NLB, TMG Tags:

Missing BDA hook rules – impact and potential root cause

September 18th, 2014 No comments

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

clip_image001

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

clip_image002

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

clip_image003

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Categories: NLB, TMG Tags:

How to create a CNG HTTPSi cert using a 2008r2 CA

August 29th, 2014 No comments

In a previous article we explained how to create a self-signed CNG certificate, suitable for the HTTPS Inspection feature, which can be used to inspect sites using an SHA-256 certificate.

In this article we will explain how to generate a similar certificate using your internal CA based on Windows 2008 R2.

Using a certificate issued by your own CA, rather than a self-signed certificate, has the advantage that you will not have an additional certificate to distribute to the web proxy clients.
Bearing in mind that certificates have a limited validity period and that this eases operation maintenances, since you need only to change only the Subordinate CA certificate on TMG.

Arguably it can be said that if you set a validity period long enough, as some tenth of years, this would not be an issue.
But the truth is that what is considered secure today, might be easily compromised in a couple of years and for that reason, having an easy way to replace your certificates also improves your overall security.
The ability to quickly move to a larger key length or better hash algorithm at any time is the key to an always up to date and secure PKI infrastructure.

Now let's go ahead and create the certificate.
Begin by opening the Certificate Authority administration console, right click on Certificate Templates then Manage.

clip_image001

First step is duplicating the “Subordinate Certification Authority” template.

clip_image003

In Compatibility settings select Windows Server 2008:

clip_image005

Type a display name for the template:

clip_image007

Put the checkbox on “CA certificate manager approval” if you prefer to. If you do you will have to approve the request once submitted.

clip_image009

In the Extensions tab select Key usage then Edit:

clip_image011

Put the checkbox on “Certificate signing” only

clip_image013

Ensure the local Administrator, or your administrative user/group, has Enroll permissions:

clip_image015

Right click on Certificate Templates, New, Certificate Template to Issue:

clip_image017

Select then newly created template then click OK:

clip_image019

The new template will then appear as available:

clip_image021

Then open MMC, add the Certificates snap-in for the Local computer.

Open the Personal container, right click on Certificates, All Tasks, Advanced Operations, Create Custom request:

clip_image023

Select Active Directory Enrollment Policy then click Next:

clip_image025

Select the template then click Next:

clip_image027

Click on Details then Properties:

clip_image029

Enter a Common name then click Add:

clip_image031

Enter a friendly name for the certificate:

clip_image032

In the Private key tab ensure the CSP “Microsoft Software Key Storage Provider” is listed:

clip_image033

Ensure “Mark private key exportable is selected”:

clip_image034

In Select Hash Algorithm select “sha256”:

clip_image035

Then click OK, you will be asked to save the request to a file:

clip_image036

Open an elevated command prompt and execute the command:

certreq -submit -config "<ServerNameCAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>"

The last parameter is required if you have not requested an approval before issuing the certificate.

If no approval is required a .cer will be retrieved, otherwise you will have to refer to the RequestID that will be displayed:

clip_image037

If the approval is required, once the request has been approved in the CA console, enter the following command to retrieve the .cer file:

certreq -retrieve -config "<ServerNameCAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerNameCAName>" "<CertificateResponse.cer>"

clip_image038

At this point you will find the new certificate in the Personal store of the local computer and you can export it:

clip_image040

Ensure you export the private key:

clip_image041

Do not select any of the PFX options:

clip_image042

Provide the PFX password when requested and save the file.

Then export the certificate again, this time without the private key:

clip_image043

Click Next then select the DER format:

clip_image044

Click Next then save the .CER file.

Notice that the certificate you have just generated might be signed using the SHA1 Hash algorithm, although we have requested a certificate using SHA256 Hash Algorithm. This happens due to the fact that in some operating systems the Subordinate Certification Authority template forces the key hashing algorithm to be SHA1. This however does not prevent TMG from issuing (signing) certificates with SHA256 hash algorithms.

Also note that Microsoft is phasing out weaker certificates such as SHA1 certificates and certificates with keys under 1024 bits in length. So expect at some point in time this to change.

So don’t be surprised and go ahead with the next steps.

Copy the PFX and the CER files to the TMG box, open the HTTPS Inspection configuration and import the certificate form the PFX file:

clip_image045

Then save and apply the configuration

On the TMG server open an MMC console and add the Certificates snap-in for the local computer.
Then import the .cer file in the Intermediate certificate store.
You will need to restart the TMG server.

clip_image047

Importing the certificate in the Intermediate store is necessary for the TMG server to send the intermediate certificate in the certificate chain so that the client is able to build the trust chain.

This is further explained bellow.

Now you can try from a client browsing a site using a CNG certificate, such as Twitter.
You will see the certificate being signed by the new certificate from your CA:

clip_image048

Notice that this certificate is signed using SHA256:

clip_image049

Regarding the building of the certificate chain

Since the Subordinate CA Certificate (“TMG HTTPS Inspection CNG Ent.CA” in this case) is not published anywhere the clients can’t, on its own find the certificate SubCA certificate.

For a normal certificate issuing CA you would be able to publish the SubCA Certificate and publish to either a LDAP or HTTP location and the clients would be able to look it up, by downloading the certificate from the AIA Extension in the certificate.

In the case of TMG issued certificates, for HTTP inspection, these don’t have an AIA extension.

clip_image051

TMG will send both the certificate for the URL being accessed on the browser (or other client) and the Subordinate CA, configured in TMG to issue these certificates.

Otherwise the client would end up with a certificate that do not built up to a trusted root, having a "gap" in the chain. So as you can see bellow TMG will send the two certificates on “Server Hello” handshake.

clip_image053

The certificate generated, on the fly by TMG, for the HTTPS site you are visiting, will appear as being issued by an intermediate CA represented by the certificate you generated.

That is why it is essential to add the SubCA to the “Intermediate Certification Authorities” store for the “Local Computer”. Otherwise the TMG issued certificates would need to have the AIA sections which would require the intermediate certificate (the one you have just generated) to be published to a AIA location. This would require further configuration on your environment, so TMG provides some help in the Chain validation process and sends the intermediate CA in the "Certificate" section of the SSL handshake as we can see in the “Server Hello” handshake on the network capture above.

Your “Subordinate CA” (TMG HTTPS Inspection CNG Ent.CA) will then have an AIA Extension and from there up to the Root CA. As you can see from the image

clip_image054

This will then allow to build up a valid certificate chain ending up in your Internal CA and starting in the leaf certificate issued by TMG for HTTP Inspection. The bellow picture shows the expected Certificate chain.

clip_image055

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Luis Sousa
Support Engineer – Microsoft PKI/AD Team

Reviewer:
Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

How to create a CNG HTTPSi cert using a 2008r2 CA

August 29th, 2014 No comments

In a previous article we explained how to create a self-signed CNG certificate, suitable for the HTTPS Inspection feature, which can be used to inspect sites using an SHA-256 certificate.

In this article we will explain how to generate a similar certificate using your internal CA based on Windows 2008 R2.

Using a certificate issued by your own CA, rather than a self-signed certificate, has the advantage that you will not have an additional certificate to distribute to the web proxy clients.
Bearing in mind that certificates have a limited validity period and that this eases operation maintenances, since you need only to change only the Subordinate CA certificate on TMG.

Arguably it can be said that if you set a validity period long enough, as some tenth of years, this would not be an issue.
But the truth is that what is considered secure today, might be easily compromised in a couple of years and for that reason, having an easy way to replace your certificates also improves your overall security.
The ability to quickly move to a larger key length or better hash algorithm at any time is the key to an always up to date and secure PKI infrastructure.

Now let's go ahead and create the certificate.
Begin by opening the Certificate Authority administration console, right click on Certificate Templates then Manage.

clip_image001

First step is duplicating the “Subordinate Certification Authority” template.

clip_image003

In Compatibility settings select Windows Server 2008:

clip_image005

Type a display name for the template:

clip_image007

Put the checkbox on “CA certificate manager approval” if you prefer to. If you do you will have to approve the request once submitted.

clip_image009

In the Extensions tab select Key usage then Edit:

clip_image011

Put the checkbox on “Certificate signing” only

clip_image013

Ensure the local Administrator, or your administrative user/group, has Enroll permissions:

clip_image015

Right click on Certificate Templates, New, Certificate Template to Issue:

clip_image017

Select then newly created template then click OK:

clip_image019

The new template will then appear as available:

clip_image021

Then open MMC, add the Certificates snap-in for the Local computer.

Open the Personal container, right click on Certificates, All Tasks, Advanced Operations, Create Custom request:

clip_image023

Select Active Directory Enrollment Policy then click Next:

clip_image025

Select the template then click Next:

clip_image027

Click on Details then Properties:

clip_image029

Enter a Common name then click Add:

clip_image031

Enter a friendly name for the certificate:

clip_image032

In the Private key tab ensure the CSP “Microsoft Software Key Storage Provider” is listed:

clip_image033

Ensure “Mark private key exportable is selected”:

clip_image034

In Select Hash Algorithm select “sha256”:

clip_image035

Then click OK, you will be asked to save the request to a file:

clip_image036

Open an elevated command prompt and execute the command:

certreq -submit -config "<ServerName\CAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>"

The last parameter is required if you have not requested an approval before issuing the certificate.

If no approval is required a .cer will be retrieved, otherwise you will have to refer to the RequestID that will be displayed:

clip_image037

If the approval is required, once the request has been approved in the CA console, enter the following command to retrieve the .cer file:

certreq -retrieve -config "<ServerName\CAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerName\CAName>" "<CertificateResponse.cer>"

clip_image038

At this point you will find the new certificate in the Personal store of the local computer and you can export it:

clip_image040

Ensure you export the private key:

clip_image041

Do not select any of the PFX options:

clip_image042

Provide the PFX password when requested and save the file.

Then export the certificate again, this time without the private key:

clip_image043

Click Next then select the DER format:

clip_image044

Click Next then save the .CER file.

Notice that the certificate you have just generated might be signed using the SHA1 Hash algorithm, although we have requested a certificate using SHA256 Hash Algorithm. This happens due to the fact that in some operating systems the Subordinate Certification Authority template forces the key hashing algorithm to be SHA1. This however does not prevent TMG from issuing (signing) certificates with SHA256 hash algorithms.

Also note that Microsoft is phasing out weaker certificates such as SHA1 certificates and certificates with keys under 1024 bits in length. So expect at some point in time this to change.

So don’t be surprised and go ahead with the next steps.

Copy the PFX and the CER files to the TMG box, open the HTTPS Inspection configuration and import the certificate form the PFX file:

clip_image045

Then save and apply the configuration

On the TMG server open an MMC console and add the Certificates snap-in for the local computer.
Then import the .cer file in the Intermediate certificate store.
You will need to restart the TMG server.

clip_image047

Importing the certificate in the Intermediate store is necessary for the TMG server to send the intermediate certificate in the certificate chain so that the client is able to build the trust chain.

This is further explained bellow.

Now you can try from a client browsing a site using a CNG certificate, such as Twitter.
You will see the certificate being signed by the new certificate from your CA:

clip_image048

Notice that this certificate is signed using SHA256:

clip_image049

Regarding the building of the certificate chain

Since the Subordinate CA Certificate (“TMG HTTPS Inspection CNG Ent.CA” in this case) is not published anywhere the clients can’t, on its own find the certificate SubCA certificate.

For a normal certificate issuing CA you would be able to publish the SubCA Certificate and publish to either a LDAP or HTTP location and the clients would be able to look it up, by downloading the certificate from the AIA Extension in the certificate.

In the case of TMG issued certificates, for HTTP inspection, these don’t have an AIA extension.

clip_image051

TMG will send both the certificate for the URL being accessed on the browser (or other client) and the Subordinate CA, configured in TMG to issue these certificates.

Otherwise the client would end up with a certificate that do not built up to a trusted root, having a "gap" in the chain. So as you can see bellow TMG will send the two certificates on “Server Hello” handshake.

clip_image053

The certificate generated, on the fly by TMG, for the HTTPS site you are visiting, will appear as being issued by an intermediate CA represented by the certificate you generated.

That is why it is essential to add the SubCA to the “Intermediate Certification Authorities” store for the “Local Computer”. Otherwise the TMG issued certificates would need to have the AIA sections which would require the intermediate certificate (the one you have just generated) to be published to a AIA location. This would require further configuration on your environment, so TMG provides some help in the Chain validation process and sends the intermediate CA in the "Certificate" section of the SSL handshake as we can see in the “Server Hello” handshake on the network capture above.

Your “Subordinate CA” (TMG HTTPS Inspection CNG Ent.CA) will then have an AIA Extension and from there up to the Root CA. As you can see from the image

clip_image054

This will then allow to build up a valid certificate chain ending up in your Internal CA and starting in the leaf certificate issued by TMG for HTTP Inspection. The bellow picture shows the expected Certificate chain.

clip_image055

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Luis Sousa
Support Engineer – Microsoft PKI/AD Team

Reviewer:
Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

How to create a CNG HTTPSi cert using a 2008r2 CA

August 29th, 2014 No comments

In a previous article we explained how to create a self-signed CNG certificate, suitable for the HTTPS Inspection feature, which can be used to inspect sites using an SHA-256 certificate.

In this article we will explain how to generate a similar certificate using your internal CA based on Windows 2008 R2.

Using a certificate issued by your own CA, rather than a self-signed certificate, has the advantage that you will not have an additional certificate to distribute to the web proxy clients.
Bearing in mind that certificates have a limited validity period and that this eases operation maintenances, since you need only to change only the Subordinate CA certificate on TMG.

Arguably it can be said that if you set a validity period long enough, as some tenth of years, this would not be an issue.
But the truth is that what is considered secure today, might be easily compromised in a couple of years and for that reason, having an easy way to replace your certificates also improves your overall security.
The ability to quickly move to a larger key length or better hash algorithm at any time is the key to an always up to date and secure PKI infrastructure.

Now let's go ahead and create the certificate.
Begin by opening the Certificate Authority administration console, right click on Certificate Templates then Manage.

clip_image001

First step is duplicating the “Subordinate Certification Authority” template.

clip_image003

In Compatibility settings select Windows Server 2008:

clip_image005

Type a display name for the template:

clip_image007

Put the checkbox on “CA certificate manager approval” if you prefer to. If you do you will have to approve the request once submitted.

clip_image009

In the Extensions tab select Key usage then Edit:

clip_image011

Put the checkbox on “Certificate signing” only

clip_image013

Ensure the local Administrator, or your administrative user/group, has Enroll permissions:

clip_image015

Right click on Certificate Templates, New, Certificate Template to Issue:

clip_image017

Select then newly created template then click OK:

clip_image019

The new template will then appear as available:

clip_image021

Then open MMC, add the Certificates snap-in for the Local computer.

Open the Personal container, right click on Certificates, All Tasks, Advanced Operations, Create Custom request:

clip_image023

Select Active Directory Enrollment Policy then click Next:

clip_image025

Select the template then click Next:

clip_image027

Click on Details then Properties:

clip_image029

Enter a Common name then click Add:

clip_image031

Enter a friendly name for the certificate:

clip_image032

In the Private key tab ensure the CSP “Microsoft Software Key Storage Provider” is listed:

clip_image033

Ensure “Mark private key exportable is selected”:

clip_image034

In Select Hash Algorithm select “sha256”:

clip_image035

Then click OK, you will be asked to save the request to a file:

clip_image036

Open an elevated command prompt and execute the command:

certreq -submit -config "<ServerNameCAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>"

The last parameter is required if you have not requested an approval before issuing the certificate.

If no approval is required a .cer will be retrieved, otherwise you will have to refer to the RequestID that will be displayed:

clip_image037

If the approval is required, once the request has been approved in the CA console, enter the following command to retrieve the .cer file:

certreq -retrieve -config "<ServerNameCAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerNameCAName>" "<CertificateResponse.cer>"

clip_image038

At this point you will find the new certificate in the Personal store of the local computer and you can export it:

clip_image040

Ensure you export the private key:

clip_image041

Do not select any of the PFX options:

clip_image042

Provide the PFX password when requested and save the file.

Then export the certificate again, this time without the private key:

clip_image043

Click Next then select the DER format:

clip_image044

Click Next then save the .CER file.

Notice that the certificate you have just generated might be signed using the SHA1 Hash algorithm, although we have requested a certificate using SHA256 Hash Algorithm. This happens due to the fact that in some operating systems the Subordinate Certification Authority template forces the key hashing algorithm to be SHA1. This however does not prevent TMG from issuing (signing) certificates with SHA256 hash algorithms.

Also note that Microsoft is phasing out weaker certificates such as SHA1 certificates and certificates with keys under 1024 bits in length. So expect at some point in time this to change.

So don’t be surprised and go ahead with the next steps.

Copy the PFX and the CER files to the TMG box, open the HTTPS Inspection configuration and import the certificate form the PFX file:

clip_image045

Then save and apply the configuration

On the TMG server open an MMC console and add the Certificates snap-in for the local computer.
Then import the .cer file in the Intermediate certificate store.
You will need to restart the TMG server.

clip_image047

Importing the certificate in the Intermediate store is necessary for the TMG server to send the intermediate certificate in the certificate chain so that the client is able to build the trust chain.

This is further explained bellow.

Now you can try from a client browsing a site using a CNG certificate, such as Twitter.
You will see the certificate being signed by the new certificate from your CA:

clip_image048

Notice that this certificate is signed using SHA256:

clip_image049

Regarding the building of the certificate chain

Since the Subordinate CA Certificate (“TMG HTTPS Inspection CNG Ent.CA” in this case) is not published anywhere the clients can’t, on its own find the certificate SubCA certificate.

For a normal certificate issuing CA you would be able to publish the SubCA Certificate and publish to either a LDAP or HTTP location and the clients would be able to look it up, by downloading the certificate from the AIA Extension in the certificate.

In the case of TMG issued certificates, for HTTP inspection, these don’t have an AIA extension.

clip_image051

TMG will send both the certificate for the URL being accessed on the browser (or other client) and the Subordinate CA, configured in TMG to issue these certificates.

Otherwise the client would end up with a certificate that do not built up to a trusted root, having a "gap" in the chain. So as you can see bellow TMG will send the two certificates on “Server Hello” handshake.

clip_image053

The certificate generated, on the fly by TMG, for the HTTPS site you are visiting, will appear as being issued by an intermediate CA represented by the certificate you generated.

That is why it is essential to add the SubCA to the “Intermediate Certification Authorities” store for the “Local Computer”. Otherwise the TMG issued certificates would need to have the AIA sections which would require the intermediate certificate (the one you have just generated) to be published to a AIA location. This would require further configuration on your environment, so TMG provides some help in the Chain validation process and sends the intermediate CA in the "Certificate" section of the SSL handshake as we can see in the “Server Hello” handshake on the network capture above.

Your “Subordinate CA” (TMG HTTPS Inspection CNG Ent.CA) will then have an AIA Extension and from there up to the Root CA. As you can see from the image

clip_image054

This will then allow to build up a valid certificate chain ending up in your Internal CA and starting in the leaf certificate issued by TMG for HTTP Inspection. The bellow picture shows the expected Certificate chain.

clip_image055

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Luis Sousa
Support Engineer – Microsoft PKI/AD Team

Reviewer:
Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

TMG SP2 Rollup 5 now available

We are happy to announce the availability of Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). TMG SP2 Rollup 5 is available for download here: Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2

 

Please see KB Article ID: 2954173 for details of the fixes included in this rollup. The Build Number for this update is: 7.0.9193.644

 

To install this update, you must be running Forefront Threat Management Gateway 2010 Service Pack 2.

For more information about Forefront Threat Management Gateway 2010 SP2, please see the following
Microsoft website: Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Download information for Forefront TMG 2010 SP2

 

Thank you,

Forefront TMG Team

TMG SP2 Rollup 5 now available

We are happy to announce the availability of Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). TMG SP2 Rollup 5 is available for download here: Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2

 

Please see KB Article ID: 2954173 for details of the fixes included in this rollup. The Build Number for this update is: 7.0.9193.644

 

To install this update, you must be running Forefront Threat Management Gateway 2010 Service Pack 2.

For more information about Forefront Threat Management Gateway 2010 SP2, please see the following
Microsoft website: Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Download information for Forefront TMG 2010 SP2

 

Thank you,

Forefront TMG Team

TMG SP2 Rollup 5 now available

We are happy to announce the availability of Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). TMG SP2 Rollup 5 is available for download here: Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2

 

Please see KB Article ID: 2954173 for details of the fixes included in this rollup. The Build Number for this update is: 7.0.9193.644

 

To install this update, you must be running Forefront Threat Management Gateway 2010 Service Pack 2.

For more information about Forefront Threat Management Gateway 2010 SP2, please see the following
Microsoft website: Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Download information for Forefront TMG 2010 SP2

 

Thank you,

Forefront TMG Team

TMG HTTPS inspection is failing if the target Web site is using a CNG certificate

If you have configured HTTPS Inspection on TMG you may not be able to access some sites such as Twitter and Dropbox.
In this scenario  clients will get a blank page and in the TMG logs you will see the error 0x8009000a

This happens when:

  • Web site that are using certificate with suite-B algorithm

  • TMG certificate used by HTTPS inspection feature to sign the certificate that will be sent to client is not compatible with suite-B certificate.

To resolve the problem you need to install a CNG certificate for the HTTPS Inspection feature

As example here is a  PowerShell script that create a self-signed CNG certificate:

#SCRIPT – Generate Self-signed CNG Certificates for Certificate signing purpose, This will be used by TMG Https Inpection  
#AUTHOR – Franck Heilmann – Microsoft Corporation  
#VERSION – 1.1
#$ErrorActionPreference = "Stop"  
 
Write-Host "`n WARNING: This script sample is provided AS-IS with no warranties and confers no rights." -ForegroundColor red  
Write-Host "`n This script sample will generate self-signed CNG Authority certificate to be used by TMG HTTPS Inspection feature"  
Write-Host " in the Local Computer Personal certificate store.`n Private is can be exported. As well the .cer and .pfx files will be save ini the provided directory`n`n"  
 
$outputDir = Read-Host "`nEnter directory path where certificate will be saved"  
$Subject = Read-Host "`nEnter the Subject for certificate "  
$password = Read-Host -assecurestring "`nPfx password"  
$ValidateDays = Read-Host "`nCertificate Validity days: (please enter number of days)"  
 
#Generate cert in local computer My store  
$name = new-object -com "X509Enrollment.CX500DistinguishedName.1"  
$name.Encode("CN=$Subject", 0)  
 
# The Key  
$key = new-object -com "X509Enrollment.CX509PrivateKey.1"  
$key.ProviderName = "Microsoft Software Key Storage Provider" # CNG is Software Key Storage "Microsoft RSA SChannel Cryptographic Provider"  
$key.KeySpec = 0 # was 1 but 0 looks needed for CNG http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx  
$key.keyUsage =0xfffff # Set the key usage to all usage http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx  
$key.Length = 2048  
$key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)" # Allow Write NT AUTHORITYSYSTEM Allow Write BUILTINAdministrators Allow Write NT AUTHORITYNETWORK SERVICE  
$key.MachineContext = 1  
$key.ExportPolicy = 1 # Allow private key to be exported XCN_NCRYPT_ALLOW_EXPORT_FLAG 0x00000001 http://msdn.microsoft.com/en-us/library/windows/desktop/aa379002(v=vs.85).aspx  
$key.Create()  
Write-Host "`nPrivate Key created ……"  
 
#The certificate itself  
$cert = new-object -com "X509Enrollment.CX509CertificateRequestCertificate.1" # Interface for self signed cert request http://msdn.microsoft.com/en-us/library/windows/desktop/aa377124(v=vs.85).aspx  
$cert.InitializeFromPrivateKey(2, $key, "")  
$cert.Subject = $name  
$cert.Issuer = $cert.Subject  
 
$today =get-date  
$cert.NotBefore = $today.AddDays(-1) # yesterday  
$cert.NotAfter = $cert.NotBefore.AddDays($ValidateDays)  
 
# Add Key usage to the certificate, this is needed as TMG chek this during certificate import  
$KeyUsage = new-object -com "X509Enrollment.CX509ExtensionKeyUsage.1"  
$Keyusage.InitializeEncode(0x4) #0x4 XCN_CERT_KEY_CERT_SIGN_KEY_USAGE http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx  
$cert.X509Extensions.Add($keyusage)  

$BasicConstraints = new-object -com "X509Enrollment.CX509ExtensionBasicConstraints.1"

$BasicConstraints.InitializeEncode(1,0) #set isCA to true, max path of 0 means it can't create subordinate CAs, only endpoint certs

$cert.X509Extensions.Add($BasicConstraints)
$cert.Encode()  
Write-Host "`nCertificate created ……"  
 
$enrollment = new-object -com "X509Enrollment.CX509Enrollment.1"  
$enrollment.InitializeFromRequest($cert)  
 
$certdata = $enrollment.CreateRequest(0)  
 
 
$enrollment.InstallResponse(2, $certdata, 0, "")  
Write-Host "`nCNG self signed installed in the Computer certificate local store"  
 
#Create the ".pfx" and ".cer" version by exporting the just inserted certificate  
$store = new-object System.Security.Cryptography.X509Certificates.X509Store "My","LocalMachine"  
$store.Open("ReadOnly")  
$certs = $store.Certificates  
$cerPath = $outputDir+ ""+ $Subject+ ".cer"  
$pfxPath = $outputDir + "" + $Subject + ".pfx"  
 
foreach ($cert in $certs)  
{  
# write-host $cert.Subject  
if($cert.Subject -like ("CN="+ $Subject))  
{  
$ExportCert = $cert.Export(1) #http://msdn.microsoft.com/fr-fr/library/system.security.cryptography.x509certificates.x509certificate2.aspx 1=.cer 3=.fx  
[System.IO.File]::WriteAllBytes(($cerPath), $ExportCert)  
Write-Host "`nCertificate .cer exported to: " $cerPath  
$PFXStrData =$cert.Export(3,$password)  
[System.IO.File]::WriteAllBytes($pfxPath, $PFXStrData)  
Write-Host "`nCertificate with private Key .pfx exported to: " $pfxPath  
}  
}  
$store.close()  
 
#now Import it to Local computer Root store  
$RootCert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2 $cerPath  
$RootStore = new-object System.Security.Cryptography.X509Certificates.X509Store "Root","LocalMachine"  
$RootStore.Open("ReadWrite")  
$RootStore.Add($RootCert)  
Write-Host "`nCertificate installed in Local computer – Trusted root"  
$RootStore.close()  
 
Write-Host "`nDone … `n" -ForegroundColor Green

You will have to copy the above lines into a new file and then save it into a file name with .ps1 extension, such as CNG-HTTPSi.ps1 on a computer running Windows 2008 R2 SP1 or later.

Then follow these steps:

  • Open a PowerShell window as administrator

  • Ensure local scripts can be executed by running the command:
    Set-ExecutionPolicy Set-ExecutionPolicy RemoteSigned
    Find more information about execution policy in this article: http://technet.microsoft.com/en-us/library/ee176949.aspx

  • Execute the script with the command ./CNG-HTTPSi.ps1

  • Enter the path where the certificates will be saved

  • Enter the subject, such as ”CNG HTTPS Inspection”

  • Enter the pfx password

  • Enter the validity of the certificate in days, for example 730 for two years

  • In the specified folder you will find a .cer and a .pfx files

  • Deploy the cer file in the Trusted Root container to all clients and the TMG servers, you can deploy the certificate manually or using Active directory
    Find more information in this article: http://technet.microsoft.com/en-us/library/dd441069

  • Once the certificate is deployed you can reconfigure HTTP Inspection on TMG importing the pfx certificate generated by the script

  • Save and apply the configuration then you will be able to reach the site

  

Author:

Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Franck Heilmann
Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Uncategorized Tags:

TMG HTTPS inspection is failing if the target Web site is using a CNG certificate

If you have configured HTTPS Inspection on TMG you may not be able to access some sites such as Twitter and Dropbox.
In this scenario  clients will get a blank page and in the TMG logs you will see the error 0x8009000a

This happens when:

  • Web site that are using certificate with suite-B algorithm

  • TMG certificate used by HTTPS inspection feature to sign the certificate that will be sent to client is not compatible with suite-B certificate.

To resolve the problem you need to install a CNG certificate for the HTTPS Inspection feature

As example here is a  PowerShell script that create a self-signed CNG certificate:

#SCRIPT – Generate Self-signed CNG Certificates for Certificate signing purpose, This will be used by TMG Https Inpection  
#AUTHOR – Franck Heilmann – Microsoft Corporation  
#VERSION – 1.1
#$ErrorActionPreference = "Stop"  
 
Write-Host "`n WARNING: This script sample is provided AS-IS with no warranties and confers no rights." -ForegroundColor red  
Write-Host "`n This script sample will generate self-signed CNG Authority certificate to be used by TMG HTTPS Inspection feature"  
Write-Host " in the Local Computer Personal certificate store.`n Private is can be exported. As well the .cer and .pfx files will be save ini the provided directory`n`n"  
 
$outputDir = Read-Host "`nEnter directory path where certificate will be saved"  
$Subject = Read-Host "`nEnter the Subject for certificate "  
$password = Read-Host -assecurestring "`nPfx password"  
$ValidateDays = Read-Host "`nCertificate Validity days: (please enter number of days)"  
 
#Generate cert in local computer My store  
$name = new-object -com "X509Enrollment.CX500DistinguishedName.1"  
$name.Encode("CN=$Subject", 0)  
 
# The Key  
$key = new-object -com "X509Enrollment.CX509PrivateKey.1"  
$key.ProviderName = "Microsoft Software Key Storage Provider" # CNG is Software Key Storage "Microsoft RSA SChannel Cryptographic Provider"  
$key.KeySpec = 0 # was 1 but 0 looks needed for CNG http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx  
$key.keyUsage =0xfffff # Set the key usage to all usage http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx  
$key.Length = 2048  
$key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)" # Allow Write NT AUTHORITY\SYSTEM Allow Write BUILTIN\Administrators Allow Write NT AUTHORITY\NETWORK SERVICE  
$key.MachineContext = 1  
$key.ExportPolicy = 1 # Allow private key to be exported XCN_NCRYPT_ALLOW_EXPORT_FLAG 0x00000001 http://msdn.microsoft.com/en-us/library/windows/desktop/aa379002(v=vs.85).aspx  
$key.Create()  
Write-Host "`nPrivate Key created ……"  
 
#The certificate itself  
$cert = new-object -com "X509Enrollment.CX509CertificateRequestCertificate.1" # Interface for self signed cert request http://msdn.microsoft.com/en-us/library/windows/desktop/aa377124(v=vs.85).aspx  
$cert.InitializeFromPrivateKey(2, $key, "")  
$cert.Subject = $name  
$cert.Issuer = $cert.Subject  
 
$today =get-date  
$cert.NotBefore = $today.AddDays(-1) # yesterday  
$cert.NotAfter = $cert.NotBefore.AddDays($ValidateDays)  
 
# Add Key usage to the certificate, this is needed as TMG chek this during certificate import  
$KeyUsage = new-object -com "X509Enrollment.CX509ExtensionKeyUsage.1"  
$Keyusage.InitializeEncode(0x4) #0x4 XCN_CERT_KEY_CERT_SIGN_KEY_USAGE http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx  
$cert.X509Extensions.Add($keyusage)  

$BasicConstraints = new-object -com "X509Enrollment.CX509ExtensionBasicConstraints.1"

$BasicConstraints.InitializeEncode(1,0) #set isCA to true, max path of 0 means it can't create subordinate CAs, only endpoint certs

$cert.X509Extensions.Add($BasicConstraints)
$cert.Encode()  
Write-Host "`nCertificate created ……"  
 
$enrollment = new-object -com "X509Enrollment.CX509Enrollment.1"  
$enrollment.InitializeFromRequest($cert)  
 
$certdata = $enrollment.CreateRequest(0)  
 
 
$enrollment.InstallResponse(2, $certdata, 0, "")  
Write-Host "`nCNG self signed installed in the Computer certificate local store"  
 
#Create the ".pfx" and ".cer" version by exporting the just inserted certificate  
$store = new-object System.Security.Cryptography.X509Certificates.X509Store "My","LocalMachine"  
$store.Open("ReadOnly")  
$certs = $store.Certificates  
$cerPath = $outputDir+ "\"+ $Subject+ ".cer"  
$pfxPath = $outputDir + "\" + $Subject + ".pfx"  
 
foreach ($cert in $certs)  
{  
# write-host $cert.Subject  
if($cert.Subject -like ("CN="+ $Subject))  
{  
$ExportCert = $cert.Export(1) #http://msdn.microsoft.com/fr-fr/library/system.security.cryptography.x509certificates.x509certificate2.aspx 1=.cer 3=.fx  
[System.IO.File]::WriteAllBytes(($cerPath), $ExportCert)  
Write-Host "`nCertificate .cer exported to: " $cerPath  
$PFXStrData =$cert.Export(3,$password)  
[System.IO.File]::WriteAllBytes($pfxPath, $PFXStrData)  
Write-Host "`nCertificate with private Key .pfx exported to: " $pfxPath  
}  
}  
$store.close()  
 
#now Import it to Local computer Root store  
$RootCert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2 $cerPath  
$RootStore = new-object System.Security.Cryptography.X509Certificates.X509Store "Root","LocalMachine"  
$RootStore.Open("ReadWrite")  
$RootStore.Add($RootCert)  
Write-Host "`nCertificate installed in Local computer – Trusted root"  
$RootStore.close()  
 
Write-Host "`nDone … `n" -ForegroundColor Green

You will have to copy the above lines into a new file and then save it into a file name with .ps1 extension, such as CNG-HTTPSi.ps1 on a computer running Windows 2008 R2 SP1 or later.

Then follow these steps:

  • Open a PowerShell window as administrator

  • Ensure local scripts can be executed by running the command:
    Set-ExecutionPolicy Set-ExecutionPolicy RemoteSigned
    Find more information about execution policy in this article: http://technet.microsoft.com/en-us/library/ee176949.aspx

  • Execute the script with the command ./CNG-HTTPSi.ps1

  • Enter the path where the certificates will be saved

  • Enter the subject, such as ”CNG HTTPS Inspection”

  • Enter the pfx password

  • Enter the validity of the certificate in days, for example 730 for two years

  • In the specified folder you will find a .cer and a .pfx files

  • Deploy the cer file in the Trusted Root container to all clients and the TMG servers, you can deploy the certificate manually or using Active directory
    Find more information in this article: http://technet.microsoft.com/en-us/library/dd441069

  • Once the certificate is deployed you can reconfigure HTTP Inspection on TMG importing the pfx certificate generated by the script

  • Save and apply the configuration then you will be able to reach the site

  

Author:

Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Franck Heilmann
Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Uncategorized Tags:

TMG HTTPS inspection is failing if the target Web site is using a CNG certificate

If you have configured HTTPS Inspection on TMG you may not be able to access some sites such as Twitter and Dropbox.
In this scenario  clients will get a blank page and in the TMG logs you will see the error 0x8009000a

This happens when:

  • Web site that are using certificate with suite-B algorithm

  • TMG certificate used by HTTPS inspection feature to sign the certificate that will be sent to client is not compatible with suite-B certificate.

To resolve the problem you need to install a CNG certificate for the HTTPS Inspection feature

As example here is a  PowerShell script that create a self-signed CNG certificate:

#SCRIPT – Generate Self-signed CNG Certificates for Certificate signing purpose, This will be used by TMG Https Inpection  
#AUTHOR – Franck Heilmann – Microsoft Corporation  
#VERSION – 1.1
#$ErrorActionPreference = "Stop"  
 
Write-Host "`n WARNING: This script sample is provided AS-IS with no warranties and confers no rights." -ForegroundColor red  
Write-Host "`n This script sample will generate self-signed CNG Authority certificate to be used by TMG HTTPS Inspection feature"  
Write-Host " in the Local Computer Personal certificate store.`n Private is can be exported. As well the .cer and .pfx files will be save ini the provided directory`n`n"  
 
$outputDir = Read-Host "`nEnter directory path where certificate will be saved"  
$Subject = Read-Host "`nEnter the Subject for certificate "  
$password = Read-Host -assecurestring "`nPfx password"  
$ValidateDays = Read-Host "`nCertificate Validity days: (please enter number of days)"  
 
#Generate cert in local computer My store  
$name = new-object -com "X509Enrollment.CX500DistinguishedName.1"  
$name.Encode("CN=$Subject", 0)  
 
# The Key  
$key = new-object -com "X509Enrollment.CX509PrivateKey.1"  
$key.ProviderName = "Microsoft Software Key Storage Provider" # CNG is Software Key Storage "Microsoft RSA SChannel Cryptographic Provider"  
$key.KeySpec = 0 # was 1 but 0 looks needed for CNG http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx  
$key.keyUsage =0xfffff # Set the key usage to all usage http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx  
$key.Length = 2048  
$key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)" # Allow Write NT AUTHORITYSYSTEM Allow Write BUILTINAdministrators Allow Write NT AUTHORITYNETWORK SERVICE  
$key.MachineContext = 1  
$key.ExportPolicy = 1 # Allow private key to be exported XCN_NCRYPT_ALLOW_EXPORT_FLAG 0x00000001 http://msdn.microsoft.com/en-us/library/windows/desktop/aa379002(v=vs.85).aspx  
$key.Create()  
Write-Host "`nPrivate Key created ……"  
 
#The certificate itself  
$cert = new-object -com "X509Enrollment.CX509CertificateRequestCertificate.1" # Interface for self signed cert request http://msdn.microsoft.com/en-us/library/windows/desktop/aa377124(v=vs.85).aspx  
$cert.InitializeFromPrivateKey(2, $key, "")  
$cert.Subject = $name  
$cert.Issuer = $cert.Subject  
 
$today =get-date  
$cert.NotBefore = $today.AddDays(-1) # yesterday  
$cert.NotAfter = $cert.NotBefore.AddDays($ValidateDays)  
 
# Add Key usage to the certificate, this is needed as TMG chek this during certificate import  
$KeyUsage = new-object -com "X509Enrollment.CX509ExtensionKeyUsage.1"  
$Keyusage.InitializeEncode(0x4) #0x4 XCN_CERT_KEY_CERT_SIGN_KEY_USAGE http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx  
$cert.X509Extensions.Add($keyusage)  

$BasicConstraints = new-object -com "X509Enrollment.CX509ExtensionBasicConstraints.1"

$BasicConstraints.InitializeEncode(1,0) #set isCA to true, max path of 0 means it can't create subordinate CAs, only endpoint certs

$cert.X509Extensions.Add($BasicConstraints)
$cert.Encode()  
Write-Host "`nCertificate created ……"  
 
$enrollment = new-object -com "X509Enrollment.CX509Enrollment.1"  
$enrollment.InitializeFromRequest($cert)  
 
$certdata = $enrollment.CreateRequest(0)  
 
 
$enrollment.InstallResponse(2, $certdata, 0, "")  
Write-Host "`nCNG self signed installed in the Computer certificate local store"  
 
#Create the ".pfx" and ".cer" version by exporting the just inserted certificate  
$store = new-object System.Security.Cryptography.X509Certificates.X509Store "My","LocalMachine"  
$store.Open("ReadOnly")  
$certs = $store.Certificates  
$cerPath = $outputDir+ ""+ $Subject+ ".cer"  
$pfxPath = $outputDir + "" + $Subject + ".pfx"  
 
foreach ($cert in $certs)  
{  
# write-host $cert.Subject  
if($cert.Subject -like ("CN="+ $Subject))  
{  
$ExportCert = $cert.Export(1) #http://msdn.microsoft.com/fr-fr/library/system.security.cryptography.x509certificates.x509certificate2.aspx 1=.cer 3=.fx  
[System.IO.File]::WriteAllBytes(($cerPath), $ExportCert)  
Write-Host "`nCertificate .cer exported to: " $cerPath  
$PFXStrData =$cert.Export(3,$password)  
[System.IO.File]::WriteAllBytes($pfxPath, $PFXStrData)  
Write-Host "`nCertificate with private Key .pfx exported to: " $pfxPath  
}  
}  
$store.close()  
 
#now Import it to Local computer Root store  
$RootCert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2 $cerPath  
$RootStore = new-object System.Security.Cryptography.X509Certificates.X509Store "Root","LocalMachine"  
$RootStore.Open("ReadWrite")  
$RootStore.Add($RootCert)  
Write-Host "`nCertificate installed in Local computer – Trusted root"  
$RootStore.close()  
 
Write-Host "`nDone … `n" -ForegroundColor Green

You will have to copy the above lines into a new file and then save it into a file name with .ps1 extension, such as CNG-HTTPSi.ps1 on a computer running Windows 2008 R2 SP1 or later.

Then follow these steps:

  • Open a PowerShell window as administrator

  • Ensure local scripts can be executed by running the command:
    Set-ExecutionPolicy Set-ExecutionPolicy RemoteSigned
    Find more information about execution policy in this article: http://technet.microsoft.com/en-us/library/ee176949.aspx

  • Execute the script with the command ./CNG-HTTPSi.ps1

  • Enter the path where the certificates will be saved

  • Enter the subject, such as ”CNG HTTPS Inspection”

  • Enter the pfx password

  • Enter the validity of the certificate in days, for example 730 for two years

  • In the specified folder you will find a .cer and a .pfx files

  • Deploy the cer file in the Trusted Root container to all clients and the TMG servers, you can deploy the certificate manually or using Active directory
    Find more information in this article: http://technet.microsoft.com/en-us/library/dd441069

  • Once the certificate is deployed you can reconfigure HTTP Inspection on TMG importing the pfx certificate generated by the script

  • Save and apply the configuration then you will be able to reach the site

  

Author:

Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Franck Heilmann
Sr. Escalation Engineer – Microsoft Forefront Edge Security Team

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Uncategorized Tags:

TMG Web Listener Certificate “Private Key handle error” 0x80090016

You may face an issue with a certificate assigned to a listener that suddenly becomes invalid and therefore the incoming SSL connection are dropped.

Restarting the service you will show the following error:


Event Source: Microsoft Firewall
Event ID: 14060
Description: Description: Cannot load an application filter Web Proxy Filter ({4CB7513E-220E-4C20-815A-B67BAA295FF4}). FilterInit failed with code 0x80092004.
To attempt to activate this application filter again, stop and restart the Firewall service.

The problem can be caused by the permission on private keys of the certificate store becoming corrupted. This may be affecting one or more certificates.
In these cases deleting the bad certificate and re-importing can help to resolve the the problem most of the times.

Find more information in this article: http://blogs.technet.com/b/isablog/archive/2009/03/10/unable-to-start-microsoft-firewall-service-in-isa-server-2006.aspx

In some cases you may have lost the original PFX file or forgot the password and need the fix the issue using a different approach.
In this article we will discuss how to better diagnose the issue and try to fix it, this may or may not work in your environment depending on the entity of the damage.

You can identify the invalid certificates by opening the TMG console, even if the Firewall service is not running, and try to assign the right certificate to all of your listeners.
By unselecting the checkbox “Show only valid certificates”, you will see a message similar to that in the screenshot below:

In the properties of the listener, when selecting a certificate, you may get the status “Private key handle error” or “Invalid key”

You can try fixing the issue from the Certificates console:

  • Execute MMC

  • Add the Certificate snap-in for the Local computer

  • In the Personal store right click on the certificate, All task, Manage Private keys

  • If you can assign Full control to the local Administrators group and to SYSTEM

  • Then go back to the TMG console and select the certificate, it should appear valid

  • Save and apply the configuration and try to start the Firewall service

However you may be unable to assign the permission from the certificates console, you may get an Access denied error.
In this case you will have to identify the file with the certificate’s private key, the file is located in the folder c:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

To troubleshoot the issue, you can use Process Monitor from SysInternals (DOWNLOAD: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx).Once downloaded and extracted follow these steps:

  • Close all running programs, just keep the Certificates MMC open

  • Start Process Monitor, a capture will start automatically

  • On the Certificate MMC go to Manage Private keys as described above

  • Once you get the Access Denied error go back to Process Monitor and press CTRL-E to stop the capture

  • Click on Tools then Process Tree

  • Scroll down to mmc.exe, right click then Add process to Include filter, then click Close

  • The events will be filtered and only those generated by MMC will be displayed

  • Scroll down in the list and you will see some rows generated while trying to access to the private key file and ACESS DENIED in the result column, right click on any of them then Jump To …

  • The right folder and file will automatically be opened and you will be able to assign the permissions. You may also need to take ownership of the file in order to do that.

  • Then go back to the TMG console and select the certificate, it should appear valid

  • Save and apply the configuration and try to start the Firewall service

It is important to always re-select the certificate in the TMG console, this way the additional permissions required by the TMG Firewall service will be assigned automatically.

Depending on the entity of the damage you may need to follow the above steps for all the certificates affected by the issue.

Author:

Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

 

Categories: Uncategorized Tags:

TMG Web Listener Certificate “Private Key handle error” 0x80090016

You may face an issue with a certificate assigned to a listener that suddenly becomes invalid and therefore the incoming SSL connection are dropped.

Restarting the service you will show the following error:


Event Source: Microsoft Firewall
Event ID: 14060
Description: Description: Cannot load an application filter Web Proxy Filter ({4CB7513E-220E-4C20-815A-B67BAA295FF4}). FilterInit failed with code 0x80092004.
To attempt to activate this application filter again, stop and restart the Firewall service.

The problem can be caused by the permission on private keys of the certificate store becoming corrupted. This may be affecting one or more certificates.
In these cases deleting the bad certificate and re-importing can help to resolve the the problem most of the times.

Find more information in this article: http://blogs.technet.com/b/isablog/archive/2009/03/10/unable-to-start-microsoft-firewall-service-in-isa-server-2006.aspx

In some cases you may have lost the original PFX file or forgot the password and need the fix the issue using a different approach.
In this article we will discuss how to better diagnose the issue and try to fix it, this may or may not work in your environment depending on the entity of the damage.

You can identify the invalid certificates by opening the TMG console, even if the Firewall service is not running, and try to assign the right certificate to all of your listeners.
By unselecting the checkbox “Show only valid certificates”, you will see a message similar to that in the screenshot below:

In the properties of the listener, when selecting a certificate, you may get the status “Private key handle error” or “Invalid key”

You can try fixing the issue from the Certificates console:

  • Execute MMC

  • Add the Certificate snap-in for the Local computer

  • In the Personal store right click on the certificate, All task, Manage Private keys

  • If you can assign Full control to the local Administrators group and to SYSTEM

  • Then go back to the TMG console and select the certificate, it should appear valid

  • Save and apply the configuration and try to start the Firewall service

However you may be unable to assign the permission from the certificates console, you may get an Access denied error.
In this case you will have to identify the file with the certificate’s private key, the file is located in the folder c:ProgramDataMicrosoftCryptoRSAMachineKeys

To troubleshoot the issue, you can use Process Monitor from SysInternals (DOWNLOAD: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx).Once downloaded and extracted follow these steps:

  • Close all running programs, just keep the Certificates MMC open

  • Start Process Monitor, a capture will start automatically

  • On the Certificate MMC go to Manage Private keys as described above

  • Once you get the Access Denied error go back to Process Monitor and press CTRL-E to stop the capture

  • Click on Tools then Process Tree

  • Scroll down to mmc.exe, right click then Add process to Include filter, then click Close

  • The events will be filtered and only those generated by MMC will be displayed

  • Scroll down in the list and you will see some rows generated while trying to access to the private key file and ACESS DENIED in the result column, right click on any of them then Jump To …

  • The right folder and file will automatically be opened and you will be able to assign the permissions. You may also need to take ownership of the file in order to do that.

  • Then go back to the TMG console and select the certificate, it should appear valid

  • Save and apply the configuration and try to start the Firewall service

It is important to always re-select the certificate in the TMG console, this way the additional permissions required by the TMG Firewall service will be assigned automatically.

Depending on the entity of the damage you may need to follow the above steps for all the certificates affected by the issue.

Author:

Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

 

Categories: Uncategorized Tags:

TMG Web Listener Certificate “Private Key handle error” 0x80090016

You may face an issue with a certificate assigned to a listener that suddenly becomes invalid and therefore the incoming SSL connection are dropped.

Restarting the service you will show the following error:


Event Source: Microsoft Firewall
Event ID: 14060
Description: Description: Cannot load an application filter Web Proxy Filter ({4CB7513E-220E-4C20-815A-B67BAA295FF4}). FilterInit failed with code 0x80092004.
To attempt to activate this application filter again, stop and restart the Firewall service.

The problem can be caused by the permission on private keys of the certificate store becoming corrupted. This may be affecting one or more certificates.
In these cases deleting the bad certificate and re-importing can help to resolve the the problem most of the times.

Find more information in this article: http://blogs.technet.com/b/isablog/archive/2009/03/10/unable-to-start-microsoft-firewall-service-in-isa-server-2006.aspx

In some cases you may have lost the original PFX file or forgot the password and need the fix the issue using a different approach.
In this article we will discuss how to better diagnose the issue and try to fix it, this may or may not work in your environment depending on the entity of the damage.

You can identify the invalid certificates by opening the TMG console, even if the Firewall service is not running, and try to assign the right certificate to all of your listeners.
By unselecting the checkbox “Show only valid certificates”, you will see a message similar to that in the screenshot below:

In the properties of the listener, when selecting a certificate, you may get the status “Private key handle error” or “Invalid key”

You can try fixing the issue from the Certificates console:

  • Execute MMC

  • Add the Certificate snap-in for the Local computer

  • In the Personal store right click on the certificate, All task, Manage Private keys

  • If you can assign Full control to the local Administrators group and to SYSTEM

  • Then go back to the TMG console and select the certificate, it should appear valid

  • Save and apply the configuration and try to start the Firewall service

However you may be unable to assign the permission from the certificates console, you may get an Access denied error.
In this case you will have to identify the file with the certificate’s private key, the file is located in the folder c:ProgramDataMicrosoftCryptoRSAMachineKeys

To troubleshoot the issue, you can use Process Monitor from SysInternals (DOWNLOAD: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx).Once downloaded and extracted follow these steps:

  • Close all running programs, just keep the Certificates MMC open

  • Start Process Monitor, a capture will start automatically

  • On the Certificate MMC go to Manage Private keys as described above

  • Once you get the Access Denied error go back to Process Monitor and press CTRL-E to stop the capture

  • Click on Tools then Process Tree

  • Scroll down to mmc.exe, right click then Add process to Include filter, then click Close

  • The events will be filtered and only those generated by MMC will be displayed

  • Scroll down in the list and you will see some rows generated while trying to access to the private key file and ACESS DENIED in the result column, right click on any of them then Jump To …

  • The right folder and file will automatically be opened and you will be able to assign the permissions. You may also need to take ownership of the file in order to do that.

  • Then go back to the TMG console and select the certificate, it should appear valid

  • Save and apply the configuration and try to start the Firewall service

It is important to always re-select the certificate in the TMG console, this way the additional permissions required by the TMG Firewall service will be assigned automatically.

Depending on the entity of the damage you may need to follow the above steps for all the certificates affected by the issue.

Author:

Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

 

Categories: Uncategorized Tags:

TMG 2010 – YOU CANNOT REMOTELY CONNECT TO TMG SERVER WHEN IT’S PUBLISHING RDP PROTOCOL

March 24th, 2014 No comments

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

clip_image002

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

clip_image003

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

clip_image005

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

clip_image006

clip_image007

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

  1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

  2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

clip_image009

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

clip_image010

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Publishing, RDP, TMG Tags:

TMG 2010 – YOU CANNOT REMOTELY CONNECT TO TMG SERVER WHEN IT’S PUBLISHING RDP PROTOCOL

March 24th, 2014 No comments

If some of you recently tried to publish RDP protocol through TMG server, and suddenly lost the possibility to perform TS connections to the TMG server itself, you may find this post useful!

In TMG 2010, a System Policy rule exists allowing RDP traffic from a white-list of workstations to the TMG server itself.

clip_image002

Thanks to this, it’s generically possible to connect to our TMG server from allowed PCs.

If you perform the following command, you’ll be able to see the TCP listener bound to the Remote Desktop Services (RDS) service accepting incoming RDP connections on default port 3389:

Netstat –ano | findstr :3389

clip_image003

Now, let’s assume that you have to publish RDP protocol externally through TMG, so that TS connections from external devices toward an internal server can be established, while the internal server’s IP address is masked.

You can do this by creating a specific “Non-Web server publishing rule” in TMG:

clip_image005

If you run again the netstat command mentioned above after you performed this configuration, you will see no differences at all, and everything should be working as expected.

Let’s now assume you have to reboot the TMG server.

After the reboot, if you run the netstat, you’ll see that the situation has changed:

clip_image006

clip_image007

Now the TMG server is listening for RDP connection only on the IP address which has been configured within TMG’s Server Publishing rule. Moreover, we can see that the listener is now associated to the PID of the FW service itself, and we no longer have entries related to the RDS service.

If you test TS connectivity to the TMG server from one of the allowed internal workstations, it will now fail.

This happens because of a socket conflict generated between the FW service and the RDS service, and it is an expected behavior.

In order to allow remote access while publishing RDP, basically 2 solutions exist: 

  1. You can publish the RDP server on different port than 3389, using non web server publishing rule and creating a “customized” RDP protocol for the new considered port.

  2. You can just change the RDS on the TMG to listen on a different port or adapter

 To apply this second solution, you can open Remote Desktop Session Host Configuration > Right-Click on RDP-TCP > Network Adapter > then select the internal NIC.

clip_image009

After this action, just restart the RDS service.

If you now run a new netstat, you’ll see the following situation:

clip_image010

You will now have the RDS service listening on the IP addresses bound to the internal NIC, while the FW service is listening on the external side for RDP publishing.

With this configuration, it’s again possible to establish TS connections to the TMG server even when the server publishes the RDP protocol.

As always…I hope you can find this useful!!

Author:

Daniele Gaiulli
Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: Publishing, RDP, TMG Tags: