Re: Using ImpersonateLoggedOnUser

From: Alvin Bruney [Microsoft MVP] (www.lulu.com/owc)
Date: 02/28/05 

Date: Sun, 27 Feb 2005 19:22:14 -0500

It depends on how exactly the print call is being made. If it invokes
another process, that process will run under the worker process account.
Bruce baker wrote some code to fix this issue in here a couple weeks ago
using the .NET API, have a google for it. 

-- 
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------
"D" <anonymous@discussions.microsoft.com> wrote in message 
news:1f0f01c51d23$36a63410$a401280a@phx.gbl...
> We have a .NET application implemented as a Windows
> service in order to perform impersonation for the purposes
> of gaining access to various resources. We are using
> ImpersonateLoggedOnUser() instead of the .NET
> impersonation API.
>
> Everything works fine except when we call an external COM
> component that is supposed to print a report using its
> internal API calls. We can access file resources, etc.
>
> We perform impersonation to a valid administrator account,
> yet the application fails to print (we wrote debugging
> information to make sure that we are impersonating
> properly).
>
> The problem appears to be that the external process is
> still using the local SYSTEM account, which by default
> does not have access to printers (unless the registry is
> modified - see http://support.microsoft.com/default.aspx?
> scid=kb;en-us;184291). If the registry is modified to
> allow printer access to the SYSTEM account, printing works
> fine.
>
> We do not want to have to modify the registry to allow
> access to printers. Any idea why impersonation is failing
> here?
>
> Thanks in advance.

Relevant Pages

  • Re: SetPassword access denied
    ... safely invoke SetPassword etc..... ... impersonation or using the process token without impersonation) is NOT ... account that is used for performing remote activities in the directory. ... Co-author of "The .NET Developer's Guide to Directory Services ...
    (microsoft.public.windows.server.active_directory)
  • Re: VS.NET 2005 and the "allowDefinition=MachineToApplication" error
    ... Your description of impersonation is great. ... If you want to use the default configured account, eliminate that entry, or configure it as: ... The easiest way to assign correct permissions to all required directories is to run: ... I re-started IIS and tried to access my ASPX page again -- same ...
    (microsoft.public.dotnet.framework.aspnet)
  • [Full-disclosure] Maybe nothing so shady; depends on the motive.
    ... There may be no impersonation going on. ... attempted use of a disabled account would produce messages about "account foo login fail" ... SecureWorks was still reading email addressed to David Maynor. ...
    (Full-Disclosure)
  • Re: Impersonation
    ... impersonation, unless you actually need to be userX for some file operation, ... I also wonder why folks always talk about using a seperate account DB. ... I know the diference between IIS and WSE authentication mecanism. ... >>> where I need to check password in UsernameTokenManager for that I need ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: SetPassword access denied
    ... That said, I think one thing worth pointing out is that in both cases here, your code is supplying credentials to the DirectoryEntry constructor. ... the identity of the current thread (established either via impersonation or using the process token without impersonation) is NOT the account that is used for performing remote activities in the directory. ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.windows.server.active_directory)