Re: Total Confusion! - ACLs and Windows authentication with no impersonation

From: Pete Beech (peter_beech_at_hotmail.nojunk.com)
Date: 07/20/04

  • Next message: Jonathan Van Eenwyk: "Minimum Privileges for Debugging Local ASP.NET" 
    Date: Tue, 20 Jul 2004 00:15:51 +0200

    Hi,
    thanks for the reply. However, I thought it was a bit different.. as I
    understand it, if its a resource mapped to aspnet_isapi.dll, then IIS just
    authenticates, and passes the token to the aspnet_wp.exe process. In the
    diagram in the link I gave, its in the ASP.NET part that the NTFS
    permissions are checked, and not in IIS.

    It seems like this FileAuthorizationModule in ASP.NET is checking the NTFS
    settings using the original callers token, and not the using the ASPNET
    account - regardless of the impersonation settings. If I understand it
    right, the impersonation settings only affect programmatic access to
    resources (e.g. the example I saw in this article (link below) was the
    loading of an XML file, from code - if impersonation was on, then the XML
    would be only loaded if the impersonated user had access, if impersonation
    was off, then it would be loaded if ASPNET had access).

    So, I have the situation where, on the intranet, I want to programmatically
    check the Windows User trying to logon against a DB, but without having to
    grant specific access to anyone at the NTFS ACL level, apart from ASPNET -
    but it looks to be me like I need to grant access to 'Everyone' just to be
    able to get to ASP.NET to be able to do the programmatic authentication,
    because of the FileAuthorizationModule.

    I'm sure there is a way, but I can't see it..

    Cheers, and thanks for your help..
    Pete

    (There is a great article about all this stuff.. which stresses the fact
    that ACL checks are made, regardless of the impersonation settings:
    http://msdn.microsoft.com/msdnmag/issues/02/04/ASPSec/ . And, to me, this
    seems to directly contradict the .NET documentation (specifically this
    diagram, and the statement "Notice that if impersonation is not enabled, the
    application runs with the IIS process identity. For Microsoft Windows 2000
    Server and Windows XP, the default identity is a User account named ASPNET
    that is created automatically when ASP.NET is installed. If you want to
    restrict access, you must use some other means of authorization, such as URL
    authorization.") )

    ------------------------------------------
    "Raterus" <raterus@spam.org> wrote in message
    news:eJsDBcdbEHA.712@TK2MSFTNGP11.phx.gbl...
    Here is how I think of this process.

    You have aspx pages..and you have the resources this page wants to get at.
    When anonymous authentication is disabled, yes the page itself MUST have
    NTFS permissions set so the user can access the page, this is an IIS thing,
    you aren't even at ASP.NET yet at this step.

    After they have access to the page, if impersonation is disabled, this is
    when the aspnet user takes over the process, and access to other resourses
    is granted based on that, not the original user.

    You should be able to do what you are after, in your asp.net pages, use
    HttpContext.Current.User to get at the user who requested the page.

    Hope this helps,
    --Michael

    "Pete Beech" <peter.beech@iname.com> wrote in message
    news:7b400a8c.0407191019.7f15ef1@posting.google.com...
    > Hi all,
    > apologies if this has come up before, but I've been searching the
    > whole day and found nothing...
    >
    > If I have authentication set to "windows", and identity
    > impersonation="false", do I need to grant access to the authenticated
    > windows user on the website and its resources (aspx files, etc)?
    >
    > The MSDN VS.NET documention has the diagram in this link
    >
    (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/ht
    ml/cpconaspnetdataflow.asp)
    > - it looks like, if impersonation is set to false, it says it does
    > 'other security checks', but does not go through NTFS ACL security.
    > Other responses I've seen say that, if impersonation is false, then
    > you only need to grant access to the ASPNET user.
    >
    >
    > However, in the Building Secure ASP.NET application book, Chapter 8,
    > it states "Windows ACLs
    > Client Requested Resources. The ASP.NET FileAuthorizationModule
    > performs access checks for requested file types that are mapped to the
    > ASP.NET ISAPI. It uses the original caller's access token and ACL
    > attached to requested resources in order to perform access checks.
    > **** Impersonation is not required. ****"
    >
    > and later on, about Windows authentication,
    > "The access token of the authenticated caller (which may be the
    > Anonymous Internet user account if IIS is configured for Anonymous
    > authentication) is made available to the ASP.NET application. Note the
    > following:
    >
    > This allows the ASP.NET FileAuthorizationModule to perform access
    > checks against requested ASP.NET files using the original caller's
    > access token.
    > Important ASP.NET File authorization only performs access checks
    > against file types that are mapped to Aspnet_isapi.dll.
    > *** File authorization does not require impersonation. **** With
    > impersonation enabled any resource access performed by your
    > application uses the impersonated caller's identity. In this event,
    > ensure that the ACLs attached to resources contain an Access Control
    > Entry (ACE) that grants at least read access to the original caller's
    > identity."
    >
    >
    > When I actually try it out, it seems that I do need to have the user
    > granted access with an ACL on the resource, even with no
    > impersonation. But this seems to directly contradict the .NET
    > documentation.
    >
    > Does this really mean that, if I want to programmatically deny access
    > or use the authorization tag in the web.config, that I need to set
    > access to 'Everyone'? Can I really not just grant access to the ASPNET
    > account? Or am I just misunderstanding this completely?
    >
    > What I would like is to be able to just grant access to ASPNET, but
    > still obtain the Windows User identity to do my own custom
    > authorization. Is this possible?
    >
    > Hope someone can help me!,
    >
    > Cheers,
    > Pete

  • Next message: Jonathan Van Eenwyk: "Minimum Privileges for Debugging Local ASP.NET"

    Relevant Pages

    • Re: IIS on Domain Controller = Authorization Problem
      ... it means that IIS successfully authenticated with some ... but that account lacks NTFS permissions on the requested resource. ... A common misconception that enabling "Anonymous authentication" should ... identity to access resources for all requests, ...
      (microsoft.public.inetserver.iis)
    • Re: Total Confusion! - ACLs and Windows authentication with no impersonation
      ... After they have access to the page, if impersonation is disabled, this is when the aspnet user takes over the process, and access to other resourses is granted based on that, not the original user. ... > Client Requested Resources. ... It uses the original caller's access token and ACL ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: Multiple Users with impersonation using one account
      ... you don't need impersonation to check for user identity - Context.User.Identity.Name is populated with the clients name ... some applications use resources such as the file system for ... or for opening files on other network ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: Service Account replaced by IUSR ??
      ... I can't think of a reason why the IUSR account would get used here then. ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... "By using impersonation, ASP.NET applications can execute code or access ... created when you enable impersonation allow you to access local resources ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: Impersonation in non domain member server
      ... first of all you are not forced to use auto impersonation - you can always manually impersonate before you are doing the resource access... ... undo impersonation temporarily when talking to resources that are not "compatible" with impersonation ... remote server located at the DMZ (this is, a non domain member ...
      (microsoft.public.dotnet.security)