In Bath? Not disabling your Bluetooth when you don't need it? You may have been under surveillance..

I was going to go with "technologically raped", but that's a bit sensationalist. Granted I'm probably going a bit over the top, but it looks like some researchers from the University of Bath, my home town, were let loose with various bluetooth tools and equipment. The aim of their research was to do some basic modelling and proof of concept work - mapping interactions, using bluetooth.

Astonishingly they captured 10,000 unique devices (supposedly) over 6 months, from various locations. Including "the pub", which appears unnamed. Now whilst I usually disable my bluetooth when I'm not using it (one, because the battery life on my k800i is slowy going the way of the electron fairies, and two because I don't want stuff like this happening, or my phone being subjected to anything that it shouldn't), it makes me wonder if the people who were being tracked were informed. Granted it's interesting work nonetheless, although the fact that they used a pub strikes me as a good excuse for other activities; "Err... yes we're in the pub. But don't worry, it's all in the name of science!"

However this could serve as a practical wake up call for those who object to lack of privacy but aren't technologically aware.

Automagically configuring Wyse thin clients running "blazer"

It's probably no secret to some people who read this that I do a fair bit of work with terminal servers and thin clients (dumb, low power machines that connect to a terminal or citrix server). However, most deployments I've been involved with at work at relatively small, our largest of which has recently gone up to a load balanced set of 5 Windows Terminal Servers, a few weekends ago.

In the past we've always manually configured the thin clients, as they've always been rolled out over a long period, typically in very small quanities (no more than one or two); slowly replacing aging computers. However, this project is effectively a new cluster of terminal servers (replacing some aging hardware it was decided that it would be a good opportunity to do things properly). Personally I didn't really like the prospect of going to each one in the building and manually fixing the config, or using a CNAME in the local DNS, as many probably need firmware updating and altering in other ways to bring them inline with the rest.

In the past I knew that the Wyse S10's (which is the model we've mostly got deployed with this client) were administratively configurable (by this I mean en-mass from a single point, á la group policy), but I had never really gone hunting for some decent docs until three-four weeks ago.

I stumbled across freewysemonkeys.com, an absolute gold mine of documentation for anything Wyse thin client related without having to wade through all the other "user guides" from Wyse themselves. Whilst the docs weren't always 100% accurate for our model they did give me enough of a leg up to get everything we needed working perfectly on all but the oldest S10's (unfortunately getting a firmware update from Wyse currently requires a support contract, according to their site).

A few days prior to this project I had tested it on another, much smaller client, as I was on-site virtualising part of their systems, and it worked awesomely well. Based on the configuration we will now beable to tell if a thin client has a proper network connection by simply asking what colour the background of the thin client is, setup various remote connections, wallpapers and icons, automatically reflash the firmware if there's a newer version available, etc. all of which is picked from some basic DHCP scope options and a FTP server.

There are other solutions for the various thin client's out there, so if you're still manually configuring stuff by hand before shipping out to a customer, I recommend investigating for your chosen make and model, no matter how small your deployment is. It'll make your life as an administrator, and the life of your users, much easier.

Never doubt yourself

One of the users for the client that I mentioned in my last post works from home a fair bit, using a site-to-site IPSec tunnel that was setup a number of weeks ago, and a MacBook Pro running Leopard. As the rest of this client's network is Windows based we hadn't really considered restricting the Mac at all. After all this user is relatively clued up.. Or so I thought.

Tuesday we were told that the user was unable to access various resources on the LAN in the office. This was very odd as we could talk to the only other device on her subnet, which was her IP hard phone, without any problems. Even stranger her IP hard phone was working. We took her through the usual tests and everything seemed to be ok. I then incorrectly assumed that something had happened as part of the upgrade. The problem was this just didn't make sense. If something had happened her IP phone wouldn't work either. The lack of another machine at the tunnel end really hampered testing.

Much faffing and testing we come to the conclusion that it's truly just her Macbook Pro. Further investigation reveals that PeerGuardian for OSX had been installed - which by default blocks almost all traffic. The moral is if something stops working, even if you know that you've changed something recently and you knew what you were doing properly, don't waste too much time trying to figure out what you've done. Take a break and find out if it's someone else's fault first. If it still doesn't make sense then it probably is you've caused.

I guess it's a week of thoughts rather than technical stuff.

Best laid plans gang aft agley

No matter how much you prepare, no matter how much work you put in beforehand, no matter what you do you cannot always have everything covered. This weekend myself, Dave and Chris were on-site performing an upgrade for a customer (several server upgrades, some new hardware, some switching of roles, upgrade to Exchange 2007 from Exchange 2003, replication of Exchange using SCR, file replication using DFS, implementation of a load balanced terminal server cluster, etc.). It was quite significant to say the least. Luckily we had done a lot of prep work beforehand so that we didn't have to do as much; Everything from new OU structure to new group policies for software deployment, to the virtual servers already being built and ready to be added to the domain.

