[cvsnt] Re: SSPI Problems
bo.berglund at telia.com
Fri Dec 30 08:20:21 GMT 2005
On Thu, 29 Dec 2005 19:45:22 -0500, "Bob Provencher"
<bob at aesirsoft.com> wrote:
>Is anyone else having problems with SSPI?
>We recently upgraded and now can not login to the server.
Upgraded from what to what???
>We use the :sspi:username:password at host form of the cvsroot, using a
>username and password on the server. When we do this the user is locked out
>after three tries (so we know we are getting to the correct account).
Lockout means that the password was not accepted by the server. It
also means that the server correctly identified the account to be
Have you doublechecked that the password used is *exactly* the same in
the CVS usage as on the server? Case sensitivity matters.
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
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!
>We're logging onto a server that is not part of a domain, from a client that
>is. The username and password on the client are the same as that on the
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 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!
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.
The crucial thing here is that your connect string must be specified
as I wrote above.
I will fire up my W2003 test server and prepare it with a new account
just to test if something has changed recently.
(Bo Berglund, developer in Sweden)
More information about the cvsnt