I've installed the free Hyper-V Server 2008 on a server, and there was no domain available, so I've left it in the local workgroup.

I had Vista x64 Ultimate installed on a laptop(workgroup too). I've downloaded the Windows Vista Service Pack 1 Management Tools update for the release version of Hyper-V and installed it on that laptop in order to manage the Hyper-V Server 2008 from it.

As you may know, we can't connect to the Hyper-V Server by IP address. The name of the Hyper-V Server was hypervstd. So I've added an entry for this name on the C:\Windows\System32\drivers\etc\HOSTS file on the laptop:

You can edit the HOSTS file on the Hyper-V Server too from the CMD window, just type "notepad.exe hosts" while you are in the C:\Windows\System32\drivers\etc\ folder to add an entry for the name of the machine on which the Hyper-V MMC is installed(you need a static IP address on this machine for that). Although it worked for me without doing that.

So:

- the Hyper-V Server 2008 and the Vista x64 laptop are members of the same workgroup(I've observed that might work if they are members of different workgroups).
- I've added a local administrator on the Hyper-V Server with the same user name and password as the user logged on the Vista laptop.
- the HOSTS files were prepared.

And now I can connect. However, I was getting the error "Access denied. Unable to establish communication between: ‘HYPERVSTD’ and ‘the name of the laptop’ " within the Virtual Machines area of the Hyper-V MMC.

I've followed Step 7 from John Howard’s tutorial, which is:

1. Click Start, Run, type DCOMCNFG. Click OK.
2. Expand Component Services, expand Computers. Right-click on My Computer and click on Properties.
3. Click on COM Security.
4. In the Access Permission area, click Edit Limits.
5. Select ANONYMOUS LOGON in the Group or User Name area. Then set the Permissions for ANONYMOUS LOGON to Allow for Remote Access.

And things started to work fine for me.

 - How do I restrict from which IP addresses the VPN clients can connect to the ISA VPN Server ?

 - How do I specify that ISA will accept PPTP remote access connections from a certain IP address range(s) and L2TP/IPsec remote access connections from another IP address range(s) ?

 - How do I restrict on which external IP address ISA listens for incoming VPN remote access connections (for PPTP and L2TP/IPsec) ?

 - How do I specify which users can use PPTP and which users can use L2TP/IPsec and adjust the firewall access rules to control access to internal resources in respect with the VPN protocol used by users ?

 - How do I specify that users from location X can use only PPTP and that users from location Y can use only L2TP/Psec and adjust the firewall access rules to control access to internal resources in respect with the VPN protocol used by users and the location of these users ?

 - How do I specify that a group of users can only connect from location X and another group of users can connect from any location ?

 - How do I disable DES and Diffie-Hellman 768-bit MODP group 1 for L2TP/IPsec on the ISA VPN server ?

Read more... or Download as PDF. 

As you may know, allowing TFTP through ISA was not an easy task in the past.

It looks that the future version of ISA, Threat Management Gateway (TMG) will include a TFTP filter, see Microsoft's About application filters article.

The TFTP filter in TMG Beta 1:

I've quickly tested it, trying to download or upload some files over a VPN connection to a TFTP server behind TMG from a VPN client. It worked very nice.

It was a straight process to allow TFTP for the VPN client, I've simply created an access rule allowing TFTP:

The TFTP filter is by default bound to the TFTP protocol:

Analyzing TMG's logs, we can see that TMG has allowed the server's response(which used to create problems, since the server chooses a different source port):

When a FTP client issues the PASV Request command, the FTP server supporting passive mode returns a response, 227 Entering Passive Mode, response which contains an IP address and a TCP port to which the FTP client will connect back in order to open a data connection.
That opens the possibility for an attacker to modify the server's response and enter another IP address(from the original IP address of the FTP server) to which the FTP client to connect. Doing that, the attacker may easily obtain an open TCP connection to another server from the client for various purposes.
For further reading, refer to this paper: Manipulating FTP Clients Using The PASV Command. A summary of this paper can be found here.
As said there, some clients will connect to whatever would be the IP address specified in the FTP server's response for the FTP PASV request command.

So what happens when such a FTP client(in this test Firefox 2.0) is behind the ISA 2006 Firewall, and uses FTP passive mode ?
As you may know, ISA 2006 includes a FTP filter(an application filter), for inspecting FTP traffic, and allowing the needed connections in respect with the PASV response of the FTP server.

First, let's test when the FTP client is not behind ISA. A Wireshark capture shows us what's happening.

As you can see, the FTP client connects to the 192.168.220.74 FTP server. However, in the response for PASV Request command, the server specifies the 192.168.220.73 IP address to which the FTP client to connect. And the FTP client does that. Note that there aren’t any Passive IP address, Passive Port or Passive IP NAT: True fields in the server’s response, these fields are shown by Wireshark to help us understand easier the FTP conversation. For example, if I select the Passive IP NAT: True field, we can see that no corresponding data in the hex area is selected(because there isn’t any) and Wireshark tells us that NAT is active because the server’s IP address and the IP address from server’s 227 Entering Passive Mode response are different. See Wireshark’s online help for Display Filter Reference: File Transfer Protocol (FTP).

Let's now put this FTP client behind ISA.
I'm going to start a Wireshark capture on the FTP client and one on the FTP server.

If we look at the one taken on the FTP server, we will see that the server gave the "expected" response for the PASV Request command, however, now, the client terminates the TCP connection(the packet with the FIN flag).

If we look at the one taken on the FTP client, we will see that instead of the "expected" response for the PASV Request command, there is a different message, containing the reply code "Syntax error, command unrecognized (500)" and a "500 the server returned invalid response for PASV command" argument, which causes the FTP client to terminate the FTP connection.

And Firefox will display the "500 the server returned invalid response for PASV command" message too.

So ISA blocked the possible dangerous response. Note that RFC 959 FILE TRANSFER PROTOCOL (FTP), does not mention that the return of a different IP address in the PASV response message is illegal or so. Also ISA 2006's FTP filter does not support the EPSV command. With EPSV(Extended Passive Mode), the FTP server's response will contain only the port number, and the client will assume that it will connect to the same IP address that was originally connected to.

If we repeat the scenario, this time using Opera 9.10 as the FTP client, the same thing can be observed, this time however, the FTP client sends the Quit command too.

Wireshark capture on the FTP server:

Wireshark capture on the FTP client:

Other FTP clients may attempt to use active mode if passive mode fails.

So ISA can help mitigate the security issues of such a behavior of the FTP client(assuming there is no real world application for it).

Note: You can publish with ISA 2006 without problems an internal or DMZ located passive FTP server with a FTP server publishing rule(when ISA is doing NAT from Internal to External, or respectively from DMZ to External). Just make sure the FTP server is not configured to return in the 227 Entering Passive Mode response, ISA's external IP address(the public IP address used on ISA to publish that FTP server). Some FTP servers, for example the Filezilla FTP Server, when located behind NAT devices(which cannot understand the FTP traffic), allow you to specify this IP address, see for example Filezilla FTP Server's help file. You do not need to do that with ISA, as ISA's FTP filter will modify on the fly server's 227 Entering Passive Mode response, replacing the internal IP address of the FTP server with ISA's external IP address(the public IP address used on ISA to publish that FTP server, which is the original IP address used to start the FTP connection by the external FTP client). If you do that, ISA will block the server's response, sending to the client the message we saw above, containing the reply code "Syntax error, command unrecognized (500)" and a "500 the server returned invalid response for PASV command" argument, which will cause the external FTP client to terminate the FTP connection. ISA's FTP filter expects in the FTP server's 227 Entering Passive Mode response, the original internal IP address of the FTP server.

You currently have an ISA Server 2006 SE on your network.
And you may have an existent site-to-site VPN connection, or plan to add one. For several reasons, you may like to move the existent site-to-site VPN connection over a dedicated connection(say, to buy for that a new Internet connection). Or you may want to create the new VPN tunnel over a dedicated Internet connection.

Depending on the nature of the remote VPN gateway, another ISA Server 2006 or a third-party VNP gateway, and your requirements, you need to choose between the IPsec tunnel mode VPN site-to-site connection or the L2TP/IPsec site-to-site VPN connection(I do not count PPTP, as personal, I dislike the use of it these days due to security reasons).

If you connect to a remote third-party VPN gateways, likely, your only option would be the IPsec tunnel mode VPN site-to-site connection.
If you connect to another ISA Server 2006, you may like to use, per Microsoft's recommendations, the L2TP/IPsec site-to-site VPN connection.

In this part we will establish an IPsec tunnel mode VPN site-to-site connection between two ISA Server 2006 SE SP1 installed on Windows 2003 Standard Edition R2 SP2.

The network diagram:

The lab diagram:

Read more...

Some time ago, I've posted on the Vyatta Users forum about an issue regarding L2TP/IPsec remote access VPN.
For some reasons, things went sideways, and an ambiguous situation reigned.

On 26.08.2008, on the Vyatta Users forum, an announce was made, that a Security Reference document is available for download at http://www.vyatta.org/documentation.

Within that document, Chapter 4 Remote Access VPN Overview, section Remote Access VPN configuration, topic Remote Access VPN Deployment Issues, L2TP/IPsec part, Vyatta documented that issue.

Vyatta provide a solution using iptables for Glendale(VC4).
Starting with Hollywood(VC4.1), the issue can be addressed directly from the CLI, a configuration example being presented.

Vyatta kept their word, and both documented and addressed the respective issue.

For doing that, three big Hip Hip Hoorays from me today for Vyatta in the security area.

There are a couple of things concerning any security admin regarding its users like don't do anything stupid and keep your software(like OS, antivirus definitions...) up to date.

For the security admin, these things might be under her/his control if the machines are located on the corporate network.
The admin will make sure tha the OS' are patched on a timely basis, install on every user machine a personal antivirus and a personal firewall. He or she will keep the antivirus definitions up to date.

When these machines leave the corporate network for a period of time, and need access to the corporate network from remote locations, the admin is clueless about their state of health.

Were the latest security patches installed ?
Was the antivirus kept up to date, or even worse, is still the antivirus program enabled on these machines ?
Is the personal firewall still enabled on the users' machines ?
Have those machines become a sort of gateways for the user's home network, thus serving as a potential path to the corporate network for an attacker once the user uses a VPN connection to access the corporate network ?

Unfortunetely, there aren't by default any practical means available with ISA for the security admin to check the remote VPN users machines' health status(when I say practical, I exclude the administrative nightmare VPN Quarantine made available with ISA 2004/2006 by Microsoft, solution which will make most of the people abandoning the idea of using a remote access VPN quarantine with ISA).
NAP is a hot topic right now.
If you search for NAP, you may found out that this will be available on the future version of ISA, called TMG. But TMG is far away at this moment.

Luckily for the ISA admins, an enterprise grade VPN quarantine solution for ISA is available for quite a while now. This solution is called VPN-Q 2006. You can reach it at its vendor site, http://www.winfrasoft.com/. It will work with the VPN protocols available on ISA, PPTP and L2TP/IPsec. And very important, VPN-Q 2006 is a very easy to use and to implement solution.

Read more...

Just for the record:
If you have ever sent to your ISA Server 2004/2006 or attempted to sent through your ISA an IP packet that consists of only an IP header, you may have noticed that your ISA logs do not show anything.
Here is the explanation why:
http://support.microsoft.com/kb/936905

Windows Server 2003 simply drops those packets, without forwarding them to ISA.
These packets do not pass through ISA or if they target one of ISA's IP addresses, there is no reply packet, they are silently dropped, so there is nothing to worry about.
But you'll never know that someone made some "funky" attempts, assuming that you may want to know.

Bellow is the nmap command, just in case you want to test it yourself(-p55 means IP Protocol 55, will set the Protocols field within the IP header, I've entered a random number).
Note that if you use -p6 which means TCP, nmap will send an ACK segment to a random destination port.
Also if you use -p17 which means UDP, nmap will send an UDP packet to a random destinaton port.
And if you use -p255, and the destination host is on the local network, nmap will first send an ARP request for the destination IP address, and if an ARP reply is received, the IP packet that consists of only an IP header will be sent to the specified destination. If you replace the host destination with the entire local network, say 192.168.22.0/24, nmap will first send an ARP request for the every IP address from the specified network range, and for every host that sends an ARP reply, the IP packet that consists of only an IP header will be sent.

Or the hping3 command(--iproto 55 means IP Protocol 55, will set the Protocols field within the IP header):

Such a packet captured with Wireshark:

So, you've tried many combinations in an attempt to configure your Mac OS X L2TP/IPsec VPN clients to use IKE authentication with certificates with your ISA Server 2006, certificates issued for the Mac VPN Clients and ISA by an internal Windows Enterprise CA.

You may have a couple of certificates installed on ISA issued by this CA, so you have troubles identifying which certificate is ISA picking for IKE authentication, if this certificate has the "correct" fields required by the Mac OS X L2TP/IPsec VPN clients' security checks.

Till now this "game" left you fuming.
I've mentioned in the first part of this article about the posibility of using a separate CA to issue certificates just for the Mac OS X L2TP/IPsec VPN clients and ISA, certificates that can be used for IKE authentication.

If you have not gave up, and you are still searching for a solution, one such solution can be to use an OpenSSL CA to issue the needed certificates for IKE authentication.
Your Windows L2TP/IPsec VPN clients will continue to use the same certificates they used before for IKE authentication.
We will use this OpenSSL CA just to issue to ISA a "valid"(from the perspective of the Mac OS X L2TP/IPsec VPN clients) certificate and also to issue certificates for the Mac OS X L2TP/IPsec VPN clients.

I'm using an OpenSSL CA because it can easily issue the "correct" certificate for ISA that will work with Mac OS X L2TP/IPsec VPN clients.
We have seen that it is recommended to have installed on ISA a certificate with no EKU field and with the SAN field containing a DNS Name, a FQDN which the Mac OS X L2TP/IPsec VPN clients will use as their VPN server address.
Since only one certificate will be installed on ISA issued by this CA, you will know for sure what certificate will be used for the IKE authentications between ISA and the Mac OS X L2TP/IPsec VPN clients. No more "games".

Read more...

Using L2TP/IPsec for a VPN site-to-site connection is recommended when both VPN gateways are ISA 2004/2006 Firewalls. This is specified in clear in many docs on Microsoft's web site.

IPsec Tunnel Mode site-to-site VPN connections are used when interoperability with a VPN gateway from another vendor is required. ISA Server 2006 has passed the VPNC Basic Interoperability Test. If you scroll this document, you will find against which VPN gateways ISA Server 2006 was tested.

If you need to create an IPsec Tunnel Mode site-to-site VPN connection with a VPN gateway from another vendor, you may ran into a couple of unsupported settings or scenarios.

Let's point out some of them.

A easy to spot one will be the lack of support for Diffie-Hellman MODP Group 5 (1536-bit). Popular VPN gateways often use this group. ISA Server 2006 can use instead the stronger Diffie-Hellman MODP Group 14.

Read more...

When you are troubleshooting L2TP/IPsec remote access VPN connections using certificates for IKE authentication, a good place to start, you may think, would be the Event Viewer on your ISA Server, particularly the Security Audits.
I would add: maybe. It might be a good idea or not. Depends.

How is that, you may wonder ?

For example you may see that Event ID 541: IKE security association established, Mode: Key Exchange (Main mode) was logged.
So, you would say: IKE MM negotiations went fine, I have an established IKE MM Phase, and now IKE Quick Mode may start.

Wrong. You have an IKE MM Phase established just from ISA's point of view.
That does not imply that the client has also an established IKE MM Phase.

The client will send to ISA its third IKE MM message, an encrypted message, which contains the authentication payload along with the client's certificate.
ISA analyzes this message, everything appears to be fine, and it logs that IKE MM was establised.
After that ISA sends to the client its third IKE MM message, which contains the authentication payload along with ISA's certificate.

The client will take a look at this message. If the client(say it's a Mac OS X L2TP/IPsec VPN client or a Vista L2TP/IPsec VPN client) is configured to perform additional checks on ISA's certificate, it may not accept ISA's certificate, for example the SAN field on the VPN server's certificate does not contain the expected DNS name.

Let's exemplify the above described issue.

I recently wrote something about Mac OS X L2TP/IPsec as VPN clients and ISA as an L2TP/IPsec VPN server:
http://www.carbonwind.net/ISA/MacOSXVPNL2TP/MacOSXVPNL2TP1.htm
There we have seen that the Mac OS X L2TP/IPsec VPN clients perform certain checks on the VPN server's certificate. So a Mac OS X L2TP/IPsec VPN client can serve as a good example for a quick test.

Let's say I'm connecting from a Mac OS X L2TP/IPsec VPN client to an ISA 2006 L2TP/IPsec VPN server, and the VPN connection cannot be established. ISA has installed on it a certificate which contains within the SAN field the DNS Name isabranch.carbonwind.net.
The Mac OS X L2TP/IPsec VPN client is configured to connect to the vpn.carbonwind.net VPN server.

The Event Viewer/Security on ISA will log an Event ID 541: IKE security association established, Mode: Key Exchange (Main mode).

If we look at the Oakley.log on ISA, we can notice that indeed from ISA's point of view the VPN client was successfully authenticated and the IKE MM phase was established. And that ISA is using a certificate with the CN isabranch.carbonwind.net. If we look into the Computer Certificate Store on ISA, we will see that this certificate has within the SAN field the DNS Name isabranch.carbonwind.net.

ISA will send its third IKE MM message to the VPN client.
However, the Mac OS X L2TP/IPsec VPN client sends back a NOTIFY message, informing ISA that its certificate is invalid(ISA does not appear to be aware of the meaning of this message).
The Mac OS X L2TP/IPsec VPN client expected the SAN field from ISA's certificate to contain the DNS Name vpn.carbonwind.net.
So from the Mac OS X L2TP/IPsec VPN client's point of view, IKE MM was not quite established, the authentication of the VPN server failed.

If from the VPN client's point of view the VPN server would be successfully authenticated and the IKE MM would be established, the VPN client may send the first IKE QM message. But in our case, the Mac OS X L2TP/IPsec VPN client sends back an ISAKMP Informational Exchange message instead, so no IKE QM negotiations. The second authentication phase, user authentication(PPP authentication), will start only after IKE QM negotiations will be successfully completed, the L2TP tunnel started and a PPP authentication method selected.

Thus, it must be noted that the Event Viewer is just a quick troubleshooting tool for IKE negotiations, and it may be a little bit confusing. If you want to analyze deeper the IKE negotiations, check the Oakley.log on ISA.

I wrote within this article about the Vista L2TP/IPsec VPN client and the Verify the Name and Usage attributes of the server's certificate checkbox:
http://www.carbonwind.net/ISA/L2TP/l2tp2.htm
As said there, I've noticed that the Vista L2TP/IPsec VPN client checks the EKU field of the VPN server's certificate to see if contains Server authentication. If not, IKE authentication will fail.

If you want to find out more about the Verify the Name and Usage attributes of the server's certificate checkbox, see KB926182.

A couple of days ago, I found this article on the Routing and Remote Access Blog, titled Vista/LH: Security changes for remote access scenarios:
http://blogs.technet.com/rrasblog/archive/2006/11/01/vista-lh-security-changes-for-
remote-access-scenarios.aspx

Within this article, there is a confirmation that indeed the Vista L2TP/IPsec VPN Client checks the EKU field of the VPN server's certificate for Server authentication(1.3.6.1.5.5.7.3.1).

So if you plan to use your ISA Server as a VPN server and on the Vista machines to enable within the L2TP/IPsec VPN Client the Verify the Name and Usage attributes of the server's certificate checkbox, make sure that ISA has installed and will use a proper certificate for IKE authentication(check the Oakley.log on ISA to see what certificate is selected in case you have multiple certificates installed in the Computer Certificate Store, I wrote about this issue here). Otherwise, your Vista machines will be unable to connect using an L2TP/IPsec connection to your VPN server.

A lot of ISA admins have problems with their VPN clients which are not able to resolve single label names.

There is an interesting Microsoft document explaining how single label names are resolved by Windows XP or Vista:
http://download.microsoft.com/download/e/2/0/e2090852-3b7f-40a3-9883-07a427af1560/
DNS-GlobalNames-Zone-Deployment.doc

A simple way to fix that is to have a WINS server.
But that might be another problem, since people may not want to add a WINS server on their network.

Another solution to this is to install the DHCP Relay on ISA and give the VPN clients through DHCP Options the connection-specific DNS Suffix for the VPN adapter.
http://www.isaserver.org/tutorials/2004dhcprelay.html
However there is an issue with the DHCP INFORM packet sent by the VPN Client. It may be dropped by ISA as a spoofed packet.
To fix that, you need to add a registry entry on ISA:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\
FWSRV]"FWS_PNP_IPHELPER_QUITE_PERIOD"=dword:000005dc

Other option is to use the GPO and distribute the DNS Suffix search list.
http://technet2.microsoft.com/windowsserver/en/library/
5fe46cef-db12-4b78-94d2-2a0b62a282711033.mspx?mfr=true
http://support.microsoft.com/kb/294785

I was asked by someone if there is another way to give to the VPN clients the connection-specific DNS suffix for the VPN adapter.
The answer is yes, if you use CMAK profiles.

You can set the DNSSuffix key to the required value under [TCP/IP&EntryName Tunnel] section in the .cms file.
http://technet2.microsoft.com/windowsserver/en/library/
7a5bd80a-56aa-4cb9-b3c4-006886bf33e71033.mspx?mfr=true

You can do that through the CMAK wizard or by manually editing the .cms file and then re-run the CMAK wizard for that profile without making any changes in order that your manually inserted options to be incorporated into the self-extracting executable profile.

Jason Jones has two great articles about how to use CMAK:
http://blog.msfirewall.org.uk/2008/06/using-cmak-to-configure-isa-server-vpn.html
http://blog.msfirewall.org.uk/2008/06/using-cmak-to-configure-isa-server-vpn_10.html

Run as usualy the CMAK wizard to create a new profile.

When you've reached the Ready to Build the Service Profile window, put a checkmark into the Advanced customization checkbox and click Next.

In the Section name drop-down menu select [TCP/IP&EntryName Tunnel], in my case TCP/IP&ISA VPN Tunnel. In the Key name area enter DNSSuffix. And in the Value field type your DNS suffix, in my case, carbonwind.net. Click Apply.

As you can see, the entered values will be saved into the isavpn.cms file. Click Next. And build your cmak profile.

If we take a look at the isavpn.cms file, we can spot the new lines used for our DNS suffix.

As said before, if you already have a CMAK profile and do not want to make the modifications from the wizard, you can manually insert the above lines into your .cms file. And then simply re-run the CMAK wizard without making any modifications in order that the manually modified .cms file to be read and the modifications to be added to the self-extracting executable CMAK profile.

Install the CMAK profile on one of your VPN client machine and connect.

Open cmd.exe and run an ipconfig /all command. You should have a connection-specific DNS suffix on your PPP adapter.

In the first part, we've discussed about using certificate for IKE authentication.
Let's talk now about using pre-shared keys.
Pre-shared keys are a weak authentication method, but they can be useful for testing.
As we have seen, using certificate for IKE authentication can cause some problems.
Having some NAT devices along the path or connecting while we are behind a restrictive firewall can introduce certain issues too.
Pre-shared keys allow us to take a step by step approach in configuring our L2TP/IPsec VPN connections.
For example, we can configure ISA and the Mac L2TP/IPsec VPN clients to use a pre-shared key for IKE authentication, then make a first test while there is no other device(especially a NAT device which might break our connection) between the Macs and ISA. If this test is successful, we know that the second level of authentication (user authentication) is working too. After that we can make a test while the Mac is behind a NAT device(to see if NAT-T is working or if the NAT device is not breaking the NAT-T process).
If this test is successful, we can proceed and configure ISA and the Mac L2TP/IPsec VPN clients to use certificates for IKE authentication, then make a first test while there is no other device(especially a NAT device) between the Macs and ISA. And so on ...

It was a simple process to configure Mac OS X 10.4.8 or Mac OS X 10.4.10 to use pre-shared keys with L2TP/IPsec.
I did not encounter any problems.

Read more...

I'm not a Mac user. However, recently I had the chance to test the Mac OS X 10.4.8 and Mac OS X 10.4.10 as L2TP/IPsec VPN clients with ISA Server 2006 as L2TP/IPsec VPN server. I've decided to put a couple of notes regarding what I have observed.
In this part we will talk about using certificates for IKE authentication.
In a future part, we will talk about using pre-shared keys. Pre-shared keys are a weak authentication method, but they can be useful for testing.
I do not have currently access to a Mac OS X 10.5.x machine. When/if I will have access to such a machine, I will test to see what happens.

I've started configuring and connecting with a Mac OS X 10.4.8 machine. I thought I got it working, but when I attempted to connect with a Mac OS X 10.4.10 machine, I could not. So I needed to make some changes in order to make it work.

I've first prepared ISA.
I'm using an Enteprise CA(Windows 2003 Standard R2 SP2).

Read more...