Archive for the ‘DirectoryService’ category

Mountain Lion and MCX

July 27, 2012

In my last post, I asserted that Local MCX still works in Mountain Lion. And it does. But that doesn’t mean there aren’t issues to deal with.

There have been various reports of certain MCX settings not behaving correctly — for example, it appears that currently you can’t use MCX to manage Dock settings “Once” — only “Always” management works. (And that’s not useful for us — it doesn’t allow one to set certain Dock defaults and then leave the Dock alone for the user to modify as they’d like.)

There’s another challenge if you use Local MCX in an alternate local DirectoryService node, as described here:

In Mountain Lion, dscl refuses to write to non-default local nodes:

# sudo dscl /Local/MCX create /Computers/foo
create: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)

This makes manipulating things in a non-default local node much harder than it was in Leopard through Lion.

You can still copy files into /private/var/db/dslocal/nodes/MCX, and that can serve as a workaround for now. All of the packages I use to configure Local MCX do exactly that — they install plist files into /private/var/db/dslocal/nodes/MCX/computergroups. But there is one major exception.

I have one package that does the setup for Local MCX. It makes sure the /Local/MCX node is present, makes sure it is in the search path, and makes sure that an appropriate record exists in /Local/MCX/Computers to represent the current local machine. This requires writing to the /Local/MCX node to dynamically create the computer record. We can’t just install a file, because the contents of the data in the computer record are unique for each computer.

So there’s our problem: we can’t use dscl to create a computer record in the /Local/MCX node, yet we must dynamically create an object in that node.

There are two solutions, both which rely on the fact that all objects in Local DirectoryService nodes are actually just plist files.

The first:  We could use another plist creation tool to create the needed plist. We could use defaults or PlistBuddy, for example. But that would require us to take the time to figure out how to use one of those tools to create a file that is the same as if dscl created it.

The second: Use dscl to create the record in the /Local/Default node. Then just move the plist from /private/var/db/dslocal/nodes/Default/computers/foo.plist to /private/var/db/dslocal/nodes/MCX/computers/

The second approach is the one I decided to take, since it seemed easier.

Here is the script I currently use for initial Local MCX setup. If you are currently using Local MCX on Lion or earlier, I hope it is of some help if you want to continue to use Local MCX on Mountain Lion.

Mountain Lion: suppress Apple ID / iCloud prompt

July 26, 2012

This question has come up a few times in the past few days, so I thought I’d better document it.

On Mountain Lion, how do I suppress the Setup Assistant that prompts for an Apple ID to setup iCloud?

The answer is to use MCX. You can use Local MCX, network directory-based MCX, or Profiles.

You can read more about Local MCX here. (And yes, Local MCX still works in Mountain Lion.)

# dscl /Search mcxread /ComputerGroups/setupassistant
App domain:
Key: DidSeeCloudSetup
State: once
Value: 1

App domain:
Key: LastSeenCloudProductVersion
State: once
Value: 10.8

Here is a profile that will do the same thing. You can use the command-line profiles tool to install it.

NOTE: for whatever reason, this doesn’t work if the management frequency is set to “Always” or “Forced”. It does work when set “Once”. I have not tested “Often”, but I imagine that would work as well.

MacTech magazine May 2012

June 11, 2012

The May 2012 issue of MacTech is available via the iPad app; dead-tree mailings can’t be far behind.

In this month’s issue I detail a method for creating packages to create a local admin account on your managed machines. This same package will create a working local admin account on Leopard through Lion (and possibly beyond), and will work in the stripped-down Lion install environment. If you need to update the local admin password, you can just install a newer version of the exact same package.

This fits in with my general theme for 2012: which is “Don’t Repeat Yourself!”

Yet again with the Local MCX

March 12, 2010

Earlier this week, I outlined some changes to my Local MCX implementation. I moved all of my computer and computergroup records (that existed solely to hold MCX data) from the Default local DS store at /var/db/dslocal/nodes/Default/ to a newly created node at /var/db/dslocal/nodes/MCX/.

In order to make this new local node do anything useful, you have to add it to the authentication search path. In this post I used Directory Utility to perform this task. That’s great when you’re doing your initial testing, but not terribly useful when to need to roll this change out to hundreds of machines (or more!).

