If it's enough you could just remove the <allow roles/>-entry in the <location>-section for dashboard path and admin interface path in Web.config on the public server. Then no one would be able to login and access it.

It's by default but just make sure that you still have `deny` of your /cms/ location element:

  <location path="cms">
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
  </location>

If you want to remove only Admin interface for all users except the users with admin roles in public server then change the web.config like this

<location path="CMS/admin">
    <system.web>
      <authorization>
        <allow roles="WebAdmins, Administrators" />
        <deny users="*" />
      </authorization>
    </system.web>
</location>

If nobody is allowed to Admin interface then 

<location path="CMS/admin">
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
</location>

Note that removing access rights to /utils/ make shake things up since the login screen is there by default (utils/login.aspx).

1: Visit a restricted area
2: Go to login view (by default /utils/login.aspx)
3: the /utils path is restricted
4: Go to login view

In web.config you may change the path to you login view where the visitor is redirected if trying to enter a restricted area.

Note that removing access rights to /utils/ make shake things up since the login screen is there by default (utils/login.aspx).

1: Visit a restricted area
2: Go to login view (by default /utils/login.aspx)
3: the /utils path is restricted
4: Go to login view

In web.config you may change the path to you login view where the visitor is redirected if trying to enter a restricted area.

Have you ever wrote an answer in late evening? Aahh, what I was thinking about, Alf :) Of course - if you will secure `utils` location - you may get some weird infinite loop. Crap :D

Is there another way to do this. As I know you can comment out the roles but I want it so that if somone does browse the path it is as if it doesnt exist (default 404 handler should kick in then) rather than giving them a login prompt.

searching the *.config files for "<location path=" I see these entries

Web.config

315 <location path="interface">
345 <location path="interface/CMS/admin">
353 <location path="util">
457 <location path="modulesbin">
476 <location path="IndexingService/IndexingService.svc">
488 <location path="WebServices">
513 <location path="Views/Plugins">
522 <location path="Static">
530 <location path="CmoWebServices">
558 <location path="interface/CMO">
589 <location path="interface/CMO/Settings">
597 <location path="util/editor/tinymce/plugins">

I did try removing all these location paths on the test box but I'm still able to navigate to /interface/ and get a weird unstylised page (see screenshot, http://imageshack.com/a/img842/563/7ckn.png)

Does anyone have any thoughts on this?

Thanks

Doug

If you see something like this in your EPiServerFramework.config file:

<add virtualPath="~/interface/" physicalPath="[appDataPath]\Modules" name="ProtectedAddons" type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider, EPiServer.Framework" />

It means that by removing location elements from web.config you just remove settings for that loction and some below.

Hi Valdis

This is what I tried already and get the result I posted in the screenshot in previous reply.

Its worth noting in our current test environment we have two servers doing the public facing role (which have some seperate entries in web.config) and then another server we use soley for the interface and content authoring (again seperate entries).

I notice in DB there is table called tblSiteConfig which seems to hold a copy of the web.config. I am assuming each time a webservers app pool is recycled the values from web.config are read into this table? How does that work if web.config on servers 1 & 2 (public) is slightly different from server 3 (content authoring)

Not 100% sure but if `enableSavingOfConfigurationToDatabase` = true (which is default) this means that site configuration is written to database for sharing with other servers (enterprise scenarios). I bet that last arrives - win for content of this particular table.

That setting doesnt seem to be present in any config but its definatley updating the DB so I guess its on by default in 7.5.

Do you know if the data in the table takes priority over the local .config files?

Thanks

Do actual reads happen in your case from that table?

I can see that reading from datbase happens only in Obsolete class called `ConfigurationHandler`. That gives possibility to retrieve various site related info from content references and other helper methods. This has been refactored in 7.5.

Thanks for the reply.

I'll setup a trace on the DB to check and ask the developers, I doubt they would be using it if its been deprecated.

