How to Configure SSL on XenDesktop Controllers to Secure XML Traffic

From XenDesktop Controller

IIS Installed on XenDesktop Controller

In this scenario, the XenDesktop controller has IIS installed and functioning to serve Web Interface or other web services. To complete this setup, you must request a Server Certificate and install it on IIS.

There are two ways to generate Server Certificates on IIS 7.x:

  • Create Certificate Request: This generates a CSR file to be submitted to a third party Certification Authority (CA) or to your internal Microsoft CA. For more information, refer to Microsoft TechNet article – Request an Internet Server Certificate (IIS 7)

  • Create Domain Certificate: This generates a CSR file and submits it to your domain registered Microsoft CA server. For more information, refer to the Microsoft TechNet article – Create a Domain Server Certificate on IIS 7.

    User-added image

After the Server Certificate is installed on IIS, ensure to set the Bindings to enable HTTPS on IIS by completing the following procedure:

  1. Select the IIS site that you want to enable HTTPS and select Bindings under Edit Site.

    User-added image

  1. Click Add, select Type as https, port number as 443, select the SSL Certificate that you installed and click OK.

    User-added image

  1. Open Registry Editor on XenDesktop Controller and look for the following key name.

    HKEY_LOCAL_MACHINESOFTWARECitrixDesktopServer.

    Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

  1. Verify that XmlServicesSslPort registry key exists with the correct value for SSL port. By default, it is set to 443.

    User-added image

  1. Change the XML service port.

    You can do this using PowerShell by running the following command:

    BrokerService –WiSslPort <port number>

    Note
    : If you decide to change the XML service port number on XenDesktop Controller, ensure to update the IIS port number as well under Bindings to match the new value.

IIS is not Installed on XenDesktop Controller

In this scenario, the XenDesktop Controller does not have IIS installed. As a result, there are a few ways to obtain a Server Certificate for the Controller:

  • Export an existing Server Certificate from another server in PFX format. When exporting the Server Certificate, ensure to select the private key as well.

  • You can use the Certreq utility from Microsoft to generate a Certificate Signing Request and submit it to a third party CA or your internal Microsoft CA server. For more information, refer to the Microsoft TechNet article – Certreq.exe Syntax.

    Note: Ensure to always import the PFX server certificates under the XenDesktop controller Local Computer certificate store and not My user account.

    User-added image

After the Server Certificate is installed on XenDesktop Controller, register the SSL certificate for HTTPS on the server. To accomplish this, Windows 2008 has a built-in utility called netsh that allows you to bind SSL certificates to a port configuration. For more information, refer to the Microsoft MSDN article – How to: Configure a Port with an SSL Certificate

The following is the command that you must use:

netsh http add sslcert ipport=0.0.0.0:<port Number> certhash=<hash number> appid={XenDesktop Broker Service GUID}

To obtain the certificate hash of a Server Certificate, open the Registry Editor, and open the following key name location and search for the Server Certificate that you want to use:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystemCertificatesMYCertificates

User-added image

An alternative to obtain this certificate hash

  1. Open the Server Certificate and under the Details tab, select Thumprint:

    User-added image

  1. Obtain the GUID of the XenDesktop controller Citrix Broker Service.

  2. Open Registry Editor and select Find.

  3. Search for Broker Service words. By default, the location is in HKEY_CLASSES_ROOTInstallerProducts (see the following example):

    User-added image

  1. Now that you have the certificate hash and Citrix Broker Service GUID, you can run the netsh command to bind the SSL certificate to port 443 and Citrix Broker Service. The following example is based on the GUID and certificate hash values taken from the preceding screenshots:

    Here is command to get the GUID

    Run the below command in Elevated command prompt on the DDC

    wmic product where “Name like ‘Citrix Broker Service'” get Name,identifyingnumber

    IdentifyingNumber

    ​C: >netsh http add sslcert ipport=10.12.37.231:443 certhash=298B8AB50322A5A601A57D4976875191D85A2949 appid={13C9D851-5D94-7C44-4A2B-218F89A28DC7}

    Note
    : For GUID, ensure to include dashes (-). Otherwise, the command cannot run successfully.

