If you’re trying to publish Remote Desktop Services or RemoteApp on Microsoft Forefront Unified Access Gateway 2010, and if you encounter the following error, read on:

“Your computer can’t connect to the remote computer because no certificate was configured to use at the Remote Desktop Gateway server. Contact your network administrator for assistance”.

Before we look into how to fix this, we need to understand how RDS publishing works with UAG:

1. A UAG client accesses a Forefront UAG portal using a Web browser and evaluating the endpoint compliance and session access policies defined on UAG by the administrator.
2. The end user launches a Remote Desktop application in the portal. The portal uses the RDS ActiveX component to activate the RDC client software running on the endpoint. If the ActiveX component doesn’t exist, it is installed.
3. The RDC client on the endpoint initiates an RDP-over-HTTPS connection with the Forefront UAG server.
4. The HTTPS connection terminates on the Forefront UAG server. Forefront UAG uses its integrated RD Gateway to handle the connection. Forefront UAG verifies that the user logged on to the portal successfully, and was authenticated using a session cookie, and then enforces the endpoint access policies.
5. An RDP session is established from Forefront UAG to the backend RDS hosts.

As you can see in step 3 and 4, the HTTPS connection terminates on the Forefront UAG server, which also acts a Remote Desktop Gateway. The error appears because no SSL certificate is configured by default on the RD Gateway running on the Forefront UAG computer.

The Solution

1. On the computer running UAG, open the RD Gateway Manager (Administrative Tools > Remote Desktop Services > Remote Desktop Gateway Manager)

   

2. You will see that “A server certificate is not yet installed or selected”. Click on View or modify certificate properties
   
   
3. Choose the option Select an existing certificate from the RD Gateway <computername>. Click the Import Certificate button.
4. Choose the certificate that matches the public DNS name of your UAG portal. In my case it is uag.tech.com – this is the URL that users connecting from outside your organization will type into the browser to get into the UAG portal. It can be the same certificate that you are using on your HTTPS trunk.

   

5. Click Import and OK.
6. Try to connect to the RDS Session Host from the UAG portal. It should work (if you have configured the application and your endpoint is compliant with the endpoint security policies that you defined).

While trying to request a certificate using the Certificates MMC snap-in on a computer running ISA Server, Threat Management Gateway (TMG) or Unified Access Gateway (UAG), you may encounter the following error:

“The RPC Server is unavailable”

This may be caused due to the RPC Filter in ISA Server/TMG. The RPC filter ensures security by monitoring RPC traffic flowing through the firewall. DCOM traffic is also dropped by this filter. However, DCOM is required to request a certificate.

To workaround this problem, disable strict RPC compliance setting on ISA Server/TMG. Here’s how to do it:

• Right click on Firewall Policy and choose Edit System Policy .
• Under Authentication, select Active Directory configuration group
• Uncheck the Enforce Strict RPC Compliance option.

• Click OK and apply your changes.

Of course, you will also need to create a firewall policy rule to allow all traffic from Localhost to Internal. Once you have requested the certificate you can revert these changes.

You can now request certificates from your ISA Server/TMG computer!

January 27, 2009

The internal transport certificate is automatically generated at the Exchange Server 2007 hub transport server and is usually valid only for one year. Once the certificate expires, you will receive continuous event 12019 errors in your Edge transport servers that are subscribed via Edgesync.

Event Type:      Error
Event Source:    MSExchangeTransport
Event Category:  TransportService
Event ID:        12019
Date:            1/27/2009
Time:            4:46:34 PM
User:            N/A
Computer:        EDGETRANSPORT
Description:
The remote internal transport certificate expired. Certificate subject: CN=<hub transport server>.

You can generate a new SMTP transport certificate on the Hub transport server by running the New-ExchangeCertificate cmdlet with no arguments.

This will automatically generate a new certificate. You then need to restart the Microsoft Exchange Edgesync service so that the Edge transport servers will be informed of the change.

If you have installed Exchange 2007 Client Access Servers in your organization, and if you have installed your SSL certificates (even commercial ones) on IIS, Outlook MAPI users may receive ‘Security Alert’ messages similar to the above in Outlook.

The name on the security certificate is invalid or does not match the name of the site.

This is because of the certificate that you have installed on IIS. Outlook 2007 MAPI clients use Client Access Servers for the Autodiscover service. The Autodiscovery web service (a virtual directory on the Client Access Server) is used for automatically finding the mailbox server for a given user. When the Autodiscover service is accessed by Outlook, and the name on the security certificate installed in IIS doesn’t match the internal FQDN of the Client Access server (CAS), this error results.

