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.