Problem solve Get help with specific problems with your technologies, process and projects.

Citrix XenApp Server configuration and security

Learn how to use Citrix XenApp Server configuration to secure your client's infrastructure with this chapter excerpt.


To protect assets from risks that were identified as possible threats to a business, countermeasures must be implemented. Servers will need certain configurations to provide security, and plans must be put into practice. Compare the risks faced by an organization with an operating system's features to find support that will address certain threats. Configuring the server to use these services or tools can assist in dealing with potential problems. For example, installing AD and using domain controllers on a network can heighten security and provide the ability to control user access and security across the network. In the same way, configuring a file server to use EFS so that data on the server's hard disk is encrypted can augment file security. Using security features in an operating system allows you to minimize many potential threats.

Protecting your server (and its parts)

About the book
This chapter excerpt on locking down your XenApp Server (download PDF) is taken from the book Securing Citrix XenApp Server in the Enterprise. The book gives security guidance for XenApp Server, ICA and network connections, and Terminal Services. It also teaches how to create XenApp security policies and procedures, and how to use Citrix Secure Gateway to prevent attacks.  

As we have said many times in this book that your job as a XenApp administrator is to not only make applications and resources available to your users, but to do so securely while still maintaining a productive environment that is usable. There are many tools and resources available to assist you in completing the task of protecting your server. However, sometimes the most obvious things are often overlooked. For example, let's say that an industrious employee can quickly reboot one of your XenApp servers and change the BIOS configuration to boot from a USB device that they connect to the server, or even a CD that has "questionable" content on it. Sound bizarre? Perhaps, but how long would that employee need to compromise the system if he were to have physical access to one of your servers? What could he do? Your job as security administrators is to think about situations just like this one, and in this section, we will cover some of the ways you can protect your server (and its parts.)

System BIOS lockdown

You can adopt the best security policies and implement the latest software and you can still have a security incident. Without adequately ensuring the physical integrity of your servers, you could be easily compromised by an insider, like coworker, contractor, visitor or even a friend. Therefore, you must ensure that even the most mundane ways of gaining access to your systems is thoroughly considered.

About the author
Tariq Bin Azad is the principal consultant and founder of NetSoft Communications Inc., a consulting company based in Toronto. He has more than 100 certifications and over 15 years experience working in the information technology industry. Eight of those 15 years were spent as a system analyst/consultant specializing in thin client, Active Directory and messaging technology in various industries.

All your security measures are useless if an attacker can gain physical access to your system. What would happen if an attacker were to gain access to one of your servers, could he then take a bootable CD and reboot your server and have it boot from the CD because your BIOS setting allows for that -- or worse yet, your BIOS is not protected.

To prevent this, use the system BIOS to disable boot devices other than the hard disk (or, if that's not possible, select the hard disk as the first boot device). For computers located in hard-to-protect public areas, consider removing floppy and CD/DVD drives, and disabling or removing USB and FireWire ports, to prevent people from booting the PC with a Linux disc, IPod or fl ash memory USB drive.

Password protect your system BIOS. Most types of BIOS let you create a user password that must be entered to permit the system to start up. If your BIOS supports it, an administrative password will prevent attackers from changing BIOS settings (including the boot password).

You should have this password stored in a secure location in case you need to make changes to the system later. Keep in mind that just because you password protect your system BIOS you will thwart an attackers efforts. Some systems accept master passwords, lists of which appear on the Internet. By entering particular key combinations an attacker may be able to sidestep BIOS password security on certain systems.

Additionally, anyone with the opportunity to open the system's case can clear the passwords by moving a jumper on the motherboard, or by disconnecting the battery that powers the BIOS settings' memory chip. If you're worried about that happening, get a lock for the case itself and have the server in a locked server cabinet.

USB blockers

USB blockers can be installed to minimize the security risks imposed by using portable storage media and portable devices in your enterprise, such as:

  • Memory sticks
  • Jump drive
  • Personal Digital Assistants (PDAs)
  • Cell Phones
  • MP3 Players
  • Digital Cameras
  • Scanners
  • Hard disk drives
  • CD/DVD
  • Printers

By using these devices, data can be retrieved and often changed while bypassing established security guidelines. Of course, this frequently causes irritation to administrators. Because of that, enterprises are threatened not only of the danger of the data theft and integrity compromise, but also of the intentional or unintentional "import" of viruses, Trojan horses and other damaging software.

Most USB blockers are built up on the Windows Device Manager and can be configured to prevent new or unknown devices from being accessible. These blockers are typically installed as a software component within the Windows operating system and can then be configured via Windows
Group Policy.


You can utilize XenApp Resource Manager with or without the summary database to establish a means of producing alarms based on metrics you configure and want to monitor.

The first step is to establish the metrics that you want to track. This process is easier than establishing the thresholds for those metrics; in short, this initial step is more art than science.

However, you can leverage Resource Manager and/or Performance Monitor in the creation of this baseline to allow you to more accurately establish the metrics and their thresholds that you will track.

Each metric has both yellow and red thresholds as configured on the right. Yellow represents the warning state, meaning something is slightly out of ordinary but not considered catastrophic yet. Red is reserved for those metrics that indicate a severe state that will need immediate attention. As we have stated several times, choosing the correct values to enter into the Threshold Configuration is definitely a challenge that we all face. The reality is that no two Presentation Server environments are identical; every environment has its own specific server hardware, operating systems, applications, and so on. Add to that the nuisance of differences in patch levels, software configuration, and usage patterns within various applications and you can quickly see why this will present a "tweaking" exercise for your environment. As a general rule of thumb, however, you can use the Visual Threshold Configuration window to get good idea of what your current environment looks like so you can make a more educated guess as to the values to enter.

Configuring alerts is a two-step process. Step one is to configure the individual metrics you want to be alerted on and the method to be alerted with. The second step is to enable alerting and configure the alerting methods. Alerts can be sent to e-mails, SNMP traps, or Short Message Service (SMS) pages. The Alerts tab of a given metric's properties allows for the configuration of these options. Basically, enable the way you want to be alerted when that particular metric enters an alert state, such as the transition to red. As a best practice, it is considered good etiquette to notify that the alert state is over by sending confirmation of the transition back to a green state.

Read the rest of this chapter excerpt.

Printed with permission from Syngress, a division of Elsevier. Copyright 2008. "Securing Citrix XenApp Server in the Enterprise" by Tariq Azad. For more information about this title and other similar books, please visit

This was last published in April 2009

Dig Deeper on Server management, sales and installation

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

As a beginning IT student, I find the information provided very useful. Thank you
@ish235, glad you found it helpful!