The JammyBlog

One of the 'fun' things (I'll use that term loosely) in coming into a company 40 years into their existence is digging through all the inconsistencies, oddities, historical goodies and that favourtite of IT words "legacy" items that you can then try to reverse and steer toward best practices.

Almost a year ago I took over the Windows team, and still we're trying to turn the ship around on certain decisions that made sense at one time (NT 3?) but don't hold water anymore.

Dealing with assigning domain admin rights is one we're hitting on right now. Years ago, the decision was made that all helpdesk members should have Domain Admin rights. In fact, anyone who does any Windows desktop support was given Domain Admin rights. The other thing is that Admin rights were granted to the user's daily user account, and as there were multiple domains, the accounts were often duplicated between domains. Obviously this isn't good, but what we're working to design now is to setup a situation where we can limit those with Administrator rights to an absolute minimum, still allow helpdesk to reset passwords and manage accounts, and also to perform desktop troubleshooting and support on the company PCs. We also need to have separate admin accounts and user accounts, and prevent duplicating user accounts. Of course there's ways to do all of these things, but finding the right mix is a challenge.

The other trick of course, is to sell this to the IT teams so that they can still work effectively, and we're not introducing huge inconveniences or extra steps into their jobs.

This is such a common thing, I was sure I would find lots of good documentation out there on best practices and how-tos, but surprisingly that hasn't been the case. We're still in the design and testing phase, so I'll let you know what we come up with...

I suppose it's quite obvious at this point I'm not going to be a candidate for 'blog of the year'...nonetheless, I'll still take some time to update on things from time to time.

The biggest consumer of my time over the past 4 months has been a worldwide Lotus Notes email client upgrade that I'm project managing, as well as doing alot of the tech work on. Notes, you ask? Yes...I suppose that's a topic for another blog, but several years ago I fell into a position where part of my job was managing and supporting a Notes and Domino environment - this despite my relatively pure-Microsoft pedigree to that point.

I'm still working for a Domino shop, and as one of the people who knows the most about it, I'm acting as the manager for not only the global Windows team, but the messaging team as well. One significant change that came from this is to move our global Domino server infrastructure from Solaris to Windows 2003 Server. Your welcome, Microsoft.

I'm in Belgium as we speak...after spending two weeks in Manila in November to upgrade Asia, and upgrading North America in December, we're now upgrading Europe and Middle East, with one more week to go to hit our targets and fly home.

It's been fun - not without it's challenges, but a good project overall. I'm happy to say we're on schedule, on budget, and largely without incident as well.

Hmmm, what else is new...ah yes! I finally completed the additional certifications that I had been working on for some time. Last March I finished my RHCE, and then in October I passed my CISSP certification as well. So now I have MCSE, RHCE, and CISSP, as well as formerly having CCNA and MVP. Now that I've pretty much overqualified myself for the vast majority of jobs out there, I think I'd better quit while I'm ahead.

OK, so as I kinda suspected, I've been slipping on this here blog-thing. However; there's nothing more boring that reading someone blog about how they never have time to blog, so I'm not going to apologize, make excuses, or discuss it any further. I post when I post, and that's that! :)

Now, the thing that made me login to actually write something here is simply this: I HATE REBATES! I bloody hate them. They're horrible. They suck. They bite. They blow chunks.
Whichever marketing genius thought of the mail-in-rebate should be drawn, quartered, and fed to the ants. They are the absolute least-user-friendly, least customer-oriented things in existence. They're a pain in my behind and they get on my nerves.

And of course I'm not alone...no, do a quick search for 'i hate rebates', and in no time you'll find many like-minded people venting about the annoyance of rebates. Despite this, they only seem to be growing in popularity. I'm currently waiting on a rebate for my cell phone, and two rebates from RAM purchases. I just received a rebate rejection letter from something I bought before Christmas. Yes, it took 5 months to get the response back: rejected because 'not posted by the deadline'. Wrong! I posted it at least 2 weeks before the deadline.

If you want to cut the price. Just cut the price. And, if you really want to mail me a rebate, refund the tax as well. (15% in these parts!)

Sigh...still waiting for the backlash to begin. And when it does, they shall be first against the wall!

