Design Consideration Presentation Server 4.

Consulting Solutions

How Policies Impact Presentation Server Environments

Overview
There are numerous ways to apply a configuration or security setting onto a group of servers within a Presentation Server environment. Because policies are so unique, diverse and customizable, there is no single, correct method towards policy design. However, this document will give the key areas to consider when deciding on the appropriate approach to implementing a setting via a policy. This design consideration will look at the following types of policies and the common practices associated with them: Citrix Presentation Server policies: These policies are defined within the management console on Presentation Server and only apply to connections using the Citrix ICA protocol but not the Microsoft RDP protocol. Presentation Server policies also allow for the configuration of Presentation Server-specific options like Session Printers and Progressive Display. The power of these policies is that they have the ability to be filtered based on users, location and even the method for launching the published applications. Many of these filters are only available within Presentation Server. Active Directory Policies: These policies are configured within Active Directory. They are applied to organizational units (folders), domains, sites, etc within the Active Directory structure. A single Active Directory policy can consist of a computer policy and a user policy. A computer policy consists of settings that affect the physical computer and impact all users logging onto the computer while a user policy affects the user and is applied on all systems the user logs onto. Local server policies and custom policies are types of Active Directory policies and are described as: o Local Server Policies and Settings: Local Server Policies are similar to Active Directory policies, except they are managed on a server-by-server basis and configured locally on that specific server, where Active Directory policies are managed centrally and can impact hundreds or thousands of users or computers with a single application of a policy. Custom Active Directory Policy Templates: Custom ADM templates, like the Citrix icaclient.adm template, are Active Directory or Local Server policies used to make configuration settings. They can be custom registry settings or simply standard policies re-organized as two examples. The concept of custom templates is supported, but depending on the author of the custom template, supportability by either Citrix or Microsoft might not be available. Organizations will have to verify the supportability of custom ADM templates. Also, any custom template used might already have settings configured, potentially causing issues with the environment. It is highly recommended to test custom policies in a test environment before implementing in production.

These five areas are the basis for the design decisions for an enterprise deployment of Presentation Server. These types of policies will be impacted by the following design areas: Policy Type Policy Integration Policy Filters

Policy Prioritization Policy Precedence

Design Decision Areas

Policy Type
Each policy type, Presentation Server policies, Active Directory Policies, Local Server Policies and Custom Policies has their strengths and also their weaknesses. In an ideal world, only one type of policy would be used, which would help simplify the policy design, but this is rarely possible as required functionality within the different types of policies differ. Oftentimes there will be a mixture of policy types used to create an environment that is both secure and usable. Pros Presentation Server Policies
Only place to configure certain Presentation Server settings Can encompass five different filters for determining who applies the policy Only impacts Presentation Server users and computers, not requiring other team support to implement If using other Citrix products, can incorporate Access Gateway and Password Manager settings All users/devices connecting to Presentation Server can be impacted by policies Policy expertise already available within organization, so maintainability is easy Includes settings not included with Presentation Server policies

Cons
Active Directory policies can make Presentation Server policies not function as expected because the underlying functionality in Terminal Services is disabled, thus making troubleshooting more difficult

Active Directory Policies

Local Server Policies

Easy to test settings on a single server without a chance of impacting the rest of the environment

Custom ADM Policies

Ability to use the Active Directory infrastructure to set custom settings for applications

Applied policies can be located at numerous levels, making it difficult to determine resulting policy Not as granular as Citrix policies No differentiation between RDP and ICA protocols Many organizations do not allow Presentation Server administrators ability to modify Active Directory policies Systems have to be managed by Active Directory for policies to be applied Hard to manage as each server must be modified Impacts all users who logon to server. Settings cannot easily be applied based on group membership Custom template concepts are supported but the actual custom file is not, unless it is expressly stated by the company

Because of the growing complexity of environments many enterprise organizations will require the use of two or three different policy types in the environment. In many circumstances, Presentation Server policies are used in conjunction with Active Directory policies, while Local Server Policies are only used in test environments for localized configuration testing or in situations where adding this functionality to Active directory is not possible. The remainder of this article will only focus on Presentation Server and Active Directory policies. Custom Policies fit in with Active Directory policies, but they can contain a wide array of configuration options that could already be part of Active Directory. Although they are custom, they still follow Active Directory policy rules.

