Showing posts with label VPN. Show all posts
Showing posts with label VPN. Show all posts

Sunday 20 May 2018

Azure Helper

Azure Services - Replacing Data Centres with "Azure Virtual Networks"
There are so many different services that are constantly being changed and new services added.  This info looks at using an "Azure Virtual Network" to replace traditional data centres.  This "Azure Virtual Network" scenario covers VM's, Virtual Networking (subnets and VPN's), Resource Groups and backups (Recovery Service vaults).

Replacement of a traditional data centre
Tip:  Virtual Networks is a service offered by Azure.  "Azure Virtual Networks" is my term referring to using Azure to host VMS on Azure that happen to us the Virtual Networks service.
  1. Hierarchy is "VM" assigned to a "VNet" that is in a "Resource Group" on Azure tenant.
  2. VPN creates an encrypted secure tunnel between an office location (from the router/or a specific machine) directly to your VNet, allowing the office to use the VM's internal IP addresses.
  3. Use the "Azure AD Domain Service" rather than a DC on a VM or on-prem/data centre to connect machines together.
  4. "Recovery Service Vault" allows you can set up customised policies to back-up the entire VM's.
Azure SQL

T-SQL to create a new login and assign permissions to a specific database using SQL Server Management Studio:
Use master
CREATE LOGIN TestReader WITH PASSWORD = 'Password';

USE AzureTimesheetDB
CREATE USER TestReader FROM LOGIN TestReader;
EXEC sp_addrolemember 'db_datareader', 'TestReader';

Add rights to the TestReader user to run a specific Stored Proc:
USE AzureTimesheetDB;   
GRANT EXECUTE ON OBJECT::uspGetTimesheeyById  
    TO TestReader ;  
GO 

Azure Virtual Desktop/ Azure VDI

Microsoft Azure Virtual Desktop (AVD), previously called Windows Virtual Desktop (WVD) is Microsoft's Azures implementation of VDI (Virtual Desktop Infrastructure).  The most common VDI I came across is Citrix Virtual Apps and Desktops (CVAD).  VDI provides a user with a remote desktop instance so a user has their desktop apps and setup from anywhere without need a local laptop build. i.e. don't need to have a full laptop/client machine locally.  The machine is instead hosted as in AVD's case in an Azure Data Centre and the user logs in with their network credentials and gets their instance to work on.  No need to build laptops and easy to move laptop for the user.  Laptop is no longer a risk as the data is held in the data centre.  

Tags

I'm not a huge fan of tags, even in complex environments I find naming the resources and arranging the resource groups logically pays a high return.  One exception I use is I tag a common tag "Environment" on all my enterprise resources.  This allows me to quickly filter for production or test environment resource only with the Azure Portal.

updated: 2021/07/07 Azure Data Studio

Azure Data Studio can be used instead of SSMS to look at and query SQL database. 

Friday 22 October 2010

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.