Mark is not only a Lead Program Manager on the Windows Home Server team, he works on the drive extender technology and is also my manager! Mark has been on the Windows Home Server team for close to 4 years. Mark is a big user of the drive extender technology with an 8TB home server at his house!! That puts my 2TB home server to shame!
Let’s cut to the interview:
Find the full post over at the Windows Home Server blog.
I get a lot of questions on understanding certificates in general, this post is intended to answer those general questions and is not specific to any product. Although I plan on using Windows Home Server and Windows Small Business Server 2008 as examples here. I do have a previous post on understanding the self-issued certificate in SBS 2003 and SBS 2008, as this post will focus on understanding trusted certificates, and what makes them trusted.
Certificates provide two purposes:
I will cover the authenticating the server to the client in this part 1 post, and will write a part 2 post that handles the second part of encryption.
Part 1 – Authenticating the Server to the Client
Think of a certificate like a drivers license; a United States drivers license as that’s what I’m most familiar with. The drivers license has three key components that makes it what it is.
This is the same as a computer SSL certificate. It has a valid URL, an expiry date, and an issuing authority. When the client gets to the intended URL such as https://remote.contoso.com, it asks the server for proof that it is remote.contoso.com, and the server presents it’s certificate. The client validates the 3 checks. Does the URL in the certificate match (ie. are you “Sean Daniel”). Is this certificate valid (is the expiry date past today’s current date and time). Those are the two easy to understand checks. The final check is “do I trust the issuing authority”. In the case of a drivers license, you’d bend it, look at it under a black light to make sure it’s authentic, and then you’d see Washington state issued it and be. Sure, I trust the state government.
With certificates, it’s slightly different. The computer follows the certificate chain outlined in the certificate path (IE view):
In the above example for Home Server, the client will check if it trusts foo.homeserver.com. It looks into it’s trusted certificate store for a matching certificate, none would exist of course, so it would then look for the “GoDaddy Secure Certification Authority” in the same store. Because the “GoDaddy Secure Certification Authority” trusts foo.homeserver.com, the client can base it’s trust on that. Again, it won’t find that certificate, so it bounces up to the root certificate and looks for “Go Daddy Class 2 Certification Authority” in the trusted root store:
As you can see from a view on my Windows 7 box, Windows 7 by default trusts this certificate, so since I trust that certificate, and that certificate trusts the “Go Daddy Secure Certification Authority”, then my Windows 7 machine also trusts this authority, and since the “Go Daddy Secure Certification Authority” trusts foo.homeserver.com, then My Windows 7 client also trusts foo.homeserver.com, and a trusted certificate connection is established.
In the non-computer world, think of it this way. When I try to get on a plane, and I present my drivers license (domestic flights only!), they trust WA state and allow me on the plane. If I were to present my Microsoft Identification, they would probably look at me sideways and ask for another ID, because the airlines don’t trust the Microsoft employee issuing authority. However, if I go to my companies Christmas party I can present EITHER my drivers license, or my Microsoft ID, and they trust both, since they trust WA state, and the Microsoft employee issuing authority.
In Windows SBS 2003/2008 and the use of self issued certificates. You install the leaf cert (sbs 2003) or the root cert (sbs 2008) into your client trusted root store, and now your client will trust that issuing authority as mentioned above. This is outlined in my old post.
On Mobile devices, such as Windows Mobile, you need to ensure the certificate is in that root store as well, which is why some certs work and some don’t on older Windows Mobile devices. Additionally it’s important to call out that browsers on clients behave differently too. For example, Firefox has it’s own certificate store and doesn’t use the one in Windows. The certificates in Windows and also on later mobile devices are updated and maintained through the secure connection of Windows Update.
Hopefully this clears up the server to client authentication. Of course we know the client authenticates to the server by providing your username and password to prove you are indeed the user the server should give access to.
Last important thing to remember, is NEVER install a certificate over an unsecure or un-trusted internet connection, you should always use a SECURE method of installing certificates. That means you download a cert over an already trusted and secure connection, or you bring it home in your pocket on a USB key. You never know if there is going to be a malicious server giving you a bad certificate for the wrong server on the Internet. Then you will just be giving your username and password to the wrong server on the Internet, and that would be disaster.
Browsing my one of my favorite RSS feeds: LifeHacker. I came across something that might be useful to a bunch of Small Business Server VAPs configuring your network. In many cases, some companies like to provide a courtesy kiosk for visiting folks or perhaps they have a single computer for the break room.
Over at How-To Geek is where they outline the steps. Basically it leverages local Group Policy (although there is no reason you can’t do this in global group policy on your Windows Small Business Server 2008 machine) to allow users to only run certain applications. Thus preventing users from getting into trouble and lowering your total cost of ownership on that client PC (or your whole network).
I’m copying the steps here for convenience. Thanks How-To Geek!
If you have a shared or public computer you might want to allow users to use only specified programs. Today we take a look at a setting in Local Group Policy that allows you to set only specified programs to run.
Note: This process uses Local Group Policy Editor which is not available in Home versions of Windows 7.
First click on Start and enter gpedit.msc into the search box and hit Enter.
Navigate to User Configuration \ Administrative Templates \ System. Then under Setting scroll down and double click on Run only specified Windows applications.
Set it to Enabled, then under the Options section click on the Show button next to List of allowed applications.
A Show Contents dialog comes up where you can type in the apps you want to allow users to run. When finished with the list, click OK then close out of Local Group Policy Editor.
If a user tries to access an application that is not on the specified list they will receive the following error message.
This is a nice feature for limiting what programs users can or cannot access on the computer.
Ever wish you could just get to all the configuration changes in Windows with one folder, instead of going back and forth in the Control Panel? Well, now you can. Elegant Code has a blog post on how to do this. Here’s how:
This gives you a new folder with a nice icon:
Opening this folder gives you the giant list of configuration items that span across all of the control panel and such. Giving you ultimate access to configuration aspects. I only have tried this running as an Administrator on the system.
And just as a reminder, “God” is not considered a strong password to protect your system, so don’t let this go to your head. ;o)
UPDATE: Looks like ZDNet gets to the bottom of all the GUID mode shortcuts. Their post is here, including:
Oddly enough, over the holiday’s I was working to figure out the remote access for my friend who just recently got a home server. For all intents and purposes, his router stated the ports were open, yet Home Server would not show that remote access is available. A quick Bing search lead me to believe from forums that the ISP (Telus in Canada) blocks the required ports for Windows Home Server
Those ports, 80 & 443 used for HTTP and HTTPS access to the server means that you are in a double-NAT environment that your ISP provides for you. Unfortunately you have no control over the external most NAT device and as a result, remote access won’t work for you. Here is a video from HomeServerLand that will help you understand this scenario
The options if you find yourself in this situation are:
Good luck with your ISP, you’ll need it!
Are you having troubles with remote access? Could it be because you have a Double-NAT configuration on your network? HomeServerLand has a video that explains what a double-NAT is and how you can avoid it. It’s a great 2 minute video that will help you understand this configuration and how to avoid it.
This great video talks about how to determine if you have a double NAT either on your local network, or from your Internet Service Provider.
If you haven’t already, make sure you check out HomeServerLand’s very valuable router configuration support wiki.
In a follow up to last weeks blog on Understanding and set up of Remote Access to Windows Home Server, Sean Daniel, Program Manager for Windows Home Server, has provided further information on potential issues that you may experience when setting up your Remote Access, and how to solve the problem.
Once you finish setting up your remote access through Windows Home Server’s Wizard, a final screen will be shown. In a perfect world, when you click on Details you’ll see all green checks once you have finished this wizard. However, because there are three components (the home server, the ISP and the router), sometimes there is a snag in the setup. Here is an example of a working domain name with sample data:
The first check-box will actually check to make sure you have an outbound connection. This will ensure it can connect to the specific …
Subscribe
