Restricting shares on a network

[gerbil]

Trying to restrict some share access on a simple network I made a syntax error or two, and googled net share and hidden share. This sort of thing came up many times:
"to create a hidden share enter...
net share concfgC:\ /GRANT:username, FULL
" ...and was touted as a hack! and totally mischievous stuff.
Well, I thought you created "hidden shares" by using sharename$.... and so the cmd would be...
net share hideyhole$=D:\secretstuff /GRANT:username, FULL
-which, of course, works. And looks silly, and isn't very hidden.
The first cmd just throws, obviously, syntax error. So what is this concfg thing? It's variously in posts also as concfg and concfg". Also, C:\ will already be shared as C$, so that also won't run.
What's going on? Oh, I don't need help on the initial thing, creating the restricted share.

[Reverend Jim]

You are correct in that appending $ to the share name makes it a hidden share, however all shares are by definition restricted, it's just a matter of to what degree. You control

1. who has access to the share
2. what access rights they have

If you want to assign users and access rights through the command line you should do that using icacls, otherwise you can do that using the GUI by running fsmgmt.msc, selecting Shares in the tree then going to the Share Permissions tab of the properties for the given share.

One very strong warning about using icacls - the biggest mistake novices make is not using the /e parameter. Using /e edits the existing access control list. If you leave out /e you replace all existing rights with the new rights. This could leave you locked out of a folder if you are not careful.

I have no idea what concfg is.

[gerbil]

Thanks, Jim. I'm coming up to speed on W7, and it is not helpful to find what i suspect is simply a mob of parroted, incorrect posts on a subject. I got trapped by the coding monster in Daniweb... that should be... "net share concfgC:\ /GRANT:username, FULL" ...Oh, bloody hell, it's all over me, the pest...... net share concfgSTARC:\ /GRANT....
But concfgSTAR means nothing, either, or even less - you cannot use a "*" in a sharename. The other thing is, you cannot add a user to a share when the share access is already Everyone, Full. Or create a new share to that same target. Some code they are putting up.
When you create a volume a hidden share is created to that volume, eg P$ for volume P: So directly editing via cmd the access to that share is naughty?
I knew about the /e parameter; I've seen quite a few posts here about lock-outs originating from that little thing.

[Reverend Jim]

Technically, the default hidden shares are known as administrative shares. I used to do development/support for the system operators in our control centre (Manitoba Hydro). Because I was a sysadmin with complete access I would always use the admin shares to access their computers from my desk.

If the share is already Everyone:Full you can still add users. For example, let's say you have a share for which all employees have full access (unlikely but let's go with it). If you bring in someone from outside temporarily you might want them to have read-only access, or you may want to lock them out entirely. In that case you can add that user into the list (using fsmgmt.msc) and use the Deny column to restrict their access. You might even create a domain group called TempEmployees and use that in the Deny column instead. That way, just by adding the temp names into the TempEmployees group they automatically get the restricted permissions. At least that's how I remember it. I've been retired since 2008 and things may have changed since then.

As a rule you want to do as little mucking around with the ACLs (access control lists) as possible. That's why it is preferable to specify group names in the ACLs rather than individual users. Another rule is to grant as few permissions as possible. In reality you'd likely never use Everyone:Full except in limited circumstances.

[JorgeM]

Just to elaborate some more on Share and NTFS permissions since it was brought up... It's best practice that when you create a Share, go ahead and apply Everyone:Full Control (keep reading). Then restrict the access using NTFS permissions (the access control list). This works best because when you apply Share and NTFS permissions, the most restrictive permissions will apply to the user.

So say Joe belongs to the Sales group and you apply the filling permissions:

Share: Everyone-->Full Control
NTFS: Sales-->Read

Joe will only be allows to read.

I have more info and examples if you are interested: Share vs NTFS Permissions

[Reverend Jim]

I disagree. By your scenario anyone who is not in Sales will have full permission. That includes the right to modify existing permissions. Not a good idea because then you have to keep track of who you don't want to have access and that's a lot more difficult then granting access to those who need it.

[JorgeM]

I respectfully disagree with your response. Users that are not members of the Sales group would not have any access because only the "Sales" group is explicitly listed on the NTFS access control list in the example I provided.

In my example, the Share permission only lists the everyone group and the NTFS tab would only list the Sales group.

Feel free to set up a test to validate.

[Reverend Jim]

Upon rereading your post and trying to recall techniques I haven't used since 2008 I do believe you are correct. Apologies.

[JorgeM]

No apologies needed, my only intent is to ensure that others that come a cross this thread get correct information. I've posted misinformation in error in other threads as well. No worries.

[gerbil]

Jim, your first example about adding users with different levels makes sense; I had not tried that. As does keep ing it simple with ACLs. And Jorge, your example explaining the permissions hierarchy was good.
Thanks to both of you... a bit off my track but now I know more.
NB. concfg* chatter is web trash.