Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner

Getting basic auth prompt before apm logon page event

kimhenriksen
Cirrostratus
Cirrostratus

Hi

 

I´ve setup a basic login policy.

Check if client subnet is RFC1918, if yes do ntlm auth, if not go to logon page and do MFA login.

 

But.. when i access the VIP external i get a basic auth login prompt before the logon page, any tips on where to look?

 

/Kim

1 ACCEPTED SOLUTION

kimhenriksen
Cirrostratus
Cirrostratus

A quick update.

Latest rule is not correct, pasted the wrong one from the clipboard.

 

Here the latest.

when HTTP_REQUEST { 

 if { [IP::addr [IP::client_addr] equals "10.0.0.0/8"] or [IP::addr [IP::client_addr] equals "192.168.0.0/16"] or [IP::addr [IP::client_addr] equals "172.16.0.0/12"] } { 

  if { [ACCESS::session data get session.ntlm.last.result] eq 1 } {

    ECA::disable

  } else {

  ECA::enable

  ECA::select select_ntlm:/Common/ntlm_profile

  #log local0. "eca enabled"

 }

 } else {

  ECA::disable

  #log local0. "RFC1918 ECA disable"

 }

}

 

 

 

View solution in original post

7 REPLIES 7

Hi Kim

 

First guess - is there an upstream device that might do a NAT and the BIG-IP doesn't see the real client IP address?

 

There is a old question here, that offers a solution with iRule and XFF headers:

F5 APM - How to do IP Subnet match for IPs in header

 

KR

kimhenriksen
Cirrostratus
Cirrostratus

Did a tcpdump and i see the public ip. And i have a http xff profile added.

But I am guessing that the ECA profile applied to the VIP, which i guess will be run first.. I´ll try and add a public ip check in the irule before eca enable.

Did you actually check the APM Access Reports for this? This should, given the right log settings are applied, already give you a clue why you get a basic auth prompt instead of the MFA login.

I´ve just checked the default log. But I am applying a new ECA irule, which disables ECA for RFC1918.

As I havent seen anything in the standard reports. So i guess this happens before APM kicks in.

Can you share the config / iRule(s) you are using?

 

Usually, when something seems off with iRules, I try to add logging and take a look at this reference:

iRule Event Order Flowchart

It shows iRules HTTP and ACCESS event order.

when HTTP_REQUEST {

if { [ACCESS::session data get session.ntlm.last.result] eq 1 } {

ECA::disable

} else {

ECA::enable

ECA::select select_ntlm:/Common/ntlm_config

}

}

 

This the one used now, but want to try and change it to this instead.

 

when HTTP_REQUEST { 

 if { [IP::addr [IP::client_addr] equals 10.0.0.0/8] or [IP::addr [IP::client_addr] equals 192.168.0.0/16] or [IP::addr [IP::client_addr] equals 172.16.0.0/12] } { 

  ECA::disable

 }

 elseif { [ACCESS::session data get session.ntlm.last.result] eq 1 } {

  ECA::disable

 } 

 else {

  ECA::enable

  ECA::select select_ntlm:/Common/ntlm_config

 }

}

kimhenriksen
Cirrostratus
Cirrostratus

A quick update.

Latest rule is not correct, pasted the wrong one from the clipboard.

 

Here the latest.

when HTTP_REQUEST { 

 if { [IP::addr [IP::client_addr] equals "10.0.0.0/8"] or [IP::addr [IP::client_addr] equals "192.168.0.0/16"] or [IP::addr [IP::client_addr] equals "172.16.0.0/12"] } { 

  if { [ACCESS::session data get session.ntlm.last.result] eq 1 } {

    ECA::disable

  } else {

  ECA::enable

  ECA::select select_ntlm:/Common/ntlm_profile

  #log local0. "eca enabled"

 }

 } else {

  ECA::disable

  #log local0. "RFC1918 ECA disable"

 }

}