Damn it Shades, now you got me started thinking about junkyard design options.
First of all, a domain would be your best bet. An old PC with a properly configured Untangle (or similar product) might do the trick as well.-Shades
This actually has potential, but I'll come back to that.
However, if macguyvering is your only option, you could think about the following concept and steps to take (fooling your users a bit).
Make a virtual LAN on your switch that is not allowed internet access. I do hope you have a DHCP server that "parks" every known and unknown computer/smartphone" in that virtual LAN. Then there should be a script available to anyone that should suggest it has to run to grant internet access. That script should then assign (hard-coded) IP numbers in a different subnet with internet access on a first come, first serve basis. With 20 or so users that shouldn't be too hard. This script should also disable HomeGroup (as 4wd has shown you) and whatever else you need/want.-Shades
Okay, bear with me as I play devil's advocate/hacker here. An isolated VLAN isn't going to stop devices from accessing a hot spot. The DHCP angle also goes up in smoke due to it only having the ability to control devices that ask it for an IP address. The problem child hotspot has DHCP capabilities too. Then there is the 20 users x how many devices x at least 2 NICs = how many MAC addresses needing to be tracked? *Shudder*
Here's the problem, even if you completely lock down all but one network adapter/path there still is one. And that one can be modified to do what ever someone wants it to (like connect to multiple networks) if they know how. Now the really horrific part is that if the don't know how and try to give it a go anyway ... And/or follow a "reasonably tech savvy" friends advice they could easily end up creating a vortex that sucks the entire network into the Chinese petting palace universe. This scenario -which I've seen play out many times - with local administrative rights is really the biggest danger IMO.
HomeGroup membership at this point actually becomes rather irrelevant when the thing you're really trying to block is the (technically completely unrelated because it is on a totally different layer of the OSI model) TCP/IP network connectivity to the internet.
But we're not totally screwed ... Yet!
Untangle is based on Linux and its web-interface makes management tasks quite easy.-Shades
Getting back to the gateway fortification method. If the users do actually need to be connected to the internal network to perform their jobs. We can leverage that in our favor with a wee bit of static routing based shenanigans.
Here's the thing. Have you ever encountered a Cisco VPC client install that was setup by a hyper paranoid asshole that blocked access to everything except the remote target network? It's both infuriating to troubleshoot...and - being ephemerally session based - exactly what we want. Because all you really need is a DHCP server that will toss in a few rather restrictive static routes, and nothing the users do or try will allow them to get to anything while they are on the company network because the IP routing table won't allow it. Sure they can connect to anything, within a first hop broadcast zone ... But any attempt to go past that will - via the routing table - auto-magically fail.
And ultimately that is really what is needed. An environment that will transparently allow them just enough room to realize that they have failed...so that they give up and go back to work.
Recent Posts
Working with only a vague grasp of WTH that is...I'm going to guess that it doesn't really need to be in a rack ... Yes?
...Are you talking about this error popping up on a driver search??