Good morning all,
Currently running MWG 184.108.40.206.0.
I've got MWG running quite happily in our main domain at the moment, however I've had a request to add in some filtering policies for one of our subsidaries who have their own AD domain. My thoughts are to join the MWG appliance to the new domain & create a new port for HTTP proxy (the new domain wants a different level of web filtering compared to my current ruleset - I've used this approach before and seems to work well for differentiating groups of users/devices).
On my current rule set i have block templates with our company branding (logo & service desk contact details configured in the default schema) - one of the requirements for adding this domain is not to include this information. Does anyone know the easiest way of setting up new block pages that I can apply depending on the domain the user is coming from?
Hope this makes sense & any help appreciated.
Solved! Go to Solution.
MWG should work just fine with multiple domains. To differentiate, companyA from companyB, you could go the proxy port based route, or do it based on client IP. Proxy port is probably easiest.
The block page question is the tricky part because there is no easy solution.
The only thing that I could think of is you set the "Message.Language" property based on the incoming proxy port *in one of the first rules*.
Once this is set, you would need to modify all of the block pages to use this to determine the language, instead of based on the browser (auto).
On a side note from your question I'd recommend upgrading to take advantage of latest features. 220.127.116.11 is still vulnerable to Heartbleed for example.
Thanks for the reply, much appreciated. I have decided to go down the seperate proxy port route - I've created new top level rule sets so that filtering is only applied to the new domain if the users are connecting on the new listener port. My approach to the filtering pages so far is to create a new collection & edit the default schema with the new logo/contact detail text. I've then added a new block page (in my test it's the URL Blocked page) & edited the rules where this applies. It works (or seems to) but i suspect isn't the quickest/cleanest approach.
Thanks for the advice on the MWG version too - I will look into the upgrade pretty quickly in that case.
Further to my last reply - i've now gone through and set up block pages for each domain (using 2 different template collections). This has worked for anything in my policies (where i've changed the block pages for the ruleset under my new proxy port), however i've run into a problem with proxy generated error/info pages (such as the FTP browsing page). Generated pages such as these use the original template, so no new logo/text.
On further investigation these seem to be defined under the 'Proxy Generated Error Messages' configuration option.
It doesn't look like I can have more than one collection here; is it possible to define this on a per-port basis, or have a rule to define which collection to use perhaps?
You are correct.
Proxy messages happen outside the scope of a block page. It wouldn't have the context to know who the user was in order to know which block page to present.
You should make a generic, non-branded set page with minimal information in oder to apply to all proxy generated messages.
I've attached a generic-lloking System schema that I use for those peruposes.
Create a new collection called System and import the .zip file into it.
Thanks for the reply - that makes sense. Apologies if i've misread your reply - should a zip file be attached?
It didn't when i posted the reply but does now. Must be one of those days
I've got the zip file now, thanks very much
On the topic of multiple domains - I've also been looking at how the logs can be imported into web reporter - is there anything i would need to do specifically to identify users on different AD domains? would this be worth writing seperate access logs for each AD domain so i can better differentiate them?