The last thing that we need to look at when considering MetaFrame XP security is how your MetaFrame XP servers will be administered. This is often overlooked, but very important. Even the world's most technically secure environments won't actually be secure if too many people have administrative rights.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Another big part of the administration of your MetaFrame XP servers relates to how the servers are actually used. This includes how administrators or help desk personnel shadow end users and how everyone's actions are logged, recorded, and audited.
As we look at the security of the MetaFrame XP administrative environment, we'll focus on three areas:
- MetaFrame XP administrators.
- Shadowing end users.
- Auditing and usage logs.
MetaFrame XP Administrators
You can configure your server farm administrators using the Citrix Management Console (CMC | Farm | Citrix Administrators). Farm administrators can be added by group or by user. In environments with Feature Release 1 and lower, there are two levels of farm administrator: "Read-Only" and "Read-Write." In Feature Release 2 environments, you can also configure custom levels of farm administration.
When granting accounts different levels of administrative access, there are two things to consider:
- Administrative rights apply to the IMA Data Store only.
- Administrative rights can only be assigned on a farm-wide basis.
When you assign MetaFrame XP administrator rights to the server farm, you are actually assigning rights to the IMA data store itself. Assigning administrator rights in the CMC does not change any NTFS file rights anywhere and it does not add the user to any Windows domain groups. It is not necessary for a user to have domain administrator or server administrator rights for him to be granted farm administrator rights-although these rights are usually granted for convenience.
Assigning Read-Only farm administrator rights allows the assigned user to read any information about any server from the IMA data store, and the Read-Write privilege allows users to add, delete, change, and reconfigure the information on MetaFrame XP farm servers that is contained in the IMA data store.
You can use the custom rights in Feature Release 2 environments to customize the specific administrative rights that a user has. When you configure custom rights, you have extremely granular control over the type of rights that an administrator has. You do not have control over the where those rights are applied.
For example, you can use custom administrator rights to grant a user the ability to edit load evaluators without giving him the ability do anything else in the farm. However, since all farm administrative settings apply on a farm-wide basis, that administrator would be able to edit load evaluators on any server in the farm. There is no way to allow users to administer certain servers while preventing them from administering others. Think of these rights as "options-based," not "server-based."
In fact, all administrative rights assigned through the CMC always apply on a farm-wide basis. If you have some administrators that you only want to administer certain farm servers, you need to break the server farm into multiple farms, or trust the administrators not to touch the wrong servers.
Some crafty people have thought that they could find a way around this "all or nothing" limitation, by creating one single server farm with granular administration by setting local rights on MetaFrame XP servers. They created three servers in one farm. Each server had its own administrator, and each administrator only had administrative level access on his own server-with no rights on the other servers. All three administrators were configured with server farm Read-Write administrator privileges.
The problem with this scenario is that all of the administrators have full read-write administrative access to the IMA data store. Administrator "A" cannot access Administrator "B's" server directly through the network, but Administrator "A" can launch the CMC and delete users, applications, and configuration information for Administrator "B's" server. This is because this server farm information does not reside on the local server, but rather in the IMA data store, where Administrator "A" is a full Read-Write administrator.
Help Desk Security Rights
One of the nice things about the ability to set custom administrative rights in your server farm with Feature Release 2 is that it allows you to give your help desk analysts the power to do their jobs without giving them full farm administration rights.
Most people create a Windows domain group called "Helpdesk" and give them the following custom rights in the server farm:
- Log on to Citrix Management Console
- View Printers and Printer Drivers
- View Published Applications and Content
- View Resource Management Configuration
- View Server Information
- Disconnect Users
- Log Off Users
- Reset Sessions
- Send Messages
- View Session Management
- View User Policies
MetaFrame Administration in Active Directory Environments
Just as publishing applications to users in AD environments is no different than in non-AD environments, MetaFrame XP administration is the same in both environments. MetaFrame XP does not extend the Active Directory schema. The "limitation" of only having farm-wide administrators still holds true in the AD environment. The only change from an administration standpoint with in AD environment is that MetaFrame XP administrators can be assigned based on the AD-only groups. (Universal, etc.)
MetaFrame XP shadowing allows administrators to remotely view a selected end user's ICA session. There are several security and privacy concerns raised when deciding how to use shadowing. These stem from the fact that a malicious user could shadow another user's session without them knowing it. They would be able to view potential sensitive or personal information.
To mitigate this security risk, you have the option of choosing not to enable any of the shadowing features or choosing to manage the shadowing environment so that only authorized users are able to shadow other users. Additionally, if you do enable shadowing, you can log all shadow requests for security purposes. Let's look at how these two options can be applied in the real world.
Choosing not to Enable Shadowing
When you install MetaFrame XP, you have the option of choosing not to install the shadowing capabilities. If the security principles of your environment prevent you from using shadowing, this allows you to easily turn off shadowing for your environment.
You also have the ability to configure which users are able to shadow other users. These rights are configured at the connection layer via the Citrix Connection Configuration utility (CCC | Right-click connection | Permissions). The "Full Control" default rights give users shadowing rights over a connection. Alternately, you can select "Advanced..." ("Special Access" in NT 4) for access to granular rights, where you can assign shadowing permissions without assigning the "Full Control" rights.
If you are using Feature Release 2, you can also configure shadowing permissions as part of a Citrix user policy. (See Chapter 5 for more information.)
Shadowee / Shadower Interaction
Even with permissions to shadow users, there are two shadowing parameters that can be configured, "Input" and "Notification." Each of these can be set to "ON" or "OFF." These can be configured as a property of a connection via the Citrix Connection Configuration (CCC | Edit Connection | Advanced Button) or as a property of the user's account via the user management tool for your platform. If you're using Feature Release 2, you can also specify the minimum settings for shadowing users with a Citrix user policy.
Shadow Session Logging
The MetaFrame XP shadow taskbar can be configured to log all shadow events (Right click on Shadow taskbar | Logging Options... | Enable logging). The logs that are produced are by default not secure-making them not very useful. Most people want to log shadowing so that they can watch potentially mischievous employees who might want to spy on other users.
Fortunately, in MetaFrame XP, there is a special DLL (shdwhook.dll) that is responsible for logging shadowed sessions. This DLL watches all applications that could be used for shadowing (cshadow.exe, mfadmin.exe, shadow.exe, and tsadmin.exe) and logs the sessions to the event viewer.
MetaFrame XP User Auditing
Often times MetaFrame XP administrators want to be able to create log files that they can use to audit specific MetaFrame XP user events, such as user session logons and logoffs. There are three ways that audit logs can be created:
- MetaFrame XPa or XPe load manager.
- Windows user account auditing.
- Third party auditing and logging tools.
Logging Users with MetaFrame XPa or XPe Load Manager
When thinking of ways that user actions can be logged, most people immediately think of the logging that is available with MetaFrame XP load manager in MetaFrame XPa and XPe. This logging, which is enabled via the Citrix Management Console (CMC | Load Evaluators | Log Tab | Enable Logging Button), will show ICA user requests and resolutions of those requests.
The MetaFrame XP load manager log is secure (except for farm administrators with Read-Write privileges) and it works well for what it was intended for. The problem is that this log was intended for load balancing troubleshooting purposes. It has a small size limitation. After it reaches 16k it stops logging events until it is manually cleared and reset.
The load manager log should not be used for security purposes.
Logging Users with Windows Auditing
For more industrial-strength user logging, it's best to think back to your Windows NT administration 101 class:
- In NT 4 environments, you can enable user auditing via user manager for domains (Security Menu | Auditing).
- In Windows 2000 environments, auditing can be configured via a group policy in Active Directory environments (Group Policy Object | Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy), or via the local computer policy when group policies are not used (Administrative Tools | Local Security Settings | Local Policies | Audit Policy). When Active Directory is used, most people configure the audit policies for the Group Policy Object that has the OU that contains their MetaFrame XP servers.
Once your servers are set to allow auditing, you can configure auditing for any item via the audit dialog box (Item Properties | Security Tab | Advanced Button | Audit Tab). There are many books dedicated to Windows 2000 security that can take you step by step through the various security and audit log elements of Windows 2000.
All of the user and computer auditing information is written to the security event log. There is a utility included on the MetaFrame XP CD, auditlog.exe, that can be used to dump the contents of the security event log to a CSV file. From there, you can import that file into a spreadsheet to generate audit reports.
Logging Users with Third Party Tools
If you need heavy duty security auditing and logging in your MetaFrame XP environment, you will probably be disappointed with the native components that are available from Microsoft of Citrix. Most likely, you will want to use a third party security tool, such as Techtonik's ONEAPP utility. Details are available from www.oneapp.co.uk. New information about other third party tools is constantly available at http://thethin.net.