[cvsnt] Re: SSPI Problems

Bob Provencher bob at aesirsoft.com
Fri Dec 30 21:52:46 GMT 2005

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

>> Have you doublechecked that the password used is *exactly* the same in
the CVS usage as on the server? Case sensitivity matters.<<

Yes, I have, numerous times.

>> But then, why are you putting the password into the connect string in
the first place? It will break your security if you do this!
All sandbox metadata will now have the password in cleartext for all
to see!!!!!<<

Well, interestingly enough we did not invent this, but simply used what
appeared to be the correct syntax that we found on the internet.  We didn't
find a heck of a lot of documentation for how to use SSPI.  Since the server
is not in the domain of the client computer it would stand to reason you
would have to provide the login credentials, as the currently logged on user
would not be the correct account.

Also, your statement about clear-text concerns me.  I was unable to find the
username/password combination anywhere in the repository.  What do you mean
about the sandbox metadata?  Do you mean in the various client side files?

>> I have used SSPI many times with a different username from that which
I am logged on as and it always worked just fine with this syntax:

  :sspi:user at server:/repo  (note that there is no password here!)

Then the correct procedure is to log in *once only*:
  cvs login  (enter password)

Now the password is cached in encrypted form by CVSNT in the HKCU part
of the Registry and is therefore safe from other users. And it will be
used by CVSNT every time it accesses the same CVSROOT.
No need to put the password into the string! <<

I'll look into that key, that may have something to do with the issue.

>> You are *not* logging in, at least not according to your description!
You are instead sending a hardcoded (and cleartext) password as part
of the connect string! <<

I'm not sure what your point is here.  The action we were doing was a login,
which failed.  Are you saying it is not a login since it failed?  I'm not
interested in semantic arguments, I simply want the problem solved.

>> I never tried having a non-domain server on a network with a domain,
but I don't think that will matter at all. The server will get a
connection request from the client and it will receive the password as
part of the process. Since it does not know about any domain there is
nowhere else to look for authentication than in its own user database,
which is what you wanted from the start, right? So the talk about
domains is moot here! <<

Well, I'm pretty experienced at developing for NT security and Active
Directory.  Domains are very relevant when talking about logins.  I don't
think LSA simply looks in it's own user database for an account with the
same username/password as the incoming one.

>> In fact I have many times used a laptop where I am logged in to a
domain account and then used the above syntax to connect to a CVS
server that is not part of that domain and it works just fine. In fact
in these cases I also had the same account name/password on the domain
and on the server with no problems whatever. <<

That's good to know.  We were also able to do this with the syntax we told
you prior to our recent upgrade.  Knowing that it works in later releases is
good information.  We just have to figure out what is wrong about our
environment or connect string.

>> The crucial thing here is that your connect string must be specified
as I wrote above.  <<

We have tried that, but will keep investigating.

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook