Logon Error - Event ID 533

WinXP SP3, System is standalone, not connected to a network

This is the text of the event:

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 533
Date: 6/3/2009
Time: 08:14:05
User: NT AUTHORITY\SYSTEM
Computer: IS00002

Description:
Logon Failure:
Reason: User not allowed to logon at this computer
User Name: dummy
Domain: (deleted)
Logon Type: 2
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: (deleted)

--------------------------------------------------
The "deleted" text is for security purposes.

1) "Dummy" is member of "Users" Group

2) Local Security Settings, Log on locally = Users, Administrators

Note all Security Settings are DoD mandated.

Even if I create a new account like "Dummy" I get this error.

ONLY if I make a user (ANY user) a member of Administrators can they
logon.

I found the MS TeckNet article:
http://www.microsoft.com/technet/sup...ty&LCID=103 3

Also found many hits using Google.

Problem, none provided a fix or even a hint that applies in this case
(Users in Log on locally).

So, WHAT is the fix?

Some possibilities for you to consider:
http://www.eventid.net/display.asp?e...rit y&phase=1

What version of Windows XP?

Logon Type 2 - Interactive
This is what occurs to you first when you think of logons, that is, a
logon at the console of a computer. You'll see type 2 logons when a user
attempts to log on at the local keyboard and screen whether with a
domain account or a local account from the computer's local SAM. To tell
the difference between an attempt to logon with a local or domain
account look for the domain or computer name preceding the user name in
the event's description. Don't forget that logon's through an KVM over
IP component or a server's proprietary "lights-out" remote KVM feature
are still interactive logons from the standpoint of Windows and will be
logged as such.
http://www.windowsecurity.com/articles/Logon-Types.html

http://www.microsoft.com/resources/d....mspx?mfr=true

Gerry, the references do not apply. The fixes are for systems using
Domain Servers, NOT un-networked standalones.

The "Domain: (deleted)" = "Domain: IS00002"

The system is default WORKGROUP

Both keyboard & mouse are connected directly to this standalone PS/2.
This is a local keyboard, mouse, monitor.

I am assuming the error showing "Domain: IS00002" is what you get when
using a local logon. So, SHOULD a logon to a non-networked standalone
in a WORKGROUP, have a "Domain" name listed in this type of Event
Error?

OR, is that the error, something in WinXP thinks "Users" are logging
into an actual Domain? BUT, when ANYONE is a member of Administrators,
they do NOT have a logon problem.

Neither. This is a DoD system, used where I work. This is why I
stated in my original post that all Security Settings are DoD
mandated. No network connection allowed. Win Updates via our Slip-
Stream CD use in our OEM product. AntiVirus Updates via CD, Symantec
Intelligent Updater.

As stated on my original post, WinXP SP3 was installed from scratch
(WinXP SP2 CD -> SP3 upgrade via CD). I have done this numerous
times.

Is this the software you are using?
http://www.microsoft.com/downloads/d...n#Requirements

I am confused. What is this computer to be used for? Is it a home or
office computer?

Have you just installed Windows XP? Have you answered these questions
incorrectly?

I'll double check, but I'm sure we overwrite every 30-days. Anyway,
we clear/save all Audit Logs every week, so a full log should not be
the problem.

Also, 2 days ago, I created a dummy account, member Users Group, for
testing. The user cannot logon and no Profile folder is made, as I
would expect.

Your security Audit log may be full, log in as an admin and delete it. If
that is not it then check out this policy
Computer Configuration\Windows Settings\Security Settings\Local
Policies\Security Options
If this policy is enabled, it causes the system to halt if a security audit
cannot be logged for any reason. Typically, an event will fail to be logged
when the security audit log is full and the retention method specified for
the security log is either Do Not Overwrite Events or Overwrite Events by
Days. The DOD configuration may have their own modifications to that policy.

No. Your URL is for Win2003 systems only. Also the article is not
the governing DoD authority for the system we have to use.

Take a look at these articles http://support.microsoft.com/kb/823659
http://support.microsoft.com/kb/160783/

Do not click on any links this person provider as he is the worst troll
current lurking in this newsgroups.

The suggestion regarding security logs should not apply if the overwrite
option has been selected and you have the default maximum of 512 kb. You
have received the failure report and no doubt later events are recorded
in the Security log. The comments by the Real Truth Imposter are
contradicted by the continuing recording of events.

How to Set Log Size and Overwrite Options
To specify log size and overwrite options, follow these steps:
Click Start, and then click Control Panel. Click Performance and
Maintenance, then click Administrative Tools, and then double-click
Computer Management. Or, open the MMC containing the Event Viewer
snap-in.
In the console tree, expand Event Viewer, and then right-click the log
in which you want to set size and overwrite options.
Under Log size, type the size that you want in the Maximum log size box.
Under When maximum log size is reached, click the overwrite option that
you want.
If you want to clear the log contents, click Clear Log.
Click OK.
Source: http://support.microsoft.com/kb/308427/en-us