A successful bind looks as displayed in the following screen shot:

User-added image

From the Web Interface server

Configure the XenApp Web Site or XenApp Services Site to use HTTPS and 443 as Transport Type and XML Service port respectively under Server Farms.

User-added image

Note: To have a successful SSL connection to the XenDesktop 5 Controller, ensure that Web Interface has installed the Trusted Root certificate (under Local Computer certificate store).

Related:

  • No Related Posts

Applications not enumerating on StoreFront

Check for valid certificates issues to the store on the DDCs. If new cert is installed, rebind XML service to the new certificate by doing the following on each DDC:

In cmd as admin:

wmic product where “name like ‘Citrix Broker Service'” get IdentifyingNumber, name, version

This will show current AppID associated with the Citrix Broker Service

netsh http show ssl cert

This will display the current certificate hash associated with the App ID found in the previous command. If it does not match the new thumbprint of the new certificate:

http delete sslcert 0.0.0.0:443

netsh

http addssl cert ipport=0.0.0.0:443 certhash=<new thumbprint of cert with no spaces> appid={appid}

If successful, please try and log back into Storefront and validate apps enumerate

Related:

Communication times out while forwarding to RemoteHcl WCF server

Specify the cloud connector FQDN in the WinHTTP proxy bypass list. The following example shows the addition of the cloud connector with an FQDN of `bvcchard2.hardening.local` to the WinHTTP proxy bypass list:


After setting the bypass list, restart the cloud connector to apply the new WinHTTP settings.

Important

When specifying the bypass list, use semicolons, not commas, to separate the items in the list. The netsh winhttp set proxy command accepts the comma syntax, but the resulting bypass list is ignored. Do not use “*” wildcards when performing this operation.

For example:

netsh winhttp set proxy proxy-server=”http=10.10.10.50:8080;https=10.10.10.50:8080″ bypass-list=”<-loopback>;bvcchard2.hardening.local”

In the example above, the IP addresses are the proxy server and port.

Related:

Communication times out while forwarding to RemoteHcl WCF server (HclOverWebsockets feature toggle enabled)

Specify the cloud connector FQDN in the WinHTTP proxy bypass list. The following example shows the addition of the cloud connector with an FQDN of `bvcchard2.hardening.local` to the WinHTTP proxy bypass list:


After setting the bypass list, restart the cloud connector to apply the new WinHTTP settings.

Important

When specifying the bypass list, use semicolons, not commas, to separate the items in the list. The netsh winhttp set proxy command accepts the comma syntax, but the resulting bypass list is ignored. Do not use “*” wildcards when performing this operation.

For example:

netsh winhttp set proxy proxy-server=”http=10.10.10.50:8080;https=10.10.10.50:8080″ bypass-list=”<-loopback>;bvcchard2.hardening.local”

In the example above, the IP addresses are the proxy server and port.

Related:

Vulnerability in License Server and Snap-in for Desktop Studio, aka Heartbleed

Secure Configuration of Licensing Heartbleed Update

In response to the recent Heartbleed vulnerability in OpenSSL (CVE-2014-0160) Citrix released a security advisory, CTX140605, advising customers of its potential effects on some Citrix Licensing components. As part of the Citrix response to this vulnerability, a configuration document was published providing manual steps to temporarily mitigate the effects of this vulnerability on the affected components.

Citrix has released new versions of the product that are not affected by this vulnerability and this article provides detailed instructions on ensuring the updated licensing components are securely configured. New product versions are downloadable here.

License Server for Windows

For installations of the License Server for Windows

