Azure Application Gateway Basics

Azure Application Gateway is a http traffic load balancer that allows me to manage my web traffic.  So based on urls, paths, the traffic can be pushed on accordingly.  It also provides for sticky sessions.  In my head I see Azure Application Gateway as a layer 7 HTTP Load Balancer and a Web Application Firewall (WAF).  There are 3 core concepts: Front-ends, rules and backends that are used to route traffic from the front-end to the back-ends.

Azure Load Balancer works at level 4 where Azure application gateway is for web traffic at layer 7 of the OSI model.

Azure Front Door is basically for world wide Application gateway functionality.

Checklist on the Application Gateway: 

• You should enable the WAF unless you already use another WAF like Imperva enterprise wide, do this under the "Web application firewall" option, setup OWASP rules.  
• Config session affinity, and HTTPS termination using the "HTTP settings".  
• "Listeners"  are what listens for incoming http requests.
• "Rules" bind the listeners to the backend pools.
• "Backend pools" are used to point traffic to the end points.  Also remember to setup "Health Probes", this allows the App pool to verify the backends are working.
•  Ensure you set the diagnostics logging to send logs to "Log Analytics" so you can examine the logs.

Features: 

1. SSL/TLS termination - Terminate SSL using certificate
2. Autoscaling - increase the size or instance count based on traffic requirements
3. Can be setup to be zone redundant
4. Static IP address that doesn't change
5. WAF and DDoS (pretty new 2022, applied using Azure DDoS Sentinel service) capabilities - The WAF allows you to apply OWASP rules and add additional custom rules.  Bot protection is also built in, rules need to be applied to get it to work.  
6. URL-based routing
7. Multiple domains/site hosting
8. Redirection
9. Sticky sessions/session affinity
10. HTTP/2 support
11. Custom error pages (so useful)
12. Rewrite headers and URL

References:

How an application gateway works | Microsoft Docs

WAF options

TLS 1.2 and SharePoint on-prem.

Problem:  By default SharePoint 2016 and SP 2013 use TLS1.0 for its communication protocol (think SSL version number).  A lot of companies and partners are now insisting your internal SharePoint farms support TLS 1.2 and not the earlier versions.  For various compliance frameworks (DSS PCI, HIPPA) you need to ensure you no longer use TLS1.0 or 1.1 and only support TLS 1.2 and soon to be TLS 1.3.  The problem is that earlier versions have potential vulnerabilities and can lead to various attach including being susceptible to man in the middle attacks.

TLS/SSL Basics:

Three Areas of Concern:

