Category Archives: 6393

Don’t fire people until after you wipe their phones

A very commonly required feature for mobile access to email is remote wipe – the ability to reach out and wipe all corporate data off a mobile device. Exchange ActiveSync supports this feature and has for several versions now. You, as the Exchange or Security administrator can issue a remote wipe command to a compliant device, or the user can do it themselves through Exchange, and the next time the user connects the device will be wiped.

There are two major flaws in that design. One is the well understood "the next time the user connects" part: you cannot reach out to the device and immediately wipe it. The devices do support receiving remote commands through SMS, but for some reason there is no function in Exchange to use that feature to somehow, securely, trigger a remote wipe.

It turns out, however, that there is another, possibly even larger, flaw in the implementation of remote wiping in Exchange ActiveSync. Here is the work flow:

  1. Device connects to Exchange Server
  2. Device transmits DeviceID
  3. Exchange server asks for authentication
  4. Device authenticates
  5. Exchange server checks if a remote wipe command has been issued for the device

Spot the flaw yet? Consider this scenario

  1. Bob failed to sufficiently internalize the sexual harassment training and racks up enough points to get fired
  2. Bob is walked to the door with his shiny personal Windows Phone 7 Smartphone or whatever in his pocket
  3. IT Department is notified that Bob has been terminated and disables/deletes his account
  4. IT Department, following the security policy, issues a remote wipe command to Bob's phone

Pop quiz: What happens to all the company confidential data on Bob's device?

Answer: Nothing! It will stay there for as long as Bob decides it should. Go back and look at the connection workflow again. The Exchange server will only send the remote wipe command to Bob's device after Bob has already authenticated. The IT Department did the absolutely logical thing and disabled Bob's account. Therefore, he will never successfully authenticate again. The way remote wipe is implemented in Exchange ActiveSync means we just lost the ability to wipe our data off Bob's mobile phone.

The alleged solution to this is that you should reverse steps 3 and 4 in your firing process: leave Bob's account active until his device gets wiped. If that makes you just a little queasy you are not alone. In my opinion, this is a major feature miss. Remote wipe in Exchange ActiveSync is only useful when a user loses his or her device, and even then, it is lacking since you cannot reach out to the device and wipe it. Remote wipe in Exchange ActiveSync is utterly useless when people are terminated from their emoloyer.

How Delegation Privileges Are Represented In Active Directory

One of the last areas where more tool support is needed is in monitoring the various attributes in Active Directory (AD). Recently I got curious about the delegation flags, and, more to the point, how to tell which accounts have been trusted for delegation. This could be of great import if, for instance, you have to produce reports of privileged accounts.

KB 305144 gives a certain amount of detail about how delegation rights are presented in Active Directory. However, it is unclear from that article how to discover accounts trusted for full delegation, as opposed to those trusted only for constrained delegation; and the various flags with "DELEGATION" in them are not as clearly explained as I would like. Nor was I able to glean any insight into this from the various security guides and recommendations for Windows. I asked around, and got great answers from Ken Schaefer. By spinning up a Windows Server 2003 Domain Controller in Amazon EC2 and running a few tests, I was able to verify that Ken was indeed correct.

Delegation rights are represented in the userAccountControl flag on the account object in AD, whether a user or a computer account. There are a couple of different flags involved, however. Here are the values set in various circumstances:

For a computer account, the default userAccountControl flag value is 0x1020, which is equivalent to the WORKSTATION_TRUST_ACCOUNT & PASSWD_NOTREQD values being set. A user account is set to 0x200 (NORMAL_ACCOUNT) by default.

When you enable full delegation, 0x80000, or TRUSTED_FOR_DELEGATION, gets ANDed to the userAccountControl flag. This is irrespective of domain functional level. In other words, in a Windows 2000 compatible domain, checking the "Trusted for delegation" box; and, in higher functional levels, checking "Trust this computer for delegation to any service" using the "Kerberos Only" setting, both result in the same flag being set. The same flag is set on user accounts when you check the "Account is trusted for delegation" checkbox.

