Securing Citrix Data Transport pt.i

The XML Service


Communication between the Web Interface and the server running XenApp involves passing user and resource set information between the Web Interface and the Citrix XML Service in the server farm.


In a typical session, the Web Interface server and XenApp farm server use a TCP/IP connection and the Citrix XML protocol to pass the information.
There are three transport options for this traffic.

• HTTP. Sends data over a standard HTTP connection. Seems to be the standard from my experience and relies on other provisions for the security of the data transmitted. 
• HTTPS. Sends data over a secure HTTP connection using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Requires IIS be installed on XenApp servers. 
• SSL Relay. Sends data over a secure connection that uses the SSL Relay running on a server running XenApp to perform host authentication and data encryption.

This post will discuss using SSL relay to secure the traffic in a XenApp  6.5 farm with Provisioning Services streamed servers.

What roles does SSL Relay play in securing XML traffic?

Typical traffic flow is illustrated in the diagram below, using SSL Relay to encrypt traffic between the Web Interface and XenApp server. 

Web Interface traffic flow

1. A user browses to and authenticates on the Web Interface server over HTTPS
2. The Web Interface server will send the user name of the person logging on to a XenApp server over port 443
3. The XML service on the XenApp server may return the following information to the Web Interface server over port 443

•  farm server list 
•  farm name 
•  list of published apps for that user
•  all details of the published apps 
•  ACL for the published apps

What are the prerequisites?

A functioning Public Key Infrastructure (PKI) that you can generate certificate templates from, and access to group policy to configure certificate Auto-enrollment for your Citrix servers. 

Step 1. Create Certificate

Excellent guide in this CTX article, can't add a thing to the process as it's spot on: http://support.citrix.com/article/CTX128257

If you have any problems with your Certificate Authority, this post is GOLD, it has saved my bacon before: http://blogs.technet.com/b/askds/archive/2007/11/06/how-to-troubleshoot-certificate-enrollment-in-the-mmc-certificate-snap-in.aspx

Step 2. Create GPO for Auto-enrollment

Computer Configuration - Windows Settings - Security Settings - Public Key Policies/Certificate Services Client - Auto-Enrollment Settings

Set Configuration Model to COnfigured and Tick both Renew expired certificates and Update Certificates options.

Right click on Automatic Certificate Request Settings, select New Automatic Certificate Request, 

Select Computer as the certificate type and complete the wizard. 

Step 3. Verify change

After this policy is configured and applied to your XenApp and Webinterface servers,reboot your web interface server. 

To verify that auto-enrollment is working, open the MMC on the Web Interface and XenApp servers, add the certificates snap-in, selecting your local computer as the target. There should be a certificate under the Personal node that corresponds to the FQDN of the server you are logged onto 

Step 4. Secure XenApp

Log onto a XenAPp server and open the SSL relay tool:

C:\Program Files (x86)\Citrix\SSLRelay\SSLRelayconfig.exe

Click OK at the first message that pops up as this is just saying nothing has been configured yet

Place a tick in the Enable SSL relay box, confirm your other settings are correct (including that you have a valid certificate in the local store) 
Next, add all the farm servers as hosts and close the tool.

On your Web Interface server, change the connection settings for your sites by selecting SSL relay under the Server Farms option box.


And that should do it!


Provisioning Services


PvS throws a small spanner in the works, as the certificate that is loaded on the golden image will not be usable when working servers are spun up from that image.


Instead of certificate autoenrollment, use a wildcard certificate - e.g.: *.domain.com, and generally do the same as above.

Microsoft Forefront Threat Management Gateway - traps for young players pt. ii

A couple more to add:


Access to file shares/servers can’t be restricted by user group. CIFS traffic will not work with any rule that tries to authenticate the user. Further details here: http://support.microsoft.com/kb/913782 but Microsoft’s summation is:


 The Firewall Client program can only process Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) traffic that is passed through the Windows Sockets API (Winsock). CIFS connections do not use Winsock calls. Therefore, the Firewall Client program cannot authenticate CIFS connections to the server. If you configure a rule that requires CIFS authentication, the connection will be denied.


This came about configuring TMG array for internal network segmentation, and this is a bit of a pity, as though authenticating the rules themselves isn't a showstopper (NTFS permissions will handle the security) logging of file server access would have been good.


