Vulnerability in EPiServer.Forms
While trying to access the "Index Site Content" - /EPiServer/EPiServer.Search.Cms/IndexContent.aspx (in cms 11)Im met with a Security Exception :
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file. Exception Details: System.Security.SecurityException: Request for principal permission failed.
[SecurityException: Request for principal permission failed.]
System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp) +132
System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) +44
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +134
The problem is that it works fine on my local machine, and this only happens on the production enviroment. I cant seem to figure out whats wrong. Accessing other tools such as export, importManage Content, Change log etc all works. I noticed this issue when it seemed like the search had stopped working after the update from cms 10 -> 11.
I forgot to mention that i have already tried to add : <trust level="Full" /> to the web.config.
Could this be relevant?
I just read through that post and i cant seem to find anything that would point me to what the cause of this could be. Like i said, it only happends on the production environment, i have 0 issues when accessing it on a local machine (dev environment). Did i miss anything or what were you thinking of exactly :) ?
I was thinking if your production web.config has been updated with the changes:
Configuration sections EPiServerFrameworkSection, StaticFileSection, EPiServerDataStoreSection and SearchSection have been moved to assembly EPiServer.Framework.AspNet
That is my first thought is if it can even find the configuration at all. :)
I doubt that is the issue, since we copied the local config and just made changes to connection strings etc to reflect the production db and url. After a quick compare it seems they are as identical as they can get, so i assume the issue lies elsewhere :(
Ah, i think i misunderstood the OP.
You aren't having a security issue with the actual search, but rather with accessing the admin page for triggering a full index?
I haven't made the transition to 11 yet.
If you haven't done it yet i would suggest you go through the function permissions to see if they added anything there:
CMS->Admin->Config->Security->Permissions for Functions
That is something that wouldn't have been migrated with the config file.
Exactly, im trying to access the page that allows me to call a full reindex. Humm i checked it out but does not seem to have anything to do with it, since we never even bothered to edit anything there in previous versions. Hopefully you have less trouble with ur update :)
I won't notice if i get the same issue as you have anyway, we have a custom job to do a full index that includes commerce content. :D
I am also experiencing this but also on my local development environement.
Have tried to replace the machine.config and web.config with full trust for the Episerver local site but doesn't seem to be working...
A couple of things to try out:
1. Turn of firewall to see if it fixes the issue.
2. Compare the application pool settings between local and production.
3. Make sure you have the following in your web.config
<authentication mode="None" />
One difference is that IndexContent.aspx is delivered from disk through a VPP (from folder /modules/_protected/EPiServer.Search.CMS) while the other pages in admin mode you mention are delivered from a ZIP package (from folder /modules/_protected/CMS/CMS.zip) .Not that I know that it can be a problem,but it is a difference at least...
Can you check that the account running the web process has access rights (file access on disk) for the file IndexContent.aspx (compared to e.g. web.config)?
In our case it turned out that we needed to set the virtual roles mapped to our specific admin group roles for our site implementation.
Since Epi was checking for the principalrole of Administrators.
Eric, can you tell me exactly how you did this? I also tries to get this working by setting the virtual role without success...
Jonas, we had the same problem. I read through this thread and found that changing how the Administrators role work solved the problem. Since we are using Azure AD authentication (and no multiplexing) the Windows role Administrators in not really used anymore. But, it seems that the IndexContent.aspx page requires the user to be in this group.
I removed the follwoing row in web.config (under virtualRoles/providers)
<add name="Administrators" type="EPiServer.Security.WindowsAdministratorsRole, EPiServer.Framework" />
And added this row instead
<add name="Administrators" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebAdmins, GrpAppAdmOffice365E1" mode="Any" />
where "GrpAppAdmOffice365E1" is the admin role provided by Azure AD and WebAdmins is the standard EPiServer role.
Note that we now no longer can login as an adminsitrator using Windows Authentication, but since we are only using Azure AD its not an issue for us.