In a Windows Server 2003 or higher functional level domain you gain the ability to trust an account for delegation only to specific services: constrained delegation. If you configure constrained delegation using Kerberos only, the userAccountControl value is not changed at all. The account simply gets a list of services it can delegate to in the msDS-AllowedToDelegateTo flag.

However, if you configure constrained delegation using any protocol, the userAccountControl value gets ANDed with 0x1000000, or TRUSTED_TO_AUTH_FOR_DELEGATION.

There is also a flag in userAccountControl called NOT_DELEGATED. This flag is set when you check the box "Account is sensitive and cannot be delegated."

This tie-back to the graphical user interface, as well as explanation of the various flags, should help an auditor construct a query that lists all accounts trusted for delegation in an arbitrary domain. Obviously, any account with TRUSTED_FOR_DELEGATION set should be considered extremely sensitive; as sensitive as a Domain Controller or Enterprise Admin account. An account with TRUSTED_TO_AUTH_FOR_DELEGATION set is probably less sensitive, depending on which specific services it can connect to, but still quite sensitive as it can use other protocols than Kerberos. Finally, and least sensitive of those accounts trusted for some form of delegation, are those that are only permitted to delegate to specific services using Kerberos.

A better, more reliable, work-around for the Microsoft Video Control Vulnerability

For the past few days I've been following the Microsoft Video Control Vulnerability with interest. Basically, it's another vulnerable ActiveX control that needs killbitted. Last night, Microsoft posted a work-around which involves using a Group Policy ADM template (ADM is the template format that was deprecated in Vista and Windows Server 2008). Unfortunately, the template tattoos the registry, which is not really recommended.

I contemplated for a while writing a work-around for this issue, but then remembered that I actually did; almost three years ago. The workaround I wrote then, for another ActiveX vulnerability will not tattoo the registry, and will be much simpler to deploy with an Enterprise Management System. Just take the CLSIDs from the advisory (there are 45 of them) and run my script that many times with the -k switch. If you wish to revert the change, run the same script with the -r switch.

You need to manually undo your MS08-078 mitigations

Normal
0

false
false
false

EN-US
X-NONE
X-NONE

MicrosoftInternetExplorer4

<!–
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-alt:"Calisto MT";
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:-1610611985 1107304683 0 0 159 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-alt:"Times New Roman";
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-1610611985 1073750139 0 0 159 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-size:10.0pt;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
–>

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}

Just as an FYI, for those of you that used Microsoft's recommended mitigations for MS08-078. If you unregistered the
MSXML Island object you need to manually re-create
the registry entries after you install the patch to restore the functionality.
The patch does not re-create the registry entries. Unfortunately, it appears
Microsoft removed the actual registry entries from the bulletin and removed the
work-around information from the advisory altogether, so unless you created a
backup copy, you will need to look at an untouched system to find out what the
registry entry was.

 

Or, you can just copy this into a text file called
“WhyDidTheyRemoveTheInformationINeed.reg” and double-click it:

 

Windows Registry Editor Version 5.00

 

[HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}]

@="MsxmlIsland"

 

[HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}\InProcServer32]

"ThreadingModel"="Apartment"

@=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,\

  00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,73,00,\

  78,00,6d,00,6c,00,33,00,2e,00,64,00,6c,00,6c,00,00,00

 

[HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}\TypeLib]

@="{D63E0CE2-A0A2-11D0-9C02-00C04FC99C8E}"

XP Antivirus in the News

Several helpful people just pointed me to some articles on XP Antivirus and its various variants. In case you do not remember, XP Antivirus was the subject of an article I wrote for The Register a few months back.

It turns out that the scammers got hacked, and the hacker posted some internal accounting details on the web. As suspected, this is a sophisticated business making millions of dollars. It even appears to have an affiliate program.

In case you have not seen the articles yet, here are a few:

http://www.iht.com/articles/2008/10/30/technology/virus.php
http://www.smh.com.au/news/technology/security/russian-scammers-cash-in-on-popup-menace/2008/11/04/1225560814202.html
http://www.scmagazineuk.com/Hacker-reveals-Russian-software-company-behind-anti-virus-scam/article/120152/

