How Windows PowerShell exposes passwords in clear text

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’m attending a two-day Windows PowerShell course, delivered by my colleague Dave – who I know reads this blog and should really think about starting his own…

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) 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

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

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 640×480 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.

Problems with Microsoft Update

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

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

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

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

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

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.”

Fixing RIS after installing Windows Server 2003 SP2

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

This may be an isolated incident, as I’ve already written about how my Windows Server 2003 SP2 installation appeared to be broken (but was ultimately successful) but ever since SP2 was installed, I’ve been warned about service startup failures and have been unable to PXE boot to RIS.

I haven’t bothered too much – my RIS server is used for XP builds and I rarely need to build XP machines these days but as there are no fully-featured Windows Vista display drivers for my IBM ThinkPad T40, I wanted to rebuild it on XP today.

It turns out that the problem was trivial. RIS has been replaced in Windows Server 2003 SP2 by Windows Deployment Services (WDS). WDS includes something called Windows Deployment Services Legacy – which looks remarkably like RIS to me (it uses WDS binaries to provide RIS functionality). I fired up the Windows Deployment Services Legacy administrative tool and performed a diagnostic check, after which PXE boots resulted in a successful connection to the OSChooser.

Problems installing Windows Server 2003 SP2 using automatic updates

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few days back, I noticed that I was unable to access websites as I had lost connectivity to my DNS server. When I checked the console, I found that my server had failed to install an update… Windows Server 2003 SP2 as it happens, which Windows Software Update Services (WSUS) had pushed out via the automatic updates mechanism. I restarted the machine and waited as it restored the prior configuration, running the software update removal wizard (at least it recovered cleanly), then waited as WSUS tried to push SP2 again. As the repeat update ran interactively, I found the problem – for some reason, towards the end of the installation, the following message was displayed:

Administrative Privileges Required

You must be an administrator of this computer to run this utility.

Log off, and then log on using an administrator account.

(even though I was logged on as the domain Administrator). After clicking OK, the installation continued before reporting:

Automatic Updates

You have successfully updated your computer.

You must restart your computer for the updates to take effect.

I’ve not seen any issues since the restart and the service pack seems to have applied successfully but checking the system event log reveals two entries describing the original problem:

Event Type: Error
Event Source: Windows Update Agent
Event Category: Installation
Event ID: 20
Date: 16/03/2007
Time: 06:00:19
User: N/A
Computer: servername
Description:
Installation Failure: Windows failed to install the following update with error 0x80242007: Windows Server 2003 Service Pack 2 (32-bit x86).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 57 69 6e 33 32 48 52 65 Win32HRe
0008: 73 75 6c 74 3d 30 78 38 sult=0x8
0010: 30 32 34 32 30 30 37 20 0242007
0018: 55 70 64 61 74 65 49 44 UpdateID
0020: 3d 7b 39 34 35 32 35 30 ={945250
0028: 33 43 2d 30 35 42 45 2d 3C-05BE-
0030: 34 41 36 34 2d 39 39 45 4A64-99E
0038: 44 2d 39 41 35 39 46 37 D-9A59F7
0040: 44 36 35 33 39 38 7d 20 D65398}
0048: 52 65 76 69 73 69 6f 6e Revision
0050: 4e 75 6d 62 65 72 3d 31 Number=1
0058: 30 34 20 00 04 .

Event Type: Error
Event Source: NtServicePack
Event Category: None
Event ID: 4374
Date: 17/03/2007
Time: 15:16:38
User: N/A
Computer: servername
Description:
Windows Server 2003 installation failed, leaving Windows Server 2003 partially updated.
The installation of the Service Pack did not complete, and a rollback to the pre-installation state has been initiated. A rollback is a two-step process. Step one is complete; to complete step two, click OK. To be reminded at next login to complete step two, click Cancel. After you complete the rollback, your system will reboot and you may retry the installation of the Service Pack.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

My other Windows servers seem to have updated without any problems; however this illustrates the risk of having WSUS automatically approve updates.

Using RIS as a TFTP server

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier tonight I needed to upgrade the software on an Ethernet switch. Most network administrators will be aware that this generally requires access to a trivial file transfer protocol (TFTP) server and it’s widely believed that to set up TFTP on a Windows server requires third party software. Not so – Microsoft remote installation services (RIS) includes a built-in TFTP daemon and I found that this can be used to serve files to any TFTP client (I’ve written before about using RIS to PXE boot non-Windows images and this was a effectively a variation on the same theme).

All that was required was to copy the binary that I needed to run on my Ethernet switch to the RIS server’s remote installation share (\\servername\RemInst). Once the file had been copied to the RIS server it was simply a case of following the switch upgrade process and supplying the appropriate TFTP server address (i.e. the IP address for the RIS server) and filename.

Problems connecting to Windows Server 2003 shares from within MacOS X

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Although I’ve been connecting to Windows XP clients with no issues, each time I attempted to connect to my Windows Server 2003 (SP1) server from the Finder in MacOS X 10.4.7, I was greeted with the following message:

The alias servername could not be opened because the original item cannot be found.

There was nothing wrong with the alias (it was created automatically by OS X when browsing the network) but, as Drew McLellan outlines in his blog, the issue turns out to be related to digitally-signed SMB traffic, which must be disabled.

Strangely, the option to digitally sign communications (if client agrees) didn’t seem to make any difference, so it really is necessary to disable digitally signed communications (always). Although it would seem logical to make the change via Group Policy, this is a computer setting (so is not applied to a user account) and as Macs are not domain members they are not affected by group policy either (although the policy for the target server could be set at domain level)

Beware that if editing local policies, these are overridden by site and domain-level policies; however in this case, it’s probably best to make the change only on those servers to which access is required from a computer that doesn’t support SMB signing as the need for digitally signed communications is intended to prevent man-in-the-middle attacks from occuring and disabling this represents a security risk. Further details can be found in the Microsoft Windows Server TechCenter.

Removing MOM’s Active Directory management pack helper object

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few months back I had a look at Microsoft Operations Manager (MOM) 2005. Then, a couple of weeks back, I noticed that one of my servers had the Microsoft Operations Manager 2005 Agent installed, as well as the Active Directory management pack helper object. I uninstalled the Microsoft Operations Manager 2005 agent from the Add/Remove programs applet in Control Panel, but when I went to remove the helper object I was greeted with the following error (and the MSI Installer logged event ID 11920 in the application log):

Active Directory Management Pack Helper Object
Service ‘MOM’ (MOM) failed to start. Verify that you have sufficient privileges to start system services.

Retrying the operation produced the same error, so I was forced to cancel, then confirm the cancellation, before finally receiving another error message (and the MSI Installer logged event ID 11725 in the application log):

Add or Remove Programs
Fatal error during installation.

The answer was found on the microsoft.public.mom newsgroup – I needed to reinstall the MOM agent before the AD management pack helper object could be removed but there was a slight complication because I no longer have a MOM server (I deleted my virtual MOM server after finishing my testing). Manual agent installation is possible, but I needed to supply false details for the management group name and management server in order to let the installation take place with a warning that the agent would keep retrying to contact the server (all other settings were left at their defaults).

Once the agent installation was complete, it was a straightforward operation to remove the Active Directory management pack helper object, before uninstalling the MOM agent (successfully indicated by MSI Installer event ID 11724 in the application log).

It’s a simple enough workaround but represents lousy design on the part of the MOM agent/management pack installers – surely any child helper object installations should be identified before a parent agent will allow itself to be uninstalled?