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: The English version of this fix should have the following file attributes or later:

   Date         Time   Version        Size     File name
   -----------------------------------------------------------------
   08-Oct-2001  19:13  5.0.2195.4472  123,664  Adsldp.dll
   08-Oct-2001  19:13  5.0.2195.4308  130,832  Adsldpc.dll
   08-Oct-2001  19:13  5.0.2195.4016   62,736  Adsmsext.dll
   08-Oct-2001  19:13  5.0.2195.4384  364,816  Advapi32.dll
   08-Oct-2001  19:13  5.0.2195.4141  133,904  Dnsapi.dll
   08-Oct-2001  19:13  5.0.2195.4379   91,408  Dnsrslvr.dll
   08-Oct-2001  19:19  5.0.2195.4411  529,168  Instlsa5.dll
   08-Oct-2001  19:13  5.0.2195.4437  145,680  Kdcsvc.dll
   04-Oct-2001  21:00  5.0.2195.4471  199,440  Kerberos.dll
   04-Sep-2001  09:32  5.0.2195.4276   71,024  Ksecdd.sys
   27-Sep-2001  15:58  5.0.2195.4411  511,248  Lsasrv.dll    128-bit
   06-Sep-2001  18:31  5.0.2195.4301  507,152  Lsasrv.dll     56-bit
   06-Sep-2001  18:31  5.0.2195.4301   33,552  Lsass.exe
   27-Sep-2001  15:59  5.0.2195.4285  114,448  Msv1_0.dll
   08-Oct-2001  19:14  5.0.2195.4153  312,080  Netapi32.dll
   08-Oct-2001  19:13  5.0.2195.4357  370,448  Netlogon.dll
   08-Oct-2001  19:13  5.0.2195.4464  912,656  Ntdsa.dll
   08-Oct-2001  19:13  5.0.2195.4433  387,856  Samsrv.dll
   08-Oct-2001  19:13  5.0.2195.4117  111,376  Scecli.dll
   08-Oct-2001  19:13  5.0.2195.4476  299,792  Scesrv.dll
   29-May-2001  07:41  5.0.2195.3649    5,632  Sp2res.dll
   08-Oct-2001  19:13  5.0.2195.4025   50,960  W32time.dll
   01-Aug-2001  21:44  5.0.2195.4025   56,592  W32tm.exe
   08-Oct-2001  19:13  5.0.2195.4433  125,712  Wldap32.dll
				

NOTE: Because of file dependencies, this hotfix requires Microsoft Windows 2000 Service Pack 2.

Microsoft has confirmed that this problem may cause a degree of security vulnerability in Microsoft Windows 2000.

For more information on this vulnerability, see the following Microsoft Web site:

Configuring SID Filtering

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): The related command to disable SID filtering is: To verify the SID filtering settings on a domain, use this command: 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: 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: