Quantcast
Channel: Secure Gateway – Carl Webster
Viewing all articles
Browse latest Browse all 14

Learning the Basics of Citrix XenApp 5 for Windows Server 2003 and XenServer 5.5 (Part 10 of 10)

$
0
0

In Part 9 of this 10-part series, you learned to allow external access to the published applications using the AltAddr method.  In the final part of this series, you will learn how to:

  • Generate an SSL certificate request
  • Purchase an SSL Certificate from GoDaddy
  • Complete the certificate request
  • Test the certificate
  • Install and configure Citrix Secure Gateway 3.1.2
  • Test external and internal secure access to published applications

Using Citrix Secure Gateway (CSG) is better than using AltAddr because CSG is SSL based and helps to secure the logon and data traffic.  CSG is also easy to install and configure

When you completed Part 9 you were in the Citrix Web Interface Management Console (WIMC).  Before CSG can be installed and configured, the AltAddr configuration settings need to be removed.

Click XenApp Web Sites in the left column, your XenApp site in the middle column and then Secure Access in the right column, or Action Pane (Figure 1).

Figure 1

We need to change the Default access method from the Alternate method back to Direct.  The current Direct method needs to be removed and then the current Alternate method needs to be changed back to Direct.

Click the line that has Direct for the access method and then click Remove (Figure 2).

Figure 2

Click the Default/Alternate line and then click Edit… (Figure 3).

Figure 3

Click the dropdown box, select Direct and then click OK (Figure 4).

Figure 4

Click Finish (Figure 5).

The only access method at this time is now the original default method of Direct access.

Figure 5

Now the AltAddr assigned to the server’s network interface needs to be removed.

Open a command prompt window. Type in altaddr /delete InternalIPAddress and press Enter.  Substituting your real Internal IP Address.  Type in altaddr and press Enter.  Your results should be similar to Figure 6.

Figure 6

Type exit and press Enter to close the command prompt window.

CSG uses SSL so TCP ports 1494 and 2598 no longer need to be opened on your router and or firewall.

Your router and or firewall need to be configured to allow the necessary ports through.

Port Protocol
80 HTTP
443 HTTPS (SSL)
3389 Remote Desktop (optional)

Here is my router configuration (Figure 7).

Figure 7

Minimize the WIMC.

Click Start, Administrative Tools, Internet Information Services (IIS) Manager (Figure 8).

Figure 8

Expand Web Sites (Figure 9).

Figure 9

Select Default Web Site (Figure 10).

Figure 10

Right-click Default Web Site and then click Properties (Figure 11).

Figure 11

Click the Directory Security tab and then click Server Certificate… (Figure 12).

Figure 12

The Web Server Certificate Wizard starts.  Click Next (Figure 13).

Figure 13

Select Create a new certificate and click Next (Figure 14).

Figure 14

Click Next (Figure 15).

Figure 15

You can type in any Name for the new certificate on Figure 16.  I use citrix.domain.tld or for my certificate, citrix.websterslab.com.  For GoDaddy.com SSL certificates, the Bit length must be 2048 or higher.  Select a suitable Bit length value and then click Next.

Note: For compatibility with future versions of IIS, a Bit length of 4096 is recommended.

Figure 16

You can enter anything for Organization and Organizational unit (Figure 17).  They should either be very easy for you to remember or should be documented in your Change Control processes.  If you ever need to rekey your certificate, you will need this information.  If what you enter during the GoDaddy rekeying process does not match what you enter here, the rekeying will not be allowed by GoDaddy.   I prefer to keep everything simple and enter citrix.domain.tld or for my certificate, both fields will be citrix.websterslab.com.

Enter your Organization, Organizational unit and click Next.

Note: Other SSL providers may require these fields to map to the information contained in the domain WHOIS information.

Figure 17

For Your Site’s Common Name, enter citrix.domain.tld or for my certificate, citrix.websterslab.com and then click Next (Figure 18).

Figure 18

Select your Country/Region, enter your State/province, City/locality and click Next (Figure 19).

