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;
- Explicit Proxy - destination host header requests mapped to policy
- Explicit Proxy - user agent header requests mapped to policy
- Explicit Proxy - ICAP Header (X auth groups) mapped to policy
- WCCP as fallback for anyone not using the explicit proxy settings.
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.
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 Rule Action Events Comments 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 Rule Action Events Comments 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.
hehe. Yes screenshots are helpful. I'll grant you that.
I just can't read them on my phone when the notifications come in.