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.
Hi Glen.
> Sounds like too many variables -- spin them down and you'll get to the
> solution. (OK, so that much is obvious).
:-)) Ok... tried my best :-))) Thanks for the tips...
> -- Figure out exactly what username(s) is|are being used. Check the
> server security audit log when the machines connect, that will tell you
> exactly which credentials are being used.
Ok. Tested it again using 'cvs -d :sspi:server:/repository ver'.
On two machines that works ok and connects as the user
remembered by Windows and not the local user.
On the problematic machine it ignored the user information
remembered by Windows and attempts to log in as the local user.
> -- Check the registry for cvs login password cache, and experiment with
> removing those.
Cleared all of those before.
> -- Check the machines connecting to the CVS server using a separate file
> share, not just with CVS. The Windows authentication should (in theory)
> be the same process as SSPI but CVS will be out of the loop so you can
> potentially eliminate it as the problem.
Rechecked this with server side auditing turned on and it works as
expected on all PCs, i.e. all log in with user information remembered
by Windows and not with the local user name.
> -- I've seen "odd" windows behavior when there are issues with domain
> membership. It's been awhile (in Win32 version context) since it
> happened, but might be worth looking into if you're still getting
> inconsistent results.
Nope. Should not be the cause as the machines here are in
a workgroup and not a domain.
> Let us know if you get something specific that points to CVSNT. If this
> doesn't work, someone here might be able to come up with other ideas to
> try.
Well, it seems to be CVSNT related but my gut says that most
likely its affected by something else on the system.
Right now only on one PC an 'incorrect' login (the local user login) is
used when connecting to the server while on all the others (two PCs)
the login information stored by Windows is used. This happens only
when the two newer CVSNT releases I tested (2.5.03 (Scorpio) Build
2151 and 2.5.02 (Servalan) Build 2064) and not when using an older
2.0.62.1817 release on the client side.
Any ideas? Anything else I should test? Any debugging output I
can get from CVSNT itself? If needed - I can try it out with some
other releases - just tell me which... :-)
Best regards,
Jurko Gospodnetic