I’m on some sort of vacation since last week at home in Puerto Rico… I say “some sort” because I’m actually upgrading my last SBS2k box to 2k3 and using the old box as a terminal server. While I was preparing the migration the client asked if there was a way to take out the “Security Warning“ page that they get when they access OWA (and RWW in the future) from a public computer (one that the cert has not been imported previously)… and I told him that it would cost $400-800/yr to get a Verisign cert to fix that. We both knew that there is no way they were going to pay that for getting rid of such small annoyance.
The next day I got curious, researched this a little more and found out that there were many “trusted“ companies (I mean trusted in the sense that IE and most browsers already trust the ssl cert authority) that sell SSL certs for less than $30/yr. So, I asked my client if the “convinience” of not having to click on the security warning box was worth $30 and they said yes. So, I ran the SSL cert wizard on the SBS box to issue the CSR, then I went to www.godaddy.com and got a Turbo 128-bit SSL Cert in about 10-15 minutes. The browser (and more importantly my client) was happy.
This reinforced my beliefs on a couple of things…
1) This is not something I would normally do… but for $30 is not a bad deal.
2) Verisign overcharges for pretty much everything… I don’t know how people keep doing business with them. Who cares where the cert comes from (i.e. normal people don’t check who’s the issuing authority)?
3) Anyone can get an SSL cert. The “verification” process was a joke (just a reply to an email sent to the domain owner). While I really don’t care for SBS, some people think that just because there is a “secure” icon on the browser the transaction is really secure.
That’s all for now… 🙂
If you have a remote office or a branch it might be a good idea to have those users connected to your primary office permanently. You could even have an additional domain controller on the remote site or even make the users login via a Terminal Server on your primary location. To connect the two locations together you have a couple of options:
- Connect each computer individually using PPTP VPN to the SBS box directly.
- Use a PPTP VPN-capable router on the remote site and establish the VPN directly to the SBS box.
- Use 2 VPN routers (IPSec) to establish a site to site VPN.
Option #3 is fairly common. However, this method presents a problem when you want to keep using ISA. You cannot put the router in front of ISA anymore because you will terminate the VPN tunnel there and your users will not be able to access the resources in the LAN. So, what can you do? Well, there are a couple of ways to go around this problem… I will discuss one way:
You will need two VPN-capable routers (and know how to create a “normal” tunnel between them) and two public IPs on the site where ISA is located.
Your setup should look like this:
Basically, what you need is to give ISA and the VPN router in the main office 2 distinct public IPs and put them parallel to each other. Then turn off the DHCP on the VPN router on the main office and make sure is on the same subnet as the internal LAN and connect it to the same switch as the SBS internal NIC. Configure the VPN link between the 2 sites as you would in a “normal” situation and make sure your VPN router is blocking all incoming traffic. As with any VPN the remote LAN must be on a different subnet.
Now, the last step would be to tell the local LAN how to find the remote one (since SBS is the default gateway the computers will try to use that one instead of the VPN router). To correct this we must create a static route on the server… so go and run the following command on the SBS box “route add -p 10.0.0.0 mask 255.255.255.0 192.168.16.3” and you should be good to go.
There could be other variations in this scheme, but if you understand the steps involved here then its easy to modify this to do whatever you want.