Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Help needed with inbound VIRTUAL HTTP on PIX

Current problem:

Incoming HTTP requests authenticated at a boundary PIX using RADIUS pass the authentication credentials on to an IIS web server running Outlook web access. The Radius authentication at the PIX uses a one time password,the IIS tries to look this up on the local NT domain & fails.

I'd like to stop the PIX passing the credentials to IIS. In fact I'd like the PIX to authenticate seperately from a different RADIUS server than the IIS. I think that Virtual HTTP will do this but can only find configuration examples for outbound use of this command.

Any help appreciated

Richard

1 REPLY
New Member

Re: Help needed with inbound VIRTUAL HTTP on PIX

First, let me try to explain what the purpose of Virtual HTTP is. The PIX is not passing these credentials to IIS. When a browser requests a web page from a secure site that requires authentication, the web server (IIS) prompts for username and password. The user enters this information on their browser and resends the request now WITH the credentials being passed on. When you place a PIX in the middle to “proxy” this request, The PIX requests the credentials, checks them against the radius server and opens the conduit when allowed. The browser thinks this is the IIS server and so it sends back the request with the credentials the PIX had asked for, the web can’t authenticate these credentials and so it doesn’t serve up the page.

Virtual HTTP eliminates this by authenticating against a dead address (inside in your case). Since this dead address is not listening on http port 80, the browser fails to connect and sends another http get WITHOUT the credentials. Since the user already authenticated on the last attempt, the conduit is open to him so the web server gets this request without interference (no authentication credentials embedded).

So to use this feature make sure you are running on current PIX code. It’s been known to be buggy in early releases. Say you already have a static (inside,outside) 200.1.1.1 192.168.1.1 netmask 255.255.255.255 for your web server. Make another static for this “dead” device you want to authenticate against. Say for example: static (inside,outside) 200.1.1.2 192.168.1.2 netmask 255.255.255.255. Make sure neither address really exists. Add virtual http 200.1.1.2. Now, instruct your users to point their browsers to http://200.1.1.2 and once they’ve successfully authenticated, point their browser to http://200.1.1.1 (Of coarse you can use names and DNS for both of these.)

Look at the examples under the command reference at:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v53/config/commands.htm#xtocid223377

for specifics on the access-lists surrounding these commands and such.

BTW, I’ve never done this inbound, only outbound, but I can’t see why it wouldn’t work. Most users don’t like the two step process of this so you might be better off using a VPN client to get to the local segment and then the user can act normally on the network.

Another option is to just let the user authenticate against the NT database and remove AAA from the PIX. If you do this, you should move the server to a DMZ segment for security.

I’m sure someone else could offer some other workarounds, there are many different ways to get around this.

161
Views
0
Helpful
1
Replies
CreatePlease to create content