Listen...You Smell Something?

VSTS Setup and an Old Habit

A few months a go I had the pleasure of setting up Visual Studio Team Systems for a small team of people to evaluate. Along the way I picked up my old habit of writing down each step that was taken so I could reproduce exactly what I did. I thought it might be kind of fun to share my notes for setting up the Team Foundation(TF) server. I installed the TF server in a virtual server that was a guest on a Windows Server 2003 machine running Virtual Server. The TF server needed to be the TF server, the data tier, an Active Directory server for the test domain, and a VPN end point so the remote team members could connect. This is what my notes look like:

• *1 Install Server 2003 + Windows Update
• Assign Static IP 192.168.***.***
• *2 Install SP1
• Windows Update
• Install Active Directory (Typical first server install)    
  • TFDomain.local
  • Note: Installs DNS
  • Note: Installs DHCP
• Remove DHCP server
• Install IIS
• *3 WIndows Update
• Install SQL 2005
  • sa : *sa password*>
• *4 Create & Assign SQL Server Reporting Services Application Pool
• Install Sharepoint Services
• Windows Update
• Exclude SQL Server Reporting Services from Windows Sharepoint Services Management
• Setup Domain Users
  • TFSSetup      *password*
  • TFSService      *password*
  • TFSMike      *password*
  • Rest of team users
• *5 Create Domain User Group TFSAdmin
• Install Team Foundation Server
• Add TFSService to Namespace Admin
• Add TFSAdmin to Namespace Admin
• Reset SQL Analysis to 1 hour
• *6 Add TFSAdmin to Sharepoint Administrators
• Add VPN Role to server
  • IP range 192.168.***.*** - 192.168.***.***
• Enable Undo Disks
• Install ctl00... fix from http://www.amaxo.com/blog/archives/2005/05/eliminate_ctl00.html
• *7 Delete registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\VSSAccessControl
• Enable Undo Disks
• *8 Add clients to TFDomain.local domain
• Add registry key back to eliminate errors (see 3 steps up)
• Enable Undo Disks

The *[number] steps indicate where I took a copy of the virtual hard disk and saved it to a different location in case I needed to back up a step or 2.

The clients were all Virtual PC images running Windows XP Pro that I added to the domain and installed Visual Studio 2005 Team Suite Edition. The team members are able to log on to the Virtual PC image using the domain users I setup and then VPN to the TF server and use all of the Team functionality. Overall, it works pretty well. Of course since then Microsoft has released a Virtual PC image that has all of the comonents pre installed. It makes it a lot easier to play with VSTS but you don't get the feeling of accomplishment from getting this beast all setup and running for the team.

Now, doesn't that look fun?

Working without Admin rights

In my previous post I talked about how I started to work with a Limited User Account (LUA). I've found that as long as you have a couple of tools and a good idea of what is going on working without Administrative rights is not too bad. There are times that you need Administrative rights to get things done though. The most common for me is installing new software. The Program Files directory is a restricted area with read only rights for LUA users. To install software you have several choices:

1. Log out and then log on as Administrator and install the software
2. If you are not in a domain you can use Fast User Switching to leave your LUA acocunt logged in and still log in with an Administrative account to install the software
3. Temporarily make your account part of the Administrators group to install the software

The first 2 items are pretty self explanatory. The third item requires a little explaining. How do you temporarily add your account to the Administrators group? You can do it the hard way through the control panel or you can do it the easy way by downloading and running a script called MakeMeAdmin(complete description found on Aaron Margosis' Blog). When you run the script (after a little customization of user names of course) it will prompt you for the password for an Administrator account (or any account that has the right to add and remove users from the Administrators group) and then prompt for your LUA account password. If both of those are correct it will open a command prompt window (with a red background to warn that thsi command prompt has admin rights). Since processes gain the security rights of the process that launched them then anything you run from this command prompt has admin rights (Windows Explorer can be an exception. See this post for more information). Now you can install software without having to leave the confines of your LUA account. Pretty nifty (yes, I just said nifty).

There's one more tool that needs to be mentioned and that is PrivBar(Once again, complete information on Aaron Margosis' Blog). What PrivBar does is adds aother toolbar to Windows Explorer and Internet Explorer that shows what rights that instance has. If you don't install PrivBar and use MakeMeAdmin to launch a WIndows Explorer it is really easy to get the one with admin rights mixed up with ones that don't have admin rights. That is really the purpose of PrivBar: help you keep your windows straight.

The combination of MakeMeAdmin and PrivBar is a good start to being able to handle the tasks that require admin rights while still managing to spend the majority of your computer time without them. MakeMeAdmin is especially useful because you can combine it with a general knowledge of commands to do just about anything you can do from the Control Panel. The trick is knowing what to type at the command prompt to get the desired control panels applets (or whatever they are called) to come up. Here is a list of ones I find useful:

