[cvsnt] CVSNT service user and impersonation

Michael Wojcik Michael.Wojcik at microfocus.com
Tue Feb 27 16:17:30 GMT 2007


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


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook