How to inventory and export AD FS relying party trusts

What you can export from AD FS, and what you must rebuild

AD FS trust configuration can be inventoried and exported in part, but claim rules, certificates, usage history and application-side settings need manual collection. Start by treating the farm as an unknown: you may not know how many relying party trusts exist, which ones are live, or which ones were set up by someone who has since left. Your renewal or Windows Server lifecycle decision sets the deadline, so the inventory should be finished before anyone commits to a target platform. The export path covers the trust definitions themselves: the relying party identifiers, the protocol each trust uses, and the endpoints and metadata the farm holds for it. Microsoft's own AD FS documentation describes the readiness and reporting tools and the configuration export options, but this page does not name specific commands or reports because they were not confirmed against that documentation for this guide. Confirm the current tooling on Microsoft Learn for your farm version before you script anything.

The gaps are where most migration plans fail. Issuance transform and authorization claim rules, token signing and encryption certificates, the usage history that shows whether a trust still gets traffic, and the settings held on each application (redirect URIs, logout endpoints, SAML attribute consumer details, and what the app expects in its own config file) usually sit outside a single export. Collect these per trust, with an owner and a business contact for each application. The output should be one register with a row per relying party: protocol, identifiers, claim rules written out in plain language, certificate expiry dates, observed sign-in activity over a period you agree with the application owners, and a disposition of migrate, retire or keep on another platform. That register is the input to the migration plan and to the separate pages on re-creating clients and mapping claims.

Which AD FS data can be exported, and in what form

This table lists each AD FS data type to inventory, the export method for it and the output format and limits to expect. Treat the format column as a prompt to test, because output shape varies by cmdlet, console view and script version. The main takeaway is that a script or console export captures configuration, while owners, business purpose and real dependencies must be recorded separately.

Data type	Export method	Output format and limits
Relying party trust list	Get-AdfsRelyingPartyTrust in the AD FS Management Shell, or the Relying Party Trusts node in the AD FS console	Object output on screen. File format depends on how you save it. Confirm in a lab export.
Protocol and endpoints	Protocol, endpoint and identifier properties from Get-AdfsRelyingPartyTrust or the trust Properties dialog	Property values as text. Check that WS-Federation, SAML and OIDC settings each appear in the output.
Issuance transform rules	Rule text from the trust's issuance transform rules, through PowerShell or copied from the rule editor	Claim rule text. Copy the text manually as a backup, and confirm the export keeps line breaks and rule order.
Issuance authorization rules	Authorization rules from the same trust, using the same PowerShell or console method	Rule text. Note which trusts permit all users and which restrict access by group or claim.
Token signing and encryption certificates	Get-AdfsCertificate for status, thumbprints and expiry. Private key export only as PFX under your key policy	Certificate status as text. PFX files require a password and a secure store. Confirm expiry dates in your environment.
Claims provider trusts	Get-AdfsClaimsProviderTrust or the Claims Provider Trusts node in the AD FS console	Object output as text. Confirm which fields, including metadata URLs, appear in your export.
Usage and activity	Microsoft's migration readiness script and AD FS audit event logs for relying party sign-ins	Script output and event log records. Check the time window and log retention on each federation and proxy server.
Owners and business purpose	Manual record kept by the application owners and the identity team	Spreadsheet or ticket. Exports do not record owners, so completeness depends on the people you ask.

What does not export cleanly and how teams work around it

The AD FS configuration export gives you a readable inventory, but several parts of a federation estate never arrive as a file you can import. Treat each gap below as a separate work item in the migration plan, with a named owner and a check that proves it is closed.

Token signing private keys

The token signing and token decryption certificates on the AD FS farm are the trust anchors that relying parties rely on to verify tokens. Exports carry the public certificate and thumbprint, but the private key stays in the server's certificate store and is marked non-exportable on many farms. The new provider generates its own signing keys, so every relying party must be re-pointed to new metadata. Record the certificate thumbprints and expiry dates in the inventory, then confirm with each application owner when their trust must switch.

Claim rules written as free text

Issuance transform and authorization rules are stored as claim rule language, but many were written by hand over years and carry comments only in the change ticket. An export shows the rule text, not why a rule exists or which application depends on it. For each relying party, map every rule to its purpose, then translate it into a Keycloak mapper or equivalent and test the resulting token claims against the rule output. Keep the old rule text beside the new mapping as evidence.

