Re: Impersonation for accessing network resources?

Beware "domain\\Administrator" or @"domain\administrator" not
"domain\administrator".

Once you have a connected network session it remains valid for the whole
logon session, that is why you should create a session from your domain
logon (through a logon script) or from a batch file that runs when a user
logs on locally instead of impersonating in user applications.

Willy.

"Ben Fidge" <ben.fidge@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23xZuXRWAGHA.532@xxxxxxxxxxxxxxxxxxxxxxx
> Basically I've been using [domain]\Administrator and [password] the same
> as I enter when I try to access the mapped drive from explorer. However it
> works in explorer but not my app. However, if I first connect using
> Explorer, I then don't need to use LogonUser. Strange!
>
> Ben
>
>
> "Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
> news:Obz6ugLAGHA.3864@xxxxxxxxxxxxxxxxxxxxxxx
>>
>> "Ben Fidge" <BenFidge@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:B024D767-93F7-49E9-94D4-E0CC31871F31@xxxxxxxxxxxxxxxx
>>> Hi
>>>
>>> I have a small WinForms app that needs to copy files from a shared drive
>>> on
>>> a network. If I connect to the mapped drive using Explorer, a password
>>> dialog
>>> pops-up and I have to provide credentials with permission to access this
>>> resource on the machine where it's hosted. This is once for each desktop
>>> logon session (ie after every reboot). If I do this, my app can access
>>> the
>>> network resource fine, but otherwise fails with permission errors.
>>>
>>> As my app runs when Windows starts, I don't want to first connect to the
>>> mapped drive each and every time.
>>>
>>> I've found some C# code that allows me to impersonate a
>>> domain/account/password context, but it won't work in the scenario I
>>> want. I
>>> know the code works because it allows me to impersonate local accounts,
>>> just
>>> not access the network resource. When run, the following error occurs:
>>>
>>> "Error No: 1326 - Error: Logon failure: unknown user name or bad
>>> password."
>>>
>>> However, I know the domain/account/password are all correct.
>>>
>>> The code is based on Win32 API's LogonUser. Am I barking up the wrong
>>> tree?
>>>
>>> Thanks
>>>
>>> Ben
>>>
>>
>> If you call LogonUser you should specify the credentials of a valid user
>> that has appropriate privileges to access the remote server.
>>
>>
>> Willy.
>>
>>
>>
>
>


.

Relevant Pages

  • Re: Gaining access to network shares from WebServices and WebForms
    ... If you mean creating a Logon session and impersonating the session token the answer is yes, but there are some issues, most notably ... running aspnet which such elevated privilege is considered very bad security wise. ... Another possibility is to create a network authentication handshake by calling the SSPI API's using ME C++. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: cant use "NET USE" at windows services
    ... Network logon sessions are tied to the windows logon session of the caller. ... if i put the same code at the windows service and start ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Windows Service System Account Permissions
    ... > You also can't use mapped drives. ... Yes, but you need to map the drive in the SYSTEM logon session, network ... SYSTEM uses the machine account to access the network.. ...
    (microsoft.public.dotnet.languages.csharp)
  • CreateProcessAsUser and network share
    ... LogonUser/CreateProcessAsUser to create the process under user context. ... Works fine if the network share is in the same domain, ... I understand from the MSDN documentation that connection made in the first ... logon session might not be available to the second logon session created ...
    (microsoft.public.platformsdk.security)
  • CreateProcessAsUser and network share
    ... LogonUser/CreateProcessAsUser to create the process under user context. ... Works fine is the network share is in the same domain, ... I understand from the MSDN documentation that connection made in the first ... logon session might not be available to the second logon session created ...
    (microsoft.public.win32.programmer.networks)
Loading