You see that tagline about being a low-tech guy? I'm really not kidding. Here's some proof: for the past four years I haven't had high-speed Internet at home. True story.

Now, there are reasons, of course. First off, I have two kids under the age of four, so home time generally means home time. Parking my butt in front of a computer after dinner would be a one-way ticket to Divorceville. Second, I live 4 minutes from work. If I really need to do something, I'll go and do it. Third, I'm generally pretty cheap. :)

So, things change (ie. my new company will pay for it) and I ordered a new 'Ultra' high-speed service at the house. It's great, almost 5Mbps downloads...sweet. What really hit home after the install was how much things have changed since the last time I had highspeed (2001).

This particular flavour of highspeed came with a free installation. I figured it would be pretty simple, but it's included, so what the hey. Our installer was a nice guy from a local cable puller. He seemed quite competent in installing cables and wall-jacks, but I had the distinct impression he didn't know a hub from a switch from a router. No bother, everything went well, and within no time I had scanned the instructions and started surfing. It took me at least a full minute before that nagging voice hit me - 'hey - you're surfing unprotected on a public IP!'. Woah! Caught up in the euphoria, I forgot the most basic of security basics. After all, this PC had been living a quiet and isolated life...he wasn't ready for the big city!

So - what tools does a cheap guy like myself use for safe surfing? Well, I made a few stops. First, ZoneLabs for a copy of the Zone Alarm personal firewall. Next, Windows Update for the newest patches. Third, Grisoft for the AVG free virus scanner. Google for the pop-up blocker, and lastly back to Micrsoft for the Anti-Spyware beta.

I felt considerably safer now, but it didn't take long to see what a hassle this is for home users. Unfortunately, most of these tools are still not at the right level of user-friendliness for most home users. The Anti-Spyware tool pops up with a warning: services.exe is trying to access the Internet...hmmm...guess I'd better allow that just in case. And so on. Despite my best intentions, I still think our computer is quite vulnerable, simply because most people using it are just going to 'allow' on any warning that happens to pop up. It's human nature...you're not sure what the message means, you don't want to break anything, you assume that there's no problems, and presto you're whacked with Spyware or a virus, or whatever.

It also really stuns me what little responsibilty the ISP takes in all this. They're unleashing thousands of unprotected surfers at 5Mbps without so much as a 'be careful'. It's like handing the school bus keys to the town drunk and not even checking if he has a license. Accident Waiting to Happen (tm)

I'd really like to see some stats on the infection rates and malware propagation rates of corporate users vs. home users. As IT professionals we put complex and well-crafted means in place to keep our users safe, while home users are spreading email worms and launching DDoS attacks willy-nilly. It boggles my mind that a worm like MyDoom can cause so much damage, and yet the prevention was completely 'computers 101' - "Don't launch the attachment".

It seems to me that two things have to happen - ISPs need to take more responsibility. I don't think that they should begin restricting their customers actions, but they should at the very least provide some guidance, some training, and some suggested free software to use. They should also all offer optional malware scanning, at no extra cost.

On the flipside, I think that software vendors need to work to make their tools as easy as possible, and as self-exaplanatory as possible. I'm hopefull that in future my personal firewall won't tell me that services.exe is accessing 123.4.56.7:DNS, but rather will explain that my PC is making an outbound DNS request to my configured DNS server.

I remember helping my first company setup it's Internet connection. We had a whole Class C to oursleves, and we all surfed on public IPs with no firewall. A simpler time perhaps...but unfortunately long gone and not likely to return. In the meantime, we all need to step up and be vigilent.

I've been thinking alot about WINS and browsing these days...

Now, before you start calling Dr. Phil to schedule my first appointment, let me just say that I've actually had *reason* to think about WINS and browsing...

For one, I visit experts-exchange.com semi-regularly, and try to help people out with questions they post there. Inevitably, at least once a day, someone will submit a post which essentially says "blah blah blah, server X can't see server y, blah blah", and I think to myself...browsing again. Inevitably I post a response saying "use WINS". Sometimes I take the time to explain *why* to use WINS, sometimes not. If there's one thing that I've found WINS is good at, it's helping people browse. That said, I'm finding it less and less useful for anything else these days. In fact, I would go so far as to say that except for browsing (which I don't particularly care about anyway), WINS is useless. Yes, I'm calling for it - Death to WINS!

Most of you probably know the story behind all this stuff and how WINS came to be, right? The Coles Notes version is that the essense of what we know as "Windows Networking" was designed and developed circa Windows for Workgroups - and as such, it was made to work in small, peer-to-peer networks that did not span subnets. In that capacity, it worked great - every PC tells every other PC about themselves, and presto, we can all share things and connect to each other's PC in a NetBIOS utopia. Unfortunately, when Microsoft decided to move into the "Enterprise", not-peer-to-peer, more-than-one-subnet arena (think Windows NT), rather than completely scrapping Microsoft Networking and recreating it from scratch, they essentially tried to drag it along and implement workarounds (I'll call them kludges) so that things will still function as they did in that small-network world. Now, some MS developers may bristle at my use of the name kludge, but hey, I'm calling it like I see it. WINS, my friends, is one of those kludges. The fact is that NetBIOS browsing wouldn't work in a multi-subnet environment, so something had to be introduced to make it work, and that something was WINS. WINS allowed NetBIOS name lookups and browsing to span subnets by using client-server and server-to-server calls rather than only broadcasts to do the job. That was great, but of course browsing was still a sick and twisted labyrinth that only two people in the world actually fully understood. OK, I'm being harsh, I'll tackle browsing another day. Oh yes, one of those people (and another impetus for these blogs) is here.

OK, so we have an idea as to why WINS came about, now I'll get to why I think it should (and inevitably will) go away. Again, for the uninitiated, WINS is essentially a database of names and IP addresses. WINS clients query for a name, and the WINS server responds back with the address. The database is dynamically built via registrations that WINS clients sends to the server whenever they start or stop network services. As an aside, acting as a Master Browser or Domain Master Browser is one of those things that gets registered with the WINS server, and *that* is how a Master Browser from one subnet can find a Master Browser from another subnet. The real benefit to WINS in those days was the fact that it was dynamic. We had a different name-lookup service available (DNS), but of course at the time it would have required entering static host records for each and every PC - and either assigning static IP addresses, or setting DHCP reservations for every PC. As you can see, WINS truly was necessary - it was the only name-lookup service that allowed us to use DHCP and didn't require manual upkeep. That was then.

When information started coming out about Windows 2000 and what Active Directory would involve, the deal I heard was that NetBIOS would be gone. This is what I expected - no more NetBIOS names, no more WINS, nada. Obviously I wasn't travelling in the right circles at the time, because as you know, WINS is still alive and well. The problem is, what Windows 2000 did do is to render WINS virtually obsolete by introducing Dynamic DNS.

Now, for the past 5 years we've been living in a world where most organizations are managing and maintaining two parallel and virtually identical network services. Double the admin, double the network traffic, double everything. Show of hands: how many are running both DNS and WINS in your Windows environment? That's what I thought. Do you add static hosts records to both databases? Do you scavenge and backup both databases? Do you configure replication between servers for both services? It's ridiculous really...I'm in a pure Windows 2000/2003 environment - I shouldn't need WINS at all, yet I'm still running it. Why? Browsing. Right now, in a global organization of over 2000 users, we are running a collection of replicating WINS servers for the sole purpose of allowing each and everybody to click and see each and everybody else. Now, in my opinion this is definitely not worth it, but I'll talk about browsing in a later post.

