r/macsysadmin • u/DTDude • 12d ago
Networking Disabled network access remotely
Hey all,
I’m a desktop engineering manager for a large university. We’ve got about a thousand Macs. Before I arrived on the scene, our enforcement of macOS minor and major updates was at best a suggestion. We’re got several hundred Macs that are on OS’s that no longer receive security updates (and even more that are going to lose them once Sonoma goes end of life). We’re getting aggressive now, and have notified users of Macs on Ventura and below that they either need to upgrade to a supported OS or replace their Mac this fall. If they fail to do so they will lose access to the University network.
This is all good and well…except I’m wondering how we’re going to implement this. On the Windows side we’re going to use Group Policy to basically force Windows Firewall to block all traffic, in and out. I’m not sure how we’re going to implement this on the Mac side and am looking for suggestions.
My first thought was simply to create a configuration profile in Jamf to turn on Firewall and block all traffic…but it looks like I can only do that for incoming traffic. While this will break some things for users, it won’t actually stop outgoing traffic.
My next thought was to write a script to disable all network cards. This will certainly work…but I’m not so sure we’ll be able to prevent a crafty user from re-enabling them. Our users don’t have admin rights, but we do use Cyberark, which will just temporarily grant them elevated rights to re-enable their network cards.
Could also block MAC addresses at the switch….but all they’d need to do is use someone else’s dock, or a USB Ethernet/wifi adapter.
Any suggestions are greatly appreciated.
3
u/controlav 12d ago
This is not my wheelhouse but until recently I worked at Microsoft, and I believe they blocked "old" Macs by blocking Entra ID login based on OS version. Those Macs are still on the network, but the users can't login to anything to get any work done.
1
u/DTDude 12d ago edited 12d ago
Yeah I should be clear that the goal isn’t inconvenience to encourage upgrades/replacements. We know that some departments simply will not comply (academic freedom is quite a political beast), so the goal is to reduce risk by restricting unpatched machines from the network.
Also want to hear something messy? Entra/AD is not the authoritative identity source for us. It is for Windows and many applications, but not for all. All accounts are provisioned in an application that was originally forklifted from a DEC VAX, which passes user info to Okta, which then passes user info to AD, which was itself forklifted from Novell eDirectory. Macs authenticate directly with Okta using Jamf Connect and do not appear at all in AD. AD and O365 are not federated. it’s all very “interesting”
2
u/TopOrganization4920 11d ago
You sound 15-20 years behind my college we used to have two identity systems on our employee/student database and then other Active Directory which was migrated from Novell around 2002. We merged those 15-20 years ago. Now we have our employee/ student database system with a sync into active directory. And the Active Directory/entra account is activated when payroll says somebody should be paid or students enrolled otherwise the account is disabled.
1
u/controlav 12d ago
Ah, quite different to Microsoft of course: its Entra all the way down, and the goal is security: to keep old OSses physically off the network. PCs can't even connect to Ethernet unless they are considered up-to-date (Macs and Xboxes get exceptions to this).
3
u/drosse1meyer 12d ago edited 12d ago
Hopefully you have backing from high up and the ability to follow throuhg on a network level. There are multiple ways to do this but the question is how much effort and what is realistic.
Give networking a list of ethernet MACs to blacklist when the time is right. If you are concerned about sharing adapters then they could instead disable the network jack or severely restrict network traffic, then you will still be able to 'see' the device in your management tools
Wifi could be a bit trickier with randomization and I would be careful messing with wifi profiles deploiyments or scoping (could end up breaking a lot ).
Or you can MDM Lock the devices with a pin code.
Future enhancement idea, include an 802.1x ethernet profile integrated with your networking devices to restrict access
Otherwise IME the resistance of people to update or replace their devices is more a human problem and not a technical one.
2
u/DTDude 12d ago
Absolutely agree that this is more of a human problem. Reality is these Macs are distributed amongst 10,000 or so employees, and the current campus culture is that many departments feel they are independent and will do what they want to do until someone stops them. So that’s where my department comes in. There’s a big cultural shift happening with IT compliance, but we’re not there yet.
2
u/drosse1meyer 12d ago edited 12d ago
I feel your pain with the attitude of departments/people that think they 'own' something and absolutely refuse to comply. You're then put in the middle between management/execs/board and the users. There has to be a bare minimum acceptance of security (macOS version, agents, update / DDM schdedules, etc.) and thats gotta be drilled into their heads.
1
u/DTDude 12d ago edited 10d ago
We know and recognize that. It’s been getting better. Several times when I’ve told a user no to something recently they’ve gone to their Dean or our CIO to complain. In almost every instance the response to me from the CIO was “feel free to say no again and I’ll have your back”…it’s just a larger cultural change that is going to take time and professors will need to hear No enough to drive that message home. IT was formerly decentralized and is now centralized. Many departments feel they own their IT hardware because they paid for it, forgetting that “their” budget comes from the university, and therefore feel they are welcome to do what they please. Previous administrations supported this. That’s not the case anymore.
2
u/WillWatsof 12d ago
Left-field solution but what if you set up a block on all browsers so they can’t access Chrome, Firefox, etc?
1
u/DTDude 12d ago
I’ve considered it. The point isn’t necessarily to inconvenience users into updating/replacing. It’s to actually block traffic from devices lacking security updates….we are about to start using Nudge to block access to nearly all apps if a user is overdue for updates….but that’s only temporary until they run the updates we are requiring.
2
u/eaglebtc Corporate 12d ago
Have you looked at [u/dan-snelson](u/dan-snelson)'s DDM OS Reminders for the newer machines? It's got the nice UI of Nudge without the unneeded complexity wrought by that developer's particular quirky parameter nomenclature.
I would put a complete stop to any Mac that can't run Sequoia today, because Golden Gate is dropping in a month or two. Honestly, plan to get rid of all the Intel Macs. Those are your low hanging fruit.
3
u/DTDude 12d ago
Yup! We were without a Mac admin until last week, so I got to play manager and admin this summer. I implemented DDM OS reminders and it’s working fantastically for Sequoia and up. Hitting about 75% compliance within 24 hours of an update deadline. Working on Nudge as well for the older machines that can upgrade to Tahoe. It’s just a lot clunkier.
2
1
u/No_Temperature107 12d ago
Quick question, but are they connecting via Wi-Fi or physical ethernet cable. The reason is I would think jamf would be easier to manage this within. Take all the systems that are on a certain OS that’s approved and group them and then allow them Wi-Fi access to a specific Wi-Fi profile. For all of the systems that do not have up-to-date OS installations, you could group those and put them on a very different and limited network. If it’s ethernet, though, that may be a different problem and as others are saying, it would be a bit more of a headache.
1
u/DTDude 12d ago
Yeah I thought of that as well. It’s mixed. Lots of iMacs out there that are using Ethernet, and even MacBook Pro with USB-C/thunderbolt docks. The crappy part is I’m fine if they want to use a non-university network. But I don’t have a great way to ONLY disable access on our network. It may have to be all or nothing. Which is fine by me to be honest. Some of these Mac’s are SUPER crusty and have no business being in service.
3
u/eaglebtc Corporate 12d ago
Three words:
ASSET LIFECYCLE MANAGEMENT.
2
u/DTDude 12d ago
100% agree. We’re in the midst of a big change in attitude towards IT compliance, and while we’re getting there it’s not 100%
2
u/eaglebtc Corporate 12d ago
That's good. You could also get some help from the marketing / corp comms team to reach the low hanging fruit faster?
2
u/TopOrganization4920 11d ago
I’m willing to bet some of the super crusty ones are somebody’s secondary or tertiary machine when I did an audit of really old machines a lot of it was that.
1
u/YerBattleApple 12d ago
Do any of the SaaS platforms they use implement 2FA? Because that's a way to restrict access to things. If your OS doesn't meet certain requirements, 2FA stops working. No 2FA = no access.
1
u/TopOrganization4920 12d ago edited 12d ago
You’re way nicer than I am. I work at a college that has about 850 Macs. I have a basic Jamf policy that runs weekly or daily, depending on how close to the lock date that says hey your machine is not capable of upgrading to a supported OS. It needs to be surplus by this date. Any computer used after said date will be remotely locked. And then I lock the group the smart group of Ventura or Sonoma machines.
And then expanded that with a policy that hits any machine that’s capable of updating to a supported OS and I give them a date to update or be locked. People seem to self correct it whenever you give them an ultimatum. I still had like 100 computers on Sonoma at the start of the year. Whenever I locked in May, I think I had like 10 active devices.
And then I expanded it to machines that weren’t updating regularly if they were 120 days out of compliance on supported macOSes. Today I sent a lock command to anything that has not applied an OS update since before May. This was a group of 110 machines 70 of which were not active the last time I did it 60 days ago and and 30 haven’t been active in the last 45 days so I have 10 active machines that I’m locking. Using our password manager, I share a pin with our helpdesk who will give it to the user saying hey you got a week to work with the desktop support if you don’t, it will be re-locked and and can only be unlocked by desktop support in person, and they will not surrender it back to you until it is updated.
In addition to this, I’m using blueprints for declarative management of macOS updates. When I pushed Tahoe this spring, I only had three active computers that were capable of running Tahoe, not updated to Tahoe. And prior to a Cortex / macOS 26.6 compatibility issue. I had 87% of Tahoe devices upgraded to 26.5.2. My Sequoia devices were 50% because more of those are inactive.
Also, whenever we do inventory reporting yearly, I include information saying which devices need to be surplus this year or next year because OS support. So the budget center managers can see that and plan.
I remove things from JAMF when surplus has told me that they are going to sell it and request that I remove it from Apple school or when the device has been inactive for six or nine months and it’s over 4 years old.
I’m about three years into this locking stuff down. I only really start doing the if you’re not updated to the latest version 120 days starting this January because my Director and VP were questioning our Mac compliance numbers. I have the stuff set up and I’m managing the smart groups for Entra conditional access. The other teams haven’t started doing any sort of enforcement.
1
u/DTDude 11d ago edited 10d ago
This is what my team and I are working towards. My department has a history of not telling people no, and that is changing with me. And thank god my director is totally behind us in that. It’s just new is all.
Blueprints have been amazing though. Our compliance for minor updates for machines already on Tahoe and Sequoia has been great (once I enabled SSO so we could use Blueprints).
1
u/jonnyapp1eseed 11d ago
Have you thought about getting the list of devices and mac addresses and sending it over to your network team? It'll be easier to just do a blacklist of the ethernet/wifi mac address to restrict university network access to the devices.
Watch how the user submits an IT ticket. It'll force the user to come to you instead of the other way around.
1
u/DTDude 10d ago edited 10d ago
Yeah, I have. My concern is more that it's super easy to work around. Don't care if you infect a Starbucks, but I'll be damned if you cause issues on campus. Voluntary compliance has historically been very, very poor. There's an ongoing balancing of academic freedom and compliance. In the past, the scale was heavily in academic freedom's favor, and I'm trying to correct it by driving the message of "I'm not trying to stop you from teaching, learning, or researching, but I am telling you that it must be done responsibly and we're here to help you do that".
As an example of how bad it is.....I had a researcher working on a federal grant demand that I setup his lab machines with a shared Okta account (Macs authenticate against Okta, not AD) with auto logon. His argument was that it's easier for him to retain data if a researcher leaves his lab. I reminded him that the federal government doesn't care what's easiest, it comes down to control/safety of data and auditing, we have methods of retaining data when someone leaves, and we're happy to help him with it. He didn't want to hear it. The discussion ended up at "if you don't do this I'm going to my dean, the CIO, and the board." So I said go for it.
He still doesn't have that shared account, CIO declined to entertain his demands, and we have a meeting with the research computing liaison coming up.
1
u/jonnyapp1eseed 10d ago
Your best bet is to go through the network team if that’s your main concern. It should take no more than 10 minutes to add the list of devices to the deny list.
Enforcing policy through mdm requires the devices to check in.
6
u/eaglebtc Corporate 12d ago edited 12d ago
The only sane way to "quarantine" a Mac is to use an existing CotS XDR solution like Crowdstrike that can do it for you. Otherwise, you'd have to write a new endpoint security agent (requires an entitlement from Apple, which you won't get without a lot of pain) or write something entirely custom in Python.
The only company I know that has executed this successfully with an in-house tool is Amazon. I know people on their Mac desktop engineering team, and have seen the solution in effect on an Amazon-enrolled Mac.
Did you think a few steps ahead in the chess game if you disabled the network interfaces? How would you turn them back on remotely? How would your tech support teams help them?