feature delegation permissionsRSS

8 replies

Last post Apr 24, 2008 05:14 AM by roelvs

  • feature delegation permissions

    Apr 19, 2008 06:52 PM|roelvs|LINK

     I'm a little confused while configuring feature delegation for our web site owners.

     I followed most of the best practices found on this website (shared configuration, UNC-based hosting, load-balancing) for shared hosting, and (almost ;-) ) everything runs smoothly.

    Delegation is working fine also, but only if delegated to users with administrator permissions on the web server and file share. If other users try to connect to their website with the IIS manager on a Vista SP1 machine, then the manager shows the icons of the delegated features, but selecting one results in an error. (error while executing request, detail: filename:MACHINE/WEBROOT)

    What permissions are important on the share/web server to get this setup working?

    important detail: we are using AD accounts for delegation.


     

  • Re: feature delegation permissions

    Apr 21, 2008 02:35 AM|NitashaV|LINK

    It seems that the account used to establish the connection to the website does not have the read/write permissions to the site's web.config file. Can you post the complete error message you see?

    Meanwhile the article at : http://learn.iis.net/page.aspx/349/remote-administration-behavior-matrix/ should help you determine what acls are needed for the identity establishing a connection to a website.

    -Nitasha

  • Re: feature delegation permissions

    Apr 23, 2008 06:10 AM|roelvs|LINK

    Thank you for your response. The document you mentioned was very useful, but it only confirms there are no errors in my configuration. For your convenience, I included the detailed error:

     

    IISWMSVC_AUTHORIZATION_FAILED

    The user 'domain\user' is not authorized for the path '/site_name'.

    Exception:System.Runtime.InteropServices.COMException (0x80090016): Keyset does not exist (Exception from HRESULT: 0x80090016)
       at Microsoft.Web.Administration.Interop.IAppHostProperty.get_Value()
       at Microsoft.Web.Administration.ConfigurationElement.GetPropertyValue(IAppHostProperty property)
       at Microsoft.Web.Administration.ConfigurationManager.LoadRedirectionInfo()
       at Microsoft.Web.Administration.ConfigurationManager.GetAdministrationConfigMapIfNeeded()
       at Microsoft.Web.Administration.ConfigurationManager.SetAdminManagerProperties(WebConfigurationMap webConfigMap, Boolean isAdminConfig, IAppHostAdminManager adminManager, Boolean isRemote)
       at Microsoft.Web.Administration.ConfigurationManager.CreateWritableAdminManager(WebConfigurationMap webConfigMap, String configPathToEdit, Boolean isAdminConfig)
       at Microsoft.Web.Administration.ConfigurationManager.CreateConfiguration(WebConfigurationMap configMap, String configPathToEdit, Boolean isAdminConfig)
       at Microsoft.Web.Administration.ConfigurationManager.GetConfiguration(String rawConfigurationPath, String cacheKey, Boolean isAdminConfig)
       at Microsoft.Web.Management.Server.ConfigurationAuthorizationProvider.GetSection(ServerManager serverManager)
       at Microsoft.Web.Management.Server.ConfigurationAuthorizationProvider.IsAuthorized(IPrincipal principal, String configurationPath)
       at Microsoft.Web.Management.Server.WebManagementAuthorizationModule.IsAuthorized(HttpContext context)

    Process:WMSvc
    User=domain\user

    this is the error on the server side. On the user side, there is an error message with empty details, empty error message; only "filename: MACHINE/WEBROOT"

     

  • Re: feature delegation permissions

    Apr 23, 2008 10:08 PM|NitashaV|LINK

    Hmm... based on the error you see it seems that the LocalService identity does not have the correct acls on the machine key used to decrypt passwords in server config files (aka applicationHost.config, redirection.config)

    To confirm this theory and also find which machine key is being used to decrypt passwords, try: a) installing procmon (sysinternals tool, can be installed from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx)

    b) run the tool on the background while trying to repro this issue.

    c) You should get an access denied message in the log, this should point you to the machineKey as well as the userName thats trying to access this key.

     

     

     

     

  • Re: feature delegation permissions

    Apr 24, 2008 02:13 AM|roelvs|LINK

    Thank you, using procmon, i could indeed narrow down the problem. It seems like the permissions on the hidden directory:

     c:\programData\Microsoft\crypto\RSA\machineKeys

    were wrongly set. Editing these permissions resolved this solution....

    Does this folder really needs modify permissions for the 'everyone'-group? Isn't that a security risk? Either way, thank you! 

     

  • Re: feature delegation permissions

    Apr 24, 2008 02:28 AM|NitashaV|LINK

    You shouldnt have to give "everyone" permissions to this machine key. Just the identity (should be local service or wmsvc) that is trying to read server config files (and so decrypt the password).

     

     

  • Re: feature delegation permissions

    Apr 24, 2008 02:50 AM|roelvs|LINK

    according to the results in process monitor, the impersonated (ad-account) is used to access these keys. So I should give every user with delegated permissions rights on this directory. (hundreds of users)

    By the way, the 'everyone'-group was already in the NTFS ACL even before I reset these rights... (I confirmed this on another server)

     regards,

    R

  • Re: feature delegation permissions

    Apr 24, 2008 04:09 AM|NitashaV|LINK

    Trying to understand how your client and server machines are configured and the repro steps - You have iis manager client on vista sp1 and you are trying to establish a connection to a site on a w2k8 server using some ad auth credentials(non admin user, right?).

    Does that cover it? Or is there any unc or shared configuration in your scenario?

     

     

     

     

     

  • Re: feature delegation permissions

    Apr 24, 2008 05:14 AM|roelvs|LINK

    OK, I'll try to give you an idea of our setup...

    - we have a shared storage (unc) with folders for the websites. website owners have permissions to publish a website. (domain\USER) There is also an (domain\IU_user) for these folders, used by the webserver for anonymous access.

    - The shared storage is also used for the shared IIS configuration (once the first server works perfectly, more servers will be added). To access the storage, another account (domain\IISconfig) is used by the web server.

    Every website owner (domain\USER) has also permissions to manage their website on their local computer with the IIS manager.
    And that's when the strange behaviour occurred.

    Of course, the domain\user users don't have administrative permissions on either the webserver or the shared storage.