Archive

Archive for the ‘Publishing’ Category

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:

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:

How to generate a certificate with subject alternative names (SAN)

October 9th, 2011 No comments

When publishing services like Outlook Anywhere, OWA and Active Sync for exchange in ISA/TMG, we sometimes need certificates with subject alternative names (SAN). This enables us to publish multiple DNS names using one SSL Web Listener. Requesting SAN certificates is something we can perform directly through a Microsoft internal CA. However there are some steps to follow before gathering a new certificate that makes use of SANs.

This article explains how to request a new certificate with a SAN from the Microsoft Management Console on the TMG computer.

The following security best practices apply when adding subject alternate names to certificates:

· In general, the use of user-defined SANs can increase the risk of impersonation attacks because it allows a user to specify arbitrary names in a certificate request. Because user input can be abused by persons with malicious intent, precautions should be taken to mitigate the risks associated with the use of user-defined SANs and protect the integrity of your public key infrastructure (PKI).

· Certificate requests that contain SANs should be held in a pending state until they can be reviewed by a certificate manager. For information about configuring certificate templates to require certificate manager approval, see Issuance Requirements.

· Implement administrative procedures for reviewing pending certificate requests and verifying the requester is authorized to use the requested subject names.

· Implement separation of duties and role-based administration to ensure that individuals who can request certificates with SANs cannot also issue them. See Implement Role-Based Administration.

· Restrict usage of SANs to only those individuals that require it, such as administrators who install Web server certificates. For information about configuring certificate template security, see Issuing Certificates Based on Certificate Templates.

· If you must use SAN attributes because your server that requires a certificate with a SAN is running Windows Server 2003, consider completing certificate enrollment procedures on a computer that is running Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista.

Hence we definitely suggest to make use of the mmc console to generate your SANs certificates.

Generating a certificate using the certificate console on TMG/ISA

To generate a SANs certificate use the Microsoft Management console on the TMG/ISA server as explained in the following paragraphs.

However before running the mmc certificate console we need to duplicate the template “web server” on the CA and make it visible under mmc-> certificate itself.

To accomplish this step we must open the certification authority as enterprise administrator and under certificate templates, right click on “manage”. We will open the certification template console where we have to duplicate the template “web server”. You have to configure it with the permission to be “visible” under the mmc certificate console, by selecting “enroll” in the security tab for the “authenticated users”. Be careful that the template version must be V2 and NOT V3 (2003 and not 2008), as TMG doesn’t support CNG certificates (http://technet.microsoft.com/de-de/library/ee796231.aspx#dfg9o9i8uuy6tre).

Once we have opened it and we have expanded local computer –> personal, we have to right click and chose “all task” and “request new certificate”.

image

After pressing “next” twice and choosing the template model “web server”, which had been duplicated previously, we select details and we must click on “properties”.

At this stage we have the two fields under the subject tab which are of interest:

Subject name -> type-> CN

Alternative name -> type-> DNS

image

Then press “ok”, “enroll” and if everything goes fine, we should get something like this:

image

At this point the certificate has been correctly created and installed under the certificate store.

However from TMG/ISA there is something to do before enrolling the certificate. By design TMG/ISA blocks DCOM and you’ll see an error similar to this:

image

With certutil from the command line you’ll see something like this:

C:\Windows\system32>certutil -ping -config "WIN2008DC.via.santagiulia\via-WIN2008DC-CA"

Connecting to WIN2008DC.via.santagiulia\via-WIN2008DC-CA …

Server could not be reached: The RPC server is unavailable. 0x800706ba (WIN32: 1722)

In TMG/ISA we need to disable the Strict RPC compliance using “edit system policies” -> “authentication services” -> “enforce strict RPC compliance” and apply it. This is because TMG/ISA blocks DCOM by design and DCOM is required to acquire a certificate.

You can also use the following command from the command line to check the CA availability on any server:

C:\Windows\system32>certutil -ping -config "FQDN\CA_Name"

if everything is fine we should get:

C:\Windows\system32>certutil -ping -config "WIN2008DC.via.santagiulia\via-WIN2008DC-CA"

Connecting to WIN2008DC.via.santagiulia\via-WIN2008DC-CA …

Server "via-WIN2008DC-CA" ICertRequest2 interface is alive

CertUtil: -ping command completed successfully.

That’s all. We have successfully created and imported our new SANs certificate.

Please be aware that you need to make sure that this certificate is installed on each node if you’re running an Array of ISA/TMG server, in order to be able to create a SSL listener on each one of the nodes.

Author
Andrea Vescovo
Support Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Philipp Sand
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Carsten Kinder
Principal Consultant
Microsoft Consulting Services

Categories: certificate, Publishing Tags: