Search This Blog

Wednesday, May 25, 2011

Auditing Users and Groups with the Windows Security Log

Active Directory is one of the most important areas of Windows that should be monitored for intrusion prevention and the auditing required by legislation like HIPAA and Sarbanes-Oxley. I say that because Active Directory is home to objects most associated with user access: user accounts, groups, organizational units and group policy objects. This article deals with monitoring users and groups using the Windows Security Log.
New user accounts are important to audit to verify that they correspond to a legitimate employee, contractor or application. Outside intruders often create new user accounts to facilitate continued access to the penetrated system. Certain changes to user accounts are important to audit since they can be a tip-off to compromised accounts. For instance, both insider and outsider computer criminals often gain access to a system by socially engineering the help desk to a user’s password. Or a previously disabled account being re-enabled may be suspicious depending on the history and type of the account. Group changes, especially changes to the group’s membership, are very useful to track since groups are used to control access to resources, link security policies and control wireless and remote access all over a Windows network. Changes to an organizational unit’s Security tab usually corresponds to delegation of administrative authority over that OU but also occurs when you change normal user access to directory objects. Examples include delegating password reset or user account creation authority over the NYC OU. Any change to a group policy object or changes to the Group Policy tab of an OU, can result in wide reaching changes to the security policies applied to the computers in that OU or changes to desktop restrictions for the user accounts in that OU. In this article I’ll focus on auditing changes to users and groups.
To track changes to users and groups you must enable “Audit account management” on your domain controllers. The best way to do this is to enable this audit policy in the “Default Domain Controllers” GPO which is linked to your Domain Controllers OU as seen in figure 1. “Audit account management events” provides specific event IDs for important operations that can be performed on users and groups.   

User account auditing

The basic operations of creation, change and deletion of user accounts in AD are tracked with event IDs 624, 642 and 630, respectively. Each of these event IDs provides the name of the user who performed the operation and the name of the user account that was affected as you can see below in the example of event ID 642 which was taken from a Windows 2000 domain controller:
User Account Changed:
 -
 Target Account Name:alicej
 Target Domain:ELMW2
 Target Account ID:ELMW2\alicej
 Caller User Name:Administrator
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x1469C1)
 Privileges:-
Note that event ID 624 (user account created) replaces “Target” with “New” in the above sample. For changed user accounts, Window 2000 sometimes documents the type of change made to the account in the first line after “User Account Changed”. With Windows Server 2003, Microsoft added a bunch of new fields to the description of event ID 642 as shown below.
User Account Changed:
 -
 Target Account Name:alicej
 Target Domain:ELMW2
 Target Account ID:ELMW2\alicej
 Caller User Name:Administrator
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x1469C1)
 Privileges:-
 Changed Attributes:
 Sam Account Name:-
 Display Name:-
 User Principal Name:-
 Home Directory:-
 Home Drive:-
 Script Path:-
 Profile Path:-
 User Workstations:-
 Password Last Set:-
 Account Expires:9/7/2004 12:00:00 AM
 Primary Group ID:-
 AllowedToDelegateTo:-
 Old UAC Value:-
 New UAC Value:-
 User Account Control:-
 User Parameters:-
 Sid History:-
 Logon Hours:-
In the above example you can see that Administrator set Alicej’s account expiration date to 9/7/2004. These new fields are a real advance since Windows 2000 was pretty inconsistent about which account property changes it documented and which it left blank in the event’s description. Sometimes all you knew was that the account was changed but not what changed. Most of the fields are self explanatory but “Old UAC Value” and “New UAC Value” bear some discussion. UAC stands for user account control and is a 4-byte field whose bits correspond to the check boxes on the user’s account seen in figure 2. At first I thought it was necessary to isolate the individual check boxes from the UAC value. However that is not necessary because the next field, User Account Control, graciously lists in plain English which options where checked or unchecked. For instance in the case of a user account being enabled, User Account Control specifies “Account Enabled”.
Windows Server 2003, and to a lesser degree Windows 2000, also has a number of event IDs devoted to specific user account maintenance operations. When a user changes his own password Windows Server 2003 logs event ID 627, “Change Password Attempt” as shown below.
Change Password Attempt:
 Target Account Name:bob
 Target Domain:ELMW2
 Target Account ID:ELMW2\bob
 Caller User Name:bob
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x130650)
 Privileges:-
When an administrator resets some other user’s password such as in the case of forgotten password support calls, Windows Server 2003 logs event ID 628.
User Account password set:
 Target Account Name:harold
 Target Domain:ELM
 Target Account ID:ELM\harold
 Caller User Name:timg
 Caller Domain:ELM
 Caller Logon ID:(0x0,0x158EB7)
Notice that the “caller” fields identify the user, timg, who reset the “target” user account, harold. Windows 2000 acts a little differently. Despite MS documentation, Windows 2000 logs event ID 627 for both password resets and password changes by the same user. To distinguish between password changes and resets, compare the caller username to the target user name. If they match, you know that the user changes his/her own password.
When Windows locks a user account after repeated logon failures, you’ll see event ID 644 in the security log of the domain controller where the logon failures occurred. 
User Account Locked Out:
 Target Account Name:alicej
 Target Account ID:ELMW2\alicej
 Caller Machine Name:W3DC
 Caller User Name:W2DC$
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x3E7)
When the user contacts the help desk or administrator to have his password reset, Windows Server 2003 logs event ID 671, “User account unlocked”. Windows 2000 does not log this event. 

Group auditing

Auditing changes to groups is very easy. Windows provides different event IDs for each combination of group type, group scope and operation. In AD, you have 2 types of groups. Distribution groups cannot be assigned rights or permissions. Distribution groups are reserved exclusively for distribution lists in Exchange 2000. In the security log distribution groups are referred to as “security disabled” groups. Security groups are the more familiar type of group and the only group type that you can assign permissions and rights. Security groups are referred to as “security enabled” groups in the security log. Groups also have 1 or 3 scopes: Universal, Global and Local. The chart below illustrates the difference between the 3 scopes.
Scope
Can have as members Can be grantedpermissions
Universal Users and global or universal groups from any domain in the forest Anywhere in the forest
Global Users and other global groups  from same the domain Anywhere in the forest
Domain local Users and global or universal groups from any domain in the forest and domain local groups from the same domain Only within the same domain
Windows logs 5 different event IDs for each group type and scope combination. The 5 events correspond to the 5 operations Windows audits for each group: creation, change, deletion, member added and member removed.
Type
Scope Created Changed Deleted Member
Added Removed
Security Local 635 641 638 636 637
Global 631 639 634 632 633
Universal 658 659 662 660 661
Distribution Local 648 649 652 650 651
Global 653 654 657 655 656
Universal 663 664 667 665 666
From an access control auditing perspective, the most important column would have to member added since that operation usually corresponds to a user being granted new access.
As you can see, “Audit account management” provides a wealth of information for tracking changes to your users and groups in Active Directory. Remember though, you must monitor and/or collect these events from each domain controller within your domain since the only domain controllers that logs an account management event is the one where the change was actually executed. While a change to a user or group does get replicated to all the other domain controllers, replication does not trigger any events in the security log. For effective use of the security log you need someway of collecting events into a single database for monitoring and reporting purposes using some home grown scripts or an event log management tool such as GFI’s LanGuard SELM.

Tuesday, May 17, 2011

Getting Certificate from third party Certificate Authorities for SSTP

SSTP as you know requires a machine certificate to be installed on the VPN server.
Most of the times, when the administrators need this machine certificate, they can configure a CA Server and get the certificates from this CA. But for this to work, the CDPs (CRL Distribution Point) need to be published on some server located on the Internet so that the client machines can access it for doing the Certificate Revocation Check during the SSL phase.
If you don't plan to deploy your own CA as well as CDP servers, you can obtain a machine certificate from a third party Certificate Authority.
These third party Certificate Authorities need a Certificate Request file to generate the Certificate requested.This blog is going to tell about how to generate this Certificate Request file on the Windows Server 2008 machine.
Here are the steps to generate the Certificate Request File.
- Go to any Windows Server 2008.
- Open MMC.
- Add the Certificate Snap-in for the “Computer Account”.
- Now, do a right click on the “Peronal” and select “All tasks”->”Advanced Operations”->”Create custom request” as shown below:-
CertReq1
- You will see the following GUI :-
CertReq2
Press “next” on this GUI. You will get the following GUI:-
CertReq3
Press Next on this window. Now, you will get the following GUI which will be used to configure the various properties of the Certificate:-
CertReq4
Click on the “Details” tab which will show the “Properties” tab. Click on this “Properties” tab to set the properties of this Certificate. This will pop up the following new GUI:-
CertReq5
Enter the Certificate’s Friendly name and description of your choice. Sample name and description are entered above.
Press on the “Subject” tab present at the top of this window.. You will see the following GUI:-
CertReq6
On this window, you will need to specify the Subject name of the certificate. Select “Type” as “Common Name” in the Subject Name and then enter the name of the Certificate in the “Value” field. In the above sample, I have entered the IP address of the SSTP Server. You can specify any name also here. Now Press “Add” button.
Now click on the “Extensions” tab present at the top of this window.. You will see the following window:-
CertReq7
In this window, click in front of the “Extended Key Usage (application policies)”. You will have to select the EKU (Extended Key Usage) of the Certificate. This will be “Server Authentication” for SSTP. Select “Server Authentication” and then Press “Add” button.
Now Click on the “Private Key” present at the top of this window. You will see the following window:-
CertReq8
Here, click in front of  “Key Options” and then Check the “Make private key exportable”. Press “Apply” button and then Press the “OK” button.
Now press “Next”. You will be shown the following window where you will have to specify the path of the Certificate Request file :-
CertReq9
After specifying the name and path of the certificate request file, press “Finish” button.
A Certificate Request File will be generated in the location you have specified above.
- If you open it with Notepad, it will somewhat look like as follows:-
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIChjCCAe8CAQAwFzEVMBMGA1UEAwwMMTAuMTMxLjEwLjEyMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQC3unAcoIxAx+y5xWB7NXhZlJlvfWes30w9FFmnlpXp
RR56FyQLmtc1H4KtEY/UJNQ/ud/Bi0VL039WaRnISC18gjAlDhFTNX0H14x55PGy
FrX4/0UPdp2opSeI9En8FiPIBYHGP9exjXuLoanWowhluu/pXtdL/vZZzAOxliEG
wQIDAQABoIIBLTAaBgorBgEEAYI3DQIDMQwWCjYuMC42MDAxLjIwRQYJKwYBBAGC
NxUUMTgwNgIBBQwMc3JhLXN0cmVzcy00DBpTUkEtU1RSRVNTLTRcQWRtaW5pc3Ry
YXRvcgwHTU1DLkVYRTBgBgkqhkiG9w0BCQ4xUzBRMBMGA1UdJQQMMAoGCCsGAQUF
BwMBMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwEwHQYDVR0OBBYEFPvbYdsW
c5+59cqXEi9cmQDsnaqPMGYGCisGAQQBgjcNAgIxWDBWAgEAHk4ATQBpAGMAcgBv
AHMAbwBmAHQAIABTAG8AZgB0AHcAYQByAGUAIABLAGUAeQAgAFMAdABvAHIAYQBn
AGUAIABQAHIAbwB2AGkAZABlAHIDAQAwDQYJKoZIhvcNAQEFBQADgYEAMVbeX7Nm
UqRusxQmvKX0OFsfHCRYqGGI73REiKkVskh+Cl1yjgIK0zx14Fzm3Y5PDz8iaKrS
No/jTCPUG4voyjYPFB4YaP2ARBI+InO/a62U9oNYazxzSHmellW9C8PHOs7EtzIu
kFMwB+DxcJ1hGdcCzZMw/fYK2qS6nxmYZHU=
-----END NEW CERTIFICATE REQUEST-----

You will have to make use of this certificate request content to generate the certificate on the Public Certificate Authority.
Thanks,
Amit Kumar
Software Design Engineer/Test (amkuma@online.microsoft.com**),
RRAS, Windows Enterprise Networking, Microsoft.
** Remove the "online" to actually email me
[This posting is provided "AS IS" with no warranties, and confers no rights.]
blogs.technet.com

Publishing a Windows Server 2008 SSL VPN Server Using ISA 2006 Firewalls

How to configure an SSTP VPN server and how to configure the ISA Firewall to allow inbound connections from SSTP VPN client to the SSTP VPN server.

If you would like to read the following parts in this article series please go to:

Being a road warrior is always a bit of a crap shoot. You are pretty sure that the hotel you are going to will have an Internet connection. But will the Internet connection work? How many times have you had to troubleshoot your Internet connection in a hotel, only to find out that there is something wrong with the wireless connection or the router for your segment in the hotel.
But getting that Internet connection to work often is not the end of your troubles; your next worry is what kind of firewall does the hotel have in place? Does the hotel firewall support VPN connections? If so, what kind of VPN connections does it support? I have been to hotels that support only PPTP connections. Other hotels support only L2TP/IPSec connection, and some hotels that support both PPTP and L2TP/IPSec. Unfortunately, many hotels do not support either PPTP or L2TP/IPSec. As a network admin who might need to access many networks over a VPN connection when I am out of town, this is where the real pain starts.
The problem with hotel firewalls or routers is that they want to keep things easy. They are not blocking your VPN connections out of spite or because they want to ruin your trip. It is much easier from a management and security point of view to allow only HTTP and HTTPS (SSL) outbound, two easy protocols that are used by 99% of their users. This makes troubleshooting much easier for the network service providers who support the Internet connectivity for these hotels.
Of course, if you are someone who needs a VPN connection and you are staying at one of these hotels, life becomes an exercise in futility when your network, or one of your client’s networks needs servicing and the only way to provide that service is through a network level VPN connection. What to do? In the past, I have bent my policy on never allowing RDP connections to a network just in order to get the access I need to fix things – but this is always uncomfortable, because I am acutely aware of the risks of allowing RDP access from the Internet.
The good news is that we now have a solution, or at least we will have one when Windows Server 2008 is released next month (February 2008). That solution is the SSTP VPN protocol included with Windows Server 2008. SSTP is the Secure Socket Tunnel Protocol, which is essentially PPP over SSL. SSTP allows you to connect to your VPN server over TCP port 443, just like any other SSL connection, and it also works with non-authenticating Web proxies, so even if your hotel uses an ISA firewall for outbound access (you would be surprised by how many do), your SSTP connections will work fine through them.
In this article I am going to show you how to configure an SSTP VPN server and how to configure the ISA Firewall to allow inbound connections from SSTP VPN client to the SSTP VPN server. The ISA Firewall will be configured with two Publishing Rules: a Server Publishing Rule that allows inbound connections to the SSTP server and a Web Publishing Rule that allows inbound connections to the CRL distribution site.
First, let us take a look at our example network for this configuration:

Figure 1
There are two data paths we need to take into consideration here. First, there is the SSTP connection that must be made through the ISA Firewall that terminates at the SSTP SSL VPN server. The second connection needs to make two hops through our network – the first hop is an HTTP connection made through the ISA Firewall, and the second hop is through the SSL VPN gateway to the CDP. In order to support this, we will need to configure the SSL VPN gateway to be a NAT server that will perform reverse NAT in order to allow access to the CDP located behind the VPN server.
The SSTP VPN client must be running Vista SP1. The RTM version of the Vista client does not support SSTP.
The ISA Firewall is not a domain member in this example. The reason for this is that domain membership is not a requirement in this scenario. If you wanted to make the ISA Firewall a domain member, you would have to configure the ISA Firewall to use a router behind the ISA Firewall’s internal interface, since intradomain communications do not work with NAT devices in the path. The router would be put in parallel with the VPN server, so that its internal and external interfaces are on network IDs that mirror those on the SSTP VPN gateway computer.
The SSTP VPN gateway is a domain member. This is so we can take advantage of Windows authentication. I did this for simplicity, since I did not want to get into the details of setting up a Network Policy Server in this article. If you do not want your SSTP VPN gateway to be a domain member, you can install a Network Policy Server on the corporate network and configure the VPN Server to use that for authentication and accounting (NPS servers are the Windows 2008 replacements for the Windows Server 2003 IAS server).
The CRL Distribution Point computer on the internal network is a domain controller for the msfirewall.org domain. Server Roles installed on this machine include Active Directory Certificate Services, DHCP Server, DNS Server, Active Directory Domain Services, and the WINS server feature.
We will need to perform the following procedures to get the solution working:
  • Install IIS on the VPN server.
  • Request a machine certificate for the VPN server using the IIS Certificate Request Wizard.
  • Install the RRAS server role on the VPN server.
  • Enable the RRAS Server and configure it to be a VPN and NAT server.
  • Configure the NAT server to publish the CRL.
  • Configure the User Account to allow dial-up connections.
  • Configure IIS on the Certificate Server to allow HTTP connections for the CRL directory.
  • Configure the ISA Firewall with an PPTP VPN Server, SSL VPN Server and CDP Web Publishing Rules.
  • Configure the HOSTS file on the VPN client.
  • Use PPTP to connect to the VPN server.
  • Obtain a CA Certificate from the Enterprise CA.
  • Configure the ISA Firewall with an SSL VPN Server Publishing and CDP Web Publishing Rules.
  • Configure the Client to use SSTP and Connect to the VPN Server using SSTP.

Install IIS on the VPN Server

This might sound like a strange way to get things started, as I normally suggest that you never put a Web server on a network security device. The good news is that we do not need to keep the Web server on the VPN server, we just need to use it for a little while. The reason for this is that the Web enrollment site included with the Windows Server 2008 Certificate Server is no longer useful for requesting computer certificates, at least not in a Windows Server 2008 and Windows Vista environment. In fact, it is no use at all. What is interesting about this is that you can still try to get a computer certificate using the Web enrollment site, and it will look like it was installed, but in fact the certificate is not installed.
To solve this problem, we will take advantage of the fact that we are using an enterprise CA. When using an Enterprise CA, you can make a request to an online certificate server. The online request for a computer certificate is allowed when you use the IIS Certificate Request Wizard and request what they now call a “Domain Certificate”. This only works when the machine requesting the certificate belongs to the same domain as the Enterprise CA.
Perform the following steps on the VPN server to install the IIS Web server role:
  1. Open the Windows 2008 Server Manager.
  2. In the left pane of the console, click the Roles node.

Figure 2

  1. Click the Add Roles link on the right side of the right pane.
  2. Click Next on the Before You Begin page.
  3. Put a checkmark in the Web Server (IIS) checkbox on the Select Server Roles page. Click Next.

Figure 3

  1. Read the information on the Web Server (IIS) page if you like. This is good general information about using IIS 7 as a Web server, but since we are not going to use the IIS Web server on the VPN server, this information does not really apply to our scenario. Click Next.
  2. On the Select Role Services page, a number of options are already selected. However, if you use the default options, it does not seem that you will get the option of using the Certificate Request Wizard. This was the case when I tested it. There is no Role Service for the Certificate Request Wizard, so I tried putting a checkmark in each of the Security options and that seemed to work. Do the same on yours and click Next.

Figure 4

  1. Review the information on the Confirm Installation Selections page and click Install.
  2. Click Close on the Installation Results page.

Figure 5

Request a Machine Certificate for the VPN Server using the IIS Certificate Request Wizard

The next step is to request a machine certificate for the VPN server. The VPN server needs a machine certificate to create the SSL VPN connection with the SSL VPN client computer. The common name on the certificate must match the name that the VPN client will use to connect to the SSL VPN gateway computer. This means that you will need to create a public DNS entry for the name on the certificate so that resolves to the external IP address on the VPN server, or the IP address of a NAT device in front of the VPN server that will forward the connection to the SSL VPN server.
Perform the following steps to request and install the computer certificate on the SSL VPN server:
  1. In the Server Manager, expand the Roles node in the left pane and then expand the Web Server (IIS) node. Click on Internet Information Services (IIS) Manager.

Figure 6

  1. In the Internet Information Services (IIS) Manager console that appears in the panes to the right of the left pane, click on the name of the server. In this example, the name of the server is W2008RC0-VPNGW. Click on the Server Certificates icon in the right pane of the IIS console.

Figure 7

  1. In the right pane of the console, click the Create Domain Certificate link.

Figure 8

  1. Fill out the information on the Distinguished Name Properties page. The most important entry on this page is the Common Name entry. This name is the name that VPN clients will use to connect to the VPN server. You will need a public DNS entry for this name so that is resolves either to the external interface of the VPN server, or the public address of a NAT device in front of the VPN server. In this example we’ll use the common name sstp.msfirewall.org. Later, we’ll create HOSTS file entries on the VPN client computer so that it can resolve this name. Click Next.

Figure 9

  1. On the Online Certification Authority page, click the Select button. In the Select Certification Authority dialog box, click the name of the Enterprise CA and click OK. Enter a friendly name for the certificate in the Friendly name text box. In this example we’ll use the name SSTP Cert so that we know it’s being used for the SSTP VPN gateway.

Figure 10

  1. Click Finish on the Online Certification Authority page.

Figure 11

  1. The wizard will run and then disappear. After this point you’ll see the certificate appear in the IIS console. Double click on the certificate and you can see the common name in the Issued to section and that we have a private key that corresponds to the certificate. Click OK to close the Certificate dialog box.

Figure 12

Now that we have a certificate, we can install the RRAS Server Role. Note that it’s critical that you install the certificate first, before you install the RRAS Server Role. If you don’t, you’ll end up being in a world of hurt, because you’ll have to use a fairly complex command line routine to bind the certificate to the SSL VPN listener.

Install the RRAS Server Role on the VPN Server


To install the RRAS Server Role, perform the following steps:
  1. In the Server Manager, click the Roles node in the left pane of the console.
  2. In the Roles Summary section, click the Add Roles link.
  3. Click Next on the Before You Begin page.
  4. On the Select Server Roles page, put a checkmark in the Network Policy and Access Services checkbox. Click Next.

Figure 13

  1. Read the information on the Network Policy and Access Services page. Most of it is about the new Network Policy Server (which used to be called the Internet Authentication Server [IAS] which was a RADIUS server) and NAP, neither of which apply to our current scenario. Click Next.
  2. On the Select Role Services page, put a checkmark in the Routing and Remote Access Services checkbox. This will put checkmarks in the Remote Access Service and Routing checkboxes. Click Next.

Figure 14

  1. Click Install on the Confirm Installation Selections page.
  2. Click Close on the Installation Results page.

Enable the RRAS Server and Configure it to be a VPN and NAT Server

Now that the RRAS server role is installed, we need to enable the RRAS service, just like how we did it in previous versions of Windows. We need to enable the VPN server feature and the NAT service. While it’s clear why we need to enable the VPN server component, you might wonder why we need to enable the NAT server. The reason for enabling the NAT server is so that external clients can gain access to the Certificate Server to connect to the CRL. If the SSTP VPN client can’t download the CRL, the SSTP VPN connection will fail.
In order to allow access to the CRL, we’ll configure the VPN server as a NAT server and publish the CRL using reverse NAT. The SSL VPN client will first connect to the ISA Firewall. The ISA Firewall will be configured with a Web Publishing Rule that allows connections to the URL required to access the CRL. This Web Publishing Rule is also configured to forward the request to the external interface of the NAT Server. The NAT server on the VPN server will be configured to forward the HTTP request to the certificate server that contains the CRL.
Perform the following steps to enable the RRAS service:
  1. In the Server Manager, expand the Roles node in the left pane of the console. Expand the Network Policy and Access Services node and click on the Routing and Remote Access node. Right click on the Routing and Remote Access node and click Configure and Enable Routing and Remote Access.

Figure 15

  1. Click Next on the Welcome to the Routing and Remote Access Server Setup Wizard page.
  2. On the Configuration page, select the Virtual private network (VPN) access and NAT option and click Next.

Figure 16

  1. On the VPN Connection page, select the NIC in the Network interfaces section that represents the external interface of the VPN server. Then click Next.
  2. On the IP Address Assignment page, select the Automatically option. We can select this option because we have a DHCP server installed on the domain controller behind the VPN server. If you didn’t have a DHCP server, then you would have to select the From a specified range of addresses option and then provide a list of addresses that VPN clients could use when connecting to the network through the VPN gateway. Click Next.

Figure 17

  1. On the Managing Multiple Remote Access Servers page, select the No, use Routing and Remote Access to authenticate connection requests. This is the option we use when there is no NPS or RADIUS server available. Since the VPN server is a member of the domain, you can authenticate users using domain accounts. If the VPN server were not a member of the domain, then only local accounts on the VPN server could be used, unless you decide to use the NPS server. I’ll do an article on how to use an NPS server in the future. Click Next.

Figure 18

  1. Read the summary information on the Completing the Routing and Remote Access Server Setup Wizard page and click Finish.
  2. Click OK in the Routing and Remote Access dialog box informing you that relaying of DHCP messages requires a DHCP relay agent.
  3. In the left pane of the console, expand the Routing and Remote Access node and then click on the Ports node. In the middle pane you’ll see that WAN Miniport connections for SSTP are now available.

Figure 19

Configure the NAT Server to Publish the CRL

As I mentioned earlier, the SSL VPN client needs to be able to download the CRL to confirm that the server certificate on the VPN server hasn’t been revoked. In order to do this, you need to configure a device in front of the certificate server to forward HTTP requests for the CRL location to the Certificate Server.
How do you know what URL the SSL VPN client needs to connect to in order to download the CRL? That information is contained within certificate itself. If you go to the VPN server again and double click on the certificate in the IIS console, as you did earlier, you’ll be able to find this information.
Click the Details tab of the certificate and scroll down to the CRL Distribution Points entry and click on that entry. In the lower pane you’ll see the various distribution points based on the protocol used to access those points. In the certificate seen in the figure below, you can see that we need to allow the SSL VPN client access to the CRL via the URL:
http://win2008rc0-dc.msfirewall.org/CertEnroll/WIN2008RC0-DC.msfirewall.org.crl

Figure 20

Because of this, you need to create a public DNS entry for this name so that external VPN clients can resolve this name to an IP address on the external interface of the ISA Firewall. In this example, we need to have win2008rc0-dc.msfirewall.org resolve to the IP address on the external interface of the ISA Firewall. When the connection reaches the external interface of the ISA Firewall, it will forward the connection to the NAT server on the VPN server, which will then perform reverse NAT and send the connection to the CA that’s hosting the CDP.
I should note here that using the default CRL site name might not be the more secure option, since it exposes a private computer name to the Internet. You can create a custom CDP (CRL Distribution Point) to prevent this if you consider exposing the private name of your CA in your public DNS a security issue. You can find some information on how to change these values at How to Change the Policy Settings for a Certification Authority (CA) in Windows 2000
Perform the following steps to configure RRAS NAT to forward HTTP requests to Certificate Server:
  1. In the left pane of the Server Manager, expand the Routing and Remote Access node and then expand the IPv4 node. Click on the NAT node.
  2. In the NAT node, right click on the external interface in the middle pane of the console. In this example, the name of the external interface is Local Area Connection. Click Properties.

Figure 21

  1. In the Local Area Connection Properties dialog box, click on the Web Server (HTTP) checkbox. That brings up the Edit Service dialog box. In the Private Address text box, enter the IP address of the Certificate Server on the internal network. Click OK.

Figure 22

  1. Click OK in the Local Area Connection Properties dialog box.

Figure 23

Now that the NAT server is installed and configured, we can move our attention to configuring the CA server, the ISA Firewall and the SSTP VPN client.

Summary

In this article we began with a discussion on the challenges of VPN remote access from hotel locations and how the SSTP protocol helps to solve these problems by allowing VPN connections to take place over an SSL connection through TCP port 443, which is allowed through all firewalls in these environments. Then we installed certificate services on the VPN server so that we could obtain a computer certificate. After installing the certificate on the SSL VPN server, we installed the RRAS VPN and NAT services on the VPN gateway. We finished up by configuring the NAT server on the VPN gateway to forward incoming HTTP connections forwarded by the ISA Firewall to terminate on the CA hosting the CDP. Next week we will finish up the configuration by configuring the CA server, the ISA Firewall and the SSTP VPN client.
 Part 2
We will configure the SSL VPN client so that it connects to the SSTP SSL VPN server and then test the connection. We will also confirm that the SSTP connection was successful. 

Publishing a Windows Server 2008 SSL VPN Server Using ISA 2006 Firewalls (Part 2)

How to configure a user account to allow dial-up access and then configure the CDP to allow anonymous HTTP connections. Then we will finish up by configuring the ISA Firewall to allow the required connections to the VPN server and the CDP Web site.

Thomas Shinder photo
AddThis
If you would like to read the other parts in this article series please go to:
In the first part of this three part series on how to publish the Windows Server 2008 SSTP SSL VPN server, we began with a discussion on the challenges of VPN remote access from hotel locations and how the SSTP protocol helps to solve these problems by allowing VPN connections to take place over an SSL connection through TCP port 443, which is allowed through all firewalls in these environments. Then we installed certificate services on the VPN server so that we could obtain a computer certificate. After installing the certificate on the SSL VPN server, we installed the RRAS VPN and NAT services on the VPN gateway. We finished up by configuring the NAT server on the VPN gateway to forward incoming HTTP connections forwarded by the ISA Firewall to terminate on the CA hosting the CDP.
In this, part two of the article series, we will configure a user account to allow dial-up access and then configure the CDP to allow anonymous HTTP connections. Then we will finish up by configuring the ISA Firewall to allow the required connections to the VPN server and the CDP Web site.

Configure the User Account to Allow Dial-up Connections

User accounts need permission for dial-up access before they can connect to a Windows VPN server that is a member of an Active Directory domain. The best way to do this is to use a Network Policy Server (NPS) and use the default user account permission which is to allow remote access based on NPS policy. However, we did not install an NPS server in this scenario, so we will have to manually configure the user’s dial-in permission.
I will write in a future article how you can use an NPS server and EAP User Certificate authentication to establish the SSL VPN server connection.
Perform the following steps to enable dial-in permission on the user account that you want to connect to the SSL VPN server. In this example we will enable dial-in access for the default domain administrator account:
  1. At the domain controller, open the Active Directory Users and Computers console from the Administrative Tools menu.
  2. In the left pane of the console, expand the domain name and click on the Users node. Double click on the Administrator account.
  3. Click on the Dial-in tab. The default setting is Control access through NPS Network Policy. Since we do not have an NPS server in this scenario, we will change the setting to Allow access, as seen in the figure below. Click OK.

Figure 1

Configure IIS on the Certificate Server to Allow HTTP Connections for the CRL Directory

For some reason, when the installation wizard installs the Certificate Services Web site, it configures the CRL directory to require an SSL connection. While this seems like a good idea from a security point of view, the problem is that the URI on the certificate is not configured to use SSL. I suppose you could create a custom CDP entry for the certificate so that it uses SSL, but you can bet dollars to donuts that Microsoft has not documented this problem anywhere. Since we are using the default settings for the CDP in this article, we need to turn off the SSL requirement on the CA’s Web site for the CRL directory path.
Perform the following steps to disable the SSL requirement for the CRL directory:
  1. From the Administrative Tools menu, open the Internet Information Services (IIS) Manager.
  2. In the left pane of the IIS console, expand the server name and then expand the Sites node. Expand the Default Web Site node and click on the CertEnroll node, as seen in the figure below.

Figure 2

  1. If you look in the middle pane of the console, you will see that the CRL is located in this virtual directory, as seen in the figure below. In order to see the content of this virtual directory, you will need to click on the Content View button at the bottom of the middle pane.

Figure 3

  1. Click on the Features View button on the bottom of the middle pane. At the bottom of the middle pane, double click the SSL Settings icon.

Figure 4

  1. The SSL Settings page appears in the middle pane. Remove the checkmark from the Require SSL checkbox. Click the Apply link in the right pane of the console.

