Wednesday, December 2, 2009

Disabling the command prompt does NOT increase security

There is a configuration setting in the Windows operating system called "Disable the command prompt." It "prevents users from running the interactive command prompt, Cmd.exe. This policy also determines whether batch files (.cmd and .bat) can run on the computer. If you enable this policy and the user tries to open a command window, the system displays a message explaining that a policy prevents the action" (copied and pasted from the Microsoft documentation).

This setting is a holdover from Windows 95/98 (which had no security), but it is completely pointless on Windows NT/2000/XP/2003/Vista and later. I can't think of a single good reason to disable the command prompt. Why? Because cmd.exe is a program, not a security boundary.

In the Windows operating system, a security boundary prevents a program from doing something, or prevents data from going somewhere, without authorization. If a user opens a command prompt (i.e., starts the cmd.exe program), the cmd.exe program is running as that user, just like any other program the user runs. The cmd.exe program does not somehow give the user the ability to do things they can't do otherwise. The user's account is the security boundary, not the command prompt.

I have seen many requests for technical help in various forums, and sometimes the answer to a problem involves typing commands at a command prompt. Occasionally, I will see a reply like: "That won't work, because we have disabled the command prompt." My suspicion is that some administrators think that disabling the command prompt somehow increases security, but because this is wrong, the only thing it accomplishes in cases like this is slowing down problem solving processes (thus increasing costs).

[Update 5/13/2015] - These comments also apply to running PowerShell. (I'm not talking about PowerShell's execution policy, which is a separate issue. I am talking about just running powershell.exe or powershell_ise.exe.)

Tuesday, September 1, 2009

Unchain office computers?

Yesterday, I was pointed to an article written by Farhad Manjoo on Slate titled Unchain the Office Computers! Apparently, Mr. Manjoo has never been responsible for maintaining a corporate network. For example, at the beginning of the article, he writes that people are less productive because
...at work they're stymied by the IT department, that class of interoffice Brahmins that decides, ridiculously and capriciously, how people should work.
By this, he seems to mean that IT is "ridiculous" and "capricious" because people some IT departments block people from installing whatever programs they want. This comment, which is itself ridiculous, reveals a large amount of ignorance. For example, on a Windows-based network, doing what Mr. Manjoo suggests requires giving all users Administrator-level control of their computers. Microsoft's official documentation says this is a bad idea and gives the reasons why. I can vouch for this with personal experience: I used to work in a large networked environment back in the Windows NT 4.0 days (1998-2000) where everyone had Administrator access, and the help desk team I worked with spent most of our day fixing user mistakes that would have been prevented if the users didn't have Administrator access. I fail to see how this will somehow increase productivity. I would argue that, in most cases, there will be a net productivity loss, particularly with unskilled users.

Mr. Manjoo's second mistake is in confusing the above issue (blocking program installation) with blocking Internet access. These are two separate issues for an organization, and should be addressed as such. He complains that all IT restrictions are arbitrary, but sometimes there's no nefarious intent by IT to prevent people from doing something--for example, suppose IT installs Internet monitoring software, but the monitoring software's default settings are too restrictive. Yes, this is a mistake IT should rectify, but my point is that not all Internet access blockages are intentional. In addition, sometimes it's simply user error. For example, I have heard complaints that "IT is blocking my web site" when in fact the user was typing an invalid web address.

My advice to Mr. Manjoo is not to write about an IT topic until he is properly informed about it. I wonder if he took the time to interview IT managers to find out the reasons for his complaints? (My guess is that he probably didn't.) Writing an uninformed article that confuses two broad issues (blocking program installation and blocking web sites) doesn't do anyone any favors and has the effect of unfairly casting IT in a bad light.

Tuesday, June 2, 2009

Virtual Iron

Virtual Iron (www.virtualiron.com) is a most impressive piece of virtualization software. It's very functional, and it's far less expensive than VMWare if it suits your needs. I recommend purchasing the web-based training as well.

As an added bonus, Virtual Iron includes a fancy software product called "Platespin Portability Suite" (now owned by Novell) that can convert a physical machine into a virtual machine (aka a "P2V conversion"). I performed a P2V conversion on a production server yesterday, and the Platespin software worked nearly flawlessly. The only thing I noticed that did not survive the conversion was my NTFS quota settings on the server's second volume, but that is a minor quibble.

All in all, I am very pleased with Virtual Iron and Platespin Portability Suite in helping my company transition from a physical to a virtual server infrastructure with a minimum of headache.

Now that Virtual Iron has been purchased by Oracle (as of May 13, 2009), it will be interesting to see what effects this has on the Virtual Iron product and pricing. I hope Oracle will continue to enhance the Virtual Iron product without raising its licensing and support pricing. If they increase the costs too much, they risk losing the customers on which Virtual Iron built their business.