Windows Networking, help me understand.

[superboyac]

I've been messing around with Windows networking for the past two weeks.  So many things I don't understand, and seemingly so many inconsistencies in the way things work that look exactly the same from the setup point of view.

Workgroup vs. Homegroup:
I initially was using Homegroups (Windows 7 and Windows 8 machines).  Then, it told me it can't share the root of a drive.  So I disabled homegroups and now use normal file sharing.

Some folders share, some don't:
Some folders from the same computer get shared properly, I can see it from the other and access it no problem.  Others don't.  Same permissions, same everything.  The one that doesn't work is a root drive, but I don't understand why that doesn't work.

Full control?
On some folders, I have full control for all users (everyone, administrators, guest).  Yet when I connect it is read only.  So whether someone has full control or read only...it really only works in read only.  I don't understand this.

[40hz]

Workgroup vs. Homegroup:
I initially was using Homegroups (Windows 7 and Windows 8 machines).  Then, it told me it can't share the root of a drive.  So I disabled homegroups and now use normal file sharing.

-superboyac (October 14, 2013, 02:23 PM)

A Homegroup is basically a workgroup with preconfigured security settings and some additional restrictions. (Not quite, but close enough for all practical purposes.) It was designed to allow easy and relatively secure resource sharing in a non-critical network such as home sweet home. It's not very flexible. And IMHO, not even worth using.

A Workgroup is your basic peer-to-peer setup designed for use with 20 or less PCs. Workgroups are a pain because there's no centralized access control. You need to set up a user account on each computer you want access to in a Workgroup. It's not like a domain where you could just set up one set of credentials for yourself and be allowed access to every computer on the network.

Workgroups have default shared folders. If you can log onto machine-A as User-1, you have relatively full access to everything on machine-A. If you're logged onto machine-A however, you only have access to the default shared drives on machine-B unless you set up User-1 as a user on machine-B as well.

There is no central point (i.e. domain controller) that all the machines on your workgroup network can query to see who is authorized to access their resources. (That feature is provided by a domain - not a workgroup.) Access is controlled locally by each machine in the workgroup. Access is controlled by a domain controller in a domain.

Hope that clarifies things.

[Stoic Joker]

Workgroup vs. Homegroup:
I initially was using Homegroups (Windows 7 and Windows 8 machines).  Then, it told me it can't share the root of a drive.  So I disabled homegroups and now use normal file sharing.

-superboyac (October 14, 2013, 02:23 PM)

While I share 40hz's dim/purist view of homegroups ... Their purpose is to step around the issue of having to match credential between machines in a workgroup (a.k.a. the pinnacle of Administrative overhead oriented nightmares). Homegroups have a singular key that is shared between all member machines allowing access regardless of logged on user's existence on the target machine.

Never share the root of C:, it's horribly bad form and make BOFH's cringe, wince, and frequently homicidal.

Note: the professional version of any Windows client OS (workgroup or domain) will have a hidden administrative access only share called C$ if need be. Creating another one is just begging for disaster.

Some folders share, some don't:
Some folders from the same computer get shared properly, I can see it from the other and access it no problem.  Others don't.  Same permissions, same everything.  The one that doesn't work is a root drive, but I don't understand why that doesn't work.

-superboyac (October 14, 2013, 02:23 PM)

They have literally written books about this one; file permissions vs. share permissions. You'll need both to get write access to a Windows share.

Full control?
On some folders, I have full control for all users (everyone, administrators, guest).  Yet when I connect it is read only.  So whether someone has full control or read only...it really only works in read only.  I don't understand this.

-superboyac (October 14, 2013, 02:23 PM)

Rule of thumb 101: Never grant Full control to anything for any reason...ever. Seriously, this is another 5 star bid for tragic consequences. Always administer shares from their own hosted root.

Share permissions need only Change for Users.
NTFS (file) permissions need only Modify for Users.

By users I mean only the specific ones that are to be allowed access to said share.

Full Control permission grant the ability to create shares inside of an existing share, and/or the ability to modify file permissions inside a target share. Both have ended badly every single time I've seen it ... Possibly due to the fact that this perilous configuration had much to do with why I got called there to start with...

[4wd]

Just to follow on from SB's query:

What's the difference between, (this only applies to Server and Pro+ versions AFAIK):

