MCX and InstaDMG

[userosx]

I’m fairly new to both InstaDMG and local MCX, so please forgive my lack of knowledge here… Historically I’ve built images on a Mac Pro making extensive use of ‘defaults’ and PlistBuddy. Thus, this new method is taking some adjustment…

My question is this: Is the only way to configure local MCX via InstaDMG to use CLI/scripts with ‘dscl’? This isn’t a problem per se, but I would then need to determine the correct syntax/command for every change I want to make. Is there a way to configure a machine using Workgroup Manager and essentially apply a pre-configured file or template? In other words, instead of writing a script with every mcx/dscl command, doing some sort of “export” and applying it to the build? I’ve created the initial “localhost” package that creates the computer record, but before I start deciphering all of the plist and dscl configurations, I thought I’d check to see if there is an easier way. Finally, if this can only be done via dscl in a script, I was hoping to find some commonly used commands, like changing the options in the Security pane in System Preferences.

[Patrick Fergus]

I’m going on the assumption that you don’t have any directory service (AD, OD) at all. See here (search for “Local MCX”):

[url]http://homepage.mac.com/gregneagle/files/MW2009_IT803.pdf[/url]

and here:

[url]http://managingosx.wordpress.com/2008/02/07/mcx-dslocal-and-leopard/[/url]

You’re going to want to plan to be able to replace the files that you’re installing to enable local MCX when you figure out a new MCX setting you wish to set (via FileWave, radmind, ARD, etc).

Kudos to gneagle since all of the above is his work.

– Patrick

[larkost]

Greg has also posted his Macworld slides, along with those from the rest of the presenters (at least those of us who provided them):

http://www.macenterprise.org/macworld-2008-slides/imaging-track

[Anthony Reimer]

Local MCX settings were a showstopper for me this month. I went over everything I could find on this board and did go over Greg’s MW2009 slides. Let me go through my process in case someone can see the point of failure:

Goal:
Leopard Image with three local user accounts: general user (whitelist apps and system prefs), instructor (standard account), and admin. Payload is 66 GB (!!), as it includes Final Cut Studio and Adobe Creative Suite. Deployed to 30 stations in labs (often use FW800 drives hooked up locally due to image size). Only ARD is available for systems management.

Process:
(1) Get as much packaged and installed as possible using InstaDMG workflow. Create at least the admin and general user account in that workflow using createUser.
(2) Place InstaDMG-generated image on a test machine and do the rest the old fashioned way (i.e. image a “golden” machine and deploy from that). Right now, “the rest” is Final Cut, CS4 and some customizations that are outside of my skill set right now (e.g., I don’t have any shell scripts that run at first launch after deployment).

Result:
Some MCX settings do not stick upon deployment. In the worst case, it ignores the application whitelist and blocks everything.

In desperation, I also tried using Parental Controls, but could not lock down the System Preference panes individually. Am willing to hear any thoughts and expertise.

[Patrick Fergus]

What are you attempting to whitelist? Could you just whitelist the directories (/Applications) that contain the applications?

Are you attempting to disable access to Preference Panes, or just require an administrative L/P (your choice of words of “lock down” is unclear).

– Patrick

[Anthony Reimer]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p][i]What are you attempting to whitelist? Could you just whitelist the directories (/Applications) that contain the applications?[/i][/p][/QUOTE]
I could and have considered that. The reasons I didn’t are (1) I have had problems deleting some Apple-provided apps (e.g., Mail) that seem to resurface any time you push out an OS update, (2) It would provide access to all utilities (I have been known to place maintenance utils like CacheOutX in there that I don’t want general users to access). I could reconsider on that one.

[QUOTE][p][i]Are you attempting to disable access to Preference Panes, or just require an administrative L/P (your choice of words of “lock down” is unclear).[/i][/p][/QUOTE]
Disable access to specific panes. There are a number of panes that do not require authentication to which I would rather not provide access. Conversely, I want users to have access to panes that are important to quality of their work, such as settings for Wacom tablets and sound output.

Anthony

[Patrick Fergus]

You could whitelist the entire /Applications directory and then blacklist the apps you do [i]not[/i] want users to access–that’s what we’re doing here. Not that it’s going to help you if application white/blacklisting isn’t working [i]at all[/i].

If possible, can you log in as an admin and hold down the “Option” key when clicking “OK” and ask to “Refresh Preferences”? I’m aware this won’t work if MCX doesn’t exist in the first place (you can’t disable what you don’t have), but I’m wondering if this is a timing issue or a complete failure of MCX.

Are you bound to any directory system (AD, OD) with MCX-aware schema?

– Patrick

[Anthony Reimer]

[QUOTE][u]Quote by: Patrick Fergus[/u][p][i]If possible, can you log in as an admin and hold down the “Option” key when clicking “OK” and ask to “Refresh Preferences”?[/i][/p][/QUOTE]
No change in behaviour, other than losing one nicety with the login screen. Was worth a shot.

[quote][i]Are you bound to any directory system (AD, OD) with MCX-aware schema?[/i][/quote]
No. That might happen down the road (and, from what everyone here says, should be my goal), but right now, all that our server does is serve files.

I’m going to go back to the InstaDMG part of the image and try to get that smaller image working (might as well eliminate some possible sources of failure).

Anthony

[Greg Neagle]

