SSPT RRAS VPN with Wildcard Certificate–Client Issues

Posted on November 16, 2017 Brian ReidLeave a commentPosted in rras, sstp, vpn

If you set up an SSTP VPN on Windows RRAS server and are using a wildcard certificate, there are client settings to fix before the client can connect.

If you run the Windows 10 client through the default setup for a VPN you get the following error.

This reads “The remove access connection completed, but authentication failed because the certificate on the server computer does not have a server name specified”

Note that this blog is based on 1709, so the steps are slight different than earlier builds as more of the settings have moved to the modern settings dialogs.

Right click the network/wifi icon on the task bar and choose “Open Network Internet Settings” (with two spaces in the middle – oops, UI bug)

This shows the following dialog in Windows 10 RS3 (1709). If on an earlier build you are now on the old style network settings, which is where we are heading anyway

Click Status

Click Change adapter options

This is the classic Windows networking screen from a number of versions of Windows

Right-click the network connection for the VPN you are having an issue with and choose Properties

Change to the Security tab

Then change your settings as shown below:

Data encryption: Require encryption

Authentication: Use Extensible Authentication Protocol (EAP): Microsoft Secured password (EAP-MSCHAP v2) (…)

And finally if your machine is a member of the domain that you are signing into, click properties and check the only option here

Windows RRAS VPN and Multi Factor Authentication

Posted on January 13, 2015January 14, 2015 Brian Reid6 CommentsPosted in Azure, MFA, multi-factor auth, password, phone factor, policy, pptp, remote desktop, rras, sdk, vpn

This blog post covers the steps to add Multi Factor Authentication (MFA) to Windows RRAS server. Once this is enabled, and you sign in with a user enabled for MFA in Azure Multi-Factor Authentication Server (an on-premises server) you are required to answer your phone before you can connect over the VPN. That is, you connect to the VPN endpoint, enter your username and password and if they are correct, then confirm that you want to authenticate by answering your phone. If you are not connecting over VPN and someone else is and using your credentials, unless they also have your phone they are not going to succeed! And all this for less than a £1 per user per month!

This configuration requires the following components set up:

Multi Factor Authentication set up in Azure
Azure Multi-Factor Authentication Server installed on-premises
Some users configured in Azure Multi-Factor Authentication Server
RRAS VPN server configured to use RADIUS for authentication, with the MFA server being the RADIUS endpoint

Step 1: MFA setup in Microsoft Azure

To do this you need an Azure subscription and DirSync configured to populate the Azure Active Directory with users. If you already have Office 365 with DirSync then you have this configuration already and you can login to Azure using the Azure AD link from the Office 365 management portal.

Once in Azure select “Active Directory” from the portal and click “Multi-Factor Auth Providers” from the menu at the top. You will probably not have any providers listed here, but if you do already (for example you are already using MFA for Office 365 or AD FS) then you can use the existing provider. To add a provider click Add, select “Multi-Factor Auth Provider” and “Quick Create” as shown:

Provide a name and then choose a usage model. Usage models are per user or per authentication. Per User works when a single user will authenticate more than 10 times a month. When users would only use MFA occasionally you can buy the service by the authentication request. For example if you had 200 VPN users who connected each day, you would choose Per User. But if you had 200 VPN users, who only dialled in once a month (i.e. a total of 200 authentications) then you would be better off buying the Per Authentication model as you would pay for 20 batches of authentications (each batch allows 10 authentications regardless of the user). You cannot change the authentication model without removing the auth provider and making a new one.

Finally, link the provider to your directory.

Select your auth provider once it is created and click Manage at the bottom of the portal:

This opens a new tab in the browser and takes you to the Azure Multi-Factor Authentication management pages.

Whilst here, as there is actually not a lot to do here, take a look at Configure to see what settings you can change. Maybe enter your email address for the fraud alert notifications, but leave everything else as is for now.

Back on the home page of the Azure Multi-Factor Authentication web site, click Downloads.

Step 2: Installing Multi-Factor Authentication Server

From the Downloads page find the small download link (above the Generate Activation Credentials button) and download the software to a Windows Server that is joined to your domain.

On the said server install .NET 2.0 and IIS with the default settings. Ensure that you have a digital certificate installed, as the web site the the users will go to for provisioning and managing their device is available over SSL. Mobile phones can use the app to validate connections as well, and that will be the subject of a different blog post, but you need a trusted cert that is valid and has a subject name such as mfa.domain.com (where domain.com is your domain) and so a 3rd party cert is required. In this blog I have used my wildcard cert from DigiCert.

Run the Multi-Factor Authentication Server installer and proceed through the steps. Use the wizard to configure the server and select VPN. During the installation you will also need to authenticate the Multi-Factor Authentication Server to Azure. This requires a set of credentials that are valid for ten minutes at a time, and generated from the Generate Activation Credentials button in the management web page at Azure. So don’t click this button until the Multi-Factor Authentication Server requires this info.

