Hi Shane,
I fully agree that having a master connection to see all of the composited defaults would be great, but we aren't there quite yet. It is fairly easy to work around from a scripting standpoint though and I'll investigate the programatic side of it a bit.
The profiles command makes it pretty simple to interrogate the system for configuration profile data. Keep in mind that profiles can contain preference settings or configuration data. Things like loginwindow settings will show up in the ManagedPreferences folder, but configuration data like 802.1X or certificates will not. A simple 'sudo profiles -Pv' will show you if profiles are installed and what the non-secure parts of their payloads are. You can even more simply test to see if profiles are installed at all with 'profiles -H'. If that test returns false then we can proceed to the next step. (Currently we don't offer any public APIs to work with the ConfigurationProfiles.framework as it's private.)
Settings that are preferences from mcx or profiles will show up in the master composited plist file at /Library/ManagedPreferences/<username>/complete.plist. You can simply read this in and see everything that's composited regardless of policy source. If the file doesn't exist, then there aren't any ManagedPreferences to look for.
After that you can drop down to looking in defaults and plist files as we've done in the past.
Is this a great or simple solution? No, not really. It is the best viable one we have to work with currently.
We've got some pretty decent developer documents on the preferences system in general, NSUserDefaults, and CFPreferenceSettings.
Josh
--
Josh Wisenbaker
Consulting Engineer - Apple U.S. Commercial and Governmental Sales
dubs(a)apple.com
On Jun 4, 2013, at 11:01 AM, Shane Shaffer <shane.shaffer(a)g2-inc.com> wrote:
> While working with configuration profiles is likely the preferred configuration mechanism moving forward (if one hasn't already invested in another mechanism), the larger problem remains that there are multiple mechanisms for configuring settings such as these, with unclear relationships between those mechanisms and unclear behaviors within some mechanisms. If only configuration profiles were used it seems to be a relatively simple problem, but that's not realistic. We're dealing with systems that might have a profile configured this way, might be managed via Profile Manager, might have multiple conflicting .plist files across the multitude of locations in the preferences hierarchy (all the by host, by user, system wide, managed vs. local, etc. variants), and so on. Any configuration method specific assessment mechanism is ultimately of little value as long as multiple methods of configuration can be used.
>
> I've previously gone down the road of attempting to understand the hierarchy of .plist files and locations, but eventually realized that the effective precedence hierarchy differs from setting to setting (not all settings that may be configured in a plist file in one location are honored if set by that same plist file in another location, and other differences), and may be dependent on the state of the session lifecycle (i.e., one precedence hierarchy is used at login that makes a managed preference override a user level preference, but if the user can change the setting during that session it may override the managed preference for the duration of that session). Dealing with just plist files proved to be an impractical assessment problem due to the inconsistent behaviors and lack of documentation making it a frustrating trial and error effort.
>
> What we really need is a definitive way to determine the effective configuration of a setting regardless of configuration methods used. Sort of an extended MCXCompositor behavior I suppose. A capability that does this would be great for assessment, but to ensure proper remediation we also need documentation of how all these configuration methods interact so we can choose the most appropriate method and/or get the desired result regardless of method chosen.
>
> Shane Shaffer
> G2, Inc.
> shane.shaffer(a)g2-inc.com