Random SharePoint Administration Thoughts

Random SharePoint Administration thoughts… In no particular order.

Disable SSL 3.0 in SharePoint 2010 and 2013; SSL 3.0 through TLS 1.1 for SharePoint 2013.

Use SSL everywhere. There is no reason not to. Use SNI, if appropriate. All browsers supported by SharePoint 2016 also support SNI. Certain browsers supported by SharePoint 2010 and 2013 do not support SNI, but you shouldn’t be using those anyways.

Use SSL Bridging, never SSL Offloading. SSL Bridging is a “man-in-the-middle” appliance that decrypts the user’s session but re-encrypts the session before sending it to the destination server. SSL Offloading should be considered insecure for SharePoint. Services like Office Web Apps 2013, Workflow Manager 1.0, Exchange Task Sync, and SharePoint Apps leverage OAuth2 tokens. OAuth2 tokens are insecure and can be replayed if intercepted.

Use the Windows Firewall. There’s no reason to not do so. SharePoint creates (most) the Windows Firewall exceptions.

Think twice about using SAML. There are many user experience issues (namely the People Picker) and Business Intelligence is problematic. If you want to use ADFS for Single Sign On purposes, use ADFS 3.0 (Windows Server 2012 R2) using a non-claims aware relaying party. This allows you to continue using Windows Claims on SharePoint.

Use Kerberos on SharePoint Web Applications*. It’s simple! setspn -S HTTP/webAppUrl.company.com DOMAIN\iisAppPoolAccount. And of course make sure Kerberos is selected in the Authentication Provider settings. Kerberos is faster and more secure than NTLM. *certain cross-forest restrictions may apply

And speaking of Kerberos, always enable Kerberos for SQL Server. Again, simple. setspn -S MSSQLSvc/sqlServerName.company.com:1433 DOMAIN\sqlServiceAccount  and setspn -S MSSQLSvc/sqlServerName:1433 DOMAIN\sqlServiceAccount . Just remember, local connections to SQL (e.g. running SSMS on SQL Server) will continue to use NTLM authentication.

Stop Service Instances and delete Service Applications you’re not using. Not sure what you’ll use on a new deployment? Only deploy Managed Metadata Service, Search Service, and the User Profile Service Application. Nothing else. Start Service Instances and create Service Applications as business requirements call for it.

Keep Web Applications to a minimum. Two is preferable when MySites are being used (one standard Web Application, the second dedicated to MySites).

Keep Application Pools to a minimum. A single Application Pool for all Web Applications, and a single Application Pool for most Service Applications.

Keep Managed Paths to a minimum, with a maximum recommended of 20. Each request is evaluated against the Managed Paths, so the fewer you have, the better the performance.

Consider following the Streamlined Topology architecture. Sure, it isn’t 100% reliable with SharePoint 2010 and 2013 (due to the topology service sometimes routing requests to another server anyways), but in SharePoint 2016, the topology service is “smart” and will route requests locally when the service runs locally.

Not using the User Profile Synchronization Service? Your Farm Admin service account does not need Local Administrator rights! Using the Claims to Windows Token Service? Create a dedicated service account for it. This account must have Local Administrator rights (along with specific User Rights). No other account needs Local Administrator rights.

Always run the Foundation Web Service on all servers. It helps with solution deployment and Security Token Service issues, plus there is no reason to not do so. Have some ISV telling you that you need licenses for all servers running Foundation Web? Just tell them that you only have n number of services filling that role in the farm, they’ll often understand and make an exception.

Always test SharePoint security hotfixes. Those hotfixes contain fixes from non-security updates, typically from the previous month. This means security updates may introduce regressions, or just outright break things.

Don’t use Microsoft Network Load Balancer. It’s a poor solution for your load balancing problems. If free is a big deal, consider something like Apache’s mod_ssl or HAProxy. There’s plenty of fully free solutions.

Those are just some of my random thoughts about to-do and not-to-do if you’re building or maintaining a farm. What would you add to this list? Comment below!

