Category Archives: Windows

Windows

Zone Information for downloaded files and NTFS Alternate Data streams

Leave a comment

Since Windows XP Service Pack 2 was launched, every time you try to run or open a file that has been downloaded from the Internet, or more correctly, from the Internet Zone in Internet Explorer. You are prompted with the following warning message:

 022207_2051_ZoneInforma1

What this message does, basically, is to warn you that you are opening a file that is downloaded from an un-trusted location. You can see further evidence of this if you view the file’s properties:

 022207_2051_ZoneInforma2

Notice the Unblock button on the lower right. If you select it, the next time you try to open the same file you see no warning. Somehow, by pressing Unblock, you have told Windows that you want to allow this particular file, even if it is from the Internet. But where is this information stored? I searched in all the places I could think of; attributes, DACLs, SACLs, details. What prompted me to do this was that I wanted to unblock several file and was looking for a command line utility to do it. Not even Google knew where this information was stored.

The reason I wanted a command line tool was this. If you download an archive from the Internet and then extract the files in it before you unblock it, all the extracted files are also marked as coming from the Internet and require individual unblocking.

When I attended Tech Ed IT Forum last week in Barcelona I asked Microsoft Security Guru Steve Riley about this, and, not surprisingly, he knew the answer. The information is stored in an NTFS alternated data stream!

NTFS alternate data streams are a little known feature of the NTFS file system, and have been available since Windows NT 3.1. This feature allows you to store data of any kind in an alternate location within a file. When we use files normally we are accessing stream 0. When you open an EXE file or a DOC file you are reading stream 0 of that file. But as I said, you can add several more streams. A while back, ADSs was the cause of a security scare. Someone had read about ADS and found them to be a security risk. What if a malicious user stored a virus or malware in an ADS? The user and all his anti-virus and anti-malware software, would be oblivious! As it turned out, this quickly blew over and now several anti-virus/malware packages scan for the presence of ADSs within files.

So how does this apply to files from the Internet? Consider this example; you have a file you have downloaded from the Internet. In my case it is called daemon408-x86.exe and is the installer for Daemon Tools. When I try to run this file I receive the warning mentioned earlier. Now that I know that this is caused by an alternate data stream I can use a tool to view and delete that stream. There are several tools available, but I chose streams from SysInternals. This is the output from streams for my file:

 022207_2051_ZoneInforma3

As you can see, this file has an ADS called Zone.Identifier:$DATA. To see what it contains we use the more command, which is part of Windows.

 022207_2051_ZoneInforma4

This is the raw data that is stored in the additional stream. Not very much in this case, just two lines of text. But this is what Explorer looks for when you ask to open a file.

To delete this additional stream so that the file opens without warning we again use streams from SysInternals.

 022207_2051_ZoneInforma5

If you want to know more about NTFS Alternate Data Streams, check out these links:

You can download the streams tool from the SysInternals site:

http://www.microsoft.com/technet/sysinternals/Utilities/Streams.mspx

Until next time!

Windows

The Case of the Missing File Transfer Manager

Leave a comment

Everyone downloading from MSDN, the MCT Download Center or any other semi-open Microsoft download site, is familiar with the Microsoft File Transfer Manager application. It is a rather nice utility that is installed on your machine the first time you start a download from one of the sites I mentioned. It supports queuing and resume of downloads. As I said; nice.

 022207_1451_TheCaseofth1

It has, however, a rather nasty habit of disappearing once you close it. This makes it hard to resume your downloads if they did not finish, and to view your download history. The only way (well, not really, but more on that later) to start it again is to visit one of the Microsoft download sites and start a new download. Then it will launch again and you can examine the command line in Process Explorer and find where it is stored so that you can launch it again later without having to start a download. Or not…

I have gone through this exercise many times and I know where the FTM is installed, or at least I used to know, back when I was running Windows XP. Then it was something like c:windowsMicrosoft File Transfer Manager. But now I am running Vista, and it’s not at that location any more. I set out to find it, I mean, how hard could it be?

First I searched the machine for a filename containing trans, using Windows Desktop Search which is integrated into Windows Vista. No matches. Then I tried some variations on the filename; still nothing. So now I started looking in the Program Files and Windows directories trying to find it using empirical observation. Meaning that I manually looked in each folder in those directories. Still nothing. This was getting frustrating so I signed in to MSDN and started a new download. After the FTM started I checked it’s command line in Process Explorer:

 022207_1451_TheCaseofth2

And there it was; in c:windowsDownloaded Program FilesTransferMgr.exe. Success! So now let’s go there and make a shortcut on the desktop so that I have it ready next time I need it. This is how that folder looks in Explorer (with ‘show hidden and system files’ turned on):

 022207_1451_TheCaseofth3

This was getting really frustrating. Switching to my old friend, the command line I got some more info:

 022207_1451_TheCaseofth4

