Microsoft Windows NT and Windows 2000 protect system resources with access control lists (ACLs). ACLs are lists of security identifiers (SIDs) and lists of access rights or permissions that are granted to that security principal. SIDs are relative to a domain. The SID of a user or group from a domain is always based on the SID of the domain, and uniquely identifies the user or group. ACLs are placed on a resource to indicate which users and groups are permitted to access the resource, and what level of access the users and groups are allowed. When a user attempts to access the resource, Windows compares the list of SIDs in the ACL to the list of SIDs that identify the user and his or her group memberships, and grants or denies access as appropriate.
When a user logs on to a domain, the user's account SID and group membership SIDs are determined by a domain controller in the user's account domain. The SID of the trusted domain, the relative ID (RID) of the user's account, the RID of the user's primary group, and the SIDs of all other group memberships are combined into an authorization data structure and passed to the requesting computer. If the authenticating domain controller is running Windows 2000, it also checks to determine if the user has any SIDs in his or her SIDHistory attribute and includes those SIDs in the authorization data.
If the computer that is requesting user authentication is in a different domain from the user's account, authentication occurs by using a trust. Trust is created between Windows NT-based or Windows 2000-based domains to simplify the user's authentication experience--especially by enabling single sign-on. When one domain trusts another, it means that the trusting domain allows the trusted domain to authenticate the users (or computers) whose accounts it manages. During authentication, the computer in the trusting domain accepts the authorization data that is provided by the trusted domain controller. There is no way for the computer that is requesting authentication to determine the validity of the authorization information, so it accepts the data as accurate based on the existence of the trust relationship.
A vulnerability exists because the trusting domain does not verify that the trusted domain is actually authoritative for all the SIDs in the authorization data. If one of the SIDs in the list identifies a user or security group that is not in the trusted domain, the trusting domain accepts the information and uses it for subsequent access control decisions. If an attacker were to insert SIDs into the authorization data at the trusted domain, he or she could elevate his or her privileges to those that are associated with any user or group, including the Domain Administrators group for the trusting domain. This would enable the attacker to gain full Domain Administrator access on computers in the trusting domain.
Exploiting this vulnerability would be a challenge. At a minimum, an attacker would need administrative privileges on the trusted domain, and the technical wherewithal to modify low-level operating system functions and data structures. Windows 2000 provides a mechanism for introducing additional SIDs into authorization data, known as SIDHistory. However, there is no programming interface that would allow an attacker--even with administrative rights--to introduce a SID into the SIDHistory information; instead, an attacker would need to perform a binary edit of the data structures that hold the SIDHistory information. To counter these potential attacks, Microsoft has added a feature called SID filtering to Windows NT 4.0 and Windows 2000. With SID filtering, an administrator can cause the domain controllers in a given domain to "quarantine" a trusted domain. This would cause the domain controllers in the trusting domain to remove all SIDs that are not relative to the trusted domain from any authorization data that is received from that domain. Quarantining is performed from the trusting domain, and is done on a per-domain basis.
SID filtering blocks Windows 2000 transitive trust. If a quarantined domain is located in the trust path between two domains, users from domains on the other side of the quarantined domain cannot access resources in the quarantining domain. For this reason, quarantined domains should be leaf domains, their child domains should be only resource domains that contain no user accounts, or the quarantined domain should be in a separate forest.
A Windows 2000 administrator should not use the SID filtering feature to create a "restricted-access" domain within a forest. The recommended quarantine scenario is to quarantine only domains in separate forests. A trust should be established from the domain that is to be protected to the domain that is to be quarantined, and then the trusting domain should be configured to filter the SIDs from the trusted domain.
Microsoft recommends that you do not use this SID filtering between domains in the same forest because it disrupts the default trust and authentication behavior of a forest, including intra-forest replication, and is likely to lead to problems with programs that might be difficult to troubleshoot. This article contains a list programs and functionality that are known to malfunction in SID filtering environments. Do not use restricted access domains and follow the recommendations that are listed above if you need these programs or functionality. Microsoft cannot provide workarounds for these issues.
To resolve this problem, obtain Windows 2000 Security Rollup Package 1 (SRP1). For additional information about SRP1, click the article number below to view the article in the Microsoft Knowledge Base:
311401 Windows 2000 Security Rollup Package 1 (SRP1), January 2002
The English version of this fix should have the following file attributes or later:
You can configure SID filtering with the updated Windows 2000 Service Pack 2 (SP2) version of the Netdom.exe utility on Windows 2000-based domains. For SID filtering to work properly, SP2 must be installed on every domain controller in the trusting domain (the domain that is quarantining another domain). The updated version of Netdom.exe is included in the Support Tools folder on the SP2 CD-ROM, or you can download it from the Microsoft Web site. A /filtersids switch has been added to this version of Netdom.exe to configure SID filtering.
For Windows 2000-based domains, to quarantine a domain, use the following command once on one domain controller in the domain (in this example, the RESDOM domain is filtering the ACCDOM domain):
Typical Active Directory replication causes the setting to be propagated to all domain controllers in the domain.
Authentication and Auditing Changes
Refer to the online Help in Windows 2000 for information about how to configure auditing in Windows 2000.
When a trust is established, the trusting domain creates and stores a data structure called a Trusted Domain object (TDO) that contains the SID of the trusted domain and other information about the trust. When SID filtering is enabled for a trusted domain, authentications to that domain do not succeed if the authorization data presents a domain SID that does not match the SID in the trusting domain's TDO for the quarantined domain. This circumstance can occur only if the authorization data was altered. If authentication does not succeed in this manner and logon or logoff auditing is enabled, an event is generated in the event log on the domain controller that is processing the authentication request in the trusting domain.
SP2 includes a new security audit event with event ID 548 for NTLM authentication, and adds a new failure code (0xC000019B) to event ID 677 during Kerberos authentication. These are logon or logoff failure events that are generated when the domain SID is "spoofed." The following sample entries demonstrate these events.
During NTLM authentication:
Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 548 Date: Event date Time: Event time User: NT AUTHORITY\SYSTEM Computer: Name of the computer where the event is logged Description: Logon Failure. Reason: Domain sid inconsistent User Name: Name of the user being authenticated Domain: Name of the Quarantined Domain Logon Type: 3 Logon Process: NtLmSsp Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Workstation Name: Name of the client computer
During Kerberos authentication:
Event Type: Failure Audit Event Source: Security Event Category: Account Logon Event ID: 677 Date: Event date Time: Event time User: NT AUTHORITY\SYSTEM Computer: Name of the computer where the event is logged Description: Service Ticket Request Failed: User Name: Name of the user being authenticated User Domain: Name of the user's Domain Service Name: Full qualified name of the Quarantined Domain Ticket Options: 0x0 Failure Code: 0xC000019B Client Address: 127.0.0.1 Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 537 Date: Event date Time: Event time User: NT AUTHORITY\SYSTEM Computer: Name of the client computer Description: Logon Failure: Reason: An unexpected error occurred during logon User Name: Name of the user being authenticated Domain: Name of the user's Domain Logon Type: 2 Logon Process: User32 Authentication Package: Negotiate Workstation Name: Name of the client computer
Limitations of SID Filtering
There are three potential drawbacks associated with SID filtering that could potentially prevent some users from gaining access to resources for which they are authorized:
SID filtering and SIDHistory are mutually exclusive mechanisms. If SID filtering is in effect on a domain, it filters any SIDHistory information in incoming authorization data from quarantined domains.
SID filtering can block the single sign-on benefits of transitive trust in Windows 2000. For example, assume that domain A trusts domain B, and domain B trusts domain C. Typically, in Windows 2000, a user from domain C could gain access to resources in domain A because domain A transitively trusts domain C. However, if domain A has SID filtering in effect for domain B, it would no longer allow domain B to vouch for a user from domain C, because domain B is not authoritative for SIDs in domain C.
SID filtering filters SIDs that are associated with a user's membership in universal groups if the groups are not maintained in the user's account domain.
Incompatible Programs and Features
The following programs and Windows 2000 features are known to be incompatible with SID filtering:
Universal group membership for all universal groups that are not in the user's account domain
Microsoft Exchange 2000 features that rely on universal groups
SIDHistory for migrated accounts
Transitive trust does not work properly
Active Directory replication--for this reason in particular, SID filtering should not be used between domains in the same forest. SID filtering should be used only to filter on external trusts.
For additional information about how to obtain a hotfix for Windows 2000 Datacenter Server, click the following article number to view the article in the Microsoft Knowledge Base:
265173 The Datacenter Program and Windows 2000 Datacenter Server product
For additional information about how to install multiple hotfixes with only one reboot, click the following article number to view the article in the Microsoft Knowledge Base:
296861 How to install multiple Windows updates or hotfixes with only one reboot