Thanks to Marc Michault, Phillippe Jan, and Jason Grubè for all pointing me to articles on this topic.

Today’s forecast for O’Hare: Lots of Vulnerable Computers

Olliver Sommer, a German Small Business Server MVP, flew home from the Microsoft MVP Summit via O'Hare Airport in Chicago. While there, he spotted this wonderful piece of advice for how to configure your computer to use the airport wireless network.

The document is meant well, but lacks a bit in the execution. It recommends that you disable exceptions in Windows Firewall because doing so stops attacks through Windows Messenger while on the wireless network. Of course, you would only get attacked through Messenger if you actually accept unsolicited requests from people.

The document then goes on to show how to disable the exceptions. It even has a screenshot; which would work far better if the screenshot showed the exceptions disabled. Instead, the screenshot shows the firewall turned off entirely. One has to wonder how many people followed the advice in the picture as opposed to the text.

Then comes the piece de resistance. The document recommends you disable Simple File Sharing. Not only does this presume that you are using Windows XP Pro, as Windows XP Home does not permit you to turn off Simple File Sharing. Simple File Sharing, as it turns out, is partially a user interface feature that governs which sharing user interface you see. However, there is an internal feature as well. in fact, Simple File Sharing is essentially the Force Guest feature. If Force Guest is turned on all users connecting from the network connect as Guest. In other words, by disabling Force Guest, you would enable remote users to connect using as an authenticated user, potentially even an administrator. Force Guest ensures that the only thing a remote user can do is read, and write if you have permitted that, the files you have made available to network users. Turn off Force Guest and a user that guesses the password of your administrative account can take over your computer.

In other words, the guidance that O'Hare Airport is publishing has you disable the firewall and enable traditional file sharing so anyone can start guessing passwords against your computer. One wonders if this is perchance some new Transportation Security Administration (TSA) inspection scheme to investigate what is on your laptop?

What I Learned from Attending the Windows Launch Event Today

Today I attended the Microsoft 2008 server wave launch event in Seattle. In the process I learned a number of things:

  1. The launch event apparently does not need to coincide with actually launching anything. Server 2008 launched a couple of months ago. Visual Studio 2008 launched in November 2007, and SQL Server 2008, the third part of the tri-fecta that comprised the launch, will not actually launch until the third quarter this year.
  2. The primary purpose of launch events is apparently to get free junk, and in some cases, other stuff, from a collection of vendors you have never heard of and don't care about. I hung out in the "Ask the Experts" booth for a while, with fellow MVP Alun Jones. I think we answered more questions about "so, what free stuff do you give away" or "would you like to scan my badge for your drawing" than we did on any other topic. We did not actually have any drawing, nor any free stuff to give away other than actual knowledge, or at least, opinions. We answered precious few security questions.
  3. Explaining to people that you are a security "expert" apparently does not stop them from asking you questions about SharePoint.
  4. What the one sausage said to the other sausage in the frying pan (yeah, it was bad, and it is not really worth the bits to relay it)
  5. Windows Firewall with Advanced Security stops malware from spreading on your network. Yes, that's right. I went to the security presentation and, apparently, in conjunction with System Center, Windows Firewall will somehow cause malware to ask for permission before sending your credit card to Russia and your bank account to China. Had I not known already that no host-based firewall can stop malware running  on a computer from sending anything to anyone I might actually have been convinced by this claim. As it were, I was just kind of appalled that Microsoft now officially makes the same ludicrous and impossible claims that the security vendors do.
  6. Network Access Protection (NAP) provides "Secure Access Control" to your network. Apparently it does this by giving your computer a bogus IP address. This means that the domain admin that logs on to a workstation cannot disable the built-in firewall. Yes, that is correct, during the demo, the presenter actually logged on to a Vista client using a domain admin account (bad), and then claimed that NAP can stop the locally logged on user from doing whatever that user possibly pleases to do (untrue).

