In my previous article in this series on Internet connectivity and security, we went a step further than the initial firewall installation and implemented a client access VPN. We implemented authentication but, due to client requirements, we then had to go above and beyond. The client’s concerns about strong authentication led us toward several potential solutions.
Extra strength authentication
One of the additional parameters designated for securing the VPN was an extra level of authentication. The client company wanted not only the usual domain logon but also a remote form of logon. We could have chosen to use RADIUS (IAS, in Microsoft speak) to authenticate users. In so doing, we could actually create the remote users in a local database on the IAS server, rather than having the IAS server refer to the domain database for user verification. That would provide for the remote logon, and then users would actually log on to the domain during the second part of the connection process—the terminal server session.
Another option that was considered was to perform the remote logon by having users log on locally to the actual VPN server using a specific remote access account. In so doing, they would not be exposing the domain logon process to prying eyes. At worst, exposure would be limited to the VPN system. We experimented with these and several other combinations until we realized that we were looking at things from the wrong angle. We shelved these as secondary options because they didn’t really give the client what they were looking for.
It turns out that the reasoning behind the extra level of authentication stemmed from an underlying issue. The client was concerned about users sharing passwords for remote access. Now that the cat was out of the bag, we began to move in the right direction. We assisted the client in writing a security policy that addressed the issue, but we all agreed that the best manner in which to implement it was at the system level. The bottom line was that we had to authenticate the physical computers gaining access to the VPN. After this initial computer authentication process, the remote PC would be connected to only the actual VPN system. From here, they would need to connect to the terminal server inside the VPN/Firewall perimeter system. To do so, the remote user would run the terminal client and enter the IP address of the internal terminal server. When connecting to this server, they would then be confronted with the actual domain logon. At this point, we had satisfied the security constraints set by the client, at least on paper. Now, how did we implement this model?
Verifying the computer
The overriding concern when considering how to verify the computer identity was whether or not we wanted to deal with the complexity of implementing MS Certificate Services. This service is now provided with Windows 2000. With it, you can generate your own computer-based certificates for verifying user and computer identity. To do so, we would have to create our own root certificate authority (CA) and then a subordinate CA. Then the issue would arise about which servers on which to install it.
Since it’s a good idea to secure the root CA, we decided to install it on a domain controller well inside the network. Some experts recommend taking the root CA offline so that there is no chance of compromise, but we didn’t have the luxury of an extra server. The subordinate CA was installed on the Terminal server. When deciding to use Certificate Services, we had to determine how to use it in a productive manner, yet provide only the features we needed. With the myriad of features and options available with MS Certificate Services, this was no small task.
Eventually, we chose to install the CA as a standalone. This configuration is used for generating certificates to external clients. And, although the certificates were not external to the company, we wanted to treat them as such during the initial connection process. Then we requested and issued certificates for each remote client and the VPN server. Microsoft provides a Web interface for CA servers that allow other systems to request certificates by simply connecting to the CA via browser using the http://ca_server_name/certsrv URL. After installing the certificates, we next had to modify the authentication method at the VPN server. Extensible Authentication Protocol (EAP) facilitates the use of certificates and thus had to be configured. On the VPN system, we had to change the authentication method in the remote access policy that was created by the VPN setup wizard. Under the RRAS console, we simply edited the profile to include EAP and then again in the local system properties (within the Security tab). At that point, we configured our test client to also use EAP under the VPN connection icon’s properties. Then came the moment of truth. We tried to connect and were immediately rejected. After double-checking the details (and Q259880), we made a few adjustments and successfully connected.
Keep in mind that this was not the only way to fulfill the need for Internet access and security. At each juncture in this overall process, we had several options. One option was to use an external CA like VeriSign. In this way, we would have an internal CA, which would refer to an external root CA provider for certificate verification. Then again, we could have chosen to use IAS for RADIUS authentication. But, given the client’s specifications and preexisting constraints, things turned out well as the project evolved.
Looking back over the scope of the project, I would only make a few recommendations. Among these, I highly suggest supplementary documentation, like the Windows 2000 Resource Kit. Unfortunately, the Microsoft Web site is a little thin on specific information regarding custom configurations like these. And the Windows 2000 Help system does not provide the depth needed to effectively complete such a project. Last but not least, plan it carefully. If you specify all of the needs and requirements before you start the implementation phase, it’ll make the process much smoother.