Using Constraints and Policy Mapping

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

The method or methods that you use to limit unplanned trust depend in large part on the security challenges that you must address in your organization.

For example, use name constraints to limit unplanned domain-based trusts. If your organization has more than one domain — such as contoso.com and subdomain.contoso.com — you might only want cross-certificates to map to CAs in the contoso.com domain and not to CAs in the subdomain.contoso.com domain. On the other hand, if you have five different domains and want your cross-certificates to apply to three of them, path constraints provide a more flexible solution.

Use path constraints if transitive trusts create problems for your organization — for example, if you have an environment in which users can freely install subordinate CAs and you do not have strong security guidelines governing CA creation and management.

Policy constraints are the most useful of the constraint options, both internally and externally. Name and path constraints might not provide you with sufficient protection in certain cross-certified relationships if the security standards of your business partners are not as strong as yours. For example, organization A might have a policy that all user certificates must be approved manually by an administrator, while organization B approves certificate requests automatically as long as the user has an e-mail account. The security administrators for organization A must ensure that the certificates that users in organization B use to access resources meet the higher security standards that are necessary in organization A. They can accomplish this by using policy constraints.

Use policy mapping if the organization that you are cross-certifying with has policies that are similar to those of your organization. Policy mapping is less useful when the policies of your organization are stricter than the policies of the other organization, or vice versa. If this is the case, use policy constraints to restrict your trust relationship instead of using policy mapping.