Figure 5

  1. Close the IIS console after you see the The changes have been successfully saved Alert.

Figure 6

Configure the ISA Firewall with an PPTP VPN Server, SSL VPN Server and CDP Web Publishing Rules


Now we are ready to configure the ISA Firewall. We need to create three publishing rules to support the solution:
  • A Web Publishing Rule that allows the SSL VPN access to the CRL Distribution Point (CDP).
  • A Server Publishing Rule that allows inbound SSL connections to the SSTP server which allows the SSTP connection to be established with the VPN server.
  • A Server Publishing that allows PPTP to the VPN server, so that the VPN client can access the CA certificate from the Web Enrollment site on the network behind the VPN server.
After your clients have obtained certificates, you can disable the PPTP rule. Or you can leave the PPTP rule or use L2TP/IPSec instead of PPTP for a more secure connection. The reason why you might want to leave an alternate VPN protocol enabled is that only Windows Vista SP1 clients support SSTP. Windows XP SP3 might support it, but it is not looking like it right now, as I have installed a release candidate of Windows XP SP3 and there is no evidence of SSTP support in its VPN client.
Before we get started with the procedure, you might be asking yourself why we are using a Server Publishing Rule for the SSTP connection. After all, if we used a Web Publishing Rule instead of a Server Publishing Rule, we could control access to the SSTP server based on path and public name. We might even be able to tighten the rule even more by configuring the HTTP Security Filter. Unfortunately, I have not found a way to make this work.
However, that does not mean it cannot work. From what I have read about SSTP on the RRAS Team Blog, it is at least theoretically possible to terminate the SSL connect at the ISA Firewall and forward the connection to the SSTP VPN gateway. However, when I tried to do this, I saw in the ISA Firewall’s log files that a connection was established and then immediately terminated by the ISA Firewall.
If you would like to give it a try, you should try to decipher the instructions in the RRAS Team Blog file on how to get SSL to HTTP bridging to work with the ISA Firewall. While SSL to SSL would be more secure, I would be happy to see if it is possible to get even SSL to HTTP bridging to work. For more information, check out: Configuring SSTP based VPN server behind a SSL terminator (or reverse HTTP proxy).
We will start with the Web Publishing Rule for the CDP:
  1. In the ISA Firewall console, click on the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Publish Web Sites link.
  2. On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the rule in the Web Publishing Rule name text box. In this example, we will name the rule CDP Site. Click Next.
  3. On the Select Rule Action page, select the Allow option and click Next.

Figure 7

  1. On the Publishing Type page, select the Publish a single Web site or load balancer option and click Next.

Figure 8

  1. On the Server Connection Security page, select the Use non-secured connection to connect the published Web server or server farm option. We select this option because the SSTP VPN client does not use SSL to connect to the CDP. Click Next.

Figure 9

  1. On the Internal Publishing Details page, enter a name for the CDP Web site in the Internal site name text box. Since we are using HTTP, it does not matter what name we enter into this text box. Had this been an SSL publishing rule, we would have had to enter the name on the Web site certificate bound to the site. Put a checkmark in the Use a computer name or IP address to connect to the published server checkbox and then put in the IP address of the external interface of the VPN server. In this case, the IP address on the external interface of the VPN server is 10.10.10.2. This will allow the NAT server on the VPN server to forward the HTTP connection to the CDP Web site. Click Next.

Figure 10

  1. When the SSTP VPN client calls for the CRL, it will use the address listed on the certificate. As we saw in part one of this article series, the URL on the certificate for the CRL is http://win2008rc0-dc.msfirewall.org/CertEnroll/WIN2008RC0-DC.msfirewall.org.crl. To make our Web Publishing Rule more secure, we can limit the paths external clients can reach through this Web Publishing Rule. Since we only want to give access to the CRL, we will enter the path /CertEnroll/WIN2008RC0-DC.msfirewall.org.crl. This prevents external users from “looking around” through different paths on our certificate server. We do not need to worry about forwarding the host header, since we’re not using any Host Header controls on the certificate server’s Web site. Click Next.

Figure 11

  1. We can further lock down this rule by making sure only clients that enter the correct host name are able to connect through this Web Publishing Rule. The host name is listed in the CDP section of the certificate, which in this case is win2008rc0-dc.msfirewall.org. On the Public Name Details page, select the, This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter win2008rc0-dc.msfirewall.org. We do not need to make any changes in the path since we configured the path on the last page of the wizard. Click Next.

Figure 12

  1. Click the New button on the Select Web Listener page.
  2. On the Welcome to the New Web Listener Wizard page, enter a name for the Web Listener in the Web listener name text box. In this example, we will name the Web Listener HTTP. Click Next.
  3. On the Client Connection Security page, select the Do not require SSL secured connections with clients option. The reason for this is that the SSTP client doesn’t use SSL to gain access to the CDP. Click Next.

Figure 13

  1. On the Web Listener IP Addresses page, put a checkmark in the External checkbox. We do not need to select IP addresses since in this example we have only a single IP address on the external interface of the ISA Firewall. You can leave the checkmark in the ISA Server will compress content sent to clients through this Web Listener if the clients requesting the content support compression checkbox. Click Next.

Figure 14

  1. On the Authentication Settings page, select the No Authentication option from the Select how clients will provide credentials to the ISA Server drop down list. The SSTP client is not able to authenticate when accessing the CDP, so we must not enable authentication on this listener. Well, you can enable authentication if you like, if you need to use this listener for other Web Publishing Rules, but we have to make sure to allow access to All Users, in which case no authentication takes place. Click Next.

Figure 15

  1. Click Next on the Single Sign On Settings page.
  2. Click Finish on the Completing the New Web Listener Wizard page.
  3. Click Next on the Select Web Listener page.

Figure 16

  1. On the Authentication Delegation page, select the No delegation, and client cannot authenticate directly option from the Select the method used by ISA Server to authenticate to the published Web server drop down list. Since no authentication is take place on this connection, there is no reason to allow authentication. Click Next.  

Figure 17

  1. On the User Sets page, accept the default setting, All Users, and click Next.
  2. Click Finish on the Completing the New Web Publishing Rule Wizard page.
Now let us create the Server Publishing Rule for the PPTP Server:
  1. In the ISA Firewall console, click the Firewall Policy node. Click the Tasks tab in the Task Pane and click Publish Non-Web Server Protocols.
  2. On the Welcome to the New Server Publishing Rule Wizard page, enter a name for the rule in the Server publishing rule name text box. In this example we’ll name the rule PPTP VPN. Click Next.
  3. On the Select Server page, enter the IP address on the external interface of the VPN server. In this example, the external interface of the VPN server is 10.10.10.2, so we’ll enter that into the Server IP address text box. Click Next.

Figure 18

  1. On the Select Protocol page, select the PPTP Server option from the Selected protocol drop down list. Click Next.

Figure 19

  1. On the Network Listener IP Addresses page, put a checkmark in the External checkbox. Click Next.

Figure 20

  1. Click Finish on the Completing the New Server Publishing Rule Wizard page.
Now we will finish up our publishing rules by creating a Server Publishing Rule for the SSTP protocol, which is actually an HTTPS Server Publishing Rule:
  1. In the ISA Firewall console, click the Firewall Policy node in the left pane of the console. Click the Tasks tab in the Task Pane and click Publish Non-Web Server.
  2. On the Welcome to the New Server Publishing Rule Wizard page, enter a name for the Server Publishing Rule in the Server publishing rule name text box. In this example, we will name the rule SSTP Server. Click Next.
  3. On the Select Server page, enter the IP address on the external interface of the VPN server in the Server IP address text box. In this example, we’ll enter 10.10.10.2. Click Next.
  4. On the Select Protocol page, select the HTTPS Server option from the Selected protocol drop down list. Click Next.

Figure 21

  1. On the Network Listener IP Addresses page, put a checkmark in the External checkbox. Click Next.
  2. Click Finish on the Completing the New Server Publishing Rule Wizard page.
  3. Click Apply to save the changes and update the firewall policy. Click OK in the Saving Configuration Changes dialog box.

Summary

In this, part two of our series on publishing the Windows Server 2008 SSTP SSL VPN server, we started by configuring dial-in permissions for a user account. We then moved to the CDP Web server so that anonymous HTTP connection could be made to it. Then we went to the ISA Firewall to create the two Server Publishing Rules and one Web Publishing Rule that are required to allow the connections to the VPN server and the CRL Distribution Point. In the next and final part of the series, we will configure the VPN client to connect to the SSL VPN server and confirm the connections by looking at information on the client, the VPN server and at the ISA Firewall.
Part 3 
We will configure the SSL VPN client so that it connects to the SSTP SSL VPN server and then test the connection. We will also confirm that the SSTP connection was successful.
If you would like to read the previous parts in this article series please go to:
In the first two parts of this series on how to publish a Window Server 2008 SSTP SSL VPN server, we went over the challenges of VPN access from hotel and other public networks, then we went over the configuration of the CDP Web site and the ISA Firewall. We also enabled a user account for dial-in access.
In this, part three and the part article in the series, we’ll configure the SSL VPN client so that it will be able to connect to the SSTP SSL VPN server and then test the connection. We’ll look at some confirmatory information on the SSL VPN client, the ISA Firewall and at the RRAS server to confirm that the SSTP connection was successful.
For a complete description of how to arrive at a working configuration, check out part 1 of this series.

Configure the HOSTS File on the VPN Client

Now we can move our attention to the VPN client. The first thing we need to do on the client is configure the HOSTS file so that we can simulate a public DNS infrastructure. There are two names that we need to enter into the HOSTS file (and the same is true for the public DNS server that you would use in a production environment). The first name is the name of the VPN server, as defined by the common/subject name on the certificate that we’ve bound to the SSL VPN server. The second name we need to enter into the HOSTS file (or a public DNS server) is the CDP URL, which is found on the certificate. We saw the location of the CDP information in part 1 of this series.
Remember, these names much resolve to the IP address on the external interface of the ISA Firewall that is listening for the incoming connections, as defined by the settings on the publishing rule and listener.
The two names we will need to enter into the HOSTS file in this example are:
192.168.1.72     sstp.msfirewall.org
192.168.1.72     win2008rc0-dc.msfirewall.org
Perform the following steps on the Vista SP1 VPN client to configure the HOSTS file:
  1. Click the Start button and enter c:\windows\system32\drivers\etc\hosts in the search box and press ENTER.
  2. In the Open With dialog box, double click on Notepad.
  3. Enter the HOSTS file entries using the format as seen in the figure below. Make sure that you press enter after the last line so that the cursor appears under the last line.

Figure 1

  1. Close the file and choose the save option when asked.

Use PPTP to Connect to the VPN Server

We are getting closer to creating an SSL VPN connection! The next step is to create a VPN connectoid on the Vista SP1 client that will allow us to make an initial VPN connection to the VPN server. We need to do this in our current scenario because the client computer is not a domain member. Since the machine is not a domain member, it will not have the CA certificate automatically installed in its Trusted Root Certificate Authorities machine certificate store. If the machine were a domain member, autoenrollment would have taken care of that problem for us, since we have installed an Enterprise CA.
The easiest way to do this is to create a PPTP connection from the Vista SP1 VPN client to the Windows Server 2008 VPN server. By default, the VPN server will support PPTP connections and the client will try PPTP first before trying L2TP/IPSec and then SSTP. To do this, we need to create a VPN connectoid or connection object.
Perform the following steps on the VPN client to create the connectoid:
  1. On the VPN client, right click the network icon in the tray and click the Network and Sharing Center.
  2. In the Network Sharing Center window, click the Set up a connection or network link on the left side of the window.
  3. On the Choose a connection option page, click on the Connect to a workplace entry and click Next.

Figure 2

  1. On the How do you want to connect page, select the Use my Internet connection (VPN) entry.

Figure 3

  1. On the Type the Internet address to connect to page, enter the name of the SSL VPN server. Make sure that this is the same name as the common name on the certificate used by the SSL VPN server. In this example, the name is sstp.msfirewall.org. Enter a Destination Name. In this example we will name the destination SSL VPN. Click Next.

Figure 4

  1. On the Type your user name and password page, enter the User name, Password and Domain. Click Connect.

Figure 5

  1. Click Close on the You are connected page.

Figure 6

  1. On the Select a location for the “SSL VPN” network  page, select the Work option.

Figure 7

  1. Click Continue on the UAC prompt.
  2. Click Close on the Successfully set network settings page.

Figure 8

  1. In the Network and Sharing Center, click on the View status link in the SSL VPN section, as seen in the figure below. You will see in the SSL VPN Status dialog box that the VPN connection type is PPTP. Click Close in the SSL VPN Status dialog box.

Figure 9

  1. Open a command prompt and ping the domain controller. In this example, the IP address of the domain controller is 10.0.0.2. If your VPN connection is successful, you will receive a ping reply from the domain controller.

