Indexcontent.aspx throwing permissions error on latest version

November Happy Hour will be moved to Thursday December 5th.

AI OnAI Off

Home / Forums / Developers (Main Products) Forum / CMS 7.5 - 11 /

Indexcontent.aspx throwing permissions error on latest version

Erik Kozlowski

Vote:

While setting up Search on a v11 instance, I noticed that clicking "Index content" in the admin section throws a permissions error. There was one other forum post which hinted at the admin role being the cause of the issue, but I'm not really doing anything crazy for mapped roles. Just one named AD group and thats it.

Edit --> I should add that Im currently using ADFS for authentication, dont know if that matters.

Has anyone else ran across this before? Below is the detailed error

The assembly or AppDomain that failed was:
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Security.SecurityException: Request for principal permission failed.
   at System.Security.Permissions.PrincipalPermission.ThrowSecurityException()
   at System.Security.Permissions.PrincipalPermission.Demand()
   at System.Security.PermissionSet.DemandNonCAS()
   at EPiServer.UI.Admin.IndexContent..ctor()
   at ASP.episerver_episerver_search_cms_indexcontent_aspx..ctor() in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\61a7374b\1e1d9993\App_Web_nea3ffuq.0.cs:line 0
   at __ASP.FastObjectFactory_app_web_nea3ffuq.Create_ASP_episerver_episerver_search_cms_indexcontent_aspx() in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\61a7374b\1e1d9993\App_Web_nea3ffuq.1.cs:line 0
   at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp)
   at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
   at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
The action that failed was:
Demand
The type of the first permission that failed was:
System.Security.Permissions.PrincipalPermission
The first permission that failed was:
<IPermission class="System.Security.Permissions.PrincipalPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1">
<Identity Authenticated="true"
Role="WebAdmins"/>
<Identity Authenticated="true"
Role="Administrators"/>
</IPermission>

The demand was for:
<IPermission class="System.Security.Permissions.PrincipalPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1">
<Identity Authenticated="true"
Role="WebAdmins"/>
<Identity Authenticated="true"
Role="Administrators"/>
</IPermission>

#199544

Edited, Nov 29, 2018 20:32

simonb

Vote:

Did you find the solution to this? I have this problem as well....

#200116

Jan 02, 2019 11:05

Erik Kozlowski

Vote:

I did, it looks like you need to spin up a second empty site and point to the existing db/search service that you've already set up. From what I understand, that indexcontent.aspx page needs a local admin user in order to fire the indexing job.

#200123

Jan 02, 2019 16:54

simonb

Vote:

Great thanks for taking the time to reply Erik.

Just for future reference for anyone else, I tried adding the "SearchAdmins" role to virtual roles (<add name="SearchAdmins" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebAdmins, Administrators" mode="Any" />), but no luck. I wanted a CMSAdmin to be able to run this, but in the end just bit the bullet and created a user on the machine with Admin privileges to run it.

After that our indexing still wasn't running, but we could get to the page. I needed to set up localhost as a site pointing to our solution, rather than the actual site url, and it worked then. ie

<add name="serviceName" baseUri="http://localhost/IndexingService/IndexingService.svc" accessKey="local" /> rather than <add name="serviceName" baseUri="http://ourpropersiteurl.com/IndexingService/IndexingService.svc" accessKey="local" />

#200131

Jan 03, 2019 8:10

Erik Kozlowski

Vote:

Thanks for the update Simon. Managing a second site isnt ideal by any means (especially if its just for indexing), so Im more than willing to look at any other options. Will update later on the localhost route.

#200153

Jan 03, 2019 17:08

Jonas Lindau

Vote:

Simon, could you elaborate a bit on how you dd this? I seem to haver the same problem, but don't quite understand where you "use the local user". Do you mean you log on as the local user to acess the page?

Did any of you solve this without using a separate site for indexing service?

/Jonas

#200852

Jan 28, 2019 19:11

simonb

Vote:

Hi Jonas

Yes it seemed to be that you couldn't get to the indexing page using an Episerver virtual role, it had to be an actual role on the machine, eg Administrator. So you log in with that role to access the 'Index Content' admin page.

Also we didn't create a separate site as such, just added the host name, ie added localhost to Admin > Config > Manage websites > Click on site > Add button.

#201147

Feb 07, 2019 8:20

Hannes Lindroos

Vote:

I cannot add a actual role on the machine due to it being shared.

Did anyone find a config/code solution for this problem?

#202038

Mar 12, 2019 11:46

Gustaf Lindqvist Lindqvist

Vote:

I managed to solve it by adding a VirtualRole, which others have mentioned before as well, but not the SearchAdmin that was referred to but actually adding WebAdmins and mapped that to our AD-Roles.

It feels like the principal referred to in the EPiServer.UI.Admin.IndexContent is incorrect. At the moment this is

[PrincipalPermission(SecurityAction.Demand, Role = "WebAdmins")]

Shouldn't this be CMSAdmins, since that is possible to control via VirtualRoles?

Bug?

#202069

Mar 13, 2019 11:29

Please login to post a reply