Issue to use ADFS Extranet Smart Lockout with non-claims-aware application
Based on my tests, ADFS does not register the original client IP, if the client logs on to a non-claims-aware application published by the Web Application Proxy.
In this case, the AD FS Auditing event ID 1200 shows only the WAP server’s IP:
<Component xsi:type=”RequestAuditComponent”>
<Server>http://<adfs server fqdn>/adfs/services/trust</Server>
<AuthProtocol>MSISActive</AuthProtocol>
<NetworkLocation>Extranet</NetworkLocation>
<IpAddress>10.9.40.84</IpAddress>
<ForwardedIpAddress />
<ProxyIpAddress>N/A</ProxyIpAddress>
<NetworkIpAddress>N/A</NetworkIpAddress>
<ProxyServer>WAP</ProxyServer>
<UserAgentString>N/A</UserAgentString>
<Endpoint>/adfs/proxy/relyingpartytoken</Endpoint>
</Component>
If a client from the same IP logs on to a claims aware way published application the IpAddress and ForwardedIpAddress fields are containing the original client IP and the load balancer’s IP sitting before the WAP:
<Component xsi:type=”RequestAuditComponent”>
<Server>http://<adfs server fqdn>/adfs/services/trust</Server>
<AuthProtocol>WSFederation</AuthProtocol>
<NetworkLocation>Extranet</NetworkLocation>
<IpAddress>93.33.65.135,10.9.40.40</IpAddress>
<ForwardedIpAddress>93.33.65.135,10.9.40.40</ForwardedIpAddress>
<ProxyIpAddress>N/A</ProxyIpAddress>
<NetworkIpAddress>N/A</NetworkIpAddress>
<ProxyServer>ORFK-WAP02</ProxyServer>
<UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0</UserAgentString>
<Endpoint>/adfs/ls/</Endpoint>
</Component>
Consequently, after a successful logon to this non-claims-aware application the WAP IP will be registered as a FamiliarIp in ADFS, and any further logon attempt will be counted as a familiar authentication even if it’s coming from an attackers IP, since the original client IP remains hided for the ADFS ESL service.
Maybe I misconfigured something, or should it be by design?
Any idea would be appreciated.
Best Regards, Mike
Based on my tests, ADFS does not register the original client IP, if the client logs on to a non-claims-aware application published by the Web Application Proxy.In this case, the AD FS Auditing event ID 1200 shows only the WAP server’s IP: <Component xsi:type=”RequestAuditComponent”> <Server>http://<adfs server fqdn>/adfs/services/trust</Server> <AuthProtocol>MSISActive</AuthProtocol> <NetworkLocation>Extranet</NetworkLocation> <IpAddress>10.9.40.84</IpAddress> <ForwardedIpAddress /> <ProxyIpAddress>N/A</ProxyIpAddress> <NetworkIpAddress>N/A</NetworkIpAddress> <ProxyServer>WAP</ProxyServer> <UserAgentString>N/A</UserAgentString> <Endpoint>/adfs/proxy/relyingpartytoken</Endpoint> </Component>If a client from the same IP logs on to a claims aware way published application the IpAddress and ForwardedIpAddress fields are containing the original client IP and the load balancer’s IP sitting before the WAP: <Component xsi:type=”RequestAuditComponent”> <Server>http://<adfs server fqdn>/adfs/services/trust</Server> <AuthProtocol>WSFederation</AuthProtocol> <NetworkLocation>Extranet</NetworkLocation> <IpAddress>93.33.65.135,10.9.40.40</IpAddress> <ForwardedIpAddress>93.33.65.135,10.9.40.40</ForwardedIpAddress> <ProxyIpAddress>N/A</ProxyIpAddress> <NetworkIpAddress>N/A</NetworkIpAddress> <ProxyServer>ORFK-WAP02</ProxyServer> <UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0</UserAgentString> <Endpoint>/adfs/ls/</Endpoint> </Component>Consequently, after a successful logon to this non-claims-aware application the WAP IP will be registered as a FamiliarIp in ADFS, and any further logon attempt will be counted as a familiar authentication even if it’s coming from an attackers IP, since the original client IP remains hided for the ADFS ESL service.Maybe I misconfigured something, or should it be by design?Any idea would be appreciated.Best Regards, Mike Read More
