[cvsnt] More on authentication problems with build 2048 and up...

Bo Berglund bo.berglund at telia.com
Fri Aug 12 00:08:57 BST 2005

now I have received a compoletely new PC so I can install stuff from
the bottom up. :-)
I installed CVSNT using my Innosetup installer.
I installed the latest WinCvs available today at SF.

Then I copied my whole work folder from the old PC to the new one
including all CVS metadata.

Next I opened a VPN channel to the office network where we have a
CVSNT server running since years. It is now at version 2.0.38. Here I
tried this:

1) in a sandbox with CVSROOT=:sspi:cvsserver:/PC I went ahead and
issued a graph command from WinCvs to verify my connection. This
succeeded immediately.

2) in a sandbox with CVSROOT=:sspi:bosse at cvsserver:/PC i first tried
the log command but of course it failed because I have not yet logged
in to the cvs server on this new PC. So I typed cvs login in the
WinCvs command window. After entering my password I received this
cvs login
Logging in to :sspi:bosse at cvsserver:2401:/PC
[80090311] No authority could be contacted for authentication.

3) Now I extracted the files from the 2.0.51d binaries zipfile I had
saved into a new directory and pointed WinCvs to use this cvs.exe.
Then my cvs login command succeeded and afterwards I could do all the
stuff like graphing etc in this sandbox.

4) Then I switched WinCvs back to use the cvsnt build 2054 I had
previously installed and tested operations on the bosse at cvsserver
sandbox. But I was again treated to the infamous message:
cvs log -- AGIAdmin.cfg (in directory
[80090311] No authority could be contacted for authentication.

Finally I decided to narrow down where this behaviour started so I
extracted a number of binary packages and redirected WinCvs to these
The result I now have is that is the latest cvs.exe that I
have access to which does work properly, the next one (build 2048) has
this problem.

So this shows that somehow the client operations done by the new
builds cause a sspi authentication error if the CVSROOT is of the form
:sspi:user at server:/repo, but succeeds with :sspi:server:/repo
In the latter case I assume that the same authorisation server is used
(the PDC of the office network)? That is a Windows 2000 server with
Active Directory. My local PC is not connected to the domain, it is a
Workgroup PC, but I have the same login here as I have on the domain.

And whatever was done to break this was done between builds 2040 and

Any ideas?

(Bo Berglund, developer in Sweden)

More information about the cvsnt mailing list