[cvsnt] Re: New Bugs - Upgrading from CVSNT 2.5.01 (Travis) Build 1976 to CVSNT 2.5.02 (Servalan) Build 2115

[Jakob Kruse]

You misread my post Tony. I am *NOT* using any username here. I am working 
on the server itself, using its public (internet) name. What I wrote was 
that using 2.5.01 server the response generated makes Tortoise think the 
server needs a password, and so it tries sending a cvs login command. Here 
is what Tortoise gives me:

In C:\sandbox\foo: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "-x" 
"checkout" "-P" "Kontrakter\Data"
CVSROOT=:sspi:cvs.kruse-net.dk:/dana-invest.dk
cvs.exe [checkout aborted]: authorization failed: server cvs.kruse-net.dk 
rejected access to /dana-invest.dk

Using command-line cvs (2.5.01):

C:\sandbox\foo>cvs -d :sspi:cvs.kruse-net.dk:/dana-invest.dk -q -x 
checkout -P Kontrakter\Data
cvs [checkout aborted]: authorization failed: server cvs.kruse-net.dk 
rejected access to /dana-invest.dk

Changing to localhost:

C:\sandbox\foo>cvs -d :sspi:localhost:/dana-invest.dk -q -x checkout -P 
Kontrakter\Data
U Kontrakter/Data/datadef.fdx

Please give me enough credit not to automatically assume I'm doing 
everything wrong here. I have been using CVS for years. And SSPI for as long 
as it has been available. I make money teaching people how to use it. And 
I've never had any problems like this prior to 2.5.

I could need some help figuring out what tests to run and will provide 
access to a repository on the server if needed.

Regards,
Jakob Kruse


"Tony Hoyle" <tony.hoyle at march-hare.com> wrote in message 
news:diur7l$5uq$1 at paris.nodomain.org...
> Jakob Kruse wrote:
>> I just tried downgrading the server to 2.5.01.1976. It changes the error, 
>> but doesn't seem to remove the problem. Where 2.5.02 would give me the 
>> "Unknown Error -1" error, 2.5.01 gives me:
>>
>> cvs.exe [checkout aborted]: authorization failed: server <censored> 
>> rejected access to /myrepo for user Jakob Kruse
>>
>> Using Tortoise this results in a login prompt, after which Tortoise sends 
>> a cvs login command, but the error just comes again.
>>
> This is the problem with using usernames with SSPI.  It's much better to 
> just let the default authentication handle it.
>
> eg. if you're on a laptop for example, which commonly isn't logged into 
> the domain, if you use foo at server, you'll actually be trying to log into 
> LAPTOP\foo at server, which is not going to work.
>
> Once domain trusts get involved it gets even more complicated...
>
> If you let the SSPI negotiation handle it internally it'll log you in 
> using its already cached credentials for the server, so it's a lot less 
> error prone.
>
> Also, don't use cvs login with sspi unless you absolutely have to.. the 
> system already has your credentials.
>
> Tony