The settings you get when you right-click on a folder, Properties->Share with->Specific people and if you go to the File Share Management Console, (fsmgmt.msc) ?

ie. Under Properties->Share with->Specific people
Windows Networking, help me understand.

Under fsmgmt.msc:
Windows Networking, help me understand.

I would have expected to see the same users allowed under both but ... 

I'm guessing this is the difference between Users and NTFS permissions ?

[Vurbal]

The "simple" (and not entirely functional) version goes like this. You have 2 sets of permissions:

1. NTFS (file system) permissions which are the more granular of the 2.

2. Share permissions which are cruder.

When you connect to a share in theory the 2 sets of permissions are combined (sort of a logical OR) and you get whichever rights are greatest. The exception is No Access which trumps everything. However since you have Read permission we can safely rule that out.

In addition to that sometimes Windows will prevent you from doing anything but reading a file (or listing a directory) if you are not the owner - even if you definitely have all the requisite permissions. Assuming you're talking about data folders. This applies even when you're just dealing with local (NTFS) permissions.

Oh yeah, and if you're dealing with a domain setup instead that potentially opens up a whole other can of WTF was Microsoft thinking?
Finally if UAC is turned off (all the way off as opposed to the lowest standard level) on the computer you're accessing the share from you will be limited to read access. If you want to execute a file you will have to copy it to a local drive. I've had that just happen all of a sudden when rebooting after installing a Windows update.

[Stoic Joker]

I'm guessing this is the difference between Users share and NTFS permissions ?

-4wd (October 14, 2013, 05:57 PM)

(ftfy)