For this blog I am going to protect my VPN with Azure MFA. Therefore during the configuration wizard I select just the VPN option:

As you proceed through the wizard you will be asked about the RADIUS client configuration needed for your VPN provider. In here enter the IP address of your RRAS box and a password that you have made up for the occasion. You will need this password, or shared secret, when configuring the RRAS server later.

Finish the installation of Multi-Factor Authentication Server.

Once complete, open the Multi-Factor Authentication Server management program and select RADIUS Authentication. Ensure Enable RADIUS authentication is selected as this will allow this server to provide authentication on behalf of the RADIUS client and therefore insert requests for MFA via the users phone into the authentication flow.

Double click the IP address of your VPN server and select “Require User Match”

Step 3: Configure Users for MFA

Click the Users icon in Multi-Factor Authentication Server and click Import from Active Directory. Set the filtering to add just the users you want to enable MFA for. A user who dials in who is not listed here will not be blocked from authentication to the VPN.

A user will have a yellow warning icon next to it if it is disabled. For disabled users you can either allow authentication to pass through the MFA server without requiring the user to have the second factor of authentication working. This can be set on the users properties, and the Advanced tab by selecting Succeed Authentication for “When user is disabled”. The enabled check box is on the general tab.

If a user is enabled here then they will need to either complete the MFA authentication process. The exact process the user needs to do to pass the authentication process always starts with getting their username and password correct. After that they can do one of the following:

Press # when the call comes through to their phone
Reply to a text message – texts go to a US number, so this might cost the user international rates!
Press the Verify button on the MFA app on their phone
Optionally add a PIN number to any of the above – for example, when the MFA call comes through to enter your PIN and then press # rather than just #.

Each user can have different settings. When you import users from the Active Directory it reads (by default) their mobile number from the Active Directory as the primary number to authenticate against. You can set backup numbers if required. If a user has a mobile number they are enabled by default. When importing you can set which MFA method the user will use, and you can install the MFA portal so the user can change their own settings if you want (outside the scope of this blog).

By now you have Azure MFA configured, the MFA server installed on-premises (it will need port 443 access to Azure to complete the authentication) and users set up in the MFA server. The MFA server is also configured to act as a RADIUS endpoint for your VPN service. If you install more than one MFA server for load balancing and HA, ensure that each MFA server is selected on the Multi-Factor Auth Servers tab on the RADIUS settings – this starts the MFA RADIUS service on each selected machine.

Before you configure VPN, final step here is to test the user. From the Users area on the MFA server select a user and click Test. Authenticate as the user, username and password required for this test, and then press # after answering the phone. Try out the SMS or text message form factor for authentication as well. To support the mobile app you need to install the users portal, the SDK and the mobile app web service – so thats for a different blog post.

Step 4: Configure RRAS VPN to Use Multi-Factor Authentication

Finally, change to your RRAS server. Before going any further, ensure that RRAS is working before MFA is enabled – you don’t want to troubleshoot MFA only to find it was RRAS not working in the first place! The RRAS server’s IP address must match the IP address listed under the RADIUS configuration in the MFA server.

Right-click the RRAS server name in the Routing and Remote Access console. If you are setting up MFA for another type of VPN server then any that supports RADIUS will do. In the server properties, select the Security tab and change the Authentication provider to RADIUS Authentication (it was probably Windows Authentication).

Click Configure to the right of this drop-down and click Add:

Enter the IP address of your MFA server, repeating the Add process if you have more than one MFA server configured. Enter the shared secret that you used when setting up the MFA server and ensure that the timeout is set to 60 seconds. This is an important setting. When the user connects to the VPN server, the timeout needs to exceed the time it will take for the users phone to ring, listen the the greeting, enter the PIN (optionally) and press #. One minute should be enough to do this. After one minute the RRAS VPN server will automatically fail authentication, so the user has one minute to complete the second factor authentication on their phone.

You should now be able to dial into your VPN and authenticate with your username and password. Once you succeed with this, the MFA authentication starts and the call will arrive on your phone:

You can get the graphic as a vCard from http://1drv.ms/1xXCA01. Download this vCard, save it to your contacts and when you sync your contacts to your phone, your phone will tell you the Microsoft Phone Auth service is calling. You could change the name and graphic to suit, just make sure the number matches the CallerID setting in Azure MFA.

Whilst you are waiting for the call the arrive, and before you accept the auth request, the VPN client appears to pause:

Once you complete the auth, the VPN session starts up. If the call and time to answer exceeds 60 seconds, then consider increasing the RADIUS timeout on the VPN server.

Finally, and this will be a different blog post, you might want to offer the user a portal they can go to to change their settings such as updating phone number and changing mode of authentication etc. But this is off topic for this post. Later posts will cover using this MFA server integrated with AD FS and OWA as well.

An “Inexpensive” Exchange Lab In Azure

