Scott Hanselman

I recently moved a machine from our MAIN domain to a LAB domain (another domain with a hardened filewall for R&D and crazy stuff.)

We use Subversion for most of our Source Control, but a lot of legacy stuff is still in CVS and uses SSPI (Security Service Provider Interface enabling NTLM for CVS). So, when I do an update from Tortoise it automatically sends my Windows User details over there and authenticates me against the domain.

However, now I'd moved the machine and it was in another domain. The LAB domain is fairly harded and doesn't have a way for a MAIN domain user to login. Consequently updating CVS via SSPI is/was a problem.

I wrote a lame little batch file that's used like this:

addcvsuser.bat MYREPO labcvsuser

It looks like this:

IF "%1"=="" GOTO USAGE
IF "%2"=="" GOTO USAGE
SET CVSROOT=:sspi:MYCVSSERVERNAME:/%1
cvs passwd -a -r MAIN\somewindowsuser %2
SET CVSROOT=
GOTO EXIT
:USAGE
ECHO Usage: addcvsuser REPOSITORY NEWUSERNAME
:EXIT

Assuming the admin is logged in as a legit user, this file temporarily sets the CVSROOT Environment Variable with the name of the Repository you want to add a user to. The user will be added to the passwd file in that repository and won't be a real Windows User. It might be a user named labcvsuser that doesn't exist on the domain. That user is mapped to MYCVSSERVERNAME\somewindowsuser that IS a real Windows User, on the real MAIN domain.

Then, in Tortoise I change the CVSROOT used by Tortoise to :pserver: instead of :sspi: and open up ports 2401 and 2402. Now the LAB TortoiseCVS can use a username/password combo that's not on the domain and get mapped to a domain (or local) user and crisis averted.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By