\[Editor's Note: Do you have something to share with other readers who visit Windows NT Magazine online? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (300 to 700 words) to [email protected] along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100. Reader to Reader submissions are the reader's opinion and do not necessarily represent the views of Windows NT Magazine.\]
Can you put PPTP on a BDC? I don't recommend it. Despite what you might have read about needing PPTP on a BDC for domain authentication, you can easily put PPTP on a member server and have it pass-through authenticate to a domain as a RAS member server does. In fact, I imagine that this is the preferred configuration for security reasons alone. Using "Access this computer over the network" in User Rights, I have disabled all network-to-local SAM communication on our server, so the PPTP server can only route users from the Internet to the domain. Moreover, the local administrative account doesn't have dial-in permissions, and I have renamed the administrator account. After putting PPTP filtering on the Internet network card and the latest service pack on the server and client, I have effectively locked down the member server. For tighter domain security, you can disable dial-in permissions for the primary administrative account, the domain administrators, and for all other critical domain accounts. Give dial-in permissions only to those that need it and require strong passwords for the tightest security possible.
That said, our PPTP server is perhaps the most bulletproof, worry-free machine in our company. I just checked with the Srvinfo tool, which you can get from the Microsoft Windows NT Server 4.0 Resource Kit, and we haven't rebooted the server in 131 days! It's a rock solid, cost-effective alternative to expensive nailed-down connections. It works with modems, DSL, ISDN, and cable modems. The faster the better. Whenever users complain about connectivity problems, it's invariably overloaded ISP congestion, overlooked NT Workstation service packs, or low bandwidth.
Here's my top 10 checklist for installing PPTP on a member server.
- Don't use DHCP without a good reason, use a static pool instead. Have the static pool allocate an IP address from the network on the LAN-side network adapter card of the PPTP server. Make sure this allocation range does not overlap with other addresses on the LAN-side network. Also, depending upon your IP scheme, you may need to ensure that roving laptop clients release their home IP address by using hardware profiles.
- Statically list the WINS server on the LAN-side network adapter card.
- Disable the default gateway on the LAN-side network adapter card.
- Install the bare minimum you need to get the machine routing, test the routing thoroughly, and only then install PPTP.
- Stay away from routing protocols such as Routing Information Protocol (RIP) if you don't need them (and odds are you don't). Use static routes instead. Keep all the static routes in a batch file for easy reference and/or reapplication.
- To ease configuration and support, configure the PPTP LAN-side network adapter card on the same home network with the server farm and domain controller rather than building additional networks to needlessly isolate the PPTP server. Doing so will give your organization not only top performance, but more freedom since clients can surf the Web and access the home network simultaneously if they clear the "Use default gateway on remote network" box.
- If possible, don't put the PPTP server behind a firewall. If you enable PPTP filtering, putting your PPTP server behind a firewall can be overkill if you don't operate in a high-security environment. Moreover, employing a firewall can increase deployment time and extend support time because of the additional complexity.
- Size the VPNs appropriately. If you have only 10 virtual users, don't enable 100 VPNs. On the other hand, if you know you have 10 virtual users, do not configure 5 VPNs since 5 people will not be able to connect. Of course, you may have 500 laptop potential VPNs, but never more than 20 ever connect at one time. Normally, you need 1 VPN for each "nailed-down" virtual user. As far as floating VPN laptop users, that all depends upon how often they connect. My recommendation is to double what you think your top load may be. For hundreds of users using nail-down VPNs, then you are potentially looking at multiple NT 4.0 PPTP machines. Third party hardware VPNs should at least be evaluated at this point so that the best solution for your environment is made. For small shops installing new VPNs, I don't think third-party VPNs make sense.
- Don't rule out RAS with PPTP for small deployments. Evaluate both RAS with PPTP and RRAS and make the best choice for your environment. Keep in mind that with RAS and PPTP, you have the option of monitoring PPTP users from anywhere in your domain using the Remote Access Admin tool you can find on any generic NT Workstation or NT Server. (Of course, Windows 2000 has some exciting features—but that would fill up another article)!
- Keep it simple and keep checking Technet.
