Rob's Tech Fun and Games

I recently came across a need to publish a SharePoint site without authentication – effectively using anonymous access to the site.  Its surprisingly complex to set up correctly, especially if you are working with a secure ISA front end.

Share Point Configuration

First, you need to enable anonymous access for the entire web application, for every SharePoint zone.  Open the Central Administration site, and select “Application Management”.  Now select “Authentication Providers”.

When the Authentication Providers page appears, make sure you are looking at the right web application, then click on each zone, enable anonymous authentication, and click OK.  Once all the zones have been configured, the web application will allow anonymous access.

Just because anonymous access is available on the web application, it doesn’t mean its available on the sites!  You have to then set up permission on the individual sites.

In order to set the permissions on your site, you either need to go straight to the address:

http://yoursite/_layouts/setanon.aspx

Or go to Site Settings on the Site Actions menu, select “Advanced Permissions” from the “Users and Permissions” column, and then select Anonymous Access from the “Settings” option list.

Once there, simple tick to enable anonymous access!

If SharePoint is directly accessible, then you are done!  If, however, you are using ISA server to guard SharePoint, there are a couple more things left to do.

ISA Server

If you are using forms based authentication with ISA, then you need to bypass it for anonymous access!  Its not particularly surprising, but there are a few quirks when you set up your new rule and web listener.

First, it needs to be on a different IP address or port, otherwise you can’t create a new web listener.

Second, if you are restricting access to a limited IP address range without authentication … DO NOT SET UP AN EXTERNAL NETWORK.  Set up an address range, or all the configuration will fail.

Finally, if you set up a web listener, using the No Authentication option, and set the system to pass authentication through to the client,you must ensure that the option “allow client authentication over HTTP” is also ticked in the “Advanced” options within the Authentication tab on the web listener, otherwise all pages will show a 401 UNAUTHORIZED message if you access them without a username and password!

ISA Server 2006 is a strange, temperamental beast, and often needs to be cajoled into fairly standard functionality.  In order to deploy security so that users can authenticate from both the DMZ Active Directory, and the internal network (with a one way trust between the two) you need to deploy LDAP authentication.  In order to act as a secure front end and logging point, forms based authentication is recommended, particularly if branded authentication pages are important for you.  If you want to use it as a front end to extranet systems, a custom login page is pretty much a necessity, and if you need external users to change their passwords (rather than using code within your extranet or OWA), you’ll need to configure LDAP over SSL (LDAPS).

Before you begin, you’ll need to configure a domain user for ISA server to use to bind to the LDAP server, with rights to make changes if you need password change functionality.

You’ll need to ensure that your active directory domain can support LDAPS.  In order to do this, you need to intall certificate services, and ensure that the domain controllers and your ISA server all have server certificates installed, with the certificates matching their fully qualified domain names correctly. 

You can find a pretty complete guide here:

http://technet.microsoft.com/en-gb/library/bb794854.aspx

I struggled with a few points – its not clear that for password changes to work, for example, you need to use a user account with the right to make AD changes when defining the LDAP server set, and you don’t in order to simply log users onto the domain.  You apparently do in order to change passwords.

You can’t use windows authentication for any domains other than the one that the server is in, even if one way trusts are correctly configured – you really need to use LDAP server sets.  Thats not a problem if all of your internal users will access your secure extranet from the internal domain – you could bypass your ISA server and go straight to the web server.  However, people will want to give demonstrations, and work on the extranets from outside the office – its up to your policy to determine if this will affect the configuration.  Existing SSL VPN solutions might be a better option for your own employees.

Publishing SharePoint via ISA Server is fairly straightforward, even if you use SSL to the reverse proxy, and connect on port 80 to the SharePoint server in order to move the encryption load from your SharePoint box.

However, for some reason, this appears to break Telerik’s RadEditor.  In order to use RadEditor, you need to be able to connect directly to the server in the same format of the initial request, which means in the case of a secured SharePoint site, SSL.   Simply change the bridging rule to redirect requests to the SSL port, and disable redirection to the HTTP port.  This will place more load on your SharePoint servers – every request is encrypted via SSL between the SharePoint server and the proxy – weigh this load up against the editing benefits of RadEditor.