At that point, I decided I had had enough marketing shill for one day. The event was interesting, and I think most of the attendees got some value out of it in that they learned a little about some new features. however, the NAP issue deserves some additional commentary.

In case you did not know, NAP is a policy compliance feature in Windows Server 2008. It will ask well-meaning clients to provide their state of health before they get to communicate on the network. It can use three different "enforcement" mechanisms. One is DHCP based. The client simply does not get a proper lease. One is IPsec based – the client does not get the proper material to negotiate IPsec security associations. And the third is 802.1x-based – the switch won't open the port to the correct network until the client is considered good.

As you can probably tell, the DHCP based "enforcement" is extremely weak. The user on the client, or some piece of malware, can simply configure a valid IP address and go to town on the network. 802.1x can be easily defeated by installing a hub in front of the switch, letting a legitimate client open the switch port, and then stealing the port by setting your MAC address on a rogue host on the same hub to the same address as the legitimate client. The IPsec enforcement is considerably more difficult to circumvent, but you can still do it by making the NAP client lie.

The short story then, is that NAP still relies on the client to tell the Network Policy Server (NPS) what its state is. If the client lies, the NPS server has no way to know the difference, and will trust it. I actually helped design NAP, years ago, and this was a weakness we were very aware of then, but saw no way around. Yet, NAP is still valuable. It is a great technology to ensure that compliant clients stay compliant; that non-malilcious clients have all the necessary policies deployed, the right patches installed, the correct anti-malware software running and updated, and so on. Every network security administrator should definitely spend some time with NAP and consider whether it could provide another valuable tool in their arsenal.

However, NAP does NOT provide "Secure Access Control" to the network. It does not do so because it cannot provide true security. It cannot prevent malicious clients from getting on the network. Unless it is used with IPsec enforcement, in conjunction with Server and/or Domain Isolation, it also cannot prevent a malicious client from communicating with any other computer on the network. None of that makes it useless, nor does it mean that it is not a security technology. Policy enforcement, even when only on clients that choose to comply, is still a security concern, and a valid objective. Keeping managed clients managed is important. However, it is also really important that we understand the limitations of the technologies we are using, which is why I wrote this post.

Troubleshooting Errors While Updating Software

A number of people are reporting errors when running software update tools. The tools include Windows Update, Windows Defender Updates, Installshield, Adobe Updater, and probably others as well. The errors include 80070005 (from Windows tools) and c0000005 (from others). To see if we can help people get their software updates, Steve Wechsler helped me put together some troubleshooting steps. If these steps help, and more so if they don't, we'd like to hear about it. If you find something else that helps, let us know by posting a comment.

 

All these errors indicate a permissions issue of some kind. All of them basically mean "Access Denied". However, determining exactly what the cause is can be difficult. There seem to be two main reasons why this is happening: multiple firewalls on the same computer, and a permissions issue, usually in the registry.

 

Multiple Firewalls
Several people with this problem report that it disappeared when the shut down one of the several firewalls they had on their computer. If you have installed a security suite, such as Norton Internet Security, on a Windows Vista computer, you have multiple firewalls. That, in and of itself, is not a problem as long as only one of them is running. However, if two, or more, are running at the same time, you will run into trouble. Some third-party firewalls appear to fail to properly disable the built-in Windows Firewall. If you have a third-party security suite installed, take the following steps to ensure the Windows Firewall with Advanced Security is turned off:

  1. Click the Window button (the start menu)
  2. In the search dialog, type "Windows Firewall"
  3. In a few seconds you will have a couple of results, including one that says "Windows Firewall". Click that one
  4. If the right-hand window says "Windows Firewall is on" click "Change settings"
  5. Accept the User Account Control prompt by clicking "Continue"
  6. Select the "Off (not recommended)" radio button and click OK. WARNING: do not do this unless you are sure you have a third-party firewall!
  7. Attempt to run the updater that failed again.