More details on your process are definitely needed. LocalMCX is easiest to understand and deploy when you are managing settings for all users of a given machine – in that case, the settings are stored in computer records or computergroup records. When you manage computers or computergroups, it can be as simple as copying few files into the right places.

It’s certainly possible to add local MCX data to locally-defined users, but you’ll have to either modify createUser to inject the MCX data as it’s creating the users, or write some script that can find your local users and merge the MCX data into them.

Personally, I think it would be far easier to create the users on another machine, use Workgroup Manager to apply MCX settings, then capture the relevant files (/private/var/db/dslocal/nodes/Default/users/myadminsuser, /private/var/db/shadow/hash/$GeneratedUID, etc) and install them with a package or packages. This way you don’t have to use dscl to regenerate the MCX settings.

With your current image, use mcxquery and system_profiler SPManagedClientDataType to see what the MCX settings are for each user. You can also launch Workgroup Manager and look at the appropriate local records.

-Greg

[QUOTE][u]Quote by: jazzace[/u][p]Local MCX settings were a showstopper for me this month. I went over everything I could find on this board and did go over Greg’s MW2009 slides. Let me go through my process in case someone can see the point of failure:

Goal:
Leopard Image with three local user accounts: general user (whitelist apps and system prefs), instructor (standard account), and admin. Payload is 66 GB (!!), as it includes Final Cut Studio and Adobe Creative Suite. Deployed to 30 stations in labs (often use FW800 drives hooked up locally due to image size). Only ARD is available for systems management.

Process:
(1) Get as much packaged and installed as possible using InstaDMG workflow. Create at least the admin and general user account in that workflow using createUser.
(2) Place InstaDMG-generated image on a test machine and do the rest the old fashioned way (i.e. image a “golden” machine and deploy from that). Right now, “the rest” is Final Cut, CS4 and some customizations that are outside of my skill set right now (e.g., I don’t have any shell scripts that run at first launch after deployment).

Result:
Some MCX settings do not stick upon deployment. In the worst case, it ignores the application whitelist and blocks everything.

In desperation, I also tried using Parental Controls, but could not lock down the System Preference panes individually. Am willing to hear any thoughts and expertise.[/p][/QUOTE]

[Anthony Reimer]

OK, I have finally been able to find some time to get back at this and have found the primary error of my ways. Basically, I assumed (yes, I made an [i]ass[/i] out of [i]u[/i] and [i]me[/i]) that because my old method (using NetInfo database) succeeded when I cloned a machine with the right settings that this would also be the case if I got the settings right using MCX. Nope. I need to do a little more testing, but I believe I have fallen into the MAC address trap that Greg described in his Macworld slides.

Ironically, if I take a completed image, add Parental Controls, then make an image of that, it works just fine. The problem with that solution is that Parental Controls are not granular enough, particularly with System Prefs. I’ll try some variations on both and post back when I have either a solution or another query. Thanks for the replies to date.

[Anthony Reimer]

The first signs of success! Thanks to the pathnames Greg’s method revealed to me (i.e. /private/var/db/…), I have been able to come up with a solution that worked on first testing. In brief:

1. Create an InstaDMG build train with two users (one admin, one restricted). Build an image from it.
2. Deploy the image on a tester machine and set MCX settings for the restricted user using Workgroup Manager.
3. Make a package out of the file /private/var/db/dslocal/nodes/Default/users/[i]restricted[/i].plist (where [i]restricted[/i] is the short name of the restricted user).
4. Install the package on any machine with the deployed image. (I did this when the target was not the boot disk. I have not tested it while booted from the disk, like might be done with ARD.)

I’m going to add the package to the InstaDMG build train and see how it goes. I don’t see any reason for it not to work, but I’ve been wrong before.

So thanks to Greg for the archaeology. Thanks also to Patrick for suggesting whitelisting /Applications and blacklisting exceptions — using this method means that I can dispense with a third user account that I had previously deployed.

Anthony

[Anthony Reimer]

Just a follow-up. Installing the …/users/restricted.plist file within the InstaDMG build did [i]not[/i] work. Manually running a package that installs the file once the image has been deployed does seem to work (a couple glitches, but nothing major).

[Greg Neagle]

To install a fully-functioning user, you need to install the user’s plist at /private/var/db/dslocal/nodes/Default/users/username.plist and also the shadow password hash, which is located in /private/var/db/shadow/hash/ and named after the GeneratedUID of the user:

dscl . read /Users/username GeneratedUID
GeneratedUID: B7CBD232-AA9C-4E57-A130-7AF46FD46F31

-Greg

[Anthony Reimer]

[QUOTE][u]Quote by: gneagle[/u][p][i]To install a fully-functioning user, you need to install the user’s plist at /private/var/db/dslocal/nodes/Default/users/username.plist and also the shadow password hash, which is located in /private/var/db/shadow/hash/ and named after the GeneratedUID of the user…
[/i][/p][/QUOTE]

Well that would explain why I couldn’t login to that account without resetting the password! Thanks for the tip.

Since it uses the GeneratedUID, it looks like I will have to learn how to do some sort of post-restore script to make this work.

Anthony

[Greg Neagle]

[quote][i]Since it uses the GeneratedUID, it looks like I will have to learn how to do some sort of post-restore script to make this work.[/i][/quote]

No, the GeneratedUID is in the username.plist. As long as it matches the name of the file in /var/db/shadow/hash, no scripting needed. Just install both files.

-Greg

[Author]

Posts