1. SharePoint Farm (upgrade to SSL across the farm, Supports TLS 1.2 on SP2010 & 2013 since +_Oct 2016) - biggest lift
2. CSOM Client VM (Ensure the client VM can send TLS1.2) - Jump boxes, browser
3. Ensure the Communicating App support TLS1.2 (Either .NET4.6.2 compiled apps default to TLS1.2 or problematically enforce the TLS order/version. 

Our business needs three parts:
1. SharePoint farm upgrade thru DTAP environments and Test
2. Calling application needs to use TLS 1.2 as the default and can potentially call backwards.  This includes IE/Chrome, calling CSOM code (either fix works: .NET 4.6.2 upgrade or pragmatically enforcing TLS), PowerShell
// C# CSOM programmatic fix to TLS inaccuracies
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls | SecurityProtocolType.Ssl3;
3. If your tools are on a Server ensure outbound TLS traffic is allowed.  IIS TLS settings affect both inbound and outbound traffic, overwrite the outbound if you need to in the registry.

Validate SSL SharePoint Web Front End:
Use PowerShell to check the WFE or an external tool like HTBridge.
Here is a great tool to look at your HTTPS web server/endpoint setup externally: https://www.htbridge.com/ssl

Tip: Removing TLS1.0 and 1.1 needs to be thoroughly tested as there are numerous dependencies such as OWA, Workflow, CSOM, Internal Comms, SQL Server.

Testing my SharePoint 2013 Network Load Balancer

Overview:  This is how I tested my Kemp load balancer.  Kemp terminates the SSL and has a load balancer that checks the http service is running.  I still like to use session persistence for load balancing.

Fiddler is useful from the client, you can check that SSL is getting correctly written by the Load Balanacer. 
Microsoft Network Manager 3.4 is useful to watch the traffic between the WFE and the load balancer.  WireShark is also good option.  This role would probably best be performed by using Fiddler as a reverse proxy to capture the traffic (I never done this).


SharePoint 2013 has the Request Management Service that acts like a load balancer for traffic.  I don't understand the point and I would need a rather strange scenario to use Request Management if I have a decent load balancer in place (KEMP or F5).


Updated 17 Aug 2015: All the Load balancer solutions (F5, Cisco, Kemp etc.) have traffic distribution, it is a good idea to use a more advanced algorithm.  For instance using an F5, setting to use the "Dynamic Ratio" algorithm redirects traffic based on continuous monitoring of the servers resources.  F5 has many options I prefer using the "Dynamic Ratio" but it depends on the circumstances.

Load balancing in SharePoint

Background: SharePoint 2010 required sticky sessions.  In effect when the 1st request from a user comes into SharePoint 2010 to the load balancer, the request will be directed to a particular SharPoint WFE server that will then serve the subsequent requests (the user now has session affinity/sticky session).

SharePoint 2013 has distributed cache so you no longer need to use sticky sessions, the load balancer merely needs to direct the user to any server (preferably the quietiest).

Possible options for Load Balancers in SharePoint:
F5/BIG-IP (Level 2, 3, 4 &7)
KEMP (Level 4 & 7)

Barracuda (Level 4)
Cisco - I don't think Cisco build dedicate load balancers and more however "Cisco IOS-based router product has load balancing capabilities".
Not familiar with:
http://www.coyotepoint.com/products/compare
http://www.radware.com/Products/ApplicationDelivery/AppDirector/load_balancing.aspx
http://www.a10networks.com/resources/files/DG_MS-SharePoint2013.pdf - NLB and SSL termination.

Key features needed off a Load Balancer:
Distributed Denial of Service (DDoS) attack protection
Http compression
SSL acceleration/ and termination
Persistance/Sticky sessions
HA via distribution of requests and verifying that SP is running.
 

Fiddler Tip - view https traffic

Problem:Need to see https traffic between the browser or any client application and the web server.

Inital Hypothesis:  Use fiddelr to trust the sites public certificate so that https traffic can be monitored.

Resolution:  Open Fiddler
Tools >Fiddler options > Https > Decrypt https traffic.  Accept the popups.

Updated 2017-06-02: Screens have changed slightly.

Update 2023-06-22: Auto responder - allows me to inject a local file instead of a network file, in the example below, I overwrite, making the developer loop much easier, and I can develop faster.

Streamline JavaScript web resource development using Fiddler AutoResponder (Developer Guide for Dynamics 365 Customer Engagement (on-premises)) | Microsoft Learn

Issue in Document libraries in MOSS using Word 2010

Problem:  The business upgrades there Office desktop version to Office 2010.  If a user needs to add new documents into a document library running on MOSS.  Word 2010 opens and then throws the error "This file could not be found.".

Initial Hypothesis: Office(Word) 2007 and Office(Word) 2003 can create the new documents.  Office(Word) 2010 can edit a document added by a previous version or an uploaded document correctly.  The issue appears to be between Word 2010 and document libraries in MOSS when adding a new document under SSL.

I can open the full url to the word template correctly using IE and Word 2010, so the issue must be with the url that is crafted for Word 2010.

I was looking at the templates associate with each content type in my document library, the path is always relative however, as I am adding the the template it stores a relative value.

Resolution: The url that is requested using the new document derives from the content type's default document template.  My site uses SSL, and it looks like the path that SharePoint generate is incorrect (I need to confirm this using fiddler, but as I'm on my clients site using a locked down workstation and no access to the servers I can't see the url being generated).  Anyway, my fix is to save the full https path in the "Enter the URL of an existing document template".

Extranet user access options - Farm architecture design considerations

Problem: What is the best approach for an extranet?

Hypothesis:
You are implement SharePoint 2010 and you need users to have remote access, the 2 key technology impact areas are:
• Authentication to SharePoint 2010; and
• Remote access mechanism (External users).
I will deal with each question separately for simplicity.

Authentication
SharePoint 2010 has 2 mechanisms for authentication: classic (MOSS approach) and claims based. I would almost always recommend using Claims based authentication as this allows you to hook into any credential provider such as LDAP, AD, SQL or a custom provider. For example a recent project involved authentication from Active Directory & an IBM LDAP provider, this was relatively easy to do using claims based authentication.  If you have a custom Single Sign-On (SSO) solution you can write your own claims provider.
Remote Access
The answer for where to deploy SharePoint is … “It depends on what you have currently, your licencing and security requirements.”

Option 1
You can put SharePoint in your DMZ (public area) and use a reverse proxy and allow users access to you SharePoint farm. You will probably want to use SSL between the external end users and the reverse proxy.  The traffic between the SharePoint Farm the proxy won’t be under SSL. This approach is good for easy access, high performance and easy setup. This approach is not as secure as getting users to login to your network using VPN access. The advantage is you merely need SSL setup (my preference is firewall SSL termination i.e BlueCoat, most hardware firewalls offer this including F5’s Big-IP, you can also use the latest ISA/UMG proxy software to do SSL termination. Microsoft’s ISA 2006 has SSL termination built and is a pretty good solution. I believe UMG is the update to ISA.  SharePoint requires sticky sessions so if you are using a hardware or software based load balanced, you must have sticky sessions enabled.

Option 2
Another option is to use SSL NIC’s or my least favourite but most commonly used option is SSL on the server. You can still have your firewall in place but you don’t use a reverse proxy. I would definitely go for a reverse proxy with external access over SSL but this options is available on smaller SharePoint farms.  You can also load balance using NLB.  SSL adds about a 35% overhead to CPU resources on the server and SSL NIC cards can drastically improve CPU utilisation, however I would prefer to terminate at the firewall if possible.

Option 3
VPN solutions – Either IPSec or SSL-VPN’s are a good option but it depends on your infrastructure as setting up a VPN is a program in itself. Remote offices are already on VPN or some tunnelling technology but this doesn’t work for home users or 3rd parties as you need to give them remote access which generally involves RSA token or some sort of security token. This is the most secure option and once a user is on the network they will access your private SharePoint farm over http.

Resolution:  The general answer as always in SharePoint is "It depends ...".
I would recommend profiling all type of possible users something like

Role: Head Office User
Description: Http access from the LAN authenticating using AD.


Role: Satellite Office User
Description: Remote office has a VPN tunnel/MPLS to the head office, employees are authenticated using AD and will use http to access the SharePoint farm.

Role: Employee at home
Description: http (SSL-VPN) AD Employees have SSL-VPN access and once connected used http to view the SharePoint farm.  Authenticated using AD.


Role: 3rd Party users https SQL database or AD
Description: Suppliers need to with SharePoint, they will access 2 SharePoint load balanced servers in the DMZ using https.  The firewall is an ISA server 2006 which offers SSL termination and host header redirection.....

You can also surface the same site using different urls, so have an internal site and then a site in the DMZ.

When doing your farm architecture other points to bear in mind are redundancy, performance & licencing.  This coupled with your existing technology status and your SharePoint will provide a accessible, stable, scalable, preformant, secure SharePoint farm.   Designing your farm will reduce you licencing costs dramatically while providing the best solution to the business.