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.
On Thu, 29 Dec 2005 19:45:22 -0500, "Bob Provencher" <bob at aesirsoft.com> wrote: >Is anyone else having problems with SSPI? Probably not... > >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 used. 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 to see!!!!! 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 >domain. 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 (Bo Berglund, developer in Sweden)