Posted on March 11, 2014March 14, 2014 Brian ReidLeave a commentPosted in 2010, 2013, Azure, cloud, DNS, exchange, exchange online, hyper-v, IAmMEC, Office 365, vhd, vm, vpn

This blog post centres around two scripts that can be used to quickly provision an Exchange Server lab in Azure and then to remove it again. The reason why the blog post is titled “inexpensive” is that Azure charges compute hours even if the virtual machines are shut down. Therefore to make my Exchange lab cheaper to operate and to not charge me when the lab is not being used, I took my already provisioned VHD files and created a few scripts to create the virtual machines and cloud service and then to remove it again if needed.

Before you start using these scripts, you need to have already uploaded or created your own VHD’s in Azure and designed your lab as you need. These scripts will then take a CSV file with the relevant values in them and create a VM for each VHD in the correct subnet (that you have also created in Azure) and always in the correct order – thus ensuring they always get the same IP address from your virtual network (UPDATE: 14 March 2014 – Thanks to Bhargav, this script now reserves the IPs as well as this is a newish feature in Azure). Without reserving an IP, when you boot your domain controller first in each subnet it will always get the fourth available IP address. This IP is the DNS IP address in Azure and then each of the other machines are created and booted in the order of your choosing and so get the subsequent IP’s. Azure never used to guarantee the IP but updates in Feb 2014 now allow this with the latest Azure PowerShell cmdlets. This way we can ensure the private IP is always the same and machine dependancies such as domain controllers running first are adhered to.

These scripts are created in PowerShell and call the Windows Azure PowerShell cmdlets. You need to install the Azure cmdlets on your computer and these scripts rely on features found in version 0.7.3.1 or later. You can install the cmdlets from http://www.windowsazure.com/en-us/documentation/articles/install-configure-powershell/

Build-AzureExchangeLab.ps1

# Retrieve with Get-AzureSubscription 
$subscriptionName = "Visual Studio Premium with MSDN"

Import-AzurePublishSettingsFile 'downloaded.publishsettings.file.got.with.Get-AzurePublishSettingsFile'

# Select the subscription to work on if you have more than one subscription
Select-AzureSubscription -SubscriptionName $subscriptionName

# Name of Virtual Network to add VM's to
$VMNetName = "MCMHybrid"

# CSV File with following columns (BringOnline,VMName,StorageAccount,VMOSDiskName,VMInstanceSize,SubnetName,IPAddress,Location,AffinityGroup,WaitForBoot,PublicRDPPort)
)
$CSVFile = Import-CSV 'path\filename.csv'

# Loop to build lab here. Ultimately get values from CSV file
foreach ($VMItem in $CSVFile) {

    # Retrieve with Get-AzureStorageAccount  
    $StorageAccount = $VMItem.StorageAccount

    # Specify the storage account location containing the VHDs 
    Set-AzureSubscription -SubscriptionName $subscriptionName  -CurrentStorageAccount $StorageAccount
  
    # Not Used $location = $VMItem.Location     # Retrieve with Get-AzureLocation

    # Specify the subnet to use. Retreive with Get-AzureVNetSite | FL Subnets
    $subnetName = $VMItem.SubnetName

    $AffinityGroup = $VMItem.AffinityGroup      # From Get-AzureAffinityGroup (for association with a private network you have already created). 

    $VMName = $VMItem.VMName
    $VMOSDiskName = $VMItem.VMOSDiskName        # From Get-AzureDisk
    $VMInstanceSize = $VMItem.VMInstanceSize    # ExtraSmall, Small, Medium, Large, ExtraLarge 
    $CloudServiceName = $VMName
    $IPAddress = $VMItem.IPAddress              # Reserves a specific IP for the VM

    if ($VMItem.BringOnline -eq "Yes") {
        Write-Host "Creating VM: " $VMName
        $NewVM = New-AzureVMConfig -Name $VMName -DiskName $VMOSDiskName -InstanceSize $VMInstanceSize | Add-AzureEndpoint -Name 'Remote Desktop' -LocalPort 3389 -PublicPort $VMItem.PublicRDPPort -Protocol tcp | Add-AzureEndpoint -Protocol tcp -LocalPort 25 -PublicPort 25 -Name 'SMTP' | Add-AzureEndpoint -Protocol tcp -LocalPort 443 -PublicPort 443 -Name 'SSL' | Add-AzureEndpoint -Protocol tcp -LocalPort 80 -PublicPort 80 -Name 'HTTP' | Set-AzureSubnet –SubnetNames $subnetName | Set-AzureStaticVNetIP –IPAddress $IPAddress        
        # Creates new VM and waits for it to boot if required
        if ($VMItem.WaitForBoot -eq "Yes") {New-AzureVM -ServiceName $CloudServiceName -AffinityGroup $AffinityGroup -VMs $NewVM -VNetName $VMNetName -WaitForBoot}
            else {New-AzureVM -ServiceName $CloudServiceName -AffinityGroup $AffinityGroup -VMs $NewVM -VNetName $VMNetName }
    }
}

