Require a password to unl0ck each system preference pane

I just have this in my first boot script.

/usr/libexec/PlistBuddy -c 'set rights:system.preferences:shared bool false' '/etc/authorization'

there are actually several of those required for Lion and then they still only work some of the time from my experience…
here is our function in perl…
sub requireSysPrefsPW { my $firstbootArgs = shift; my $ans = lc($$firstbootArgs{reqsyspw}) || 'no'; my $authfile = "/private/etc/authorization"; my $plcmd = "/usr/libexec/PlistBuddy"; my $beg = " -c "Set rights:"; my $end = ":shared false" $authfile"; my @prefs = qw( system.preferences system.preferences.datetime system.preferences.energysaver system.preferences.network system.preferences.printing system.preferences.sharing system.preferences.softwareupdate system.preferences.startupdisk system.preferences.timemachine ); if ($ans eq 'yes') { syslog('notice', "Require passwd for SysPrefs pane %s ", $ans); foreach my $pref (@prefs) { my $cmd = $plcmd . $beg . $pref . $end; print $cmd . " "; system("$cmd"); } } else { syslog('notice', "skipping requireSysPrefsPW function "); } return;
}

--
Todd Ness
Technology Consultant/Non-Windows Services
Americas Regional Delivery Engineering
HP Enterprise Services

Does any one know a scripts to set the *Require a password to unlock each

On 26 November 2011 01:36, Tim Kimpton <Tim.Kimpton at rufusleonard.com> wrote: system preference pane? *

I wrote a policy to mimic the ticking of that box in the Security
Preference Pane. Please see attached.

N.B. I provide no assurance that it functions correctly (despite my
testing) nor any warranty.

Cheers,
Doug

The package dumps a plist I created based on a diff of the changes that OS
On 2 December 2011 23:32, Tim Kimpton <Tim.Kimpton at rufusleonard.com> wrote:
X makes when ticking that box in the Security PreferencePane. In the
postinstall script it uses a feature of OS X's `security` command to import
that plist into the /etc/authorization file.

Because the plist is extracted from what the GUI itself changes and the way
of getting it into the /etc/authorization file is via the use of an Apple
API, I think it's a clean way of going about things. Depending on your
organisation, you may like to adapt this to a policy rather than a run once
when installed configuration change.

Note about the use of `security authorizationdb write`, it's incredibly
picky about the XML you push to it and does not provide good feedback in
case of error. If you'd like to work with it for other authorizationdb
changes, the best way to be sure if something worked is by checking the
return value, ie: echo $?

Cheers,
Doug