VPN

Windows 10 Build 10122

Richard Green on

As we know, I’ve been running the Windows 10 Technical Previews on my daily driver laptop, a Dell Latitude E7440 provided by work since the first builds and there have been moments of greatness as well as moments of sadness.

The defining moment of sadness came with Build 10049 when the Cisco AnyConnect VPN client ceased to work due to stack changes Microsoft were making to the networking. It’s understandable that changes like this would occur but it was an inconvenience too. I resorted to enabling the Hyper-V role on my laptop and running a Windows 8.1 virtual machine so that I could get to my corporate resources.

I reached out to Cisco on Twitter at the time and they responded that they were aware of the issue and they were working with Microsoft on it. Fast forward to present time and I installed the update to move to Build 10122 last night at home after Windows Update prompted me that the update was available for download whilst in the office yesterday.

Cisco got back in touch with me last night with the following response.

The fact that Build 10122 allows VPN clients to function against is obviously positive news but I wasn’t going to build a-fresh with an unofficial .iso built from the .esd file download in part because I don’t want to have to reinstall and re-configure all my applications but also because there are threads circulating online that Windows 10 will fail to activate if it was built using an unofficial media.

You can probably therefore imagine my surprise when after doing the upgrade, I found that the Cisco AnyConnect client in fact was actually working and I responded to Cisco accordingly.

Given that their initial statement was that this would require a fresh install to work, I have no doubt that I could be in an edge case and that some people may still find this to be now working however I want to point out that I hacked or modified nothing to make this work. I didn’t previously have AnyConnect installed due to it not working so this was a clean install of the AnyConnect 3.1.05182 client package.

Although this post largely centres on my relief that VPN is now working, I am having an issue with Cortana right now where she doesn’t want to acknowledge the UK as a functioning region even though I have all the relevant language and speech packs for en-GB installed. Working from home today, when I connected my laptop to my Lenovo USB 3.0 Dock, I also found that ports on the dock weren’t detected the first time around. I had to connect and disconnect a couple of times before the Ethernet and DisplayPort connections for my screens were detected but it is all working okay now.

All in all, I’m pretty happy with Build 10122 thus far and it seems like we are slowly working towards a solid build for RTM. If only the same could be said for the current crop of Windows 10 Phone builds.

Deployment Scenarios for Office 365 and AAD Identity

Richard Green on

In my previous post from yesterday on understanding Office 365 and AAD federated identity types, I talked about the two methods for allowing our users to sign in to the Microsoft cloud services with our on-premises identity using either DirSync, AADSync or FIM for same sign-on or using ADFS for single sign-on. Now that we understand the products at a high-level, I want to cover off some options for deployment scenarios and specifically, how we can leverage Microsoft Azure to host these services.

Customers are increasingly trying to cut the cord with their on-premise datacenters due to the high cost of running them and are looking for cheaper alternatives to run their services. Moving our email, collaboration and communication productivity tools to Office 365 is one way that we can work towards achieving that however in consuming these Office 365 services, we remove the need for having our on-premises Exchange, SharePoint and Lync servers but we replace them with servers that are used to synchronise our identities to the cloud or provide the authentication tokens. If these servers go down it could actually have a more detremental effect than the loss of an on-premise Lync server so we need to pay close attention.

On-Premise Deployments

DirSync, AADSync and FIM for Same Sign-On

If you have opted for a same sign-on deployment then unless you have a specific need for FIM because you have a complex infrastructure or if you have already deployed FIM and want to leverage that existing investment you will be deploying DirSync or AADSync. DirSync is the incumbant tool and AADSync is its replacement although DirSync is still supported and will continue to be supported for a currently undefined period of time so if you have already deployed DirSync then you don’t need to rush out and upgrade your servers to AADSync.

AADSync On-Premise

None of these products, DirSync, AADSync or FIM support clustering or high availability which means you can deploy only one of them at a time. FIM can be sweet talked into working as a clustered product but the process is unsupported and documented by Damian Flynn at http://www.damianflynn.com/2012/10/11/fim-sync-server-2010r2-cluster-build/. If you want to provide high availability for these applications then you will need to look outside the operating system and look to your hypervisor, assuming you are deploying them as virtual machines.

For DirSync and AADSync, the easiest thing to do will be to have a disaster recovery plan and a build document for the installation so that if you’re server melts, you can deploy a new one from a VM template in short order. If you were extra paranoid, you could have a VM deployed with the DirSync or AADSync binaries on the server ready to install (but not installed) so that if you had a failure you could simply run through the installer following your build document and be up and running in about 15 to 30 minutes.

For FIM, you definately want a backup of this server because a) its not highly available and b) there are complex configurations going on here and tryring to re-create this from scratch as we would likely do with DirSync and AADSync wouldn’t be fun nor quick.

ADFS for Single Sign-On

As we know from my previous article, deploying ADFS is more involved and requires more moving parts howeer luckily, all of these parts can be clustered or load balanced accordingly. The exception to this is the DirSync or AADSync server that you deploy in addition to the ADFS servers to sync the users identities but not the password attribute to go with it.

ADFS On-Premise

ADFS Proxies which reside in your DMZ network segment are essentially web servers which can be load balanced. We only require Port 443 for HTTPS SSL pages to be made publicly accessible and we can use either Windows native NLB or we can use a hardware or software load balancer such as a Citrix Netscaler, KEMP Loadmaster or an A10 Thunder load balancer. As a side note of interest, Citrix and A10 both support integration into VMM so if you are using a Microsoft private cloud with Hyper-V and VMM in your on-premise network then these products can be easily integrated into your deployment approach for new servers.

ADFS servers live in your clean, corporate network and route requests between the proxies in your DMZ to the Active Directory domain controllers to retrieve the authorization for users. The ADFS servers use a Windows Internal Database (WID) as standard which supports farms of up to five ADFS servers however if you need more than five servers, you will need a seperate SQL Server for the database which we can of course cluster.

Azure Deployment

DirSync, AADSync and FIM for Same Sign-On

As I mentioned earlier, companies are interested in cord cutting the on-premise datacenter as we know so moving things into the cloud where it is possible and makes sense helps us to achieve this and more importantly, reduce the dependancy on our internal facilities. With DirSync, AADSync and FIM deployments for same sign-on, we can really easily achieve this with Microsoft Azure.

AADSync Azure

The components that make this design work are the Azure VPN which provides site-to-site connectivity between your on-premises environment and Microsoft Azure. Once you have the Azure VPN configured and working and you have your virtual network segments configured in Microsoft Azure, we need to deploy an Active Directory Domain Controller into Azure using an IaaS VM. This will hold a replica of your Active Directory database from on-premise. We then deploy the DirSync, AADSync or FIM server on an IaaS VM in Azure.

By deploying the synchronisation VM in Azure along with the domain controller, the two servers are within the same AD Site which you will have created for Azure and will allow the synchronisation server to contact AD for the user data it needs and will allow it very fast access to the Azure Active Directory service to sync your objects to the cloud directory.

For high availability in this design, we can deploy multiple Domain Controllers into the Azure AD Site and we can use the Azure VPN service in a point-to-multi-point configuration so that two of your on-premise datacenters have an endpoint for the Azure VPN so that we aren’t dependant on a single site for on-premise connectivity. Remember that with this same sign-on deployment, we can only have a single synchronisation server so it is not possible to make this element highly available. When we deploy multiple Active Directory Domain Controllers into Azure, we need to make sure that these VMs go into an Availability Set together which causes the Azure fabric to place these VMs on seperate hosts and racks in the environment so that they are not effected by maintenance operations.

ADFS for Single Sign-On

Using Azure to deploy our ADFS for single sign-on deployment really is the way to show case the power and ease at wihch we can deploy a complex solution with Microsoft Azure. The building block of this design is the same as that of the DirSync and AADSync in that we start out with configuring Azure VPN in a point-to-point or point-to-multi-point connection to our on-premise environment and we then deploy multiple Active Directory Domain Controllers which provide our authentication source.

ADFS Azure

In deploying SSO with ADFS, we need to configure, deploy and test the ADFS environment before we deploy and configure the DirSync or AADSync server. I must atest to not fully understanding the reason for this but Microsoft recommend it so we do it. As you would do for an on-premise deployment, we deploy two ADFS Proxies which recieve our incoming token requests and we deploy two ADFS Servers which do the back and forth between our ADFS Proxies and the AD Domain Controllers to authorize users.

As we did with our previous same sign-on design for a Microsoft Azure deployment, we need to make sure we place our IaaS VMs into Availability Sets however this time we have three sets: one for our Domain Controllers, one for the ADFS Proxies and one for the ADFS Servers.

With an on-premise deployment, we need to buy and configure a load-balancer to use with the multiple ADFS Proxy servers however in Azure we can simply use the Azure Load Balancer to quickly and easily achieve this.

With the ADFS for single sign-on deployment in Microsoft Azure, if having two VMs running for each service isn’t quite enough availability for you because you are concerned about the resiliency that Microsoft provide within a single Azure datacenter, you could take the deployment to another level and use two datacenters. Using two Microsoft Azure datacenters, we split the services provided by the deployment throughout the Azure environment and use the Azure Traffic Manager to provide Geolocation awareness for users and direct them to the most appropriate ADFS Proxy for authentication. If you are deploying ADFS for single sign-on in an organisation which has users throughout the globe then this could be an ideal deployment to achieve not only your high availability requirements for IT but also to improve the user experience by sending the user to the ADFS Proxy closest to them.

Cost Consideration

All of this talk of Azure deployments is very nice but we need to be aware of our costs. Deploying services on-premises has costs associated and these costs are often a lot higher than people realise because they don’t fully take into account every facet of the infrastructure. When you are costing up an on-premise VM you will likely include the cost of the SAN disk occupation or the percentage of a host it occupies and the host of that virtualization host but are you factoring in the amount of extra power that server will consume as a result of the extra CPU cycles or the fraction of load that adds to your UPS or your network switches?