Remove-AzureExchangeLab.ps1

# Retrieve with Get-AzureSubscription 
$subscriptionName = "Visual Studio Premium with MSDN"

Import-AzurePublishSettingsFile 'downloaded.publishsettings.file.got.with.Get-AzurePublishSettingsFile'

# Select the subscription to work on if you have more than one subscription
Select-AzureSubscription -SubscriptionName $subscriptionName

# CSV File with following columns (BringOnline,VMName,StorageAccount,VMOSDiskName,VMInstanceSize,SubnetName,IPAddress,Location,AffinityGroup,WaitForBoot,PublicRDPPort)
$CSVFile = Import-CSV 'path\filename.csv'

# Loop to build lab here. Ultimately get values from CSV file
foreach ($VMItem in $CSVFile) {

    # Stop VM
    Stop-AzureVM -Name $VMItem.VMName -ServiceName $VMItem.VMName -Force

    # Remove VM but leave VHDs behind
    Remove-AzureVM -ServiceName $VMItem.VMName -Name $VMItem.VMName 

    # Remove Cloud Service
    Remove-AzureService $VMItem.VMName -Force
}

CSV File Format

The CSV file has a row per virtual machine, listed in order that the machine is booted:

BringOnline,VMName,StorageAccount,VMOSDiskName,VMInstanceSize,SubnetName,IPAddress,Location,AffinityGroup,WaitForBoot,PublicRDPPort
Yes,mh-oxf-dc1,portalvhdsjv47jtq9qdrmb,mh-oxf-mbx2-mh-oxf-mbx2-0-201312301745030496,Small,Oxford,10.0.0.4,West Europe,C7Solutions-AG,Yes,3389
etc,…

The columns are as follows:

BringOnline: Yes or No
VMName: This name is used for the VM and the Cloud Service. It must be unique within Azure. An example might be EX-LAB-01 (if that is unique that is)
StorageAccount: The name of the storage account that the VHD is stored in. This might be one you created yourself or one made by Azure with a name containing random letters. For example portalvhdshr4djwe9dwcb5 would be what this value might look like. Use Get-AzureStorageAccount to find this value.
VMOSDiskName: This is the disk name (not the file name) and is retrieved with Get-AzureDisk
VMInstanceSize: ExtraSmall, Small, Medium, Large or ExtraLarge
SubnetName: Get with Get-AzureVNetSite | FL Subnets
IPAddress: Sets a specific IP address for the VM. VM will always get this IP when it boots and other VM’s will not take it if the happen to boot before it
Location: Retrieve with Get-AzureLocation. This value is not used in the script as I use Affinity Groups and subnets instead.
AffinityGroup: From Get-AzureAffinityGroup (for association with a private network you have already created).
WaitForBoot: Yes or No. This will wait for the VM to come online (and thus get an IP correctly provisioned in order) or ensure things like the domain controller is running first.
PublicRDPPort: Set to 3389 unless you want to use a different port. For simplicity, the script sets ports 443, 80 and 25 as open on the IP addresses of the VM

Creating an Azure VPN with a Draytek Router

Posted on January 7, 2014 Brian Reid10 CommentsPosted in Azure, cloud, draytek, exchange, firewall, ipsec, vpn

The Microsoft Azure cloud operating system can be connected to your network by way of a virtual private network or VPN. Azure lists some supported devices and provides configuration scripts for them, but does not include the Draytek range of devices. Draytek devices are common in the small business market and for techy home users. This blog post will show how to configure a site to site VPN between your network and your Azure tenant using a Draytek 2920 router. Other Draytek routers will work as well, just the screenshots and instructions here are from that model of router.

Collecting required information

Before you start you need the following information to hand:

The IP subnets of your network. For the purposes of this blog these are 192.168.5.0/24 and 192.168.6.0/24
The IP subnet that you wish to use in Azure. This needs to be different from the subnet(s) on your LAN. For the purpose of this blog this will be 192.168.4.0/24.

Configuring Azure Networks

To configure your VPN login to your Azure tenant at https://manage.windowsazure.com/ and from the services area on the left click Networks near the bottom. Add a new network by clicking Create a virtual network or from the bottom toolbar clicking + New and from the options select Custom Create. Note that Quick Create will not create a valid solution as it will note create a VPN gateway.

Enter the name of the VPN network and enter a name for the affinity group that you need to create. You will place virtual machines into this affinity group so that they get an IP address valid for this network. I’m based in the UK, so I choose West Europe (i.e. Dublin) as the datacentre to use.

Click the right-hand arrow at the bottom of the screen and check Site to site VPN. You only need to add a DNS name and IP address (to an existing DNS server) on your LAN if your virtual machines need to use this DNS server to resolve on-premises resources. I will use Azure to do my name resolution, so will not enter them here.

