Do not allow domain computers to communicate with each other

Our domain consists of around 60 computers. I have been tasked with making sure that Windows 10 workstations cannot communicate with each other. My manager asked that I create static routes so that computers can only communicate with the network printers, file server, DC, and access the Internet.

Since all of theses computers are on the same network I don't believe static routes are going to prevent these computers from seeing each other. What is the best way to allow computers on the domain to use network resources, but not communicate directly with each other?

Solution 1:

If you have a switch that supports it, 'protected ports' for cabled connections or 'client isolation' for access points on Wi-Fi can help you eliminate traffic between hosts in the same Layer-2 network.

For example, this is from Cisco switch manual:

Protected ports have these features: A protected port does not forward any traffic (unicast, multicast, or broadcast) to any other port that is also a protected port. Data traffic cannot be forwarded between protected ports at Layer 2; only control traffic, such as PIM packets, is forwarded because these packets are processed by the CPU and forwarded in software. All data traffic passing between protected ports must be forwarded through a Layer 3 device.

So if you don't intend to transfer data between them, you don't need to take action once they are 'protected'.

Forwarding behavior between a protected port and a nonprotected port proceeds as usual.

Your clients can be protected, DHCP server, gateway, etc. can be on unprotected ports.

Update 27-07-2017
As @sirex pointed out, if you have more than one switches which are not stacked, meaning they are virtually NOT a single switch, protected ports won't stop traffic between those.

Note: Some switches (as specified in the Private VLAN Catalyst Switch Support Matrix ) currently support only the PVLAN Edge feature. The term "protected ports" also refers to this feature. PVLAN Edge ports have a restriction that prevents communication with other protected ports on the same switch. Protected ports on separate switches, however, can communicate with each other.

If that is the case you would need Isolated Private VLAN ports:

In some situations, you need to prevent Layer 2 (L2) connectivity between end devices on a switch without the placement of the devices in different IP subnets. This setup prevents the waste of IP addresses. Private VLANs (PVLANs) allow the isolation at Layer 2 of devices in the same IP subnet. You can restrict some ports on the switch to reach only specific ports that have a default gateway, backup server, or Cisco LocalDirector attached.

If PVLAN is spanning over multiple switches, VLAN trunks between the switches should be standard VLAN ports.

You can extend PVLANs across switches with the use of trunks. Trunk ports carry traffic from regular VLANs and also from primary, isolated, and community VLANs. Cisco recommends the use of standard trunk ports if both switches that undergo trunking support PVLANs.

If you are Cisco user, you can use this matrix to see whether your switches support the options you need.

Solution 2:

You could do this, if you did something as horrible as make 1 subnet per client. This would be a management nightmare.

The Windows Firewall, with appropriate policies, will help with this. You could do something like Domain Isolation, but even more restrictive. You could enforce rules per OU, with the servers in one OU and the workstations in another. You'd also want to make sure that printers (and servers) are not on the same subnet as the workstations to make this simpler.

https://technet.microsoft.com/en-us/library/cc730709(v=ws.10).aspx

Regarding network printers - you could make this even easier if you didn't allow direct printing, but hosted the printers as shared queues from a print server. This has been a good idea for a long time for multiple reasons.

Can I ask what the actual business goal of this is? Is it to help prevent malware outbreaks? Keeping the big picture/finish line in mind helps define requirements, so that should always be part of your question.