Hi Shangwu,
Impersonation between three machines requires delegation permission.
Impersonation tokens are bound to a particular server; thus if Machine
‘A’ sends an impersonation token (without delegation) to Machine ‘B’,
services on Machine ‘B’ cannot do anything on behalf of that entity on
Machine ‘C’ because the credentials are not transferable.
Indeed, one of the valuable features of Kerberos is that it explicitly
provides a model for delegation tokens, which weren’t supported in
Windows prior to Win2K. The documentation on this at kernel level is
sparse, but there is more information from a user mode perspective. The
material is equally applicable, however.
For example, there’s a good description of the issue in KB article #
329986. Yes, the article is about IIS and ASP programming, but the
description of a primary token, impersonation token, the “double hop
issue” as they call it and how to make all of this work is directly
applicable. The TOKEN part of this applies, even in kernel mode.
That’s the reason what you are trying to do doesn’t work. I hope this
helps.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shangwu
Sent: Monday, March 28, 2005 2:28 PM
To: ntfsd redirect
Subject: Re:[ntfsd] need help about impersonation
It seems nobody interested in this question. I would like to ask
Microsoft’s
experts or OSR’s experts to give me any advice for this impersonation
problem. Even though the call of SeImpersonateClientEx always returns
STATUS_SUCCESS for a create IRP to the redirector, the request not only
fails but also causes fatal system errors.
Is it possible to do this kind of impersonation between three machines?
Or
should I save and pass username/password as a credential to the third
machine?
I also watched some strange behavior of network requests. Suppose a
request
from clientA to serverB then serverB relay it to serverC. If I firstly
open
a file saved on serverC from serverB, then I open the file in a shared
folder on serverB from clientA, my filter can see that the first IRP is
for
\serverC\IPC$ and the second IRP is for \serverC\sharedfolder\filename.
If I
never open a file on serverC from serverB, when I open a file of serverC
from clientA across serverB, my filter on serverB can only see IRPs for
\serverC\IPC$ only.
If someone has the internal knowledge of SRV.sys and RDR.sys, please
post
your very valuable advice.
Thanks,
Shangwu
“Shangwu” wrote in message news:xxxxx@ntfsd…
> Hello,
>
> My filter driver wants to impersonate an IRP_MJ_CREATE for a remote
client
> (A) to access files on another remote server (C) across the current
server
> (B) on which the filter is running. Hopefully this is clear.
>
> The filter attaches its device object to \FileSystem\MRxSmb’s device
> object and sets a flag in the device object to indicate that this is
for
> the network redirector.
> When my user mode service opens the filter’s control device, the
filter
> creates a security context and saves it with the control device
object.
> In the create dispatch routine, it checks if the file name containing
the
> remote server name like \serverC\sharename. Then the filter calls
> SeImpersonateClientEx to impersonate the current thread by the saved
> security context.
>
> The problem is that the filter can only catches IRPs with file name
like
> \serverC\IPC$ instead of \serverC\sharename\file. If the request is
> originated from the local application on serverB to access files on
> serverC, it can catch the IRP with the expected file name.
>
> So what else device objects are needed to attach to by the filter?
>
> Your response is greatly appreciated.
>
> Shangwu
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com