Wednesday, July 30, 2008
Hopefully this clears up some of the questions you might have had.
Thursday, July 24, 2008
You are probably familiar with the Windows Small Business Server 2003 newsgroups. And you are probably also wondering where are the 2008 newsgroups? Well, the good news is the newsgroups have started. The bad news is the spammers have gotten a hold of our 2003 newsgroups, and making them more spam then anything else.
As a result, the public newsgroups have gone to Connect!
Yep, head on over to Connect to sign up for the newsgroups to get an insight view of SBS 2008, even if you don't have time to install the Release Candidate of SBS 2008.
Friday, July 18, 2008
For more information on the last release candidate (known as RC1) visit the Windows SBS 2008 Connect Website. The RC1 will be available to the general public sometime next week, register today to get notified!
Monday, July 14, 2008
Allowing OWA and Mobile Devices to download files from SharePoint and the File-System without a VPN connection
The Power of Exchange 2007 is amazing. Did you know that with Exchange 2007, that's included with Windows Small Business Server 2008 you can have your Outlook Web Access and Mobile Device users click a link to download files directly from the Internal Company Web Site (http://companyweb) or file shares?
Well, you can and it's easy to use, and easy to configure.
To Enable Remote File Access for Outlook Web Access Users:
- Click Start, All Programs, Microsoft Exchange Server 2007, and then select Exchange Management Console.
- Once the console opens up, expand Server Configuration and then click on Client Access.
- Right-click on the owa (SBS Web Application), and choose Properties
- Once the property page loads, click on the Remote File Servers tab, and click the Allow button.
- In the pop-up that opens, type in "companyweb" without the quotes
- Click Ok and then Ok again to get back to the console.
Now when users send email with http://companyweb/shared%20documents/myfile.txt as a link in email, Outlook Web Access users will be able to click the link and download the file directly through OWA.
This technique can be done with file-servers as well, simply by putting the SBS server name into the Allow list. The user would just put in \\server\share\filename.ext into the email and the user would be able to download it via OWA.
Finally, you can also do this for mobile devices, by switching tabs to the Exchange ActiveSync tab and repeating the same steps.
Thursday, July 10, 2008
A couple of days ago, I made a post to help you understand the self-issued certificates. Today I wanted to extend on that and show what's been built for 2008 to help you install the self-issued certificate. If you open the Company Web Site inside the company, you'll notice an announcement that tells users how to obtain this package. They can browse to "\\contoso-server\users\public downloads" on the server and obtain the zip file shown on the left. This zip file can then be copied to a USB key or floppy drive and taken to the remote PC. Alternatively, it can be run inside the network to install the certificate onto a Windows Mobile device that is connected to the user's PC. It is not necessary to use this package on client computers that are joined to the domain because Group Policy will push the certificate to these client computers, for the case of a laptop that leaves the domain, it will already have the certificate installed in the trusted root store.
One thing to note, is that each time the Fix My Network wizard is run, it checks the validity of the certificate, if it's invalid, it'll go ahead and re-create the certificates and fix everything up for you.. including dropping a new package to the Public Downloads share.
Once you have the tool at the remote location, un-zip it, and run it. The tool is very simple, and runs on XP SP2 or higher clients, including Vista. When you run it, you will see the following UI:
As you can see from the screen shot, you can install the certificate on the remote PC, or any device running Windows Mobile 6.
While using self-issued certificates got easier with 2008, its still a pain to have to install the certificate every 5 years onto remote devices, it's far easier to use a Trusted Certificate.
Wednesday, July 09, 2008
SBS 2008 Migration demo and interview
If you want to read and comment on the post, visit TechNet Edge.
Tuesday, July 08, 2008
Wrap up of SBS/EBS announcements from World Wide Partner Conference
Check read the comments or leave a comment over on this post at TechNet Edge.
You can learn all about the System Health for SBS 2008 by watching his video here:
SBS 2008 system health PM interview and demo
Click here to go to the post over at Technet Edge
Since there seems to be some confusion about the removal of "Server Down" support, I wanted to make sure this got some broad reach. In case you haven't seen over on the Official SBS Blog, Microsoft has responded with corrections to assumptions.
Most importantly, the "Server Down" support will continue on until it's announced officially on a Microsoft web site. For details, point your browsers over to this post at the Official SBS Blog.
Monday, July 07, 2008
I'm not going to make a statement that understanding self-issued certificates is hard, but I do get enough questions on them that it's prudent for me to do a post regarding them to help folks understand how they work.
First, what's a Certificate used for?
An SSL Certificate is used for two reasons, to validate the remote server to the client, before the client sends any data to that server, and to encrypt the data between the client and server over an un-secure network (ie. the Internet). The former prevents DNS attacks such as Man in the Middle Attacks, or Phishing, by having the server present you with some valid Identification that it is who the server says it is. Think of it like Identification for you at a party or club. Let's say you work for a company called Contoso, they have photo id at the company which you have, and you also have a valid drivers license for the state you're in. Let's say you go to an invite-only party. If you show up at that door, you can show your drivers license to prove that you are who you say you are, this has your picture on it that the door man can see, and your name. The door man can look at the picture, and at you, and because he trusts the state government, knows that you are you. Think of the state-issued drivers license as a Trusted Certificate, because the door man trusts the issuer (or the state government).
Now let's say you show up at the same party, but this time the party is a party for Contoso. You could show your drivers license because the door man will trust the state-issued ID, or you could show your company ID badge, because the door man works for this company and trusts the badges issued by Contoso. Think of the company ID badge as a Self-Issued Certificate. Because the badge and ID was maintained by the company, not all locations will trust it, just the ones that trust that Issuing Authority (or the company Contoso's badges).
Back in the land of computers, let's take a look at what happens when a client connects to a secure server. To the left is the process that clients and server goes through. The client will resolve the server's IP address via DNS and end up at a server's web-site. That client will want to verify the server's identity, so it will request the server's certificate, or Identification. The server will provide this certificate to the client.
The client then looks at the certificate and validates 3 key things:
1) The date range for validity of the certificate. Is the current date on the client within the start/end dates for the certificate provided by the server?
2) The URL the client was attempting to go to is the URL of the certificate (e.g. www.contoso.com is both the URL that the client wants, and what the certificate was provided)
3) The Certificate is from a trusted provider. The client will look at the certificate chain and validate that the root certificate is located in the client's local trusted certificate store as a valid trusted certificate.
If all three of these checks pass, the client will then agree to trust the server and use the certificate to encrypt traffic when talking to the server, and request the web page the client was originally looking for. Please note here, that the client doesn't get to the web-site (including any IIS headers) until the certificate is validated. So if the server is hosting multiple web-sites, it has no idea which one the client is asking for until the process of validating the certificate is complete.
Once the certificates first purpose is completed (to ensure the client is actually talking to the correct server on the Internet), the second purpose kicks in and the client uses the public encryption key to send and receive information to and from the server. The server is the only machine on the whole Internet (if it's not, the root certificate needs to be recreated, unless there is trust between those multiple computers, as in a cluster.) that has the private key and can decrypt the network traffic.
You may wonder how the server identifies the client computer through all this? That's the easy part, the user logs into the web-site with a username and password, and sometimes additional authentication keys using 2-factor authentication.
So a Trusted Certificate is more secure right?
Wrong! A Self-Issued certificate, and a Trusted Certificate often provide the same level of encryption. The big difference between a self-issued and trusted certificate is the ease of use. Many trusted certificates are good for 1 year, and have 1024 bit encryption. The SBS self-issued certs are good for a period of time (5 or 2 years as you'll see below), and also have 1024 bit encryption. Where they differ is distributing the root certificate. In order for a client (PC, Windows Mobile, MAC, etc) to trust that certificate it must know about the root cert, which means in a self-issued scenario, that this cert must be distributed to all clients that are going to connect to the server. In a trusted certificate scenario, the trusted root certificate is already distributed by Windows Update, or at the time the PC, MAC or Windows Mobile device was built! So there is no need to distribute the root cert if you're using a trusted certificate, because the client already trusts the root cert.
So, your choice between Trusted and Self-Issued really comes down to how much work you want to do to distribute the root certificate, more so then the security level of the certificate. You need to consider all the devices that will connect. If one of those is a kiosk at an airport or hotel, in which you cannot install the root cert, then there is a clear choice for you towards Trusted Certificates. If you have remote workers, it's probably easier to get a trusted certificate as well.
(As a side note, 1024 bit encryption was chosen primarily because the processors in Windows Mobile devices get bogged down encrypting and decrypting traffic using higher numbers. I'm sure this will change over time)
Windows Small Business Server 2003 Self-Issued Certificate
In SBS 2003, the root certificate was also the leaf certificate. This means that the root certificate was the certificate used to validate trust, and also encrypt the traffic on the web.
As you can see, the certificate is the root certificate. This certificate needs to be sent to all the remotely connecting devices. If this certificate is not in the remote computer/device trusted authority certificate store, then the user will always receive a certificate warning that the certificate is not trusted. This root certificate is valid for 5 years.
Windows Small Business Server 2008 Self-Issued Certificate
In SBS 2008, we went a step further with the self-issued certificate, and provided a root certificate and a leaf certificate. The root certificate needs to be distributed to all the clients, and the leaf certificate is installed onto the IIS web site. This adds slightly more security over SBS 2003, because the leaf certificate is valid for 2 years, and the root certificate is valid for 5 years, similar to SBS 2003. The reason this is more secure, is because if the leaf certificate is compromised by any way, you can simply re-issue a new leaf certificate and not have to replace any of the certificates on the computer/devices. In fact, the Fix My Network wizard will do this for you when the certificate is about to expire.
You can see the chaining from the certificate path above. In addition to the new improved design of the certificate infrastructure, we also provided a ZIP file that can be used to distribute the package. This Zip file is available from "\\contoso-server\public\public downloads\" internally to the network only. Users will copy this ZIP package to a USB disk and take it with them to their home PC to install it.
Important: People always ask me why this isn't available directly from the Remote Web Workplace. Well, it goes back to the flow chart above. You can't download a certificate to trust a server from an un-trusted source! Essentially if you agree to go to the un-trusted source, you have no guarantee that the package you download is the right one. Not only that, but you will have already provided your username and password to an un-trusted server which could be the wrong one! If the un-trusted server was malicious, they could log into the actual server as the user and do all sorts of damage! Taking the package home on a USB key in your pocket is the safe way, because the certificate is traveling through a trusted path out to your remote PC.
In addition, because the Certificate Authority is configured and set up by default in SBS 2008, you can entertain the idea of using the certificate infrastructure to configure secure wireless, or IPSec, or secure VPN.
So, if you're still reading (long post today!), you understand how certificates work to secure network traffic and ensure you're communicating with the correct server. You understand the differences between the self-issued certificates, and trusted-authority certificates, and finally, how they are used in the two versions of Windows Small Business Server that use certificates.
If you wanted the Microsoft recommendation, for ease of configuration and explanation to your end users only, we recommend going with a trusted certificate for your network. Prices on trusted certificates have fallen to less then it would cost to pay a consultant a hour to install the remote devices, not to mention the education you need to provide your users. In speaking with many consultants, they'd rather spend their efforts elsewhere any ways! The self-issued certificate is really a means to provide encryption level security to businesses that absolutely cannot afford a trusted certificate. Trust me, it's worth it...
For bonus points, who can tell me why I call them self-issued instead of self-signed?