Click the right-hand arrow at the bottom of the screen and enter a name for your LAN and your external IP address (not shown here). This needs to be a static IP address that is not NAT’ed, so in my case this will be the external IP address of the Draytek router. Also enter the address space(s) for your LAN.

Click the right-hand arrow at the bottom of the screen to go to page 4 of the wizard and select an address space that does not conflict with your LAN address spaces entered on the previous screen. In the picture below I have configured 192.168.4.0 as the subnet with a /24 CIDR range. You can edit the values provided if they do not suit. For the subnets within this network, you need one or more subnets for the address space. My final aim for the Azure tenant is to host a multisite Exchange Server lab, so I will create four subnets within the 192.168.4.0/24 address space. The first address space is going to be reserved for routing purposes back to my LAN. The routing subnet is configured by clicking the add gateway subnet button.

Click the tick mark and wait for the network to be created. Once created click the network name and then Dashboard.

You will see that the gateway is not created. To start the VPN gateway at Azure click the Create Gateway button on the lower black toolbar. Choose Static Routing and confirm the choice. In about 15 minutes time the status of the gateway will go blue and the VPN grey.

We can now move onto configuring the router on your LAN as Azure is now waiting for the connection to take place.

Configuring a Draytek Router to Connect to Azure

On the VPN page in Azure you will see the status of the connection showing the amount of data that has crossed the connection to date and the IP address that you need to connect your VPN tunnel to. Make a note of this IP address (redacted in the above picture) and also make a note of the Shared Key, this you can get from the Manged Key button on the toolbar. Copy this to your clipboard and navigate to your Draytek admin page.

Ensure that your router provides service for IPSec VPN’s and that this type of traffic is not being passed through the router to another device. This is available from VPN and Remote Access > Remote Access Control in the Draytek web admin pages.

Change to VPN and Remote Access > LAN to LAN and click an available LAN to LAN profile that is not being used. In section 1 give the profile a suitable name and enable it, disable Netbios naming packets from crossing the VPN and allow multicast if you will need it. Set the Call Direction to Dial-Out and check the Always on option if you require the connection to be up all the time. Scheduled connections are also possible.

Under Dial-Out Settings (section 2) ensure IPSec Tunnel is selected and the Server IP/Host Name for VPN matches the Gateway IP Address provided on the Azure management page. Under IKE Authentication ensure Pre-Shared Key is selected. Click the IKE Pre-Shared Key button and paste the pre-shared key from Azure.

Under IPSec Security Method select High (ESP) and ensure AES with Authentication is selected. Azure requires AES encryption. The Advanced options do not need changing as they are valid for Azure already.

Scroll down to section 5 (sections 3 and 4 do not need completing) and enter the network address space in use at Azure as the value for Remote Network IP and ensure the Remote Network Mask value is correct. This ensures that connections to this subnet are routed down this VPN tunnel. If you have multiple address spaces created at Azure then click the More button and add the rest of the Azure networks (not the individual subnets within the address space) if you added additional address spaces.

Save the VPN profile and navigate to VPN and Remote Access > Connection Management. In about 10 seconds you will see this page refresh and you should see the connection to Azure has been made.

Back on the Azure management console the VPN at the LAN side should be green and the Data In and Data Out values increasing. At the time of writing, an Azure VPN costs £1.44 per day and this does not include any network traffic across the link.

Creating Azure Virtual Machines on Your VPN

Ensure that your link is up by pinging the VPN endpoint at Azure. This will be the second IP address on the gateway subnet that was created earlier. In my example this is 192.168.4.197.

Virtual machines in Azure will get an IP address from your VPN and will be directly reachable to and from your LAN if they are associated with the VPN network created when the VPN was created. To do this either create a virtual machine from the gallery option (not Quick Create) to make a new virtual machine from a template or one of your existing unused VHDs or images and set the region/affinity group to the VPN network.

Note that you cannot change the network that an existing machine is associated with – you need to delete the virtual machine (but without deleting the disks) and also delete the associated cloud service. Then you can make the VM again and choose My Disks from the gallery and select the VPN as the Region/Affinity Group/Virtual Network value.

That is it. You virtual machines will come online and be provisioned and get an IP address on your virtual network. To see the IP address click the virtual machine and view the dashboard. Note that shutting down the virtual machine will release the IP and you cannot assign static IP’s in Azure or the machine will not be reachable – all connectivity to Azure machines is via resolved names.

Create i386 CMAK Profile on x64 Machine

Posted on May 28, 2009September 30, 2013 Brian Reid1 CommentPosted in vpn

Informing users and clients how to connect their Windows PC to a VPN connection is easy, but could be easier. There are a few questions to answer and having the user type this in might mean wrong answers, and therefore a supsequent support call would be required.

To ease this issue, and reduce the support call costs Microsoft have made available for a number of years the Connection Manager Administration Kit (CMAK). Lots of websites and blogs describe how to make CMAK profiles but to date none that I can find solve the problem of installing CMAK on a x64 version of Windows 2008 (for example Small Business Server 2008, but any x64 bit architecture will do) and attempting to deploy the resulting executable on a i386 XP architecture.

