SharePoint 2013. Enable anonymous access

Этот пост доступен на русском языке здесь: http://blog.vitalyzhukov.ru/ru/sharepoint-2013-enable-anonymous-access.aspx.

8/28/2012

Step by step instruction how to enable anonymous access for web application based on SharePoint 2013.

Central Administration

First of all, it's necessary to enable anonymous access for SharePoint 2013 web application. In central administration go to web applications list (Application Management - Manage web applications) and select the application you need to enable anonymous access and click Authentication Providers button on the ribbon:

On the popup window select zone to set providers for it. In my case there is only one zone - Default:

Enable anonymous access for selected zone:

Anonymous access is enabled on web application level. In additional you can set policy for anonymous users. The policy may be these: none, deny write and deny all. For set the policy click Anonymous policy button on the ribbon:

Site settings

Anonymous access is enabled for SharePoint 2013 web application. Now we can set permissions for anonymous users on sites. For this on Site Permissions page (Settings - Site settings - Site Permissions) click Anonymous Access button:

And select acess rights:

View lists and items

In spite of anonymous access is enabled anonymous users can't view lists/document libraries and items. To resolve this it's necessary to add ViewFormPages right for site using AnonymousPermMask64 property of it:

Now anonymous acces is enabled for the site and anonymous users can view lists and items:

SharePoint 2013 | SharePoint Security Author: Vitaly Zhukov

 

Gravatar
Alec D

THANK YOU! I'm new to Sharepoint and this was bugging the heck out of me. Turns out i was in slightly the wrong location!

Gravatar
Vitaly Zhukov

Alec D, I'm glad that my post is useful to you!

Gravatar
Patrick

Impressive vitaly. Zdrowo!

Gravatar
Jahanzaib

I have to say I find the discussion rniardgeg Folders vs. Metadata always interesting. Keeping it brief, I must say I am in complete agreement witha0Chris. I base this on the fact that there seems to be 2 big issues that users deem folders are necessary for: Security and Large list issues. Now we all may not agree on usage and settings and the little eccentricities of SharePoint I have to be clear about Security and Largea0Lists.You can have an extremely large number of files/items in a library or list. The most I have personally seen is in the range of 157,000 items (Library). The default view presents 50 of the most recent documents only. The results populate across the WAN half a world away in about .34 seconds. All the documents may be retrieved based on Folder Names (not real folders but what their team decided to call their metadata column), dates, authors, and up to 6 other metadata items. Their longest list returns 4,500 items (only 3 exceed the recommended 2,000 item limit) in just under 4 seconds across WAN, half a world away. I think that mystery is solved.Finally — security. Why an organization would find it necessary to manage the security of 10,000 separate items is beyond me. I guess it happens though. The same goes for folders. Why would yo want to manage information on that level? Document management, collaboration, processes, and Information management are but a few issues that come into play with SharePoint. IF a company has developed some sort of folder structuring system where many of their documents are managed and secured at folders levels then they have not been led down the right path by their consultants. OK, I will admit, I have used folders, but for very limited reasons, and never for security purposes. It has been mostly for archival purposes. How I overcome the security problem is through information architecture. What are the items, who uses the items, how often are they used, when are they used, how often are they reviewed, appended, changed, and finally when is it considered archivable.If an organization plans their document structure company wide, I will guarantee you that the structure will not lend itself readily to folders, but to Sites and Libraries structured around security, usage, need and the type of information. As an example, I finally had a department of a particular client come to me after using SharePoint for 2 years with their information stored in several libraries under several sites and THOUSANDS of folders. In some cases the structure was 10 levels deep. At the time it was what they wanted and there was no arguing them out of it. When they came to me they begged for restructuring. Security was bombing out because they couldn’t keep ahead of the changes. People were storing documents anywhere they thought was right. They had 5 levels of security but based on their design you would hav ethought there were 500. When we finished, they had 7 Sites, each secured at the site level only as libraries inhereted from the site. 2 of the Sites were Portals where other users could accesss cross department information. No more than 7 security groups used to manage security and at the site level only. No woperational for 6 months with no permisisons issues reported and not 1 single folder in use. So here is to metadata, long live metadata.