Over-thinking it?? Server-triggerable "run once" policies

[Shinko]

I'm having a hard time figuring out a realistic solution to what seems like a simple problem. I think explaining use cases will cut to the chase the best, so let's dive in.

1) Our laptops will soon be imaged & drop-shipped to end users by a third party. For security purposes, some of our policies/scripts will only apply when the asset is verified to be in the user's hands ("In Service"). I need for a tech to mark a computer "In Service" even if the computer is offline or off-network, for multiple computers at a time, in a way that will "reset" so that future issues do not occur after a re-image.

2) Our laptops are often offline or off-network, but techs still need to be able to "queue" policies to them at their convenience.

The best way I've found to do all this is to have techs add laptops to static groups according to what should happen and then use an API script to remove it from the static group when it's done. I guess the "complexity" of it doesn't scare me, I just don't like the way we're passing credentials insecurely.

Is that the only real way to accomplish this?

(It only just occurred to me that I might have the techs run scripts that run API calls instead. If I could have them do that, it seems much more secure, and I could for example have techs run an API call to set an EA to runPolicyX which adds computers to SmartGroupX which runs policyX at next check-in .. which then resets that original EA!)

Running 9.72.

[bentoms]

@Shinko that sounds somewhat sensible with the restrictions you've mentioned.

But, why not have a cloud accessible JSS? &/or depending on what's being scoped.. Maybe smart groups would work? Or the new in 9.81 trigger "once per user, per computer"?

[Shinko]

Hmmm... Cloud accessible JSS? Our JSS is cloud-based. Am I misunderstanding? :) And, Smart groups... I couldn't think of a way for techs to easily add a batch of new hire laptops to something like that. :( Smart groups cannot be manually edited AFAIK. They would have to edit EA's manually 1-by-1... Or, all machines would have to be online to run a Casper Remote batch update command for EA's... Any other ideas?

Didn't know about that in 9.81--interesting, but the problem was that the way the tech adds/initiates the policy is not reset on image. i.e. if a tech has to add a computer to a policy to kick it off, at re-image the computer is not un-scoped from the policy.... :(

[mm2270]

Maybe I'm not completely understanding your scenario, but could you perhaps drop some kind of file or folder on the Macs as part of the normal imaging setup that would get picked up by an EA script and place them into a Smart Group automatically, designated as "Not In Service" initially. Then when the user gets it, set up a policy that runs on first login that removes that file/folder and recons the Mac. This would land the Mac into another Smart Group for machines that need to run those setup policies.

I say this because we actually have a similar setup to your it seems. An outside vendor does our imaging and ships the Mac to the end user. The imaging process drops a Setup in progress file on the Macs that gets picked up in the JSS by an EA script. Most of our initial policies have an exclusion for a Smart Group of Macs that still have that file present, so the policies don't run on them. Once the user gets it, they go through a custom setup application to finalize their Mac setup. At the end, it runs a cleanup process that removes that setup in progress file and collects inventory. (We have a JSS cluster with an externally facing tomcat box) This let's the JSS know that the Mac is ready and can apply all the other policies to it, including any pending configuration profiles.

Would something like that work for you?

[Shinko]

That is quite similar to us... =) I do use a file + EA as you describe.

However... We want to prevent the scenario where the 3rd party vendor cracks our admin password (they have unlimited time & resources to do so, after all) and then has admin access to all of our machines. The image is extremely locked down & once the asset is marked "In Service" (manually by a tech once he's sure it's at the user) a bunch of those passwords/keys are changed yet again. I don't think I can use the setup you describe because nothing would prevent the vendor from just booting up a machine after image themselves, letting those policies run, & having a hay day.

Does that make any sense? :P I REALLY appreciate the input. Trying to balance between being concise and yet detailed.

[mm2270]

@Shinko So, forgive me for asking, but, if there is that much of a concern about the security of your Macs and a possible distrust of the vendor doing the imaging, then using an external vendor doesn't sound like the best option for your organization. Either that, or find a vendor you can put some trust in that won't be trying to hack into your Macs?
I guess I say that because we have a very close relationship with the vendor that does the imaging. The only thing they don't have access to is our FileVault recovery keys, but they do have local admin accounts and our firmware password. The company also does repairs of our Macs, so they need those credentials. All work (imaging, repairs, etc) is done in a secure locked down location on their premises that only a few employees in the company even have access to.

Excepting the above, is there some way you can use Network Segments for this, so, for example, the policies would only run if the Mac is used from within one of the known Network Segments? I'm guessing straight network segments alone would not work since you said these get shipped to clients wherever they happen to be, but what about only if they are on VPN to the company network would the policies run? That should prevent the imaging vendor from booting one of them and getting in and having those policies run since presumably they would not have VPN access. Possible?