Application-side configuration

Each relying party also depends on settings that live in the application, not in AD FS: registered redirect URIs, session lifetimes, logout endpoints, and how SharePoint or header-based apps read the claims they receive. A trust record shows none of this. Ask each application owner for a written list of the claim names, URIs and session timeouts the app expects, then run a test sign-in in staging before cutover. Header-based apps often need an explicit check that the user identifier format has not changed.

Web Application Proxy publishing rules

Web Application Proxy publishes internal applications and AD FS endpoints to remote users through its own publishing rules, pre-authentication settings and certificates. These rules are kept on the proxy servers and are not part of the federation service configuration you export. Document each published hostname, path, authentication mode and backend target in a manual record. Check which entries also depend on the load balancer and on Kerberos constrained delegation, since those dependencies will not move with the rules.

Sign-in history beyond retention

Usage reports from AD FS show sign-ins only within the event log and audit retention you have configured, so older activity may already be gone. Without that history, a relying party that is used once a year can look unused and be removed by mistake. Before you decommission a trust, confirm the retention period on each AD FS server and export what remains to long-term storage. Where history is short, ask application owners to confirm business use and schedule a review before any trust is retired.

Why the trust inventory has to come before any export

The relying party trust inventory decides the scope, cost and order of an AD FS migration, so it has to be finished before anyone exports a configuration file or builds a client in a new identity provider. Every trust carries a protocol, a set of claim rules, certificates, endpoints and an owner, and each of those attributes changes the work. A SAML service provider with a simple name ID rule is a small task. A WS-Federation trust feeding a line-of-business application with custom claim transforms may need a different target product or a rebuild. Counting trusts tells you little until you know which ones are used, which ones are not, and which ones have someone accountable for them. Trusts fall into three groups that call for different decisions. Trusts in active use show sign-in events in AD FS audit and the migration activity report, and they must move with a tested cutover. Trusts used rarely, such as an annual regulatory filing or a quarterly finance close, look idle in a 30-day window, so you must confirm their usage over a longer period with the business before retiring anything. Trusts nobody owns are the hardest: they usually have no contact, an expired certificate or an endpoint that no longer resolves. Treat each of them as a risk to resolve, not as a candidate to delete silently.

The inventory feeds one decision per relying party: move it to the new identity provider, retire it, or re-architect it because its protocol or claim logic will not translate directly. Record for each trust the protocol, the claim rules in plain language, the signing and encryption certificates, the consuming application, the data it receives and the business process it supports. Then sort the list. Retire trusts with no sign-ins and a confirmed owner decision. Move standard SAML and OpenID Connect clients through a repeatable pattern. Flag WS-Federation and custom claim rule cases for a separate design review. The owner of each application must confirm its own record. Usage logs show that a trust was used, not what it needs, and a claim rule written years ago may be the only documentation of an attribute the application depends on. Ask each owner to validate the endpoints, the required claims, the sign-out behavior and the cutover window in writing. Keep that sign-off with the inventory, because it is the evidence auditors and change boards will ask for when a trust is removed.

The sequence for a complete AD FS trust export

This sequence turns scattered AD FS configuration into a signed-off inventory of every relying party trust, with its protocol, claims, certificates, real usage and a named owner. The result is the input a migration plan for Keycloak, authentik or WSO2 Identity Server can be built from.