MCX in non-default local nodes

March 7, 2010

Based on some ideas in this thread I started experimenting with some changes to my Local MCX setup with the goal of eliminating warnings like these from /var/log/system.log:

Mar 7 10:41:19 allure[39]: MCXCCacheGraph(local_laptop, dsRecTypeStandard:Computers): Cannot cache because an existing record named "local_laptop" has conflicting attributes and must be deleted before caching.

This is a common warning when managing MCX data in the local directory service and seems to be harmless. Another seemingly related problem in when the OS deletes local_computer type records from the local DS node at startup, which isn’t so harmless, as it stops local MCX settings from being applied.

Add a user to the admin group via command line 3.0

January 14, 2010

One of the more visited articles on this site is several years old – this one on adding a user to the local admin group.

I thought I should update that information since it is somewhat out of date. Apple’s preferred and recommended way to add a user to the local admin group is to use dseditgroup, like so:

/usr/sbin/dseditgroup -o edit -a gneagle -t user admin

This -a(dds) “gneagle”, which is an object of -t(ype) “user”, to the group “admin”.

To delete a user from the local admin group:

/usr/sbin/dseditgroup -o edit -d gneagle -t user admin

You can also use dseditgroup on a network directory service if you have admin credentials for the directory server:

dseditgroup -o edit -n /LDAPv3/ -u dsadminusername -p -a gneagle -t user group_on_network_directory

This will prompt you for the dsadminusername’s password interactively. You can include the dsadminuser’s password like so:

dseditgroup -o edit -n /LDAPv3/ -u dsadminusername -P dsadminuserpassword -a gneagle -t user group_on_network_directory

dseditgroup can do many other things, like create and delete groups, add nested groups to an existing group, and check membership of a given user for a given group.

man dseditgroup for more info.

Leopard, MobileAccounts, and NFS homes

February 19, 2009

HomeSyncOn the MacEnterprise maillist, Arjen van Bochoven wrote of problems with automatic HomeSyncs under Leopard with NFS home directories. Manual syncs worked fine, but the automatic background syncs would fail with errors that looked like this:

1:: [228] Peer "network" is unable to sync. (-[SPeer_FS_PHD mountPeerVolume] (Peer-FS-PHD.m:140): "'((homePath))' is nil")
0:: [228] [2009/02/19 10:45:10.640] Peer "network" is unable to sync. Not enough peers will be available to continue syncing.
0:: [228] [2009/02/19 10:45:10.640] Aborting sync of "HomeSync_Mirror".

I saw the exact same problem in my environment. This also affected login and logout syncs. Here’s the (ugly) fix. (more…)

Macworld 2009 MCX presentation

January 7, 2009

WGM iconHere is a PDF of my presentation at Macworld SF 2008 on Managing OS X Clients with or without Open Directory.

Converting NetInfo accounts to dslocal

June 23, 2008

If you are doing an in-place upgrade from Tiger to Leopard without using the Apple Leopard Install DVD, you may need a way to convert existing local or mobile accounts from NetInfo to the dslocal store.

Here’s a script that converts local accounts; it requires the nicl binary, which you can copy from any Tiger installation.

For local accounts, it uses nicl to read the account info, and dscl to create a new corresponding account. For mobile accounts, it uses createmobileaccount to recreate the mobile account.


Enforcing FileVault on local accounts

February 8, 2008

FileVaultNew in Leopard is the ability to protect an account with FileVault as it is being created. When creating a mobile account, you can check the box to use FileVault, and this setting is easy to enforce with Workgroup Manager’s preference management as part of the Mobility settings.

If you use the Accounts preference pane to create a local account, you’ll see a new checkbox labeled “Turn on FileVault protection”, but it’s unchecked by default. What if your organization wants to ensure that all accounts — even purely local accounts — on laptops are protected with FileVault? With Workgroup Manager’s preference management, there does not seem to be a way to manage this setting in the Accounts preference pane. But you can manage it if you dig a little deeper…


Get every new post delivered to your Inbox.

Join 170 other followers