Welcome to Microsoft Q&A,
Thank you for providing the detailed information.
Based on your description, if the custom rule evaluates correctly when tested manually but the expected claim value is not reaching the relying party, the issue is often related to claims pipeline processing, rule execution order, or the distinction between the input claim set and output claim set, rather than the rule syntax itself. Claim rules are processed by the AD FS claims engine as part of the claims pipeline, and each stage receives the output from the previous stage.
The AD FS claims pipeline processes claim in the following order:
- Claims Provider Acceptance Transform Rules
- Authorization Rules
- Relying Party Issuance Transform Rules
- Token issuance to the relying party
Only claims that successfully pass through each stage are available to subsequent stages. A claim generated or transformed at one stage must exist in the output claim set before it can be consumed by later rules.
Key troubleshooting checks
- Verify that the required claim exists in the incoming claim set before the custom rule executes.
- Confirm that an earlier rule is not filtering or transforming the claim unexpectedly.
- Review the rule processing order. AD FS processes rules sequentially, and later rules can only consume claims generated by earlier rules. Also emphasize that all rules within a rule set are processed in order by the claims engine.
- Verify that the relying party trust contains an issuance transform rule that explicitly passes through or transforms the claim type required by the application. Claims are not automatically passed unless a rule issues them.
- Ensure the rule uses
issue()when the claim must be sent downstream. A claim generated withadd()is only added to the input claim set for use by subsequent rules and is not automatically issued to the relying party.
Recommended debugging process
- Confirm that the claim exists after the Claims Provider Acceptance Transform Rules stage.
- Review any Authorization Rules to ensure token issuance is not being restricted.
- Examine each Issuance Transform Rule in sequence and verify that the expected claim is present in the output claim set.
- Enable AD FS auditing and review Event IDs 1000 and 1001, which Microsoft recommends when troubleshooting claims processing.
- Test with a claims-aware application (such as a claims echo application) to validate the actual claims contained in the issued token instead of relying solely on manual rule testing.
For example, if Rule 1 generates a custom claim:
c:[type ==
=> issue(type = "customclaim", value = c.Value);
Then Rule 2 can consume customclaim only if Rule 1 executes successfully and places the claim into the output claim set. If Rule 1 uses add() instead of issue(), or if Rule 2 executes before Rule 1, the claim may not be available for issuance to the relying party.
Reference: The Role of the Claims Pipeline | Microsoft Learn
AD FS Troubleshooting - Claims Rules | Microsoft Learn
The Role of Claim Rules | Microsoft Learn
If you find this answer helpful, please click Accept Answer.
Thank you for using Microsoft Q&A!