Articles January 25, 2008 at 11:32 am

Using Managed Preferences in the DSLocal domain

So this has recently been discussed on the MacEnteprise list, but we thought we'd try and collate these ideas into a real world example.

Most of you should be aware of how you can use MCX to manage preferences for your directory service. Generally these days this is done by either running Open Directory, extending the schema for Active Directory or a standard OpenLDAP installation, or running a "magic triangle" setup where your client machines are bound to both an Open Directory setup and an Active Directory/OpenLDAP setup.

You might think that apart from these scenarios that you don't have any options for MCX management, but that's not true at all. We do have another option. Put MCX controls into the local directory service. 

 

Read on for some practical examples…. 

Let's think of a real world example. Let's imagine that you have a remote directory service that hasn't had the schema extended, and you don't have an OS X Server box providing a magic triangle setup, but you would like to manage a few simple preferences such as the loginwindow, perhaps disabling automatic login, and disabling password hints.

We could do this simply by pushing out appropriate preferences, or writing to the given preference files, but doing this with MCX gives you some major advantages.

Firstly, you'll find that some of Apple's preference panes will respect an MCX setting and actually disable the GUI controls for a given preference. For example, if you enforce FileVault with MCX, you'll see that users can't actually click on "Turn Off FileVault" in the Security preference pane.

Secondly, even when GUI controls don't disable themselves for MCX, you don't have to worry about the relevant setting being overwritten by a user and you scripting it to be automatically reset. MCX will sort this all out at login.

So to get started…. We're going to create a Computer record in the DSLocal domain (where all your local users and groups are stored) that sets the appropriate preferences. To get started, download the Server Admin Tools from Apple, and open up Workgroup Manager.

We have two ways of creating a "localhost" Computer record.

First, the command line way, which is probably what you'll use if you want to script this for all your machines, perhaps as a launchd item, or perhaps as a post-script for your imaging process.

sudo dscl . -create /Computers/localhost<br />sudo dscl . -create /Computers/localhost RealName localhost<br />sudo dscl . -create /Computers/localhost GeneratedUUID &#36;(uuidgen)<br />sudo dscl . -create /Computers/localhost ENetAddress &#36;(ifconfig en0 |grep ether | awk &#39;{print &#36;2}&#39;)<br />sudo dscl . -create /Computers/localhost IPAddress 127.0.0.1<br />

Secondly, the Workgroup Manager way.

  • Open up Workgroup Manager
  • Don't login to a server, but go up to the Server menu and choose "View Directories"
  • Make sure you've selected the DSLocal domain "/Local/Default" in the node bar, just below the toolbar in Workgroup Manager
  • Click on the padlock icon to authenticate as an admin
  • Select the Computers pane, the third icon from the left, the single square icon
  • Click onthe "New Computer" toolbar icon.
  • Under the "General" tab, set the Name and Short Name to "localhost"
  • Under the "Network" tab, set the Ethernet ID to that of the local ethernet interface ("ifconfig en0" or "networksetup -getmacaddress en0") and the IP Address to "127.0.0.1"

Now we have a localhost computer record, and you can start managing preferences for it. Most of you should be aware of the kinds of things you can do here, but we're going to run through a quick example.

  • Open up Workgroup Manager, select the localhost Computer record, select "Preferences" in the toolbar, and choose the "Login" group
  • Select the "Options" tab and click on "Always"
  • Uncheck "Show password hint…" and "Enable automatic login"

As of 10.5, Apple have given us some excellent new tools for examining MCX data. Firstly we have some new commands for dscl, and we're going to use "mcxread" to view the settings we just created.

&#36; dscl . -mcxread /Computers/localhost<br />App domain: .GlobalPreferences<br />Key: com.apple.autologout.AutoLogOutDelay<br />State: always<br />Value: 0<br /><br />App domain: .GlobalPreferences<br />Key: MultipleSessionEnabled<br />State: always<br />Value: 0<br /><br />App domain: com.apple.loginwindow<br />Key: RetriesUntilHint<br />State: always<br />Value: 0<br /><br />App domain: com.apple.loginwindow<br />Key: AdminMayDisableMCX<br />State: always<br />Value: 0<br /><br />App domain: com.apple.loginwindow<br />Key: com.apple.login.mcx.DisableAutoLoginClient<br />State: always<br />Value: 1<br /><br />App domain: com.apple.loginwindow<br />Key: DisableConsoleAccess<br />State: always<br />Value: 0<br /><br />App domain: com.apple.loginwindow<br />Key: UseComputerNameForComputerRecordName<br />State: always<br />Value: 0<br /><br />App domain: com.apple.loginwindow<br />Key: EnableExternalAccounts<br />State: always<br />Value: 1<br /><br />App domain: com.apple.systempreferences<br />Key: com.apple.preferences.users<br />State: always<br />Value: (<br />    MultipleSessionEnabled<br />)<br /><br />App domain: com.apple.MCX<br />Key: DisableGuestAccount<br />State: always<br />Value: 1<br />

We also have "mcxset", "mcxedit", "mcxdelete", "mcxexport", "mcximport" and "mcxhelp" which should all be reasonably self-explanatory.

If you're reading the whole article first before actually running through the steps (which is probably a good idea… 🙂 ), here is an alternative way of disabling password hints and automatic login using "mcxset". If you have set things up in Workgroup Manager already, you can go back and turn the preferences off if you want to try setting them from the command line.

sudo dscl . -mcxset /Computers/localhost com.apple.loginwindow RetriesUntilHint always 0<br />sudo dscl . -mcxset /Computers/localhost com.apple.loginwindow com.apple.login.mcx.DisableAutoLoginClient always 1<br />

Pretty easy really huh?

