none
Impersonated Identity Not Propagated To ActiveX Control RRS feed

  • Question

  • Greetings,

    I have an application (Windows Forms) where, upon startup, before creating an actual form, I impersonate another user. WindowIdentity.GetCurrent() confirms just that. Then, I instantiate a form where I have an ActiveX control (Windows Media Player, actually) and I set it to open a file located on a file share.

    Now, the problem is, Windows Media Player is, apparently, running with the original identity, not the impersonated one. I am saying this because it does not have privileges to open the file.

    If I run my application with the runas command, it works fine.

    I understand there are issues regarding identity flow to COM; is there anything I can do?

    If you need any more information, I'll be happy to provide.

    Thanks in advance,

    Ricardo

    Friday, March 18, 2011 10:36 AM

Answers

  • Exactly how are you accessing the file share? Are you sure this is a privilege issue or is it possible you just can't see the file?

    Here's what I'm thinking: network drives are in the user's profile (registry based) and impersonating the user does not typically load the user profile. 

    See Remarks http://msdn.microsoft.com/en-us/library/bb762281(v=vs.85).aspx 

    So iff the network share is a drive like Z: that by definition is in a user profile then things are confusing, you may be trying to access your drive with another user's credentials or the other way around. Something like that anyway.


    Phil Wilson
    • Marked as answer by eryang Monday, April 11, 2011 3:08 AM
    Wednesday, March 23, 2011 5:53 PM
  • I see.  You may or may not know that LOGON32_NETWORK_LOGON is a fast logon designed to authenticate users only and the resulting token is no good for impersonation or delegation.  But then again, you are not using that token directly.  I see that you are duplicating it.  I guess that fixes the above.  Just and idea:  Try calling LogonUser() with LOGON32_INTERACTIVE_LOGON.  The token should be good right out of the LogonUser() box. :)

    But I also just noted something in the DuplicateToken() help in MSDN Online:  It says the token will be good for impersonation in the local PC, not outside the PC.  So this is probably where the problem relies.  You need a delegation token most likely because you want to authenticate to a network file share.  Better yet:  Call LogonUser() with LOGON32_LOGON_NEW_CREDENTIALS.  This is the equivalent of the "runas /netonly" command line tool.


    MCP
    • Marked as answer by eryang Monday, April 11, 2011 3:08 AM
    Wednesday, March 23, 2011 5:54 PM

All replies

  • How are you obtaining the identity used to impersonate?  Via the LogonUser() API?  Or maybe the WindowsIdentity(string username) constructor?  Please clarify.

    Another question:  When you run WMP as an ActiveX, is that ActiveX in process or out of process?


    MCP
    Saturday, March 19, 2011 12:45 AM
  • Hi,

    I am using the Win32 LogonUser API. It is returning OK, and WindowsIdentity.GetCurrent() confirms that.

    WMP was added through Visual Studio's add reference.

    Any ideas?

    Thanks!

    RP

    Saturday, March 19, 2011 1:50 PM
  • When you use LogonUser(), are you requesting an interactive token?  Or any other type?  It would be faster if you just show the function call here.

    When Media Player starts playing, can you see wmplayer.exe (or whatever the name is) using Process Explorer or Task Manager?  Remember to show processes from all users.  If wmplayer.exe is there, under what username is it running?


    MCP
    Saturday, March 19, 2011 6:27 PM
  • Hello, Jose!

    Sorry for the late answer. No, I do not see wmplayer.exe in the list of processes, I suppose it is running inproc.

    As for the LogonUser, here is my code:

    WindowsImpersonationContext impContext = NetworkSecurity.ImpersonateUser(

                        null,

                        "username",

    "password",

                        LogonType.LOGON32_LOGON_NETWORK,

                        LogonProvider.LOGON32_PROVIDER_DEFAULT);  

     

    public static WindowsImpersonationContext ImpersonateUser(string strDomain,

    string strLogin,

    string strPwd,

    LogonType logonType,

    LogonProvider logonProvider)

    {

    IntPtr tokenHandle = IntPtr.Zero;

    IntPtr dupeTokenHandle = IntPtr.Zero;

    const int SecurityImpersonation = 2;

    bool returnValue = SecuUtil32.LogonUser(

    strLogin,

    strDomain,

    strPwd, 

    (int)logonType,

    (int)logonProvider,

    ref tokenHandle);

    if (false == returnValue)

    {

    int ret = Marshal.GetLastWin32Error();

    string strErr = String.Format("LogonUser failed with error code : {0}", ret);

    throw new ApplicationException(strErr, null);

    }

    bool retVal = SecuUtil32.DuplicateToken(tokenHandle, SecurityImpersonation, ref dupeTokenHandle);

    if (false == retVal)

    {

    SecuUtil32.CloseHandle(tokenHandle);

    throw new ApplicationException("Failed to duplicate token", null);

    }

    WindowsIdentity newId = new WindowsIdentity(dupeTokenHandle);

    WindowsImpersonationContext impersonatedUser = newId.Impersonate();

    return impersonatedUser;

    return null;

    }

    Thanks,

    RP

    Wednesday, March 23, 2011 5:15 PM
  • Exactly how are you accessing the file share? Are you sure this is a privilege issue or is it possible you just can't see the file?

    Here's what I'm thinking: network drives are in the user's profile (registry based) and impersonating the user does not typically load the user profile. 

    See Remarks http://msdn.microsoft.com/en-us/library/bb762281(v=vs.85).aspx 

    So iff the network share is a drive like Z: that by definition is in a user profile then things are confusing, you may be trying to access your drive with another user's credentials or the other way around. Something like that anyway.


    Phil Wilson
    • Marked as answer by eryang Monday, April 11, 2011 3:08 AM
    Wednesday, March 23, 2011 5:53 PM
  • I see.  You may or may not know that LOGON32_NETWORK_LOGON is a fast logon designed to authenticate users only and the resulting token is no good for impersonation or delegation.  But then again, you are not using that token directly.  I see that you are duplicating it.  I guess that fixes the above.  Just and idea:  Try calling LogonUser() with LOGON32_INTERACTIVE_LOGON.  The token should be good right out of the LogonUser() box. :)

    But I also just noted something in the DuplicateToken() help in MSDN Online:  It says the token will be good for impersonation in the local PC, not outside the PC.  So this is probably where the problem relies.  You need a delegation token most likely because you want to authenticate to a network file share.  Better yet:  Call LogonUser() with LOGON32_LOGON_NEW_CREDENTIALS.  This is the equivalent of the "runas /netonly" command line tool.


    MCP
    • Marked as answer by eryang Monday, April 11, 2011 3:08 AM
    Wednesday, March 23, 2011 5:54 PM
  • Hi Ricardo,

    I'm writing to check the issue status, please feel free to let us know if you have any concern.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Saturday, March 26, 2011 5:57 AM