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
- A user browses to and authenticates on the Web Interface server over HTTPS
- The Web Interface server will send the user name of the person logging on to a XenApp server over port 443
- 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.
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.
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.
No comments:
Post a Comment