I'm still very keen to know how to resolve my original issue though :)

To go for pure 404 error - I would try to find a way to deploy episerverframework.config file to front-end server where Admin and Edit mode should give 404 error without `cms` path at all. That would mean that there is physically no Admin and Edit mode on front-end server.

Yes thats what I'm trying to do but I cant seem to find the right combination to get it working. I'll carry on experimenting.

What are your current implementation? And what approaches are you currently experimenting with?

We are a new customer so there is no current implementation. EPiServer is new to us this is why I am trying to work out how to do this before the project goes into production.

It is currently being developed by 3rd party developers which I then deploy to our UAT systems so as IT/Infrastructure administrator I am trying to work out how to make it secure ready for production deployment.

When I say experiment I mean hacking the .config files around until it seems to do what I want as the various bits of documentation I've seen only seem to cover removing the roles from the location paths which isnt enough for us.

Clear. If you are running with 7.6 version - you may look into differentiate deployment content for various servers - for instance, for front-end servers do not deploy modules/_protected/ folder content, also remove related web.config entries (the easiest solution would be to play around various deployment / solution configurations and web config transformation files if using Web Agent deployment infrastructure). In such a way - there is no physically Admin mode on that server. Also remove `cms` location provider entry in EPiServerFramework.config.

I think there are two ways to achieve the original goal

1) Handle the redirection at the webserver /  IIS level - using UrlRewrite. Here you would add rules that would forbid access to the admin interface by redirecting requests to that url to another url of your choosing

or

2) Add a deny * location rule to your config (as mentioned above). This will mean that any users attempting to access will be redirected to the asp.net forms authentication page configured in web.config. If you don't want them to see a login screen then change the login Url to another value. It doesn't have to be a login page, it can be any page on your site, such as your 404 page. This may be confusing if your site still uses the asp.net membership model for other authentication scernarios as this change will effect ever Unauthenticated request.

I prefer option 1 as the changes are environment specific rather than you having to change the behaviour of your application.

Wow - I only just noticed that forum threads can go over two pages! That was confusing. Where do I log EPiServer World improvements?

There is a tab with "feedback" if you have some improvements to World :)

Found it :)

It depends "how secure" removal you would like to implement. Redirects and denials are IMHO *soft* removal of Admin and Edit mode but least disturbing :) 

@Valdis Iljuconoks We are going to be running version 7.5, so does what you say only apply to 7.6?

@Mark Everard redirection might be a possibility if we cant completley remove the admin. I assume for public facing site I can redirect all of these locations and the public facing site for users will work without issue?

315 <location path="interface">
345 <location path="interface/CMS/admin">
353 <location path="util">
457 <location path="modulesbin">
476 <location path="IndexingService/IndexingService.svc">
488 <location path="WebServices">
513 <location path="Views/Plugins">
522 <location path="Static">
530 <location path="CmoWebServices">
558 <location path="interface/CMO">
589 <location path="interface/CMO/Settings">
597 <location path="util/editor/tinymce/plugins">

My knowledge of episerver is pretty limited at the moment so apologies for any dumb questions.

I'll run through my methods of what I've done next week and describe the outcome in more detail.

Thanks all for your replies so far.

Doug

It depends on your application (web site) as well. You may be serving something not releated to EPiServer through `WebServices` location as well. Also `Static` may be used to serve javascripts or stylesheets. What about `Views/Plugins` - I don't know any of EPi functionality located there?

Yes - Admin mode shell libraries are served via .zip file under /modules/_protected. So it's easier for 7.6. For pure 7.5 - you will need to remove files from modulesbin/ as well - if you are looking for hard remove. Usually:

EPiServer.Cms.Shell.UI.dll
EPiServer.Shell.UI.dll

Hi Valdis

Thanks again for your reply.

Those DLL's only seem to be present in \bin\ rather than \modulesbin\ I assume its OK to remove those for public facing servers?

Just test on some other server before removing :)