Sadly several things bit us in the arse; Several GPO settings aren't accessible from a 2008 server that were available on a 2003 server (I'm specifically thinking the 2003 R2 Printer Deployment - no matter what we did existing settings wouldn't actually show up), an older server we wanted to use as the virtual server host was playing up when we moved the virtual servers to it, which resulted in a complete change of plan, the virtual domain controller idea was binned at the main office end, and the idea of using a small virtualised 2008 server for the print server wasn't 100% successful thanks to an older Toshiba Studio 311C that we had forgotten about, and some barcode printers. The ISA 2004 to 2006 upgrade went like a dream, however (don't ask).

Despite this when users came in this morning we had few problems - some issues with some of the accountancy software, some issues with printers not being set as the default (which their invoice/despatch note formatting software uses), and weirdly some users picking up old polcies that just wouldn't die until the the profile was binned (thank you file and settings transfer, you did save me some time there). When you consider that there was almost no reasonable chance of going back to how things were originally in a reasonable time-frame, and that that the margin for error was obviously so small, it's impressive just how well things went despite the changes in the original plan.

It also goes to show that even if you have to bin several days of preparation and planning that still pays off regardless. Constant testing with users through out at each suitable stage is key, no matter how much of a pain in the arse it is. Our plans for smaller customers tend to be a bit thin on the ground, but this is usually because it's the same old routine over and over again. Whilst this means we know what we're doing it does mean that we could get a bit complacent; having a new, more interesting, larger project like this certainly reminded me a lot about the importance of a good plan, good prep work, and being paranoid (to a certain extent).

MS ISA Server 2004 to Draytek Vigor 2800 IPSec Tunnel

A few weeks ago I had to setup my first IPSec tunnel between ISA 2004 and a non-Windows device, in this case a Draytek Vigor 2800, to create a site-to-site VPN. I had a few things that I hit on the Draytek which stumped me for a little bit (although probably could've been resolved much more quickly had I been more familiar with a Draytek Vigor I fear).

First thing I did was to head into the ISA console and setup an IPSec tunnel, using almost all of the defaults (this is important as the settings for the Draytek must match the ISA/Windows defaults). If you're not familiar with ISA, then the process is roughly as follows;

  1. Under VPN and then Remote Sites, hit "Add a remote site network" under tasks.
  2. Select IPSec tunnel, bung in the external IP of the draytek for the "Remote VPN gateway IP address" and selected the external IP for the local gateway (what you'd probably refer to as the end points if you were doing this in anything else), add the authentication (either PSK or cert. - in this example I'll use a PSK, although you might want to think about using a certificate once you've tested it with a PSK), added the remote address subnet and then pretty much followed the defaults.
  3. Apply this and then head to Configuration > Networks, Network Rules. Create a new Network Rule from our internal subnet into the remote network to route, not NAT.
  4. Apply this, and then head to the Firewall Policy and created a couple of rules to allow the traffic we wanted the remote subnet and the internal to send and receive. Apply again and you're done.

The Vigor then needs to be configured, to match the ISA server;

  1. Head to VPN and Remote Access > Remote Access Control, and enabled the IPSec VPN Service (this is what had caught me out - some how I'd managed to miss this completely!).
  2. Under IPSec General Setup, untick Medium (AH), tick all the items next to High (ESP).
  3. Next go to VPN and Remote Access > LAN to LAN. Select the first free profile (probably 1) and set it up as follows:
    • Common Settings Set the Profile Name to anything you like, its just a name - I used the same name that I gave the network in ISA. Tick "Enable this profile" and select both for Call Direction.
    • Dial-Out Settings Select IPSec tunnel, set the "Server IP/Host Name for VPN" to the external IP of your ISA server (or whatever you selected in your IPSec tunnel setup in ISA). Set the IKE Pre-Shared Key to the same as in ISA, or if you used a certificate set the Digital Signature. Under IPSec Security Method set "High (ESP) 3DES with Authentication". Click advanced to open a new window and check "Main mode", set IKE phase 1 proposal to 3DES_SHA1_G2, IKE phase 2 proposal to 3DES_SHA1/DES_MD5, IKE phase 1 key lifetime to 28800, IKE phase 2 key lifetime to 3600 and enable PFS and click ok.
    • TCP/IP Network Settings Set the WAN IP and the Remote Gateway IP to 0.0.0.0. Set the Remote Network IP to your internal subnet host address, and the Remote Network Mask to your internal subnet mask (by internal I mean the subnet protected by ISA). Disable RIP (unless you want to use it), and set the NAT operation to Private IP. We didn't need to set this as the default route, this is obviously your own design decision.

You should now be good to go, and your Vigor and ISA box will negotiate and encrypt all traffic that travels between the 2 subnets, as it should. To check on the Vigor you can head to connection management and check out whether or not the tunnel is currently up, and that it's encrypted.

There are various reasons for opting for an IPSec tunnel, however the major one is that it's one of the easier tunnels that can be created, and are secure. You could of course opt for a site-to-site PPTP, or L2TP/IPSec, VPN. However these come with their own complications and security issues.

If the Vigor 2800 is anything to go by, I'd say that the Draytek routers are a nice bit of kit which work well for SOHO deployments, although there are a number of things in the GUI which really started to cheese me off after a while. There's no denying that they're not as flexible as other solutions, but they're no where near as simple as other routers which you could use. I'm still not entirely convinced that they're the perfect solution, although Chris has fallen in love with them, but at the end of the day for this sort of job you're rarely going to be touching them once they're up and working, so the cost savings over an equivilent Cisco box may pay off at the end of the day.