Reenable Workgroup (without Domain)

[dazu89]

Dear community,
I used to enable network file sharing between two machines in a workgroup within my private network without a domain by setting up two identical user accounts on both machines. The device on which I ran the script is now hardened indeed, to the point that I am unable to restore the necessary group policies to make this hack work again – I would much appreciate your help in reconfiguring the necessary group policies to this end or hearing your opinion on the weakness of this hack.

Up to now I changed the following:

• Add "Everyone" to "Local Policies > Access this computer from the network" (if not on a secure network, I block all incoming connections in a different way)

My first guess would have been to change some setting related to the Security Accounts Manager (SAM), but I am still stuck at the "Enter network credentials" prompt on the other machine.

[simeononsecurity]

Everyone shouldn't be used as it can allow anonymous access if it weren't disabled via this hardening script.
Instead you should assign the user to a group and allow that group access to the remote network. In the windows world, the everyone permission should practically never be used except in very specific instances of IIS servers and few other exceptions. In which case, you'd know when you need to use it.

As far as fixing access, that permission and sharing the file via the windows GUI should be enough for most cases.
The one thing I would check is the "Deny access from the network" option, as it might have included "Local Accounts", which would break the share in the way you're suggesting.

Additionally, depending on how you're mounting the share and since you're using the same username and in a workgroup situation, you should specify your username in hostname\username format. For instance, if the machine name is "NAS" and your username is "dazu", you should login to that machine using "NAS\dazu" as your username. Sometimes windows is smart enough to not need this, but often it does. Using this format will ensure that it will work every time.

[dazu89]

Thank you, @simeononsecurity for your assistance, and in general, for making this script available to the wider public!
Indeed, creating and adding an identical user account as the one on the client machine to the host and adding it under "Access this computer from the network" as well as deleting "Local Accounts" group from the policy "Deny access from the network" did solve the issue.