Posted by William Diaz on January 31, 2014
So, recently I had the need to setup auditing on a local workstation to try and determine who or what was deleting a specific set of files. Before we started, we decided to test the auditing on a couple PCs to audit all failed and successful attempts to delete any files or folders within some random test folder. Audit events are recorded in the Security logs of the Windows Event Viewer. Specifically, Audit Object Access events of interest are event ID 4656 (A handle to an object was requested) and 4663 (An attempt was made to access an object). The details should allude to the responsible user account and process. But to our surprise our test folder was not recording any audit events for any of the objects inside.
Maybe an oversight but perhaps auditing was not enabled in group policy. But a quick check revealed that it was being set for both success and failure:
Maybe it wasn’t getting applied to the workstation. Although deprecated since Vista, RSOP from the command line is useful for quickly spotting polices that might not be getting applied to the local computer. Sure enough I could see there was a problem with the audit policies: “The policy engine did not attempt to configure the setting…”
Read the rest of this entry »
Posted in Inside Windows | 1 Comment »
Posted by William Diaz on January 30, 2014
Posted in Uncategorized | Leave a Comment »
Posted by William Diaz on January 24, 2014
While in the process of composing an web-based email today via Internet Explorer, I noticed something odd when I went to attach a file to the message. In the IE file upload dialog there were a series of files listed on the desktop that I knew were not really there. Judging by the dates they had been hanging around for some time now but I had never noticed them (and, no, they were not hidden or marked as protected operating system files):
The files themselves were no mystery; they are nothing more than text files that dump process, thread, and stack information to the desktop when the JRE crashes. I tried to attach one of these to the web message but nothing would happen. However, from within in the dialog box I could right click and open them like any other files. Attempting to move the file also failed because the file itself apparently didn’t exist:
If that was the case, I should then get the same message trying to copy it back to the desktop. Instead, the dialog this time indicated it did exist:
I wondered if I could access these ghost files from outside IE by, for example, attaching them to a message in Outlook. Not surprisingly, the same set of files did not appear from the desktop location:
This was likely something specific to IE. To determine where the files were actually residing, I turned to Process Monitor, started a trace for file activity and proceeded to open one of the ghost files via the IE File upload dialog box. Afterwards, I stopped the trace and did a search for the file in question.
There was half the mystery, the files actually resided in C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\username\Desktop. The other half of the mystery was then just a matter of some quick research into IE and Virtualized folders. That lead me to this MSDN article Understanding and Working in Protected Mode Internet Explorer. In short:
A Compatibility Layer handles the needs of many existing extensions. It intercepts attempts to write to medium integrity resources, such as the Documents folder in the user profile and the HKEY_CURRENT_USER registry hive. However it will not intercept writes to system locations like Program Files and HKEY_LOCAL_MACHINE. The compatibility layer uses a Windows Compatibility Shim to automatically redirect these operations to the following low integrity locations:
If I unchecked Enable Protected Mode in IE the virtual files no longer appeared in the file IE file dialog. Not that you don’t want to do that, just delete the files instead.
Posted in Troubleshooting | Tagged: Internet Explorer | Leave a Comment »
Posted by William Diaz on January 14, 2014
Today, I encountered the following on a newly imaged workstation: “The user Profile Service service failed the logon. User profile cannot be loaded.”
Often times when I encounter this it’s a simple matter of hacking the registry to fix it. This is covered in detail in this Microsoft KB You receive a "The User Profile Service failed the logon” error message. It also covered in one of my older (pre-MS KB) blogs.
The article, however, doesn’t cover the other scenario. Local admin and domain techs accounts could logon but not standard users accounts. This is often due to file permissions. For whatever reason, a system-admin protected file was created deep into the profile of the Default user account. This is where all new profiles are created from, and Everyone\Users must have at least read permissions for a new profile to be successfully spawned from the Default. The details are alluded to in the Windows Application event logs, event ID 1509:
Windows cannot copy file \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm to location \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm. This error may be caused by network problems or insufficient security rights.
DETAIL – Access is denied.
Looking at the problem file, we can see that the file has no permissions for Everyone\Users:
The solution is to delete the file (if non-essential) or add the correct user(s) and permissions. And depending on the location, you may need to uncheck Hide protected operation system files in Windows Explorer.
Posted in Troubleshooting | Leave a Comment »