If this resolves the problem you can resolve it permanently by either leaving Windows Firewall off, or by disabling the third-party firewall. For the most part, they perform the same function, although the built-in firewall typically is far less intrusive and more stable. To disable the third-party firewall refer to the manufacturer's documentation.

 

Permissions Problems

If you do not have two firewalls the problem is almost certainly permissions related. If this is your case you need to resort to advanced troubleshooting tools.

 

Follow these steps carefully. They are written for Windows Vista, but the problem has also affected Windows XP. With only minor modifications (such as the ommission of the UAC elevation-related steps) they work on Windows XP as well.

 

Keep in mind that setting incorrect permissions can significantly harm your computer, to the point where it is either completely insecure, will not boot, or both. There are multiple recommendations out on the Internet that recommend that you change the permissions on large parts of the registry and the operating system. Doing so will render your computer unsupported and disable significant parts of the security sub-system. Surgical precision is key when modifying permissions.

 

  1. First, download Microsoft/System Internals Process Monitor from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx. Save it somewhere you can remember, such as your Downloads directory or the desktop.
  2. Open the Downloads directory in Windows Explorer (the easiest way is to hold down the Window key and hit E, click your name, and click Downloads)
  3. Right-click ProcessMonitor and select "Extract all…" Walk through the wizard to extract the files
  4. In the window that opens when the extraction is complete, double-click "procmon" or "procmon.exe"
  5. In the "Open File – Security Warning" prompt, uncheck the box that says "Always ask before opening this file" and click Run
  6. Accept the User Account Control prompt by selecting Continue
  7. Accept the license agreement (no, the next time you run the tool you will only have the User Account Control prompt, not all three)
  8. Maximize the window
  9. Hold the CTRL key and hit L
  10. In the drop-down that says "Architecture" select "Result"
  11. In the text box next to "Is" type "ACCESS DENIED" (without the quotes). Here is what it should look like:

  12. Hit the Add button
  13. Hit OK
  14. Hold CTRL and hit X to clear the output window

You now have Process Monitor monitoring all operations on the computer. At this point, retry the updater that fails. If the updater fails with a permissions problem, you should get entries in the Process Monitor window. Each one indicates a potential problem that could harm your ability to install updates, although they may also be unrelated.

 

Here is an example of the types of ACCESS DENIED errors you may see. Note that your process name would not be regedit.exe.
 

To fix the problem you need to set permissions. If you are not comfortable with exactly how to do that, I can help you if you send me the keys that are causing the error. You can do that most easily by clicking CTRL+A in Process Monitor, and then clicking CTRL+C to copy it. Then click the "Comments" link on the right side of the blog to send me a message, and paste the output into it.

 

To fix the problem yourself you can also change the permissions on the registry key (typically) or file that is a problem. I have not yet seen this happen because of file permissions, but if it does, it would be interesting to know. To fix registry permissions problems, do this:

 

  1. Right click the event and select “Jump to…”
  2. Right-click the key that is listed and select “Permissions…”
  3. Click Advanced
  4. Make sure that permissions are at least Full Control for TrustedInstaller, and Read for Administrators and SYSTEM. If that is what you have, and you are using a non-Windows installer (such as Adobe Updater), close the Advanced window, select the Administrators entry, and click the Full Control checkbox
  5. Click OK to close the dialogs.
  6. Retry the update

This will work under the assumption that the proper permissions were overridden on that particular key. In general, permissions on these keys should be Read for everyone except Trusted Installer, as follows:

You may, however, see Administrators have Full Control, or SYSTEM having Full Control. Those are both typically acceptable.

 

If this helps you, and you do not mind, could you please post a comment with the key that was a problem? It would be very interesting if we could figure out if this is caused by some particular piece of software that modifies some particular value.

Troubleshooting Permission Errors While Updating Software

A number of people are reporting errors when running software update tools. The tools include Windows Update, Windows Defender Updates, Installshield, Adobe Updater, and probably others as well. The errors include 80070005 (from Windows tools) and c0000005 (from others). To see if we can help people get their software updates, Steve Wechsler helped me put together some troubleshooting steps. If these steps help, and more so if they don't, we'd like to hear about it. If you find something else that helps, let us know by posting a comment.

 

