My FAVORITE Win2K Security Features

February 1, 2000 - Chuck Flink

The more things change, the clearer it becomes what was really good in the Good Ole Days!  

When we have a chance to experiment with alternate ways of doing things, sometimes the best is the simple old solutions of the past.  Windows 2000 provides a wonderfully rich opportunity to re-explore the old and the new of OS technology.  When we do, sometimes the answers surprise us. Sometimes we're simply floored by the brilliance of something new.  Often we're floored by the rediscovery of how brilliant those who proceeded us were!  It's not all one or another, but it's almost always worth the trip.  Here's my favorite security features new to Windows NT's latest incarnation:  Windows 2000.

Let's start with letting the Linux / Unix community get their I-told-you-so's out of the way:

All out #1 best new feature:  RunAs command and shift-click option. Ok, ok.  Yes, it's nothing but a glorified su(1M) command allowing a user to Substitute another User identity when launching a command.  I know, you're asking, "Why did it take Microsoft so long to see the light?"  Please let me explain the history and some of the old "new" ways Microsoft and other OS designers tried to get the job done.

In the good old days pre-Windows and pre-Linux, Unix ruled over the era of mini-computers.  From the perspective of the InfoSec gurus of that era, one of the worse architectural sins of Unix was the inclusion of the user identity root.  The "root" user was almighty.  No security controls applied to this user.  The good side of this was that the administrator could always overpower any access controls or other restrictions that got in the way of solving problems with the system.  The bad side was that just about any fool could create a Trojan Horse script and trick a lazy administrator into executing it!  The easiest step was to have the administrator, without his knowledge, create a set-user-id-to-root copy of the command interpreter (sh(1)).  Then whoever executed the copy (i.e. launch a shell based on the privileges inherited from that file) would take on the root (superuser) identity and become able to do anything on the machine.

The history of attacks of this sort (and related flaws and oversights and stupid administrator mistakes) shaped a branch of the Information Security lore that preached against the evils of aggregated privilege and made any OS architect feel like a 3rd grader if he/she dared to copy something like su(1M) or the root in their new designs.  The result in the case of Windows NT was the development of a complex partitioning of privilege into a large number of distinct privileges that can be farmed-out to various individuals and groups based on the tasks they are required to perform:  Administrators, Domain Administrators, Print Operators, Power Users, Users, Guests, etc.  The philosophy behind this design is known in InfoSec circles as "Least Privilege", e.g. you give each user, service, computer, component, etc. no more privilege than it needs to get it's job done.  This can be taken to the extreme of compartmentalization in which Administrators can administer the machine, but cannot execute ordinary user commands or decrypt user data.

There is no doubt that the "weakest link" in many a corporate security plan is the low-paid administrators who enjoy all the privileges of access and control but are treated by management as glorified clerks.  The clear short-term solution is to realize how much you trust and depend upon these people and treat them right!  The long term answer will be compartmentalization based on encrypting file systems and PKI to ensure that nobody is almighty.  This day is far off, in spite of Windows 2000 inclusion of an encrypting file system and extensive Public Key Infrastructure support.  But this is a topic for another day.  It's an important step, but NOT a favorite feature to review here!

After defining all of these itemized privileges and creating all of these various roles to subdivide the powers of the administrator, the Windows NT security architects lost sight of the prize.... or more correctly, exhaustion and deadlines pushed them to accept the expediency of allowing ordinary users to be added to the Administrators group, thus inheriting virtually all privilege.  Though the underpinnings of the security architecture supported the concept of Least Privilege, the product was shipped with it trivially easy for every administrator to configure the system so that he/she had virtually all privileges virtually all of the time!  Yes, guidelines were published reminding every administrator that he/she should create TWO identities for themselves:  one with and one without administrator privilege.  But the reality is that many, many installations of Windows NT run on PCs where the owner of the PC essentially runs as SuperUser 100% of the time!

There was nothing that allowed easy management of the administrator's two identities, forcing her/him to basically have twice as much work in managing his/her environment.  Windows 2000 takes a step back, overcomes the sophomoric fears that damned su(1) with the same broad brush that condemned the SuperUser concept, and implemented RunAs.  The user with administrative responsibilities can now login as him/herself, with ordinary user privileges, and then invoke privilege on an individual command or applet basis by using RunAs and it's Shift-Click GUI instantiation.  Finally we have the low-level privilege compartmentalization reflected at the user operational level.... the administrator can be administrator just long enough without requiring logging off and on again with the associated loss of context, windows, running apps, etc.

How did the Security Gurus of the past come to mislead us in damning su(1M)?  It may be as simple as the confusion of names.  Many, many Unix users thought the "s" and "u" in the name meant Super User, not simply Substitute User.  It was only a door to superuser privilege when the user identity being substituted for the current identity was that of the user 'root'.  Once privileges were subdivided between roles, having the ability to take on a role for only a short time was not a crime, but in fact an important feature.  

What a shame that we let our understanding of commands and principles become so shallow that we waste years with a design that misses the mark!  Hooray that the Windows 2000 designers have corrected this serious oversight!  Now you Linux designers:  learn what Least Privilege is and how to implement it practically!  The technology of encryption and management via a PKI is coming!  IF you want to compete with Windows 2000, learn and grow.  You might very well find that keeping what you have and changing your focus to embedded systems may be a more profitable fit for Linux technology.  But if you intend to challenge Win2K in the corporate enterprise, it's time to learn new lessons!

