These behavioural inconsistencies are usually caused by the timing of when the
ViewFormPagesLockdown feature first gets enabled, and the inheritance state of
each web.
If you have some sites in an existing site collection that have security
inheritance already broken at the first time you enable the
ViewFormPagesLockdown feature they may not inherit the Special Permission level
that ViewFormPagesLockdown creates, while other sites get it. Once you have
enabled the ViewFormPagesLockdown feature once, the special permission level is
already created, the behaviour is set, and deactivating/activating it has no
effect on the inconsistent sites.
After activating ViewFormPagesLockdown, breaking inheritance on sites in the
collection maintains the special permission level, even though you can't see it
through the UI. So you may end up with two sites both with broken security
inheritance that behave differently from an Anonymous point of view.
I have seen some solutions to the problem that involve ignoring the
ViewFormPagesLockdown feature and instead changing the class that the system
pages inherit from (like View All Site Content - viewlsts.aspx) to something
like SecuredFormPage (or something like it). But have never recommended it due
to later support concerns.
As you can tell, I have a few battle scars on this one.
Cheers,
J.
From: [email protected] [mailto:[email protected]] On Behalf Of
Paul Noone
Sent: Tuesday, 23 November 2010 8:15 AM
To: ozMOSS
Subject: RE: Help with 401 errors on public site
Hi Chris,
We have exactly the same behaviour with a subsite collection doing all the
right things. Settings are identical and I can't for the life of me work out
why. ViewFormpagesLockdown is disabled, anonymous access is set sitewide - and
yet anonymous users CANNOT directly access anything in _layouts and are not
able to view list form pages with explicit access enabled on the list.
I wound up deleting that site as an aberration after extensive testing to find
the cause. Some sources believe it was the combination of enabling anonymous
access for Lists and Libraries, then deactivating the feature, then changing
access to sitewide... In the end I never cracked it.
If you ever work it out I'd love to know the answer; especially if you can get
it working for a root site!
Regards,
Paul
--
Online Developer/Administrator,
ICT Projects Team
CEO Sydney
From: [email protected] [mailto:[email protected]] On Behalf Of
Chris Howell
Sent: Tuesday, 23 November 2010 12:20 AM
To: ozMOSS
Subject: Re: Help with 401 errors on public site
Hi,
Thanks for all the responses. Still working my way through them and need to
discuss with my colleague who I'm working with on this issue.
Strangest thing we've found now is that we actually have a sub site that
exhibits the behaviour we would like but need to get to the bottom of why this
sub site does it but not others.
Will keep digging and let you know what we find/come up with.
Cheers,
Chris
From: Paul Noone
<[email protected]<mailto:[email protected]>>
Reply-To: ozMOSS <[email protected]<mailto:[email protected]>>
Date: Mon, 22 Nov 2010 08:29:38 +1100
To: ozMOSS <[email protected]<mailto:[email protected]>>
Subject: RE: Help with 401 errors on public site
Hi Chris,
There is no way around this without writing a customer provider. We hit the
same issue and the decision was made to disable the feature to return normal
functionality and access to much needed list forms by users and search
botsalike.
There were two caveats around this:
1. Modify all list views to remove Modified and Checked-Out fields to
alleviate some of the privacy concerns.
a. I strongly suggest a coded solution using a provisioning feature at site
creation.
b. We additionally purchased a solution that allows us to permission fields.
2. Hiding the View All Site Content page.
a. Still haven't got around to this because I can't find a simple solution
that doesn't involved modifying the OOTB page.
b. Am considering creating a new page that requires authenticated users and
replacing the link to viewlsts.aspx with the new page.
Would be interested in hearing what solution you ultimately apply.
Regards,
Paul
--
Online Developer/Administrator,
ICT Projects Team
CEO Sydney
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Chris Howell
Sent: Saturday, 20 November 2010 11:21 AM
To: ozMOSS
Subject: Re: Help with 401 errors on public site
James,
Thanks for the response. AFAIK we are using the ViewFormPagesLockDown feature.
Some work was done previously with permissions but as I understand it, that
only resolved issues for internal staff accessing the site; the problem still
remained for external anonymous users.
Cheers,
Chris
From: James Boman <[email protected]<mailto:[email protected]>>
Reply-To: ozMOSS <[email protected]<mailto:[email protected]>>
Date: Thu, 18 Nov 2010 23:53:57 +0000
To: ozMOSS <[email protected]<mailto:[email protected]>>
Subject: RE: Help with 401 errors on public site
I know it might not be immediately helpful, but on the topic of 401's in
Internet facing sites there is something to be to be aware of that might be
contributing to your 401 woes...
If you use the ViewFormPagesLockDown feature (as all public facing MOSS sites
should) it has security ramifications such that if you break security
inheritance at the list or item level, Anonymous Internet users will lose
access (regardless of the permissions granted), and be presented with 401
errors.
It doesn't matter if you specifically grant access to the items/lists, and
toggle the Anonymous setting - Internet users will lose access if the Special
Permission level is not inherited.
So for Internet sites you must choose between
* Enabling the ViewFormPagesLockDown feature and living with web level
security only
* Not using ViewFormPagesLockDown and having all your system forms
available (like View All Site Content)
I logged an incident with Microsoft Support - and got the "By Design"
resolution.
Cheers,
James.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Chris Howell
Sent: Thursday, 18 November 2010 3:19 PM
To: ozMOSS
Subject: Help with 401 errors on public site
Hi,
We have a public facing internet site and we're seeing a lot of 401 errors in
Web Trends.
The errors are occuring for links such as:
http://www.oursiteurl.au/Pages/
We've got a couple of questions that we're looking to resolve so was hoping to
get some input from the list.
1. How do we find any links that exist within the site that are linking
directly to a /pages/ link as it appears that somehow people are being taken to
this from a link but we're not aware of them; all links we can find are to a
specific page within the library.
2. How have people implemented work arounds at the /Pages/ level to redirect to
the default.aspx page in the library and avoid a 401 error? I've found
somesites; the WA one being a very good example
(http://www.westernaustralia.com/au/Pages/Welcome_to_Western_Australia.aspx)
where this is done.
Anyone on the list had any involvement with that site or others and could share
info or point to resources?
Thanks in advance.
Chris
_______________________________________________ ozmoss mailing list
[email protected]<mailto:[email protected]>http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
_______________________________________________ ozmoss mailing list
[email protected]<mailto:[email protected]>
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
_______________________________________________
ozmoss mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