Take a read-only copy of the farm configuration
The AD FS administrator exports the farm configuration and records the token-signing and token-decrypting certificate thumbprints, the service account, and the Web Application Proxy servers that sit in front of the farm. Store the copy in a location that the migration team can read but not change, and keep a dated record of who took it. The step is complete when the team can open the configuration export without an AD FS console session and can see the same farm name and server list that the management console shows.
Run the migration readiness check and collect usage reports
Run Microsoft's AD FS migration readiness script on the primary federation server and save its output alongside the configuration copy. Then pull the AD FS usage data that Microsoft documents for relying party activity, so each trust shows whether it has signed in recently rather than only whether it exists. Confirm the readiness output lists the same number of relying party trusts shown in the AD FS management console under Relying Party Trusts. Any difference should be resolved before the next step, because a trust missing from the script output is a trust missing from the plan.
Export trust settings from a test copy first
Export the relying party trust settings with PowerShell from a test federation server or a restored copy of the configuration, not from production. Check that the export file opens in a text editor or spreadsheet and contains the expected fields for each trust: identifier, protocol, endpoints, signing and encryption settings, and the access control policy name. Then repeat the export on production and compare the two files. The step is done when the production export contains the same trust count as the management console and the test export matches it field for field.
Record claim rules and certificate expiry dates
For each trust, record the issuance transform rules and the acceptance rules, the claim types sent to the application, and any custom attribute stores involved. Note the certificate expiry date for every signing and encryption certificate that the trust uses, and flag any that expire before the planned cutover. Mark which rules are simple attribute pass-throughs and which contain regular expressions, conditional logic or group lookups, since those will need manual translation into mappers. To verify, pick one trust, sign in to the application as a test user and confirm that the claims in the token match what the recorded rules say it should send.
Assign an owner to every trust
Assign one named business or technical owner to each relying party trust, and record who approves changes to it. Where usage data shows a trust has not been used recently, the owner decides whether it is retired, moved or kept, and that decision goes in the inventory with the date. Confirm that no trust in the inventory has an empty owner field and that the owners have confirmed their entries. Trusts without an owner usually surface later as broken sign-ins during cutover, so this step should not be skipped for applications that appear to be unused.
Sign off the inventory before planning the cutover
Review the completed inventory with the identity lead, the application owners and the security or compliance reviewer, and record their sign-off with the date and the version of the export it refers to. Each trust should now have its protocol, claim summary, certificate dates, usage status and owner on one line. Confirm the sign-off by checking that the trust count in the signed inventory equals the count in the readiness output and the production export. This signed record is the baseline for choosing which trusts move to SAML or OpenID Connect clients and which need a different path.

How each protocol shapes the target plan

SAML relying parties are usually the largest group in an AD FS estate, and they are the most portable. For each one, the inventory should capture the entity ID, the assertion consumer service URLs and bindings, and the metadata source, whether a file, a URL or manual entry. Record the token signing and encryption certificates the relying party trusts, their expiry dates and whether AD FS signs the whole response, the assertion or both. Capture the NameID format and every claim rule that builds the assertion, because those rules become attribute mappers on the new side. Note the single logout endpoints and whether the application expects them to work.

Entity ID and endpoints: Assertion consumer URLs, bindings and the exact entity ID, since a single character change breaks trust.
Signing and encryption certificates: Which keys each relying party trusts, when they expire and who rotates them.
NameID and claim sets: The NameID format and every outgoing claim, mapped back to the directory attribute behind it.
Logout behavior: Whether single logout is configured, tested and relied on by the application.
Metadata drift: Whether the metadata on the application side still matches what AD FS publishes.

Keycloak supports SAML 2.0 alongside OpenID Connect and OAuth 2.0, and authentik and WSO2 Identity Server also offer SAML providers. Confirm with each vendor how the target handles encrypted assertions, signed requests and the specific NameID formats your applications use before you choose a target.

What to plan before the AD FS farm is retired

Inventory results only help if they feed a schedule, a risk list and an evidence trail. The six items below connect the relying party inventory to the dates, certificates, owners, licenses and rollback steps that decide when each trust can move.

Windows Server lifecycle dates

Record the operating system edition, patch level and end of support date for every AD FS farm server and Web Application Proxy server. Farms on older Windows Server releases may hit end of extended support before a replacement is live, which changes the deadline for the whole plan. Confirm each date with Microsoft's lifecycle pages for your exact edition, and note which servers can be upgraded in place and which must be rebuilt.

Token signing and service certificate expiry

List the token signing certificate, the token decryption certificate if used, the SSL certificate on the federation service name and any service communications certificates. Note the expiry date, the issuing authority and which relying parties trust each one by thumbprint or metadata. An expiring token signing certificate can break every SAML and WS-Federation trust at once, so the new identity provider must be ready before that date.

Change windows and owner availability

