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 firstname.lastname@example.org.
> 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