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 Fri, 30 Dec 2005 16:52:46 -0500, "Bob Provencher" <bob at aesirsoft.com> wrote: > >>> 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. That is handled by specifying the CVSROOT string as: :sspi:user at server:/repo and doing a cvs login (once only!). After this has been done the credentials (CVSROOT and encrypted password) are stored in the HKCU part of the Registry, which is only accessible by the user logged on at the moment. If another user logs on to the Workstation he will get a different registry hive where this is not present. The next time a cvs operation refrences the *same* CVSROOT the password will be read (by cvs.exe clientside) from the registry and used in the negotiations with the server. This is fully transparent to the user. > >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? Sandbox == Checked out source folder and files hierarchy it exists on the client computer in the file system. Metadata == the files in the hidden CVS subfolder in all sandbox folders. These files will be visible in Windows Explorer if it is set to show hidden files (which I *always* set mine to do. Specifically the CVS/Root file will contain an exact replica of the connection string *including* the password if used like you suggested. Anyone with access to the client computer can read the user and password from this file. However, since you have failed to check out anything you have not yet gotten these files. I merely wanted to point out a potential security risk to you up front.... > >>> 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. What key? I did not mention the key did I? Here it is: HKEY_CURRENT_USER\Software\cvsnt\cvspass But it is no use trying to manipulate it manually, cvs handles it automatically..... > >>> 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. Login in CVS is a special command. It is used to communicate the user/password combination for protocols that need it. These include pserver, sserver and the user at server version of sspi. CVS Login is not a persistent connection as you might have with other kinds of systems since cvs is sessionless. It merely establishes that a certain set of credentials are valid and then stores them for later use. You can do either one of these commands on a command prompt to get the same result: cvs -d :sspi:user at server:/Repo login or set CVSROOT=:sspi:user at server:/Repo cvs login In both cases you will have to enter the password and then it is evaluated. Successful evaluation leads to saving it in the registry. > >>> 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. What I want to point out is that if you use a CVS server that is not part of a domain and it receives a call through TCP port 2401 to its server, then it has no choice than to do authentication to its own database since it does not know about the domain, right? And if that user exists in its database and the password evaluates then it will accept the call. But in so doing the username must be properly formatted and in such a case we are discussing here a simple "user" will be enough of a specification. > >>> 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. This has "always" worked for me! I have used such a setup on some of my servers since the :ntserver: protocol was ditched several years ago. No news here, and it is still working well. And I have CVS repositories on all kinds of servers (NT4, W2K-Pro, W2K-Server, XP-Pro, W2003 Enterprise Server) attached to domains and running on workgroups. All work fine! Please have a look here and see if you have missed something in your setup: http://web.telia.com/~u86216177/InstallCVSNT25.html /Bo (Bo Berglund, developer in Sweden)