Map each relying party to a named business owner and a technical contact, then agree a change window for each cutover. Ask owners which months carry month-end, audit or seasonal peaks. Applications that only some users reach, or that run batch jobs, need a test plan that covers those paths, not just a login test.

Windows Server and SQL Server licensing records

Keep proof of Windows Server licenses and client access licenses for the farm and proxy servers, and identify any SQL Server instance the farm uses for its configuration database. Record the license type, the licensing agreement and the renewal date. Licensing records show what the current estate costs to run, which supports the comparison with a self-hosted replacement and the decision on when to stop renewing.

Rollback plan for each relying party

For every trust, write down the steps to return to AD FS if the new provider fails: the DNS or load balancer change to reverse, the metadata or endpoint that must be restored and the test users who confirm access. Keep the AD FS trust active in parallel until the application passes acceptance testing. Rollback steps should be rehearsed on a non-production copy before the cutover date.

Audit retention for exported records

Store the exported trust list, claim rules, certificate inventory and the activity report in a controlled location with a retention period set by your records policy and any applicable regulation. Ask your compliance team and external auditor which evidence they expect to see, how long it must be kept and who may access it. Exports taken before a migration are often the only record of how access worked at that time.

Questions teams ask before exporting AD FS trusts

How much effort does a complete AD FS trust inventory take?

The effort depends on how many relying party trusts exist, how many of them are documented, and how many certificates and claim rules sit behind them. No fixed duration is supplied for this work, so ask for one in a written quote. The main drivers are:

The number of relying party trusts, including disabled or abandoned ones that still appear in the configuration
Applications nobody documented, which need traffic evidence and an owner before they can be classified
The number of token-signing and token-decryption certificates, and any SAML metadata endpoints that expire or change
How quickly application owners respond, since a trust without an owner usually stalls the plan

Can our own team run the AD FS export, and when does outside help make sense?

Yes, a capable identity team can run the export internally, because the core tasks are read-only inspection of AD FS configuration, exporting trust settings, and running Microsoft's migration readiness tooling. Outside help makes more sense when the estate is large, when claim rules are complex or inconsistent, when the team has no spare capacity, or when the result must be reviewed against a compliance program. Confirm the tooling and export steps against Microsoft's current documentation for your AD FS version before you start.

What do application owners and the identity team need to provide?

Application owners confirm what each relying party does, who uses it, which users and claims it needs, and when it can be tested or retired. The identity team provides access to the AD FS servers, the configuration and audit logs, certificate records, and a change window for any test. Agree on a named owner for every trust before the inventory starts, and record the decision for each one in a single register so that unowned applications surface early.

Does DeployOpen offer a fixed-scope engagement for the inventory and export?

DeployOpen plans and implements self-hosted open-source identity platforms, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A trust inventory, export and migration plan can be scoped that way, covering the trust register, protocol and certificate findings, and the export package. DeployOpen does not publish a price list, so ask for a quote based on the written scope, which should list the number of trusts, the systems in scope and the deliverables.

How do we decide whether to move, retire or re-architect each trust?

Decide per trust using evidence of actual use, not the configuration alone. Retire trusts with no sign-in activity over an agreed observation period, move trusts whose protocol and claims map cleanly to SAML or OpenID Connect, and flag for re-architecture the trusts that depend on WS-Federation, Kerberos, header-based access, or custom claim rules that the target platform handles differently. Record the owner's decision and the reason in the register, so the plan can be reviewed later. Confirm the target platform's protocol support before you assign a trust to a move.

How should exported AD FS data that contains personal information be handled?

Treat the export as sensitive. Trust exports and activity reports can include user identifiers, email addresses, group names and claim values that count as personal information, so limit who can read them, store them in an approved location, and set a retention date. Remove or pseudonymize personal data where the analysis does not need it, and check your data protection obligations with your privacy team before sharing the files with a partner. Keep an access log of who opened the exports.

What should a written quote for this work include?

Ask for a quote that lists the scope in concrete terms: the AD FS farms covered, the expected number of relying party trusts, the systems and owners to interview, the certificate review, and the deliverables such as the trust register and migration plan. The quote should also state the assumptions, what the client provides, the acceptance criteria for each deliverable, and any work that falls outside the scope. Ask how each item is priced, and which parts are one-time and which recur if you later want ongoing support.

