One of our customers is using a Citrix NetScaler appliance for SSL VPN capabilities for remote users. I tried to start an application (RDP Client) through this SSL VPN solution, but I couldn’t succeed. I was able to login and I would see all the published applications, but when executing one, I received the following error message:
The remote session was disconnected because there are no Terminal Server License Servers available to provide a license. Please contact the server administrator.
So I did contact customers system engineers, because I thought the problem was related to the customers Terminal Server License Server environment. I thought this, because I was still able to use SSL VPN solutions from other customers. They couldn’t find any solution for my problem and that’s correct.
The solution for the problem is found on my own laptop. I stumbled upon this TechNet article. I opened my registry and deleted the following folder and subkey:
This did the trick. I was able to execute the published applications again without any problem after rebooting my laptop.
Using a Microsoft CA is very common in network to issue self-signed certificates. Last week I had to configure a Windows IIS server with client certificate authorization. Remote people (non Active Directory users) need a client certificate to browse to a specific website. The communication between the remote user and the website is secure by a default SSL web certificate.
The website is configured to require SSL and client certificate authentication. Within IIS I configured Client Certificate Mappings to authenticate the remote users. To create Client Certificate Mappings I had to generate client certificates. Client certificates can be generated by installing a Microsoft Certificate Authority. You can also use OpenSSL to generate client certificate, but this customers has a complete Microsoft Windows environment, so I decided to install a Microsoft CA.
You can install two kinds of CA’s:
A standalone CA does not issue certificates independent of administrator intervention. The reasoning for this is based upon the fact that a standalone CA doesn’t tap into a local or domain user account. Instead, it relies upon human intervention as a ‘last check’ method prior to issuing a certificate. Standalone CA certificates are also not distributed automatically, but further require a delivery method, such as group policy (for local domain users), or via further human intervention. For Web and Internet access, this is the type of CA to use.
The enterprise CA adds a new level of flexibility and ability to the certificate picture, but also added complexity. The Enterprise CA is integrated with Active Directory, and only provides certificates to members within that Active Directory. This pretty much kills the idea of having both an extranet or secure Internet communications along with secure local domain communications. Enterprise Certificates can, however, be used in a manner that falls within the ‘not often, but still really nifty’ category. Enterprise Certificates can be used to bypass repeated and redundant domain authentication, and when properly configured, can be used to further enhance the standard Kerberos authentication methods. Enterprise Certificates are automatically issued for every user account when it is created. The certificate itself, since it is a file, can be stored on any storage location and can still be valid. In keeping along this train of thought, it is possible to place a certificate on a card or plug-in device that can be used to authenticate a user during the normal Kerberos authentication process. These specialized devices are called Smart Cards, and while Smart Card implementation is somewhat expensive, several large corporations have implemented this technology as an added safety factor. […] Source
I decided to install a Standalone CA server, so client certificates can be generated with credentials from the remote users. When using an Enterprise CA, the client certificate contains the credentials from the Windows users who generates the request. The Enterprise CA requires Windows Integrated Authentication to perform a request.
Everything is working perfectly, the only caveat was the validity period of the client certificates. By default, the lifetime of a certificate that is issued by a Stand-alone Certificate Authority CA is one year. The validity period that is defined in the registry affects all certificates that are issued by Stand-alone and Enterprise CAs. For Enterprise CAs, the default registry setting is two years. I used the following procedure to change the default validity period from one year to two years.
I found this procedure in the Microsoft Knowledge Base and used it on Microsoft Windows 2003 and Microsoft Windows 2008.
My colleagues and I configure a Windows server from time-to-time. Mostly when we configure a server, it is a server which is placed in the DMZ zone, like an ISA Reverse Proxy or Citrix Secure Gateway. Recently I spoke with a colleague and we started discussing the running services under Windows.
After installing a Windows server with the default settings, I am stunned about all the different services which are running on the newly installed server. So most of the time, I stop a lot of these services and configure them to be started manually after a reboot. I do not only stop services from the Services MMC, but also settings on the network card, like Client for Microsoft Windows, File and Printer Sharing for Microsoft Windows, Registrar connection in DNS, LMHOST lookup and NetBIOS over TCP/IP.
Normally a server in the DMZ doesn’t have any printers connected, so I stop the Print Spooler service, but when connecting to the server with RDP the following Event logging shows up in the Event Viewer –> System log:
Description: Error communicating with the Spooler system service. Open the Services snap-in and confirm that the Print Spooler service is running.
Looking at the Internet, there are different ways to stop is error from showing up in the Event viewer. All solutions are related to stopping the mapping of printers during the RDP log-in process. My colleague told me that he always uses a registry entry to disable the logging and guess what, this specific registry entry is shown below:
Registry folder: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd
Entry name: fEnablePrintRDR
Value: 0x00000000 (0)
After adding this registry key the warning message in the Event Viewer won’t show up again.