Windows has a feature called "impersonation", by which a process running as one user account can assume, on a single thread, the identity of another logged-on user account, for purposes of performing some action on behalf of the second account. This makes sure that we get access control right.
For instance, the Server service, which runs as LocalSystem, handles remote file requests like requests to access files on a share. It logs the remote user on, spawns a worker thread to access the file(s) locally, and then impersonates the remote user on that worker thread. This way, all permission checks are performed against the remote user; we don't accidentally give away any extra permissions.
If Server didn't impersonate, and Microsoft got something wrong in the code, Server might accidentally do something with LocalSystem permission and return the results to the remote user, who might not have had permission to perform the same operation.
"Primary user" is the account from the primary token of the process which performed the auditable action- LocalSystem in my example. "Client user" is the account from the impersonation token of the thread which performed the auditable action- the remote user in my example.
If impersonation is not occurring, then the client user fields would not be filled out- we'd put a dash in them.
What does this mean for you?
If the client user fields are filled out, then the client user is the interesting user- the user "who dunnit". This is the account that made the request that caused something auditable to occur.
If the client user fields are not filled out- that is, the client user is "-" (hyphen/dash)- then the primary user is the interesting user.
In Windows Vista, to simplify the audit schema and make the events easier to understand, we're getting rid of primary and client user fields and replacing them with "Subject"- subject is the client user if impersonation is occurring, otherwise it's the primary user.
For those dev types who still want to know the primary user in those cases, you'll still be able to correlate with process tracking audit events and the process creation event will tell you the user from the process' primary token.
PingBack from http://winblogs.security-feed.com/2005/12/16/what-the-heck-are-primary-user-and-client-user/