Implementing a simple deployment of DirSync or AADSync will be very cheap and I would challenge any enterprise to be able to do it themselves cheaper. A single datacenter deployment of ADFS for single sign-on will cost more to implement than same sign-on due to the increased number of servers and the addition of the Azure Load Balancer however that cost will double if you extend that to a dual Azure datacenter deployment not to mention the increased configuration complexity.

To conclude, make sure you consider the cost and complexity of what you are proposing to implement and make sure that what you plan to do is really what you need to do. If all your users are based in the UK then having that all sining, dual datacenter, multi-point Azure VPN deployment split across the UK and East Coast US with Geolocation Traffic Management probably isn’t what you really need and you will be wasting resources in both money to pay for it and time and complexity to manage it.

The Forgotten Cost of Microsoft Azure Networks

Richard Green on

We all know cloud services cost money, that’s a no brainer because we are consuming resources in somebody else’s environments, but what happens when you forget about it?

I was looking at my Microsoft Azure subscription today to see how I was doing for billing this month and the bill was higher than I expected. When I looked through the consumption charts in the Account Portal, I was shocked to see £20 of consumption against the Azure Network Gateway. Sometime ago, I had configured the Azure Network Site-to-Site VPN to test the feature against my ASA firewall at home. Once I had played with it for a while and verified I had a good configuration, I disabled the IPsec tunnel at my end as there was no point in keeping the connection up for the sake of it.

Problem was, I forgot about the Azure VPN Gateway which is a required item to enable the Site-to-Site VPN to function. I had accidentally left it running, consuming resources as it pleased without me actually reaping the service it offered.

Azure Gateway Hours

Sure, the cost is not significant, but it’s still a cost I’d rather avoid as I’m sure anyone out there paying up for cloud services would avoid. Money for nothing as Dire Straits famously said.

Needless to say, the VPN Gateway is now deleted and when the time comes that I want to use the Site-to-Site VPN, I’ll need to redeploy it and re-configure the Pre-Shared Key and IP Address for the tunnel endpoint on my ASA but that’s worth doing for a £20 a month saving on my Azure bill. Let this be a lesson to us all. Remember what you deploy and remember to clean-up after yourself when you’re finished with it.

Permit PPTP VPN GRE Traffic via a Cisco PIX Firewall

Richard Green on

Earlier this week, I tried to connect to a PPTP VPN connection. My Windows 8.1 PC gave me the following error:

Error 806: a connection between your computer and the VPN server has been established but the VPN connection cannot be completed.  The most common cause for this is that there is at least one internet device between your computer and the VPN server is not configured to allow GRE protocol packets Verify that protocol 47 GRE is allowed on all personal firewall devices or routers.  if the problem persists, contact your administrator.

At home, I use a Cisco PIX 515E firewall as my edge firewall device. My configuration isn’t particularly locked down in the sense that I don’t deny much traffic outbound (it causes too many internal support tickets with the wife and kids).

The error momentarily filled me with dread as I knew it was going to be an issue at my end as other people could connect to the service without any issues. The main reason though is that I know that from previous experience with VPNs, firewall and network devices getting in the stream and blocking traffic can be fraught with problems trying to resolve it.

A few Bing searches later and I was none the wiser. All of the details online seem to focus around people trying to host their own PPTP VPN servers and having issues with inbound connections, however with thru absence of other assistance, I figured I would try once of the recommendations I found which works to allow inbound PPTP connections and low-and-behold, a fix.

fixup protocol pptp 1723

Simply enter this command via the command line interface of the PIX or using Cisco ADSM and the command line entry dialog. The PIX will return with a slightly bizarre looking response and now you’re all set to place outgoing PPTP VPN connections.

The reason and rationale? The PIX does not by default inspect the IP Protocol 47 traffic (GRE) which is used by a PPTP VPN connection and therefore is dropped. Entering this command adds GRE to the inspection ruleset on the PIX so that the traffic can be seen and permitted to pass, assuming you don’t have an ACL which will then block it (the system level inspections happen before ACLs are taken into account).

Cisco VPN Client and Windows 7

Richard Green on

So I was searching today for something specific to the Cisco IP Communicator software phone version of the Cisco IP 7941 to see if there is a way to make it work nice with Windows 7, but in the process I found a lot of threads and blog entries about problems with the Cisco VPN client causing BSOD’s with ndis.sys.

I’d just like to say that I’ve got the Cisco VPN client installed on my Windows 7 Build 7000 machine without any issues. I can connect and disconnect as many times as I like without issue.

This is actually better than the experience in Windows Vista where the Cisco Virtual Network Adapter for the tunnel kept failing meaning after every connect/disconnect cycle I would have to reboot to get the adapter going again before being able to connect again.

This hit me worst at home if I roamed between my two Wireless AP’s where the WPA2-PSK authentication takes a little bit of time and the tunnel would drop during the roam.

In a nutshell…..Cisco VPN client just works in Windows 7, just like it should do.