Policy Integration
Many organizations will identify the need to use Presentation Server policies and Active Directory policies. Policy configuration can become quite confusing when creating policies from both sources. Many of the challenges that occur with using Presentation Server and Active Directory policies together is that some items appear to be duplicated in both areas. By understanding how the policy works, designing and troubleshooting a policy solution will become easier, as with any technology. As an example of how the policies function, the following settings were configured: Presentation Server policy: Enable client drive mapping Active Directory policy for Terminal Services: Disable client drive mapping

The result was that a users client drive mapping was disabled, meaning that the user could not map client drives. This would lend one to believe that Active Directory policies took precedence over Presentation Server policies. If the statement was true, then the next example would result in a clients drives to be mapped: Presentation Server policy: Disable client drive mapping Active Directory policy for Terminal Services: Enable client drive mapping

The result was that the users client drive mapping was still disabled. In this example, it appears that Presentation Server policies took precedence. There doesnt appear to be a commonality between precedence of Presentation Server and Active Directory policies. In fact, precedence isnt critical. What is critical is to understand what the policies are doing. Active Directory policies for Terminal Services enable and disable features Presentation Server utilizes for functionality. Terminal Services is the foundation and Presentation Server utilizes the foundation to extend the systems capabilities. If the foundational piece is removed, Presentation Server has nothin g to build upon, thus resulting in no functionality regardless of the Presentation Server setting. In the above example, by disabling a foundational feature within Terminal Services (drive mapping), Presentation Server can no longer use and augment the feature. If the foundational component within Terminal Services is enabled, then Presentation Server policies can be used to allow or deny the functionality. This is why confusion and complexity increases significantly when multiple policies from different sources are used. To ease confusion, it is recommended that Active Directory policies be used only where there is no corresponding policy within Presentation Server, as Presentation Sever policies allows for greater filtering options, as described in the next section. Also, in many environments, Presentation Server administrators do not have the rights to manipulate Active Directory policies, making configuration, troubleshooting and management much more difficult in a Active Directory policy world.

Policy Filter
Policy filtering is simply the ability to apply a policy to a group of users or computers based on matching criteria. As there are numerous ways to associate a policy with a group of users, it can oftentimes be difficult to decide the best course of action, especially as the configuration of policy filters is different between Presentation Server policies and Active Directory policies resulting in potential conflicts. However, there are some general guidelines on this procedure. Within Presentation Server policies, assigning a policy is broken down into the following five core filter areas: User Name: Policies can be associated with a group of users. Client Name: Client name is the name associated with the workstation that is connecting to Presentation Server. If using Presentation Server 4.0 and Web Interface, the client name is dynamic starting with WI_. If a policy is created for users who use Web Interface, the filter for the client name would look for WI_. In Presentation Server 4.5 and Web Interface 4.5, the administrator has the option of using the dynamically generated client name or to use the workstations configured hostname. Servers: Policies can be applied to a group of Presentation Servers.

IP Address: Policies can be applied if the users workstation is in the range specified. However, this can cause challenges as users can be at a remote site that uses a internal-only IP Address scheme, like 10.10.x.x, and the Presentation Server environment also uses the same internal-only IP Address scheme. Even though the user is remote, this policy filter could mistakenly apply policies meant for internal users to an external user. Access Control: Policies can be applied based on a wide range of options included with Citrix Access Gateway Advanced and Enterprise editions. The policies that can be used to restrict/grant access to Presentation Server or other resources can range from installed hotfixes/service packs to virus definition versions.

For Active Directory policies, a key decision is whether to apply the policy to computers or users, regardless of the location within Active Directory the policy is applied to. Within Active Directory, policies are applied to different objects like Site, Domain or Organizational Unit (OU). Active Directory policies are broken down into two parts: User Configuration and Computer Configuration. As would make sense, settings included in the user configuration are focused at the user-level and are applied during logon. By default, all users who reside in the OU where the policy is associated to will apply the user-configuration portion of the policy during logon to every system they log into. Likewise, all computers that are members of an OU where a computer configuration policy is applied will apply the policy on startup, which will impact all users who log onto that computer. The first challenge of policy association with Active Directory and Presentation Server deployments revolves around three core areas: Presentation Server-specific computer policies: Presentation Server is a specialized resource in an enterprise; typically a special policy is created and deployed only to the Presentation Servers. This is easily accomplished by creating a separate OU for the Presentation Servers. Organizations can create a Presentation Server-specific computer policy, apply it to the Presentation Server OU, and be confident that the policy is only applied to the computers within the OU and below and nothing else. Based on the policies applied, the Presentation Server OU might have to be further broken down into server roles, geographical locations, or business units. In many circumstances, it is typical to disable the user configuration portion of the base Presentation Server-specific computer policies. This helps prevent user settings from being added to the base computer policy. Presentation Server-specific user policies: Organizations typically have a need for user-specific policies to be applied only when a user logs onto a Presentation Servers. As user accounts could be located anywhere in Active Directory, the organization could simply create a policy at the domain-level, but the policy would be applied to every system any user logged into. Applying user-specific settings to the OU containing the Presentation Servers will also not work as the user accounts are not located within the particular OU unless the Loopback Processing policy is applied to the OU. A Loopback policy, which is a computer configuration policy, forces the computer to apply the assigned user configuration policy of the OU to any user who logs onto the system, regardless of the users location within Active Directory. By using Loopback processing, organizations can force users to apply a specific user configuration policy only if they connect to a server located within the Presentation Server OU. In many circumstances, it is typical to disable the computer portion of the Presentation Server-specific user policies, so settings added to the computer portion of the policy will not impact the computer configuration. Also, by disabling half of the policy, logons times can be improved slightly as the disabled portion of the policy does not require parsing. Active Directory Policy Filtering: As the policy configuration moves into a more advanced stage, there usually becomes a need for a small set of users, like Presentation Server administrators, to have another policy applied when connecting to Presentation Servers. Creating and applying this policy to the OU containing the Presentation Server administrators will not meet the needs because the policy will apply to every system the Presentation Server administrators connect to. Applying the policy to the OU of the Presentation Servers, which has Loopback enabled, will also not work because all users who connect to the Presentation Servers will apply the policy. The solution is to use Active Directory policy filtering. With Policy Filtering, organizations can create policies and further specify which particular users or groups of users should apply the policy. With the Presentation Server administrator example, the organization could create a policy for Presentation Server administrators, assign it to the OU containing the Presentation Servers and set the policy filter so that only the group of Presentation Server administrators applies the policy. This functionality is accomplished within the Properties - Security settings of each policy.

Policy Prioritization
A challenge to overcome, which becomes more difficult as the number of the policies increases, is policy prioritization. As numerous policies can be applied to the same set of users or computers, prioritization must be created so more important policies takes precedence over lower priority policies. The key point for any policy design is to understand the goals of the policy: to create the most efficient standard operating environment for the users without compromising security. Unfortunately, users have different needs thus creating conflict in the policy design, but all needs can be met with a proper policy design and prioritization. Many organizations go about their policy design by creating a base policy for all users, then creating additional policies for particular user needs; samples of common base policies are located in Appendix B: Sample Base Active Directory Computer Configuration Policy and Appendix A: Sample Base Presentation Server Policy. The base policy is often configured to coincide with the preferred operating environment for the users within the organization, while others use the base policy to secure the system as much as possible and then open up features on an as needed basis, which often means hiding operating system options or turning off Presentation Server virtual channels. The base policy in Active Directory and Presentation Server will each have the lowest priority, so all users start from the same point. Once the base policy is complete, a user analysis should identify the needs of different user groups, which will help identify other policy needs. If these settings are approved by the organization, additional policies can be created that are specific for the particular set of users using the different filtering options outlined above. Policy prioritization of these user-group specific policies is not critical until a point is reached when users become members of multiple groups and are thus assigned multiple policies each modifying the same configuration. At this point, there are two common options: Prioritize Policies: Try to keep the numbers of policies to a minimum as larger sets of users can share the same policy. As the number of policies increases, it takes the system longer to apply the policy and also makes it much more difficult to understand which users get what settings. Using the Resultant Set of Policy for Active Directory and Presentation Server policies is instrumental in identifying the correct policy prioritization hierarchy to follow. Create a New Policy: The creation of a new policy might be required because the desired environment for a set of users is not achievable with prioritization as. The common course of action is to create a new policy with a higher priority; however, it is usually recommended to keep the number of policies small in number as more policies increases confusion, complexity and can increase logon time.

Care must be taken when creating multiple policies for many reasons. Each policy created will have an impact on the time required to logon to the system. Although the impact is small, it does add up. Many organizations have a standard for policy design in place that reduces the number of overall policies, but still allows for the granularity of setting modification for the user groups.