Figure 10

Obtain a CA Certificate from the Enterprise CA

advertisement

Advertisement
Use the #1 Exchange Server anti-spam solution, which uses two anti-spam engines to capture over 99% of spam flooding your server on a daily basis
Download a free time-limited trial!
The SSL VPN client needs to trust the CA that issued the certificate used by the SSTP VPN server. In order to establish this trust, we need to install the CA certificate of the CA that issued the VPN server’s certificate. We can do this by connecting to the Web enrollment site on the CA on the internal network and installing the certificate in the VPN client’s Trusted Root Certification Authorities certificate store.
Perform the following steps to obtain the certificate from the Web enrollment site:
  1. On the VPN client that is connected to the VPN server over a PPTP link, enter http://10.0.0.2/certsrv in the address bar in Internet Explorer and press ENTER.
  2. Enter a user name and password that is valid in the credentials dialog box. In this example we will use the default domain administrator account’s username and password.
  3. On the Welcome page of the Web enrollment site, click the Download a CA certificate, certificate chain, or CRL link.

Figure 11

  1. Click Allow in the dialog box warning you that A website wants to open web content using this program on your computer. Then click Close on the Did you notice the Information bar dialog box if it appears.

Figure 12

  1. Note that the Information bar informs you that the Web site might not work correctly, since the ActiveX control is blocked. This should not be a problem, as we’ll be downloading the CA certificate and using the Certificates MMC to install the certificate. Click the Download CA certificate link.

Figure 13

  1. In the File Download – Security Warning dialog box, click the Save button. Save the certificate to the Desktop.

Figure 14

  1. Click Close in the Download complete dialog box.
  2. Close Internet Explorer.
Now we need to install the CA certificate into the VPN client machine’s Trusted Root Certification Authorities Certificate Store. Perform the following steps to install the certificate:
  1. Click Start and then enter mmc in the Search box. Press ENTER.
  2. Click Continue in the UAC dialog box.
  3. In the Console1 window, click the File menu and then click Add/Remove Snap-in.
  4. In the Add or Remove Snap-ins dialog box, click the Certificates entry in the Available snap-ins list and then click Add.
  5. On the Certificates snap-in page, select the Computer account option and click Finish.
  6. On the Select Computer page, select the Local computer option and click Finish.
  7. Click OK in the Add or Remove Snap-ins dialog box.
  8. In the left pane of the console, expand the Certificates (Local Computer) node and then expand the Trusted Root Certification Authorities node. Click on the Certificates node. Right click on the Certificates node, point to All Tasks and click Import.

Figure 15

  1. Click Next on the Welcome to the Certificate Import Wizard page.
  2. On the File to Import page, use the Browse button to find the certificate, then click Next.

Figure 16

  1. On the Certificate Store page, confirm that the Place all certificates in the following store option is selected and that the Trusted Root Certification Authorities store is the one listed. Click Next.

Figure 17

  1. Click Finish on the Completing the Certificate Import page.
  2. Click OK in the dialog box informing you that the import was successful.
  3. The certificate now appears in the console, as seen in the figure below.

Figure 18

  1. Close the MMC console.

Configure the Client to use SSTP and Connect to the VPN Server using SSTP

We are almost there! Now we need to disconnect the VPN connection and configure the VPN client to use SSTP for its VPN protocol. In a production environment, you should not have to have the users do this step, as you would be using the Connection Manager Administration Kit to create the VPN connectoid for the user, which will set the client to use SSTP, or you would configure only SSTP ports on the VPN server.
It depends on your environment, as you want to time things so that users can use PPTP for a while as you’re deploying certificates. Of course, you can always deploy the CA certificates out of band, such as via a Web site download or e-mail, in which case you would not need to allow PPTP. But then, if you had some downlevel clients that don’t support SSTP, you would need to allow PPTP or L2TP/IPSec, so you would not be able to disable all non-SSTP ports. In that case, you’ll have to depend on manual configuration or an updated CMAK package.
Another option is to bind the SSTP listener to a specific IP address in the RRAS server. In this case, you could create a custom CMAK package that points only to the IP address on the SSL VPN server that is listening for the incoming SSTP connections. Other addresses on the SSTP VPN server would listen for PPTP and/or L2TP/IPSec connections.
Perform the following steps to disconnect the PPTP session and configure the VPN client connectoid to use SSTP:
  1. At the VPN client computer, open the Network and Sharing Center as you did earlier.
  2. In the Network and Sharing Center window, click the Disconnect link, which lies just under the View Status link we used earlier. The SSL VPN section will disappear from the Network and Sharing Center.
  3. In the Network and Sharing Center, click the Manage network connections link.
  4. Right click the SSL VPN link and click the Properties command.

Figure 19

  1. In the SSL VPN Properties dialog box, click the Networking tab. In the Type of VPN drop down box, click the down arrow and select the Secure Socket Tunneling Protocol (SSTP) option and click OK.

Figure 20

  1. Double click the SSL VPN connectoid in the Network Connections window.
  2. In the Connect SSL VPN dialog box, click the Connect button.
  3. When the connection is complete, right click the SSL VPN connectoid in the Network Connections window and click Status.

Figure 21

  1. In the SSL VPN Status dialog box, you can see that an SSTP WAN Miniport connection was established.

Figure 22

  1. If you go to the VPN server and open the Routing and Remote Access Console, you will confirm that an SSTP connection was established.

Figure 23

If you look in the ISA Firewall console, you will see a few log entries indicating the SSL VPN connection. An interesting find is that the SSTP VPN client also seems to want to send LDAP connections to the ISA Firewall. Not sure why this is the case, but I will keep looking in the RRAS Team Blog for more information on this and I will blog on this situation when I find out an answer.(Unfortunately, I could not capture this behavior when I restarted the SSTP VPN client, which makes the finding even more odd.)

Figure 24
If you have problems with your SSTP SSL VPN server configuration, the RRAS Team Blog includes a fantastic troubleshooting guide that has many error conditions and possible fixes for each of the error conditions. Check out their troubleshooting guide, How to debug SSTP specific connection failures.

Summary

In this, the final part of our article series on how to publish a Windows Server 2008 SSL VPN server using the 2006 ISA Firewall, we completed the configuration of the user account, the CRL Web site, the ISA Firewall and the SSL VPN client. We finished up by completing the SSTP connection and confirmed that it was successful. I hope you enjoyed this series and you are always welcome to write to me with questions at tshinder@isaserver.org. Thanks! –Tom.If you would like to read the previous parts in this article series please go to: