Use DEP to keep stolen computers enrolled

[gregleeper]

It just dawned on me after a couple of Airs have gone missing or have been stolen recently that we could use DEP to keep those devices enrolled. The info is certainly out there on how to reinstall the OS and thus remove the jamf binary.

Are there any drawbacks to keeping your computers assigned to a pre-stage enrollment even after being deployed?

[ImAMacGuy]

my understanding is that with DEP even if they wipe and reload the system, it will still reload the MDM as part of the process when it checks in with apple to register itself. So unless they keep it offline (including during imaging), it will always re-enroll into the MDM it was assigned to.

Haven't verified it though.

[adamcodega · Accepted solution]

If you don't give the computer a network connection during Setup Assistant, or fake the applesetupdone file, then the computer will bypass checking in with Apple. I have not been able to test yet if a computer would check in with Apple at any other point in time after Setup Assistant.

I don't see why you wouldn't keep the computer assigned, then if it's reimaged or etc it's already ready to go.

[jaharmi]

I’ve gotten the same information from Apple, @adamcodega. DEP on OS X is part of the Setup Assistant. That has helped me to frame what it likely can and cannot do, and when.

If the Setup Assistant is skipped, the MDM enrollment does not take place. If there is no active Internet connection, the Setup Assistant does not complete the enrollment. My understanding is that the user is not offered enrollment later. (It would be interesting to hear if that is not the case.)

Even with DEP, the account creation step cannot be skipped. Whoever goes through that process creates an administrator account that could potentially undo or prevent management actions.

[gregleeper]

I just tested this out. After using internet recovery mode to erase the disc and reinstall the OS, if the network configuration portion of the setup assistant is skipped, then it does not checkin with Apple's servers to enroll in MDM.

I don't know of another point at which the computer would check in with Apple.

[mm2270]

Huh. Seems like Apple needs to add in a (controllable) option for the DEP admin to force an internet connection at the time the Setup Assistant runs, meaning, if no internet connection is present, it won't go through the setup at all.

As usual, Apple comes up with some brilliant ideas, but leaves loopholes the size of a Mack truck for users to find and bypass it. Why don't they think of things like this? Or, do they think of it but just don't care? Likely the latter.

[gregleeper]

@mm2270 i believe iOS enforces this, right?

[adamcodega]

I think this is the case of don't call an apple an orange. (I know, stupid pun.)

Apple hasn't designed DEP as a recovery system, I think it was designed to make device management easier and configuration distribution, especially on iOS, easier. Given the nature of iOS, you can't use an iPad without Wi-Fi so why not make check-in with Apple required? I think they added DEP to OS X without the design story that it's used for device recovery.

I'm unsure how a computer would be configured to require check-in with Apple without special things being done at the factory, which would negate the convenience of DEP on devices you've already deployed.

I like the idea of a computer checking in with Apple even after Setup Assistant, but then do all Apple computers start doing that? What if your security conscious and don't want your computer doing that? Many companies already block APNS because of security concerns.

At this point I'm simply changing my view of DEP but still moving forward because it works as a deployment model for us.

[adamcodega]

Thanks for the input from Apple, @jaharmi. I was going to ask the same.

[mm2270]

Yeah, I understand DEP wasn't envisioned as a recovery model, but it was envisioned (at least I think) as a way to ensure devices are always enrolled in your MDM system. Given that, I can't see how it makes any sense to allow such an easy loophole to bypass that. Forget about recovering stolen devices for a moment and think simply of ensuring a device delivered to an end user is being properly enrolled in your management solution. As it stands, it can be too easily bypassed and is thus useless for us. We're not using it, but I had been looking at it from time to time to see if it made sense. But given this information, there is simply no way we can use it.

I can't say I'm actually all that surprised this is the case. As typical, Apple sides more with the end user than with institutions trying to manage their institutionally owned Apple products.

[gregleeper]

I tested this out on a Macbook Air that shipped with 10.7 so my erase and restore brought back Lion. Does anyone know if the later OS versions require an Internet connection before continuing with Setup Assistant?

[adamcodega]

None do, that would be annoying if you were setting up a computer for non Internet use, or just not set for Wi-Fi at the time.

[gregleeper]

My understanding is that DEP, regardless of platform, is envisioned as a hands-off, out of the box approach for IT. Directly ship the computer or device to the end user while also enrolling it the management framework when it's set up. How does IT ever fully embrace this method if there is a possibility of user error in the initial setup?

[jaharmi]

@gregleeper, as far as I know, the information I have from Apple is current as of Yosemite.

For DEP to provide hands-off deployment in more and varied situations, I can imagine it would need to allow for network security (802.1X for wired/wireless/etc.) and the ability to skip more Setup Assistant steps (possibly including a profile-based method to create user accounts rather than doing so through the Assistant).

[mm2270]

As I thought more about this situation yesterday, I finally got why it works as it does, and realized I wasn't seeing the obvious before.
Since any Mac enrolled in DEP ships from Apple with the exact same OS config as a Mac you'd pick up at an Apple Store for example, there isn't anything local on the Mac that would indicate it needs to be enrolled in an MDM setup. it isn't until it checks in with Apple's servers that it gets flagged as a DEP device and does the enrollment. Given this, it makes perfect sense that not having an internet connection bypasses this, since it can't possibly know OOTB that it should enroll itself in anything.

But, it would be great if Apple included some kind of low level process that, as soon as a Mac did get an internet connection, it would do a one time check-in with Apple's servers, just to see if its a DEP destined device. That way devices could get enrolled later that didn't initially have an internet connection, for whatever valid or invalid reasons there might be.
The way it is now, its a one time shot, and is far too reliant on external access to work. Miss that one opportunity to enroll at the Setup application, and you don't get a second chance, which is kind of crazy. As mentioned, there could be valid reasons why an end user doesn't get the Mac connected to the 'net during setup. They may be setting it up in a location where they don't have internet access for example, so the "bypass" may not even be intentional at all, but can still happen regardless.
It seems Apple didn't really think the process through very thoroughly to me. They seem at times to operate in this idealistic world where everything just works, users always do exactly what they should, and internet access is ubiquitous and a given. Problem is, we don't live in that world.

[gregleeper]

Thanks for everyone's thoughts on this. I look forward to seeing how DEP on OS X progresses.

[adamcodega]

Not to keep us talking in circles but @mm2270 You expanded on the point I made earlier. I worry if a device did any sort of check-in after the fact security people (or paranoid folk) would cry foul.

DEP and VPP are constantly evolving, will have to keep our eyes on the next iteration of DEP.

[rcastorani]

Sorry to bring up an old thread, but does anyone know if the DEP process checks-in again during an OS upgrade? A different setup assistant pops up asking to sign into iCloud, then asks if you want to send information to developers, then "setting up your mac". Curious if this is another DEP check-in or not.

[dan-snelson]

@rcastorani While I don't have anything conclusive, I've noticed DEP-enabled devices which were assigned to a PreStage after they were already enrolled in the JSS, re-enroll post OS upgrade.

[stevewood]

@rcastorani yes, even with a complete nuke and pave, DEP will check in with your MDM server. I had a laptop stolen last year that was sold at a swap meet this year. The "new" owner erased the drive and installed El Cap on it. The machine immediately contacted my JSS and started checking in after the jamf binary was installed. I then used Prey Proejct to recover the laptop. You can see the script I used here:

Prey Project Mass Deploy through

[rcastorani]

Thanks for the replies.

@dan.snelson I've noticed the same thing and that is what I was afraid of.

@stevewood I understand the DEP process check-in during the full setup assistant after a fresh install (I've actually recovered several machines and have caught three thieves this year). I am specifically referring to the setup screens after an existing machine is upgraded from 10.9 or 10.10 to 10.11. It seems to me that DEP checks in again even though it isn't a fresh install and it's only an in-place upgrade.

Somehow, after upgrading to el cap through self service, one of our users triggered the postenrollment script that creates new users and it overwrote his existing user. We recovered some data, but I can't figure out how this only happened to one machine. Going to add a script to check for our admin account before firing off any new deployment scripts as a safeguard.

[stevewood]

@rcastorani ah, sorry, I misunderstood the question. I do not believe that a machine would check back in to DEP on an upgrade. It seems to me that a machine would only check in on a fresh install.

How is that postenrollment policy/script set to trigger?

And what's in the Self Service policy to upgrade? Do you have any extra scripts (like a postinstall script) that could be flushing or enrolling the machine again?

[rcastorani]

@stevewood The policy is configured as an Enrollment Complete trigger only. I actually modified one of your scripts (thanks btw!) which drops a LaunchDaemon and reboots the computer. We heard from the user that about 4 hours after the El Cap upgrade (no additional scripts btw) the computer restarted and ran the post install script.

Part of that script does flush policies so unfortunately we can't see any other history. However, it does show that it was re-enrolled using DEP prestage enrollment. It seems to me that the upgrade somehow re-enrolled it.

We are testing on some machines now - we removed the jamf binary, upgraded to el cap, and the mdm profiles did drop back down. So the computer re-enrolls during an upgrade based on the pre-stage enrollment which then triggers the policy that should only be run on new machines.

Until I can better wrap my head around this one I've disabled the post enrollment launch daemon policy. We are planning on changing up our zero-touch deployment anyway with the new DEP features anyway.

[stevewood]

@rcastorani In your testing, why did you remove the jamf binary? Did you also remove the machine from the JSS? My understanding is that a machine would not run through a Pre-Stage (PreStage Imaging or PreStage Enrollment) unless it was removed from the JSS.

I'll test an upgrade here and see if I have the same experience as you are seeing.

[rcastorani]

@stevewood Well we're testing two different things actually. One was a deprovision script for sold computers and the other is just trying to figure out what happened to this one laptop that re-enrolled. We didn't remove the computer from the JSS either time though.

That is my understanding as well, which is why I'm incredibly confused as to how this happened. It was obviously already enrolled with a working binary because the upgrade was in Self Service and it runs several scripts beforehand including a recon.

[devlinford]

@adamcodega ,

Not to keep us talking in circles but @mm2270 You expanded on the point I made earlier. I worry if a device did any sort of check-in after the fact security people (or paranoid folk) would cry foul. DEP and VPP are constantly evolving, will have to keep our eyes on the next iteration of DEP.

This is just poor implementation on Apples part, and it doesn't appear to be getting any better (2 years after original post). If an institution has made the decision to use DEP, then they have accepted the security exception of 'phoning home to Apple' to check for DEP registration, full stop. It doesn't matter if this happens after an out-of-the-box first run or three days later when it finds a valid internet connection, it is in the best interest of the institution for this handshake to take place. The point of DEP is to get a system enrolled in an MDM and lock it to an institution; both of which can be easily bypassed, and by accident no less, if someone fires up the system without knowing they need a network connection (this is far worse than someone attempting to game the system). We all know a monkey could remove a Jamf Profile and free a system from the JSS if they wanted to, I'm more concerned about a regular compliant user just accidentally mis-configuring upon first run.

This handshake should be taking place even after an erase and image is pushed to the device. When it connects to any network, it should phone home and pop a notice that this system is part of DEP, and gets re-directed to the MDM for PreStage instructions.

Further to this....Why is there a PreStage flag to 'Make MDM Profile Mandatory" if it isn't by design?!

The only way a system enrolled in DEP should be able to get past an MDM enrolment is if it is 'Unassigned' from the Apple DEP portal - Sadly this is NOT the case...C'mon Apple...and we aren't doing ourselves any favours by justifying this...

[AdamSanderson]

So I am having a similar issue with DEP but on the opposite side of things. I run a small IT refurbishing business and we receive a lot of pre-owned Macbook laptops. We fully wipe all the devices again and then restore the OS. However, we have been seeing units that after restoring they begin to prompt to enable the device enrollment process from the previous company.

To test, I used a machine I know is enrolled in the DEP program (it was prompting to start the enrollment process) I reimaged the system and went through the initial setup process again. However, the DEP enrollment does NOT consistently appear. Sometimes it will prompt during the setup process, sometimes it appears at the desktop, sometimes it doesn't appear at all even after several reboots / reimages.

Is there a way to definitive check if a specific machine is enrolled in the DEP program? Perhaps something I can do in terminal to force a machine to start the enrollment process? An online serial number check? If I setup my own DEP account could I check the serial number against it to see if they are eligible to be enrolled? From what I read, it sounds like the devices are enrolled by Apple and not the company that purchases them.

I want to be able to check if a machine is still enrolled BEFORE I purchase the equipment. Obviously, if a machine is still controlled by DEP I do not want to purchase it. I'd want to have the device removed from DEP but from reading the admin guides it seems like only the DEP admin can disavow a device.

Thank you for your assistance!

[Funtelo156]

Sorry to ask again, but am I right in thinking that once the machine is on and running and past the original setup (before DEP was activated) that it will not ask again unless I script it ?

We have some use cases here and looking for more information.

Thanks

J

[Leilomei]

Would love to know about this too. Is the machine fine after the machine is past the original setup before DEP MDM and PreStage is applied? Or does it periodically call into Apple’s servers from time to time?

Have some use cases as well.

Thanks!!

[sparky627]

I think the most definitive way to determine the status of a machine, and subsequently unenroll them, is to call Apple. With iPads it takes them a couple weeks if you're able to prove ownership.

As for checking on a machine, I've used sudo /usr/bin/profiles status -type enrollment to check the current status and sudo /usr/bin/profiles renew -type enrollment to trigger DEP checks. If you've got a solid network connection with no firewalls between you and the DEP servers, you should get an accurate report. (At least for us it's always the network that is the wildcard)