My Experiment
- So I set up a simple network with Two computers. Both on the same Work group.
- I created a LOCAL user 'A' with pasword 'A' in Computer 1.
- And then I created an identical named LOCAL user 'A' with identical password 'A' on Computer 2.
My Observation
- What I notice is that when I'm logged in as 'A' in computer 2, I am allowed network access as 'A' in Computer 1. E.g. when browing 'A' shared folders.
My Thoughts
- This is ironic as even though they are the identical in name, they are acutally two different LOCAL users on two different computers!
- This to me can be a security hazard. What if coincientially a Person has the same username and password in computer 2 thus incorrectly given access to Computer 1?
My Question:
- What is this sharing of username and password called?
- How come identical name and authentication between two windows PCs on same network works?
- How do we enable/disable this sharing of identical LOCAL usernames and passwords between two computers?
I've also realized that this works during DCOM calls as well.
Thank you for any answers
Let's get started:
"By Design"... or more specifically, "pass-through authentication".
Because this is what it's designed to do. When Windows attempts to access a network resource, and the resource requires authentication, it sends through its current username and password. The receiving computer then authenticates this and returns success or failure. (This is really, really simplified, it doesn't actually broadcast your password but I'm going to KISS).
Honestly, this isn't what you want. Mainly because the user will just then type their username and password into the credentials box, and then get the same access they would have had previously. Instead, you should be applying security on the shares/resources to ensure that only the people you want to have access have access.
After you log in, Win box will take your password and store its LM and NT hashes in kernel memory, to have this SSO function on workgroups and NT4 domains. (On Active Directory domains, the Kerberos TGT obtained when you enter the password is stored as well.) User-space programs can't use these hashes directly, but they can ask the kernel to connect to a SMB server using the stored password/ticket, or to perform NTLM challenge-response operation or Kerberos auth on behalf of the app/service for other protocols such as IMAP or HTTP. Also, Windows uses MD4 hashes for both local authentication and NTLM, but this is not important – it could as well keep plain-text password in memory if it was needed. Hope this explains.