Rob's Tech Fun and Games

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.

The SharePoint usage reports, once enabled, look extremely pretty, but are generally pretty meaningless unless you are dealing with absolutely huge numbers of hits, where averages and graphical representations are the only effective way of dealing with information.  However, there are two report pages that are extremely useful, particularly for slightly smaller sites, that can’t be reached through the GUI interface in MOSS 2007.   They are actually from the basic WSS system, and MOSS inexplicably misses out any direct reference though the administration pages.

The second of these, usage details, is brilliant for tracking usage of a site, showing which users have accessed the site on which days over the last month.  Its invaluable as a quick security check to make sure no unexpected users are accessing the site!  The permissions system in SharePoint is pretty robust, especially if you’ve stuck to SharePoint and AD groups to assign rights, but its always possible for oddities to happen.

Having read various papers on this over the course of the day (the most useful can be found here), it seems pretty clear – the SharePoint security structure is hard to maintain!

Here are some key recommendations for a maintainable structure:

• Focus on using Active Directory to maintain your security structure.  Set up groups in Active Directory, and assign them to SharePoint groups in your site collection.  Don’t assign users to SharePoint groups – assign users to the right groups in Active Directory, which will automatically filter through into SharePoint.
• Active Directory has a wide selection of APIs and tools to manage group membership – if you need to handle security changes programatically, you’ll find it much easier in AD than SharePoint.
• Always use Domain Local groups in Active Directory to assign to your SharePoint group.  This is not only best practise according to standard Windows recommendations, it also allows you to use users from a different domain over a one way trust.  Universal and Global groups are limited to your domain and forest respectively.
• SharePoint’s People Picker is quite powerful.  If you need granularity beyond simple groups, you can assign specific access to individual users where needed, but your administration demands will go up.  Try not to break inheritence rules without VERY strong business drivers, as maintaining security after that point is extremely difficult.
• For a simple extranet structure, using the default SharePoint groups is fine – most external users are visitors to the site, unable to make changes.  Internal users are members, able to update teh site where appropriate.  IT staff tend to be Site Owners, in order to maintain the site structure.  This is actually quite flexible, especially if moving between the groups is simple through Active Directory group assignments.