Medley of Microsoft articles on Domain and forest trusts, Microsoft NTLM, external trusts and Forest Trusts
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.
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.
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.
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.
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.
“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:
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.”)
Updated: January 21, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
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.
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:
Domain Admins (in the forest root domain)
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:
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.