Default policy does not apply by default
-
A client told me that users can't save XML files from Outlook Web Access, and a little googling around told me that OWA's default policy blocks certain attachments (why is XML on that list anyway?). Open Exchange Management Console, edit the Default (and only) OWA policy, remove XML from blocked extensions and MIME types,, and try saving an XML attachment - except it still doesn't work. Just to be on the safe side, I also added XML to the Always save list, with no apparent effect.
After googling around a bit, I found a thread on ExpertsexChange that had the answer: manually apply the default policy to all users:Get-Mailbox -organizationalunit "SBSUsers" -resultsize unlimited | Set-CASMailbox -OwaMailboxPolicy "default"
What's the point of default policy if it doesn't apply by default (what is it using instead then? there's no other policy defined), and why are XML files so dangerous that they have to be completely blocked by default?
-
For the first time in my life I agree with MS on something... block XML out, you'll live a happier life.
-
@ender said:
A client told me that users can't save XML files from Outlook Web Access, and a little googling around told me that OWA's default policy blocks certain attachments (why is XML on that list anyway?). Open Exchange Management Console, edit the Default (and only) OWA policy, remove XML from blocked extensions and MIME types,, and try saving an XML attachment - except it still doesn't work. Just to be on the safe side, I also added XML to the Always save list, with no apparent effect.
I recall my current sysadmin saying something about the MMC snap-in not actually making changes to the new exchange's settings anymore (2010?) and everything has to be done from powershell.
After googling around a bit, I found a thread on ExpertsexChange that had the answer: manually apply the default policy to all users:Get-Mailbox -organizationalunit "SBSUsers" -resultsize unlimited | Set-CASMailbox -OwaMailboxPolicy "default"
What's the point of default policy if it doesn't apply by default (what is it using instead then? there's no other policy defined), and why are XML files so dangerous that they have to be completely blocked by default?
-
@ubersoldat said:
heeheeFor the first time in my life I agree with MS on something... block XML out, you'll live a happier life.
Mandatory hint: But only XML is enterprisey enough!
or: if your problem is too complex, add XML
-
@ubersoldat said:
For the first time in my life I agree with MS on something... block XML out, you'll live a happier life.
The accounting software needs those XMLs - no XML, nobody gets paid (don't ask me why some of it has to be exchanged through e-mail, and why specifically is OWA needed, when they have Outlook).
@rad131304 said:I recall my current sysadmin saying something about the MMC snap-in not actually making changes to the new exchange's settings anymore (2010?) and everything has to be done from powershell.
Many (but not all) things can still be done through the Management Console, but all it does is run powershell scripts in the background (managing the list of extensions and MIME types is definitely easier through the GUI than the shell). This is both in 2007 and 2010.
-
@ender said:
What's the point of default policy if it doesn't apply by default (what is it using instead then? there's no other policy defined)
Gonna guess that the default policy would apply to new users. And, the policy it's using for everyone else is... everyone else's policy. You're assuming that permissions inherit, when it appears that permissions are static per user. Eg, the defaults are just a template that get applied when a user is new.
-
@pkmnfrk said:
Gonna guess that the default policy would apply to new users.
Nope, if I modify the extensions list now, the changes are applied immediately.
-
As for why XML would be blocked, if it contains a stylesheet then it could potentially be auto-transformed into a dangerous script by the browser.
-
@ender said:
@pkmnfrk said:
Gonna guess that the default policy would apply to new users.
Nope, if I modify the extensions list now, the changes are applied immediately.Welp, dunno what to say then. Except that you should switch to Google Apps :)
-
@ender said:
@ubersoldat said:
Well, it wouldn't be the first time he's been wrong about something. I think, as usual, he's just pwned the configuration because both the MMC and the EMC have never worked when I've been asked to do even the simplest tasks (e.g. allow a user to send to a distribution group).For the first time in my life I agree with MS on something... block XML out, you'll live a happier life.
The accounting software needs those XMLs - no XML, nobody gets paid (don't ask me why some of it has to be exchanged through e-mail, and why specifically is OWA needed, when they have Outlook).
@rad131304 said:I recall my current sysadmin saying something about the MMC snap-in not actually making changes to the new exchange's settings anymore (2010?) and everything has to be done from powershell.
Many (but not all) things can still be done through the Management Console, but all it does is run powershell scripts in the background (managing the list of extensions and MIME types is definitely easier through the GUI than the shell). This is both in 2007 and 2010.
-
@ekolis said:
As for why XML would be blocked, if it contains a stylesheet then it could potentially be auto-transformed into a dangerous script by the browser.
Only if OWA is dumb enough to display the XML file. The only thing I can come up with is that maybe they were afraid there would be browsers that ignored the instruction to download the XML file and displayed it inline instead.
-
@morbiuswilters said:
@ekolis said:
As for why XML would be blocked, if it contains a stylesheet then it could potentially be auto-transformed into a dangerous script by the browser.
Only if OWA is dumb enough to display the XML file. The only thing I can come up with is that maybe they were afraid there would be browsers that ignored the instruction to download the XML file and displayed it inline instead.
Having seen a working (in IE 7, at least) XSS attack against a text/plain file, I wouldn't be surprised at something comparably minor like that. (Apparently older IE will attempt to interpret a text/plain file as HTML if it looks sufficiently HTML-like enough. Also, people tend not to HTML-escape output into text files, because that would be ridiculous, so it's quite hard to know what to do in that situation. Wikipedia uses the ingenious but somewhat worrying workaround of serving plaintext files using text/css, because it renders the same way as text/plain in every browser but IE never interprets it as HTML…)
-
@ais523 said:
Having seen a working (in IE 7, at least) XSS attack against a text/plain file, I wouldn't be surprised at something comparably minor like that. (Apparently older IE will attempt to interpret a text/plain file as HTML if it looks sufficiently HTML-like enough. Also, people tend not to HTML-escape output into text files, because that would be ridiculous, so it's quite hard to know what to do in that situation. Wikipedia uses the ingenious but somewhat worrying workaround of serving plaintext files using text/css, because it renders the same way as text/plain in every browser but IE never interprets it as HTML…)
I thought that IE will execute scripts ("expressions") in CSS. Or is it extremely limited in what it will actually evaluate?
-
@ais523 said:
Having seen a working (in IE 7, at least) XSS attack against a text/plain file, I wouldn't be surprised at something comparably minor like that.
I don't think that's the same thing I'm talking about. If you tell IE7 to download a file, it will do it, not display it inline. I don't know what browser would display it inline (maybe some plugin which changed the behavior?)
-
@sprained said:
@ais523 said:
Having seen a working (in IE 7, at least) XSS attack against a text/plain file, I wouldn't be surprised at something comparably minor like that. (Apparently older IE will attempt to interpret a text/plain file as HTML if it looks sufficiently HTML-like enough. Also, people tend not to HTML-escape output into text files, because that would be ridiculous, so it's quite hard to know what to do in that situation. Wikipedia uses the ingenious but somewhat worrying workaround of serving plaintext files using text/css, because it renders the same way as text/plain in every browser but IE never interprets it as HTML…)
I thought that IE will execute scripts ("expressions") in CSS. Or is it extremely limited in what it will actually evaluate?
It let you run any function. I don't know if it is still does. Actually a very useful feature but poorly thought-out.
-
@rad131304 said:
@ender said:
A client told me that users can't save XML files from Outlook Web Access, and a little googling around told me that OWA's default policy blocks certain attachments (why is XML on that list anyway?). Open Exchange Management Console, edit the Default (and only) OWA policy, remove XML from blocked extensions and MIME types,, and try saving an XML attachment - except it still doesn't work. Just to be on the safe side, I also added XML to the Always save list, with no apparent effect.
I recall my current sysadmin saying something about the MMC snap-in not actually making changes to the new exchange's settings anymore (2010?) and everything has to be done from powershell.
After googling around a bit, I found a thread on ExpertsexChange that had the answer: manually apply the default policy to all users:Get-Mailbox -organizationalunit "SBSUsers" -resultsize unlimited | Set-CASMailbox -OwaMailboxPolicy "default"
What's the point of default policy if it doesn't apply by default (what is it using instead then? there's no other policy defined), and why are XML files so dangerous that they have to be completely blocked by default?
Meh. It wasn't so long ago that Microsoft was all bothered about MMC and how cool snap-ins were. I never got it... how much do the snap-ins really have in common anyway? And how many of them were as annoying as shit?
Now they're cramming a command-line tool down our throats. Did the MMC Nazis lose out to the Powershell anarchists? Or was the evolution from snap-in based GUI to exceedingly cryptic new shell scripting system an inevitable, even planned occurrence? I'm guesing the former explanation is more correct.
-
@bridget99 said:
Meh. It wasn't so long ago that Microsoft was all bothered about MMC and how cool snap-ins were. I never got it... how much do the snap-ins really have in common anyway? And how many of them were as annoying as shit?
You mean like how the Refresh button isn't available half the time? MMC always seemed half-baked to me, too, which is a pity because it's a good idea if done correctly.
With Exchange, it seems to be a toss-up between whether Microsoft or the sysadmin is responsible for the workload of uncommon tasks. If there's something that you may only ever have to do the once, should Microsoft expend the effort desiging and testing a GUI control to perform it, or should the sysadmin waste a load of time figuring out from various blog entries and half-written MS docs exactly what PowerShell command must be entered?
With regards to the OP: I guess the advantage of Windows Small Business Server is that it's "cheap", but since many small businesses don't run their own IT anyway, would it not be nice if Microsoft would licence normal Windows Server + Exchange with the same CAL limit, for exactly the same price, so that no-one is forced to screw around with all the stupid wizards if they don't want to? The joy of SBS is wasting time trying to figure out whether the wizards can do what you want (in which case it's supposedly do-or-die), or whether you're expected to do it the "hard" (read: easy and obvious) way. Also, notice how the SBS control panel actively discourages Group Policy by making you set every bleeding setting on a per-user basis?