By default, communication to version 11.11.1 of the License Administration Console is carried out using HTTP on port 8082. Citrix recommends that administrators configure the License Administration Console to use HTTPS using the following steps:

  1. On the License Administration Console go to Administration > Server Configuration > Secure Web Server Configuration. Select Enable HTTPS.

  2. To enable HTTP to HTTPS redirection, select Redirect non-secure web access to secure web access click Save and restart the license server. This moves HTTP traffic to go over HTTPS.

  3. For systems that previously had the Citrix Simple License Service Windows Service installed, the service has been combined into Citrix Web Services for Licensing that is installed by the Citrix Licensing installer. This service no longer requires a separate installation and is configured by the License Server installer.

Citrix Licensing Administration Snap-in

The Citrix Licensing Administration Snap-in is normally installed on computers with Citrix Desktop Studio. Some installations with custom configurations might also have this Snap-in installed standalone. The Citrix Licensing Administration Snap-in communicates with the Web Services for Licensing component over port 8083. Communication to the License Server over this port was manually blocked in the Windows firewall by the prior suggested Heartbleed mitigation.

Log on to each computer where the Administration Snap-in is installed as an Administrator and open a command prompt. Note that on Windows Server 2008 and later the command prompt might have to run with elevated permission if UAC is enabled. Type the following command:

netsh advfirewall firewall delete rule name="Temporary Block for Licensing Admin PowerShell" dir=out protocol=TCP remoteip=<IP of License Server> remoteport=8083

For additional details on netsh firewall configuration see Netsh AdvFirewall Firewall Commands.

Impact

Citrix Studio and custom installations of the Citrix Licensing Administration Snap-in will now be able to administer licensing.

Citrix Usage Collector

Some customer environments might have the Citrix Usage Collector installed. Servers running the Citrix Usage Collector must have outgoing port 443 re-enabled in the Windows Firewall.

Log on to the Citrix Usage Collector servers as an Administrator and open a command prompt. Note that on Windows Server 2008 and later the command prompt might have to run with elevated permission if UAC is enabled. Type the following commands:

netsh advfirewall firewall delete rule name="Temporary Block Web Services For Licensing" dir=out protocol=TCP program="c:Program Files (x86)CitrixLicensingUsageCollectorctxurt.exe" remoteport=443

Note that for 32-bit systems the program path is “c:Program FilesCitrixLicensingUsageCollectorctxurt.exe”.

For additional details on netsh firewall configuration see Netsh AdvFirewall Firewall Commands.

Impact

Now Citrix Usage Collector can safely transmit the usage data over the network.

Related:

“Cannot complete request” when logging on via NetScaler using dual factor authentication and SSON to StoreFront Server 3.14

The certificate hash shown did not match the one binding to the SSL port 443 in IIS (correct cert hash starts with 89BA19BD4…)

Delete the legacy certificate causing errors via CLI command

Netsh http delete sslcert ipport=0.0.0.0:443

Note: The legacy certificate was associated with another set of StoreFront servers (3 SF servers) instead of the new certificate created for this new set of 2 SF servers.

Validation

When issuing the CLI command:

“netsh http show sslcert” – we now see that the certificate is gone

When testing logging on to the NetScaler, we were able to SSON to SF server using the 2 factor authentication in place and keeping the setting “Enable Loopback Communication” set to ON (Under SF – Edit Receiver for Web Site – Advanced Settings)

Related:

  • No Related Posts

7005894: IDM Remote Loader on Windows 2008 R2 and PWFilter firewall settings

The existing Windows Firewall configuration prevents the remote loader from receiving any password changes as captured by the PWFilter.dll on other Domain Controllers within the domain. To solve this problem, do the following:

On the Windows Server firewall, (required only on the server which hosts the Active Directory Remote Loader) add the following rules:

— Inbound Rules —

Name Group Profile Enabled Action Override Program Local Address Remote Address Protocol Local Port Remote Port Allowed Users Allowed Computers.

Rule 1

dirxml port 8090 IN Domain Yes Allow No Any Any Any TCP 8090 Any Any Any

