Swapping out a CheckPoint firewall for a new set of ASA's, running 8.0(3) and ASDM 6.1(1).
One of the features that I'm trying to replicate with the crossgrade is HTTPS based direct network access authentication (or client auth in CheckPoint-speak)
With the CheckPoint install, the firewall runs a small HTTPS web authentication daemon. The users would navigate to the firewall's web daemon, run through an authentication process and then be unlocked for access to servers/services behind the firewall. Until successful client auth, the servers/services would be unreachable.
With the ASA, I'm using a trigger ACL in combination with the "aaa authentication match" and "aaa authentication listener" commands with moderate success. I can replicate most of the functionality from CheckPoint to the ASA's, but getting that final 5-10% remaining to make the swapout transparent is becoming a pain :)
Couple of questions:
-) Is there any way to get the ASA to trigger web authentication against the root of the ASA web service URL?
The docs state that the web auth service can be accessed via the following URL:
This access works, but is there any way to have the web auth service run the login prompt from the following URL instead?:
When I try to access the firewall's web auth root with direct auth configured for HTTP (not HTTPS), the browser immediately gets a HTTP-404 from the ASA. Using a copy of Fiddler2 linked to my browser, I was able to intercept the auth sessions when I tried to use HTTPS. When navigating to https://<firewall IP>, the browser immediately gets redirections to either:
GET /+webvpn+/index.html HTTP/1.1
GET /+CSCOE+/logon.html?a0=&a1=&a2=&a3= HTTP/1.1
Even though WebVPN is disabled, it looks like the ASA has some WebVPN redirects active. Is there any way to stop those WebVPN redirects and allow the web auth service to run instead?
-) Is there any way to disable the use of HTTP basic authentication? I'd like to force the users to manually navigate and authenticate via the firewall's direct HTTPS authentication page prior to gaining access. This would mean that any attempts to directly access a server/resource requiring authentication behind the firewall should be silently dropped until manual authentication is successful. The redirect feature partially solves this, but I run into problems with the redirect when working with HTTPS remote sites - the redirect screws with the SSL certificate validation + the users get a warning msg in their browser.