Setting "Everyone" in File Sharing to Work with Specific Users

Pyprohly · 07 Apr 2017

The only thing that attracted me to this thread was the permission problem and I wouldn’t be too confident in the networking department, but I’m glad I chose to engage in this thread because now that the weekend’s near I was able to do some intense research and testing with Windows networking to really brushed up on my skill in this area. After doing this, I’ve realised that two crucial points I have said are completely wrong and that I must correct these immediately.

Firstly, when I said,

Pyprohly said:

person A wanting to authenticate remotely with user A on that machine must create an identical user A on their own machine, i.e., same username, same password.

This is incorrect. You are never required to create identical user accounts across network machines. It is a very common tip to hear however, and I think this is because it solves networking issues as it happens to coincide correct requirements.

When you create an identical users on remote machines you’re automatically fulfilling two criteria points that actually matter: (1) you’re persuaded to set a password on the account you are authenticating with. A user account must have a password to be used for remote access unless those specific public shares provided by HomeGroup are used. (2) You’re forced to use credentials that are approved of on the target machine. People try to use the credentials for their own user account on their own machine rather than the machine for which they want to connect to.

Secondly, it is a bit of a mistake to categorise Workgroups and HomeGroups as two distinct networking possibilities. Before, I said,

Pyprohly said:

toppinglift said:

I just wanted to repeat that I am not using Homegroup.

Yes, it is important the we’ve established that.

suggesting that there is a great importance in identifying which technology is being used. And I also stressed not having used a Workgroup before which is really a dumb thing to say, as you’ll see.

All Windows machines are in fact on a Workgroup by default. Which Workgroup and hence which machines you see on the network is determined by the Workgroup name. Machines with matching Workgroup names are on the same Workgroup. By default, Windows machines have a Workgroup name of “WORKGROUP”.

A HomeGroup is an extension to Workgroups. All it does is just add special shares, often called “public shares”, to speed up the authentication process. The only difference between these kinds of shares is that public shares don’t require you to authenticate with credentials. When accessing normal shares (“Workgroup” shares) when on a HomeGroup, you will still be prompted for credentials if you try to access them.

These corrections don’t invalidate the steps I posted in post #9. Just remember that you don’t need users A, B, C, or D to exist on the machine/s you’re intending to use to connect with.

Edit: Also, custom shares are not “Everyone, Full” by default! But you should still make them so. The default shares that come with Windows are.

toppinglift · 08 Apr 2017

I tried post #9 instructions and could not make them work. I am quoting them below for the convenience of anyone following the thread:

The following is what needs to be done.

Make local users A, B, C, and D, and assign a password to each (they must have passwords for you to authenticate remotely with).
Create a share through Explorer. Because the share permissions are by default set up how we want it to be, i.e. it includes “Everyone, Full”, they can be ignored as we won’t be controlling access this way. Go to Properties -> Security.
The Properties -> Security pane represents the NTFS permissions. Here, you control access by including or denying users or group appropriately. In this case, you’ll be specifying the local users you’ve setup in step 1.
Click “Apply” or “OK”.
Test share access.

Below is what I did to test the share access. The No. 1 settings granted everyone access. The No. 2 settings granted no user access, including the user on the "white list.":

Setting "Everyone" in File Sharing to Work with Specific Users-post-9-reply.png

Pyprohly · 09 Apr 2017

That should be correct. When clicking that machine in the Network view of Explorer on another machine you’ll be prompted for credentials. Enter “Allen_T450” then the password for that account (it must have a password set) and you should be through.

Post back error messages if anything fails.

toppinglift · 09 Apr 2017

Below is the error message I get if I do Setting #2 under Post #12 ("Everyone" listed under Advanced Share; "Everyone" removed under NFTS, and white listed user "Allen T-450" added, all with full permissions)

Setting "Everyone" in File Sharing to Work with Specific Users-network-error.png

In addition, no other user on the network can access the folder.

ON THE OTHER HAND, if I change the NFTS permission by removing the white listed user Allen T-450 and adding "Everyone", then the entire network can access the folder (see setting #1 in post #12). This is where I have been for the last few months. Everything else in the network works well--I've had no problems as long as I keep to setting #1, but then I can't control access because everyone can access the folders. Thanks.

Pyprohly · 09 Apr 2017

Now that you’ve set up access permissions correctly, it is up to you to authenticate using the right credentials.

In the case of your screenshot, you’re accessing the share “fcsc” on computer B with the wrong credentials from computer A. You can flush the cached credentials on computer A at any time by entering the below command in a PowerShell terminal. After doing this you should be prompted for new credentials upon accessing computer B’s shares. Make sure all Explorer windows are closed.

Code:

Restart-Service Workstation -Force

Also make sure “Password protected sharing“ is enabled on computer B. This should be on my default.

toppinglift · 10 Apr 2017

Hi Pyprohly,
I thought you were right that it may be a credential problem where the accessing pc had the wrong or inaccurate credentials, but I was very careful and mirrored user names and passwords for BOTH the PC acting as a server with the shared file (PC "B") and the client PC (PC "A"). Password protected sharing is enabled on PC "B". Unfortunately, I can't make the change.
Below is the screen shot after the changes you suggested to be done in Powershell. Is there any other way to get a prompt for credentials from PC "B"?

Setting "Everyone" in File Sharing to Work with Specific Users-powershell_credentials.jpg

Pyprohly · 10 Apr 2017

Restarting a service is an administrative action.

I posted the command so you can renter credentials if you had previously entered them incorrectly, but so far you haven’t mentioned or questioned much about what needs to be entered into this prompt when it displays which makes me wonder whether your machine ever gave you this prompt at all. Are you familiar with the credential prompt I’m talking about? If there’s something I’ve mentioned you’re unsure of, please ask.

Cached credentials are volatile. Rebooting should also clear them effectively.

toppinglift said:

I was very careful and mirrored user names and passwords for BOTH the PC acting as a server with the shared file (PC "B") and the client PC (PC "A").

That’s okay, but I’ve rectified that creating identical accounts across computers isn’t actually necessary and won’t contribute to your success in accessing the share.

toppinglift · 10 Apr 2017

Ok, so I've solved part of the mystery--and you gave me the help to do it, but I am still wading through a lot of manure. You focused me on my credentialing. I know you now say it's not necessary to mirror identical accounts and passwords across machines for success--but what happens if you don't have the right accounts and passwords in the first place? I didn't know this, but this YouTube video (link below) explains that if any of the PC users CHANGED their user names and passwords from the first time they set up their account, the PC with the shared file only uses the ORIGINAL name of the user to grant permission NOT the CHANGED name.

This blew my mind--it is so counter-intuitive, but I tried it. You input (without the quotes) "control userpasswords2" in the Run dialog box and you can get the ORIGINAL user name, not the changed user name. I can't try it now on shared file permissions to see if it would work, but I did a quick remote login into the PC and that worked with the original name of the accessing PC that I obtained from "control userpasswords2". Here is the link to this video for any readers of this thread:

Logon failure unknown username or bad password | (Windows Workgroup Fix) - YouTube

Now my problem is, I have all the wrong credentials on the PC with the shared file, and I am not sure what will happen if start deleting them using "control userpasswords2" and re-input them with the correct credentials. I am not sure it that is the right place to start doing all those changes. Currently, all the shared files are working because I have "Everybody" in the NTFS permissions.

Pyprohly · 11 Apr 2017

Do you or do you not get prompted for credentials when accessing shares or network workstations?

Did you change the account’s name on PC B?

That video isn’t relevant. As far as I’m aware, “Logon failure” is not your error.

toppinglift · 13 Apr 2017

Hi Pyprohly,

Thanks for your patience--I understand what you are saying. I think in our situation, where all the user names had been changed in the last year--the Users' PC's (PC "A") are sending the legacy User names to PC "B" instead of the changed User names. PC "B" had been configured with User accounts using the changed User names, NOT the legacy names, so there is a conflict and permission will be denied. This is revealed by using in Run "control userpasswords2". The credentialing problem, which you detected and highlighted, may be the source of the difficulty, but I have not had time to test it.

I will test it more this weekend. If it works, then the Aussies are heroes.

If it doesn't, then I have to go back to the drawing board and start again.