Mark's Windows Server Blog

Snippets of Windows Server information from Mark Wilson

August 2007 - Posts

How Windows PowerShell exposes passwords in clear text

I've written before about Windows PowerShell (twice) and I think it's a great product, but it is a version 1.0 product and as such it has some faults. One (which I was horrified to discover today during a PowerShell fundamentals course) is that this product, which is intended to be secure by default (for a number of good reasons) has the ability to store user credentials in clear text!

All it takes is two lines of PowerShell script:

$cred=get-credential username

the user wil then be prompted for their password using a standard Windows authentication dialog)

$cred.getnetworkcredential()

(the username, password and domain will be displayed in clear text)

Some people ask what's wrong with this? After all there are legitimate reasons for needing to use credentials in this manner. That may be so but one of the fundamental principles of Windows security is that passwords are never stored in clear-text - only as a hashed value - clearly this breaks that model. Those who think there is nothing wrong with this argue that the credentials are then only used by the user that entered them in the first place. Even so, I'm sure this method could easily be used as part of a phishing attempt using a fake (or altered) script (digitally signing scripts may be the default configuration but many organisations will disable this, just as they do with signed device drivers and many othe security features).

After searching Microsoft Connect and being surprised that I couldn't find any previous feedback on this I've raised the issue as a bug but expect to see it closed as "Resolved - by design" within a few days. If it really is by design, then I don't feel that it's a particularly smart design decision - especially as security is tauted as one of the key reasons to move from VBscript to PowerShell.

How not to upgrade from Windows Server 2003 to Windows Server 2003 R2

I just upgraded a server from Windows Server 2003 (with SP2 installed) to Windows Server 2003 R2 (SP2 slipstreamed).

It wasn't exactly smooth, because I didn't RTFM... (it's my home server, it's Saturday afternoon, it should have been trivial and I don't have a lot of time to spend planning this... a perfect demonstration of the need for proper planning that I stress to my customers). If you want to avoid my cowboy IT guy approach (i.e. insert disk 1 and upgrade from running copy of Windows - what could possibly go wrong?), check out Microsoft knowledge base article 912309 before starting the job (I didn't).

Because I didn't do it properly, I had some issues but I imagine there are plenty of others who will try what I did and may now be googling to get out of a few holes. This is what I did - your problems may differ depending on your configuration:

  • When my screen reverted to 4 bit 640x480 colour (but Device Manager said my display adapter was working fine), I ignored the problem. After a reboot, I was back to my usual display properties.
  • My machine (which is a domain controller) complained that it couldn't install the R2 components until I had updated the Active Directory schema. I followed the instructions (run opticaldrive:\cmpnents\r2\adprep\adprep.exe /forestprep) and then restarted R2 setup with opticaldrive:\r2auto.exe (I could also have used opticaldrive:\cmpnents\r2\setup2.exe).
  • Changing directory permissions (that's what adprep.exe did) will break certain applications - in my case WSUS and Virtual Server (i.e. those apps that rely on IIS). I'm still working on that issue and will blog something when (if) I fix it.
  • The upgrade also wiped out at least one of the configuration changes that I made in the registry - in this case enabling IP forwarding.
A few commands to get started with Windows Server Core
Scotty wrote:

Mark mailed me last night to ask about my crib sheet for Core Server but as it was Friday evening was taking a rest from the digital world. A hour and a half later he mailed me back to say he had found all he needed.

Now this was from the mail Mark's first real go in anger at installing and configuring Core Server but we have to remember he is an great Windows professional and old enough to have used command lines for a significant proportion of his life with computers.

I'm honoured that Scotty refers to me as a professional but somewhat concerned at the same time that my age (I'm only 35!) is linked with command line usage. Actually, I think it's got more to do with geekiness and although I can't confess to being a Linux/Unix expert, I do love diving into a command shell. I guess what Scotty is saying is that I'm old enough to have cut my teeth in the computing world before GUIs were the norm - and he's right.