Also,
When moving TMG servers from a standalone array to an Enterprise Managed array, make sure you configure the correct routes (under the Networking node) on the Enterprise Array before you join the TMG servers, this may save you a bit of time 

Microsoft Forefront Threat Management Gateway - traps for young players pt. i

While rolling out a TMG infrastructure recently, I have come across a bunch of issues. I’ll be making some documentation of them below, as I haven’t found much on Google that seemed to indicate the issues I have been having.


Issue #1 – Wrong certificate on Web Listener

At the start of the project I wanted to stage all my publishing rules on the reverse proxy TMG, so I created everything with all the right settings, except for the SSL certificate that would be used in production. No problem, I thought, I’ll use the built in TMG server cert until I get the real ones, and just swap them out in the Listener properties.


This was not straightforward. I loaded the correct UC cert and changed the properties of the listener to use this cert for the defined IP address - it all looked good in the TMG console, but when I browsed to the published OWA site, I found that it was using the TMG server certificate. The only way I could fix was to delete the publishing rule and associated listener. And then export the UC cert with key - reimported, recreated everything and it worked.


Issue #2 - WA - LDAPS authentication not working, only non-secure LDAP on Workgroup TMG


I installed the Enterprise CA cert on the workgroup member TMG server, this allowed TMG to trust DC for LDAPS.


Issue #3 Reinstalling TMG fails on Reporting Services

I had to reinstall two TMGs as we had to change network template from single NIC to Back Firewall. I uninstalled everything, but could not reinstall.

I had to uninstall SQL client, manually delete all SQL folders under Program File folders and uninstall ADLDS
After this TMG reinstalled just fine.

Issue # 4 Published CRM issues 

CRM published through TMG was not working at all to start with – this was caused by the bridging of https 443 traffic to http 5555 – the firewall saw the 5555 traffic as unidentified traffic and denied it.

This turned out because I had “Enable Forefront TMG Client support for this network” disabled (Networking -> Networks -> Internal Properties -> Forefront TMG Client)

Once this was working, I found that CRM was popping up a Windows Authentication box, instead of the CRM Forms logon.

This was because the "Internal Network" in the IFD configuration is blank on the CRM server, so the CRM Server thinks our connections in via the TMG are from internally, therefore it is expecting Kerberos authentication to be used rather than forms authentication.

Still, the connection was bad, sometimes I would get “Internet Explorer cannot display the webpage”, and when I was logged on it would time out rather quickly.

What I found to help was to disable HTTP Compression, the compression filter and the caching filter.

CRM is still a little bit niggly, but a lot better :)


Issue #5 TMG HTTPS Inspection blocks Skype

When using TMG as the forward proxy, HTTPS inspection kills Skype. I have found no answer for why on the internets, but my theory is that it is not the inspection of the traffic itself, but that when this rule is enabled, TMG must verify the certificates at the destination and because these maybe self signed then it will simply not initiate the connection. This would explain why you can’t set a source exemption for this rule and have it work

I am sure there will be more to come in another post.

To change network interfaces on XenDesktop machine catalogs

When you are adding a new XenDesktop host to your XenDesktop 5 deployment, you will select the guest network that all created desktops will have as thier default.

As with most configuration in XenDesktop 5, changing what this network is after the initial setup requires PowerShell and some manual intervention

For existing virtual desktops, reconfigure the network interfaces manually through the vCenter console – i.e. right click the desktops and edit settings, change network label.

To ensure that all future desktops are then created with the correct interface the default has to be changed using PowerShell
First, open a PowerShell console as administrator.

Load the Citrix cmdlets:
Add-PSSnapin "Citrix*"

Discover the network path:
get-item xdhyp:\hostingunits\<hostname>

Where ‘hostname’ is what the virtual infrastructure is named as in the XenDesktop Desktop Studio console. (In the main view select Configuration -> Hosts -> and look for the server name for the vCenter server or XenServer resource pool)

Type this command:
get-item xdhyp:\hostingunits\<hostname>

The results should be returned, and one line will be:
NetworkPath          : XDHyp:\Connections\Melbourne\ESX.datacenter\Lab.cluster\OLD.network