Rule 2

dirxml process dirxml_remote.exe IN Domain Yes Allow No %SystemDrive%NovellRemoteLoaderdirxml_remote.exe Any Any Any Any Any Any Any

NOTE: The port number should be the port number specified on the Remote Loader configuration. So instead of 8090, it will be whatever you specified in the configuration.

No specific Outbound Rules are needed.

The rules can be given any name.

They rules must be assigned to at least the Domain profile.

If using the 64 bit remote loader, the path differs: %SystemDrive%NovellRemoteLoader64bitdirxml_remote.exe

The rules can be also added from the command line using the following commands, modifying the port and path as applicable:

netsh advfirewall netsh advfirewall firewall add rule name="dirxml port 8090" dir=in action=allow enable=yes profile=domain protocol=TCP localport=80
netsh advfirewall firewall add rule name="dirxml process dirxml_remote.exe" dir=in action=allow program="%SystemDrive%NovellRemoteLoaderdirxml_remote.exe" enable=yes profile=domain

Related:

7023313: How to changes the SSL certificate used within DRA REST Services

This document (7023313) is provided subject to the disclaimer at the end of this document.

Environment

NetIQ Directory and Resource Administrator REST Services 9.0.2.x

NetIQ Directory and Resource Administrator REST Services 9.0.3.x

NetIQ Directory and Resource Administrator REST Services 9.1.x

NetIQ Directory and Resource Administrator REST Services 9.2.x

Situation

The SSL certificate(s) used by the DRA REST Services application and / or the DRAClient Web site have expired.

The SSL certificate(s) used by the DRA REST Services application and / or the DRAClient Web need to be changed.

Resolution

In order to change the SSL Certificate used by DRA REST Services and DRA Web Client, you will need to go over the following steps. All of the steps below require local logon to the Windows OS hosting the DRA REST Services and DRAClient Web Site. All steps requiring a Windows CMD line should be done using an Administrator CMD

prompt.

  • Step 1 – Configure the new certificate on the Server
  1. Import the new updated SSL certificate to the REST Server and IIS Server
    1. If using the same SSL Cert for IIS and REST Services, the new certificate can be added within IIS
    2. If using one certificate for REST and one for IIS, additional SSL certs can be added using Windows Certificate Services MMC Snap-In
    3. Certs used to DRA REST and WEB should be hosted in the Local Machine’s Personal Certificate Store
  • Step 2 – Locate and copy the new Certificate’s Thumbprint
  1. Open the certificate properties and locate the Certificate Thumbprint property
    1. The certificate properties can be viewed via IIS Manager
    2. The certificate properties can be viewed via the Certificate Store Windows MMC Snap-in
    3. Sample thumbprint property: ‎7c 56 b6 9b b9 ad 02 66 fa f0 22 cc 10 89 fd bf 77 2e b1 f0
  2. Use a text editor, such as Windows Notepad; to remove the spaces within the certificate properties
    1. Sample thumbprint without spaces: ‎7c56b69bb9ad0266faf022cc1089fdbf772eb1f0
  • Step 3 – Update the REST Services Application with the new certificate
  1. Locate and copy the Existing Application ID, and port for the IIS Server
    1. From an Administrator CMD Prompt: run netsh http show sslcert
    2. The REST Services Application default port is 443

    3. Sample Application ID {8031ba52-3c9d-4193-800a-d620b3e98508}
  2. Delete the existing SSL binding for the REST Services Application
  3. From an Administrator CMD Prompt: run Netssh http delete sslcert ipport=<REST Services Application IP Address and Port listed from the show ssl cert output>
  4. Bind the new SSL cert to the REST Services Application
  5. From an Administrator CMD Prompt: run netsh http add sslcert ipport=<REST Services Application IP Address and Port listed from the show ssl cert output> certhash=<ThumbPrintID of new certificate>appid=<Application ID, including the {}>
  • Step 4 – Change the SSL Certificate used by IIS
  1. Locate and copy the Existing Application ID, and port for the REST Services Application
    1. From an Administrator CMD Prompt: run netsh http show sslcert
    2. The IIS Website default port is 443

    3. Sample Application ID {4dc3e181-e14b-4a21-b022-59fc669b0914}
  2. Delete the existing SSL binding for the REST Services Application
  3. From an Administrator CMD Prompt: run Netssh http delete sslcert ipport=<IIS Web site IP Address and Port listed from the show ssl cert output>
  4. Bind the new SSL cert to the REST Services Application
  5. From an Administrator CMD Prompt: run netsh http add sslcert ipport=<IIS Web site IP Address and Port listed from the show ssl cert output> certhash=<ThumbPrintID of new certificate>appid=<Application ID, including the {}>