Note: Other SSL providers may require the State/province to be spelled out.

Figure 19

By default, the Certificate Request File Name is saved as c:\certreq.txt.  The IIS Certificate Wizard allows you to specify a different location and filename of your choice.  Either enter a new file name or accept the default and then click Next (Figure 20).

Figure 20

Verify the information on the Request File Summary page is correct.  If anything needs to be corrected, click Back and make any necessary corrections.  If all the information is correct, click Next (Figure 21).

Figure 21

Click Finish to complete the certificate request and generate the file (Figure 22).

Figure 22

Leave the Default Web Site Properties page up.  Click Start, Run and type in the path and filename for your certificate request file.  If you accepted the default, type in c:\certreq.txt and press Enter (Figure 23).  This will open the file in Notepad (Figure 24).

Figure 23

Figure 24

Press Ctrl-A to select the entire certificate request and then press Ctrl-C to copy the file contents to the server’s clipboard (Figure 25).  Do not change anything in this file.  Doing so will invalidate the certificate request process and you will need to start over.

Figure 25

Exit Notepad, start Internet Explorer and go to http://www.godaddy.com (Figure 26).

Figure 26

Log in to your account and click on SSL Certificates (Figure 27).

Figure 27

Scroll down and under Standard SSL, select Single — List Price $49.99/yr, then the number of years you wish your certificate to be valid and then click Add (Figure 28).

Figure 28

You can safely bypass all the extra deals GoDaddy tries to sell you.  Nothing else is needed for your SSL Certificate to work with the Citrix Secure Gateway and Web Interface.

Scroll down to the bottom of the screen and click “No thanks” (Figure 29).

Figure 29

Enter any promo codes you have, select your payment method and check the box by I have read and agree to the terms of the Universal Terms of Service and then click Continue With Checkout (Figure 30).

Figure 30

Enter the information for your payment method and complete that process (No, I’m not showing you mine!).

When the payment process is complete, click Login to Begin Using Your Products (Figure 31).

Figure 31

Once back on the main account page, you should have an alert showing to start the process to setup your SSL Certificate.  Click the link Get Started (Figure 32).

Figure 32

On the Managing Secure Certificates screen, click the link to “Use Credit” for your new certificate (Figure 33).

Figure 33

The Set up New Certificate wizard starts.  Click Continue (Figure 28).

Figure 34

Click Close on the Thank You! popup (Figure 35).

Figure 35

Back on the Managing Secure Certificates Control Panel, click the Manage Certificate link for the New Certificate (Figure 36).

Note: It may take a few minutes before your new certificate shows up in the list.

Figure 36

A new browser window opens up.  Click Request Certificate (Figure 37).

Figure 37

Select Third Party or Dedicated/Virtual Dedicated Server w/o Simple Control Panel, click in the CSR box and press Ctrl-V, make sure the certificate issuing organization is Go Daddy and then click Next (Figure 38).

Figure 38

Verify the information is correct and then click Next (Figure 39).  If the information is not correct, click Back and correct the information.

Figure 39

Click Finished (Figure 40).

Figure 40

You will receive an e-mail from Go Daddy in a few minutes telling you “Your SSL Certificate Has Been Issued”.

Back on the Manage Certificates control panel, select your new SSL Certificate and then click the Download arrow (Figure 41).

Figure 41

Select IIS6 from the dropdown box and then click Download Certificate for IIS6 (Figure 42).

Figure 42

Open the file… (Figure 43).

Figure 43

And extract the files to c:\sslcert (Figure 44).

Figure 44

Click Close (Figure 45).

Figure 45

Log out of GoDaddy.com and close all browser windows.

Click Start, Run, type in MMC and press Enter (Figures 46 and 47).

Figure 46

Figure 47

Click File and Add/Remove Snap-in… (Figure 48).

Figure 48

Click Add… (Figure 49).

Figure 49

Click Certificates and then click Add (Figure 50).

Figure 50

Select Computer account and click Next (Figure 51).

Figure 51

Select Local computer and click Finish (Figure 52).

