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 Glen Starrett > Sent: Tuesday, 27 February, 2007 10:34 > To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > Subject: Re: [cvsnt] CVSNT service user and impersonation > > Bo Berglund wrote: > > So if you put some extra code into the script to create the drive letter > > mapping in code it might work. There's no difference, from a security point of view, between mapping a drive (using the user's current credentials) and using a UNC path, which Rick said he already tried. > It's been awhile since I looked at the restrictions around > impersonation, but I believe the impersonated credentials are only valid > on the local machine -- that is, you can't be impersonated on a server > then have that server use your credentials to connect to yet > another server. That's generally true. An impersonation token usually has the SecurityImpersonation impersonation level. Per the MSDN docs: SecurityImpersonation The server process can impersonate the client's security context on its local system. The server cannot impersonate the client on remote systems. Win2000 and later provide a higher level of impersonation, SecurityDelegation, which does provide remote authorization. I don't know offhand whether it'd be possible to get a delegation token in this case; there are subtleties that I haven't investigated. > There are other ways around this though -- you might be able to include > a username with password in the net use command, for example. I'd > have to fiddle with it to come up with a solid way, but it > can be done. net use * \\server\share /user:domain\username password This is not a great idea, though, since it leaves the user credentials in plain text in the script. The risk can be mitigated somewhat by restricting read access to the script file. What Rick's trying to do - have a service impersonate a user to a remote server - violates the Windows protection model. That's why it's difficult. -- Michael Wojcik Principal Software Systems Developer, Micro Focus