ADFS 2012 R2配置O365 IP访问限制遇阻，请求技术支持

Alright, let's break down the common pitfalls and fixes for your ADFS claim rule configuration, since you're trying to restrict Office 365 access to office/VPN IPs with an ActiveSync exception, and having trouble identifying Web Application Proxy (WAP) requests.

First, let's align on the two critical rule sets you need:

1. A rule to identify requests coming through WAP (this is how you distinguish internal vs. external traffic)
2. A combined authorization rule that checks source IP trust + exempts ActiveSync traffic

This is where most folks stumble. Let's ditch the potentially unreliable insidecorporatenetwork claim and use the WAP-specific x-ms-proxy claim instead—it's far more consistent for detecting WAP-forwarded requests.

Replace your existing WAP rule with this PowerShell command (way more reliable than GUI setup): #

Add-AdfsClaimRuleSet -Name "Identify WAP Requests" -ClaimRules '@RuleName = "Mark WAP Requests"
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/requestcontext/claims/x-ms-proxy"]
=> issue(Type = "http://yourdomain.com/claims/iswaprequest", Value = "true");'

Just swap yourdomain.com with your actual domain. This rule will stamp every WAP-originated request with an iswaprequest=true claim.

Now let's tie everything together with targeted rules:

1. Trusted IP Range Identification Rule #

First, create a rule that marks requests from your office/VPN IPs:

Add-AdfsClaimRuleSet -Name "Trusted IP Check" -ClaimRules '@RuleName = "Flag Trusted IPs"
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/requestcontext/claims/x-ms-client-ip"]
&& c1.Value =~ "^(192.168.1.0/24|10.5.0.0/16)$" => issue(Type = "http://yourdomain.com/claims/trustedip", Value = "true");'

Update the IP ranges (192.168.1.0/24|10.5.0.0/16) to match your office and VPN subnets.

2. ActiveSync Exemption Rule #

Next, create a rule to exempt Microsoft ActiveSync traffic:

Add-AdfsClaimRuleSet -Name "ActiveSync Exception" -ClaimRules '@RuleName = "Exempt ActiveSync"
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path"]
&& c1.Value =~ "/Microsoft-Server-ActiveSync$" => issue(Type = "http://yourdomain.com/claims/activesyncexempt", Value = "true");'

This targets the specific endpoint path used by ActiveSync, ensuring those requests bypass IP checks.

3. Final Authorization Rule for Office 365 #

Now replace the default "Allow All" rule for the Office 365 relying party with this conditional permit rule:

Set-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform" -IssuanceAuthorizationRules '@RuleName = "Permit Trusted Access Only"
(c1:[Type == "http://yourdomain.com/claims/trustedip"] && c1.Value == "true")
|| (c2:[Type == "http://yourdomain.com/claims/activesyncexempt"] && c2.Value == "true")
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'

This logic says: Only allow access if the request comes from a trusted IP, OR it's an ActiveSync request.

If you're still seeing issues, here's how to debug:

• Enable verbose ADFS auditing: Set-AdfsProperties -AuditLevel Verbose
• Check the ADFS Admin logs (Event Viewer > Applications and Services Logs > AD FS > Admin) to trace claim flow for each request—you'll see if the WAP/IP/ActiveSync claims are being issued correctly.
• Verify your existing rules don't conflict: Run Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform" to review all current rules for the Office 365 relying party.
• Test edge cases: Try accessing Office 365 from an untrusted IP (should block), test ActiveSync from an external network (should work), and test office/VPN access (should work).

内容的提问来源于stack exchange，提问作者Joe129