23 Comments

  1. Great list! Another one I would add is to run Central Administration on a *real* URL and secure it through SSL.

  2. more than 1 server? configure CA for HA.

    Group policies for the end users (IE intranet zone, auto auth WebClient). Use them.

  3. When you say “Keep Web Applications to a Minimum” are you referring to utilizing Host-named Site Collections?

    • HNSC is of course a potential use case, but what I would advocate for is a single Web Application for portal/team/etc. sites and a second one for MySites. Obviously this won’t be for all orgs, but is what I would deploy to an org who is not quite certain what they want to implement yet.

  4. Understand however, I have been testing the DLP in SP2016 and noticed that I could not create a DLP Policy Assignment for Site Collections that referenced a Site Collection in a Web Application other than where the “Compliance Policy Center” had been created. Either it is a bug, which it could be since its not RTM, or its by design which leads me to having only one Web App.

  5. I’d avoid Kerberos unless is an absolute requirement.

  6. I have a question why you need SharePoint Foundation Web Application in your application servers like dedicate search servers or the servers contains central admin i know that it can take from the server resources so why you need to make it run in servers not using it?

    • For one, running it on servers that aren’t taking end user traffic, there is minimal overhead for doing so. Two, certain types of solutions (namely timer jobs) which rely in the Foundation Web service and are configured to run on any server in the farm may fail if the service isn’t running. Of course, you could put checks in just to make sure the timer job detected the Foundation Web service was running… either way. Just leaving Foundation Web running is easier.

  7. Hi Trevor, what do you mean by a “non-claims aware relying party” in ADFS for SharePoint?

  8. Kerberos on SQL – also remember to put SQL on a static port

    Kerberos in general – if you’re not the domain admin, configuration changes (adding SPNs and Allowed to delegate to) can be a bother as it needs asking someone else to do it. Also remember to klist purge all tickets to avoid headaches. My script for that:
    gwmi Win32_LogonSession | ? {$_.AuthenticationPackage -ne ‘NTLM’} | % {
    $FullLogonId = [Convert]::ToString($_.LogonId, 16).PadLeft(16, ‘0’)
    $HighPart = $FullLogonId.Substring(0, 8)
    $LowPart = $FullLogonId.Substring(8, 8)
    klist purge -lh $HighPart -li $LowPart
    }

    Still kerberos – remember to give your machines “trust this account for delegation”. Helps a LOT with powershell remoting (you don’t need CredSSP).

    Web App service on all servers – remember that your full trust WSP will deploy on all Web App servers so adding unnecessary ones makes deployment longer. With a continuous development of over 50 WSP packages (my scenario), every minute per WSP matters.

    Admin doesn’t need local admin – wrong, it’s needed for certain diagnostic tools. If all your admin does is call MS whenever something goes wrong, OK, but it can be done better.

    Using SAML – true, some services still need classic (search, powerpivot) and that can easily lead to a misconfiguration, where your users have two accounts – one windows and one from ADFS (“i:0#.w” vs. “i:60.t|providername|”)

  9. Hmm. The “Consider following the Streamlined Topology architecture” has My Sites included in the Single web App Topology, but I would only want Self-Site Creation for MySites and not anything else, or is that no longer an issue. I’m speaking strictly for SP2016 which we will deploy when its released.

    • Oops, I didn’t mean the Streamlined Topology, I meant the “SharePoint 2013 Design Sample Corporate Portal Host-Named Sites” Visio Diagram that Microsoft has published.

  10. Regarding SNI – One good reason to NOT use SNI is that the the MS WebDav client does not support SNI. You will get errors when using the SharePoint ‘Open with Explorer’ feature with SNI. See this post, for example: https://www.vioreliftode.com/index.php/microsoft-windows-webdav-client-does-not-support-server-name-indication-sni

  11. I agree – In a perfect world, I wouldn’t want users to use ‘Open With Explorer’. However, that’s not something that admins can control out of box, and in my experience, there is always going to be a subset of users that come from a ‘file share’ background, that just want to map a drive, and use SharePoint as a file share (they don’t care much for versions, metadata, content types etc)

    The saving grace is that ‘Open With Explorer’ uses ActiveX, so at least users using FireFox, Chrome, Edge etc don’t have that option :)

  12. Wow, really great thoughts! Thank you to Trevor and all the commenters for sharing!

  13. Thank You for interesting advices!

    >>What would you add to this list? Comment below!
    I prefer to add local admin to “Farm administrators”. Someone can say that it is a security hole, but I had one case when DC crashed on holidays, and I was able to login under the local admin and do something with farm.

Leave a Reply