What the destination platform needs from the export

The inventory you build from AD FS is not a file the new platform can read. Your target configuration is built from it, one relying party at a time. If the target is Keycloak, the platform's own artifact is the realm, which Keycloak exports and imports as JSON with the kc.sh export and kc.sh import commands. That realm file holds clients, roles, authentication flows and identity provider settings, so a realm export from a test instance is useful for checking your own configuration. It is not a substitute for your AD FS inventory, because AD FS trust settings, claim rules and certificates have no direct equivalent in a Keycloak realm file.

Plan around the limits the Keycloak documentation states. The Keycloak import and export guide warns that realm export has limitations as a backup and restore mechanism, so keep your own backup routine for the running environment. It also requires that all nodes be stopped while the export runs. Schedule that downtime in a non-production environment first, and confirm with your own platform team how it fits a clustered production deployment before any cutover date is set.

Treat the AD FS export as a separate working artifact. Each relying party trust, its claim issuance rules, signing certificates and endpoints must be mapped by hand to a Keycloak client, its protocol mappers and its certificate settings. Record the mapping in the migration plan with one owner per application, and mark any trust that uses a protocol Keycloak does not serve, such as WS-Federation, as a separate decision. Confirm each mapping against the application owner's test results, not against the AD FS configuration alone.

What to confirm with Microsoft and your own environment first

Do not treat the inventory tooling as settled until you have confirmed it against Microsoft's current documentation for your farm. The exact names and current versions of Microsoft's migration readiness script and activity report change over time, so record the name, version and publication date of each tool you use, and check them against Microsoft's AD FS documentation on Microsoft Learn before you run anything in production. The same applies to the export cmdlets for relying party trust settings. Confirm which AD FS PowerShell commands are available on the Windows Server version your farm runs, what each one writes out, and whether it captures claim rules, issuance transform rules, signing and encryption certificates and endpoint configuration in full. Do not assume an export from one server version is complete on another.

Confirm two more things with Microsoft and your own security and records teams. First, the retention period of AD FS activity logs on your farm and on any central log platform that receives them. Usage evidence is only as good as the window it covers, and a short window can hide a relying party that is used only at month end or during an annual process. Second, the supported target configuration for each relying party type. Whether a SAML service provider, an OpenID Connect client, a WS-Federation application or a Web Application Proxy published app can be re-created on your chosen identity provider depends on the product and version you select, so verify that in the vendor documentation for that product rather than in this inventory.

The only reliable way to confirm the output is a test export in a lab copy of the farm. Restore a recent configuration backup to isolated hardware or a non-production farm, run the readiness script, the activity report and the trust export there, then compare the results against the production farm trust by trust. Check that the claim rules, certificates and endpoints in the export match what production actually issues, and record every difference as an open item. Use the lab output as the basis for your migration plan, and repeat the test whenever the farm changes during the project.

How DeployOpen scopes and delivers an AD FS trust inventory and export

DeployOpen plans and delivers the inventory and export of AD FS relying party trusts inside your own infrastructure, as a written, fixed-scope engagement. The output is a documented trust register and migration plan that your team can review before any relying party moves to a new identity provider.

How we scope

Agree in writing which AD FS farms, proxy servers and relying party trusts fall inside the inventory.
Confirm which trust data sources you can provide, such as farm exports, usage reports and certificate stores.
Define the deliverables, timeline and sign-off points before any work starts, with a quote following from that scope.

How we build

Run Microsoft's migration readiness script and activity report against the farm to capture protocol, claim rules and usage.
Export trust settings and certificate details, then reconcile them against application owners and change records.
Classify each relying party by protocol and by dependency, flagging WS-Federation and Kerberos-dependent applications for separate review.

How we hand over

Deliver a relying party register listing owners, protocols, claim rules, certificates and observed sign-in activity.
Provide a migration plan that sequences each relying party against the target identity provider and its open decisions.
Walk your identity, security and application teams through the register so they can confirm or correct each entry.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the inventory is complete.
Keep the register current as relying parties are added, retired or re-certified during the migration.
Prepare the controls and evidence your compliance assessors may ask for, while independent auditors issue any assessment.