Policy Precedence
The policy precedence aspect of policy design is focused around Active Directory policies. As Active Directory is a tree structure, policies can be placed at any level in the tree. When aggregating multiple policies into the resultant policy, the policy aggregation, also called policy precedence, flows as follows: Processed First-Lowest Precedence: Local server tools (Terminal Services Connection Configuration) Processed Second: Local server policy Processed Third: Active Directory policies: Site level Processed Fourth: Active Directory policies: Domain level Active Directory policies: OU level o o o Processed Fifth: Highest level OU in domain Processed Sixth: Next level OU in domain, etc Processed Seventh-Highest Precedence: Lowest level OU containing object (computer or user)

These levels are important to remember, especially in troubleshooting circumstances. Policies from each level are aggregated into a final policy that is applied to the user or computer. In many enterprise deployments, the administrators responsible for the servers hosting Presentation Server do not have the rights to change policies outside of their specific OU, which will typically be the highest level for precedence. This high level of precedence allows the administrators to have the ability to block inheritance from further up the tree. Administrators have the ability to block inheritance thereby allowing lower-level OUs (those with higher precedence) to not incorporate higher-level OUs (lower precedence) into the resultant policy. This gives Presentation Server administrators more control over the settings applied to the servers and the users connecting to the servers. However, if a higher-level OU policy (lower precedence) is configured with No Override, then the lower-level OU policys block inheritance setting will have no effect and the policy will be applied. However, higher-level OU policy settings can be overridden by using a lower-level OU policy to configure the same option. The lower-level OU policies will have a higher priority than the higher-level OU policy. With all of these nuances, it is recommended to use available tools, like Resultant Set of Policy, to validate the observed outcomes with the expected outcomes.

Conclusion
Policy design can be easy or difficult; it all is dependent on the needs of the organization. There is no single, correct policy design as it is oftentimes based on the user and organizations needs. There are numerous ways to achieve the same outcome, each bringing its own benefits and challenges. Regardless of the environment in place, understanding how policies work and interoperate will make designing the policy solution much easier. In many organizations, proper policy design typically follows the following recommendations: Identify the types of policies needed, Active Directory, Presentation Server, Local, or Custom. In many production environments, the solution will be a combination of Active Directory and Presentation Sever policies. Identify how the policies will be assigned to users. It is best to make decisions that allow for more granular control over application of the policies, regardless if the granularity is needed. This means applying the user configuration portion of the policy to the Presentation Server OU and using policy filters to further control the groups of users that will apply the policy. Identify the base policy and the deviations from the base policy required for different user groups. Keep the policies small in numbers and policy prioritization will be easier. Identify if policy inheritance will impact the resulting policy and block or modify the base policy as needed.

Appendix A: Sample Base Presentation Server Policy

The following is a sample of a common base Presentation Server policy from numerous Presentation Server environments. If the base policy strategy is used, a policy similar to this should have the lowest priority. This sample policy should not be used without proper analysis of the organizations goals. Main Level 1 Level 2 Option Status Value
Bandwidth Visual Effects Turn off desktop wallpaper Turn Off Menu Animations Turn Off Window Content While Dragging Image acceleration using lossy compression Audio Clipboard COM Ports Drives LPT Ports OEM Virtual Channels Overall Session Printer TWAIN Redirection Microphone Sound Quality Turn Off Speakers Connection Mapping Optimize/Asynchronous Writes Turn Off COM Ports Turn Off LPT Ports Turn On Automatic Virtual COM Port Mapping Configure TWAIN Redirection Turn Off Clipboard Mapping Turn Off OEM Virtual Channels Turn Off Auto Client Update Enabled Enabled Enabled Enabled

SpeedScreen Session Limits

High compression

Client Devices

Resources

Audio

Enabled

Do not use microphones for audio input

Enabled Enabled Do not connect client drives at logon

Drives

Ports PDA Devices Other

Enabled Enabled

Enabled

Do not allow TWAIN redirection

Enabled

Printing

Maintenance Session Printers Client Printers

Auto-Creation Legacy Client Printers Printer Properties Retention Print Job Routing Turn Off Client Printer Mapping Native Printer Driver Auto-Install Universal Driver

Enabled

Auto-create default printer only

Drivers

Enabled Enabled

Do not automatically install drivers Use universal driver only if requested driver is unavailable

User Workspace

Connections

Limit Total Concurrent Sessions Zone Preference and Failover Server to Client

Content Redirection Shadowing Time Zones

Enabled

Configuration Permissions Do Not Estimate Local Time for Legacy Clients Do Not Use Clients' Local Time

Enabled Enabled

Do not use client redirection from server to client Allow Shadowing Administrators Only

Main