The top one is the New version of (XP's) Simple File Sharing. So it's trying to combine file and share permissions into one thing. The bottom one is the Share Permissions only tab of the Advanced Sharing options.

I tend to avoid option 1 (the top one) like a plague out of reflex, but I spend most of my time doing business systems and therefore need the detailed granular access control afforded by the advanced options.

[Stoic Joker]

When you connect to a share in theory the 2 sets of permissions are combined (sort of a logical OR) and you get whichever rights are greatest

-Vurbal (October 14, 2013, 06:07 PM)

While both Share and NTFS permissions are cumulative independently, they don't overlap (e.g. they are mutually exclusive). If you create a share, and give the administrators group the share read permission only. Even if they are the owner and have full control NTFS permissions of a folder and it's contents ... When accessed through that share they will have read permissions only.

You need both to be explicitly or implicitly (via inheritance and/or group membership) assigned to you with matching (w/r) permissions to allow manipulation of the target files.

[CWuestefeld]

The top one is the New version of (XP's) Simple File Sharing. So it's trying to combine file and share permissions into one thing.

-Stoic Joker (October 14, 2013, 06:16 PM)

So that's what "simple file sharing" is doing? I have to admit that I always found it confusing -- NOT simple -- and so have avoided it since it came out.

[4wd]

Thanks guys - so I guess the best idea is to just ignore the Properties->Share with dialog and just use Advanced Sharing.

fsmgmt.msc is crippled under Home Premium, (you can't add shares or edit shares), which seems rather inane if you get the same functionality going through the Properties->Sharing->Advanced sharing dialog.

[superboyac]

Wow, lots of good info here.  Ok...I've also been reading about it today.

Here's what I'm thinking: I want to try the domain way of doing things.  It's what I've been used to in the corporate world, and I find it easy. I've never set one up myself, that's the only thing.  So i don't know how hard or easy it is.  But after it's set up, I'm familiar with all the folder sharing and networking procedures.  hmm.

[CWuestefeld]

The thing about domains is that you need a domain controller. And getting that set up (and administered, with backups and everything) is a whole other skillset.

[40hz]

Domains are easier IMHO.

They're not hard to set up per se. Hit the option to use a domain during the server setup and it's done. Windows server sets up the domain controller (plus baseline security) and handles all the heavy lifting for you.

After that you just have to understand what a domain is (and follow a few commonsense guidelines when you create groups and assign permissions) and you're set to go. You can get as complicated, or keep it as simple, as you like/need to. A good book plus a few quality weeks of playing with, screwing up, and reinstalling will teach you enough to successfully use one in a home or soho setting. Enterprise use is another matter as CUW mentions above. But for small simple networks with one DC, Windows Server is about as easy as it gets.  

FWIW, a lot of what seems fussy or arbitrary in the Windows desktop suddenly makes a great deal of sense once wedded to a Windows server. In many respects you don't realize the full power of Microsoft's desktop until you link it to one of their servers.

[Vurbal]

The top one is the New version of (XP's) Simple File Sharing. So it's trying to combine file and share permissions into one thing.

-Stoic Joker (October 14, 2013, 06:16 PM)

So that's what "simple file sharing" is doing? I have to admit that I always found it confusing -- NOT simple -- and so have avoided it since it came out.

-CWuestefeld (October 14, 2013, 06:41 PM)

When the Microsoft terminology says simple you should read that as simpleton. As in the point is making it so even a simpleton (ie someone whose entire qualification to be a sysadmin is Microsoft's Dick and Jane certification manuals) can do it. To be honest the primary point is to make it seem like you don't need an experienced administrator because experience costs a lot more money than any server.

Whether you're running Windows or anything else that's simply not the case. The more you know, the more you are likely to deviate in various ways from the Microsoft roadmap (with NT 4 that included the sage advice to put your SQL Server in your DMZ because it didn't play well with IIS) and do things just as seriously and professionally as with any other system.

The fundamentals haven't really changed since before anyone here got into the profession. Once you figure out the right questions the answers become pretty easy to come by.

Domains are easier IMHO.

They're not hard to set up per se. Hit the option to use a domain during the server setup and it's done. Windows server sets up the domain controller (plus baseline security) and handles all the heavy lifting for you.

After that you just have to understand what a domain is (and follow a few commonsense guidelines when you create groups and assign permissions) and you're set to go. You can get as complicated, or keep it as simple, as you like/need to. A good book plus a few quality weeks of playing with, screwing up, and reinstalling will teach you enough to successfully use one in a home or soho setting. Enterprise use is another matter as CUW mentions above. But for small simple networks with one DC, Windows Server is about as easy as it gets. 

FWIW, a lot of what seems fussy or arbitrary in the Windows desktop suddenly makes a great deal of sense once wedded to a Windows server. In many respects you don't realize the full power of Microsoft's desktop until you link it to one of their servers.

-40hz (October 14, 2013, 07:42 PM)

I can't disagree with any of that, once again with the stipulation that the key is understanding the concepts and fundamentals going in. Once you've got that down all the tools are there for relatively straight forward implementation.

[Stoic Joker]

Domains are easier IMHO.

They're not hard to set up per se. Hit the option to use a domain during the server setup and it's done. Windows server sets up the domain controller (plus baseline security) and handles all the heavy lifting for you.

-40hz (October 14, 2013, 07:42 PM)

+10 I'm rather fond of saying that Active Directory has only two states of being, DNS is configured and working properly, and shit hit the fan. The defaults work just fine ... Okay, lack of a RDNS zone bugs me...but its absence is harmless...it just really bugs the crap out of me.

[CWuestefeld]

Active Directory has only two states of being, DNS is configured and working properly, and shit hit the fan

-Stoic Joker (October 15, 2013, 06:46 AM)

+1

That is the thing. Getting it set up and running and normal isn't a big deal. But wait until 5 years down the road, when that machine's dying and you need to get a new DC handling the domain. I know this is possible -- corporations do it all the time -- but I've been completely unsuccessful in figuring out how to completely replace a DC.

[x16wda]

Replacing a DC is no problem really, just build a fresh server and run dcpromo to make the new one and then dcpromo the old one to remove it.  Just make sure to have DNS installed on the new box before promotion and point it to the old one for DNS, then when the new DC is happy (always seems to take an extra reboot for me) point everything to it for DNS instead before decommissioning the old one.  I haven't worked in a single-DC environment but I'd set the new box to be a global catalog too.

Of course if you're replacing it after 5 years you'd want to update the forest and domain schemas to the latest.

Much nicer now than the days of NT4 domains.  (Though we found the Upromote utility late in the game, that makes it a little easier...)

[CWuestefeld]

Replacing a DC is no problem really, just build a fresh server and run dcpromo to make the new one and then dcpromo the old one to remove it.  Just make sure to have DNS installed on the new box before promotion and point it to the old one for DNS, then when the new DC is happy (always seems to take an extra reboot for me) point everything to it for DNS instead before decommissioning the old one. 

-x16wda (October 15, 2013, 08:35 AM)

So now you've got to understand DNS, too, including how to properly configure your own domain, and how this interrelates with ActiveDirectory -- it's not as easy as just pointing to your ISP's DNS. And this is the part that I was never able to get to work properly (this may have been complicated by the fact that I own my own domain name as well, I use that for my email address, so I needed to be able to get name resolution to hosting provider's mail server that has my domain name).

I actually thought NT4 domains were simpler. Back then, you had a PDC and some set of BDCs, and it was perfectly clear which was which. So to replace an old PDC, you'd just bring up a new BDC, get him acquainted with the old PDC, and then promote him.

[Stoic Joker]

Replacing a DC is no problem really, just build a fresh server and run dcpromo to make the new one and then dcpromo the old one to remove it.  Just make sure to have DNS installed on the new box before promotion and point it to the old one for DNS, then when the new DC is happy (always seems to take an extra reboot for me) point everything to it for DNS instead before decommissioning the old one.  

-x16wda (October 15, 2013, 08:35 AM)

So now you've got to understand DNS, too, including how to properly configure your own domain, and how this interrelates with ActiveDirectory -- it's not as easy as just pointing to your ISP's DNS.

-CWuestefeld (October 15, 2013, 08:56 AM)

Actually it is. (assuming single server for simplicity) In an AD domain the DC handles DNS period. All clients point to, and only to the DC. External lookups are to be handled by forwarding either to the default internet root servers, or to the configured forwarders. The ISP's DNS servers can be configured as forwarders but personally I prefer OpenDNS. If the ISP's DNS servers appear anywhere else in the configuration problems will ensue.

I usually just let dcpromo handle the DNS installation on the fly (for Server 2000/2003/2008 - Server 2012 is a bit different..). Then verify the FSMO roles made it over safely and down the old box. Reboot the new server to make sure it can come online with out issue, and if the event logs are clean ... Spin up the old server one more time to demote it.

And this is the part that I was never able to get to work properly (this may have been complicated by the fact that I own my own domain name as well, I use that for my email address, so I needed to be able to get name resolution to hosting provider's mail server that has my domain name).

-CWuestefeld (October 15, 2013, 08:56 AM)

having the same public and internal domain name is a bit of a no-no. But in a pinch you can just add the A records for www, mail, etc. to the internal DNS server with the external IP addresses.

I actually thought NT4 domains were simpler. Back then, you had a PDC and some set of BDCs, and it was perfectly clear which was which. So to replace an old PDC, you'd just bring up a new BDC, get him acquainted with the old PDC, and then promote him.

-CWuestefeld (October 15, 2013, 08:56 AM)

The PDC (emulator) is still there an reasonably easy to find: netdom query fsmo

[Vurbal]

Replacing a DC is no problem really, just build a fresh server and run dcpromo to make the new one and then dcpromo the old one to remove it.  Just make sure to have DNS installed on the new box before promotion and point it to the old one for DNS, then when the new DC is happy (always seems to take an extra reboot for me) point everything to it for DNS instead before decommissioning the old one.  

-x16wda (October 15, 2013, 08:35 AM)

So now you've got to understand DNS, too, including how to properly configure your own domain, and how this interrelates with ActiveDirectory -- it's not as easy as just pointing to your ISP's DNS. And this is the part that I was never able to get to work properly (this may have been complicated by the fact that I own my own domain name as well, I use that for my email address, so I needed to be able to get name resolution to hosting provider's mail server that has my domain name).

I actually thought NT4 domains were simpler. Back then, you had a PDC and some set of BDCs, and it was perfectly clear which was which. So to replace an old PDC, you'd just bring up a new BDC, get him acquainted with the old PDC, and then promote him.

-CWuestefeld (October 15, 2013, 08:56 AM)

I was clearly too tired when I wrote that - however when you're accessing via a share the 2 permissions aren't entirely separate - it's the most restrictive of the 2 that applies - more like a logical AND. The least restrictive part is when you have 2 sets of either Sharing or NTFS permissions like from your user and group or multiple groups.

The inheritance part is definitely where it can get particularly tricky, at least WRT non-system folders. That's one area where I find Posix ACLs vastly superior since you can change the inheritance mask (inherited acl) for a single user or group without blocking inheritance altogether.

Since my wife and kids use my computer from time to time I always start with extremely restrictive NTFS permissions on the root of my second hard drive and have a User folder where each of them has their own folder with full access. Then another folder off the root they all have most permissions (not Delete or Change Permissions) and a Temp folder off the root where everyone gets full control of the contents but not the folder itself.

The other oddball that can throw a monkey wrench into the works is using reparse points. Junction points and symlinks have separate permissions from the original file or folder and inheritance is based on where the junction or link is, not the file system object it references. So, for example, you can grant Write access to a folder under Program Files without changing the permissions or inheritance of the original. Just create a symlink to the folder somewhere else and it inherits from the path where the junction or symlink is located.

But not always. Depending on the Windows API call used a reparse point may be dereferenced and the context of the target object used instead. To make matters even more complicated junction points can get treated differently than symlinks in those cases. The easiest way to see that in action is to put them into Libraries. If you put a symlink in a Windows Library it gets dereferenced and the original location is actually added. If you put a junction point it gets added like any other folder.

While not related to permissions per se, that makes it a real PITA to add a network location to a library. That may even be the point although that would be stupid. Especially since you can get around it by creating a regular folder, adding it to a library, then deleting the folder and creating a symlink with the same name. Now the target of the symlink, network location or not, is in the library and can be accessed accordingly.

[Stoic Joker]

You still a bit tired there V? Because you quoted the wrong post.


Either way, I hear Ya man!

[Stoic Joker]

While not related to permissions per se, that makes it a real PITA to add a network location to a library. That may even be the point although that would be stupid. Especially since you can get around it by creating a regular folder, adding it to a library, then deleting the folder and creating a symlink with the same name. Now the target of the symlink, network location or not, is in the library and can be accessed accordingly.

-Vurbal (October 15, 2013, 01:00 PM)

It's the indexing that queers the deal there. If you make the folder available offline, it adds to a library just fine because the system will then be able to index locally via the CSC.

[40hz]

+10 w/Stoic's observation on AD and DNS within the context of Windows AD.

Half the new customers I get (who have a Windows server) come in with an AD problem because somebody in their organization decided to "tweak" or "tune" the DNS settings after the fact.  

Unless you really know what you're doing, and have a very specific and unusual set of network requirements, allow Windows to setup and configure AD and DNS. Then leave it alone. If you really do know what you're doing, you already know you won't need to futz with it unless you're in a very large enterprise, SaaS, or e-commerce setting.  

Rule of thumb: for your basic single-server/home/soho network - let the built-in Microsoft wizards do their job. You'll be a lot happier - and have a correctly running installation - if you do.
 

[Vurbal]

While not related to permissions per se, that makes it a real PITA to add a network location to a library. That may even be the point although that would be stupid. Especially since you can get around it by creating a regular folder, adding it to a library, then deleting the folder and creating a symlink with the same name. Now the target of the symlink, network location or not, is in the library and can be accessed accordingly.

-Vurbal (October 15, 2013, 01:00 PM)

It's the indexing that queers the deal there. If you make the folder available offline, it adds to a library just fine because the system will then be able to index locally via the CSC.

-Stoic Joker (October 15, 2013, 01:12 PM)

Just distracted mostly. I can only focus on one thing at a time and that's rounding up. 

[Stoic Joker]

While not related to permissions per se, that makes it a real PITA to add a network location to a library. That may even be the point although that would be stupid. Especially since you can get around it by creating a regular folder, adding it to a library, then deleting the folder and creating a symlink with the same name. Now the target of the symlink, network location or not, is in the library and can be accessed accordingly.

-Vurbal (October 15, 2013, 01:00 PM)

It's the indexing that queers the deal there. If you make the folder available offline, it adds to a library just fine because the system will then be able to index locally via the CSC.

-Stoic Joker (October 15, 2013, 01:12 PM)

Just distracted mostly. I can only focus on one thing at a time and that's rounding up. 

-Vurbal (October 15, 2013, 03:42 PM)

hehe me too ... I multitask about as well as statues dance.

[superboyac]

Hmmm...one minor complication...I need a Windows Server flavored OS to create a domain.  So I need to make a new machine?  Or run one on a VM?