Secure Migration to Windows 2000

As W2K migration focus shifts from if to when, dont lose sight of changing security concerns.


You Can't Detect What You Can't See: Illuminating the Entire Kill Chain

On-Demand Webinar

(Page 1 of 2)

Brett Regan Young

For many of us, the holidays will be spent with sugar plum fairies and the Grinch. For those of us less fortunate, the coming weeks will be spent grappling with Microsoft Corp.'s unique endowment to the enterprise computing world--Windows 2000. Large migrations are getting under way. So for those of us working in large shops, if the question of migration hasn't yet come up, it will.

Microsoft is determined to maintain its command of the corporate server market through a combination of impressive features and coercion tactics (see Joe Mullich's related story, No Rush To Open Windows 2000). These persuasive methods are already familiar to most of us: The folks in Redmond have a history of jettisoning prior versions while promoting the new ones. Because of the support implications of this philosophy, most corporate shops will be well on their way to Win2K by this time next year.

Once you've got the kvetching out of your system, you may find some value in the new and improved Windows OS. Aside from the performance and manageability perks that Microsoft has bundled into this package, the company has addressed many of the significant security weaknesses that plagued Windows NT 4.0. The result of this overhaul is a new set of security features, including a public key infrastructure platform, a transparent file encryption service, and Kerberos authentication.

How Secure Is Secure, Really?

If the new security features of Windows 2000 were a leading motivation for migration, then a good understanding of a significant W2K security limitation would be helpful. Take Windows 2000 and Kerberos authentication.

The cornerstone of Win2K's security architecture is Microsoft's implementation of Kerberos as an authentication protocol. To fully utilize all the features of Kerberos authentication, however, all existing installations of previous versions of Windows need to be upgraded. That means every server and every workstation throughout the enterprise. The source of the problem is a lingering vestige of Microsoft's past--the Windows NT Lanman protocol.

The Lanman NT (LMNT) protocol in Win2K allows backward compatibility with Windows NT, 98, 95, and 3.11 clients. It also manages the authentication of a Windows 2000 workstation to an NT 4 server. Thus, a network running multiple versions of Windows would be open to attack via password compromises, the often-exploited method of authentication in the earlier OSs.

From a hacker's perspective, this allows the weakest link type of vulnerability, where access to a well-protected Windows 2000 server is made trivial if a Windows 98 or NT 4 machine is connected to the server using the LMNT protocol. One fix for this weak link would be for Microsoft to release Kerberos client software for previous versions of Windows. But this solution would be a disincentive for those considering enterprisewide upgrades.

Novell NetWare environments will likewise be relegated to LMNT authentication. In fact, when it comes to Windows 2000's Kerberos interoperability with non-Windows operating systems, the message from Microsoft officials remains confusing. Earlier in 2000, the open-source community reprimanded Microsoft over-proposed enhancements to Kerberos that threatened to reduce interoperability.

Page 1 of 2

1 2
Next Page

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.