All these errors indicate a permissions issue of some kind. All of them basically mean "Access Denied". However, determining exactly what the cause is can be difficult. There seem to be two main reasons why this is happening: multiple firewalls on the same computer, and a permissions issue, usually in the registry.

 

Multiple Firewalls
Several people with this problem report that it disappeared when the shut down one of the several firewalls they had on their computer. If you have installed a security suite, such as Norton Internet Security, on a Windows Vista computer, you have multiple firewalls. That, in and of itself, is not a problem as long as only one of them is running. However, if two, or more, are running at the same time, you will run into trouble. Some third-party firewalls appear to fail to properly disable the built-in Windows Firewall. If you have a third-party security suite installed, take the following steps to ensure the Windows Firewall with Advanced Security is turned off:

  1. Click the Window button (the start menu)
  2. In the search dialog, type "Windows Firewall"
  3. In a few seconds you will have a couple of results, including one that says "Windows Firewall". Click that one
  4. If the right-hand window says "Windows Firewall is on" click "Change settings"
  5. Accept the User Account Control prompt by clicking "Continue"
  6. Select the "Off (not recommended)" radio button and click OK. WARNING: do not do this unless you are sure you have a third-party firewall!
  7. Attempt to run the updater that failed again.

If this resolves the problem you can resolve it permanently by either leaving Windows Firewall off, or by disabling the third-party firewall. For the most part, they perform the same function, although the built-in firewall typically is far less intrusive and more stable. To disable the third-party firewall refer to the manufacturer's documentation.

 

Permissions Problems

If you do not have two firewalls the problem is almost certainly permissions related. If this is your case you need to resort to advanced troubleshooting tools.

 

Follow these steps carefully. They are written for Windows Vista, but the problem has also affected Windows XP. With only minor modifications (such as the ommission of the UAC elevation-related steps) they work on Windows XP as well.

 

Keep in mind that setting incorrect permissions can significantly harm your computer, to the point where it is either completely insecure, will not boot, or both. There are multiple recommendations out on the Internet that recommend that you change the permissions on large parts of the registry and the operating system. Doing so will render your computer unsupported and disable significant parts of the security sub-system. Surgical precision is key when modifying permissions.

 

  1. First, download Microsoft/System Internals Process Monitor from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx. Save it somewhere you can remember, such as your Downloads directory or the desktop.
  2. Open the Downloads directory in Windows Explorer (the easiest way is to hold down the Window key and hit E, click your name, and click Downloads)
  3. Right-click ProcessMonitor and select "Extract all…" Walk through the wizard to extract the files
  4. In the window that opens when the extraction is complete, double-click "procmon" or "procmon.exe"
  5. In the "Open File – Security Warning" prompt, uncheck the box that says "Always ask before opening this file" and click Run
  6. Accept the User Account Control prompt by selecting Continue
  7. Accept the license agreement (no, the next time you run the tool you will only have the User Account Control prompt, not all three)
  8. Maximize the window
  9. Hold the CTRL key and hit L
  10. In the drop-down that says "Architecture" select "Result"
  11. In the text box next to "Is" type "ACCESS DENIED" (without the quotes). Here is what it should look like:

  12. Hit the Add button
  13. Hit OK
  14. Hold CTRL and hit X to clear the output window

You now have Process Monitor monitoring all operations on the computer. At this point, retry the updater that fails. If the updater fails with a permissions problem, you should get entries in the Process Monitor window. Each one indicates a potential problem that could harm your ability to install updates, although they may also be unrelated.

 

Here is an example of the types of ACCESS DENIED errors you may see. Note that your process name would not be regedit.exe.
 

To fix the problem you need to set permissions. If you are not comfortable with exactly how to do that, I can help you if you send me the keys that are causing the error. You can do that most easily by clicking CTRL+A in Process Monitor, and then clicking CTRL+C to copy it. Then click the "Comments" link on the right side of the blog to send me a message, and paste the output into it.

 

