How To: Restrict Realm Access by End-Client IP Address in IIS

Version Affected: All

 

Overview

This article explains how to restrict access to a realm by the end client's real IP address, using an IIS URL Rewrite request-blocking rule that checks the X-Forwarded-For or X-MS-Forwarded-Client-IP header instead of the connection's REMOTE_ADDR value — which reflects a load balancer or proxy's IP address rather than the actual client's.

This same kind of restriction can also be configured without editing IIS directly: for Classic realms, using Adaptive Authentication rules; for New Experience realms, using New Experience Policies. The steps below cover the IIS URL Rewrite approach directly.

Restrict Access by End-Client IP Address in IIS

1. In IIS Manager, go to the realm you want to restrict access to (or the top-level site, to apply the restriction globally) and open URL Rewrite. If URL Rewrite is not installed, install it from the official Microsoft IIS website — this requires a reboot.

2. Right-click and select Add Rule(s)....

3. Select Request blocking under Inbound rules, then click OK.

4. Configure the rule: set Block access based on to IP Address, Block request that to Matches the Pattern, enter the pattern to block (for example, 192.168.*.*) using Wildcards, and set How to block to Send an HTTP 403 (Forbidden) Response.

5. Double-click the new rule to edit its condition.

6. Change the condition input from {REMOTE_ADDR} to {HTTP_X_MS_FORWARDED_CLIENT_IP} — or {HTTP_X_FORWARDED_FOR}, depending on which header carries the real client IP in your environment — so the rule evaluates the end client's actual IP address instead of the address IIS sees the connection coming from.

7. Click OK.

No IIS reset is required for the change to take effect.

 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.