NB - This process relates to local user accounts.
Originally Posted by cookie_monster
Indeed, but this process happens at the remote machine (by the file server process as Mark refers to it) that the connection is being made to, so when connecting from machine A to machine B...
Machine A sends an SMB request to machine B. This includes the username/password. It would be pointless sending a SID as only machine A would know anything about it.
Machine B authenticates the username/password either against the domain or the local user account database. At this point a 'logon session' is created on Machine B holding the access token that will be used to access the resource on Machine B. A UID pointer is returned to Machine A
Machine A stores the UID in the open SMB request for Machine B.
When a request to access a secured resource goes from Machine A to Machine B, the open SMB channel is used along with the UID that Machine B then uses to refer to the original logon session created during authentication.
The point is that the SID does not travel from source PC to destination PC. The only place the Machine A SID has any relevance is on the Machine A and the same applies for the Machine B SID.
(apologies for multiple edits but I'm just coming to terms with this stuff myself)
A new comment on Marks original article has appeared that explains what I've been trying to, but does a much better job.
Mark's Blog : The Machine SID Duplication Myth
Comment dated Saturday, November 14, 2009 5:08 PM by Steve Gray
Yep i'd forgotten how the process works on a workgroup level. It's still not much of an issue if no one logs on as the local admin and everyone else logs on with a domain account. Good article though.