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.

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.

Lab topology – Two forests with ADFS and a shared application

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.

Partner ADFS sign‑in page on sts.partner.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.

Import claims provider trust from partner metadata

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. Use PowerShell to add an authorization rule:

# Rule: Permit users from Partner
$rule = '@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");'

Set-AdfsRelyingPartyTrust -TargetName "Corp Portal" -IssuanceAuthorizationRules $rule

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.

Issuance Authorization Rules for the app trust

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).

Partner ADFS – adding RP trust for Corp Portal

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

# On partner ADFS, add transform rules for Corp Portal
$rules = '@RuleName = "Send UPN"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Value = c.Value);

@RuleName = "Send Name ID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/nameidformat"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient");'

Set-AdfsRelyingPartyTrust -TargetName "Corp Portal" -IssuanceTransformRules $rules

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.

Home Realm Discovery page with both providers listed

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!

Portal application showing welcome message with partner user’s claims

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.

• 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.
• Federation metadata not reachable? – Ensure the partner’s ADFS is configured to publish federation metadata (it is by default). Check firewall rules for port 443.

If you need to remove the B2B federation trust, follow these steps on the resource side (corp.lab).

10.1 Remove the Claims Provider Trust

On ADFS01, in PowerShell:

# Remove the partner claims provider trust
Remove-AdfsClaimsProviderTrust -Name "Partner Corp" -Confirm:$false

Replace "Partner Corp" with the display name you used when adding the trust. You can list existing trusts with Get-AdfsClaimsProviderTrust.

10.2 Remove the Partner’s Relying Party Trust (on partner side)

On the partner ADFS (PADFS01), remove the relying party trust:

# Remove the relying party trust for the Corp Portal
Remove-AdfsRelyingPartyTrust -TargetName "Corp Portal" -Confirm:$false

10.3 Remove Authorization Rules from the Local RP Trust

If you added specific authorization rules to allow partner users, you can revert them to default (allow all authenticated users from corp.lab):

# Reset authorization rules to default (allow all authenticated users)
$defaultRule = '@RuleName = "Permit all users"'
Set-AdfsRelyingPartyTrust -TargetName "Corp Portal" -IssuanceAuthorizationRules $defaultRule