signing (and therefore generating) profiles (server-side or otherwise)

[arubdesu]

Just so you don't need to wait for my post to AFP548, when each workstation has the CA's public cert in the system keychain, it'll trust profiles signed in this fashion, 'offline'(or 'out-of-band'): openssl smime -sign -signer ca.pem -inkey ca_key.pem -nodetach -outform der -in MyGreat.mobileconfig -out MyGreatSigned.mobileconfig So while this is currently a dynamic thing happening client-side, turning this into a master-side function(or just using another delivery method to get it in place) would be awesome.

[dayglojesus]

Al,

First, thanks for the feature request -- I do appreciate your interest in the project and I want to help, but this is not something that can be supported with the present implementation of Puppet or the managedmac module.

Let me break it down for you...

Puppet catalogues are compiled by the puppet-master (server-side). These catalogues do not contain the compiled OS X profiles themselves, they only contain the data (class params) afforded by Hiera or another source (manifest?).

When the catalogue reaches the puppet-agent (client-side), it parses the catalogue and creates these OS X profiles on-the-fly which it then installs or uninstalls according to whatever data you passed into the classes you used to create them.

Now, the profile could be signed before installation -- it doesn't seem like that much work and my curiosity is piqued -- BUT...

1. client-side signing

For me, this is simply "window dressing" because the only effective difference will be that you don't see the big red emboldened "Unverfied" label next to the profile when you look at in System Preferences. My take is simple: If you trust your puppet-master, you can trust the profile it is managing.

2. server-side signing

To get server-side signing to happen, you will first need to create the profile, but that will never happen on the server with the Mobileconfig type. Why? This type is never even consulted but the puppet-master. Think about it...

There is never a complete profile in the catalogue -- it's just a bunch of values you passed into the different classes. Regardless what Puppet Type/Provider we talking about....

Mobileconfig, Propertylist, User, Service, File, Cron, Package, etc.

None of these resources are created ON THE SERVER -- they get created on the client and they do that because the puppet-agent parses the catalogue and then hands that data to Types and Providers which then MAKE the resource manifest itself on the local system. That's the way the Puppet works.

So, why bother using Mobileconfig type at all?

The reason this was created was so that you could use Hiera to stack data in precedence order and have Puppet compile a profile for the client that could have values inherited from multiple sources.

Example: managedmac::activedirectory

This Puppet class is a good example because Advanced AD configuration profiles are not supported by OS X server (AFAIK) and it contains a wealth of various options compiled into a single OS X profile.

Now, let's say you managed several different organizations under an AD environment. This would likely mean that while they share a great many things in common, there would be times when you needed one setting for Org_A and another for Org_B, or maybe just this ONE HOST that needs this ONE THING changed.

You decide to manage all of this using files -- a bad idea...

Okay, managing profiles as files is fine until you get to the point where common configurations need to be inserted in a consistent manner into several files. Now, every time you need to change one thing for everybody, you have to change that one thing in every file.

Well, you could take all the common settings and put them in one profile and then distribute that to everybody along with their organization profile, but now you have two files. Where does it stop?

Seriously, that setup sucks. So, Mobileconfigs with Hiera solves this because you can just create a hierarchical data structure and then compile it to each organizations' or clients' needs.

I tried to outline the idea here... http://dayglojesus.github.io/managedmac/overview

SUMMARY

If you need to sign profiles before they reach the client, you will need to sign those profiles before they ever get to the puppet-master. Then, to distribute them, you would need to use at least one File and one Exec resource in a manifest.

You could sign them client-side, but is it worth it?

HTH

[dayglojesus]

I forgot one thing... Native Puppet already supplies you everything you need to do what you are suggesting. With a couple of Execs, a function and a File resource, you could create your own Puppet class to do exactly what you need -- it's pretty simple. If you want to create such a class, I would be willing to work with you on it. Cheers.

[arubdesu]

Hey Brian, I greatly appreciate the thoughtful explanation and offer of help. I'm seeing parallels to the flexibility you get by granularly allowing management per node in munki, though it's much thicker when you're terraforming worlds😸. I could go the 'crazy person rocking themselves, rolled up into a ball in the corner' route (you even went ahead and hinted at it)... YES! CLIENT SIDE, STANDALONE CA CREATION(!), (No other alternative I can think of so far without, as you outline, major modifications. Luckily the good drugs are not yet legal in NY, so I'm (close, but) not belligerently dumb enough to suggest shipping the ca's key to each client...)(I've modified this issues title in turn.) No, really, maybe it'd have the shortest turnaround to implementing signed profiles in managedmac if we built a CA (each) client-side? The client doesn't care as long as it trusts somebody's CA cert in the system keychain, profiles which are dynamically built and signed by its key will show as trusted as well.

I'm fully willing to come to grips with the fact this enhancement request may very well be outside of the wants or needs of the current or (in my case) near-future managedmac install base, (I'm still in the 'build all the systems!' phase with puppet, starting with the subsistence level of somewhat manually generating certs to secure munki traffic) so you're more than welcome to file this in the circular bin for now. I know @groob is masterless, though, so maybe he or other potentially concerned parties want to chime in...

Another thing I appreciate in the managedmac documentation is you answering why its design is this way, but we're going to have to agree to disagree on referring to end-user-accessible(since I refuse to hide the profiles sysprefs pane) red 'not verified' warnings as 'window-dressing' - my security department SHOULD care about things like constant UAC privilege escalation nags and bad-ssl-website-warning dialog-box fatigue. (Here's not the place for debate about how much end users care about any of this, really, but it's without question more visible than MCX ever was.) Just like purty charts, and how I (um, at least recently) sign custom packages I build for my org - I'm doing it for more than just the fact it gives managers warm fuzzies.😜

If for no other reason, I just wanted to leave breadcrumbs for anyone who could benefit from knowing what the exact certs from a puppet CA are, and the commands in question that result in signed, non-MDM-dependent profiles(with help from @bruienne et al.)

[dayglojesus]

I still think about this.

[arubdesu]

As I finally got around to converting localMCX to profiles recently it dawns on me that I interact with enforcing mgmt very infrequently, but the end-game of signing server-side(and heck, even encrypting the payload) before shipping to clients would still be very attractive. With munki picking up distribution capabilities you'd think this was less of a priority, but it doesn't care what profile it delivers - nor do munki server products like @grahamgilbert's Sal take this into account yet. So something has to be involved in automating the implementation of these features. We're this close to having security rubber-stamp our instances, so hopefully I'll revisit this with engineering time soon.