Trust Relationships in Access Controls – SSCP Study Guide
Why Trust Relationships Are Important
Trust relationships are a foundational concept in access control and security architecture. They define how entities — whether users, systems, domains, or organizations — interact and share resources securely. Understanding trust relationships is critical for security professionals because misconfigured or overly permissive trusts can expose entire networks and organizations to unauthorized access, lateral movement, and data breaches. For the SSCP exam, trust relationships appear frequently in questions related to access control models, federated identity management, and domain security.
What Are Trust Relationships?
A trust relationship is a formal agreement or configuration between two or more entities that allows one entity to accept and rely upon the authentication or authorization decisions made by another. In essence, when Entity A trusts Entity B, Entity A accepts that Entity B has properly verified the identity and permissions of its users or systems.
Trust relationships can exist at many levels:
- Between Domains: In environments like Microsoft Active Directory, domains can be configured to trust each other, allowing users in one domain to access resources in another.
- Between Organizations: Federated identity management establishes trust between separate organizations so that users authenticated by one organization can access services provided by another.
- Between Systems: Servers, applications, and network devices may trust certain certificate authorities (CAs) or authentication servers to validate credentials.
- Between Users and Systems: Users trust that the systems they interact with are legitimate, and systems trust that user credentials are valid.
Types of Trust Relationships
One-Way Trust: Entity A trusts Entity B, but Entity B does not trust Entity A. Users in Entity B can access resources in Entity A, but not vice versa. Think of it as a one-directional door.
Two-Way Trust (Bidirectional): Both entities trust each other mutually. Users in either entity can access resources in the other, subject to permissions. This is common in Active Directory forest trusts.
Transitive Trust: If Entity A trusts Entity B, and Entity B trusts Entity C, then Entity A also trusts Entity C. Transitive trusts extend the chain of trust through multiple entities. In Active Directory, trusts within a forest are transitive by default.
Non-Transitive Trust: Trust is limited to the two entities involved. If Entity A trusts Entity B, and Entity B trusts Entity C, Entity A does NOT automatically trust Entity C. External trusts in Active Directory are typically non-transitive.
Implicit Trust: Trust that is automatically established, such as parent-child domain trusts in Active Directory.
Explicit Trust: Trust that is manually configured by an administrator, such as a shortcut trust or an external trust between two separate domains.
How Trust Relationships Work
Trust relationships work through the exchange and validation of authentication tokens, tickets, or assertions between the trusting and trusted entities.
1. Authentication at the Source: A user authenticates to their home domain or identity provider (the trusted entity).
2. Token or Ticket Issuance: The home domain issues an authentication token, Kerberos ticket, SAML assertion, or similar credential.
3. Presentation to the Trusting Entity: When the user attempts to access a resource in the trusting domain, the authentication credential is presented.
4. Validation: The trusting domain verifies the credential by checking it against the trust configuration. It confirms that the credential was issued by a trusted source.
5. Authorization: Once the identity is validated, the trusting domain applies its own access control policies to determine what the user is permitted to do.
Key point: Trust establishes authentication acceptance, not authorization. Just because Domain A trusts Domain B does not mean users from Domain B have full access to Domain A's resources. Authorization is still governed by permissions, ACLs, and security policies in the trusting domain.
Trust Relationships in Common Scenarios
Active Directory: Parent-child trusts are automatic and two-way transitive. Forest trusts connect separate AD forests and are two-way transitive. External trusts connect to domains outside the forest and are non-transitive. Realm trusts connect AD to non-Windows Kerberos environments.
Federated Identity: Organizations use protocols like SAML, OAuth, and OpenID Connect to establish trust. An Identity Provider (IdP) authenticates users, and Service Providers (SPs) trust the IdP's assertions. This enables Single Sign-On (SSO) across organizational boundaries.
Certificate Trust: Systems maintain a list of trusted Certificate Authorities (CAs). Any certificate signed by a trusted CA is accepted. This is a form of hierarchical transitive trust — if you trust the root CA, you trust all certificates it has issued, including those from subordinate CAs.
Security Risks of Trust Relationships
- Over-trusting: Granting excessive trust (e.g., making all trusts transitive) can expand the attack surface. An attacker who compromises one trusted domain can potentially access resources across all transitively trusted domains.
- Lateral Movement: Attackers exploit trust relationships to move from a compromised domain to other trusted domains.
- SID History Attacks: In Active Directory, attackers can inject Security Identifiers (SIDs) from a trusted domain to escalate privileges in the trusting domain. SID filtering helps mitigate this risk.
- Stale Trusts: Trust relationships that are no longer needed but remain configured create unnecessary risk.
- Misconfiguration: Incorrectly configured trust direction can expose resources to unintended entities.
Best Practices for Managing Trust Relationships
- Apply the principle of least privilege — only establish trusts that are necessary.
- Use non-transitive trusts when trust should be limited to specific entities.
- Implement SID filtering to prevent SID history-based attacks across trusts.
- Regularly audit trust relationships to identify and remove stale or unnecessary trusts.
- Use selective authentication to control which users from a trusted domain can access resources.
- Monitor authentication logs across trust boundaries for anomalous activity.
Exam Tips: Answering Questions on Trust Relationships
1. Know the direction of trust vs. direction of access: This is a classic exam trap. The direction of trust and the direction of access are opposite. If Domain A trusts Domain B, users in Domain B can access resources in Domain A. Think of it as: the trusting domain opens its door to users from the trusted domain.
2. Understand transitive vs. non-transitive: Exam questions often test whether trust extends beyond two parties. Remember that transitive trust chains through multiple entities, while non-transitive trust is strictly between two parties.
3. Trust ≠ Authorization: A very common exam theme. Trust allows authentication to be accepted across boundaries, but it does NOT grant access to resources. Access is controlled by permissions and ACLs in the trusting domain. If a question asks whether a trusted user automatically has access to resources, the answer is typically no — they still need appropriate permissions.
4. Know the AD trust types: Be familiar with parent-child (automatic, two-way, transitive), forest (two-way, transitive), external (one-way or two-way, non-transitive), and realm (for non-Windows Kerberos) trusts.
5. Federation and SSO: Questions may reference federated trust using SAML or similar protocols. Understand that the Identity Provider (IdP) is the trusted party, and the Service Provider (SP) is the trusting party that relies on the IdP's authentication assertions.
6. Look for keywords in questions: Words like transitive, one-way, two-way, federated, cross-domain, and authentication vs. authorization are strong clues about what the question is testing.
7. Security implications: If a question asks about the risk of trust relationships, think about lateral movement, privilege escalation, over-trusting, and the need for SID filtering and selective authentication.
8. Scenario-based questions: When given a scenario where two organizations need to share resources, the likely answer involves establishing a trust relationship (often federated), not duplicating user accounts. The goal is centralized authentication with distributed authorization.
9. Elimination strategy: If an answer choice suggests that establishing a trust grants full access to all resources, eliminate it. If an answer suggests that a one-way trust allows access in both directions, eliminate it. These are common distractors.
10. Remember the core principle: Trust relationships exist to enable secure collaboration and resource sharing while maintaining each entity's control over its own authorization decisions. This principle will guide you to the correct answer in most trust-related questions.
