Windows Insider
Hollow Man
Knowing how and when to use null sessions, those invisible connections, can get you out of—or into—trouble.
- By Bill Boswell
- 01/01/2002
This is my first article as the new columnist for “Windows Insider.”
I hope to continue the great work of Michael Chacon in making this a forum
for demonstrating the practical implementation of Windows features. I
want this to be a place where you can see how other certified professionals
use their knowledge to solve real-world problems.
Systems administration is a fiendishly complex business. There are lots
of gizmos that interact with each other in unexpected ways. For instance,
a colleague recently encountered a situation that shows how a small glitch
in the implementation of a group policy can lead to one of the most infamous
security vulnerabilities in Windows.
MSIng in Action
My associate was configuring software deployment using Windows 2000 group
policies. A software deployment policy consists of a small binary file,
called a group policy template, and a pointer in Active Directory that
links the template to a container such as an OU, domain or site. The deployment
template specifies a UNC path to a shared folder that holds a Microsoft
Installer (.MSI) file that holds the script for installing an application
and, possibly, all the installation files, as well. If a User or Computer
object is in a container linked to the group policy with a software deployment
policy, a client-side extension downloads the template and uses it to
configure the application for local installation. This is classic client/server
technology, and it typically works without a hitch.
The most common way to configure a deployment policy is to use the Assign
option. This installs shortcuts in the Start menu but doesn’t actually
install the application until the user launches it, thus avoiding a huge
logjam during the morning logon. It sometimes happens that the engineer
who designs an .MSI package will decide not to download all the features
in the application during the initial installation. For example, the engineer
might flag the Help file so that it installs only if and when the user
opens Help. This just-in-time feature delivery saves hard drive space
but causes headaches for laptop users who might first touch a feature
while in an airplane, or worse, when connected to the office via a dial-up
line, resulting in a long delay while the files are copied over the slow
modem connection.
Fortunately, there’s a simple way to resolve this. A group policy has
settings for both Computers and Users. If you configure a software deployment
policy to apply to Computer objects rather than User objects, the client
computers will install the application during restart before any users
log on. A happy side-benefit of this approach is that all features in
the .MSI package are installed regardless of any delayed delivery settings
in the .MSI.
My colleague verified this solution using a test server in the production
AD domain, and it worked well. The applications fully installed and the
laptops were ready to take on the road within a few minutes of the initial
boot following imaging. Situation resolved? Not quite, which leads us
to the second part of the story.
Refusing Orders
This particular system contained a two-node Win2K Advanced Server cluster
used for critical file-and-print services. Application deployment is a
significant item, so it made sense to put the .MSI files into a shared
resource on the cluster. Interestingly enough, in this configuration,
the client computers refused to install the policy-based applications.
The laptop would display a message that the deployment packages were installing,
but there was no sign of them once the user logged on.
There were other symptoms. Deployment packages configured to deploy directly
to User objects rather than Computer objects installed just fine. When
the MSI files were moved to a drive on either node of the cluster, the
applications installed flawlessly. By the same token, if the deployment
policy specified a UNC path containing the actual server name of a node
in the cluster rather than the virtual cluster name, the applications
installed without a problem. A cluster presents itself to the network
as a virtual entity distinct from the individual nodes. “We are the Borg,”
says a cluster. Unlike the Borg, each node in the cluster can stand on
its own and present shared resources in its own name. This yields three
possible UNC paths to the same folder on a two-node cluster:
\\cluster_name\share_name
\\server1_name\share_name
\\server2_name\share_name
As it turns out, the explanation for this odd behavior doesn’t involve
any magic cluster features but rather an engineering decision related
to something we use every day—authentication.
Win2K uses Kerberos by default for validating a user’s identity. When
a Win2K user touches a file share on a Win2K server, the server looks
for a Kerberos session ticket in the initial connection request. The client
obtains this ticket from a domain controller. You can see the contents
of the tickets at a client by running a Resource Kit utility called Kerbtray.
This utility installs an icon in the System Tray that you can double-click
to show the tickets and ticket-granting-tickets issued to the current
user.
Local System Account—D'oh!
Individual services running on a Win2K machine must be coded to use and
accept Kerberos credentials. Such a service is said to be Kerberized.
Only a handful of services in Win2K are Kerberized. The list includes
the two services that use the Common Internet File System (CIFS)—LanManServer
and LanManWorkstation—but doesn’t include the Cluster service. This is
because the discrete nodes of the cluster must log onto each other using
local accounts, not AD accounts. For this purpose, the Cluster service
uses the same NTLM authentication protocol used by pre-SP3 Windows NT
4.0. (An upcoming fix will upgrade the Cluster service to NTLMv2.)
This lack of Kerberos support in a cluster sets the stage for the software
deployment problem experienced by my colleague. Recall that the deployment
policy was applied to Computer objects. This means the computer must access
the deployment server hosting the .MSI files. This happens before a user
logs on, so the Local System account must do the connection. But the Local
System account is like Homer Simpson: It’s completely autocratic at home
and a total marshmallow anywhere else, because it has no network security
credentials. To make a network connection, the Local System account has
two choices. It can pretend to be somebody else or it can pretend to be
nobody at all.
In Win2K and XP, Local System can pretend to be somebody else—the computer
account of the local desktop. Computers have accounts in AD and can obtain
network security credentials in the form of Kerberos session tickets.
The Local System account can use Kerberos tickets obtained by the computer
account to make connections to Win2K servers and other XP desktops.
This is why the software deployment policies worked when the .MSI files
were on the test server and the individual nodes of the cluster. Computer
accounts are treated like ordinary users in AD, so they can connect to
any share that permits access to the Authenticated Users group.
He’s a Real Nullwhere Man
The Local System on the desktop can’t use the computer account to do an
NTLM authentication, so it falls back on the second alternative, to pretend
to be nobody at all. It’s possible to connect to a Windows NT or 2000
server without presenting any credentials whatsoever. This is called a
null session connection. A null session is the Hollow Man of Windows networking.
You can’t see it directly, but you can sense its effect all around you.
For example, when you browse My Network Places from a standalone desktop,
you make a null session connection to the Browse Master. When you create
a trust relationship to an external domain, the system uses a null session
to initiate the transaction. If you share a connection to a network printer
on another server, users printing through your machine use null sessions
to connect to the host printer server.
Null sessions appear useful, but unless properly handled, they constitute
a nasty and heavily exploited vulnerability. If you search for “null session”
with your favorite search engine, you’ll find site after site with hacking
tools that take advantage of null sessions. (Be sure to download utilities
only from respected sources. You don’t want to take the chance of introducing
a Trojan or some other nasty piece of code into your system.)
You don’t need any fancy utilities to see how null sessions and Kerberos
transactions work. Here’s a simple way to fool a desktop into giving you
access to the Local System account so you can use it to make network connections.
At a Win2K member desktop in an AD domain, log on with administrator privileges
then open a command prompt. Check the time in the system tray then, from
the command prompt, enter AT