Finally I could see all the files. Now how do you make a shortcut from the command line? That’s right, you can’t (at least I don’t know how). So that left me with trying to view the actual files present in the Downloaded Program Files directory in Explorer, where I could create a shortcut.

A folder’s layout in Windows is controlled by a file called desktop.ini. It is present in almost all directories on a Window system and controls everything from the icon of the folder, it’s name and localized name. You can do some cool stuff with desktop.ini, but that is beyond this post. My guess was that it was the desktop.ini file that was responsible for the limited view I could see in Explorer. So let’s get rid of it.

C:WindowsDownloaded Program Files>del desktop.ini
Access is denied.

OK. So what are the file permissions?

C:WindowsDownloaded Program Files>cacls desktop.ini
C:WindowsDownloaded Program Filesdesktop.ini NT SERVICETrustedInstaller:F
BUILTINAdministrators:R
NT AUTHORITYSYSTEM:R
BUILTINUsers:R

The only account that has Full Control permission to the desktop.ini file is the NT SERVICETrustedInstaller principal. So who is the owner?

subinacl.exe /file “c:windowsDownloaded Program Filesdesktop.ini” /display=owner
+File c:windowsDownloaded Program Filesdesktop.ini
/owner =trustedinstaller

Again, the NT SERVICETrustedInstaller principal.

Note: subinacl is not included in any Windows version and must be downloaded from the Microsoft Download site. It is included in the Windows Server 2003 Resource Kit, but that version does not work.

Note: You must run the above command from an elevated command prompt.

So let’s take ownership of the file, then we can change the permissions and delete it:

subinacl.exe /file “c:windowsDownloaded Program Filesdesktop.ini” /setowner=Morgan
c:windowsDownloaded Program Filesdesktop.ini : simonsenmorgan is the new owner
c:windowsDownloaded Program Filesdesktop.ini : 1 change(s)

And change it’s permissions so that we can delete or rename it:

cacls “c:WindowsDownloaded Program Filesdesktop.ini” /G simonsenmorgan:F /E

Make a backup:

copy desktop.ini c:Usersmorgan.SIMONSENDownloadsdesktop.ini.bak

And finally delete it:

del desktop.ini

Now the view in Explorer is quite different:

 022207_1451_TheCaseofth5

Note: You have to close Explorer if it was open during the desktop.ini manipulation. Otherwise the customizations in desktop.ini are cached and remain in effect.

Now I could finally create a shortcut on my desktop:

 022207_1451_TheCaseofth6

Puh, what an operation!

Now for the real killer. This was all a waste of time! Remember that I said the only way to launch the FTM was to visit a Microsoft download site and start a new download? Well, once the FTM is running you can click on the Options button, and you see this:

022207_1451_TheCaseofth7 

D’oh!

Actually I knew that the option was there. Trying to save time, my first attempt was just to try to locate it in the file system and then launch it and click the option. But then I couldn’t and as I started investigating I discovered some interesting stuff about Windows Vista and that made it all worth while.

By the way, if you are trying this on your own system, you can set the system back to it’s default state with these commands:

copy c:Usersmorgan.SIMONSENDownloadsdesktop.ini.bak .desktop.ini
cacls desktop.ini /R simonsenmorgan /E
subinacl.exe /file “c:windowsDownloaded Program Filesdesktop.ini” /setowner=”NT SERVICEtrustedinstaller”

You, of course, have to replace my paths with your own.

Now for some sleep!

Windows

Logging on through Terminal Services on a Windows Server 2003 Domain Controller

1 Comment
I work extensively with multi-domain forests, usually in a configuration with an empty root domain and several child domains that host users and computers etc. The other day I was trying to log on to a newly added Domain Controller in a child domain. I was going to prepare the domain for Exchange so I was trying to log on with an account that was a member of the Enterprise Admins group in the root domain. This usually works very well, because this group is always a member of the local Administrators group in any child domain. This time however I could not log on and got this error message:
To log on to this remote computer, you must be granted the Allow log on through Terminal Services right. By default, members of the Remote Desktop Users group have this right. If you are not a member of the Remote Desktop Users group or another group that has this right, or if the Remote Desktop Users group does not have this right, you must be granted the right manually.