Anyway, back to Server Core. I love it. I hate it. No, I love it. Well, I love the idea and I'm sure I will love using the product but, because it's not yet finished, the administration of a Server Core box can be a chore. Consequently, here's my checklist of tasks from when I needed to get a Server Core box up and running last Friday (based on the June CTP build).

  1. Enable remote desktop (from a Windows Vista client):
    cscript %windir%\system32\SCRegEdit.wsf /ar 0
  2. Change the machine name:
    netdom renamecomputer %computername% /newname:newcomputername
  3. Set the IP address for the primary NIC:
    netsh interface ipv4 set address "Local Area Connection" ipaddress subnetmask gatewayipaddress
  4. Set the DNS server addresses:
    netsh interface ipv4 add dns "Local Area Connection" ipaddress [index=indexnumber]
  5. Disable the firewall (at least until everything is working): netsh firewall set opmode disable
  6. Join a domain:
    netdom join %computername% /domain:domainname /userd:domainname\username /passwordd:*
  7. Restart the server: shutdown -r
  8. Change the drive letter allocation for an existing disk (e.g. the CD-ROM drive):
    diskpart select volume volumenumber assign letter=driveletter
  9. Format additional disks (in my case, these had been partitioned during setup but additional diskpart.exe commands could be used):
    diskpart select disk disknumber select partition partitionnumber format fs=ntfs label="volumelable" quiet
  10. Label a disk (e.g. the system disk):
    label driveletter: "volumelable"
  11. Add a domain user to a local group (note that there are some serious restrictions around this - Microsoft knowledge base article 324639 has more details):
    net localgroup groupname /add domainname\username
This has just scraped the surface with a few commands that I needed - it would have taken me a lot longer to write this post without these excellent resources: Other links that may be useful include the Windows command line reference and my own post on using netsh to set multiple DNS server addresses.
Problems with Microsoft Update

Over the last few days, I've been having problems connecting to Microsoft Update from a newly built Windows Server 2003 R2 server.  Whilst searching for updates, it's was hanging (green progress bar pulsing across the screen) before eventually reporting:

[Error number: 0x80244023]

The website has encountered a problem and cannot display the page you are trying to view.

The options provided below might help you solve the problem.

For self-help options:

Frequently Asked Questions
Find Solutions
Windows Update Newsgroup

For assisted support options:

Microsoft Online Assisted Support (no-cost for Windows Update issues)

Sadly, Microsoft's Online Assisted Support didn't do much assisting - it only pointed me back to the knowledge base, newsgroups, or paid incident support but the problem did go away all by itself (yes, really)!

In the meantime, I'd asked for help on the Microsoft Windows Update discussion group and a really helpful MVP called TaurArian replied pointing me in the direction of the MSDN reference for Windows Update agent networking error codes. Useful stuff - and it turns out that 80244023 is WU_E_PT_HTTP_STATUS_GATEWAY_TIMEOUT - i.e. proxy server problems (and probably the reason why the problem seemed to cure itself).

Avoiding Windows Server 2003 R2 product activation after using non-VLK media

Last month I wrote about how it's possible to upgrade a retail copy of Windows Vista to an Enterprise version and it turns out that this is also possible with other versions of Windows.

Last week I needed to build a new server with Windows Server 2003 R2 and my colleague who was supplying the media only brought 32-bit CDs with him (with 8GB of RAM for this server to run multiple virtual machines, it makes sense to use a 64-bit operating system). I spent most of the day downloading 64-bit CD images from various file shares around the company (in theory, because we'd bought the appropriate licenses, it shouldn't matter what media we used) but when the volume licensing key (VLK) that I'd been given didn't work we realised that the disc image we were using was an MSDN version. After supplying a product key that did work and going through all the hassle of getting the server added to the corporate domain, Windows notified me that I had 55 days left to activate the product, so I finished installing the applications today and then "upgraded" using the correct volume license media and key, removing the requirement for product activation.

Another point that's worth noting (thanks to Daniel Petri for this tip) is that the .IMG files that Microsoft provided in the "ISO only" download appear to be just ISO 9660 (.ISO) files with a different file extension. Either way, the cdburn.exe resource kit tool was able to write them on my Windows Vista PC (although it did report an error when trying to eject the CD).

Tab completion in Windows

Many people will be familiar with the command line tab completion functionality that can be used to complete folder and filenames in recent versions of Windows, but what I wasn't aware of (until I just used it, following some instructions from Microsoft in a hands-on lab training manual) was that wildcards like *.reg <tab> can be used to tab-complete filenames. This technique can even be used as arguments to a longer command, e.g. notepad *.reg <tab>.

Dustin L makes a good point in his comment on the Lifehacker article that discusses command line tab completion - Unix admins will already be familiar with the concept but there are a couple of differences between the Windows and Unix/Linux CLI tab completion implementations:

  • "In the Windows command line, if there is more than one match for what you've typed, successive presses will cycle through all of the matches rather than just display a list of the matches.
  • Windows will not complete commands, only files and directories."