Version Affected: All
Overview
WS-Trust Request Blocking rules configured for User Agents may not get applied to a specific application, even though the rule appears correctly configured.
Cause
The application sends its agent name in the X-MS-Client-Application header instead of the X-MS-Client-User-Agent header that a User Agent Blocking rule matches against. Enabling debug logging shows an event similar to: Message="[ApplicationAgent].[ValidateApp]: Found header key, X-MS-Client-Application. With value Windows-AzureAD-Authentication-Provider/1.0". Since the application is sending its name in the X-MS-Client-Application header, the WS-Trust Request Blocking rule needs to match it via an Application Blocking rule instead of (or in addition to) a User Agent Blocking rule.
Resolution:
Configure the WS-Trust Request Blocking rule to match on Application Blocking, for example:
Request Blocking Enabled : True
Logic : AND
IP Address Blocking - Allow : *
Application Blocking - Allow : Windows-AzureAD-Authentication-Provider/1.0
User Agent Blocking - Allow : *This configuration blocks all applications from using WS-Trust except Windows-AzureAD-Authentication-Provider/1.0, from any IP address and with any User Agent.
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.
Comments
Please sign in to leave a comment.