The CMAK program within Windows 2008 (added to the default installation by adding a feature) has options for the creation of a “downlevel” build (i.e. XP, 2003 and 2000) as well as a Vista build (which covers 2008 and Windows 7 as well) but the resulting executable made from the downlevel option is not valid.

The reason for this is many. Firstly the executable is constructed using iexpress.exe on an x64 machine – resulting in a x64 installer that will not run on a i386 machine. Fix this problem (see below for steps) and you find that the installer runs a program to actually create the connection object in the Network settings area of Control Panel, but this program (cmstp.exe) is also x64 architecture and so will not run on an i386 architecture machine.

Before we go into the steps to do this successfully, here (for the benefit of the search engines) are the different errors that you will see:

This profile was not built for this processor architecture. Please contact your Administrator to get the appropriate profile for this architecture.
profile.exe is not a valid Win32 application.
Error creating process <c:\docume~1\user\locals~1\temp\ixp000.tmp\.\cmstp.exe>. Reason: C:\WINDOWS\system32\advpack.dll

To fix this and create an i386 connection profile on an x64 architecture machine involves modifying the file that controls the creation of the executable (the .sed file) and getting two files from either an i386 Windows Server 2003 installation or an i386 XP installation.

First for those extra files. On the Windows 2008 Server that has CMAK installed, and having successfully created a profile (see windowssecurity.com and uksbsguy for profile creation steps) you need to create a folder called i386 inside C:\Program Files\CMAK\Support\en-US (C: and en-US might be different on your installation). This is best done from an elevated command prompt. Inside this folder place advpack.dll and cmstp.exe from an i386 installation of Windows Server 2003 or XP Professional (ensure latest service packs and patches on the source machine as well). Both of these files are found in \windows\system32 on the source installation.

Secondly, also from the elevated command prompt, you need to create a copy of the .sed file for each architecture you want to build for. The .sed file is named after the profile name that you have created and is located in a subfolder of C:\Program Files\CMAK\Profiles\Downlevel where the subfolder is the name of the profile. The default .sed file will work on x64 XP. Therefore to create a .sed file for i386 XP copy profile.sed to profile-i386.sed and then open this file in notepad (by typing notepad profile-i386.sed from the elevated command prompt).

The third step is to edit this .sed file so that the entries that point to the location of cmstp.exe and advpack.dll are to the new files you copied in the first step. Therefore change the line that starts FILE0= and the line that starts FILE1=. These should read something like the following:

FILE0=C:\Program Files\CMAK\Support\en-US\i386\advpack.dll
FILE1=C:\Program Files\CMAK\Support\en-US\i386\cmstp.exe

Additionally, but not required, I also change the TargetName= value from profile.exe to profile-i386.exe so that it does not overwrite the x64 executable that has already been created by the CMAK wizard and I edit the InstallPrompt= value to include something that indicates that I am about to install the i386 version of the connection object.

Now close and save the changes made to the new .sed file.

Finally you can build the executable. But the fun does not stop here. You might have noticed from the errors above that one of the errors is that the executable is not a valid win32 executable. This occurs if the x64 version of iexpress.exe is used to create the installation program. You need to use the 32 bit version that is installed on the x64 machine. The 32 bit version of the program is found in c:\windows\syswow64 (this stands for Windows On Windows 64) and so from the elevated command prompt type \windows\syswow64\iexpress /N profile-i386.sed (this is one command on one line if your browser happens to wrap the text over two lines). This will create the executable named after the TargetName value in the .sed file. This can then be copied to your software installation share and deployed to your users.

Configuring an SSTP VPN on Small Business Server 2008

Posted on March 31, 2009September 30, 2013 Brian Reid8 CommentsPosted in networking, pki, sbs 2008, sstp, vpn

SSL based VPN’s are great. In short it is VPN without firewall or NAT issues (both of which you get with PPTP and IPSec VPN’s). But SBS 2008 does not enable SSTP VPN’s by default. It uses RRAS, so SSTP is possible, but it is not as easy as it first looks! The following is a brief guide to the steps. Exact step by step instructions are not included, as you should be someone with RRAS and certificates experience before approaching this, and if you are not but have a business need for SSTP VPN (and who doesn’t!) then call C7 Solutions in the UK on 0845 257 1777 for help and assistance. This is not at all easy to configure and get working.