Level 1
Citrix Password Manager Streamed Applications Encryption

Level 2

Option
Central Credential Store Do Not Use MetaFrame Password Manager Configure Delivery Protocol SecureICA Encryption

Status

Value

Security

Enabled

RC5 (128-bit)

Appendix B: Sample Base Active Directory Computer Configuration Policy

The following is a sample of a common base Active Directory computer configuration policy, which is only concerned with Terminal Services settings. If the base policy strategy is used, a policy similar to this should have the lowest priority. Functionality should be modified through higher priority policies based on the user needs identified in the policy design. The base policy could also be expanded to include other non-Terminal Services related items. This sample policy should not be used without proper analysis of the organizations goals. Main Level 1 Level 2 Option Status
Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Automatic reconnection Keep-Alive Connections Automatic reconnection Restrict Terminal Services users to a single remote session Enforce Removal of Remote Desktop Wallpaper Deny log off of an administrator logged in to the console session Limit number of connections Limit maximum color depth Allow users to connect remotely using Terminal Services Do not allow local administrators to customize permissions Remove Windows Security item from Start menu Remove Disconnect option from Shut Down dialog Set path for Terminal Services Roaming Profiles Terminal Services User Home Directory Sets rules for remote control of Terminal Services user sessions Start a program on connection Allow Time Zone Redirection Do not allow clipboard redirection Do not allow smart card device redirection Allow audio redirection Do not allow COM port redirection Do not allow client printer redirection Do not allow LPT port redirection Do not allow drive redirection Do not set default client printer to be default printer in a session Terminal Server fallback printer driver behavior Always prompt client for password upon connection Set client connection encryption level RPC Security Policy/Secure Server License Server security group Prevent License upgrade Do not use temp folders per session Do not delete temp folder upon exit

Enabled

Enabled Enabled Enabled Enabled

Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Client/Server Data Redirection Encryption and Security Encryption and Security Encryption and Security Licensing GPOs Licensing GPOs Temporary Folders GPOs Temporary Folders

10

Main
Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components Windows Components System

Level 1
Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Group Policy

Level 2
GPOs Session Directory Session Directory Session Directory Session Directory Sessions Sessions Sessions

Option
Terminal Server IP address redirection Join session directory Session directory server Session directory cluster name Set time limit for disconnected sessions Sets a time limit for active Terminal Services sessions Sets a time limit for active but idle Terminal Services sessions User group policy loopback processing mode

Status

Enabled

11

Appendix C: Sample Base Active Directory User Configuration Policy

The following is a sample of a common base Active Directory user configuration policy, which is only concerned with Terminal Services settings. If the base policy strategy is used, a policy similar to this should have the lowest priority for the user configuration and be applied to the OU containing the servers hosting Presentation Server. Functionality should be modified through higher priority policies based on the user needs identified in the policy design. The base policy could also be expanded to include other non-Terminal Services related items. This sample policy should not be used without proper analysis of the organizations goals. Main Level 1 Level 2 Option Status
Windows Components Windows Components Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Terminal Services Client Sessions Sessions Sessions Sessions Sessions Start a program or connection Set rules for remote control of Terminal Services users sessions Do not allow passwords to be saved Set time limit for disconnected sessions Sets a time limit for active Terminal Services sessions Sets a time limit for active but idle Terminal Services sessions Allow reconnection from original client only Terminate sessions when time limits are reached

Windows Components Windows Components Windows Components Windows Components Windows Components

Enabled Enabled Enabled

12

Notice The information in this publication is subject to change without notice. THIS PUBLICATION IS PROVIDED AS IS WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. CITRIX SYSTEMS, INC. (CITRIX), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE. This publication contains information protected by copyright. Except for internal distribution, no part of this publication may be photocopied or reproduced in any form without prior written consent from Citrix. The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products. Citrix does not warrant products other than its own. Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies. Copyright 2007 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009 U.S.A. All rights reserved.

Version History
Daniel Feller (Sr. Architect) Daniel Feller 1.0 1.1 Content created Updated Policy tables July 31, 2007 August 21, 2007

851 West Cypress Creek Road

Fort Lauderdale, FL 33309

954-267-3000

http://www.citrix.com

Copyright 2007 Citrix Systems, Inc. All rights reserved. Citrix, the Citrix logo, Citrix ICA, Citrix MetaFrame, and other Citrix product names are trademarks of Citrix Systems, Inc. All other product names, company names, marks, logos, and symbols are trademarks of their respective owners.