Citrix E-Docs – This is the official online documentation for all Citrix products, provided by Citrix. You will find tons of answers there. It is a branch of the well-known Citrix support site, which is also provided by Citrix and where most Citrix public CTX articles are located

Brian Madden – One of the best Citrix resources on the web; Very educative and informative. Highly recommended

XenAppTraining – Also very informative and has some great free videos for you to look. You might need to register to watch the videos. I particularly like this Windows 2008 R2 configuration video: Win2008R2 Configuration . It gives you some good tips (time: 17min)

CtxAdminTools – Great variety of tools to make the Citrix and Microsoft Admin’s life easier. The author, Guillermo Musumeci is a Windows Infrastructure Architect with a “passion for designing, building, deploying and supporting enterprise architectures using Microsoft, Citrix and VMware producs” (from his About page )

CitrixExperience – Offers Free study guides for a lot of the Citrix Exams
Here are some free study guides for the Citrix exams.

Enjoy it!

The XenApp planning and installation documentation uses the following terminology.

Multi-user environment
An environment, including XenApp and Terminal Services, where applications are published on servers for use by multiple users simultaneously.
Application servers
The farm servers that host published applications.
Infrastructure servers
The farm servers that host services such as the data store or the license server. Typically, they do not host published applications.
Production farm
A farm that is in regular use and accessed by users.
Design validation farm
A farm that is set up in a laboratory environment, typically as the design or blueprint for the production farm.
Pilot farm
A preproduction pilot farm used to test a farm design before deploying the farm across the organization. A true pilot is based on access by select users, and then adding users until all users access the farm for their everyday needs.
Enumeration
The process in which a client transmits data to locate servers on the network and retrieves information about the server farm’s published applications. For example, during enumeration, the XenApp Plug-in for Hosted Apps communicates with the Citrix XML Service or the ICA browser, depending on the browsing protocol selected in the plug-in.

XenApp Setup comprises two installation wizards:

Create a New Farm. The first time you install XenApp, select Create a New Farm in the installation wizard and Setup creates the farm with that server hosting specific roles.

The server where you installed XenApp and created the farm is the first farm server or the Create farm server.
Join an Existing Farm. When you run Setup on servers after installing XenApp on the first farm server, you take a different path in Setup and XenApp references the settings you specified on the first farm server. These servers join the existing farm and communicate with the first server in the farm.

Farm Environment

You should already be familiar with client-server architecture, redirection, and application publishing.

Citrix Licensing
A Citrix License Server is required for all XenApp deployments. Install the license server on either a shared or stand-alone server, depending on your farm’s size. After you install the license server, download the appropriate license files and add these to the license server.
Data Store
The data store is the database where servers store farm static information, such as configuration information about published applications, users, printers, and servers. Each server farm has a single data store.
Data Collector
A data collector is a server that hosts an in-memory database that maintains dynamic information about the servers in the zone, such as server loads, session status, published applications, users connected, and license usage. Data collectors receive incremental data updates and queries from servers within the zone. Data collectors relay information to all other data collectors in the farm. By default, the first server in the farm functions as the data collector.
By default, the data collector is configured on the first farm server during the Create Farm Setup and all other servers are configured with equal rights to become the data collector if the data collector fails. When the zone’s data collector fails, a data collector election occurs and another server takes over the data collector functionality. Farms determine the data collector based on the election preferences set for a server
The data collector is an infrastructure server and applications are typically not published on it.
Zone
A zone is a grouping of XenApp servers that communicate with a common data collector. In large farms with multiple zones, each zone has a server designated as its data collector. Data collectors in farms with more than one zone function as communication gateways with the other zone data collectors.
The data collector maintains all load and session information for the servers in its zone. All farms have at least one zone, even small ones. The fewest number of zones should be implemented, with one being optimal. Multiple zones are necessary only in large farms that span WANs.
Streaming File or Web Server
Applications can be delivered to users by either streaming or hosting the applications on the server. If you are streaming applications, either to client or server, you must install a streaming file server in your environment. When streaming applications, you create profiles of the application and then store the profile on a file or Web server. The profile consists of the manifest file (.profile), which is an XML file that defines the profile, as well as the target CAB files, a hash key file, the icons repository (Icondata.bin), and a scripts folder for pre-launch and post-exit scripts.
Web Interface
The Web Interface is a required component in any environment where users access their applications using either the XenApp plugin or a Web browser. Install the Web Interface on a stand-alone computer; however, where resources are limited, the Web Interface is sometimes collocated with other functions..
XenApp Web and XenApp Services Sites
XenApp Web and XenApp Services sites (formerly known as Access Platform and Program Neighborhood Agent Services sites, respectively) provide an interface to the server farm from the client device. When a user authenticates to a XenApp Web or XenApp Services site, either directly or through the XenApp plug-in or the Access Gateway, the site:

Forwards the user’s credentials to the Citrix XML Service
Receives the set of applications available to that user by means of the XML Service
Displays the available applications to the user either through a Web page or by placing shortcuts directly on the user’s computer

