Blog Archives

Authorization File Change Log (of sorts) & Archive

I’ve been playing with VMWare Fusion Snapshots and OS builds and have compiled a repository of original etc/authorization files incase you mess yours up.  Authorization File Archive.

And the correct permissions are: permissions

A few have asked if these posts are still valid for 10.8.x & I’d like to confirm Yes they are.  I decided to go back and look at each & compare them to find the changes throughout the OS builds in the etc/authorization files.

10.7.2 to 10.7.3  Just some new strings added in to support multiple new languages.


10.7.3 to 10.7.4 – A couple of new Keys were added, brief description below:

<key></key> (Probably allows you to set who can see passwords in Safari)

<string>This right is used by Safari to show passwords </string>

<key></key>  (Probably allows you to set who can repair libraries)

<string>__APPNAME__ is trying to repair your photo library.</string>

<key></key> (Not too sure)

<string>Modify Settings</string>


10.7.4 to 10.7.5 – No Changes


10.7.5 to 10.8 – Lots of Changes, Notes below.

<key></key> (To investigate) 


<string>Used by diskmanagementd to allow access to its privileged functions</string> (To investigate) 

<key></key>  appears to be exactly the same as <key>system.preferences.softwareupdate</key>  but new rule of   <string>root-or-entitled-admin-or-app-specific-admin</string>  (app-specific-admin seems to be new as well)

<key></key> (This replaced a Podcast Producer key, to investigate)

<key></key> (To investigate) 

<key></key> (To investigate) 

<key>system.preferences.nvram</key> (To investigate) 

<key></key> (Is now a USER rule)


New Keys (abbreviated)

<key></key> (Appears the same, To investigate) 

<string>For making change to network configuration via System Configuration.</string>

<key>system.volume.</key> (Not sure about this lot of volume related keys) 







<key>app-specific-admin</key> (New Rule type, To investigate) 








10.8 to 10.8.1 – No Changes


10.8.1 to 10.8.2 - Some Changes.






<string>Login mechanism based rule.  Not for general use, yet.</string>





<string>builtin:login-begin</string> (NEW, not sure of use)


<string>builtin:login-success</string> (NEW, not sure of use)


———  Updated : 22 July 2013  ———-


10.8.2 to 10.8.4 - A few new entries


<key></key>  (Described as: __APPNAME__ needs to repair your Library to run applications)



A couple of New Wifi Strings that look very useful

<string>For restricting WiFi control</string>
<string>Used by the WirelessDiagnosticsSupport framework to restrict XPC services provided by the wdhelper daemon</string>


Using Network Accounts with the Authorization file – 10.7.3

I’ve had a couple of comments about using Network based accounts / groups instead of local groups.  I’ve done some tests on 10.7.3 and here’s a couple of ways to go about it. (Thanks goes to Shane for some of the info)

My testing and examples below assume a similar setup to mine which is.  Staff are allocated one machine each.  Windows Server 2008 Active Directory setup, Domain Users and Mac’s bound to AD via the native apple plug-in.  A local admin account on every mac for installing software, ARD use, backup for when directory services falls over.  Try and adjust my examples below to fit your needs.

A. Create a new local group and add users to it. (Small scale scenarios)

1. Login as an admin account, goto System Preferences > User & Groups, unlock the pane and click the + button.

2. Scroll down and choose the Group option at the bottom and give it a name.  i.e. testgroup.

3. Simply tick the users you want in that group and close the pane.  In the picture below I’ve added an account called Mickey Mouse.  The machine was bound to Active Directory via the built in Apple plugin then I logged in as the network user (mimouse) and forced a local home, creating a “Managed, Mobile” account.  I’ve also ticked my local admin account called The Boss.

4. You now have a group with your network non-admin account and your local admin account. As pictured below.

Now you can do as per my previous post simply replacing lpadmin with testgroup / whatever you called your new group for whichever Preference Panes you want to unlock.

B. Create a new local group and add existing groups to it, nested groups. (Larger scale scenario)

The example above works for a machine that has one or two known users but not multiple unknown users logging in. We’re going to add existing groups where the members are calculated, to a new local group so it covers all potential users.  Where going to effectively add Domain Users and local admins to this new group.

1. Create a new local group for the purpose.  As per above via Users & Groups or via the command line. (have a look at dscl . -create)

2. Active Directory users get added to the netaccounts local group when you login on your Mac.  Both Mobile and Network accounts. (See my note at the bottom about directly using Domain Groups)  To verify, login as a non-admin AD based user and check the account is in that group via Terminal:  dsmemberutil checkmembership -U mimouse -G netaccounts  (subbing mimouse for your network accounts shortname) you can also use dseditgroup -o checkmember netaccounts (it will check if the current terminal sessions user is in the group or not)

you’ll get a one line reply like this:  “yes mimouse is a member of netaccounts”

3. Add the netaccounts group to your new group, in my example  it’s called testgroup.  In Terminal paste the following: sudo dseditgroup -o edit -a netaccounts -t group testgroup

4. Verify your AD user is now also now part of test group. dsmemberutil checkmembership -U mimouse -G testgroup

 Note: Any other non-admin domain users that login to this machine will also get put into the netaccounts group and therefore be part of your new ‘testgroup’ automatically.

5. Add the local administrator group to this group as well.   You want to be able to edit all the System Preferences as well.  In Terminal paste the following: sudo dseditgroup -o edit -a admin -t group testgroup

6. Verify it’s worked as per step 4, subbing in a local admin’s username.  In my example ‘theboss’.

7. You now have a local group called testgroup, which contains nested groups Administrators and Network Accounts.  Open System Preferences > Users & Groups and you should see a result as pictured below.  Noting that you can’t achieve this result from the GUI.

Accounts Pane

Now you can do as per my previous post simply replacing lpadmin with testgroup / whatever you called your new group for whichever Preference Panes you want to unlock.

NOTE: You can also directly add Domain Groups into this new local group: i.e. below I’ve added Domain Admins and Domain Users from Active Directory to my group.

sudo dseditgroup -o edit -a “Domain Users” -t group testgroup
sudo dseditgroup -o edit -a “Domain Admins” -t group testgroup

BUT this membership is calculated or searched for at the time of credential checking.  A simple check of Shutting down, booting up with no network cable plugged in, logging in as my mobile AD account yields no mimouse is NOT a member of testgroup.  If I connect the Ethernet cable and wait 60 seconds it returns yes they are.  This gets cached for some time period.  I wouldn’t recommending doing it this way, as a network connection is basically required at all times.