1. The B2B Federation Scenario

In mergers, acquisitions, or long‑term partnerships, you often need to share an application (e.g., a SharePoint project portal or an engineering document system) with users from another organisation. You don’t want to create accounts for them in your AD, reset passwords, or manage their lifecycles. Instead, you want them to use their own corporate credentials.

ADFS makes this possible through Federation Trusts. We’ll simulate a partner company (partner.lab) with its own domain and ADFS. Then we’ll configure a trust so that users from partner.lab can access a claims‑aware application hosted in our organisation (corp.lab) – without any VPN or account duplication.

2. Lab Setup – Two Forests, Two ADFS Farms

We’ll extend our existing lab with a second mini‑infrastructure:

• PDC01 – Domain controller for partner.lab (new forest), with DNS and CA.
• PADFS01 – ADFS server for partner.lab (federation service name: sts.partner.lab).
• SHAREAPP – A sample claims‑aware web application hosted in corp.lab (we can reuse the Exchange OWA app or create a separate IIS site). For this lab, we’ll use a simple IIS website at https://portal.corp.lab that accepts federated users.
• Our existing corp.lab ADFS farm (ADFS01, sts.corp.lab) will act as the Resource Partner (the one hosting the app). The partner.lab ADFS will be the Account Partner (the one authenticating users).

Both sides need network connectivity, and name resolution for each other’s federation service names. Use conditional forwarders or HOSTS files.

3. Step 1 – Build the Partner Lab Environment

Create PDC01 and promote it to a new forest partner.lab. Install an Enterprise CA (same process as in Part 3). Create a gMSA for the partner ADFS service.

On PADFS01, join the partner.lab domain, install the ADFS role, request a certificate for sts.partner.lab, and configure the federation service. Test the partner ADFS IdP‑initiated sign‑on page to ensure it’s working.

4. Step 2 – Configure the Resource Side (corp.lab)

We need to tell our ADFS farm to trust the partner’s identity provider. This is done by adding a Claims Provider Trust in the AD FS Management console on ADFS01.

1. Open AD FS Management → Claims Provider Trusts → Add Claims Provider Trust.
2. Select Import data about the claims provider from online URL and enter the partner’s federation metadata URL:
   https://sts.partner.lab/federationmetadata/2007-06/federationmetadata.xml.
3. If the URL isn’t reachable (lab network isolation), you can manually enter the partner’s federation service identifier (usually http://sts.partner.lab/adfs/services/trust) and import the token‑signing certificate manually.
4. Complete the wizard. A claim rule set will be created automatically; we’ll modify it later.

Now our ADFS knows how to validate tokens issued by the partner.

4.1 Modify the Relying Party Trust for the Shared Application

Assume we already have a relying party trust for https://portal.corp.lab (or we create one now). In its properties, under the Issuance Authorization Rules, we must add a rule to permit users from the partner identity provider. By default, only authenticated users from our own AD are allowed. Add:

# Rule: Permit users from Partner
@RuleName = "Allow Partner Users"
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"] 
 || exists([Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"])
 && c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value =~ "^Partner*"]
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

In practice, you’d use a claim like the identity provider claim or a group claim. We’ll keep it simple: allow any user whose Name ID comes from the partner trust. We can also explicitly allow all users from that provider by adding an issuance authorization rule that checks the http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork claim and the issuer.

5. Step 3 – Configure the Account Partner Side (partner.lab)

On the partner ADFS server (PADFS01), we need to add a Relying Party Trust that points to our application. Even though the app is hosted on corp.lab, the partner ADFS issues tokens that the resource ADFS will accept. The relying party identifier must match the one used in the resource side’s trust (e.g., https://portal.corp.lab).

1. Add a new relying party trust: Claims aware, manual data entry.
2. Display name: Corp Portal.
3. WS‑Federation Passive protocol URL: https://portal.corp.lab/ (the endpoint where the resource ADFS will redirect the token).
4. Relying party trust identifier: https://portal.corp.lab.
5. No encryption certificate needed.
6. Add claim rules to send the user’s UPN, email, and Name ID. We’ll also send a claim that indicates the user is from the partner domain (optional but useful for authorization).

The critical claim is Name ID (UPN) and optionally Group or Role claims that the resource application can use for access control.

6. Step 4 – The Home Realm Discovery (HRD) Experience

When a partner user tries to access https://portal.corp.lab, the resource ADFS does not know immediately whether the user belongs to corp.lab or partner.lab. It presents a Home Realm Discovery page – a list of trusted identity providers. The user selects “Partner Corp” (or whatever display name we gave the claims provider trust) and is redirected to sts.partner.lab for authentication.

We can customise this HRD page, or even automate it by examining the user’s email domain suffix. In our lab, we’ll keep it visible.

7. Step 5 – Test the End‑to‑End Flow

1. On a client machine that can resolve both portal.corp.lab and sts.partner.lab, browse to https://portal.corp.lab.
2. You are redirected to sts.corp.lab (our resource ADFS), which shows the HRD page.
3. Select the partner identity provider. The browser is redirected to sts.partner.lab.
4. Sign in as a user from the partner domain (e.g., partner\testuser).
5. The partner ADFS issues a SAML token and redirects back to the resource ADFS (sts.corp.lab).
6. The resource ADFS validates the token, applies its claim rules, and posts a new token to portal.corp.lab.
7. The application receives the claims and grants access – welcome, partner user!

8. How the Trust Works

The magic lies in federation trust chaining. The resource ADFS acts as a “federation gateway” – it trusts the partner ADFS and can transform and pass through claims. The partner ADFS issues a token with the user’s identity and attributes. The resource ADFS receives that token, verifies its signature using the partner’s token‑signing certificate (which it imported during the claims provider trust setup), and then processes it through its own claim rules to produce the final claims for the application.

This means the application only trusts the resource ADFS; it never has to know about the partner ADFS. The resource side can also restrict which partner users get access using the issuance authorization rules we configured.

9. Troubleshooting Common Pitfalls

• HRD page doesn’t show the partner provider? – Check that the claims provider trust is enabled and the partner’s metadata was imported successfully. Also, verify the relying party trust is configured to “Permit all users” or has the correct authorization rules.
• “An error occurred” after selecting partner? – Often a name resolution issue: the client must be able to resolve sts.partner.lab. Use HOSTS files if needed.
• Token validation fails (MSIS7042)? – The token‑signing certificate on the resource side may not match. Re‑import the partner’s metadata or manually import the correct certificate.
• Partner user gets access denied on the app? – Inspect the claims arriving at the app. The resource ADFS might be missing a transform rule to pass through the UPN. Adjust claim rules on the resource side for the relying party trust.

10. Next Steps 🚀

Now you can confidently design and deploy cross‑organisation federation. But what happens when your ADFS version is old and you need to upgrade while users are still working? That’s where a well‑planned migration comes in.

👉 Part 8 – Upgrading & Migrating ADFS
We’ll walk through upgrading ADFS 2016/2019 to ADFS 2022, migrating the configuration database from WID to SQL, and performing a side‑by‑side cutover with zero downtime.