Active Directory Domain Services (AD DS) remains the identity backbone for many Windows environments, but classic AD authentication protocols (Kerberos/NTLM) were designed primarily for on-network resources. As soon as you need single sign-on (SSO) to a web application, partner integration, or controlled access from outside the corporate network, you typically need a federation layer that can translate AD identities into modern, web-friendly tokens. Active Directory Federation Services (AD FS) is Microsoft’s on-premises federation service that issues claims-based security tokens for relying party applications.
This article explains how to implement AD FS in a way that is secure, maintainable, and aligned with how AD DS actually operates in production. You’ll start by making the core design decisions (farm type, name, certificates, high availability). From there, you’ll build the farm, add Web Application Proxy (WAP) for external access, configure relying party trusts (SAML 2.0 and WS-Federation), and then harden and validate the deployment. Along the way, you’ll see real-world scenarios that map to common requirements: publishing a third-party SaaS app with SAML, providing SSO to an internal claims-aware app, and enabling external access for a legacy app while enforcing MFA.
What AD FS is (and what it is not)
AD FS is a Security Token Service (STS). An STS authenticates a user (typically against AD DS) and then issues a signed token containing claims. A claim is a statement about the user such as UPN, email address, group membership, or a custom attribute. Applications (called relying parties) trust AD FS to authenticate users and accept those claims in the token.
AD FS does not replace AD DS. It depends on AD DS to validate credentials and to obtain user attributes from the directory. AD FS also does not replace an application’s authorization logic; it provides identity assertions, and the application decides what to do with them.
When AD FS is the right fit, you gain a consistent authentication surface for web applications: users authenticate once (often with Integrated Windows Authentication internally), and the application receives a standards-based token (SAML, WS-Federation, OAuth/OpenID Connect in newer AD FS versions) rather than directly speaking Kerberos/NTLM.
When implementing AD FS makes sense in modern environments
In many organizations, Microsoft Entra ID (Azure AD) is now the primary identity provider for SaaS and cloud apps, with Entra Connect syncing identities. Even so, AD FS still appears in these common cases.
First, you may have strict requirements to keep authentication on-premises, including non-exportable keys in an HSM, offline CA constraints, or policies that disallow cloud-managed authentication.
Second, you might need federation for applications that cannot use modern Entra ID integrations due to network isolation, regulatory constraints, or because the apps only support AD FS-style WS-Federation/SAML patterns and are already wired to AD FS.
Third, you may be in a transition phase: AD FS can bridge legacy applications while you modernize identity, replace apps, or shift to cloud authentication over time.
If your primary goal is secure SSO for web apps using AD DS credentials, implementing AD FS remains a practical and widely deployed pattern.
Core architecture: AD FS farm, WAP, and AD DS dependencies
A production AD FS deployment typically includes:
An AD FS farm, which is one or more AD FS servers sharing configuration and token-signing/decryption certificates. Modern AD FS farms commonly use the Windows Internal Database (WID) for configuration storage when you only need AD FS and not complex multi-datacenter write patterns; SQL Server can be used when you need more advanced scenarios and operational tooling.
Web Application Proxy (WAP) servers, which publish AD FS to the internet and can also publish internal web applications. WAP sits in a perimeter network (DMZ) and proxies authentication requests to AD FS. WAP is not the same as a reverse proxy like NGINX, but functionally it provides secure publishing and pre-authentication for compatible applications.
DNS and certificates, which provide the stable federation service name (FSN) such as fs.contoso.com and the TLS configuration required for secure token issuance. Certificates are central to AD FS security: AD FS uses TLS for transport security and token-signing/decryption certificates to protect the tokens themselves.
Active Directory Domain Services, which provides user authentication and attribute retrieval. AD FS servers must be domain-joined and able to reach domain controllers reliably. In most environments, AD FS uses Kerberos/NTLM to authenticate users (for forms-based or Integrated scenarios) and LDAP queries to retrieve attributes.
Understanding these dependencies helps you avoid the most common operational pitfall: treating AD FS as a standalone web service rather than an identity tier that must be as resilient as your domain controllers.
Planning decisions that determine long-term success
Before installing roles, decide how the service will be named, how it will be made highly available, and how clients will reach it from internal and external networks. These decisions are hard to change later without downtime and reconfiguration of relying parties.
Choose a federation service name (FSN) and DNS strategy
The federation service name is the HTTPS name clients use for sign-in and metadata, for example https://fs.contoso.com/adfs/ls/. This name is embedded in relying party trust configurations and appears in token issuer identifiers.
Use a dedicated DNS name that you can maintain long-term. Avoid tying it to a specific server name. If you have split-brain DNS (internal and external zones), plan whether fs.contoso.com resolves to the internal load balancer VIP internally and to the WAP VIP externally. This is the most common pattern.
Also decide whether you will use the same TLS certificate for AD FS and WAP. In many deployments, the federation service name certificate is installed on all AD FS servers and WAP servers (or at least bound through HTTP.SYS / IIS). The private key must be available on each server that terminates TLS for that name.
Decide on WID vs SQL for the AD FS configuration database
WID is simpler and reliable for many organizations. It supports farms up to multiple nodes and is widely used. SQL Server becomes attractive when you require:
More explicit database management and monitoring.
Specific high availability patterns using SQL Always On or clustering that align with enterprise standards.
Operational requirements to query or back up AD FS configuration in a standardized SQL workflow.
For most small-to-mid and many large deployments, WID is sufficient and reduces moving parts.
Determine the service account and gMSA usage
AD FS runs as a Windows service. In modern Windows Server environments, a group Managed Service Account (gMSA) is recommended because it automatically rotates the password and reduces credential management risk.
If you cannot use gMSA, use a dedicated domain user account with strong controls and a non-expiring password policy aligned with your organization’s identity governance. Avoid using a normal administrator account.
Certificate requirements: TLS vs token-signing/decryption
AD FS uses several certificates:
The SSL/TLS certificate for the federation service name (fs.contoso.com). Clients validate this during HTTPS connections.
Token-signing certificate, used to sign issued tokens so relying parties can verify authenticity.
Token-decrypting certificate, used when relying parties require encrypted tokens.
AD FS can auto-generate token certificates, but in controlled environments you may want to provide your own. Regardless, you must have a valid TLS certificate for the federation service name.
Plan certificate lifetimes and renewal processes. Token-signing certificate rollover is a normal event and can break relying parties if they do not consume federation metadata automatically.
Load balancing and high availability
For production, treat AD FS as a tier with redundancy.
At minimum, deploy two AD FS servers behind an internal load balancer for internal clients.
For external access, deploy two WAP servers behind an external load balancer (or equivalent publishing VIP) and proxy to the internal AD FS VIP.
If you use the same federation service name internally and externally, split DNS and correct load balancing are key. Ensure health checks use an endpoint suitable for AD FS and that the load balancer supports HTTPS pass-through or termination consistent with your certificate plan.
Prerequisites checklist for an AD FS build
This section focuses on prerequisites you can validate before touching the AD FS role installation, reducing the chance of discovering missing PKI or DNS during the build window.
AD DS readiness
Ensure you have a stable AD domain functional level that supports gMSA if you plan to use it. gMSA requires Windows Server 2012 domain functional level and appropriate KDS root key configuration.
Verify domain controllers are reachable from intended AD FS and WAP subnets and that time synchronization is correct. Token issuance relies on time validity windows; significant clock skew causes sign-in failures that can look like certificate issues.
Confirm the UPN and email formats you will use for sign-in. Many organizations want users to sign in with UPN (e.g., user@contoso.com). If your AD DS UPN suffixes are not aligned with your public domain, plan whether to add UPN suffixes in AD Domains and Trusts.
DNS and name resolution
Create the DNS records for the federation service name.
Internal DNS: fs.contoso.com → internal VIP (load balancer) or a specific AD FS server for initial setup.
External DNS: fs.contoso.com → external VIP for WAP.
Plan for certificate validation and CRL/OCSP reachability. Clients (including WAP) may need to access certificate revocation data. If your PKI publishes CRLs internally only, external clients may fail certificate validation unless you publish CRLs appropriately.
Certificates and PKI
Obtain the TLS certificate for the federation service name with:
Subject: CN=fs.contoso.com
SAN: include fs.contoso.com at minimum; add other names only if needed.
Private key exportability depends on your deployment approach. If you need to install the same cert on multiple nodes and don’t have centralized certificate enrollment, you may need an exportable private key or a method to enroll the same cert on each node.
Install the certificate in the Local Computer\Personal store on the AD FS server(s) and WAP server(s) that will terminate TLS.
Network and firewall requirements
At a minimum, ensure:
WAP can reach AD FS over HTTPS (TCP 443).
Clients can reach WAP externally over HTTPS (TCP 443).
AD FS can reach domain controllers (LDAP/LDAPS, Kerberos, DNS) depending on your authentication methods.
If you use certificate authentication, smart card, or device registration, additional ports and endpoints may apply. Keep the initial deployment simple: get username/password and Integrated authentication working first, then layer on advanced methods.
Real-world scenario #1: A mid-size enterprise enabling SAML SSO for a SaaS app
Consider a 2,000-user enterprise with AD DS as the authoritative identity store and a security requirement to keep authentication on-premises. The company is adopting a SaaS application that supports SAML 2.0. The SaaS vendor provides SP (service provider) metadata and expects the organization to provide IdP metadata.
In this scenario, AD FS is used as the SAML Identity Provider (IdP). Users authenticate to AD FS with their AD credentials, and AD FS issues a SAML assertion containing NameID and email claims required by the SaaS app. The organization publishes AD FS externally through WAP so remote employees can access the SaaS app without VPN.
This scenario influences design choices: you need WAP, you need public DNS and a publicly trusted certificate for fs.contoso.com, and you must ensure the token-signing certificate rollover process is compatible with the SaaS vendor (ideally through metadata consumption).
Building the first AD FS server (farm creation)
With prerequisites in place, you can install AD FS and create the farm. The steps below use PowerShell because it is repeatable and auditable.
Install the AD FS role
On your first AD FS server (domain-joined, patched, with the TLS certificate installed):
Install-WindowsFeature ADFS-Federation -IncludeManagementTools
Create or prepare the service account (gMSA recommended)
If you use a gMSA, create it from a management host with RSAT and permissions:
powershell
# Create a KDS root key if your domain does not already have one.
# Only do this once per forest, and note it may take time to replicate.
# Add-KdsRootKey -EffectiveImmediately
New-ADServiceAccount -Name gmsa-adfs -DNSHostName fs.contoso.com -PrincipalsAllowedToRetrieveManagedPassword "CONTOSO\\ADFS-Servers$"
Then, on each AD FS server, install the gMSA:
powershell
Install-ADServiceAccount gmsa-adfs
Test-ADServiceAccount gmsa-adfs
If you use a traditional service account, ensure you know the credentials and that the account is not a domain admin.
Create the AD FS farm
You’ll need the thumbprint of the TLS certificate for fs.contoso.com:
powershell
Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*CN=fs.contoso.com*"} | Select Subject, Thumbprint, NotAfter
Create the farm (example uses WID and a gMSA):
powershell
$certThumb = "ABCD1234EF567890ABCD1234EF567890ABCD1234"
# replace
$fsName = "fs.contoso.com"
Install-AdfsFarm \
-CertificateThumbprint $certThumb \
-FederationServiceName $fsName \
-FederationServiceDisplayName "Contoso Federation" \
-GroupServiceAccountIdentifier "CONTOSO\gmsa-adfs$"
This step creates the AD FS configuration, binds the certificate, and initializes the service. If you’re using SQL instead of WID, the cmdlets differ (you provide SQL connection information).
After the farm is created, confirm the service is listening and metadata is reachable internally:
https://fs.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
You should be able to retrieve metadata from a domain-joined internal machine. If you cannot, do not proceed to WAP yet—fix DNS, certificate trust, or load balancer routing first.
Adding additional AD FS servers to the farm
A single AD FS server is a single point of failure. Once the initial node is stable, add at least one more node.
Install the role on the second server
powershell
Install-WindowsFeature ADFS-Federation -IncludeManagementTools
Ensure the TLS certificate for fs.contoso.com is installed and has the private key.
Join the server to the existing farm
On the additional AD FS server:
powershell
$certThumb = "ABCD1234EF567890ABCD1234EF567890ABCD1234"
# replace
$fsName = "fs.contoso.com"
Add-AdfsFarmNode \
-CertificateThumbprint $certThumb \
-FederationServiceName $fsName \
-GroupServiceAccountIdentifier "CONTOSO\gmsa-adfs$"
After joining, validate that both nodes are functional behind your internal load balancer VIP. At this point, you have internal HA for the federation service.
Publishing AD FS externally with Web Application Proxy (WAP)
If any users or relying parties will access AD FS from outside the corporate network, you should publish AD FS through WAP. WAP terminates external client connections and proxies requests to AD FS. It also enforces pre-authentication for published apps when configured.
WAP placement and trust model
WAP is typically placed in a perimeter network where it can accept inbound HTTPS from the internet. WAP must be able to reach the AD FS federation service over HTTPS. Importantly, WAP must trust the certificate chain used by AD FS.
If you use a publicly trusted TLS certificate on AD FS, WAP will generally trust it by default. If you use an internal CA, you must install the issuing CA certificates on WAP so it can validate the chain.
Install the Remote Access role services for WAP
On each WAP server:
powershell
Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools
Ensure the fs.contoso.com TLS certificate is installed on the WAP server as well (in Local Computer\Personal) with a private key.
Configure WAP to trust AD FS
WAP configuration registers the proxy with AD FS. This requires credentials of an account that has permission to register (typically a domain admin during setup, but you should limit ongoing use).
powershell
$certThumb = "ABCD1234EF567890ABCD1234EF567890ABCD1234"
# replace
Install-WebApplicationProxy \
-FederationServiceName "fs.contoso.com" \
-CertificateThumbprint $certThumb \
-FederationServiceTrustCredential (Get-Credential)
Once installed, publish WAP behind an external load balancer and verify external access to the metadata endpoint through the federation service name.
Because this is an identity service exposed to the internet, ensure you have strong operational controls: patching cadence, logging, and an incident response plan for authentication anomalies.
Real-world scenario #2: Publishing an internal claims-aware app for remote access without VPN
A common driver for AD FS is enabling remote access to an internal web application that supports WS-Federation (for example, a .NET application using Windows Identity Foundation or modern equivalents). The organization wants remote users to access the application without a VPN, but still enforce MFA.
In this scenario, WAP publishes the application externally and uses AD FS pre-authentication. Users hitting the app externally are redirected to AD FS, authenticate, complete MFA, and then WAP forwards the request to the internal app with the appropriate headers/tokens.
This scenario matters because it pushes you to think beyond “AD FS for SaaS” and into “AD FS as a gatekeeper for on-prem apps.” It also affects claim design: the app may need specific group or role claims to authorize features.
Configuring relying party trusts: SAML 2.0 and WS-Federation
Once your federation service is reachable, the next step is configuring relying party trusts (RPTs). An RPT defines a relationship between AD FS and an application: endpoints, identifiers, and rules for how claims are issued.
A good operational principle is to standardize how you onboard apps: require metadata where possible, define a consistent NameID strategy, and document claim rules per application.
Importing relying party metadata
For many SaaS apps, you can import their metadata XML. In AD FS Management, you typically use “Add Relying Party Trust” and select “Import data about the relying party from a file or URL.”
If you prefer PowerShell and have an accessible metadata URL:
powershell
Add-AdfsRelyingPartyTrust \
-Name "Example-SaaS" \
-MetadataUrl "https://saas.example.com/saml/metadata"
Not all vendors provide stable metadata URLs; some provide a downloadable XML. In those cases, use -MetadataFile.
Configuring identifiers and endpoints
SAML relying parties use an Entity ID (identifier) and Assertion Consumer Service (ACS) endpoints. WS-Federation relying parties use a realm identifier and WS-Fed endpoints.
Be precise here. A mismatch between entity IDs, realms, or reply URLs is the most common configuration mistake. When onboarding an app, capture:
The relying party identifier (Entity ID / realm).
The reply URL/ACS URL.
The protocol (SAML vs WS-Fed).
Whether tokens must be signed and/or encrypted.
AD FS will refuse to issue tokens to a relying party when identifiers or endpoints do not match the request.
Issuance transform rules (mapping AD attributes to claims)
Issuance transform rules tell AD FS what claims to include. Many SaaS apps want emailaddress and a NameID based on email or UPN.
A common pattern is:
NameID = user’s UPN or email
emailaddress = AD mail attribute
givenname/sn = AD givenName/surname
In AD FS, you can author rules in the claim rule language. For example, to issue UPN as NameID (SAML persistent vs transient depends on app requirements, but many accept unspecified):
text
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer,
Value = c.Value, ValueType = c.ValueType);
To issue email from the AD mail attribute, you can use a built-in rule template in the GUI (LDAP Attributes). If you need the raw rule language:
text
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"),
query = ";mail;{0}", param = c.Value);
Be cautious: relying on windowsaccountname format can be brittle across domains or when users log in with UPN. Many organizations standardize on UPN-based lookups. If you are multi-domain or multi-forest, plan claim rules and attribute stores accordingly.
Issuance authorization rules (who is allowed)
Transform rules decide “what claims,” but authorization rules decide “who can get a token.” In many environments, you should not allow all domain users to authenticate to every relying party by default.
A common practice is to create an AD security group per application (for example, APP-SaaS-Example-Users) and only issue tokens to members. This reduces blast radius if an app is misconfigured and provides a clear access request workflow.
Real-world scenario #3: Partner federation and claims normalization
A larger organization may need to federate with a partner company for a B2B integration. The partner uses its own IdP and wants to access a Contoso application. You can configure an AD FS claims provider trust (the partner IdP) and then normalize incoming claims to match what your relying party expects.
For example, the partner might send mail but your app expects upn or a specific NameID format. AD FS can transform and map claims so the relying party sees a consistent identity model regardless of the upstream provider.
This scenario emphasizes why claim design matters early. If you standardize around a small set of claims (UPN/email/objectGUID-based identifiers where appropriate), you reduce per-app customization and simplify audits.
Authentication methods and user experience design
Once relying parties exist, the next major set of decisions is how users authenticate. AD FS can support multiple methods, and the choice often differs for internal vs external access.
Integrated Windows Authentication (IWA) for internal users
Internal domain-joined clients can often use Integrated Windows Authentication, which uses Kerberos (preferred) or NTLM to authenticate seamlessly. This provides the “true SSO” experience: users browsing internal apps do not see a login prompt.
IWA requires correct SPNs and DNS resolution and works best when clients can reach AD FS directly (not through complex proxies that break Kerberos). For internal apps, this is usually straightforward if AD FS is behind an internal load balancer and the federation service name resolves appropriately.
Forms-based authentication (FBA) for external users
External users typically use forms-based authentication, where AD FS presents a login page. WAP commonly triggers FBA for external access.
If you have a mixture of internal/external access with the same federation service name, AD FS uses “extranet” and “intranet” classification to choose authentication methods. Ensure your network is correctly recognized; otherwise internal users might unexpectedly see forms prompts.
MFA integration and access control policies
AD FS supports MFA through Azure MFA Server (legacy), third-party MFA adapters, or built-in capabilities depending on AD FS version. The implementation details vary, but the architectural principle is consistent: you define when MFA is required (for example, external access, sensitive relying parties, or privileged users) and enforce it before issuing a token.
When designing MFA, avoid a global “always prompt” posture unless you have a specific requirement; it increases user friction and pushes users to insecure workarounds. Instead, tie MFA to risk factors you can reliably detect in AD FS, such as network location (extranet), group membership, or relying party.
Securing AD FS: hardening priorities that matter
Because AD FS is an authentication boundary, attackers target it. Hardening is not a single setting; it is a set of operational and configuration practices.
Patch management and OS baseline
Keep AD FS and WAP servers on a supported Windows Server version and patch regularly. Many authentication bypasses and TLS vulnerabilities are mitigated through OS and .NET updates. Treat AD FS and WAP like domain controllers in terms of patch urgency.
Apply a security baseline appropriate for your environment. Pay attention to TLS hardening (disabling legacy protocols and weak cipher suites) but validate compatibility with clients and relying parties.
Limit administrative access and protect service accounts
Restrict who can administer AD FS. AD FS administrators can create trusts and claim rules that effectively allow token issuance to unintended parties.
If you use gMSA, you reduce the risk of password theft. Regardless, protect the AD FS servers with:
Privileged Access Workstations (PAWs) or admin jump hosts.
Just Enough Administration (JEA) where feasible.
Auditing of changes to AD FS configuration.
Token-signing certificate rollover management
AD FS periodically rolls token-signing certificates (auto rollover can be enabled). Relying parties that consume federation metadata automatically will pick up new signing keys; those that pin a certificate manually may break.
Operationally, you should inventory relying parties and confirm which consume metadata. For those that do not, plan a manual update process tied to the AD FS certificate lifecycle.
Logging and monitoring
Enable and centralize AD FS and WAP logs. AD FS has event logs under Applications and Services Logs (AD FS/Admin). WAP logs also provide insight into external authentication flow.
At minimum, monitor:
Authentication failure spikes.
Changes to relying party trusts and claim rules.
Certificate expiration dates (TLS and token certificates).
Service health and latency.
While the exact monitoring stack varies (SCOM, Splunk, Sentinel, etc.), the goal is consistent: detect identity service degradation before users call the help desk.
Validating the deployment end-to-end (internal and external)
After configuring the farm and at least one relying party, validate flows systematically. Work from foundational endpoints outward.
Validate federation metadata availability
From internal and external networks (as appropriate), retrieve:
https://fs.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
You want consistent TLS behavior and no certificate chain errors.
From PowerShell:
powershell
Invoke-WebRequest -Uri "https://fs.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml" -UseBasicParsing
If this fails externally but works internally, focus on WAP publishing, external DNS, and the external load balancer.
Validate IdP-initiated and SP-initiated flows where applicable
Some SAML apps support IdP-initiated sign-in (starting at AD FS and then selecting the app). Many security teams prefer SP-initiated flows because they are explicit and reduce the chance of open redirect mistakes.
Test the flow your application will actually use. Confirm that:
The user can authenticate.
The relying party receives the correct NameID and required claims.
Sign-out behavior is acceptable (not all protocols provide perfect single logout).
Validate MFA and access policies without locking out administrators
When enabling MFA, stage changes carefully. Start with a pilot group and a single relying party, especially for external access. Ensure you have break-glass administrative access paths documented (for example, console access to servers, emergency group exemptions), but keep them controlled.
Operational practices: onboarding apps and managing change
Once AD FS is live, most of the work becomes operational: onboarding new apps, rotating certificates, and handling outages or dependency changes.
Standardize onboarding: metadata, claims, and authorization
A strong practice is to create an onboarding template:
Always request SP metadata and confirm protocol.
Standardize NameID (UPN or email) unless the app requires immutable identifiers.
Use an app-specific AD group for authorization.
Document claim rules and keep them minimal.
This reduces “special snowflake” configurations that become unmanageable after dozens of relying parties.
Manage certificates as a lifecycle, not an event
Track:
TLS certificate expiration for fs.contoso.com (affects every user).
Token-signing certificate rollover schedule.
Token-decryption certificates used by specific apps.
Where possible, automate renewal via AD CS autoenrollment for the TLS certificate, but validate that private keys and bindings are updated consistently across farm nodes and WAP.
Plan for dependency outages
AD FS depends on:
AD DS (authentication and attributes)
DNS
PKI/CRL reachability
Load balancers and network
In practice, many “AD FS outages” are DNS or certificate revocation outages. When planning maintenance windows, consider these upstream services.
Practical implementation example: onboarding a SAML SaaS relying party
To make the configuration workflow tangible, here is a typical pattern an administrator might follow when adding a SAML SaaS app.
First, confirm the SaaS app’s requirements: NameID format, required attributes, and whether it supports metadata consumption.
Second, add the relying party trust using metadata. If metadata is not available, configure identifiers and endpoints manually.
Third, create an AD group APP-SaaSName-Users and restrict issuance authorization to that group.
Fourth, add issuance transform rules: issue NameID from UPN, issue email and display name claims.
Finally, export IdP metadata for the SaaS provider (or provide them the AD FS metadata URL). Ensure they import it so token-signing rollover works.
While exact steps vary per vendor, keeping the workflow consistent prevents drift.
Practical implementation example: publishing an internal app with WAP pre-auth
When publishing an internal app through WAP with AD FS pre-authentication, treat it as both an identity and application publishing project.
You need to confirm the app supports pre-auth (typically through AD FS relying party integration) and that the internal app URL is reachable from WAP.
In many environments, administrators publish:
An external URL (public DNS) that users browse.
An internal URL (private DNS) where WAP connects.
A relying party identifier (realm) that the app uses.
Then they enforce MFA for external access and restrict authorized users to an AD group.
The key is that WAP becomes the external entry point, and AD FS becomes the pre-auth authority. This combination gives you internet exposure with a controlled authentication flow.
Practical implementation example: claims design for role-based access
Many applications use claims for authorization (for example, role claims). If you simply dump AD group memberships into tokens, you can hit token bloat issues and leak internal group names.
A better pattern is to issue a small number of role claims derived from membership in a small set of application-specific groups.
For example, you might have:
APP-ERP-Users → role User
APP-ERP-Admins → role Admin
AD FS can transform these into clean role claims that the app understands without exposing raw AD group DNs.
This approach is easier to audit and reduces token size.
Decommissioning considerations and coexistence planning
Even if you are implementing AD FS today, many organizations want an eventual path to reduce on-prem identity footprint. Build with clean boundaries:
Use standard protocols (SAML/OIDC) where possible so the app isn’t hard-wired to AD FS specifics.
Prefer metadata-driven trust where possible so keys roll cleanly.
Document claim mappings so they can be reproduced in another IdP later.
These practices make future migrations (to Entra ID or another IdP) far less disruptive.
Command reference: useful PowerShell for visibility (selective)
The AD FS PowerShell module can help you inventory configuration without relying solely on the GUI.
List relying party trusts:
powershell
Get-AdfsRelyingPartyTrust | Select Name, Identifier, Enabled
View a relying party’s endpoints:
powershell
(Get-AdfsRelyingPartyTrust -Name "Example-SaaS").WSFedEndpoint
(Get-AdfsRelyingPartyTrust -Name "Example-SaaS").SamlEndpoints
Check farm information:
powershell
Get-AdfsProperties | Select FederationServiceName, HostName, AutoCertificateRollover
These queries are especially helpful when you need to confirm what is actually configured during audits or change reviews.