Windows 10: Setting "Everyone" in File Sharing to Work with Specific Users

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)





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.

 

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[/quote]
Also make sure “Password protected sharing“ is enabled on computer B. This should be on my default.

 

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"?

 

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.

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.

 

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.

 

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.

 

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.*Biggrin If it doesn't, then I have to go back to the drawing board and start again.*cry

 

Meanwhile, I’ll take this moment to explain a few things.

Firstly, I’m grateful you mentioned control userpasswords2 because I previously didn’t know of a GUI way of changing an account’s SAM name other than creating a new account.

Updating a user account’s name is said to be a cosmetic change. The reason for this is as you’ve mentioned: if you change the name of an account you don’t use the updated name to authenticate, you must use the old name because this will be the SAM account name.

What’s happing here is that when you change the name of an account using the typical account renaming options offered through Settings or the Control Panel, you’re really only updating the “full name” property for that account and not the SAM name. The “full name” field is actually blank after creating a new account. Windows will use the “full name” field to display your user’s name if it is available, otherwise Windows will default to using the SAM account name when displaying your user account’s name.

The ADSI COM interface exposes user account properties and can be visualised with the help of PowerShell. The following is a representation of an account’s properties after a name change. The “Name” property is the SAM account name, and the “FullName” was initially empty.
Code: PS C:\Users\> [adsi]'WinNT://./Bob' | select * UserFlags : {513} MaxStorage : {-1} PasswordAge : {875756} PasswordExpired : {0} LoginHours : {255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255} FullName : {Bob the Builder} Description : {} BadPasswordAttempts : {0} LastLogin : {4/11/2017 11:55:22 PM} HomeDirectory : {} LoginScript : {} Profile : {} HomeDirDrive : {} Parameters : {} PrimaryGroupID : {513} Name : {Bob} MinPasswordLength : {0} MaxPasswordAge : {3628800} MinPasswordAge : {0} PasswordHistoryLength : {0} AutoUnlockInterval : {1800} LockoutObservationInterval : {1800} MaxBadPasswordsAllowed : {0} objectSid : {1 5 0 0 0 0 0 5 21 0 0 0 112 134 33 206 227 177 8 6 118 36 188 123 241 3 0 0} AuthenticationType : Secure Children : {} Guid : {D83F1060-1E71-11CF-B1F3-02608C9E7553} ObjectSecurity : NativeGuid : {D83F1060-1E71-11CF-B1F3-02608C9E7553} NativeObject : System.__ComObject Parent : WinNT://WORKGROUP/. Password : Path : WinNT://./New Properties : {UserFlags, MaxStorage, PasswordAge, PasswordExpired...} SchemaClassName : User SchemaEntry : System.DirectoryServices.DirectoryEntry UsePropertyCache : True Username : Options : Site : Container :[/quote] Interestingly, there is also a “Username” property, but this field seems to go unused.

I see clearly now that “Allen_T450” was not a user created for the purposes of this thread. You should have though; eliminate as many variables as possible.

 

Hi Pyprohly,
Thanks for the explanation--now it makes sense. It appears that what I stumbled upon--no genius here, just discovered it by Google searches--is a way to uncover the SAM name if the User name had been changed and no logs of the SAM name were kept. It appears to be impossible to set NFTS permissions properly unless you had the SAM name, but if you didn't--I believe you would be stuck like I was. Luckily, the <<control userpasswords2>> command reveals the SAM name of the PC even though the User name may have been "cosmetically" changed later.

So I went PC by PC and changed the user name through <<control userpasswords2>> which apparently let's you revise the SAM name. I then made sure that the credentials on the server PC matched the SAM names of the client PC's. Now the NFTS permissions work just as you said they would and I will be marking this issue SOLVED!.

But I do have two remaining questions:

1. What is a Pyprohly? (Google sheds no light on what that is).
2. Is there any trick to setting Group permissions? I thought I could just add a Group I put together under Computer Management to the Security tab NFTS permissions like individual user names, but it doesn't work for me. Thanks.

 

I’m glad a greater understanding has guided you to the solution.

Another quick, and more direct, way is to run the whoami command. Expanding the “%username%” environment variable (echo %username%) also works.

As, surely, a meticulously formed internet handle must be a thing?

It should. Groups don’t have phantom names like users, so try again.

 

I'll try the groups again, but I may be opening a new thread. We'll see.

I can see that, but it is so damn hard to remember its spelling when typing.

Another great shortcut!! Thanks.