AD DS is the core directory service that stores and manages identities, groups, and access relationships inside a Windows domain. AD FS is a claims-based federation service that enables single sign-on and cross-organisation access by trusting identity assertions from another directory. In short, AD DS manages identity locally, while AD FS extends trust across organisational boundaries.
Why AD DS and AD FS Play Different Roles in the Same Identity Stack
AD DS is the authoritative directory for Windows domain identity, so it is where users, groups, computers, and many access relationships are created, stored, and governed. AD FS sits above that foundation as a federation layer, translating trust into claims for single sign-on across organisational boundaries. The practical difference is scope: one governs the local directory, the other extends authentication and trust beyond it.
That distinction matters because the two systems fail in different ways. If AD DS is unhealthy, the enterprise loses the directory record and the access relationships that depend on it. If AD FS is unhealthy, identities may still exist in the directory, but federated sign-in, partner access, and claims-based trust paths can fail or become unavailable.
For teams designing or troubleshooting hybrid identity, it helps to treat AD DS as the system of record and AD FS as a trust broker. That means directory hygiene, group design, and account governance belong primarily to AD DS, while token issuance, relying party trust configuration, certificate handling, and federation policy belong primarily to AD FS. The Identity Federation Failure Modes guide is useful when you need to separate directory problems from claims, signing, or trust issues.
Where Federation Changes the Security Model
AD FS changes the trust boundary rather than replacing the directory. Instead of another application checking AD DS directly, AD FS issues claims that another organisation or cloud service can trust. That is why federation is powerful, but also why it expands the attack surface: the federation layer becomes part of the authentication path and a high-value target for trust abuse, token forgery, and configuration tampering.
In practice, the security model changes in three ways. First, authentication becomes indirect, because relying parties trust assertions rather than querying the source directory themselves. Second, certificates and signing keys become critical security assets because they protect the integrity of issued claims. Third, federation misconfiguration can create broad downstream access, even when the underlying directory remains unchanged. When you need to harden that boundary, NHIMG’s AD FS Security Guide covers the controls that matter most.
That is also why AD FS is not just “another login server.” It is a trust decision point. If an attacker can tamper with federation settings or signing material, they may be able to impersonate users to downstream services without ever changing the AD DS account itself. The Golden SAML and Federation Trust Abuse Defence Guide is the right reference when the question is about trust abuse rather than directory compromise.
How to Think About Ownership, Operations, and Migration
Operationally, AD DS and AD FS should not be managed by the same assumptions. AD DS is typically long-lived, core infrastructure with strong dependency on naming, replication, group policy, and administrative tiering. AD FS is more exposed to change, certificate lifecycle, endpoint publishing, and trust relationship maintenance. If you collapse those responsibilities into one team without clear boundaries, outages and misconfigurations tend to spread across both layers.
For migration and modernisation, the decision is usually not “which one is better?” but “which trust pattern do we want to keep?” Organisations often retain AD DS as the internal identity store while reducing dependence on AD FS by moving selected workloads to cloud identity or newer federation patterns. During that transition, coexistence, cutover sequencing, and rollback planning matter more than product preference. NHIMG’s Identity Platform Migration guide is a useful companion when AD FS is being phased out or reduced in scope.
When the question is resilience rather than architecture, remember that a federated stack can still need fallback paths. If AD FS is unavailable, you may need emergency access, alternate sign-in routes, or a recovery plan for critical business functions. That is a federation concern, not a directory concern alone. The Emergency Identity Operations When the Primary IdP Is Unavailable guide helps teams plan for that failure mode.
Risk and Threat Considerations
AD DS concentrates local identity authority, while AD FS concentrates trust authority. That makes each attractive for different reasons: AD DS for broad directory control and lateral movement opportunities, AD FS for token issuance abuse and federation trust manipulation. The practical risk is not just outage, but the possibility that compromise of the federation layer can extend access across organisations or into cloud services without modifying the source directory.
Failure mechanism: Attackers or misconfigurations can abuse federation trust, signing keys, or claims rules to issue or accept unauthorised identities, while directory compromise can cascade into wider access abuse if privileged groups or sync relationships are exposed.
Impact: The result can be single sign-on abuse, forged assertions, broad cross-domain access, or the loss of confidence in which system is authoritative for identity and access decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | AD FS federates trust beyond the local directory to external users and relying parties. |
| IA-5 — Authenticator Management | AD FS depends on signing keys and certificates that must be managed through their lifecycle. | |
| AC-2 — Account Management | AD DS is the directory system that creates, maintains, and governs enterprise identities and groups. | |
| Recommendation — Apply IA-9 to control federated authentication and the trust relationships that AD FS exposes. Manage federation signing material under IA-5 to protect issuance and rotation of authenticators. Use AC-2 to govern identity lifecycle, group membership, and account changes in AD DS. | ||
Practitioner Guidance
What to verify: Confirm which system is authoritative for a given control point before you troubleshoot or harden it. If the issue is missing users, group membership, or local access relationships, start with AD DS. If the issue is SSO, claims issuance, partner access, or token validation, start with AD FS.
What good looks like: AD DS owns identity lifecycle and access relationships inside the domain, while AD FS only exists where you intentionally need federated trust, with certificates, endpoints, and relying party trusts under explicit operational ownership.
Practitioner takeaway: Treat AD DS as the source of identity truth and AD FS as a separately governed trust layer, because most serious failures come from confusing directory authority with federation authority.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org