DEP Enrollment Connecting to VPN

I'm curious to see what answers others have come up with too.

In many environments, this ends up being a chicken-and-egg scenario where X is a requirement of Y but Y is a requirement of X, necessitating a rethink/redesign of the perimeter security approach in ways ranging from having multiple perimeters with increasing requirements and sensitivity up to and including eliminating the perimeter and properly securing both device and network-accessible services.

We have a similar issue with chicken and egg. To get on the secure internal 802.1X, you have to get to the right portal to add your MAC address along with your user creds.

How we solve is to provide an enrollment network with more traditional wpa2 security to assist with enrollment but slap an ACL on it to only allow JSS and access to 17.0.0.0/8. Users do the enrollment dance and a profile comes down that assists the user to get on production.

This doesn’t solve your problem really as I’m assuming your JSS doesn’t face the outside and enrollment is completed off site.

It illustrates @milesleacy ’s post on how you have to plan your infrastructure. Maybe the answer might be to have your JSS face the outside to allow your enrollment but secure the JSS from direct console access on the outside.

Consider the Jamf 350 course (https://www.jamf.com/training/350/) for a good primer basis to secure an externally facing JSS

In this case the JSS would be external (JAMF cloud). The users are external. The certs and AD enrollment are behind the firewall. As near as I can figure, we need a secure connection at time of enrollment because the Mac asks for an account before enrollment kicks off. And since our accounts are all mobile, it doesn't know you exist.

Going to throw the whole why bind question in here.. we're also an AD shop but stopped binding a couple of years ago. We've been running Enterprise Connect for a year now. Works like a charm (as does NomAD)

Must easier to manage when external DEP enrolment is in play.

Users sets up locally, connects to VPN, logs into EC and grabs a kerberos ticket. Once thats done we have a profile they can grab from Self Service which grabs user certs from the CA and sets up 802.1X WiFi...

User only with this though so depends if you rely on machine or user certs for auth.

I was waiting for that question. Mandatory from the security department. Are you running mobile accounts? Another mandatory from security.

Ah, the old security dept...

I'd definitely ask the question why they think AD binding is more secure?

Machine binds and user logs in, mobile account created, Kerberos ticket generated. Computer and User certs issued.

Or

Machine doesn't bind, local account is managed by Jamf (probably more secure than a mobile account), EC or NomAD pulls kerberos ticket (NomAD can do your certs too) and user certs.

Jamf gives you control over the machines WAY more than AD ever will, there's zero security benefit to binding to AD apart from machine level certs. All the user based stuff can be generated in AD another more manageable way.

We're a Cyber Security company and AD binding for macOS isn't a requirement.

Old is the key word... If it's good enough for windows it's good enough for Mac's (tongue in cheek statement here). We are using the machine cert for wireless and soon to prove company owned. I don't defend their requirements but the I must abide. Heck I just got them to change Sharepoint to kerberos from NTLM.

Ah Sharepoint authentication bane of my life... why do the mac guys keep banging on about kerberos??

I feel you pain, most you can really do is push back but depends on your org, we're pretty open here and like i say, i have a case of "Macs? We don't understand, do what you want" which actually suits me fine.

Back to chicken, egg then i suppose.

Local accounts are worth the fight... it's a much better user experience... One of my favorite points to use is that AD accounts are not really the Mac industry standard anymore, so why is the security group requiring it.

C