This, of course, led me to investigate. The first thing I discovered was that this Domain Controller had also been made a Terminal Server. I won’t go into how bad an idea that is here, suffice to say that I do not recommend it. From this fact it followed that someone also probably had changed the default settings of the Allow log on through Terminal Services right in some policy, and that was probably the reason I could not log on. Sure enough. The Default Domain Policy had been changed (again, not a good idea), granting the Allow log on through Terminal Services right to a global group in the domain only. Let’s call that group TSUsers. I also discovered that the same someone had also added the TSUsers group to the Remote Desktop Users group. Normally that should have been enough to allow log on through Terminal Services. Obviously it wasn’t. So I had two problems. First, why could I not log on as a member of the Administrators group when the Default Domain Policy had been changed, and second; why was it not enough to add the TSUsers group to the Remote Desktop Users group to allow them to log on through Terminal Service?
By default, the Allow log on through Terminal Services right is controlled through the Local Computer Policy, the one you can edit with gpedit.msc. The default setting for Windows Server 2003 is to grant this right to the Administrators and Remote Desktop Users local groups. If the server is promoted to a Domain Controller, the Remote Desktop Users group is removed from the Local Computer Policy, leaving only the Administrators group.  So on a Domain Controller it is not enough to be a member of the Remote Desktop Users group to log on through Terminal Services. You must be a member of the Administrators group in the domain. That is probably what confused the person who had set up the server. He had added his domain group (TSUsers) to the Remote Desktop Users group and been unable to log on, since the server was a DC. That answered my second question. To solve this problem he edited the Default Domain Policy and gave the right to his domain group. But in doing so he overrode the Local Computer Policy, which gives members of the Administrators group access. This was what made me unable to log on to the server, and the answer to my first question. Easy!
Interestingly enough the text in the Remote tab on a Domain Controller does not change, even if Remote Desktop Users no longer can log on through Terminal Services. It still says that members of the group has access.
To solve my immediate problem I added the Enterprise Admins group to the Default Domain Policy in the child domain and was able to log on and do my Exchange preparation. This setup is obviously not recommended. A DC should never be a Terminal Server and domain based policies should not be changed in such a way as to lock out administrators.
In researching this post I also found out another interesting thing about Terminal Services in Windows Server 2003. You no longer have to give a user or group both the Log on locally and Allow log on through Terminal Services rights to be able to log on via Terminal Services. This was needed in Windows 2000. In Windows Server 2003 it is handled this way:
  • Log on locally controls logon via the console (not RDP console, but keyboard attached to the server)
  • Allow log on through Terminal Services controls logons via Terminal Services.
You can read more about that in this KB article:
Difference in the user right “Deny log on locally” between Windows 2000 and Windows 2003
http://support.microsoft.com/kb/837954/en-us
Windows

How to remove Event Logs from Event Viewer

1 Comment
The Event Viewer management console has several categories depending on the roles of a server. All systems running Windows have Application, Security and System logs, or categories. These logs are represented by .evt files on disk, typically located in the %SystemRoot%system32config directory.

When a system loses a role, eg. it is demoted from Domain Controller to member server, the logs associated with that role remain in the Event Viewer console on that system. This can be quite annoying, not to mention misleading. Not only is the category retained in Event Viewer, but all the events are there as well.

I will not show you how you can remove these logs. The problem is that the .evt files are locked and cannot be deteled. They are locked by the the Event Log Service which cannot be stopped. The solution is to use Mark Russinovich’s excellent utilities PendMoves and MoveFile. You can find them here:

http://www.sysinternals.com/Utilities/pendmoves.html

Windows often needs to replace a file that is in use. This presents a problem when the process using the file cannot be stopped. To resolve this problem Windows has a spesial API that can tell Session Manager to delete that file, or replace it, on the next reboot. The MoveFile utility does just that. It tells Session Manager where to move, or delete, a file on the next reboot, before the system starts it’s services and applications. This info is stored in the registry key HKLMSystemCurrentControlSetControlSession ManagerPendingFileRenameOperations. You can write to this key using WMI or your own app, but I use Mark’s tool since it is already there.

To get rid of eg. the old File Replication Service Log from a server you would first go into Event Viewer and get the path to the .evt file by selecting properties on the log. Usually you would get C:WINDOWSSystem32configNtFrs.evt

Next, run the following command from the directory where you extracted PendMoves and MoveFile:

MoveFile.exe C:WINDOWSSystem32configNtFrs.evt “”

The “” indicates a NULL destination and is interpreted by Session Manager as a delete operation.

Now you can run PendMoves to get a list of any file move/delete operations scheduled for the next reboot.

But to get completely rid of the log we also will have to remove some setting in the registry, or else the Event Log Service would just recreate the file we deleted. The new file would be empty, of course, but the log would remain in Event Viewer.

Continuing the example with the File Replication Service Log, navigate to the key HKLMSYSTEMCurrentControlSerServicesEventlog
This is the main key for the Event Log Service and it has a subkey for each log that Event Viewer displays. Delete the entire key of the log you want to get rid of.

After the next reboot the logs should be gone from Event Viewer.

Sometimes they are not however. This usually happens because the service that uses the log is still set to Automatic startup. For example; when a DC is demoted to member server, the FRS service is not stopped and disabled. If this is the case the registry key you deleted will be recreated by FRS at startup and a new logfile created. So make sure to check all corresponding services before rebooting.