Based on some Googling after I encountered this, I found that there was a change in Windows 2003 that allowed attributes to be marked as confidential. I’m not sure if this applied to “uSNChanged.”
One example result (a top Google hit):
http://www.eventid.net/display.asp?eventid=566&eventno=4015&source=Security&phase=1
Assuming this applies to your situation, you appear to have two options (quoted from the article linked above):
- Set Directory Service Access Auditing to no auditing to remove the audit entries from the security event log.
- In ADSIEDIT go into the SCHEMA partition - UnixUserPassword - under the attributes of search flags change from 128 to 0 then Force replication.
I didn’t come across anything obviously more specific when looking for “event id 566” along with “uSNChanged.” Adapt the instructions for the attributes in your situation.
There are lots of mentions of this elsewhere. I haven’t sorted it out myself, but hopefully this helps your situation.
There doesn't appear to be a GUI-based way of doing this unless you're joined to a domain - at least not one I could find anywhere - so I did a bit more digging and I've found an answer that works for our situation.
I didn't understand what the string representation meant in the knowledge base article, but doing a bit of digging led me to discover that it's SDDL syntax. Further digging led me to this article by Alun Jones which explains how to get the security descriptor for a service and what each bit means. MS KB914392 has more details.
To append to the service's existing security descriptor, use sc sdshow "Service Name" to get the existing descriptor. If this is a plain old .NET Windows Service - as is the case with ours - the security descriptor should look something like this:
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOC
RRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)S:(AU;FA
;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
We needed to grant permissions RP (to start the service), WP (to stop the service), DT (to pause/continue the service) and LO (to query the service's current status). This could be done by adding our service account to the Power Users group, but I only want to grant individual access to the account under which the maintenance service runs.
Using runas to open a command prompt under the service account, I ran whoami /all which gave me the SID of the service account, and then constructed the additional SDDL below:
(A;;RPWPDTLO;;;S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxx)
This then gets added to the D: section of the SDDL string above:
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOC
RRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)(A;;RPWP
DTLO;;;S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxx)S:(AU;FA;CCDCLCSWRPWPDTLOC
RSDRCWDWO;;;WD)
This is then applied to the service using the sc sdset command (before the S: text):
sc sdset "Service Name" D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;
CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU
)(A;;RPWPDTLO;;;S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxx)S:(AU;FA;CCDCLCSW
RPWPDTLOCRSDRCWDWO;;;WD)
If all goes according to plan, the service can then be started, stopped, paused and have it's status queried by the user defined by the SID above.
Best Answer
That GUID is probably {D61A27C1-8F53-11D0-BFA0-00A024151983}, which is the AppID for the Removable Storage Manager.
While it's true that "Backup Operators" have the "SeBackupPrivilege" privilege granted, apparently Microsoft didn't bother (at least in Windows XP Professional) to grant them explicit permission on the DCOM applications necessary to actually make running a Scheduled Task-based backup work.
You have a couple of choices. You could just give that user "Administrator" rights, and then everything will "just work".
I've also gone through the ordeal of figuring out which DCOM objects need to have their permissions changed to make this work with a user who is only a member of "Users" and "Backup Operators". To test it, using the "Component Services" management-console snap-in, navigate to "Component Services", "Computers", "My Computer", and "DCOM Config". Modify the "Launch and Activation Permissions" on each of the objects named below, changing the setting from "Use Default" to "Customize" and adding "Backup Operators" with both "Local Launch" and "Local Activation" permission to each.
After changing those permissions, I found that I was able to make a backup job running as a Scheduled Task under a user context who only had "Users" and "Backup Operators" group membership funciton as I expected.
Microsoft is aware of the issue (see http://support.microsoft.com/kb/311866), but their article doesn't provide a correct resolution. (It's an April 2002 article, too... It clearly hasn't been updated for the changes to DCOM made in Windows XP SP2. http://technet.microsoft.com/en-us/library/bb457148.aspx)
DCOM permissions are stored in the registry as REG_BINARY keys. There's no mechanism that I'm aware of in stock Group Policy for manipulating them. It should be possible to replicate the LaunchPermission value (see it under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID{56BE716B-2F76-4dfa-8702-67AE10044F0B} after you change the launch permissions, for example) between different computers with a simple registry merge because the ACL we're placing on the resource only names well-known SIDs and no machine or domain-specific SIDs.
I'd just grant the user "Administrator" rights and be done with it, but there certainly is another option if you want to do it.