Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Piercing Security BoundariesThe Ultimate Forest Design Issue

Trusting someone has its risks. There is always the chance that the person will dishonor that trust and do you harm. This is also true of trust relationships between Windows domains and forests. Whenever you pierce a security boundary, you open another avenue of attack. Should an attacker obtain access to one domain, he may be able to more easily penetrate the defenses of the other. You will need to plan for this eventuality. You should also realize that your own trusted administrators might use the new conditions to fraudulently obtain privileges in the trusting domain or forest.

Windows NT 4.0 domains are security boundaries. Administrators in each Windows NT 4.0 domain have no rights in each other's domain. Windows 2000 and Windows Server 2003 domains are not security boundaries. Enterprise admins and schema admins have authority that can impact every domain in the forest. In addition, because of the tight coupling of domains, a rogue administrator could programmatically insert the SIDs of another domain's administrators in her authorization data and thus elevate her privileges in the other domain. A defense against this possibility is to evaluate current and potential administrators for their trustworthiness and to audit every administrator's activities. Alternatively, multiple forests can be used because the forest is a security boundary. The possibility of an attack by rogue admins is not the only reason for multiple forests. Multiple forests also provide administrative autonomy, which may be necessary due to a lack of trust within an organization or different requirements for domain-wide structure (such as password policy or schema). Multiple forests may also be deployed where politics or law requires proof of complete separation of assets.

The possibility of successful elevation of privilege attacks also arises when external trusts and forest trusts are created. Administrators in trusted domains could obtain unauthorized administrative privileges in another domain. To combat this possibility, two additional strategies, SID filtering and selection authentication, can be implemented. It is important to develop a security plan for this action before creating the external or forest trust.

TIP: Resources on Security Boundaries and Forest Design

Three excellent references on security boundaries and forest design issues are "Planning and Implementing Federated Forests in Windows Server 2003" (it even obtains a list of appropriate firewall ports to open for different scenarios involving Windows trusts), available at www.Microsoft.com/technet/prodtechnol/windowsserver2003/maintain/security/fedffin2.asp; "Multiple Forest Considerations," available at www.Microsoft.com/technet/prodtechnol/windowsserver2003/plan/mtfstwp.asp; and "Design Considerations for Delegation of Administration in Active Directory," available at www.Microsoft.com/technet/prodtechnol/ad/windows2000/plan/addeladm.asp.

These countermeasures, if used improperly or misunderstood, may hamper legitimate administrative access. Plans for managing any such issues should be established so that restricted access does not eventually result in the removal of the countermeasures. Keep in mind that although evaluating risk and imposing a security solution is a management decision, your job is to provide the technical advice to make this possible.

SID FilteringCatching SID Spoofs

Authorization for access to objects or to use rights on a system is granted to users, computers, and groups. The operating system determines access by comparing lists of approved SIDs against a list of SIDs belonging to the requesting user or computer. The security of the system, therefore, is based on the assumption that the list of SIDs and privileges assigned to an object or right is correct, and that a user's or computer's lists of authorized SIDs is also correct. Careful administration of objects and rights makes the system more trustworthy.

However, an escalation of privilege attack is possible if an attacker is authorized for some access to the system and is able to programmatically spoof or insert additional unauthorized SIDs into his authorization material. If the attacker knows the SIDs of privileged accounts and uses them, then his ability to manage the system or access its resources is only limited by those rights and privileges granted to the SID he uses. Within a Windows Server 2003 or Windows 2000 forest, there is no defense against this type of attack except the selection and monitoring of trustworthy administrators.

When a trust is established within an external domain or with another forest, these same types of attacks are possible. However, SID filtering can be used to defend against this type of attack. When SID filtering is enabled and a user crosses the trust boundary from the trusted domain into the trusting domain, his authorization list is stripped of any SIDs that belong to the trusting domain. It's as if an authorization firewall exists between the external and local domain or between the forests of the forest trust. SID filtering is turned on by default between forests in a forest trust, and it is recommended for external trusts.

SID filtering does not prevent assignment and use of privileges across domains; the list of these SIDs is added to the user's access token when the user first connects to the resource computer. The only SIDs stripped from her authorization material are those SIDs that are in her authorization material when she authenticates to the trusting domain but before she connects to the resource computer.

SID filtering is not always appropriate. It can negate the use of SID history. When a user from an external domain is migrated to the local domain, SID history is used to maintain her access to resources in the external domain. SID history maintains the list of SIDs assigned to the user in the external domain. These SIDs become part of her authorization material and hence her access token when she is connected to resources. SID filtering will remove the SIDs in SID history from the user's authorization material.

SID filtering can be turned on and off by a member of the Domain Admins group in the trusting domain by using the Windows Server 2003 support tool netdom. Netdom is added to the server when you run the suptools.msi file in the Support Tools folder of the Windows Server 2003 installation CD-ROM.

To enable SID filtering, use the following command:

Netdom filtersidstrusteddomain

To disable SID filtering, use this command:

Netdom filtersidsnotrusteddomain

NOTE: Catch 22?

SID filtering is used in an attempt to prevent escalation of privilege attacks across domain trusts. But SID filtering can be disabled by a member of the Domain Admins group of the trusting domain. A determined attacker with privileges in the trusted domain might convince or coerce a member of the Domain Admins group in the trusting domain to do so. So why apply SID Filtering in the first place? While this scenario could occur, without SID filtering, no manipulation of an administrator or complicity is necessary.

Whenever two people must cooperate to do something untoward, it's less likely for it to happen and much easier to find out about. Making it necessary that two or more people must collaborate is using the separation of duties security principle. However, you should not rely on the prohibiting effect of such action, and you should audit administrative actions.

Selective AuthenticationThe Trust Firewall

In an external or forest trust scenario, users must be authorized to access resources or exercise privileges in the trusting domain. However, when users authenticate to the domain, the Authenticated User's SID is added to their authorization material. Because many privileges of access and rights are granted to holders of this SID, users may have more access than you desire. You cannot change the membership of the Authenticated Users group; however, with Windows Server 2003, as discussed in the section "Creating a Forest Trust," you can limit their ability to authenticate to a specified domain or server.Creating a Forest Trust" section, selective authentication was turned on. An administrator in the nomoore.com domain can use the object picker to grant the noless.com\Accountants group access to resources in his domain. However, until the noless.com\Accountants group is explicitly given the permission Allowed to Authenticate, it cannot access those resources.

If the noless.com\accountants group is given that permission, then when a member of that group authenticates to the nomoore.com domain, their access token is given the "Other Organization SID."

If selective authentication is used, then you must assign the Allowed to Authenticate right to every group that needs it. This could be a large administrative chore if not carefully planned, or if the need to address authentication is dynamicthat is, if frequent changes to access must be undertaken.