• Access.cpl - Accessibility
• appwiz.cpl - Add/Remove programs
• desk.cpl - display properties
• firewall.cpl - Windows firewall settings
• hdwwiz.cpl - Add hardware wizard
• inetcpl.cpl - Internet Explorer properties
• intl.cpl - Regional language settings
• joy.cpl - Game comtrollers
• main.cpl - mouse properties
• mmsys.cp, - Sounds and Audio device properties
• ncpa.cpl - Network connections
• netsetup.cpl - Network Setup Wizard
• nusrmgr.cpl - User Accounts
• odbccp32.cpl - ODBC Data source Admin
• powercfg.cpl - Power properties
• sysdm.cpl - System properties
• timedate.cpl - time and date properties
• wscui.cpl - Windows security center
• compmgmt.msc - Computer Management
• devmgmt.msc - Device Manager
• perfmon.msc - Performance monitor
• services.msc - Services
• secpol.msc - Local policy editor
• eventvwr.msc - Event Viewer

You've now got what you need to install and run most applications with a LUA account, but what about developing with Visual Studio and a LUA account? Turns out that it is not too difficult. There are a couple of tricks to write web applications, but for Windows Forms applications it is pretty straight forward. There is a nice write up on it here (it also presents more alternatives to what I've provided).

A Beginning with LUA

About a year ago I was reading something (blog, article, billboard, I don't know what) that was talking about running Windows XP as a Limited User Account (LUA) full time. This idea had been kicking around in the back of my noggin (very technical term for my brain) for a while and I decided it was time to give it a try. I wasn't sure of all the reasons (ok, none of the reasons(well maybe one reason but it was wrong)) why this was a good idea. I had just seen enough people refer to it as a Good Thing that I simply accepted it. I quickly jumped into Computer Management and removed myself from the Administrators group. That was easy. What's the big deal? My computer didn't suddenly stop working, no blue screen (ok, the background was blue but it wasn't the BSOD). I started launching some of the applications I use and they all seemed to work fine. So I started to work like I normally would.

I think I then found a demo of some application I wanted to try. What do you mean I don't have enough privileges to install this app!? Oh yeah, I'm not an admin anymore. Uh, what did I set the Administrator password to when I installed Windows 6 months ago? I eventually found (guessed) the Administrator password, logged in as Administrator, installed the application and everything was good again.

It was around this time that I found a blog on the subject that enlightened my poor dark soul. Aaron Margosis' blog was exactly what I needed to see. It was fixing problems for me before I even knew they were problems. More importantly it was giving me good reasons for running a LUA. The theory of Least Privilege and Zero Day Attacks were now dancing in my head (noggin). I started to look at what I do on the computer and break it down into 2 categories: works as LUA, does not work as LUA. The list looks something like this:

Works as LUA

Reading email

Browsing the internets

Writing software (I was not doing web development. Web development works but takes steps I had not taken yet)

Writing documents

Instant messaging

Playing games (this one surprised me)

Does not work as LUA

Installing software

Configuring the machine

Once I had that list I looked at where attacks usually happen: Email, browsing the web, software install(hidden with a benign application). Two of those three are on my works as LUA list. By running as LUA I can reduce the attack surface for 2 of the 3 areas where most attacks happen. If I prevent 1 single attack it is worth it (in my opinion(this whole thing is my opinion why do I feel the need to say that?)).

As a software developer there is another advantage to running as a LUA. The software you write is far more likely to work when it is run under an LUA. It will not be accidental that it works, you will have found problems earlier in the cycle and developers know that probelms found earlier are way easier to fix than problems found later. Oddly though, developers are the least likely to want to run with a LUA. They tend to think that they know enough about security to avoid all of the potential threats and that they are constantly doing 'advanced' stuff on their machines so they *need* to run with Administrator rights. They (we) do not need to run with Administrative privileges. It is not writing software as an LUA that drives me away from running as LUA all the time, it is poorly written software that refuses to work with limited privileges that drives me away. If the developers would write software as LUA they would fix their software and it would be that much easier.

I have more to say on this subject but I will stop now and continue another time.

Obligatory first post

Welcome to my blog. This is where I get to spout off about any ol' thing I please. I'm sure some of it will be useful and some of it will be rubbish. I'm making up all the rules as I go along so it should at least be interesting, entertaining or maybe a bit of both. Most of what I plan to blog about is the software and technologies that I'm curently playing with (right now that is Visual Studio Team Systems, SQL Server 2005 and Windows Vista (I know me and every other developer that can get their grubby little hands on this stuff)). I'll probably throw in a book/movie/CD opinion here and there too.

A little about me (very little): I've been working for Clarity Consulting for most of the past 6 years. That's enough about me for now.

Enjoy my little piece of the blogosphere.