0

I'm in a situation where a customer of mine would like 2-factor authentication (e.g. log in and receive e-mail with access URL) according to the following rules:

  1. If the users is on the LAN, do not require 2-level authentication (AD credentials).
  2. If the user isn't on the LAN, require 2-level authentication >> Log in with username/password (can be AD, can be something else, we have created our own SSO solution) and then receive e-mail to a specified mail-adr.

Our main problem is that it is difficult to figure out where the user come from. The reason for this is the ISA server in the front that basically strip away all information about the client. The information received on the ISS where the application is running returns the ISA server address in the CLIENT_IP information.

So - how can we determine where the user come from when all traffic goes through the same ISA server?

One solution has been to create a resource that is only reachable from the LAN and basically say that "If you cannot reach this resource you are de facto not on the LAN". However - this again might have an impact on time-outs - e.g. "try and find the resource but time out after 3 seconds". This might slow down the application AND we might have an issue as several employees are working from other parts of the world where the lines are bad when it comes to accessing the production servers (e.g. people on the LAN accessing the servers over fixed line might experience not reaching the resource, even though they are actually on the LAN).

I've asked this question on stackoverflow as well, but the solution sort of stranded when we learned that the ISA server stripped all information.

(I guess this article summarize the source of my problem: http://www.redline-software.com/eng/support/articles/isaserver/security/x-forwarded-isa-track.php)

Sirex
  • 5,447
  • 2
  • 32
  • 54
sonstabo
  • 31
  • 1
  • 9

1 Answers1

0

We concluded on creating a mechanism that will be issue an encrypted secret to the client when on the LAN. If this secret is unavailable from the client machine he is de facto outside the LAN. We see that it has some holes, but we will focus on a tough encryption and short lifetime to reduce the risks.

sonstabo
  • 31
  • 1
  • 9