Citrix XML Service and the Citrix XML Broker
The Citrix XML Broker functions as an intermediary between the other servers in the farm and the Web Interface. When a user authenticates to the Web Interface, the XML Broker:

The XML Broker is a function of the Citrix XML Service. By default, the XML Service is installed on every server during XenApp Setup. However, only the XML Service on the server specified in the Web Interface functions as the broker. (The XML Service on other farm servers is still running but is not used for servicing end-user connections.) In a small farm, the XML Broker is typically designated on a server dedicated to several infrastructure functions. In a large farm, the XML Broker might be configured on one or more dedicated servers.
The XML Broker is sometimes referred to as a Citrix XML Server or the Citrix XML Service. For clarity, the term XML Broker is used to refer to when the XML Service functions as the intermediary between the Web Interface and the IMA service, regardless of whether it is hosted on a dedicated server or collocated with other infrastructure functions.

This illustration uses a large farm to show how the Web Interface and the XML Broker work together. (1) The user connects to the Web Interface through the XenApp plug-in or a Web browser; (2) the Web Interface contacts the XML Broker to determine which applications are available for this user; (3) the XML Broker queries the IMA service for this information and returns the results to the Web Interface; (4) the Web Interface displays the available applications to the user either through a Web page or by placing shortcuts directly on the user’s computer..

Infrastructure Servers
XenApp farms have two types of servers: infrastructure servers and member servers that host published applications. Infrastructure servers perform specific functions and do not typically host published applications, except in small farms. The services include:

Farm infrastructure services – Data store, data collector, and the Citrix XML Broker.
Access infrastructure services – Web Interface, Secure Gateway (optional), and Access Gateway (optional).
Additional services – Citrix License Server, Streaming File or Web Server (optional), a computer for profiling applications, Configuration Logging database (optional), EdgeSight database (optional), and SmartAuditor player (optional).

One or more infrastructure services can be grouped together in small farms. In large deployments, each service runs on one or more dedicated servers.
This illustration suggests which infrastructure functions can be grouped on the same server, depending on the size of your environment.

Factors other than size can affect how infrastructure functions are grouped . Security concerns, virtualized servers, and user load play a part in determining which functions can be collocated.
This illustration depicts infrastructure servers in a large farm. The Web Interface, XML Service, data collector, and data store are deployed on separate servers.

source: XenApp 5 for Windows Server 2008 – E-Docs
Note: This link has also several great illustrations of the components of XenApp. If you learn visually like I do you must see these illustrations

XML Port and SSL Question
Dan Murray made a interesting comment on XML and SSL
You need to do three things… you have to install a certificate on the server that is handling the XML requests, typically a Zone Data Collector in a XenApp farm, or a DesktopDelivery Controller in a XenDesktop farm. Next, setup the SSL Relay on that ZDC/DDC server. Finally, you have to configure the WI XML port to use SSL. You need all three pieces to be working to use SSL across the board the way you want to

How to Connect a Computer to a Stereo System

You probably need to buy an inexpensive “Y” RCA female adapter

Do a google search on this:
stereo audio female Y cable
or this:
“2 x RCA Male / 1 x 3.5mm Stereo Female, Y-Cable, 6 inch”
or this:
mini 3.5mm stereo plug to dual RCA plug cable, 3 to 25 feet long

It costs less than 6 dollars. I saw as low as $1.45

This video also explains in less than one minute

Also if you want to spend more this video gives you good tips too by telling you the HDMI, MAC and USB options as well

I love Wikis and YouTube’s How To’s!

google.com

• Enables users to search the world’s information, including webpages, images, and videos.

• 2 Facebook

facebook.com

A social utility that connects people, to keep up with friends, upload photos, share links and … More

• 3 YouTube

youtube.com

• YouTube is a way to get your videos to the people who matter to you. Upload, tag and share your videos

• 4 Yahoo!

yahoo.com

A major internet portal and service provider offering search results, customizable content,

• 5 Baidu.com

baidu.com

• The leading Chinese language search engine, provides “simple and reliable” search experience

• 6 Wikipedia

wikipedia.org

