So my boss made a comment that he thought the entire IT department could read his e-mail one day.  We recently switched to Office 365 and as many mail administrators know it is possible to grant yourself access to other user’s mailboxes and poke around in most e-mail systems, Exchange included.  There are valid reasons for this like when a person has an assistant or multiple people using a shared mailbox.

Regardless the question came up, what if I DO NOT want anyone else to see an event on my personal calendar, especially if I provide access to my mailbox to other users.  Luckily in Outlook and Exchange Web App this is fairly easy to do.  After all you probably don’t want to let you assistant know you are going for a colonoscopy but you still want other employees to simply know you are out of the office!

When you compose a new message in Outlook simply mark the button that says “Private” on the ribbon.  This will hide the details in your Free/Busy information and will by default hide it from anyone who has read permissions to your calendar.  Please note however that anyone with at least read permissions could get access to the details if they were technically inclined.

You can get more information about this topic from Microsoft here: http://office.microsoft.com/en-us/outlook-help/make-an-appointment-or-meeting-private-HP001230355.aspx

Thanks,

Brent

I'm attempting to lock down our SPAM and Firewall settings with Office 365 and FOPE. One of the key things we want to do is prevent certain file formats from both entering and leaving our organization. This is often a common request among E-Mail security people. FOPE allows you to define all sorts of rules using Regular Expressions (RegEx) or using Dictionaries. Dictionaries are simply large CSV (Comma Separated Value) files that contain all of the extensions to be blocked.

The FOPE Admin guide provides a good starting list to build a dictionary. It's pretty hard to use RegEx for file extensions, if not impossible. I'm providing the CSV file we used to secure the system. It's a pretty good starting point and covers most files that can execute on a Windows box. We also included some of the OSX extensions that can execute as well, although this was not our primary goal since we have 1 Mac using the service.

For more details on uploading and defining policies take a look at the FOPE Best Practice Guide: http://technet.microsoft.com/en-us/library/ff715282.aspx

Brent

Click here to download:

File Extension Dictionary.csv (0 Bytes)

Background

I recently went through the motions of setting up Active Directory Federation Services (ADFS v2) for Kreisler to allow us to begin using Office 365 with federated authentication. We have some other potential uses for federation coming later on as well. This post is not meant to dive into how we set everything up because for the most part it was relatively simple. The Office 365 documentation is very helpful and if you follow it step by step you can accomplish what you want. However, a few parts in particular were confusing for me and took a couple of tries to get right. They are:

1. SSL Requirements
2. Domain Name Forwarding and Requirements

For those not familiar ADFS does require SSL certificates and in a production environment you need to purchase at least 1 certificate and possibly 2 depending on how security conscious you are. In addition if your network is similar to ours you need to work some DNS trickery to get the desired end-user behavior.

Our ADFS Design

We don't have a large user base so having a large server farm is not required and even for small businesses (400 or less employees) this farm will support the load just fine! Our farm is composed of the following:

1. One ADFS Server
2. One ADFS Proxy

It should be noted that we decided to utilize our existing MSSQL infrastructure to host the ADFS databases and not the Windows Internal Database.

SSL for ADFS

So the documentation in Office 365 in regards to the SSL setup is somewhat confusing. Here is what it boils down to. You MUST generate the initial certificate request from your ADFS Server, even if this server is not going to be publicly facing! In addition for each certificate you generate make sure the Common Name is identical for each certificate you request. In our design we requested a single certificate. Once you get the certificate loaded life should be good, but then you have to install the Proxy. You have two options here:

1. Export the certificate from the ADFS Server, or 
2. Request a new certificate

Security Experts will say to use number two because if the public facing certificate is compromised so is your internal certificate. Then again if you don't have hundreds to throw at SSL certificates number one becomes very appetizing. You can follow standard IIS help and instructions for exporting and importing a certificate from one server to another. Once we got passed the certificate problems we were able to get the system up and running properly.

DNS for ADFS

The idea with ADFS in a Server and Proxy configuration is that internal clients will utilize Windows Integrated Authentication to login to the federation server while external clients will be redirected to a form to attempt to login. Here's the problem with this:

1. The Common Name from your SSL certificate should match the publicly accessible DNS A/AAAA record for your Federation Service. 
2. The proxy by default receives all public requests, which is normal. 
3. Internal users will still make a call to "fs.mydomain.com" which points them to the Proxy as opposed to the Server, this causes internal users to have to login.

The documentation again is somewhat light in this area. There is lots of talk about setting up HOST file definitions, which if you ask me is somewhat archaic. We took a different approach, DNS. We setup a new forward lookup zone in our Active Directory enabled DNS servers for "fs.mydomain.com" which meant that the server now becomes authoritative for our Federation Services sub-domain, so any internal requests will now get processes by our internal DNS servers and not get forwarded to external servers. The last step was to simply create an A/AAAA record for ".fs.mydomain.com" to point to the Federation Server. Now any request for "fs.mydomain.com" gets sent to our Federation Server.

Ta-Da

Again, these are just some of the larger problems we had getting things up and running but it appears to be working like a champ at this point. I'll have another post in the future to help customize your Federation Forms Login page to brand it and customize the behavior.

-Brent