So - in a post NT4, Active-Directory environment, there's really nothing that I need WINS for that DNS can't provide *except* for browsing. The obvious solution to move toward a truly NetBIOS-free world is for Microsoft to implement some equivalent to the functionality of browsing, but using DNS to do it. If you look in 'Entire Network' in 'My Network Places' (it'll always be the Neighbourhood to me...) you'll see "Microsoft Windows Networks" and "Directory". "Microsoft Windows Networks" does not use DNS - this is only populated in a multi-subnet environment by using WINS (or forcing your Master Browsers and adding LMHOSTS entries - but we won't really count that). "Directory" only lets me browse my Domain, and not any other domains that I may or may not trust. Ergo, I still really do need WINS for browsing, but DNS can and is handling everything else for me. Since there are also a number of Linux and Solaris machines on the network, one could even argue that DNS is doing a better job that WINS ever could, just for platform integration reasons alone.

Now - this long-held belief that WINS is useless was very recently shaken by the discovery of this. Unbelievably, Exchange 2000 and Exchange 2003 both *require* WINS for certain functionality to work. That truly blew my mind, and in my opinion can only be considered a flaw in Exchange. Now, we use a competing product instead of Exchange, so this is something I never would have experienced first hand if I didn't come across a link to it somewhere.

I will be participating in an Microsoft Networking MVP-only discussion this week about future networking directions in Longhorn. While I may not be privy to share some of that information here, I'm anxious to here what's in store.

Over the next while we will all start learning more and more about Longhorn and what networking features it will bring. I for one will be watching with a very interested eye any changes to the role that NetBIOS plays in a Mircrosoft network. I look forward to the day when DNS is the one and only name-lookup service we have to deal with, and we truly can say goodbye to WINS!

Much like CityTV, blogs, and Paris Hilton, wireless is everywhere...

It seems like everywhere I go, companies have deployed wireless networks. And why not? Given the incredible freedom and convenience wireless give the user, this by itself is not particularly suprising. What *is* surprising, however, is how many companies deploy insecure wireless networks.

My guess is that these wireless networks all came about the same way that mine did: end-user driven, and driven from above. I still remember the day my CEO came by my desk and told me that he really wanted us to have wireless access in his office and our boardroom. Hmmm, I thought...this could be interesting. The news was stuffed with warnings about the inherent insecurity of wireless networks...but the message was clear: make it so.

I dove into researching just how I could deploy something that wouldn't completely compromise all of our internal security measures. Given that this was over 2 years ago, my options were fewer than they are today. I was soon lost in a jungle of whitepapers and articles about 802.11a,b,g,i,x,WEP,WPA, and so on. There was news of new and emerging standards that *would* be secure, but of course none of the WAPs on the market would support them, the existing wireless cards wouldn't support them, the existing O/S's wouldn't support them, and oh yes, did I mention there wasn't really any budget for this project? Yeah.

The typical wireless security advice of the day was the sort of thing found here. Not exactly ispiring confidence when they tell you to use WEP, and then admit that's easily crackable in the same sentence. Nowadays, tools like aircrack make WEP even less useful than it was back then. About the best security tip I found was to combine WEP with limiting access by MAC address. This, of course, required pre-loading the MAC address of every wireless card into the WAP, and then maintaining this list for time eternal. I'd prefer the root canal, thanks.

Realizing that my chances of finding a technical panacea were slim, I forged on. Thinking outside of the box (as they say), I started thinking about other ways to secure our insecure wireless traffic. Inspired by articles like this one from Colubris Networksand this one from isaserver.org, I set about designing a deployment that would use our existing firewall and VPN to add security to our wireless LAN.

Part one was to treat wireless clients as hostile. And so, our comsumer-grade LinkSys was installed into the DMZ. Oh yes, with WEP enabled. (hey, it won't hurt!) Next up, give users a known isolated IP address. My WEP didn't do DHCP, so I configured a DHCP server on the firewall, and created a small scope of addresses to assign to the wireless clients. At this point, the firewall restricted any wireless client from accessing the Internet, and from access the LAN. Not only did I not want any corporate espionage, I also didn't want pimply-faced kids surfin porn on my dime! Perfect! Hack away! Oh wait, one more thing - give 'real' users access! (Darn those pesky users again...) I added a DMZ rule on the firewall, allowing only the wireless client range to only access the external interface of our VPN device, and only on TCP port 10000 - the port used for transparent tunneling of our 168-bit IPSec tunnels. And there it was...user friendly enough, secure enough, and pretty much free. The other nice thing was that since I wasn't using 'wireless' technology for the security, there was no concern about compatability with wlan cards, or with keeping up with standards as they change - the solution would hold up over time.

Interestingly, my new organization is currently in the early stages of looking at a corporate, global wireless implementation. This time, there's some better answers to the wireless security question. Some of those 'emerging standards' are now incorporated in real products, and supported by OS updates in Windows as well. Embarking on this project again, I still find that it's difficult to find one place that really describes all of the security options concisely. A few Google searches, and you'll have a ton of material to sift through. That said, this seems like a decent place to start.

This time around, instead of WEP, I'll be looking at 802.11i, WPA, and 802.1x. 802.11i is the complete reworking of wireless security to replace the faulty WEP. It's not fully available yet, but WPA is. WPA is a subset of the 802.11i fuctionality, meant as a stop-gap while the full standard crawls forward. 802.1x is actually just a means of authentication, which has been incorporated in both WPA and 802.11i.

Unfortunately, even as we stand here in early 2005, 802.1x has just been incorporated in a recent Microsoft update for XP and Server 2003, and in checking the LinkSys site, I see that none of their WAPs support WPA. Upgrade to the Cisco offerings, and WPA is there. Now...how many different brands and models of WLAN cards do I have? (gulp!) As an aside, the May 2004 issue of Windows & .Net Magazine featured a nice article on securing wireless authentication using 802.1x.

Dealing with a changing standards is always aiming at a moving target. There's bound to be incompatabilities along the way, so make sure that you test everything out before dropping a lot of money, and prepare yourself for newer and better stuff to be coming down the line. On a positive note, WPA is promising to be forward-compatible with 802.11i down the road.

Wireless security is no doubt a bumpy road, but the way is looking clearer all the time! Happy surfing...

Wouldn't you be amazed to find a robust, full-featured piece of software that was easy to deploy, saved you hundreds of hours, and - wait for it - was free?

Well, that's exactly what happened to me this year when I found SUS. Since then, I've become it's biggest fan, and decided to sing its praises here.

Oh wait, did I mention it's made by Microsoft?

Many of you by now have likely heard about 'Software Update Services' (SUS), but 9 months ago, I felt like I'd stumbled upon a pearl in my baththub. (hmm...bad analogy?)
Anyway, what sparked my search for a patching solution was the outbreak of Sasser. You may recall that this was one of those nasty worms that didn't require any user action, it just infected any unpatched Windows 2000 or XP machines that it could find. (Dastardly! I much prefer the ones where you at least have to be dumb enough to launch the attachment!)
Despite some confidence that my firewall would keep any outside machines from starting an outbreak, the potential threat of travelling users and home VPN connections left me facing the thought of patching >150 machines by hand. Not a large number of machines perhaps, but still not something I was looking forward to. (aside: Why is it that a non-administrator can't run Windows Update on a Win2K machine? Somehow that just seems to contradict the security push...)

And so I embarked on a search for a free, automated patch management tool, and stumbled across a SUS reference in a newsgroup somewhere.

Using a combination of Microsoft's SUS site and susserver.com, I was able to get this up and running within a day.

What's good about SUS:
1) Simple deployment via Group Policy (ok, for those of you without Active Directory, you'll have to distribute registry changes some other way.
2) Ability to 'Approve' updates. Updates are not deployed to my clients until I say so. Nice way to do some testing and avoid problem patches (came in handy while testing XP SP2!)
3)Minimized WAN traffic, due to single download point.
4)Low maintenance, easy administration.

What's lacking in SUS:
1) Directed updates - currently, all approved updates go to all clients of the SUS server, there's no finer control.
2) Reporting - There's no 'nice' built-in tool for confirming exactly which updates have been installed by which client. You'd have to run MS Baseline Analyzer or some other tool against a client to verify the updates. You *can* upload your IIS logs and get them analyzed here. Or download the add-on tool created by Wayne Flynn and create your own reports.
3) Ability to deploy more than just Windows updates. SUS will only do Windows updates and Service Packs. No SQL Server updates, no Office updates, etc.

All in all, SUS has served me well, and I can't wait for WUS. I'm currently playing with the beta, and although I'm still not quite *there* with it, I'm happy to report that it seems to address all three of the shortcomings listed above.

Between this and the new anti-spyware beta, I don't think anyone can say that Microsoft isn't stepping up to the plate to make securing their software easier.