Re: Service Account replaced by IUSR ??

Hm, I can't think of a reason why the IUSR account would get used here then.
If you are definitely not impersonating (which it looks like you are not)
and don't have anonymous checked anyway, then the remote access to the file
share should use the process account.

There must be something else going on that is creating the issue, but I
don't know what it is.

Can you show the code you are using for accessing the file share? That
might be helpful.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"> Hi Joe,
(First off, I'm a *big* fan of your book about AD !)
Well, to get to the matter at hand, I'm quite sure that anonymous access
is disabled. In fact, I did a check with the
System.Security.Principal.WindowsIdentity.GetCurrent() and sure enough the
application runs under the service account.
The only thing that is a bit different is that I'm running the application
with a different port number (192.168.1.2:8080), but that should not
affect the security, should it ?
As for the "trust account for delegation" option is concerned, I thought
you had to enable this, based on this text fragment in the article I
referred to :
"By using impersonation, ASP.NET applications can execute code or access
resources with the identity of the authenticated user or a fixed Windows
identity. Standard impersonate-level impersonation tokens that are usually
created when you enable impersonation allow you to access local resources
only. To be able to access remote network resources, you require a
delegate-level token. To generate a delegate-level token when you
impersonate, you need to use Kerberos authentication and your process
account needs to be marked as trusted for delegation in Active Directory.
"

But now that I read it again, I see your point. Anyway, it doesn't work
either with or without this option checked, so I'll uncheck it. I like
clean settings.

Erwin


.

Relevant Pages

  • Re: SetPassword access denied
    ... We figured out why SetPassword threw an access ... 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)
  • Re: ASP.NET Anonymous Impersonation
    ... - A process always has a token associated with a Windows account ... All resources are accessed with this thread. ... > With Integrated Windows Authentication and impersonation: ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • 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)
Loading