So We currently have a farm of about 14 old 6.x webgateways on old hardware and are replacing with 8 new MWG 7.x applainces. However we currently do Transparent proxy. But we have new requirements goign forward to authenticat users. But more than anything they want to just be able to track users and run reports on what they are doing.
We have roughly 40,000 users, over about 10-12 domains and networks that do share one common network pipe out to the internet which is were we place our current webgateways. But placing the new ones here and doign authentication for all 10 networks/domains has become a huge undertaking. Some networks will more controlled than others so explicit proxy works but for most it wont work. but tansparent autnetication using authenication server would be extremely chatty for 40000 users and isn't true autneitcation using a session.
So we had thought about settign up VM or hardware Web Gateways at the local network pipe that feeds into the main network to do just URL filtering, authentiction and tracking of users. Then at a enterprise level having a bank of MWG's to do more enterprise security of AV and Spam and over all blocks if that makes sense? Its kinda distrubuted but runs traffic through MWG's twice. not even sure this woul dbe feasible.
Has anyone else ran into issues were ahving all the wbe gateways centrally located has caused a great deal of issues to do authentication?
Any suggestion, questions or comments would be appreciated.
Solved! Go to Solution.
What issue are you running into with the authentication server? I have written a best practice on authentication server when using a transparent setup: https://community.mcafee.com/docs/DOC-4384
In it, it outlines the redirect URL which needs to be trusted by the users in order to provide credentials (without prompting).
I also go on to talk about "ideal conditions" which can be used for only authenticating under "ideal" conditions. Otherwise the session could expire and the next request after the session is expired will be forced to authenticate. This could be an HTTPS site or a POST request (which could turn out badly).
Moving MWGs the local environment may divide up the load and isolate any authentication problems to a specific environment. You could then relay that traffic upstream to the second pool of MWGs. It's feasible however I'm not sure this is a common deployment practice.
Just saw your reply. Thanks.. I am working on tring ot get Transparent working now, and saw another article about the Try-Auth ruleset.
So I have set up rules sorta like try Auth that will allow authenticated users ( who have trusted the URL) to authenitcate fine.
However I would like for those who doe not authenticate to get a Login page! Not just a prompt but a login page, that way we can make a note that they need to call the helpdesk to get ride or even include a link to show them how to add the site in thier settings.
I got the login page to come up but once credentials ar entered nothing. I can't seem to find any other info on a login page out there.
Is this possible?
Also for the borswer settings, we have 6 gateways will all 6 IP's need to be added? I am assuming yes.
Here are the Autnetication rules i have been playign with. The Try Auth was recommend to me by Erik Elasser from McAfee. When I try it it seems to work. But now I am adding the Login page part.
Issues we have is customer doesn't want to touch the browser at all and make changes and wants prmptless. Because othe rproducts can log the user without checking th ebroswer. Products I wont name but they just grab a log from AD.
So I was hoping try auth could at least grab a user name when faile dbut seems it can't it just allows the user to continue broswer. Hence wanting to make them have a ogin page, that is more official then just a prompt window.
As always I would start with something that works, and then deviate.
To start you should use the "Authentication server with login page" ruleset from the library. After you have gotten that working you can incorporate "try auth".
Attempting to work with "Authentication server time ip based session" and converting it to a login page based ruleset is a bit tougher.
Here is an example, however there is a newer version in the ruleset library:
I was wrong, there is not an Authentication Server w/ Login Page in the library.
Currently working on testing the one from the thread I mentioned.
Attached is an Authentication Server Time IP based session ruleset which uses the login page AND try auth.
When you import it you will need to select the appropriate block page (Login Page POST).
Thanks I will give it a try..
Also Ill check but is there a regular Login page in the rule sets. I may try it on another rule for something. Thanks
I am still having issues with that one you sent. Once I get to the log in page it wont accept credentials, Anythign I should check for that I may be over looking. I did change your rule for my environment.
Also the reaso i was asking about the login page, is I was thinking of doing like you have in another artcile for try auth and make them "restricted user" and have them go through a resrticed use rpolcy, however if they try to venture outside that polciy they get the login page stelling them they are restricted user at that point. If that makes sens..
But I cannot get the curret login page to wokr yet. Still oookign into it myself.