Figure 52

Click Close to close the Add Standalone Snap-in dialog (Figure 53).

Figure 53

Click OK to return to the main MMC Window (Figure 54).

Figure 54

Click the “+” to expand the Certificates folder (Figure 55).

Figure 55

Right-click on Intermediate Certification Authorities, choose All Tasks and then click Import… (Figure 56).

Figure 56

Click Next (Figure 57).

Figure 57

Click Browse… (Figure 58).

Figure 58

Change the “Files of type” dropdown to PKCS #7 Certificates (*.spc, *.p7b) (Figure 59).

Figure 59

Browse to the location you extracted and saved your certificate files, select your certificate file and click Open (Figure 60).

Figure 60

Click Next (Figure 61).

Figure 61

Select Place all certificates in the following store and make sure the Certificate store is Intermediate Certification Authorities  and click Next (Figure 62).

Figure 62

Click Finish on the Certificate Import Wizard (Figure 63).

Figure 63

Click OK (Figure 64).

Figure 64

Click the “+” next to Trusted Root Certification Authorities and then click Certificates (Figure (65).

Figure 65

Scroll down, right-click Go Daddy Class 2 Certification Authority and select Properties (Figure 66).

Figure 66

Select Disable all purposes for this certificate and click OK (Figure 67).

Figure 67

Exit the MMC console without saving changes.

Click on Default Web Site Properties dialog and then click Server Certificate… (Figure 68).

Figure 68

Click Next (Figure 69).

Figure 69

Select Process the pending request and install the certificate and click Next (Figure 70).

Figure 70

Click Browse… to locate your certificate file (Figure 71).

Figure 71

Change the Files of type to All files (*.*) (Figure 72).

Figure 72

Find and select your GoDaddy “crt” certificate file and then click Open (Figure 73).

Figure 73

Click Next (Figure 74).

Figure 74

Citrix Secure Gateway will process all incoming SSL traffic on Port 443 so the SSL Port that IIS uses must be changed.  Type in 444 and click Next (Figure 75).

Note:  This is one of the most common problems that keeps Citrix Secure Gateway from working.   Citrix Secure Gateway MUST have Port 443 reserved for its use.  IIS MUST use a different Port for SSL.

Figure 75

Verify the information on the Certificate Summary page is correct and click Next (Figure 76).

Figure 76

Click Finish (Figure 77).

Figure 77

Click OK (Figure 78).

Figure 78

Exit Internet Information Services Manager.

To verify the SSL Certificate was installed properly, you may need to create an entry in your Web Interface server’s Host file.  Click Start, Run and type in Notepad %systemroot%\system32\drivers\etc\hosts and press Enter (Figure 79).

Figure 79

Go to the bottom of the Hosts file and type 127.0.0.1, press Tab and type in the Fully Qualified Domain Name your users will use to access the Citrix Secure Gateway.  For me that is citrix.websterslab.com (Figure 80).

Figure 80

Save the changes and exit Notepad.

Open your Internet browser and go to https://FullyQualifiedDomainName:444/Citrix/XenApp.  For me, I went to https://citrix.websterslab.com:444/Citrix/XenApp (Figure 81).  Note the SSL Padlock icon.

Figure 81

Click the Padlock icon and click View certificates. (Figure 82).

Figure 82

Click each of the three tabs (Figures 83, 84 and 85).

Figure 83

Figure 84

Figure 85

Click OK and then log in to the Web Interface (Figure 86).

Figure 86

You can test running any published application if you wish.  Log off the Web Interface and exit your Internet browser.

To start the installation of CSG change the VM’s DVD Drive to the XenApp 5 ISO file (Figure 87).

Figure 87

The XenApp 5 installation starts.  Click Browse Media (Figure 88).

Figure 88

Double-click Secure Gateway (Figure 89).

Figure 89

Double-click Windows (Figure 90).

Figure 90

Double-click the CSG_GWY.msi file and click Next (Figure 91).

Figure 91

Click Next (Figure 92).

Figure 92

Select I accept the license agreement and then click Next (Figure 93).

Figure 93

Select Secure Gateway and then click Next (Figure 94).

Figure 94

Click Next to accept the default installation folder (Figure 5).

Figure 95

Citrix Best Practice is to place the Secure Gateway/Web Interface server in the DMZ and the server should not be a domain member.   Since this server, outside of this Learning series, is an Internet facing server it should be protected by all means possible.  This includes using an account that has the least possible privileges and not putting the server on your internal network.

On the Service Account page you have the option of running the Secure Gateway service under Local System or Network Service accounts.  What is the difference and which one should be chosen?  According to http://msdn.microsoft.com/en-us/library/ms684190(VS.85).aspx, the Local System account runs at a very high privilege level.  The article recommends using the Network Service account if a high privilege level is not needed.  The Secure Gateway service does not need, and should not be given, such a high privilege level.   According to http://msdn.microsoft.com/en-us/library/ms684272(VS.85).aspx, the Network Service account has very few privileges.  You should seriously consider using the Network Service account for the Secure Gateway service.  It is very odd that this important decision is not mentioned in the Secure Gateway for Windows Administrator’s Guide or any Citrix Support Tech Notes.

Using the Network Service account reduces the attack surface should your Secure Gateway/Web Interface server be hacked.  Since this account has no domain privileges it will make it harder for an attacker to compromise your domain.

If you do decide to place the Secure Gateway/Web Interface server on your internal network, then you must use the Network Service account.

Select NETWORK SERVICE from the dropdown list and then click Next (Figure 96).

Figure 96

Verify the install options (Figure 97).  If any corrections need to be made, click Back and make the necessary corrections.  If everything is correct, click Next.

Figure 97

Click Finish (Figure 98).

Figure 98

Click OK to start the Secure Gateway Configuration wizard (Figure 99).

Figure 99

Click OK to start configuring Secure Gateway (Figure 100).

Figure 100

The Standard configuration does not allow us to set, or verify, all the necessary options.  Select Advanced and then click Next (Figure 101).

Figure 101

Select your SSL certificate and click Next (Figure 12).  Click View… to view the information about your certificate.  This is the same information that was seen in Figures 83, 84 and 85.

Figure 102

For “Select secure protocol“, select Secure Sockets Layer (SSLv3) and TLSv1.  For “Select cipher suite“, select All and then click Next (Figure 103).

Figure 103

If you have a single network card with a single IP address, you can select Monitor all IPv4 addresses (Figure 104).  If you have multiple network cards and or multiple IP addresses on this server, unselect Monitor all IPv4 addresses, click Add and add the network interface(s) you wish to monitor for TCP port 443 traffic.

Secure Gateway will handle all TCP port 443 traffic and IIS handles SSL traffic on TCP port 444 (or whatever you selected earlier).  Enter 443 for the TCP port and then click Next.

Note:  IPv6 is only supported under Windows Server 2008.

Figure 104

Select No outbound traffic restrictions and then click Next (Figure 105).

Figure 105

The Secure Ticket Authority (STA) is installed on every XenApp server.  If you have multiple XenApp servers enter as many XenApp servers as you like to provide failover.

Click Add (Figure 106).

Note: Secure Ticket Authority (STA) is part of the XML Service that runs on all XenApp servers.

Figure 106

Enter citrixone for the Fully Qualified Domain Name (FQDN) and then click OK (Figure 107).

Figure 107

Click Next (Figure 108).

Figure 108

By default, Secure Gateway is limited to 250 concurrent connections.  I would not recommend increasing this limit.  If you need more than 250 concurrent connections then you should seriously consider Citrix’s hardware solution the Citrix Access Gateway.

Accept the defaults and click Next (Figure 109).

Figure 109

If you have any hardware load balancing appliances in front of your Secure Gateway/Web Interface server, enter the IP addresses here to exclude them from generating even log entries and then click Next (Figure 110).

Figure 110

Since the Secure Gateway and Web Interface are installed on the same server, select Indirect:…, check Installed on this computer and then click Next (Figure 111).

Figure 111

Select the level of logging you wish to receive from the Secure gateway service and click Next (Figure 112).

Figure 112

Check to Start the Secure Gateway service and then click Finish (Figure 113).

Figure 113

Exit the Explorer windows and the Citrix XenApp installation program.

To test external access to published applications, you will need a public DNS name for the server.  Mine is citrix.websterslab.com.  I use DynDNS to allow the use of a dynamic Public IP address for my lab server.  In your router or firewall TCP port 443 must be routed from the Public IP address to the internal IP address of the Citrix Secure Gateway/Web Interface server.

Internet -> Public IP address -> Router/Firewall -> TCP Port 443 -> Private IP address

For me:

Internet -> 69.x.y.z -> Router/Firewall -> TCP Port 443 -> 192.168.1.105

Restore the Web Interface Management Console.   In the Action pane under XenApp — Edit Settings, click Secure access (Figure 114).

Figure 114

Click the Default line and then click Edit… (Figure 115).

Figure 115

Select Gateway Direct from the dropdown list and then click OK (Figure 116).

Figure 116

Selecting Gateway Direct will send to the client the external Public IP address of the Secure Gateway/Web Interface server instead of the internal Private IP address of the XenApp server hosting the published application.

Click Next (Figure 117).

Figure 117

Enter the FQDN that users will use to access the Secure Gateway/Web Interface server and then click Next (Figure 39).

Figure 118

Click Add… (Figure 119).

Figure 119

Type in http://citrixone/scripts/ctxsta.dll and then click OK (Figure 120).

Figure 120

Click Finish (Figure 121).

Figure 121

From a computer that is external to your network, go to https://FQDN/Citrix/XenApp.  For me, this is https://citrix.websterslab.com/Citrix/XenApp (Figure 122).  Notice the SSL padlock appears.

Figure 122

Log in to the Web Interface and your published applications are shown (Figure 123).

Figure 123

Test running your published applications to verify they run successfully.

To verify the connection is using 256-bit SSL, right-click the Citrix Connection Center icon in the systray and select Open Connection Center (Figure 124).

Figure 124

Click the XenApp server and then click Properties (Figure 125).

Figure 125

The Client Connection Status dialog shows that 256-bit SSL is in use (Figure 126).

Figure 126

Exit the Client Connection Center, your published application, log off the Web Interface site and exit your Internet browser.

Repeat the tests from inside your network.

You have now successfully tested secure access to published application from both inside and outside your network.

In this final part, you learned to install and configure Citrix Secure Gateway 3.1.2 and test both external and internal secure access to published applications.

You have now learned how to complete all the goals set out for you in this 10-part series.  You have:

  • Created your MyCitrix.com account
  • Requested your evaluation license code
  • Downloaded your product license file
  • Downloaded XenApp 5 Feature Pack 2 for Server 2003
  • Downloaded XenServer 5.5
  • Learned to create a VM optimized for XenApp
  • Learned to install Windows Server 2003 R2 x86
  • Installed the prerequisites for XenApp 5 Feature Pack 2 for Server 2003, Web Interface and the Citrix License Management Console
  • Updated Windows Server 2003 R2 x86
  • Learned to install XenApp 5 Feature Pack 2 for Server 2003
  • Learned how to update XenApp 5 for Server 2003
  • Learned how to create a Web Interface site and set basic configuration settings
  • Created a test user account
  • Learned how to publish applications
  • Tested access to the published applications
  • Learned basic XenApp farm maintenance procedures
  • Learned how to use the AltAddr method to provide insecure, unencrypted external access to published applications
  • Learned how to generate an SSL certificate request, purchase an SSL certificate and complete the certificate request
  • Learned how to use Citrix Secure Gateway to provide secure, encrypted access to published application

You just finished reading Learning the Basics of Citrix XenApp 5 for Windows Server 2003 and XenServer 5.5 (Part 10 of 10) on Carl Webster. Please consider leaving a comment!


Viewing all articles
Browse latest Browse all 14

Trending Articles