To fix the problem yourself you can also change the permissions on the registry key (typically) or file that is a problem. I have not yet seen this happen because of file permissions, but if it does, it would be interesting to know. To fix registry permissions problems, do this:

 

  1. Right click the event and select “Jump to…”
  2. Right-click the key that is listed and select “Permissions…”
  3. Click Advanced
  4. Make sure that permissions are at least Full Control for TrustedInstaller, and Read for Administrators and SYSTEM. If that is what you have, and you are using a non-Windows installer (such as Adobe Updater), close the Advanced window, select the Administrators entry, and click the Full Control checkbox
  5. Click OK to close the dialogs.
  6. Retry the update

This will work under the assumption that the proper permissions were overridden on that particular key. In general, permissions on these keys should be Read for everyone except Trusted Installer, as follows:

You may, however, see Administrators have Full Control, or SYSTEM having Full Control. Those are both typically acceptable.

 

If this helps you, and you do not mind, could you please post a comment with the key that was a problem? It would be very interesting if we could figure out if this is caused by some particular piece of software that modifies some particular value.

Resource Kit Done!

Last Friday the last of the Windows Server 2008 Security Resource Kit finally went to press! This was a project I had not really planned and so, to complete it in time, I brought in an amazing crew of co-authors. Together, we managed to put together 17 chapters on how to manage security in one of the most exciting products this year.

 The contributors to the Security Resource Kit are:

  • Jimmy Andersson – Principal Advisor at Q Advice AB and Microsoft Active Directory MVP
  • Susan Bradley – Small Business Server MVP
  • Darren Canavor – Software Architect in the Windows Security group at Microsoft
  • Kurt Dillard – Consultant, and former Program Manager in the Microsoft Solutions for Security group
  • Eric Fitzgerald – Currently on the Forefront team, and formerly program manager for the auditing sub-system in Windows
  • Roger Grimes – Consultant in the ACE team at Microsoft
  • Byron Hynes – Enterprise Technology Strategist at Microsoft
  • Alun Jones – Creator of WFTPD, and Microsoft Security MVP
  • Brian Komar – President of IdentIT, Inc and Microsoft Security MVP
  • Brian Lich – Senior Technical Writer at Microsoft
  • Darren Mar-Elia – Founder and CTO of SDM Software, and Microsoft Group Policy MVP

The book has 16 chapters plus a bonus chapter on Rights Management Services on the CD. The chapters in the book are:

  1. Subjects, Users, and Other Actors
  2. Authenticators and Authentication Protocols
  3. Objects: The Stuff You Want
  4. Understanding UAC
  5. Windows Firewall(s)
  6. Services
  7. Group Policy
  8. Auditing
  9. Designing Active Directory Domain Services for Security
  10. Implementing Active Directory Certificate Services
  11. Securing Server Roles
  12. Patch Management
  13. Managing Security Dependencies to Secure Your Network
  14. Securing the Branch Office
  15. Small Business Considerations
  16. Securing Server Applications

As with my Protect Your Windows Network book, there are some assorted goodies on the CD. The first one is a much improved version of the command line elevation tool that I wrote for Windows Vista Security. It now includes not just command line elevation capability, but I also added the ability to launch an elevated Windows Explorer window. The easiest way to do that is by right-clicking the folder and selecting "Elevate Explorer Here" as shown here:

The ability to elevate Windows Explorer was not included in Windows Vista, nor in Windows Server 2008, because Explorer is not really designed to be run in multiple instances in the same session. However, I find that it works quite well in spite of that, and it is extremely useful when you need to perform multiple file operations requiring elevation.

Note the little green dot in the window above. It shows me what privileges I am running with and is provided by Aaron Margosis' most excellent Privbar tool. I highly recommend using it with the Elevation Tools so you can keep track of which windows are elevated.

The Security Resource Kit CD also comes with 15 custom-written PowerShell scripts, and an electronic version of the entire book, as well as some assorted other pieces.

All in all, I am really happy with it. I hope you will like it too.