Suppose your company’s public domain name is mycompany.com. You may have obtained a certificate for webmail.mycompany.com and installed on the IIS of your Client Access Server. This is correct because users on the internet will type the public name.

However, the same IIS on the CAS is hosts the Autodiscover virtual directory as well and this certificate applies. Your internal domain name might be mycmpny.local and the client access server FQDN might be CAS1.mycmpny.local. Outlooks 2007 uses this internal name to connect to Autodiscovery, and hence the mismatch error.

To fix this problem, open Exchange Management Shell and type the following commands:

Set-ClientAccessServer -Identity CAS1 -AutodiscoverServiceInternalUri https://webmail.mycompany.com/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity “CAS1\EWS (Default Web Site)” -InternalUrl https://webmail.mycompany.com/ews/exchange.asmx

Set-OABVirtualDirectory -Identity “CAS1\oab (Default Web Site)” -InternalUrl https://webmail.mycompany.com/oab

Set-UMVirtualDirectory -Identity “CAS1\unifiedmessaging (Default Web Site)” -InternalUrl https://webmail.mycompany.com/unifiedmessaging/service.asmx

Pay attention to the text in red, you will need to change it to reflect your server’s running parameters. Recycle the MSExchangeAutodiscoverAppPool. Your users should no longer receive the security alert.

Your enterprise root CA is an important piece of your enterprise network. Especially if you issue a lot of certificates for a wide variety of purposes to your users.

Microsoft has re-released Internet Explorer 7.0 yesterday. The added features include:

A client wanted to publish two web services on SSL using ISA Server 2006: Outlook Web Access and Sharepoint Portal Server.

We know that ISA Server can only bind one SSL certificate per socket. This translates to one HTTPS URL/website per socket. What does this mean? Lets say I have my OWA at https://owa.shijaz.com/ and I have an SSL certificate issued to owa.shijaz.com. I also have my Sharepoint portal at https://portal.shijaz.com/ for which I have acquired a certificate with common name portal.shijaz.com.

While publishing, I can have only one web listener per socket and a web listener can accept at most ONE SSL certificate. If I apply the owa.shijaz.com certificate on my web listener, OWA will work fine, but users browsing to portal.shijaz.com will get a certificate warning/error. If I apply the portal.shijaz.com certificate, users browsing to owa.shijaz.com will get a certificate warning/error.

So what’s the solution? Wouldn’t it be great if we could order a certificate with common name *.shijaz.com and use the same certificate for both (or more) websites? Yes, you can! That’s called the WILDCARD Certificate!

Ordering a wildcard certificate is fairly simple, if you know how to order a normal SSL certificate. While generating an SSL request, simply enter *.yourdomain.com as the common name for the new certificate.

Wildcard certificates have a limitation that they are not available in 128-bit SGC and available only in standard encryption. The encryption level is decided by the user’s browser, rather than the certificate. So, if you’re securing a electronic payment website or a finance-related website, a wildcard certificate may not be what you should be looking at.

Outlook Web Access (OWA) on Exchange Server 2007 now supports direct file access, which means users can connect to internal file servers over the web using the standard OWA interface.

Readers of my earlier posting on Intelligent Application Gateway 2007 will agree that, if SSL is configured on Outlook Web Access (OWA) with internal file server access enabled, and it is published using ISA Server 2006, this gives you the equivalent of a browser-based SSL-VPN connection to the file server! Think about it.

This is good news for organizations who want to publish their file servers securely for home users but cannot afford a secure VPN solution.

Similarly, users can access internal Sharepoint sites from OWA if this is enabled on Exchange Server 2007. Certainly good news for organizations that tried to publish both OWA and SharePoint server over SSL on the same ISA Server installation — and then daunted away because it meant replacing the SSL certificate a wildcard certificate (which offers weaker encryption than a normal SSL certificate).

For step-by-step instructions on how to configure direct file access, see my article Configuring direct file server access from Outlook Web Access in Exchange Server 2007

Thawte gives away free personal email certificates at their website.

A thawte Personal E-mail Certificate in conjunction with the thawte Web of Trust allows you to secure and guarantee authorship of your e-mail communications by digitally signing and encrypting your e-mails.

IN SHORT: A personal email certificate lets you digitally sign all your outgoing email so that the recipient knows that you sent it!

Click here to get a certificate.

A word of caution here, read everything carefully whilst you apply for digital certificate. Remember the password and the question-answer pairs otherwise you will *never* be able to get another certificate for the same email ID. Also keep your password totally secret – a recipient can take you to court for documents that appear to be digitally signed by you, but was in reality signed in your name by an identity thief!