I got the question last week, why there are so many logon failure events on Windows XP when it is not domain joined.
The short answer is, by design. (Yes, bad design.)
The longer answer is that the shell team is working around the fact that there is no “tell me if this user account has a blank password” API.
When in a workgroup (not domain joined), Windows XP displays a welcome screen that has little pictures (called “tiles”) for each user who is permitted to log on to the computer.
The shell team wanted the experience that when you click on a tile, that you will immediately be logged on if your password is blank (we have good data that a large percentage of home users have blank passwords). They only want you to be prompted for a password if you actually have a password. Fair enough, and it also helps with accessibility for people for whom typing is challenging.
The XP Welcome Screen, when it is initialized each time it is to be displayed, attempts to log on each user for which a tile will be displayed, using a blank password. Users with non-blank passwords will cause failures in this case (other users will cause logon success events followed by logoff success events). [2007-11-21 correction]
The Welcome Screen uses the result of these logon attempts to decide whether to display a password box when you select a user’s tile. If the user has a blank password, they will be logged on instead of being prompted for a password.
Why are they logging on the account? Well it turns out to be the easiest way to tell if your password is blank. We don’t have a “is your password blank” API- that would be a security disaster- and we would prefer that the shell team not go mucking about in the SAM, retrieving hashes and computing the blank password hash for each account so that it could compare them.
I asked for this behavior to be changed prior to XP’s release. Specifically I asked that the blank password check be moved from Welcome screen initialization to tile selection- this would still cause logon failures but many fewer of them. I was declined. I asked for fixes to it in SP1 and SP2 and was declined. At this point we will not be revisiting this “feature”; the Welcome Screen was redesigned to eliminate this problem.
The shell team who designed the Welcome Screen did not feel that auditing was a common scenario for workgroup machines, and I didn’t (and still don’t) have any business case to dispute that.