Ensure that you have run the connecting to the internet wizard, and that you are using a third party certificate (as there are less steps if you do this). With the default self signed certificate SSTP will not work as the client on the internet will not be able to reach the certificate revocation location. Using the installed Certificate Services and creating your own issued certificate requires publishing to the internet the certificate revocation information and so adds steps that are not entirely necessary given that certificates are inexpensive and would cost less to buy than the time taken to go through all the extra steps needed with your own issued certificates.
Enable remote access from the SBS Console > Network > Connectivity page and choose Configure a Virtual Private Network link under Connectivity Tasks on the right-hand side of the window.
Add some SSTP ports to the VPN in the Routing And Remote Access management program. Right-click Ports and choose Properties and enable SSTP for remote access inbound connections and set the number of connections to a suitable number for your organization. Leave PPTP enabled as Windows XP does not support SSTP VPN tunnels (only Vista SP1 and later will do so).
Create an MMC and add in the local computers Certificate snap-in. View the properties of your trusted certificate that you are using for Remote Web Workplace and note down the Thumbprint value of this certificate.
Ensure that this certificate is associated with 0.0.0.0:443 and [::]:443 network bindings on the server. Type netsh http show ssl from elevated command prompt to get this information. You typically get four entries with IP:port being the first line of each. Check for IP:port reading “0.0.0.0:443” and [::]:443 as this shows the IPv4 and IPv6 mappings for SSL certificates on the server. Ignore the :8172 and :987 entries (these are for IIS Management Service and companyweb).
If the certificate hash is not the same for both the remote web workplace certificate and the netsh bindings information in the previous two steps or if you are missing the IPv6 binding then you need to reset the bindings. If they are same then jump to step 7.
a) Ensure that the certificate bound to the remote web workplace is correct. From the client machine browse to http://remote.your_domain.com. You should be automatically forwarded to https://remote.your_domain.com/remote and the login page. If you get any certificate errors during this in the web browser you must fix them now before continuing.
b) If the certificate on the remote web workplace site is incorrect then run the Fix My Network wizard and the Set Up Your Internet Address wizard in the SBS Console (both found in the Network > Connectivity > Connectivity Task pane).
c) Repeat the test in step a and if the certificate that is now associated with the site is incorrect also run the Add A Trusted Certificate wizard which is found in the same place as above. This step should not be needed if a trusted certificate has already been installed on the server and it matches the remote.your_domain.com name and the wizards in step b will associate the correct certificate to the website.
d) From an elevated command prompt delete the certificate binding for IPv4 by typing netsh http delete sslcert ipport=0.0.0.0:443. The binding should be deleted successfully.
e) From an elevated command prompt delete the certificate binding for IPv6 by typing netsh http delete sslcert ipport=[::]:443. The binding should be deleted successfully if an IPv6 binding existed, otherwise expect to see an error which can be ignored.
f) Delete the certificate binding in the RRAS configuration by deleting these registry keys, if they exist, “HKLM\ System\ CurrentControlSet\ Services\ Sstpsvc\ Parameters\ Sha256CertificateHash” and “HKLM\ System\ CurrentControlSet\ Services\ Sstpsvc\ Parameters\ Sha1CertificateHash”
g) Connect the correct certificate to the IPv4 and IPv6 bindings by typing the following entries from an elevated command prompt where xxx is the certificate hash of the trusted certificate used for the Remote Web Workplace. netsh http add sslcert ipport=0.0.0.0:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY and netsh http add sslcert ipport=[::]:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY.
h) Close any open copy of IIS Manager and restart the program. Ensure that the bindings for the SBS Web Applications site is correctly bound to your trusted remote web workplace certificate.
i) Note that binding SSTP to the IPv4 and IPv6 listeners on port 443 will cause TS Gateway administration to display error messages (specifically that the certificate is not bound and that the IIS web site is not configured). These errors can be ignored on SBS 2008 but if you click the links to fix the errors then all will work fine. The only condition is that this fixing of errors must be done after SSTP is configured correctly (so ensure SSTP connectivity works and then come back to this step to fix). Future changes to the certificate in IIS or TS Gateway might break the SSTP binding.
From a client machine browse to https://remote.your_domain.com/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ and ensure that no errors occur. Note that you will not see anything in the web browser. View the properties of the certificate, specifically the CRL Distribution Points (CDP) value. Note that you should not have got any certificate errors when browsing to this site and if you did you need to resolve them before continuing further in these steps.
Browse to the CDP URL in the above certificate – you should be able to reach this location on the web without error. The web browser should attempt to download the CDP file.
On a Vista (SP1 or later) or Windows 7 client create a new VPN connection and in properties of the connection object choose the Security tab and ensure that the Type of VPN is set to SSTP. For regular everyday use set this to Auto, and it will find a working protocol (starting with PPTP) and so if PPTP does not work due to NAT or firewall/proxy issues SSTP will be tried and succeed (but for testing set the VPN connection specifically to SSTP). Also ensure that the name of the server you are connecting to is the same name that the certificate uses for the certificate common name.
Connect the VPN and all should work. Errors regards certificate trust will appear if you have used the self issued certificate, even if you have added the certificate to your certificate store and have the certificate working in Internet Explorer. Once you have connected you can confirm from the RRAS management console that you are connected over an SSTP VPN connection. To confirm this click Ports in the RRAS management console and the active connection should be utilizing an SSTP port.
Congratulate yourself on getting this far – this is not easy!