As noted above, the advantage of doing things this way rather than by writing to the preference file directly is that OS X is smart enough to "know" that this is a managed preference and will disable the relevant GUI control.  You'll see once the above settings are applied that the checkbox for "Show password hints" and the dropdown for "Automatic Login" in the Accounts preference pane are now disabled, and users can no longer enable them.

One thing to note is that we have this excellent new tool "mcxquery" which allows us to view the composited MCX settings for a given user, group and computer combination like:

mcxquery -user donbradman -group legends -computer staff1

but unfortunately there seems to be a bug with mcxquery not actually reporting results from the DSLocal domain, so you can't use it to examine these settings.

 

So what are the implications of this? Well remember that as of 10.5, the horrible, monolithic, mysterious NetInfo database is gone, and we now have a nice new shiny DSLocal setup that uses standard plists instead.

This means that all of these settings we've been running through are stored in a single file on the client machine, namely:

/var/db/dslocal/nodes/Default/computers/localhost.plist<br />

The only machine specific data in this file is the ethernet address of the local machine. This means these settings are really easily integrated into an existing imaging setup such as Radmind or NetRestore, and a simple startup script can replace the ethernet address of the localhost.plist file with the correct one for the current host.

A few of us who have been using Puppet for systems management are looking into writing a new MCX management type for it that should make this stuff even easier. Look for a follow up article later on this.

Even if you don't have any kind of imaging infrastructure in place, you could use svn/cvs or even curl to grab the relevant plist from a central location on startup.

All we need now is a nice snappy name for this to compete with "Magic Triangle" and "Cylinder of Destiny"…. We're looking for suggestions in the comments… 🙂

1 Comment

  • Forgive the lack of explanation.


    Author of Mac HelpMate
    http://www.macworkshops.com/machelpmate
    Mac OS X IT Training
    https://www.macworkshops.com/most/course.html

  • “Think Globally, Act DSLocally?”

  • One preference that would be nice if it could be managed is the “Require password to wake this computer from sleep or screen saver”. I don’t seem to see a way to do this with Workgroup Manager. Is there a way to do this with a dcsl mcxset command?


    _gary

    • To set the screen lock preference just import the ByHost preference into WGM from a client machine and set the policy to always.


      Breaking my server to save yours.

      Josh Wisenbaker
      http://www.afp548.com

    • Assuming you’re doing it to the localhost record we made above:

      sudo dscl . -mcxset /Computers/localhost com.apple.screensaver.ByHost askForPassword always 1

      • Can anyone verify managing com.apple.screensaver.ByHost askForPassword always 1 actually works? On my test machines, the “Require password to wake this computer from sleep or screen saver” in the Security prefs pane is greyed out, but unchecked. So this almost has the opposite of the desired effect: the screen saver is turned OFF and the user cannot turn it on…

        Very nasty. I may have to return to using

        defaults -currentHost create com.apple.screensaver askForPassword -int 1

        -Greg

  • Or maybe Home Rule Subversion 😉

  • although I like anything with “subversion” in the title, how about “group magic?”

    In the windows world, this sort of thing is called “group policy”. “policy” just gives me the creeps though, along the lines of “verboten”… thus let’s use a piece of the triangle to get “group magic

  • I think “The Magic Cow Bell” as in, that needs more cow bell.

  • I think I’m missing something. The article says “Let’s imagine that you […] don’t have an OS X Server box providing a magic triangle setup”. Then it talks about setting preferences up using Workgroup Manager. If I don’t have an OS X server, how do I have WGM? Maybe my imagination isn’t good enough 🙂

    As a matter of fact, I do have an OS X server, or at least access to one. However, it isn’t running Open Directory services, and (for a variety of reasons) isn’t likely to have that enabled in the near future. So, do I need to drag “Workgroup Manager.app” to a client machine and run it from there? Is WGM already on Leopard client somewhere? I don’t see it in the Utilities folder, but maybe it’s buried somewhere.


    Kevin Graham
    OIT Student Computing Services
    Princeton University

    • WGM is a free download as part of Apple’s server tools. No need to have a server around. WGM is then as happy to work against the local directory as it is against an LDAP directory.


      Changing the world, one server at a time.
      Joel Rennich

  • quote: “sudo dscl . -create /Computers/localhost ENetAddress $(ifconfig en0 |grep ether | awk ‘{print $2}’)”

    FWIW: This can be shortened slightly and more efficiently (by removing the call to grep) — awk can already do pattern matches.

    sudo dscl . -create /Computers/localhost ENetAddress $(ifconfig en0 | awk ‘ /ether/ {print $2}’)

    HTH

  • On Mac OS X Server the loginwindow does not recognize settings for SHOWFULLNAME. Every other setting is read but not this one. I wanted to have loginwindow to show the list of users but loginwindow only shows user/password, even if dscl . -mcxread /Computers/localhost lists

    App domain: com.apple.loginwindow
    Key: SHOWFULLNAME
    State: always
    Value: 0

    and the OPEN LDAP Server is switched off (only /Local/Default is searched).
    In the System Preferences the two options are disabled (showing this option is managed, even if all computer (and computer group) entries are deleted in Workgroup Manager)

  • lastdanstanding

    I am new to MCX and found this page because of its brief reference to managing FileVault. I am attempting to enforce FileVault in my environment with only partial success.

    Using these instructions I have created a managed preference for the System Preferences’ key com.apple.preferences.accounts.forceFVForNewUsers. It is functional in that new accounts created are forced to be FileVaulted. But users are still able to disable FileVault in the Security prefpane after the fact.

    This is counter to what is said in this article about users not being able to click the “Turn Off FileVault” button, so I am confused. Any idea what I might be missing? Do I need a second managed preference for the “GUI clicking behavior”?

    Any help greatly appreciated!

    Cheers,
    -Dan

Leave a reply

You must be logged in to post a comment.