locked
LightSwitch ACL Permissions RRS feed

  • Question

  • All of a sudden when deploying LightSwitch applications the
    permissions on the website directory began changing.  The issue is that
    the anonymous user gets set to have Read permissions (Not Set
    Previously) and the App Pool Identity permissions change to just Read. 
    Because of this an error occurs when the application is loaded:
    Load
    operation failed for query 'GetAuthenticationInfo'. Exception of type
    'System.ServiceModel.DomainServices.Client.DomainOperationException' was
    thrown.

    By giving the App Pool Identity back the permissions
    Read & Execute the error goes away.  Also, the application works
    just fine even when removing the anonymous user from the permissions.

    This is a Windows Authentication only application and anonymous access should not be allowed. 

    In
    the project folder there is a directory \Server\obj\Release\Package\.  In that
    directory there is a file called Server.SourceManifest.xml.  In that
    configuration file there are two lines for setAcl in which Web Deploy
    uses to change the permissions on the site directory.  The setting
    setAclAccess specifies what access is to be set and the default is Read.
      The setting setAclUser specifies which user will be given access and
    the default is ApplicationPoolIdentity.

    The first line in the
    configuration file doesn't set the settings setAclAccess or setAclUser
    which is changing the permissions for the App Pool Identity to Read. 
    The second line sets the setAclUser to anonymousAuthenticationUser and
    doesn't set the setting setAcl which is giving permissions for IUSR to
    Read.

    I don't see any settings in Visual Studio that allows
    changing this besides doing so manually.  Even if you delete these two
    lines they are restored again when the project is deployed.

    Looking
    at the deployment output I see that a manifest is created and the ACL
    is applied from MSBuild at C:\Program Files
    (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
    Microsoft.Web.Publishing.targets

    The website directory is set to not inherit permissions from its parent.


    Instead of ensuring that at least those permissions exist it removes any other permissions and only sets Read making the website inoperable.

    • Edited by Mike MSDN Thursday, August 15, 2013 4:11 PM
    Thursday, August 15, 2013 3:25 PM

Answers

  • Hi Mike

    I just noticed that you have submit this issue to Microsoft Connect site, and thanks for sharing this workaround with us, if you still need precise troubleshooting for this issue, you could give a positive response when Visual Studio Product Team engineers need more details,

    Best regards


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Wednesday, August 21, 2013 2:47 AM

All replies

  • Changing the directory permissions can be turned off by modifying the Server project file \Server\Server.csproj

    In that file there is a PropertyGroup for Release:
    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">

    The following entry needs to be added to that PropertyGroup:
    <IncludeSetAclProviderOnDestination>false</IncludeSetAclProviderOnDestination>

    Thursday, August 15, 2013 4:11 PM
  • Hi Mike

    I just noticed that you have submit this issue to Microsoft Connect site, and thanks for sharing this workaround with us, if you still need precise troubleshooting for this issue, you could give a positive response when Visual Studio Product Team engineers need more details,

    Best regards


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Wednesday, August 21, 2013 2:47 AM