SSTP (SSL VPN) on SBS 2008 RC0

Posted on June 23, 2008September 30, 2013 Brian ReidLeave a commentPosted in 2008, iis, rras, sbs 2008, sstp, vpn, windows

Updated 31st March 2008: Please see http://c7solutions.com/blog/2009/03/configuring-sstp-vpn-on-small-business_31.aspx as this new article replaces the below, as the below refers to a pre-release version of SBS 2008. The working instructions for configuring SSTP on SBS 2008 is much more complicated than the steps below.

SSL based VPN’s are great. In short it is VPN without firewall or NAT issues (both of which you get with PPTP and IPSec VPN’s). But the current release of SBS 2008 (RC0) does not enable SSTP VPN’s by default. It uses RRAS, so SSTP is possible, but it is not as easy as it first looks!

Ensure that you have run the connecting to the internet wizard, and that you are using a third party certificate (as there are less steps if you do this).
Enable remote access from the SBS Console > Network > Connectivity page.
Add some SSTP ports to the VPN in the Routing And Remote Access management program. Right-click Ports and choose Properties and enable SSTP for remote access inbound connections. Leave PPTP enabled as Windows XP does not support SSTP VPN tunnels (only Vista SP1 does at this time).
View the properties of your certificate and note down the Thumbprint value.
Ensure that this certificate is associated with 0.0.0.0:443 and [::]:443: certificate bindings on the server. Type “netsh http show ssl” from elevated command prompt to get this information. You typically get four entries with IP:port being the first line of each. Check for IP:port reading “0.0.0.0:443” and [::]:443 as this shows the IPv4
and IPv6 mappings for SSL certificates on the server. Ignore the :8172 and :987 entries (these are for IIS Management Service and companyweb).
For both “0.0.0.0:443” and [::]:443 make a note of the Certificate Hash. It needs to be the same for both and the same as the earlier Thumbprint value (ignore any spaces).If not see
http://blogs.technet.com/rrasblog/archive/2007/11/08/configuring-iis-on-the-sstp-server-implications-and-how-to-resolve.aspx for instructions on resetting this, noting that you need to ensure that the correct certificate is bound to the SBS Web Applications website on the SBS 2008 server (in IIS manager).
Install the “Certificate Authority Web Enrollment” role service to Active Directory Certificate Services snapin within Server Manager. This adds a virtual directory to the default website in IIS called CertEnroll which contains the certificate revocation list for the certificate you are using. Only do this if you are using the built in default issued certificate. If you are using certificates from a third party then you need to ensure you can reach
their CRL publishing site without issue – see the certificate details for information on the CRL publishing site location.
Expand the Certificate Authority on your server and right-click Revocated Certificates. Under tasks choose Publish. This updates the CRL with the new publishing location that SSTP needs to connected to. Again, use a third party certificate to make this easy!
On a Vista SP1 client create a new VPN connection and in properties > networking ensure that the Type of VPN is set to SSTP (for normal use set this to Auto, and it will find the best (starting with PPTP), but for testing set it specifically to SSTP). Also ensure that the name of the server you are connecting to is the same name that the certificate uses for the certificate common name.
Connect the VPN and all should work.

ISA Server and Net2 Access Control from Paxton

Posted on November 8, 2006September 30, 2013 Brian ReidLeave a commentPosted in 2004, door, isa, paxton, vpn

To allow access to the Net2 Server software through an ISA Server you need to create some custom protocols and then allow those protocols in the rules. This was what stopped me accessing the door control system over a VPN to a client of ours.

The new protocols needed are:

“Net2 Access Control Inbound”, which is TCP Inbound 6474 to 6475 and UDP Receive Send 6476 to 6477
“Net2 Access Control Outboubd”, which is TCP Outbound 6474 to 6475 and UDP Send Receive 6476 to 6477

These custom protocols need to be added to any firewall rules that separate you from the Net2 server, for example a rule to allow these protocols from the Internal network to the VPN Clients network is required.

Once it is working, the Net2 Workstation software will display the server name on start-up.

Adding Routes Using CMAK

Posted on February 23, 2006September 30, 2013 Brian ReidLeave a commentPosted in 2008, 2008 R2, cmak, SSL, sstp, vpn, windows 2008

I have just put together a Connection Manager VPN client (CMAK) and within it have specified the extra routing information that I needed. When I ran the client I got the following error message and could not find anything on the web with an answer, so here is the answer…

Error 1: Connect action to update your routing table failed (80070057) – shown in the VPN client

Error 2: ErrorCode = -2147024809 ErrorSource = to update your routing table – recorded in the VPN log file

The reason! It was because I had entered an incorrect routing record in the text file. So to get this right, add the routes manually when connected and make sure they work, and then duplicate these entries in the text file. If the routes cannot be added on the command line then the VPN connection will fail with the above error message.