ASA direct https network authentication questions

rahmant · ‎05-07-2008

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:

https://<firewall IP>/netaccess/connstatus.html

This access works, but is there any way to have the web auth service run the login prompt from the following URL instead?:

https://<firewall IP>

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.

Thanks,

Tariq

smahbub · ‎05-13-2008

If you want to continue to use basic HTTP authentication, but want to enable direct authentication for HTTP and HTTPS, then enter the following command:

hostname(config)# aaa authentication listener http[s] interface_name [port portnum]

where the "interface_name" argument is the interface on which you want to enable direct authentication.

The "port portnum" argument specifies the port number that the security appliance listens on; the defaults are 80 (HTTP) and 443 (HTTPS).

Enter this command separately for HTTP and for HTTPS.

phaddad · ‎05-20-2009

Don't have any brilliant suggestions for your problem, but thanks you helped me solve a problem I've been having. How did you ever discover the URL for the web auth service? I built something similar with PIX 8.0 and had everything configured correctly but never saw a reference to the URL, so I naively assumed it would just be the https://, which as you point out returns the 404 error. Maybe its in the ASA docs but not the PIX docs?

thanks

phaddad · ‎05-20-2009

One thought that may or may not be useful depending upon your environment. I only have my "aaa authentication match" acl permit https traffic to the firewall itself. I then use radius-based per-user downloaded acls to enable the appropriate network access once user authentication is successful. Downside is that you need to have some sort of radius server. The per-user stuff isn't so bad as you can create a group policy that uses a common acl. So with this config iunauthenticated user traffic is dropped silently until it is authenticated and then it just goes through w/o redirection. Hope this helps.

Peter