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.
> From: cvsnt-bounces at cvsnt.org
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Rick Martin
> Sent: Thursday, 16 November, 2006 11:39
>
> I am setting a remote workstation to access a CVS server over a VPN
and
> receiving this error when using the -d format of
:sspi:servername:/REPO.
> It works fine if I do a cvs login and use -d as
> :sspi:username at servername:/REPO.
>
> In my case the local workstation is a member of the same domain as the
> server and I am logging into the workstation with my domain account.
> Obviously, when I do this the domain server is not available because I
am
> remote. However, once I connect to the VPN it should be.
Yes, but due to the complexities of Windows authentication types,
security tokens, and other intricacies, having the domain controller
available only after you log in is not the same as having it available
when you log in.
When you log in to a workstation that's a member of a domain, but not
currently able to reach the domain controller, using a domain ID, the
workstation (if it lets the login succeed) will verify against a cached
verifier. It appears that the resulting token isn't acceptable to the
domain controller for whatever CVS does with an SSPI login without a
username supplied as part of the CVSROOT, which isn't surprising, though
I don't have time right now to try to track down all the details.
> I know this is probably not a CVS issue but I'm hoping
> someone here will have run into and addressed the problem.
I think it's Windows working as designed.
The workaround is simple: when you create a new sandbox, do a cvs login
with the username included in the CVSROOT
(":sspi:username at servername:/..."). You only have to do that once per
sandbox, until your domain password changes, and you can set the CVSROOT
environment variable if you always use the same CVSROOT string and not
even supply the -d option.
That's what I do. My machines aren't part of a domain, but my main CVS
server is, and I reach it over a VPN and use SSPI for CVS
authentication.
I realize this may be less than ideal for you, but is it actually a
problem? That is, is there a reason why you need SSPI authentication
without an explicit username?
--
Michael Wojcik
Principal Software Systems Developer
Micro Focus
michael.wojcik at microfocus.com
9420 Key West Avenue
Rockville, MD 20850
Direct: 517 676 0892
What would you like Micro Focus to do for you? Contribute your view by
visiting
http://www.microfocus.com/CustomerInsight.asp