thx! ________________________________
From: Michael B. Smith [mailto:mich...@theessentialexchange.com] Sent: Monday, March 09, 2009 10:51 AM To: MS-Exchange Admin Issues Subject: RE: OWA That's one way. You can also set the TrustedClientTimeout to be the same value as the PublicClientTimeout KB 830827 As far as I know, the timeout is the only different between public and private. From: David Mazzaccaro [mailto:david.mazzacc...@hudsonhhc.com] Sent: Monday, March 09, 2009 10:40 AM To: MS-Exchange Admin Issues Subject: RE: OWA What is the best way to force the "public computer" setting? Simply remove the radio button and text from the html? ________________________________ From: Michael B. Smith [mailto:mich...@theessentialexchange.com] Sent: Monday, March 09, 2009 9:52 AM To: MS-Exchange Admin Issues Subject: RE: OWA Three things: 1] Disable attachments via OWA 2] Use SSL combined with Forms-Based authentication with OWA 3] Force the "Public Computer" setting on OWA With those three things, barring an exploit, I would feel quite good about OWA's security. Actually, better than RPC/HTTP. There is no way using RPC/HTTP to constrain what computer attaches to RPC/HTTP. I guess that with Windows 2008 Network Access Control/Protection (or a similar solution from another vendor), you could do it based on the MAC address of the VPN client - but no Exchange-based way. From: Fogarty, Richard R CTR USA USASOC [mailto:rick.foga...@us.army.mil] Sent: Monday, March 09, 2009 9:31 AM To: MS-Exchange Admin Issues Subject: OWA We're currently running a hefty E2k3 environment. Currently, our customers only have access to their e-mail (when outside our infrastructure) by using the existing terminal server - which can only be accessed through the VPN. I'm proposing (through an impact assessment) that we view the possibilities of providing access without using the following methods. I've come up with two possibilities: 1.) OWA 2.) RPC over HTTP For quite some time, OWA has not been authorized. It appears that there are some valid points - and some control issues that have taken it off the table. Since our customers have the ability to work with some sensitive documents, OWA has always been discounted due to the possibility of a customer opening up a sensitive document on a public computer. I'm not aware of any way to delete all of the cache after the docs have been downloaded on said public computer. In fact, it doesn't even have to be public, it could be the customers home computer as well. In either case, there are valid concerns. Apparently, our infrastructure guys (for some reason) believe pulling OWA into the mix would create a huge task to redesign our infrastructure. So, to accommodate them, I recommended using RPC over HTTP when using the VPN. This way, anyone that has a travel approved laptop, still has the ability to pull down their mail - to their system, and not be bothered with the TS. So, essentially, connect to the VPN - get your mail, disconnect - work, reconnect and send all your mail. A bit of a pain, but a compromise nonetheless. While attempting the Impact Assessment, it was brought up that many other "similar" units that have similar customers provide OWA as a service. During the review processes of this IA, my boss asked, ok, if OWA isn't recommended here due to security concerns - how can XXX unit get by with it? I can't speak about the other security personnel, but I do have some concerns about the "left over" garbage once a user is done on a computer. Is OWA still considered a security risk? How do others ensure documents read on a public computer are not left over for others to view? Comments? Thanks Rick ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