Use the information to change the network path as required:
set-item xdhyp:\hostingunits\<hostname> -networkpath XDHyp:\Connections\Melbourne\ESX.datacenter\Lab.cluster\NEW.network

New Network Path will be the network interface name as it appears in vCenter console, appended with “.network”.
After this is complete, any new XenDesktop virtual machines created using MCS will have the new network interface assigned automatically.

XenApp Connector for System Center Configuration Manager (SCCM) 2007 R2 – PT I.

A quick overview of the Connector

The newish Connector for XenApp/Config Manager is great. I like the automation of installing applications out of hours, although I haven’t used the publishing aspect of it yet, just the deployment tool.

http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=2301676

At a high level, the Connector is the integration point for XenApp 6 and SCCM 2007 R2. With the Connector you can advertise applications to XenApp and let the Connector handle draining the server, notifying the users of impending installs and logging them off. Once the application is installed, the Connector can publish the applications and also push users back on to the server.

The Connector uses the Citrix Power and Capacity Manager to handle the draining of servers,which is done by changing the logon preference from 1^st Choice to whatever the lowest choice is.

Installation is pretty straight forward, but there are some tweaks you can make to the Connector to get it working just the way you want. 

With the XenApp Connector, application advertisements run a task sequence

When an advertisement is run the following actions happen:

1.    Citrix Power and Capacity Management changes the connection preference for servers targeted in the Collection and that haven’t processed the advertisement to drain user connections.

2.    Then the task sequence will run on the targeted server, if there are user sessions then the advert will fail. The Advertisement Wait timeout starts counting from the first time the server processes any mandatory assignment

3.    If a previous mandatory assignment has failed, and there are still user sessions, and the Advertisement Wait period has passed, then the following will happen:

              i.        Users will be warned of impending logoff, and asked to save their work

             ii.        Users will be logged off after the time set expires

            iii.        Server logons will be disabled

            iv.        The application will install

             v.        Logons will be enabled on the server

            vi.        Logon preference will be set back to normal

Change Advertisement wait times

When installing the Connector console extension, the default settings for the Advert Wait time is three days, and it is not possible to set it to less than one day but more than 0 through the GUI. To do this, the following file must be changed on any machines the console extension is installed on.

Browse to

C:\Program Files\Citrix\XenApp Connector for ConfigMgr 2007\
Edit the XASCCM.config file in notepad
The file should look like this:

<XASCCMConfig version="1.00">

  <XADistributionPackage>

    <ForceDateInterval>0.00:10:00</ForceDateInterval>

    <ForceOutWarningNotification>

      <LastMinuteInterval>00:05:00</LastMinuteInterval>

      <MessageTitle>Upcoming Maintenance</MessageTitle>

      <MessageBody>Please save your work and logoff, server will be in maintenance mode in 5 minutes.</MessageBody>

    </ForceOutWarningNotification>

  </XADistributionPackage>
</XASCCMConfig>

XenDesktop Machine Creation Service

So, I’ve just finished building a XenDesktop 5 proof of concept for a client:

XenServer 5.6 FP1

Provisioning Server 5.6 SP1

XenDesktop 5

Windows 7

All was going well and everything was setup, I had the golden image ready. So I go to start deploying the desktops when I discovered there is no XenDesktop Wizard! Doh!

Just my luck XenDesktop 5 now has its own deployment wizard, the Machine Creation Service (MCS). It is totally sweet, you just do the following in the Desktop Studio:

Hook your XenDesktop controller up to the hosting XenServer

Start the MCS wizard

Select how many desktops, select your primary VM, naming, AD membership.

Next, next finish – you have a bunch of virtual desktops!

Not sure if this feature will unseat PVS, but it is definitely the go for POC’s and small implementations.

Nice one Citrix J

Smart Access in XenApp 6

I discovered that I can’t apply blanket XenApp policy to all Access Gateway Enterprise Edition connections in XenApp 6. 

A restrictive policy was created that disables drive and printer mapping.

When I tried applying the policy to all Access Gateway connections, the policy settings were ignored (i.e. drives and printers were mapped).

 

But by adding the specific Access Gateway server name and policy, the policy started to apply. 

This is not as it should work though. The documentation says the following:

If no filters are configured for an enabled policy then all of the configured settings will be applied