Cause

Both the IIS Website used to host the DRA Client (known as DRAClient) and the REST Services Application are bound to an SSL Certificate. The initial install of the DRA REST Services will configure the binding. It is possible to have the existing SSL certificate expire. There might also be a need to change from one certificate to another.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

  • No Related Posts

Network browse issue after patching SEP clients on Server 2012 R2

I need a solution

I have seen an issue only on Server 2012 R2.  After a restart, you cannot browse UNC paths to any resource.  At first, it seemed completely random.  Then, as I began tracking each month, I found that it was about 40% of Server 2012 R2 servers behaving this way after taking a SEP upgrade and then restarting.  It doesn’t seem to matter if the upgrade was from an install package was pushed from SEPM or if the client patch was applied. 

When I find the issue of not being able to browse a UNC path, I find that Event ID 4202 is logged. 

Event ID: 4202
Srouce:  iphlpsvc
Unable to update the IP address on Isatap interface isatap.{7E4F31EF-659F-46FE-9D1C-12B983DE5510}. Update Type: 0. Error Code: 0x57.

I have gotten into a routine that after every maintenance window, I run a powershell script to look for this event ID on all 2012 R2 servers, and then log in to see if the server is OK or exhibiting the symptom of not being able to browse UNC paths (Group Policies won’t apply either, as they are unable to access the share on the domain controller in this condition).  If I cannot browse, I either reboot the server, or if I can’t reboot the server, I restart the Workstation service and hope the dependent services don’t lock up.

The only solution I have been able to find is to disable the isatap adapter:

netsh int isatap set state disabled

I have not yet gotten approval to disable this on all servers.

Has anyone else experienced this issue, and if so, what have you done to work around this?  Did you completely disable IPv6, or disable the isatap adapter or ???  This has to be a timing thing with both the sisnat-{GUID}.exe processing at the time the isatap interface is initializing. 

Thanks,
Joel

0

Related:

Connectivity fails for Store Front and PKI on the XenMobile Cloud Connector using Proxy

Test Connectivity fails for Store Front and PKI on the XenMobile Cloud Connector using Proxy with bypass local address containing Wild card characters.

Proxy settings like below

User-added imageUser-added imageUser-added image

Proxy logic does not honour wildcard characters when they are specified in the bypass list, It’s a known issue will be fixed in future version.

Workaround to resolve:-

Add the specific URLs for StoreFront and the PKI server to the bypass list instead of using a wildcard.

1. Remove the existing proxy setting by executing the following from the command line on the connector machine: netsh winhttp reset proxy

2. Reboot the connector machine

3. Open IE on the connector machine > Browse to Internet Options > Connections > LAN Settings > Proxy Server > Advanced

4. In the exceptions text field, enter the specific URLs that are currently experiencing issues like StoreFront and PKI server URLs.

5. Save the changes and close IE

6. Import these updated proxy settings by executing the following from the command line: netsh winhttp import proxy source=ie

7. Reboot the connector machine again

Please note that all connector services must be restarted whenever proxy changes are made on the proxy machine. It is recommended to restart the entire connector machine in order to ensure that following services are started

User-added image

Related: