AD trust register


An AD trust register should be a controlled inventory of every trust relationship in your environment, with enough detail to answer **what exists, why it exists, who owns it, and when it was last validated**. At minimum, it should capture the trust’s type, direction, transitivity, source and target domains/forests, and security settings such as selective authentication or SID filtering where applicable [1][2].


## Recommended columns


A practical trust register usually includes these fields:


| Field | Purpose |

|---|---|

| Trust ID | Unique identifier for tracking and audit references. |

| Trust name / target | The other domain or forest in the trust. |

| Source domain / forest | Your side of the relationship. |

| Trust type | Domain, forest, external, realm, etc. [3][1] |

| Direction | One-way incoming, one-way outgoing, or two-way [3][2] |

| Transitivity | Transitive or non-transitive [3][1] |

| Authentication model | Selective authentication or forest-wide authentication [1] |

| SID filtering | Enabled/disabled, where relevant [1] |

| Purpose / business justification | Why the trust exists. |

| Owner | Business or technical owner responsible for it. |

| Approval reference | Change ticket, risk approval, or architecture sign-off. |

| Creation date | When the trust was established. |

| Last review date | When it was last validated. |

| Review frequency | For example, quarterly or annually. |

| Status | Active, pending, deprecated, or scheduled for removal. |

| Notes / constraints | Special routing, name suffix routing, firewall dependencies, or exceptions. |


## Example layout


A simple register row might look like this:


| Trust ID | Source | Target | Type | Direction | Transitive | Auth model | SID filtering | Owner | Purpose | Status | Last review |

|---|---|---|---|---|---|---|---|---|---|---|---|

| TR-001 | corp.local | partner.com | Forest | Two-way | Yes | Selective auth | Enabled | IAM Team | Partner app access | Active | 2026-04-01 |


## What auditors usually want


From a security and audit perspective, the important part is not just the existence of the trust, but whether the trust is intentionally configured and periodically reviewed. Microsoft documents that trusts can be created and managed with tools like Active Directory Domains and Trusts, `netdom`, and `nltest`, and trust properties such as direction, transitivity, and selective authentication are key characteristics to record [4][1]. A good register also makes it easy to identify stale trusts, undocumented partner access, and trusts that may be broader than needed.


## Good practice


Keep the register under change control and tie each entry to a technical validation step, such as confirming the trust in AD, reviewing authentication scope, and checking whether the trust still matches the business need. For environments with multiple forests or external partners, include an expiry or re-certification date so the trust is reapproved periodically rather than assumed valid forever [4][2].



Comments

Post a Comment

Popular posts from this blog

Risk categorization on ad trust

 what would be defined as high risk in terms of trust A trust should be treated as **high risk** when it meaningfully increases the chance of lateral movement, privilege escalation, or cross-boundary compromise, especially if it extends access between forests or to sensitive production environments.[1][2] In practical audit terms, high risk usually means the trust weakens the security boundary, is difficult to monitor tightly, or depends on legacy settings and exceptions that expand exposure.[3][4] ## High-risk indicators A trust is typically high risk if any of the following apply:[1][5][6] - It is a **forest trust** or crosses a strong security boundary, because that expands the reachable attack surface.[1][2] - It allows broad authentication rather than **selective authentication**, meaning users from the trusted side can authenticate to many systems by default.[5][6] - **SID filtering** is disabled, weakened, or temporarily turned off for migration purposes.[4][7] - The trusted...
Read more

Ad control catalog

  # Active Directory Security Framework Detailed Control Catalog ## Purpose This document is an expanded draft of the Active Directory security framework with individual controls listed under each control domain so the framework can be used as the basis for an auditable control register, control testing workbook, or management review package.[1][2][3] The control statements are designed to be tailored to the organization’s actual implementation status and evidence sources while retaining mapping to recognized standards and vendor guidance.[1][2][4] ## How to use this catalog Each control should be assigned a unique internal control ID, owner, implementation status, review frequency, and evidence source during the next draft iteration.[3][2] The standards mapping shown here is intended as a practical starting point rather than a legal or certification opinion, and it should be validated against the organization’s chosen compliance framework.[3][5] ## Standards basis This draft uses ...
Read more