Re: User Rights Assignment - not available - Resolved

I would not necessarily thing you had been hacked. Some sort of corruption
as the KB article reference was a more probable reason. --- Steve

"Tim Munro" <Excelsior@xxxxxxxxxxx> wrote in message
I made a statement that "Clearly I had been hacked". Now I'm not so
sure. I'm wondering if this could have been a vestage of a failed SID
change on my computer.


"Tim Munro" <Excelsior@xxxxxxxxxxx> wrote in message
I used the DumpSec tool Steve pointed me to and obtained an error from it:

rc=3221225524 LsaEnumerateAccountsWithUserRight

Translating this to Hex I got C0000034. Googling this I found article:;en-us;199071 . Although
all my "secrets" were Ok, I poked around for a bit. I went into the
"Accounts" key, and noted some SIDs I could not explain. Armed with the
base sids of our domains, and my local machine, I removed all sid entries
I could not resolve. Low and behold my "User Rights Assignment" came
back. No reboot nothin'. Clearly I had been hacked.

Situation resolved for now. I have since done a full sweep of my
machine and all looks well.

Thanks Steve for your effort to help me here. Pointing me to DumpSec
lead me down the right path.


"Tim Munro" <Excelsior@xxxxxxxxxxx> wrote in message
OK Thanks Steve, I'll see what I come up with.


"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
Hmm. I have never seen that happen. A couple things you could try. Go
to the \windows\system32\config folder and rename the security file to
something else. Then copy the security file from the \windows\repair
folder. You can not do that however in normal operating system state
but might be able to do it while booted into Recovery Console. -- XP Recovery Console.

Another thing to try is to run the Security Configuration and Analysis
mmc snapin and analyze and then configure with the setup security.inf
security template to see if that helps or not. Beyond that if it was me
I would try to restore a backup of the System State [if you have any]
or you could try a system restore to an earlier point which is what to
try first. If none of that works I would try an upgrade/repair install
before resorting to a pristine install. An upgrade/repair install
however will require that you first install your service pack [if not
slipstreamed into install media] and then all critical updates at
Windows Updates. Another possibility is to live with it the way it is.
You could try using the free utility dumpsec from Somarsoft to see if
it shows user rights and use the Resource Kit command line tool
NTrights to change user rights when needed. --- Steve
--- XP System Restore --- Dumpsec
--- System State backup

"Tim Munro" <Excelsior@xxxxxxxxxxx> wrote in message
No go.

Here's the top of the log file created:

Sunday, February 26, 2006 10:47:44
----Configuration engine was initialized successfully.----

----Reading Configuration Template info...
Event audit settings are turned off.

----Configure User Rights...
Warning 2: The system cannot find the file specified. <--- what file?
Error enumerating info for Accounts from LSA. <----- this bothers
Configure S-1-5-20.
Configure S-1-5-19.
Configure S-1-5-32-551.
Configure S-1-5-32-544.
Configure S-1-1-0.
Configure S-1-5-32-545.
Configure S-1-5-32-547.
Configure S-1-5-21-1060284298-329068152-839522115-501.
Configure S-1-5-32-555.

User Rights configuration was completed successfully.

"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
Weird. There are free tools from SysInternals called filemon and
regmon that if you start them just before you try to run something
and then stop them from logging when the action fails you may find
helpful information in the log for access denied entries that would
indicate something you do not have necessary permissions for. I use
them quite a bit and find it is helpful to add access denied to
filter view to highlight as there could be thousands of entries in
the log. The link below is to regmon and filemon.

Another thing you could try is to use the secedit command to try and
restore security settings to default defined levels which may help
per the link below. You can simply copy and paste the command to run
as it is. --- Steve;EN-US;313222

"Tim Munro" <Excelsior@xxxxxxxxxxx> wrote in message
I went through both the integrity check and did a repair anyway.
Result is the same. I'm guessing here that this may be a permissions
problem. Everything else on the "Local Policy" mmc is accessible and
changeable. It's just the "User Rights Assignment" that is bad.

When I went to rebuild (copying and renmaing as the article
suggests) I did get the access denied. Unfortunately "Import
Template" was greyed out when I used the filename secedit.sdb. Any
other name and it was fine.

Is there somewhere in the registry I can check for permissions
that might be causing this behaviour?


"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:8OidnU6airjcPGLenZ2dnUVZ_vudnZ2d@xxxxxxxxxxxxxx
Hmm. It sounds like you may have a corrupt secedit.sdb file. See
the link below for two possibilities of which one is to attempt a
repair with esentutl and the other is a rebuild. --- Steve

To resolve this issue, first run the Esentutl.exe tool to examine
the integrity of the Secedit.sdb database. To do this, follow these
steps: 1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type the following command, and then
press ENTER:
esentutl /g Drive:\WinDir\security\database\secedit.sdb
Note In this command, Drive is the hard disk drive where
Windows XP Professional is installed, and WinDir is the folder
where Windows XP Professional is installed.
After the Esentutl.exe tool finishes, use one of the following
methods to resolve the issue, depending on the message that the
Esentutl.exe tool returns: . If the Esentutl.exe tool returns the
following message, use Method 1 to resolve the issue:
This operation may find that this database is corrupt
. If the Esentutl.exe tool returns information that is similar
to the following message, use Method 2 to resolve the issue:

Microsoft(R) Windows(R) Database Utilities
Version 5.2
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating INTEGRITY mode...
Database: L:\WINDOWS\security\database\secedit.sdb
Temp. Database: TEMPINTEG2680.EDB

Checking database integrity.

Scanning Status (% complete)
0 10 20 30 40 50 60 70 80 90 100

Integrity check successful.

Operation completed successfully in 0.841 seconds.
Note When you run the Esentutl.exe tool, your computer is returned
to the original installation state where the Local Security Policy
is not defined. You may have to start your computer in Safe Mode to
rename files or to move files. To start your computer in Safe Mode,
press the F8 key while Windows XP Professional is starting, type 1
to choose Safe Mode from the startup options, and then press ENTER.

"Tim Munro" <Excelsior@xxxxxxxxxxx> wrote in message
Hello all,

On my local PC (Windows XP SP2), in "Local Security
Settings>Local Policies>User Rights Assignments" I get "Windows
cannot read template information". Any idea what happened and/or
how to get this back?