by Shijaz Abdulla
on 22.02.2010 at 22:22
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:
- 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.
- 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.
- The RDC client on the endpoint initiates an RDP-over-HTTPS connection with the Forefront UAG server.
- 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.
- 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.
- On the computer running UAG, open the RD Gateway Manager (Administrative Tools > Remote Desktop Services > Remote Desktop Gateway Manager)
- You will see that “A server certificate is not yet installed or selected”. Click on View or modify certificate properties
- Choose the option Select an existing certificate from the RD Gateway <computername>. Click the Import Certificate button.
- 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.
- Click Import and OK.
- 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).
by Shijaz Abdulla
on 06.02.2010 at 00:29
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!
by Shijaz Abdulla
on 27.01.2009 at 16:47
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
Time: 4:46:34 PM
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.
by Shijaz Abdulla
on 10.04.2008 at 13:56
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 “CAS1EWS (Default Web Site)” -InternalUrl https://webmail.mycompany.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “CAS1oab (Default Web Site)” -InternalUrl https://webmail.mycompany.com/oab
Set-UMVirtualDirectory -Identity “CAS1unifiedmessaging (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.
by Shijaz Abdulla
on 08.04.2008 at 07:24
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.
A root CA also needs to be highly secured, both physically and over the network, because it contains the private key. A downtime on the root CA is seldom noticed because there is minimal need for using the server – except while issuing or renewing certificates. In fact, the Microsoft best practice is to power down your root CA when not in use.
Now, what to do if your enterprise root CA crashes? Information about the enterprise root CA is written on the Active directory, in the registry of the Windows Server hosting the CA, and most important of all, the private key is also stored on this machine.
Quite obviously, In the event of a total failure, a backup is required. Taking a backup of the root CA is often neglected. Believe me, it takes virtually no time to take a backup and it’s the only way to restore your CA with all private keys intact.
Microsoft KB Article 298138
explains how you can backup your CA and move it to separate hardware. The procedure is also applicable if the hardware running your root CA crashes totally and you want to set up the same CA on a new server hardware.
In this post, I will explain how you can automate a backup of the CA. Restoration can be done as per the article mentioned above. Write a script “backupCA.bat” with the following code:
certutil -backup D:backup
certutil -backupkey D:backup
certutil -backupdb D:backup
reg export HKLMSYSTEMCurrentControlSetServicesCertSvcConfiguration D:backupregbackup.reg
Make sure the D:backup folder is picked up by your centralized tape backup solution. Be extra careful with the tape because this contains the private key of your CA. Your organization should have the handling of tapes included in the security policy.
by Shijaz Abdulla
on 05.10.2007 at 12:49
Microsoft has re-released Internet Explorer 7.0 yesterday. The added features include:
- The Menu bar will be turned on by default (thankfully)
- Removed the Windows Genuine Advantage validation requirement for expanded availability to Windows PC users (legal copy of Windows… or otherwise)
- For first time users, the first-run experience includes a new, easily accessible overview
- For all users, the online Internet Explorer 7 tour has been updated to include how-to’s on great new features like tabbed browsing.
- Microsoft has also included a new MSI installer for enterprises that simplifies deployment for customers. IT Administrators can tailor to their organization’s needs by using the Internet Explorer Administration Kit (IEAK) and deploy the package to relevant units within their organization using e.g. Group Policies or Systems Management Server (SMS).
Microsoft takes its commitment seriously in helping protect the entire Windows ecosystem. Security enhancements to Internet Explorer 7 include a built-in Phishing Filter that prevents an average of 900,000 visits per week to known phishing Web sites!
Additionally, Internet Explorer 7 is the first and only browser to natively support Extended Validation SSL Certificates to help prevent online fraud.
How can I get it?
by Shijaz Abdulla
on 01.10.2007 at 09:31
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.
by Shijaz Abdulla
on 24.08.2007 at 13:46
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
by Shijaz Abdulla
on 03.07.2007 at 10:05
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!