Windowsserverdocs: More than one IP in IpAddress and ForwardedIpAddress

[xXxOlivierxXx]

I have an ADFS farm with 2 ADFS servers and 2 proxies. Both ADFS servers are behind an F5 load balancer VIP, and the 2 proxies are behind another F5 LB vip. The problem I have is that for some reason, both attributes IpAddress and ForwardedIpAddress are showing 2 IP addresses, separated by a comma: One is the true client IP address and the other one appears to be an IP address from one of the F5 VIPs. For some reason, Extranet Smart Lockout is picking up the second IP address, which is the same for every single authentication attempt. Now, I have all of my users showing the same IP address as a FamiliarIP, and all external attackers show the same IP address, which means that ADFS interprets those authentication attempts as Familiar and its provoking tons of Familiar Lockouts. Is this a bug of Extranet Smart Lockout with F5 load balancers?

<Server>N/A</Server>
      <AuthProtocol>N/A</AuthProtocol>
      <NetworkLocation>Extranet</NetworkLocation>
      <IpAddress>183.166.87.159,10.2.2.55</IpAddress>
      <ForwardedIpAddress>183.166.87.159,10.2.2.55</ForwardedIpAddress>
      <ProxyIpAddress>N/A</ProxyIpAddress>
      <NetworkIpAddress>N/A</NetworkIpAddress>

---

The following user account has been locked out due to too many bad password attempts. 
Additional Data 
Activity ID: 00000000-0000-0000-0000-000000000000 
User: 
********** 
Client IP: 
183.166.87.159,10.2.2.55 
nBad Password Count: 
6 
nLast Bad Password Attempt: 
10/31/2018

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d8634165-2ff5-9b01-e3fc-17827360a5f3
• Version Independent ID: a5a91921-3193-93ad-df22-d486e65b19f8
• Content: Configure AD FS Extranet Lockout Protection
• Content Source: WindowsServerDocs/identity/ad-fs/operations/Configure-AD-FS-Extranet-Smart-Lockout-Protection.md
• Product: windows-server-threshold
• GitHub Login: @billmath
• Microsoft Alias: billmath

[eddypuck]

I am seeing similar behavior with an ADFS farm that sits behind a Barracuda Load Balancer. The only different is that sometimes both IP addresses are listed in the Event log as noted above, but in some cases, only the load balanced IP address is logged in the Event logs. The end result is the same, the IP address of the load balancer is what is added to each user's familiar IP attribute. Any idea if there is something that can be configured to prevent this behavior?

[xXxOlivierxXx]

I haven't fixed the problem yet but I believe it does reside in the load balancer. In our case, we use one F5 VIP for external traffic balancing (this is where our WAP servers are balanced) and another for internal balancing (ADFS servers are here). My network guy told me that they have the F5 configured in such a way that the F5 appends the IP of the external load balancer VIP before sending the traffic to the internal load balancer.
According to him, The 2 options available are:
1.Move the servers onto a VLAN that is directly connected to the F5, and make the F5 the default gateway.

1. have the F5 decrypt the traffic if ADFS is actually http traffic, and insert the real client IP into the X-forwarded-for Header.

Both options represent a huge infrastructure change for me so I guess I'll just live with this issue for now.

It would be really cool to have the ability to tell ESL to exclude certain IP addresses through custom powershell commandlets or filters, something like:

`
$data = "183.166.87.159,10.2.2.55"
$data = ($data -replace "", "")
$data = ($data -replace "", "")
$data = -split ","

foreach ($i in $data){
If ( $i -eq "10.2.2.55" ){ this is the IP to exclude, in this case the one for the load balancer
Do nothing
}else{
"If Auth attempt is succesful, add IP into familiarIP"
"If Auth attempt failed and IP is unknown, increase unknown counter"
"etc..."
}
}
`

I was thinking about creating a scheduled task that runs a powershell every 10min that looks for an specific IP into the FamiliarIP list of all users (load balancer IP), and remove that IP from them, however, this doesn't address the issue of ESL not adding the right IP into the database.

[eddypuck]

Thanks for the additional information. Our implementation is exactly the same with the exception of the load balancers being Barracudas. It seems like this would be a very common architecture and basically negates the benefits of the smart lockout feature. with the exception of being able to manually unlock the accounts in ADFS.

[xXxOlivierxXx]

Correct, Microsoft needs to address this, or update the documentation and tell all Load Balancer Users (which is pretty much all ADFS deployments) to stay away from this feature.

[gaspilleur]

Any updates (by Microsoft) on this item? We have upgraded FBL to 3 for new ESL features, but now stopped activation because of this feedback. Our LB is Citrix Netscaler.

[ucblitz]

I discovered this exact same issue while shipping logs into Elastic Stack. I also use the exact same configuration that you do, BIG-IP's and all. Sometimes, there's only one IP, the VIPs, and no public IP. The fact that the ESL feature itself is not matching public addresses only out of the logs seems like a big oversight, but the bigger issue is that there's multiple IP addresses. I'll probably open a ticket with both F5 and Microsoft to see if I can't get this rectified. Until then, I guess I'll just need to either let the malicious actors beat up our ADFS or continue with the arduous process of blocking them at the F5 by geoip.

[rcookdps]

Did anyone manage to resolve the issue? I'm using Microsoft's Azure Application Gateway (WAF) and have a similar issue. A successful sign in gets two familiarIPs (internal & public) but a failed signin then reports as BadPwdCountUnkown and UnknownLockout = True when I hit the limit.

[rjrenga]

Did anyone manage to resolve the issue?

I get the Same issue, We have 3 ADFS Server and 3 ADFS Proxy server ,

With external and internal LB using the netscaller SSL_Bridge load balancing solution,

Not enabled the ESL since it is shows the netscaller IP as a familiar IP instead of client IP.

My network guys said the SSL_Bridge will not forward the client IP and need the below changes .

1.Move the servers onto a VLAN that is directly connected to the netscaller, and make the netscaller the default gateway.

1. have the netscaller decrypt the traffic if ADFS is actually http traffic, and insert the real client IP into the X-forwarded-for Header.

Both options represent a huge infrastructure change for me

Please let me know any update on this.

[SB-o-matic]

Did any one manage to resolve this. Makes ESL pointless if attackers can be let through because LB address is getting imprinted.
MSFT? F5? Netscaler? Anyone? Sigh

[ucblitz]

Did any one manage to resolve this. Makes ESL pointless if attackers can be let through because LB address is getting imprinted.
MSFT? F5? Netscaler? Anyone? Sigh

After a long and arduous MS ticket, it was explained that the internals of ESL will still pick out and block the non-private address if enforcement is enabled. This didn't help me very much with parsing the events...but the primary blocking mechanism still behaves just fine.

As a side-note for anyone securing ADFS - Adding an IP to the banned IP list will not take effect _unless_ ESL is set to Enforce.

[SB-o-matic]

Did any one manage to resolve this. Makes ESL pointless if attackers can be let through because LB address is getting imprinted.
MSFT? F5? Netscaler? Anyone? Sigh

After a long and arduous MS ticket, it was explained that the internals of ESL will still pick out and block the non-private address if enforcement is enabled. This didn't help me very much with parsing the events...but the primary blocking mechanism still behaves just fine.

As a side-note for anyone securing ADFS - Adding an IP to the banned IP list will not take effect _unless_ ESL is set to Enforce.

Wow...just ...wow. I appreciate you @ucblitz.