Windows Administrators’ Top Three Wishes

What Microsoft networks still can't do

I've been working with the beta versions of the next incarnation of Microsoft’s server product—Windows .NET Server (Win.NET Server) 2003—and I'm anxiously awaiting its final release. Win.NET Server will be a worthwhile upgrade for many, but it still leaves some things to desire. Over the years, I've heard thousands of network administrators express the same basic wish time and time again: "If only NT (or Windows 2000 or .NET Server) could…"

Now and then, a new version of Microsoft’s server OS grants one or two among the myriad variations of that basic wish, but many remain outstanding. In keeping with standard wish tradition, here are the three specific wishes I hear most often.

Wish 1: Hide objects that users can’t access.
Let’s say I have a share, \\srv1\users, that contains home directories. For example, Jack has a home directory in \\srv1\users\jack and Sue has one in \\srv1\users\sue. NTFS permissions keep Jack from looking in Sue's home directory and vice versa. But although Sue can’t look in Jack's home directory, she can still see that it exists, and that fact concerns some administrators. If Sue can't see that Jack has a home directory, then she’ll be less likely to, well, hack Jack.

Many network administrators have asked me how they can take folder security a step further and make every user's home directory completely invisible to other users. For example, if Sue executed a "dir \\srv1\users" command, then she would see only her directory. Win.NET Server doesn’t provide a way to restrict users from seeing other users’ directories, but it ought to. It’s harder to hack what you can’t see. Win.NET Server needs a "make invisible to anyone who is denied access" permission on files, directories, and other objects.

Wish 2: Disconnect users from the network with one click.
Getting rid of people is just too difficult nowadays. In 1973, when I first started working with computers, networks were mainly centralized affairs—dumb terminals hung from mainframes and minis. When a company fired someone, an administrator could quickly and simply delete or disable the former employee's user account. With a few more keystrokes, the administrator could kick the employee off the system.

Modern networks are more decentralized. You can still quickly and simply disable or delete someone's account, but breaking a user’s connection with the network isn’t so easy because you no longer have a connection—you have connections. Most users think that they're logged on only to the domain, but in fact we are typically logged on to several servers and services. For example, at the moment I have active logons to two file servers, a database server, and an email server. To kick me off the network, an administrator would need to know which servers and services I’m connected to, then break those connections. On all but the smallest networks, discovering and breaking those connections isn’t easy. Microsoft needs to add a Throw the Bum Out Wizard to its network OS.

Now, I suppose you could break a user’s connections on an up-to-date network if you restricted all logons to Kerberos and expired all Kerberos tickets every 3 minutes or so. In that case, every server that a user accesses would need to reauthenticate that user instead of every 10 hours, Active Directory’s (AD’s) default interval. As soon as you disabled a user's account, the next reauthentication would fail. But this approach wouldn't be practical because all this reauthentication traffic would overwork the network. On second thought, don’t reduce your Kerberos tickets' lifetimes to a few minutes in the hope of getting this second wish—the effect on your network would be quite negative. I think we need that wizard.

Wish 3: Limit simultaneous logins.
Single concurrent logon has never struck me as a life-and-death matter, but administrators frequently ask about it. Many folks learned about networking in the Novell world, in which I'm told you can easily restrict a user to being logged on to only one machine at a time. As with disconnecting users, the decentralized nature of Microsoft OSs exacts a price: You can't tell a user, "You can't log on to any more workstations until you log off the one that you're currently logged on to."

You can use a workaround—a Resource Kit tool that enforces one logon to a customer— but it's a mite cumbersome and requires getting a SQL Server database up and running to make it work. It would be nice if the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in let you simply check a box on a user's account to enable or disable simultaneous logons.

Will Microsoft grant our wishes? In fairness to Microsoft, let me say that doing so might take some time. Each of these three requests appears to be quite reasonable, even simple. (This situation is akin to saying, "Hey, we'll make the tax system simple; we'll just create this flat tax, see …") But implementing any of my suggested solutions would be difficult. To grant the first wish, Microsoft would have to uproot some fairly basic notions about its OS security. To grant the second and third wishes, the company would have to extend the security changes further and add new sorts of token and ticket auditing and tracking. Making any of these changes would be an extensive undertaking. So we might be wishing for a bit longer.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.