Question and Answers
Note: The same principles and concepts holds good for NetScaler Gateway as well.
This post answers some frequently asked questions regarding the Citrix Secure Ticket Authority (STA). The questions are divided into following four categories:
- Overview
- Security
- Scalability
- Troubleshooting
Overview
Q: What is the Secure Ticket Authority?
A: The Secure Ticket Authority (STA) is an XML web service that exchanges XenApp server information for randomly generated tickets. It is used to control access for a Citrix Secure Gateway server.
Q: What Citrix products interact with the STA?
A: XenMobile, Web Interface, StoreFront, XenApp Secure Access Manager, NetScaler Gateway and Citrix Secure Gateway interact with STA. Throughout this article, the following types of servers are grouped into a single category called application enumeration servers:
- Web Interface 2.0 or later
- Secure Access Manager 2.0 or later
- StoreFront
- Application enumeration servers are responsible for authenticating users, enumerating published application icons, and producing an ICA file for a client that allows them to connect to a published application through a Secure Gateway server.
Q: Why is the STA necessary?
A: In Citrix Secure Gateway deployments, the gateway server does not perform authentication of incoming requests. Instead, the gateway server defers authentication to an application enumeration server and uses the STA to guarantee that each user is authenticated. Application enumeration servers request tickets only for users who are already authenticated to the Web server. If users have valid STA tickets, the gateway assumes that they passed the authentication checks at the web server and should be permitted access.
This design allows the Citrix Secure Gateway server to inherit any authentication methods in your web server. For example, if your Web Interface server is protected with RSA SecurID, by design only SecurID-authenticated users can traverse the Secure Gateway server.
Q: How is the STA service implemented?
A: The STA is written as an ISAPI extension for Microsoft Internet Information Services (IIS). The extension is called CtxSta.dll and is hosted in the /Scripts folder by default. Other components communicate with the STA using XML over HTTP.
Application enumeration servers request tickets at application launch time by sending data to the STA as part of a ticket request. The data sent to the STA includes the address of the XenApp Server to which the user will connect and, in the case of Web Interface 2.0 and Secure Access Manager 2.0, extended information about the name of the current user and the published application the user wants to run. The STA responds by generating a ticket and sending it back to the application enumeration server. This ticket and its corresponding data remain in memory at the STA for a configurable number of seconds (100 by default).
The application enumeration server constructs an ICA file for the user and inserts the STA ticket in the Address field of the ICA file. When the client connects to the Secure Gateway, the ticket is presented and the gateway should validate the ticket before establishing a secure session for the client. The gateway performs a data request by sending the ticket back to the STA and asking for its corresponding data in return. If successfully validated, the STA forwards the original data to the gateway and the gateway establishes a relay between the end user and the XenApp Server.
Both ticket requests and data requests are carried out as XML request/response documents.
Q: Is there a version of the STA that does not require IIS?
A: No, at this time IIS is required to host the STA. Remember that the STA does not have to be exposed to an untrusted network like the Internet; the STA resides on your trusted network and is accessed by the gateway and application enumeration servers only.
Q: Where does the STA server reside?
A: The STA server can be placed anywhere as long as the Secure Gateway and application enumeration servers can reach it. Citrix recommends placing the STA on the trusted network or on a separate leg of your internal firewall, but there are no requirements for the STA server other than IIS. The STA need not belong to any domain, XenApp Server farm, Secure Access Manager farm, or other internal Web server, but sharing the STA with another function is common practice. An STA is included automatically as part of the Secure Access Manager 2.0 setup; many administrators find it convenient to locate the STA on a XenApp server.
Q: What are the differences among different versions of the STA?
A: There are no material functional differences between Versions 1.0 and 1.1, but when using the 2.0 STA with Web Interface 2.0 or Secure Access Manager 2.0, extended information is added to the ticket request: The name of the user and the application the user wants to run. This extended data is consumed by the gateway service to display details about each gateway session in the Secure Gateway 2.0 management console.
If Secure Gateway 2.0 is configured to use an older STA from Version 1.1 or 1.0, users can connect to applications but the Secure Gateway management console will show “N/A” for the user name and application name associated with each ICA session. To see the extended information in the Secure Gateway 2.0 management console, you must use Version 2.0 or later of the STA and use either Secure Access Manager 2.0 or Web Interface 2.0 as your application enumeration server.
Security
Q: How is the STA Ticket generated?
A: The ISAPI extension CtxSta.dll uses pseudo-random number generation to produce a 16-byte hexadecimal string. For security reasons, Citrix does not disclose the exact steps used to produce this random sequence of characters.
Q: What constitutes an STA Ticket?
A: The encoding format is a string of the form:
;STA_VERSION;STA_ID;TICKET
Where:
- STA_VERSION is a numeric field identifying the version of the STA. Currently the only valid values for this field are “10” for STA Versions 1.0 and 1.1 and “20” for STA Version 2.0.
- STA_ID is a sequence of 0 – 16 characters representing an arbitrary name assigned by the administrator to a particular STA. In Version 1.x, this string defaults to STA01, STA02, and so on. When the STA is installed automatically as part of Secure Access Manager 2.0, the STA ID is a hash of the server name. When multiple STAs are shared by a single gateway server, each STA ID must be unique. This allows the gateway to locate the STA that created the ticket and return to that STA for ticket validation. A ticket created on STA01 will not exist on STA02.
- TICKET is a randomly-generated sequence of 32 uppercase alphabetic or numeric characters.For example:
;10;STA01;FE0A7B2CE2E77DDC17C7FD3EE7959E79
Q: Is the Ticket validated against the Workstation?
A: No, there is nothing that ties a ticket to a particular workstation. It is theoretically possible for a ticket to be requested from Workstation A and then used from Workstation B. To mitigate this risk:
- Always use HTTPS between the client and the application enumeration server to prevent an attacker from intercepting the ticket as it travels from server to client.
- Reduce the ticket time-to-live as much as possible to reduce the amount of time an attacker would have to transfer the ticket from Machine A to Machine B.
Remember that a ticket issued by the STA can be used only once, so if the intended user on Machine A connects successfully, the ticket is invalid for all future connection attempts from Machine A or Machine B.
Q: Is the Ticket deleted after use?
A: Yes, tickets are purged immediately after a successful data request so they can be used only once. They are also deleted after a configurable time-out (default 100 seconds) if not used.
Q: Are Tickets ever written to Disk at the STA?
A: Only when verbose logging is enabled by setting LogLevel=3 in CtxSta.config. Otherwise, the STA maintains all outstanding tickets (tickets that were requested by an application enumeration server but not yet validated by a Secure Gateway) using an in-memory database. XML data is always sent to the STA using the HTTP POST command, so no meaningful ticket data is ever written to the STA Web server logs.
Q: Is it possible for someone to hijack a ticket?
A: During normal operation, a ticket must travel the following four segments of the network:
- From the STA to the application enumeration server
- From the application enumeration server to the client
- From the client to the Secure Gateway server
- From the gateway to the STA
The first and last segments exist only between servers in your DMZ and the STA on your trusted network, meaning that an intruder would need to have access to your network to intercept the ticket along those lines. Still, these pathways can be encrypted with SSL if you use Secure Gateway Version 2.0. In Citrix Secure Gateway 1.1 and earlier, traffic to the STA cannot be encrypted using SSL.
To secure the second segment, put a certificate on your application enumeration Web server and allow clients to connect only if they use HTTPS. The third segment is always secured with SSL.
Even when all of the preceding links are secured with SSL, clients are still vulnerable to attack by Trojan programs that monitor client activity. To mitigate this risk, advise your users to connect from machines where anti-virus and Trojan detection software is installed.
Q: How do I protect the STA Traffic with SSL?
A: First, install a Web server certificate on the copy of IIS that hosts the STA. For more information, see the IIS documentation.
Configure your application enumeration server and Secure Gateway server to use HTTPS when communicating with the gateway. When connecting by HTTPS, the following rules must always be met:
- You must address the STA using a fully-qualified domain name that matches the subject of the STA server certificate.
- The machine communicating with the STA must be able to resolve the STA fully-qualified domain name to an appropriate IP address.
- The machine communicating with the STA must trust the Certificate Authority (CA) that issued the STA server certificate.
- To meet the requirements of the third bullet item, the CA root certificate needs to be installed on the Secure Gateway server and on the application enumeration server. Take care when installing the root certificate: You cannot simply double-click a root certificate file and run the certificate import wizard.
(Doing so indicates that your user account, not the server or any system services, trusts the CA.) To install a root certificate for use with Citrix Secure Gateway or Web Interface, follow the steps:
- Run Mmc.exe and add the Certificates snap-in.
- When asked which certificates to manage, select Computer account and then Local Computer.
- Expand the Certificates (Local Computer) > Trusted Root Certification Authorities node. Right-click Certificates and then select All Tasks > Import.
- Browse to select your CA root certificate and complete the import wizard.
Q: Must the STA always be addressed using a Fully-Qualified Domain Name?
A: If you intend to secure traffic to the STA using SSL, any component that accesses the STA, including your gateway server and application enumeration server, must address the STA using the fully-qualified domain name (FQDN) that matches the subject of the server certificate used by IIS on the STA. For example, in Web Interface 2.0, the STA address would be entered as:https://sta-server.company.com/Scripts/CtxSta.dll
If you choose not to secure traffic to the STA, you can address the STA using an IP address, host name, or FQDN.
Q: How do I change the STA port from 80 to something else?
A: Because the STA is served by IIS, you change the STA port when you change the IIS port. The following example illustrates how to change the IIS port from 80 to 81.
- Open Internet Services Manager.
- Right-click Default Web site and view the Properties.
- On the Web site tab, change the TCP port number from 80 to 81.
- Click OK.
The preceding change also affects any other resources you published from the STA Web server. If you want to alter the STA communication port without affecting other Web pages hosted by the same Web server, you can create a new Web site in IIS for the sole purpose of hosting the STA. The following is an example of how you would create a new Web site on port 81 for the STA. - Create a new physical folder such as C:\MYSTA on your Web server’s hard drive to serve as the document root for the STA site.
- Create a subdirectory beneath MYSTA called Scripts. Move the following files from your existing STA into the new Scripts folder:
- CtxSta.dll
- CtxSta.config
- ctxxmlss.txt
- Open Internet Services Manager.
- Right-click the server name and select New > Web site.
- Create a new Web site called “My STA site” and C:\MYSTA as the document root directory.
- View the properties of your new web site and change the TCP port to 81.
- Under My STA site in Internet Services Manager, right-click the Scripts folder and view the properties. In the Application Settings section, change the Execute permissions to “Scripts and Executables.”
Note: You can choose a folder name other than “Scripts” but be aware that Secure Gateway and all application enumeration servers such as Web Interface assume that the STA is published as /Scripts/CtxSta.dll so you will also need to update the STA URL in the settings on those servers.
Q: Can an Attacker send random Tickets to the Gateway to Log On?
A: An attacker would have to guess a valid ticket and also redeem it within the few milliseconds after the client requests it but before the gateway claims it.
Q: What other information is required to Logon other than a valid STA Ticket?
A: Users also need domain credentials or a XenApp Server ticket that is requested by the application enumeration server. (A XenApp Server ticket is not the same as an STA ticket.) Satisfying the STA opens a path only to the trusted network for a particular server. Once there, the user must still authenticate with valid domain credentials.
Scalability
Q: How many STAs do I Need?
A: The STA is accessed only when a user launches an application, the answer to this question varies from one deployment to the next.
Q: Do users logon through the gateway in the morning and run a single published application all day or do they launch several applications throughout the day?
A: The duties performed by the STA are not expensive in CPU terms; it is a light XML service limited only by the performance of IIS. In one test, a low-range server with a 1GHz processor and 256MB of RAM supported over 250 ticket requests per second while CPU utilization stayed below 60%.
Q: How can I ensure STA Fault Tolerance?
A: The following application enumeration servers all allow you to enter multiple STA URLs when configuring the parameters for Secure Gateway:
- Web Interface 2.0
- Secure Access Manager 2.0
- StoreFront
In all cases, if an STA fails to respond, the application enumeration server tries another STA on the list. Each gateway server in turn must be configured with the STA URL and unique STA ID for each ticket authority.
Q: How do I Load Balance multiple STAs?
A: Special care needs to be taken when load balancing Secure Ticket Authorities. A variety of methods can be used to load-balance the connection between an application enumeration server and the STAs, but a Secure Gateway server must always contact each STA individually based on its STA ID. When configuring the address of each STA in the gateway service configuration tool, each STA address must be the true address of the STA server — do not enter the address of any hardware load balancer, cluster name, or round-robin DNS name here.
StoreFront, Web Interface 2.0, and Secure Access Manager 2.0 all support round-robin load balancing of the STAs when multiple STAs are listed. When this option is enabled, no additional load balancing software or hardware is required.
Application enumeration servers can use any form of load balancing for issuing a ticket request because each ticket received contains a field indicating the unique ID of the STA that generated it. As long as each STA ID is unique and all gateway servers can resolve the STA ID to a particular (not load balanced) server address, the operation succeeds and STA traffic is load balanced.
Q: Can I use several STAs with Microsoft Network Load Balancing?
A: Network load balancing cannot be used between the Secure Gateway server and multiple STAs. If configured this way, users receive intermittent denials because, during the ticket validation process, the gateway might be load balanced to an authority that did not originally generate the user’s ticket.
Q: Can I share a Single STA with multiple Farms, Gateways, and Enumeration Servers?
A: Yes, a single STA can be shared among any number of Secure Gateway servers and application enumeration servers. The STA is not restricted to any particular domain, farm, or application enumeration server. It is an anonymous XML service.
Troubleshooting
Q: How should IIS be configured to host the STA?
The STA URL /Scripts/CtxSta.dll must be served with Anonymous access enabled. If you point any Web browser to the STA URL you will not be prompted for a password.
- You must grant the resource Scripts and Executables permission in the IIS metabase. This permission is not needed for the entire /Scripts folder but can be set for the CtxSta.dll file individually.
- For Secure Gateway Version 1.1 and earlier, do not enable the Require SSL and Require 128-bit SSL options.
- By default, the following account permissions are needed:
On Windows 2000 servers
- The IUSR_MachineName account needs Read access to CtxSta.dll.
- The IWAM_MachineName account needs Modify access to the log file directory, which is \Inetpub\Scripts by default.
On Windows 2003 Servers
- The IUSR_MachineName account needs Read access to CtxSta.dll.
- The built-in Network Service account needs Modify access to the log file directory, which is \Inetpub\Scripts by default.
Q: How do I enable Logging at the STA?
A: Using Notepad, edit the file \Inetpub\Scripts\CtxSta.config on the STA server and locate the line that says LogLevel=0. For maximum logging, change this to LogLevel=3. You must restart the World Wide Web Publishing Service for changes to take effect.
Note: After you enable logging, the user account under whose authority the STA executes (IUSR_MachineName on Windows 2000 or Network Service on Windows 2003 by default) must have Write access to the log file directory, which is \Inetpub\Scripts by default. You can also change the log file directory when you edit CtxSta.config.
Q: Why does the Microsoft IISLockDown Tool break the STA?
A: If you accept all the default settings for IISLockDown tool, the /Scripts folder is disabled. The STA is implemented as an ISAPI filter published as /Scripts/CtxSta.dll; by disabling the /Scripts directory, you deny access to the STA. Enable the /Scripts folder and allow Scripts and executables access for the STA to function.
Q: How can I test the STA to be sure it is Working properly?
A: If you point a Web browser to the STA URL, you will see either a blank white page or the message “405 Resource Not Allowed.” Either of these results indicates a functioning STA. You can contact the STA in this manner from the console of your Secure Gateway server and also from any application enumeration server configured to use the gateway. If you receive an authentication dialog box prompting you for a password, the STA is not published anonymously and authentication requirements need to be removed.
To verify that the application enumeration server is successfully requesting STA tickets, look at the ICA files it generates. For example, from Web Interface 2.0, you can right-click a published application icon and save the result as launch.ica. Open launch.ica in Notepad and view the Address= line. For normal Secure Gateway operation, the Address parameter will contain a ticket instead of an actual XenApp server address.
Q: How do I interpret the STA Log files?
A: If you enable logging by setting LogLevel=3 in CtxSta.config, you will see details of each ticket and data request received by the STA. Remember that a ticket request is generated by an application enumeration server like Web Interface, and a data request is performed by the Secure Gateway service. If the log file shows several ticket requests but no data requests, this implies that the application enumeration server can reach the STA but the Secure Gateway server cannot. It can also imply that users cannot reach the gateway server.
During normal operation, the session sharing feature of the ICA Client can cause tickets to be requested from the STA but never claimed by the gateway. Consider the following scenario:
- A user logs on to Web Interface and clicks the Outlook icon. Web Interface requests a ticket from the STA and sends it to the user in an ICA file.
- The user connects through Secure Gateway and presents the ticket for admission. The gateway validates the ticket and allows the user to connect to a XenApp Server hosting Outlook.
- After working for a few minutes, the user returns to the application list on the Web Interface page and clicks the Excel icon. Web Interface requests a second ticket from the STA and sends it to the user in an ICA file.
- Before connecting to a new server for Excel, the ICA Client first checks to see if any existing servers to which the client is already connected have the Excel published application available.
- The server where the client is already running Outlook also has Excel installed, so the ICA Client discards the ICA file and starts Excel within the existing ICA session.
- The second ticket requested by Web Interface is never used because a second ICA session was not necessary. By default, the ticket times out after 100 seconds.
This scenario would result in a series of STA log file entries similar to the following:
CSG1305 Request Ticket - Successful 8DE802AE5A2F561233450B6CFD553035 ... CSG1304 Request Data - Successful 8DE802AE5A2F561233450B6CFD553035 ... CSG1305 Request Ticket - Successful 63EF3EAB182D846958143D19C1FDAEBA ... CSG1303 Ticket Timed Out 63EF3EAB182D846958143D19C1FDAEBA
More suspicious activity might look something like this:
CSG1203 Request Data - Ticket NOT found 7DC6409CE228ECFCB5EE50A94D6AB804 CSG1203 Request Data - Ticket NOT found 7DC6409CE228ECFCB5EE50A94D6AB805 CSG1203 Request Data - Ticket NOT found 7DC6409CE228ECFCB5EE50A94D6AB806 CSG1203 Request Data - Ticket NOT found 7DC6409CE228ECFCB5EE50A94D6AB807 CSG1203 Request Data - Ticket NOT found 7DC6409CE228ECFCB5EE50A94D6AB808 CSG1203 Request Data - Ticket NOT found 7DC6409CE228ECFCB5EE50A94D6AB809
Here we see what appears to be an attacker trying various tickets one at a time, incrementing the ticket ID with each attempt. In each case, the connection was rejected and the STA logged an entry indicating that the client presented a ticket that was not recognized as valid. To identify the IP address of the attacker, look for the following message in the event viewer on the Secure Gateway server:
CSG3207 Service received error [invalid-ticket] from STA or Authentication Service [STA01], Client IP [206.39.121.77:1157] connection dropped.
Do not interpret some “Ticket NOT found” messages as an attack. The Win32 ICA Client may attempt to reconnect to a disconnected session if the user’s network connection is dropped momentarily. The Auto Client Reconnect feature does not work for Citrix Secure Gateway users because during each reconnection attempt, the client resubmits the used STA ticket with which it originally connected. The client usually attempts to reconnect three or more times before giving up, so you will see three or more “Ticket NOT found” messages referencing the same ticket in the STA log for each occurrence of this problem. Client reconnection attempts are characterized by the attempted reuse of a previously successful ticket:
CSG1305 Request Ticket - Successful 766D558270CE32695903698AFA0F67A6 … CSG1304 Request Data - Successful 766D558270CE32695903698AFA0F67A6 … CSG1203 Request Data - Ticket NOT found 766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found 766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found 766D558270CE32695903698AFA0F67A6
Disconnect Auto Client Reconnect for Secure Gateway users by adding TransportReconnectEnabled=Off to the [WFClient] section of the ICA file. The correct way to reconnect to a disconnected session when using Secure Gateway is to return to the application enumeration server and click the application icon again.
Q: What are some of the common configuration Errors seen by Citrix Technical Support?
- The /Scripts folder or the entire Default Web site is disabled as a result of running IISLockDown or adhering to company policy for protecting Web servers.
- Logging is enabled in CtxSta.config, but the user account under whose authority the STA executes (IUSR_MachineName by default) does not have Write access to the log file directory.
- IIS on the STA server is configured to require SSL, but Secure Gateway are configured to access the STA using normal HTTP.
- If the app launch fails, first thing to be checked is if the STAs on StoreFront/Web Interface and NetScaler are given in exact same way or not, i.e. if the STAs are given as IP Address on SF/WI it should be given using IP address on NS and similarly in case of FQDN.