Coming from Webwasher / Web Gateway 6, we like what we are seeing in MWG7. But we have to ask why things were made so hard compared to the previous version? Setting simple things like access logs to log the columns you want is tedious. Setting up authentication against a windows domain is quite the experience. While the flexibility has greatly increased, the complexity has increased to the level of absurd.
There needs to be wizards or at least some how-to's and getting started guides published for the basics. We understand the concepts, but executing is like a shot in the dark. We've pulled down the ruleset from the forum and it seems hit or miss at best if we get prompted for credentials, so we've already tried that. I'm betting McAfee saw a rise in consulting engagements with this release.
So if anyone has guidance on best practices (docs, rulesets) for setting up MWG7 as a Proxy & WCCP, with Proxy using NTLM pass through auth and would care to share, we'd be ever so grateful.
I'm new to proxies and this sort of infrastructure altogether (Networking and Security/Firewalls background by trade) but really do quite like this product. I would however have to concur with the wonderfully articulated comments about complexity above. 'Quite the experience' does seem to beautifully sum up the configuration that allows for Windows authentication!
It's a slow learning curve for someone coming at this totally fresh but I feel somewhat relieved by the fact someone with exposure to these devices thinks they are complex. I'm only really scratching the surface as a lot of the initial set-up and intelligence has already been set-up but I am trying to understand it as best I can and am pulling a lot of funny faces as I do!
I have a setup using Proxy & WCCP. I also use NTLM auth with a domain controller.
I can give you some great guidance. I have taught myself how to configure and manage this gateway over the past few months. Have it pretty well down by now.
Will you be using a Cisco ASA to for WCCP?
I know how you feel. I've been responsible for setting up the web gateway in our organisation and I've basically had to use the resources I've come across on this forum along with trial and error.
My main aims were to get it set up as a proxy so we could utilise AD authentication, site filtering based on AD security groups, reporting and web cache. Same as jont717, I've got it setup using NTLM auth with our DC.
I'm sure that I haven't done some things the best way, but have just been doing things like adding sites that are having issues to the Global Whitelist.
A couple problems that I am having trouble sorting out are to do with accessing our Outlook Webmail from internally (works fine externally as it doesn't go through the MGW) and FTP access via Internet Explorer (but I think that is more to do with the way IE handles, or doesn't handle, authentication for FTP).
I'd be keen to hear about other 'best practice' ideas.
Now I also have the challenge of getting Email Gateway setup, and there is even less documentation/setup guides for that.
I am taking the possibility to thank you all for sharing your ideas and thoughts openly and being candid and helpful with the feedback you provide! THANK YOU!
I can assure you that your thoughts and requests have made it to Product Management and that we are reading them with high interest. Please keep on mentioning them, you can also send me this info as PM on this forum.
We have recorded them and will use them as basis for future product decisions.
thanks again for your collaboration and contribution,
@jont717 - At this point an ASA with WCCP would be used. We may move WCCP to our cores (6509s) eventually. I'm really struggling with the auth rules. In MWG6, we had;
We used SSL scanning in the same manor as well. I just need to duplicate that in MWG7 and we are gold.
@michael_schneider - It's great to here you guys are listening. We look forward to any ease of use enhancements that may show up in the product as a result of customer feedback.
JohnMessage was edited by: jspanitz on 4/6/11 11:17:40 AM CDT
You will need two different auth rule sets. One for WCCP and one for Direct proxy. In the ASA, you will need to create a service group (51) and match that in the Gateway for WCCP. In my case, I have two service groups, one fore HTTP traffic and one for HTTPS traffic. I found this to be better for controling the traffic for different subnets/vlans.
You will then want to create different proxy listener ports for each. Onc for WCCP and one for Direct. Ex. 9090 and 9099
Here is a screen shot of my Auth Rules.
Then you want to make them only enabled with certain proxy ports....
This should give you a good starting point.
I wrote the policyViewer to let you copy/paste rule details into emails and forums like this
But to further the discussion, each of those root Authentication tree branches above should have rules like this so they do not proceed down the authentication process and skip over the actual Authentication.Authenticate command.
|Enabled||destination host header requests mapped to policy|
1: URL.Host matches in list Allowed Destination Hosts°
|Stop Rule Set||This will not auth to specific destination hosts. This is a wildcard list of FQDNs like:|
|Enabled||user agent header requests mapped to policy|
1: Header.Request.Get("User-Agent") matches in list Non-Authenticated User Agents°
|Stop Rule Set||If user agent is in list of user agents, Authentication will be bypassed. This is also a wildcard list like:|
The authentication rules are a separate function now and don't need to map entire policies to specific users, groups or hosts, etc.
Do the autehntication in the authentication section of rules, then drop down to a URL filtering Rule Set where you make an entirely different set of conditions.
|Enabled||Allow Social Networking for some users|
1: Authentication.UserGroups contains "Facebook Users"
2: AND URL.Categories<CloudOnly> contains Social Networking
|Stop Rule Set||AD group called "Facebook Users" are allowed to Social Networking Category|
|Enabled||Allow WebMail for some users|
1: Authentication.UserGroups contains "WebMail Users"
2: AND URL.Categories<CloudOnly> contains Web Mail
|Stop Rule Set||AD group called "WebMail Users" are allowed to use web mail|
|Enabled||Allow Domain Admins categories|
1: Authentication.UserGroups contains "Domain Admins"
2: AND URL.Categories<CloudOnly> at least one in list Allowed Categories for Domain Admins°
|Stop Rule Set|
|Enabled||Allow Domain Users categories|
1: Authentication.UserGroups contains "Domain Users"
2: AND URL.Categories<CloudOnly> at least one in list Allowed Categories for Domain Users°
|Stop Rule Set|
|Enabled||Default Block for everyone else|
1: URL.Categories<Default> at least one in list Default Blocked Categories°
|Block<URL Blocked>||Statistics.Counter.Increment("BlockedByURLFilter",1)<Default>||If URL is in given category, then block|
If a request gets to the URL filtering section, they will either be authenticated or not, but if they are, then they will have UserGroups defined for them where the above rules will match. The last rule will be the baseline Block for unauthenticated users.
Of course, this is only one way to do it, but it's a start.Message was edited by: eelsasser on 4/6/11 8:45:56 PM EDT