Take care Real Truth is plausible and many get taken in by him. Normally
he posts simple comments but on this occasion his remarks are more
complex.

OK so can you post me a link for the governing DoD authority for the
system you have to use?

You probably by now appreciate that this may not be the most appropriate
newsgroup for you problem. If I knew the software you are using I may be
able to suggest a better place to ask.

This classified PDF document is not for general release. Sorry.

As for Event Viewer, your method is the long way around. I have a
link to it in the Quick Launch Bar (from Admin Tools in Control
Panel). The filesize is more than enough, overwrite 30-days, but we
clear/save once a week, so that's not the issue.

The bottom line is, if [Local Security Settings, Log on locally =
Users, Administrators], what is preventing a user-name that is a
"Member of Users" from logging on?

They get the "your account is configured to prevent you from using
this computer. Please try another computer."

[nkc_con]

I'm having a similar issue in a very similar environment.

Standalone PL-1 system WinXP SP3 and getting the same error for non administrative local users.

Its not a problem with the event log and the Users group is included in the local logon policy.

I was thinking it might have been related to rename in the computer name recently, but I don't see why that would matter.

I figured out a solution. It seems since I changed the computer name, I needed to change the workgroup name once and reboot. Then I can logon with a non admin account.

Workgroup name doesn't really matter on this machine anyway since it will never be on the network.

It might just be a concidence that mine had been renamed.

I was having an identical problem to what you describe, and when I renamed the workgroup and rebooted, the problem went away.

Since renaming the workgroup is pretty harmless, you might try it just to see.

Ensure that the user account has permissions to connect to the servers.
Go to Active Directory users and Computers > user account properties >
Account tab and click Log on to.
Select All Computers
I posted a screenshot here

Scratch that you said it is a standalone system.

The problem system has never been renamed since built 2mths ago.

The first link (KB823659) is for systems on domains, does not apply in
my case.

The second (KB160783) is for Workstations, again does not apply in my
case.

Both KB are for networked systems, the problem system is standalone
non-networked.

You are talking about a Domain Server.

Again, the problem system is standalone, workgroup, no network
connection at all.

[chord]

I have the exact same issue, and I can't figure it out. I need to get these machines configured soon.

I agree about the MVP's. Most of them are just Microsoft brown nosers.

This seemed to work for me.

Click Start, and then click Run.
In the Open box, type regedt32.exe, and then click OK.
Click the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Lsa\CrashOnAuditFail
In the right pane, double-click CrashOnAuditFail.
In the Value data box, type 0 (zero), and then click OK.
Click Start, and then click Run.
In the Open box, type secedit /refreshpolicy machine_policy /enforce, and then click OK to apply the new security setting.
Restart
Log back in and go into gpedit.msc and enable it again.
Restart

IF I can find the solution I WILL pass it on.

What bothers me is the "experts" (especially MVPs) cannot give us a
fix. Especially since many have the exact same problem.

How could WinXP NOT allow logon of a member of the Users Group when
"User Rights Assignment, Log on locally" includes "Users"....?!!!!

Is there no one else that had this problem in the past not found a
fix?

REMINDER: My problem is on a system that is NOT networked
(standalone) so Domain fixes do not apply.

I'll have to try your solution, thanks.

It matches one solution found in (found by link in Security Options)
http://support.microsoft.com/kb/823659/

BUT under paragraph "Security Settings, 1., g." it shows the exact
error msg I get, "Your account is configured to prevent you from using
this computer. Please try another computer."

AND the ref
http://support.microsoft.com/kb/160783/
deals with a Domain logon and the msg is NOT match what KB823659
states.

This is just one example of how many MS KB articles are NOT
consistent.

Your solution pointed me to the FIX.

The problem was
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Lsa
\CrashOnAuditFail
entry was corrupted ("Invalid DWORD")

Had to delete CrashOnAuditFail, then re-add it to correct the DWORD
(default = 0)

Restarted, tested user logon and it WORKED!

Reset CrashOnAuditFail = 1

Restarted and tested OK again.

[RandomUserName]

Thank you SO much! I am doing the exact same thing that you are doing and I ran into the exact same issue. It makes me suspect that something that was provided to us, a template perhaps, caused the corruption.

In any case, I was tearing my hair out until I managed to Google my way to this thread. Implemented your fix, problem solved.

THANK YOU!

[nkc_con]

I know this is belated, but thank you so very very much. This fixed my problem as well.