Share via

Multiple Events for Failed Account Creation

  • Article

When you create a local user account on Windows, and you have enabled account management auditing, you will see multiple events that map into this single occurrence. I was actually going to file a change request on this, but I'm not sure that that is the right thing to do. Here's why.

The event pattern of a failed account creation (for example, if you try to create an account, but you don't specify a password that complies with your organizations' password complexity policy), looks like this:

560 - Accessed the SAM_DOMAIN object with the "create_user" access.
632 - Added the new user account to the group "None" ("None" is the primary group SID used for local accounts; it's one of those built-in Windows SIDs; it confers no access)
624 - Created the account
633 - Removed the new user account from "None"
630 - Deleted the account
562 - SAM handle closed

Now there is something unusual here - the group add occurs before the account is created. This could be a timing issue, where the group add thread's auditable activity won the race to the event log. However it might be that we're building the user account data structure before we actually commit it to the SAM. Event log only has 1s granularity, and it's not all that unusual on a multiproc system for events to show up slightly out of order.

Overall I don't see a bug here. I would prefer to see a single "account create failed" event rather than all these events, but I understand what is going on and it's not ambiguous so I don't see a huge problem.

Also keep in mind that if this had been an Active Directory account as opposed to a local SAM account, there would likely have been several DS Access events as the various attributes of the account were populated, and one for the creation of the object in the parent OU.

Eric

Comments