My #2 best new feature:  Terminal Services, Remote Administration Mode.  Ok, ok.  All you Unix and Linux user can quit laughing.  This is largely nothing more than a re-invention of X-windows with all the bells and whistles necessary to support Microsoft Windows efficiently.  But there are important distinctions that clearly reflect the lessons learned from the past.

In the Windows NT 4.0 Terminal Services add-on, the prior generation of TS, the package was restricted to serving up specific applications for multiple users.  Effectively the NT Server was a specialized application server; users didn't have access to a desktop and shell they way X-windows provides for the Unix/Linux user.  Now, in Windows 2000 Server, the TS server is a standard component and installs with no additional licensing in Remote Administration Mode.  A user can login as an administrator from any Windows 3.x, 9.x, or NT platform, and many Windows CE platforms, and operate as if logged into the console of the Server.  Yes, there are many 3rd party products for Windows that will do this, but never has it been integrated into the system so well.  And check the cautions below!

There are many pages out on the web reviewing this new feature, so I need not cover the whole story.  Microsoft's TechNet site provides a decent demo and feature summary via PowerPoint and video screen captures.  I'm sure there are many more reviews coming, so I'll focus on where this is leading from an InfoSec point of view.

The upside of Windows 2000 Remote Administration is obvious:  no longer is the administrator locked into the computer room.  It is the geographic equivalent of the RunAs command I described above.  Now he can be on his computer logged in with his own identity and logged into the remote server with an administrative identity and context.  This is a very simple operational framework, far simpler than the other two 'new ideas' Microsoft tried to sell us in the previous incarnations of NT.

When Windows NT first appeared, each sensitive subsystem had it's own management applet.  Each of these applets included a "Connect to...." option, usually in the File menu pull-down.  Each applet could control instances of its service running on any computer in the domain.  This was implemented via Remote Procedure Call (RPC) technology and rode the encryption and authentication services available via that technology.  RPC is notoriously troublesome over low-speed networks and generally was a problem for remote administration from anywhere but the closest LANs.  With the introduction of the NT 4.0 Option Packs, we began to see the MMC management console.  This streamlined the concept by providing a common framework for all management applets, replacing the various subsystem applets with 'plug-ins' for this common tool.  But RPC was still the protocol and privilege was still granted via the current user's login, encouraging the bad practice of administrators adding their personal identity to the Administrators group in order to be able to use an applet or MMC plug-in whenever needed.  

Regardless, the MMC model is still a good one.  I especially like the idea of 3rd party vendors building plug-ins to control their routers, switches, firewalls, etc.  The integration of all computers, services and network components under a common tree that can be browsed via MMC is very attractive.  But a good security framework needs to cleanly delineate when the user is operating with privilege and when not.  You cannot do this NT 4.0 with MMC and the applet/plug-in model except by login and logout to/from a privileged user identity.  RunAs in Win2K simplifies this from a privilege point of view, but maintains the dependence on RPC between any PC the user happens to be on and any server to be managed.

Any security analysis is MUCH simpler to perform if the management access to all information is unified through a single Remote Administration stream using protocols that can operate just as effectively and securely over a WAN or dial-up network.  Unlike X-windows, the virtual terminal window is in a client-server relationship that properly reflects the client-side nature of the user relative to the remote server being administered.  X-windows is based on the model that views the user's terminal as a "graphics rendering server" offering access to virtually any remote system; the more natural model in Win2K Remote Administration avoids the security analysis problems this can lead to.  Note:  I have not analyzed RDP 5.0 (Remote Desktop Protocol) to verify how well it integrates with IPsec network security, but certainly the client-server architecture abstracted to the desktop session is now at the right level.  Note:  Windows 2000 includes support for IPsec and IPsec over L2TP in addition to the older PPTP VPN and RAS-based encryption and remote authentication technology.

But this technology doesn't stop with a cheap replacement for your favorite "remote windows" application.  Next week I'll review the security pros and cons of Windows Based Terminals, the Terminal Server remote user monitoring tools, the ability to suspend and resume remote sessions, and the potential for building a true "Compartmented Mode Workstation".... a long sought operational framework, never before compatible with Windows.

Final note:  Don't succumb to shared passwords!  In reading the above history of administrative access, you may be led to do away with all administrative logins but one (e.g. "Administrator") and simply tell all of the administrators the single password for that account.  Rather than each administrator having two logins, one a member of the Administrator group and one not, they could always login as themselves and then use RunAs or Remote Administration to re-login as Administrator whenever privilege is needed.  This is almost, but not quite, good enough.  You must maintain accountability, e.g. which of the many administrators was Administrator when bad thing xyz was done?!  If you've blocked direct login at the console for Administrator (i.e. forcing the user to first login as him/herself) and if you ensure your audit trails are enabled and maintained so you can verify which user identity was responsible for the RunAs or Remote Administration login, then you could consider this simplification.  Until you can assure this, you will still need multiple logins and the corresponding multiple passwords.

Stay tuned for listing of the WORSE Win2K Security Features in another issue!  As always, your comments are very welcome!

Return To The Flink Ink Section