A free encyclopedia built collaboratively using wiki software. (Creative Commons Attribution-Sh… More

• 7 Windows Live

live.com

Search engine from Microsoft.

• 8 Blogspot.com

blogspot.com

• 9 Amazon.com

amazon.com

Amazon.com seeks to be Earth’s most customer-centric company, where customers can find and discover

• 10 Twitter

twitter.com

Social networking and microblogging service utilising instant messaging, SMS or a web interface.

• 11 QQ.COM

qq.com

• China’s largest and most used Internet service portal owned by Tencent, Inc

• 12 淘宝网

taobao.com

包括电脑通讯、数码、男装、女装、童装、化妆品、书籍音像、运动用品、游戏装备等各种商品的买卖，还有相关的社区交流，同时提供支付宝网上交易安全保证系统。.

• 13 Google India

google.co.in

Indian version of this popular search engine. Search the whole web or only webpages from India

• 14 MSN

msn.com

Portal for shopping, news and money, e-mail, search, and chat.

• 15 Yahoo! Japan

yahoo.co.jp

Japanese version of popular portal site.

• 16 LinkedIn

linkedin.com

A networking tool to find connections to recommended job candidates, industry experts and busin… More

• 17 新浪新闻中心

sina.com.cn

包括即日的国内外不同类型的新闻与评论，人物专题，图库。

• 18 WordPress.com

wordpress.com

Free blogs managed by the developers of the WordPress software. Includes custom design template

• 19 eBay

ebay.com

International person to person auction site, with products sorted into categories.

• 20 Google

google.de

Suche im gesamten Web, in deutschsprachigen sowie in deutschen Sites. Zusätzlich kann gezielt n… More

• 21 Google谷歌

google.com.hk

谷歌搜索在中国的官方网站。

• 22 Яндекс

yandex.ru

Поиск информации в интернете с учетом русской морфологии, возможность регионального уточнения. … More

• 23 Google UK

google.co.uk

The local version of this pre-eminent search engine, offering UK-specific pages

• 24 Google 日本

google.co.jp

多言語対応サーチエンジンの日本版。ウェブ、イメージおよびニュース検索、Usenet掲示板。… More

• 25 Google France

google.fr

Version française du moteur de recherche. Propose des outils et des services pour les internaut.

The  hives are as follows:

“Registry keys are similar to folders — in addition to values, each key can contain subkeys, which may contain further subkeys, and so on” ( wikipedia )

The hierarchy of registry keys can only be accessed from a known root key handle or a Hive.

E.g. HKEY_LOCAL_MACHINE\Software\Adobe\Adobe Reader refers to the subkey “Adobe Reader” of the subkey “Adobe” of the subkey “Software” of the HKEY_LOCAL_MACHINE root key.

So, a registry Hive is higher in the registry hierarchy than a registry key. A registry key is normally contained inside of a registry hive or a root key

Good source of information about the registry: technet

1. Make sure the license server name on the license file has the same name as the hostname of the license server (note: the name is case sensitive, so if the hostname has upper and lower case, the license file must match the upper and lower case of the hostname)

The license file is located in c:\program files (x86)\citrix\Licensing\My Files folder. The license file has a .LIC extension.

It can be opened by MS WordPad, but it cannot be modified (it has a signed key, which is a encrypted signature for the number of licenses described in the top of the file, so if you change the number of licenses manually, the signed key won’t match the signed key and this will make your license file useless)

NOTE: The license file is tied to dates, not the version of XenApp. As long as the date interval for the license is  valid, the subscription advantage  license is valid and the license file doesn’t care what version of XenApp you have.

Also

2. Open a command prompt and type : “netstat -a” on the licensing server and see if port 27000 is listening.

3. If you change the license file name or did any modifications  in the policies container of XenApp (DSC or Apps Center) make sure to run from the command prompt “gpupdate /force” on the server you made the change(s)

4. Open a command prompt and type “net stop imaservice” and “net start imaservice“  to restart the IMA service after the gpupdate,  so IMA can re-read the policies

5. To check if the Licensing registry key is correct: (on the XenApp server or servers), open regedit and look into the [HKEY_LOCAL_MACHINE\Software] hive for this key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\IMA] and

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\IMA\Licensing]

Make sure you see something like this:

“LicenseServerPortNumber”=dword:00006978

“LicenseServerHostName”=”server name”

To recreate the ICA listener in XA6.0 or XenApp 6.5:

Navigate to the [HKEY_LOCAL_MACHINE\System] hive and look for this key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ICA-Tcp]

Delete the ICA-Tcp key and reboot.

After rebooting import the ICA listener key from another server that is working properly

(see this Citrix article here for more details)

As an analogy, think of the IPA file as a “zip” file used in the Apple realm.

Apple created the ITunes and App Store to control and manage the deployment of all  products for the “I” family.

So, how can “jailbroken” devices install  ”I” apps?

The answer lies on an obscure command:

zip -0 -y -r myAppName.ipa Payload/

This unsigned, unofficial .ipa file can be created by some smart re-engineering efforts as follows:

1. You first copy the file with the extension .app from the Products folder of the application called Xcode to a folder called Payload

2. Compress the file located in Payload by using the zip command described above

3. This “new” unsigned, unofficial .ipa file can now be installed on jailbroken devices

4. There is a thrid party software called Appsync that allows such maneuver.

But, what is so unique about the .ipa file?

The .ipa file has a built-in structure that  iTunes and AppStore understand and certify . The jailbroken version doesn’t have such “certification”.

The .ipa file contains the following files:

appname.app. It is the binary (or executable)  file for the app

iTunes Artwork file.  It is a PNG image (containing the app’s icon for showing the app in iTunes and the App Store)

iTunesMetadata.plist.  It is a editable file (you can use TextEdit to open it) that contains information such as the copyright information, the release date, the purchase date, the name of the developer and company who created it, etc. Think of it as an “Help-About” used in the WinTel world

See below a good example of the structure of an “official” .ipa file:

/Payload/
/Payload/Application.app
/iTunesArtwork
/iTunesMetadata.plist

See below some great links that help complement the information provided here:

Special “Thanks” to Wikipedia for providing a great detailed explanation of the .ipa file

Xcode

iTunesMetadata.plist

.APP

TextEdit

Fair Play DRM technology

Xcode Glossary:

Xcode: It is Apple’s integrated development environment for creating apps for the iPhone, Ipad, IPod and Mac.

Xcode includes the Xcode IDE, instruments, iOS Simulator, the latest Mac OS X and iOS SDKs (software development kits)

“An .ipa file is an iPhone application archive file which stores an iPhone app. It is usually encrypted with Apple‘s FairPlay DRM technology. Each .ipa file is compressed with a binary for the ARM architecture and can only be installed on an iPhone, iPod Touch, or iPad. Files with the .ipa extension can be uncompressed by changing the extension to .zip and unzipping.
.ipa files cannot be installed on the iPhone Simulator because they do not contain a binary for the x86 architecture. To run applications on the simulator, original project files which can be opened using the Xcode SDK are required.”  (from Wikipedia )

Ex: if it says something like [servername or machine-name] followed by the words: (this computer), it means you are logging on locally to your computer or server and therefore you are not automatically mapping the network drive, printers and other network resources available to you in the Windows AD environment

On the other hand if you are logging on to [domain name] and without the words “this computer” between parenthesis you are definitely logging on to a domain environmnent

See screen shot below:

ADM files are Network and System administrators best kept secrets. If you know how to use and configure them you will look like a genius in your IT department. To explain in simple words: ADM files populate user and computer interface settings and allow you to edit and make modifications to those settings(see Microsoft link further below to download O.S. ADM files)

If you use Citrix in your environment, there are two acronyms you must know:
ICA and IMA

ICA or Independent Computing Architecture is Citrix proprietary protocol that specifies how data travels between server and clients. I like to use the middle letter “C” as a mnemonic to remind me that ICA is a “client” protocol because it is installed on a “client” device; when installed it allows the “client” to gain access to applications and other resources stored on a server. That is the reason why you need a “client” plugin (aka as Citrix Online plugin, Citrix Receiver, Program Neighborhood, etc). The plugin contains the code and the set of files used for the ICA protocol.
The ICA protocol uses port 1494 to communicate (and port 2598 if session reliability is enabled)

What most people don’t know is the fact that there is a ADM file associated to the Citrix plugin that manages several client settings when data is received on the client
To use the ICA.ADM administrative template you need to load two components:
1. Load the GPOE (group Policy Object Editor) by opening MMC (start-run-MMC) and clicking on File-Add/Remove Snap-in and select GPOE from the list
2. Load the ICA.ADM file by right clicking on administrative templates and selecting “Add Remove Templates”. Browse to the Citrix ICA configuration folder (c:\program files\citrix\ICA client\configuration) and selecting the icaclient.adm file there
Once loaded you can then edit the GPO file and enable and disable several ICA settings.
The modifiable container settings are:

Network Routing
User authentication
Remoting client devices
User Experience
Client Engine and
Multi-Stream ICA

These 6 containers have 27 configurable settings. These 27 configurable settings have 98 possible options that can be modified for the Citrix Receiver plugin version 13! These numbers will vary depending on the version of the plugin)

The ICA protocol has a server component called the ICA Listener; the settings on the ICA Listener can be modified on the server under the Terminal Services Configuration Menu

Important things to remember:

“In Citrix products, Citrix policies always supersede all other policies and settings in your environment, including Active Directory policies and Windows settings

BUT (and this is a big BUT!) Always remember:

the most restrictive settings usually wins! (contradictory but true!)

Any rule that is disabled takes precedence over a lower-ranked rule that is enabled. Policy rules that are not configured are ignored.

Using Citrix policies with Active Directory
Active Directory and Windows policies do not take precedence over XenApp
policies. In a XenApp environment and with XenApp features, Citrix policies always take precedence over Windows policies and settings. Citrix XenApp policies were designed, so that they do not conflict with Active Directory policies.
In a Citrix environment, XenApp policy rules override the same settings
configured in an Active Directory policy or using the Terminal Services
Configuration tool. They also override Microsoft policies, including those that
are related to typical Remote Desktop Protocol (RDP) client connection settings such as the policies for Desktop wallpaper, Menu animations, and Windows contents while dragging.
However, XenApp policy rules do not always override policies for encryption and shadowing. These policies behave according to the most restrictive settings configured by the Terminal Services Configuration tool, Active Directory group policies, application configuration, and Citrix policies.
If you are familiar with Active Directory, note these important distinctions:
• For Active Directory policies, the disabled setting affects how the feature
functions. That is, it disables or enables the feature.
• For XenApp policies, the disabled setting only prevents a lower-priority
policy from being able to enable the policy rule. Disabling a XenApp policy
rule does not disable its corresponding feature in the product.” source: Citrix XenApp Admin Guide

======
IMA
======
ICA is for “clients” and IMA is for “servers”
This distinction is very clear
IMA or “Independent Management Architecture” is a Windows server protocol and a database component

IMA is both a database (called data store) and the protocol used to transfer background information among the XenApp servers

It is important to emphasize that: The IMA protocol is used for server-to-server communication only. The server to client communication is done by the ICA protocol

Every XenApp server in a XenApp farm runs the “IMA Service.” This service is the central component that communicates with the IMA data store and other XenApp servers in the farm. Also, the IMA service communicates with the CMC (PS4.5 and XenApp 5) DSC (XenApp 6) and Apps Center (XenApp 6.5) to allow administrators to manage and configure the XenApp farm

The IMA service component contains a collection of subsystems or DLL files associated with the different parts of XenApp; There are Dlls associated with the subsystems available for the farm, such as the policies, licensing, administrators list, servers, applications, etc.

Here are some DLLs:
The subsystem used for the access database is the imaacces.dll
IMASql.dll subsystem is used for SQL database
ImaPsSs.dll subsystem is used for the servers
ImaRuntimeSS.dll
mstjes40.dll
aiess.dll

The IMA data store works on port 2512 and 2513. The port 2512 is used for communication between servers and the port 2513 is used for communication with DSC/Apps Center

Brian Madden has a great article giving great details on the six processes that take place for the IMA data store: Brian Madden

Finally find here some Microsoft ADM files available for download:

Group Policy ADM files:

“Administrative Template files are used to populate user interface settings in the Group Policy Object Editor, enabling administrators to manage registry-based policy settings. Each successive Windows operating system and service pack includes a newer version of these .adm files.” (excerpt from the link above)

The source of these articles contain well explained pictures to clarify the subject better, so I recommend the reader to actually visit the links indicated here

********************************************************************

When to create a external Trust? pasted from: MSDN

When to create an external trust
Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

When to create an external trust

You can create an external trust to form a one-way or two-way, nontransitive trust with domains outside of your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust

When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside of the forest.

Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling advanced features. For information about enabling advanced features, see To view advanced features.

In domains with the functional level set to Windows 2000 mixed, it is recommended that you delete external trusts from a domain controller running Windows Server 2003. External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the domain controllers running Windows NT 4.0 or 3.51. However, only the trusted side of the relationship can be deleted on the domain controllers running Windows NT 4.0 or 3.51. The trusting side of the relationship (created in the Windows Server 2003 domain) is not deleted, and although it will not be operational, the trust will continue to display in Active Directory Domains and Trusts. To remove the trust completely, you will need to delete the trust from a domain controller running Windows Server 2003 in the trusting domain. If an external trust is inadvertently deleted from a domain controller running Windows NT 4.0 or 3.51, you will need to recreate the trust from any domain controller running Windows Server 2003 in the trusting domain.

For more information about how to create an external trust, see Create an external trust.

Securing external trusts

To improve the security of Active Directory forests, domain controllers running Windows Server 2003 and Windows 2000 Service Pack 4 (or higher) enable security identifier (SID) filter quarantining on all new outgoing external trusts by default.

By applying SID filter quarantining to outgoing external trusts, you prevent malicious users who have domain administrator level access in the trusted domain from granting, to themselves or other user accounts in their domain, elevated user rights to the trusting domain.

When a malicious user can grant unauthorized user rights to another user it is known as an elevation of privilege attack. For more information about SID filtering and how to further mitigate an elevation of privilege attack, see MS02-001: Forged SID could result in elevated privileges in Windows 2000 (http://go.microsoft.com/fwlink/?LinkId=102075).

How SID filter quarantining works

When security principals are created in a domain, the domain SID is included in the security principal’s SID to identify the domain in which it was created. The domain SID is an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal’s authenticity.

In a similar fashion, outgoing external trusts created from the trusting domain use SID filter quarantining to verify that incoming authentication requests made from security principals in the trusted domain contain SIDs of security principals from the trusted domain only. This is done by comparing the SIDs of the incoming security principal to the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the offending SID.

SID filtering ensures that any misuse of the SID history attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of the trusting forest.

The SID history attribute can be useful to domain administrators when they migrate user and group accounts from one domain to another. Domain administrators can add SIDs from an old user or group account to the SID history attribute of the new, migrated account. By doing this, domain administrators give the new account the same level of access to resources as the old account.

If domain administrators could not use the SID history attribute in this way, they would have to track down and reapply permissions for the new account on each network resource that the old account had access to.

Understanding the threat

If not for SID filtering on outgoing external trusts, a malicious user with administrative credentials residing in the trusted domain could sniff network authentication requests from the trusting domain to obtain the SID information of a user who has full access to resources in the trusting domain, such as a domain administrator.

After obtaining the domain administrators SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account’s SID history attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources within that domain. In this scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to the entire trusting forest.

SID filtering neutralizes the threat of malicious users in the trusted domain from using the SID history attribute to gain elevated privileges.

Impact of SID filter quarantining

SID filter quarantining on external trusts can affect your existing Active Directory infrastructure in the following two areas:

SID history data that contains SIDs from any domain other than the trusted domain will be removed from authentication requests made from the trusted domain. This will result in access being denied to resources that have the user’s old SID.

Universal group access control strategy between forests will require changes.

When SID filter quarantining is enabled, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.

If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filter quarantining will have a major impact on your access control strategy.

Because universal groups must adhere to the same SID filter quarantining guidelines as other security principal objects (that is, the universal group object SID must also contain the domain SID), you should verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain.

If the universal group in the trusted forest was not created in the trusted domain, even though it may contain users from the trusted domain as members, authentication requests made from members of that universal group will be filtered and discarded.

Therefore, before assigning access to resources in the trusting domain for users in the trusted domain, you should confirm that the universal group containing the trusted domain users was created in the trusted domain.

Disabling SID Filter quarantining

Although it is not recommended, you can disable SID filter quarantining for an external trust by using the Netdom.exe tool. You should consider disabling SID filter quarantining only in the following situations:

You have the same level of trust for all administrators who have physical access to domain controllers in the trusted domain as the administrators in the trusting domain.

You have a strict requirement to assign universal groups to resources in the trusting domain that were not created in the trusted domain.

Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access to resources in the trusting domain based on the SID history attribute.

Only domain administrators can disable SID filtering. To disable SID filter quarantining for the trusting domain, type the following syntax at a command-prompt:

Netdom trust TrustingDomainName /domain: TrustedDomainName /quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd

To enable SID filter quarantining, set the /quarantine: command-line option to Yes. For more information about Netdom.exe, see Active Directory support tools.

You can enable or disable SID filter quarantining only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filter quarantining in the trusted domain by using the domain administrator’s credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the command-line syntax.

Notes

To further secure your forest, you should consider enabling SID filter quarantining on all existing external trusts that were created by domain controllers running Windows 2000 Service Pack 3 (or earlier). You can do this by using Netdom.exe to enable SID filtering on existing external trusts, or by recreating these external trusts from a domain controller running Windows Server 2003 or Windows 2000 Service Pack 4 (or later).

You cannot turn off the default behavior that enables SID filter quarantining for newly created external trusts.

External trusts created from domain controllers running Windows 2000 Service Pack 3 (or earlier) do not enforce SID filter quarantining by default.

Domain controllers running Windows NT Server 4.0 do not take part in the trust creation process when existing domain controllers in the same domain are running Windows 2000 or Windows Server 2003.

You can enable or disable SID filter quarantining only for trusts that extend beyond forest boundaries such as external and forest trusts. For more information about SID filtering and forest trusts, see Forest trusts.

Allowing SID history to traverse forest trusts
If you are migrating users from one domain to another in different forests, you may want to allow the migrated users to access resources in their original forest by using their migrated (SID history) credentials. The default SID filtering that is applied to forest trusts prevents user-resource-access requests from traversing the trusts with the credentials of the original domain. If you want to make it possible for users to use the credentials that were migrated from their original domain, you can allow SID history to traverse forest trusts by using the netdom command.

Only domain administrators or enterprise administrators can modify SID filtering settings. To allow SID history credentials to traverse a trust relationship between two forests, type a command using the following syntax at a command prompt, and then press ENTER:

Netdom trust TrustingDomainName /domain: TrustedDomainName /enablesidhistory:Yes /usero:domainadministratorAcct/passwordo:domainadminpwd

To re-enable the default SID filtering setting across forest trusts, set the /enablesidhistory: command-line option to No. For more information about Netdom, see “Domain and Forest Trust Tools and Settings.”

****************************************

What are domain and forest trusts? (pasted from MSDN

Most organizations that have more than one domain have a legitimate need for users to access shared resources located in a different domain. Controlling this access requires that users in one domain can also be authenticated and authorized to use resources in another domain. To provide authentication and authorization capabilities between clients and servers in different domains, there must be a trust between the two domains. Trusts are the underlying technology by which secured Active Directory communications occur, and are an integral security component of the Windows Server 2003 network architecture.

When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help provide for controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only validated authentication requests to travel between domains.

How a specific trust passes authentication requests depends on how it is configured; trust relationships can be one-way, providing access from the trusted domain to resources in the trusting domain, or two way, providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case trust exists only between the two trust partner domains, or transitive, in which case trust automatically extends to any other domains that either of the partners trusts.

In some cases, trust relationships are automatically established when domains are created; in other cases, administrators must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts used and the structure of the resulting trust relationships in a given trust implementation depend on such factors as how the Active Directory directory service is organized, and whether different versions of Windows coexist on the network.

Trust Scenarios

It is possible to create a number of different domain and forest trust configurations, depending on the Active Directory structure of the organization. Windows Server 2003 domains and forests can trust other Windows Server 2003 domains and forests, as well as Windows 2000 and Windows NT 4.0 domains. For example, trust configurations vary in nature and complexity in each of the following scenarios:

Trusts within a single Windows 2000 Server or Windows Server 2003 forest

By default, all domain trusts within a single Active Directory forest are two-way, transitive trusts. There are three types of transitive trusts that are used within a single Windows 2000 Server or Windows Server 2003 forest. The first is the tree-root trust, which is created by default when you create a new domain tree by using the Active Directory Installation Wizard. The two-way transitive nature of intra-forest trusts such as the tree-root trust allows all domains in one tree to trust all domains in any other tree within the same forest.

The second type of trust is a parent-child trust. It is created automatically when you create a new domain in an existing domain tree by using the Active Directory Installation Wizard. When a new child domain is created, a parent-child trust is established between the new domain and the domain that immediately precedes it in the namespace hierarchy.

The last type of trust that can be used between trees is a shortcut trust, and is used to speed up access times to resources in a domain that is deep within the tree hierarchy of another domain.

Trusts between two Windows Server 2003 forests

It is possible to extend the transitivity of domain trusts within a single Windows Server 2003 forest to another Windows Server 2003 forest by manually creating a one-way or two-way forest trust. A forest trust is a transitive trust between a forest root domain and a second forest root domain. A one-way forest trust allows all users in one forest to trust all domains in the other forest; a two-way forest trust forms a transitive trust relationship between every domain in both forests. The transitivity of forest trusts is limited to the two forest partners; the forest trust does not extend to additional forests trusted by either of the partners.

Trusts across Windows Server 2003 and Windows 2000 forests

Windows Server 2003 forest trusts cannot be created between a Windows Server 2003 forest and a Windows 2000 forest. You can, however, manually create a trust relationship between any domain in a Windows Server 2003 forest and any domain in a Windows 2000 forest by using one-way or two-way external trusts. External trusts are nontransitive and provide for access to resources in another domain outside the forest that is not already joined by a forest trust.

Trusts between Windows Server 2003 or Windows 2000 domains and Windows NT 4.0 domains

You can manually create a one-way or two-way external trust between Windows Server 2003 or Windows 2000 domains and Windows NT 4.0 domains so that users from either domain can be authenticated to access resources in the other domain.

Trusts between Windows 2000 or Windows Server 2003 domains and non-Windows Kerberos realms

Windows 2000 or Windows Server 2003 domains can be configured to trust non-Windows-brand operating system Kerberos realms, and non-Windows Kerberos realms can be configured to trust Windows Server 2003 domains by manually creating one-way or two-way realm trusts. Realm trusts can also be configured to be either nontransitive or transitive, depending on the level of interoperability you require with UNIX or Massachusetts Institute of Technology implementations of the Kerberos version 5 protocol.

When the direction of a one-way trust is from a non-Windows Kerberos realm to a Windows Server 2003 domain, the user in the Windows Server 2003 domain can access resources in the non-Windows Kerberos realm. When the direction of trust is from a Windows Server 2003 domain to a non-Windows Kerberos realm, users in the non-Windows Kerberos realm can access the resources in the Windows Server 2003 domain.

Technologies Related to Trusts

Trusts depend on the NTLM and Kerberos authentication protocols and on Windows-based authorization and access control mechanisms to help provide a secured communications infrastructure across Active Directory domains and forests. The following diagram illustrates how authentication and authorization technologies relate to trusts and other components of the Windows distributed security model.

Applications and Net Logon
Both applications and the Net Logon service are components of the Windows distributed security channel model. Applications integrated with Windows Server 2003 and Active Directory use authentication protocols to communicate with the Net Logon service so that a secured path can be established over which authentication can occur.

Authentication Protocols
Active Directory domain controllers authenticate users and applications by using one of two protocols: either the Kerberos version 5 authentication protocol or the NTLM authentication protocol. When two Active Directory domains or forests are connected by a trust, authentication requests made using these protocols can be routed to provide access to resources in both forests.

NTLM
The NTLM protocol is the default protocol used for network authentication in the Windows NT 4.0 operating system. For compatibility reasons, it is used by Active Directory domains to process network authentication requests that come from earlier Windows-based clients and servers. Computers running Windows 2000, Windows XP or Windows Server 2003 use NTLM only when authenticating to servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains.

When the NTLM protocol is used between a client and a server, the server must contact a domain authentication service on a domain controller to verify the client credentials. The server authenticates the client by forwarding the client credentials to a domain controller in the client account domain. The authentication protocol of choice for Active Directory authentication requests, when there is a choice, is Kerberos version 5. When the Kerberos protocol is used, the server does not have to contact the domain controller. Instead, the client gets a ticket for a server by requesting one from a domain controller in the server account domain; the server validates the ticket without consulting any other authority.

Kerberos Version 5 Protocol
The Kerberos version 5 protocol is the default authentication protocol used by computers running Windows 2000, Windows XP Professional, or Windows Server 2003. This protocol is specified in RFC 1510 and is fully integrated with Active Directory, server message block (SMB), HTTP, and remote procedure call (RPC), as well as the client and server applications that use these protocols. In Active Directory domains, the Kerberos protocol is used to authenticate logons when any of the following conditions is true:

The user who is logging on uses a security account in an Active Directory domain.

The computer that is being logged on to is a Windows 2000, Windows XP or Windows Server 2003–based computer.

The computer that is being logged on to is joined to an Active Directory domain.

The computer account and the user account are in the same forest.

The computer from which the user is trying to access resources is located in a non-Windows Kerberos realm.

If any computer involved in a transaction does not support the Kerberos version 5 protocol, the NTLM protocol is used.

Authorization and Access Control
Authorization and trust technologies work together to help provide a secured communications infrastructure across Active Directory domains or forests. Authorization determines what level of access a user has to resources in a domain. Trusts facilitate cross-domain authorization of users by providing a path for authenticating users in other domains so their requests to shared resources in those domains can be authorized.

Once an authentication request made to a resource in a trusting domain is validated by the trusted domain, it is passed to the targeted resource computer, which determines, based on its access control configuration, whether to authorize the specific request made by the user, service, or computer in the trusted domain. In this way, trusts provide the mechanism by which validated authentication requests are passed to a trusting domain, while access control mechanisms on the resource computer determine the final level of access granted to the requestor in the trusted domain.

Note

“Access to resources” in any discussion of trust relationships always assumes the limitations of access control.
****************************************

Microsoft NTLM (pasted from MS NTLM

Windows Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows operating system and on stand-alone systems.
The Microsoft Kerberos security package adds greater security than NTLM to systems on a network. Although Microsoft Kerberos is the protocol of choice, NTLM is still supported. NTLM must also be used for logon authentication on stand-alone systems. For more information about Kerberos, see Microsoft Kerberos.
NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user’s password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user’s password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.
Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user’s password is kept. Noninteractive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server.
The following steps present an outline of NTLM noninteractive authentication. The first step provides the user’s NTLM credentials and occurs only as part of the interactive authentication (logon) process.
(Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.
The client sends the user name to the server (in plaintext).
The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
The client encrypts this challenge with the hash of the user’s password and returns the result to the server. This is called the response.
The server sends the following three items to the domain controller:
User name
Challenge sent to the client
Response received from the client
The domain controller uses the user name to retrieve the hash of the user’s password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.
Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

Hash – A fixed-size result obtained by applying a mathematical function (the hashing algorithm) to an arbitrary amount of data. (Also known as “message digest.”)

**********************************************************

Forest Trusts

source: TECHNET

Forest trusts
Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Forest trusts

In a Windows Server 2003 forest, you can link two disjoined Windows Server 2003 forests together to form a one-way or two-way, transitive trust relationships. A two-way, forest trust is used to form a transitive trust relationship between every domain in both forests.

Forest trusts can provide the following benefits:

Simplified management of resources across two Windows Server 2003 forests by reducing the number of external trusts necessary to share resources.

Complete two-way trust relationships with every domain in each forest.

Use of user principal name (UPN) authentication across two forests.

Use of both the Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of authorization data transferred between forests.

Flexibility of administration. Administrative tasks can be unique to each forest.

Forest trusts can only be created between two forests and cannot be implicitly extended to a third forest. This means that if a forest trust is created between forest 1 and forest 2, and a forest trust is also created between forest 2 and forest 3, forest 1 will not have an implicit trust with forest 3. For more information about the requirements needed for a forest trust, see When to create a forest trust.

Notes

In a Windows 2000 forest, if users in one forest need to access resources in another forest, an administrator can create an external trust relationship between the two domains. External trusts can be one-way or two-way and are nontransitive, and therefore, limit the ability for trust paths to extend to other domains. For more information about external trusts, see Trust types.

All trusts in Windows Server 2003 Active Directory use security identifier (SID) filtering to some degree. External trusts are quarantined by default, which prevents any domain SIDs other than those of the quarantined trusted domain from traversing the trust relationship. SID filtering is used to prevent attacks from malicious users who might try to grant elevated user rights to another user account. SID filtering on forest trusts does not prevent migrations to domains within the same forest from using SID history and will not affect your universal group access control strategy. For more information about SID filtering, see When to create an external trust.

Managing a multiple forest environment

Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support for accessing resources and other objects across multiple forests. For more information about accessing resources across multiple forests, see Accessing resources across forests.

Because each forest is administered separately, adding additional forests to your organization increases your organization’s management needs. For more information, see Creating a new forest.

Reasons to create multiple forests in your organization include:

To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it.

To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new domains to a forest only have forest-wide impact within that forest, not on a trusting forest.

Delegating forest-wide administrative control

Active Directory data that is stored in the schema and configuration containers is replicated to every domain controller in the forest. Since changes to the schema and configuration containers will affect all domains in the forest, administrative control for forest-wide changes should be entrusted to highly trained or experienced administrators. All domain data contained in the forest root domain should also be regarded as highly sensitive data.

The following groups provide forest-wide administrative control in each forest:

Enterprise Admins

Domain Admins (in the forest root domain)

Schema Admins

Since membership in any of these groups can affect forest-wide behavior, add users with caution. As a security best practice, avoid adding users from another forest to any of these forest-wide administrative groups. For more information about these groups, see Default groups.

Synchronizing data across forests

You can synchronize global address lists (GALs) and objects across forests using Microsoft Metadirectory Services (MMS) or another supported synchronization tool. Common data types that need synchronization across forests include:

GALs (Exchange)

Public folders

Directory objects

Synchronizing this data across forests will help end users view address lists and other data the same way as they do when viewing this information within their own forest.