I've brought this up with Apple, and sadly do not have a good solution. Both solutions they offered me, which I've used in the past and was dissatisfied with, aim to disable all of iCloud. As far as my investigation has uncovered, there is no way to perma-disable the one feature.

The first option, and the sloppier IMHO, is to use MDM to block access to the iCloud pane of System Preferences. This has several issues though:
- Users can still setup iCloud through the Internet Accounts pane of System Preferences, or through Mail, Messages, Contact, Calendars, Reminders, ... ... ...
- Since System Preferences restrictions via MDM is a white list, any 3rd party applications your users which to install, that have System Preferences panes (Box, Dropbox, Java, Flash, Flip4Mac, etc.) have to be pre approved by you in order to function fully (I suppose this could be an added benefit in some environments).
- As soon as you enable any MDM profiles around System Preferences, you likely will encounter odd issues. The show stopper for us was that non-bound users lost the ability to change their passwords.
- This doesn't block the feature, just access to the feature. Advanced users will find a way to circumvent it in the GUI, or can just import preferences from an unmanaged machine.

The other alternative Apple suggested would be to block all iCloud traffic at our firewall. The biggest issue I ahv eiwth this is that many of our users are remote employees and thus spend a lot of time outside the firewall.

Truth be told, I'm actually shocked that more enterprise installations are not more upset about this feature and making a huge stink about it.

@c0n0r

Truth be told, I'm actually shocked that more enterprise installations are not more upset about this feature and making a huge stink about it.

They are. Apple just doesn't care. Never has, never will.

The only answer, of course, is to make it an HR/Infosec/IT issue. If you are found to be using iCloud keychain, you are disciplined - up to or including termination.

Truth be told, I'm actually shocked that more enterprise installations are not more upset about this feature and making a huge stink about it.

Not making a big stink, but will not deploy Mavericks until we find a way to disable iCloud keychain.

if you disable iCloud don't you disable the keychain too?

Hi gus one way possibly may be to either use mcx or config profiles to control access the that preference pane. The only problem with that is every time you install a new preference pane in the system you have to update the management framework to allow it.

After a while it does become a bit of a pain

in 10.9 there is the choice of either allow pref panes or dont allow pref panes, new ones added when using the don't allow work now. of course you have to use 10.9 server, and it only works on 10.9 but it works.

@ nessts thanks thats good to know :)

Black-listing the iCloud pref pane doesn't block iCloud from being setup any one of a dozen different ways, including from applications like Mail, Messages, Reminders, ... ... ...

@c0n0r][/url Ah...bummer, didn't think of that. I think you guys are right, It will be a security concern and I've lamely ignored it up until now.

@c0n0r that is true, i suppose a good launch daemon to remove icloud preferences might be in order plus there is the don't save to iCloud profile the Mac Enterprise folks came up with.

@nessts I agree that a LaunchD process can undo SOME of the damage... but the moment the user turns on iCloud keychain, their domain name and password, not to mention pgp/gpg mail PRIVATE keys are uploaded to Apple. Sadly, by the time a process fires off to kill the settings, that worst of the damage is already done.

We've been working with Apple on this pretty heavily, but there remains no clear solution.

To make matters worse, Sam Keeley over at AFP548 just posted a security hole where you can easily get around System Preferences Panes blocked via Profiles.

http://www.afp548.com/2013/12/16/system-preferences-profiles-in-mavericks-plus-a-security-hole/

I saw the other thread that mentioned this but hadn't had the chance to look until just now. Just FWIW, this vuln exists with the older MCX settings as well, presumably on all versions of OS X. I tested on 10.8.5 and was able to uncheck a greyed out Preference Pane (disabled with the EnabledPreferencePanes array in an MCX setting) and when I relaunched System Preferences I was able to select it from the View menu and it opened right up! Nice :(
So apparently this bug has existed for a long while now and was apparently just discovered.

I can't believe Apple doesn't see this as a security hole (according to Sam in the article). I knew about other easy workarounds if a user is an admin, but this seems to work even with a standard account. Oh boy… I see lots of school kids getting into any Preference Pane they want shortly.

The only good news if you can call it that, is Sam figured out a temporary workaround by managing the HiddenPreferencePanes key in the plist. That's at least something.

Forgive my ignorance as I haven't had a close enough look at this feature in Mavericks yet. And while I completely believe and empathize with you all about Apple's "this is how we do it, get on board or get out of the way" bravado, I did see the quote below from an Apple FAQ (http://support.apple.com/kb/HT5813?viewlocale=en_US)

Can I set up iCloud Keychain so that my data isn't backed up in the cloud? Yes. When setting up iCloud Keychain, you can skip the step for creating an iCloud Security Code. Your keychain data is then stored only locally on the device, and updates only across your approved devices. Important: If you choose to not create an iCloud Security Code, Apple will not be able to recover your iCloud Keychain.

I'm doubtful but I hope this somehow helps

@evarona It's not that the feature can't be disabled, it's a simple checkbox in the iCloud pane of System Preferences to disable it completely (or, through the process you outline). The problem is that there doesn't appear to be a way to ENFORCE it being disabled. I trust my users, but I also know that not all of them read everything I send, so I can't blindly trust that no one is going to enable this feature and thus undermine the security of the organization at large.

@evarona][/url][/url, Yes, that can be done, but needs to be done by the user setting up iCloud. I don't believe there's any way to force that to happen in a management scenario. So now you're relying on your users, some which may have the attention span of a chipmunk, to pay attention to that and make the correct choice, assuming they even know they can make that choice.
I don't know, but, I doubt most security teams would get the warm and fuzzies knowing that.

I think in iOS profiles you can actually force data to not be backed up to iCloud. It would be real nice if Apple added a similar setting, via Profile say, that disabled syncing iCloud keychains to the cloud that can be pushed to OS X devices. But there is no such thing.

Ah, I see the point now. So we're back to all or nothing with iCloud. At our financial-based company we disabled iCloud completely, even blocked it at the proxy. It sucks because I love having my bookmarks synched across devices. (I tend to browse/bookmark on the iPad and then research more fully on the Mac.)

For us, it's a simple choice of convenience or "protect the brand". Sometimes it sucks but in this case choosing the latter is easier to for me manage and keeps the paychecks coming.

Perhaps someone else can get more creative than I with ~/Library/Preferences/MobileMeAccounts.plist I see it can be modified. Any thoughts on changing the Services Item 7 (Keychain_sync) report back url to 127.0.0.1? I tried just deleting it, however once I restarted it repopulated.

# Disable internet account plugins
##
if [ -e /System/Library/InternetAccounts ];
then echo Internet Plugins are enabled. Disabling sudo rm -rf /System/Library/InternetAccounts/*
fi

Might want to just delete the one for icloud, or move it, or whatever your management preference is.

iCloud accounts can be setup in any application that has native iCloud connectivity. Disabling the system pref only disables the most obvious route to set it up, and doesn't really increase security.

Early next year (at this point), I will be testing blocking or removal of /System/Library/CoreServices/Keychain Circle Notification.app, which seems to focus only on iCloud Keychain synchronization without affecting the other iCould apps. Of course, testing may tell another story. "Trust, but verify."

I'll post results here later this week.

So after removing the Keychain Circle Notification.app (compressed the app and left it on Desktop for the test), tried activating iCloud Keychain. The activation seemed to go well, but the console revealed a few entries to indicate :

1/2/14 8:35:40.318 AM secd[199] EnsureFreshParameters_block_invoke_2 SOSCloudKeychainSynchronizeAndWait: The operation couldn’t be completed. (SyncedDefaults error 1020 - Remote error : Network unreachable**)

1/2/14 9:52:05.450 AM secd[234] securityd_xpc_dictionary_handler WiFiKeychainProx[204] DeviceInCircle The operation couldn’t be completed. (com.apple.security.sos.error error 2 - Public Key not available - failed to register before call)

1/2/14 9:52:28.890 AM com.apple.launchd.peruser.502[151] (com.apple.security.keychain-circle-notification[286]) Job failed to exec(3) for weird reason: 2

We are also looking into the implications of blocking https://p-##-escrowproxy.icloud.com:443 (the ## indicates server numbers from 01 to 20, possibly higher) at the firewall level. As indicated in ~/Library/Preferences/MobileMeAcounts.plist, it is the listed ProxyURL for Keychain Sync.

Found it. Delete these files (we're doing it in the build with bash script):

#! /bin/bash

# Remove applications that allow iCloud Keychain synchronization
#Leave other iCloud services alone

sudo rm -rf /System/Library/CoreServices/Keychain Circle Notification.app
sudo rm -rf /usr/libexec/KeychainMigrator

This allowed iCloud Keychain to be activated on the local Mac, but did not pass any credentials across to other test devices, while Notes, Reminders, and Calendar items came through normally. It is important to run this script during the build, or at the least before a user logs onto the system. As C0n0r points out in this thread, once the keychain is synced, the damage is done.

We will be monitoring the building when 10.9.2 is introduced to see if the script needs to be added to remove the files once again.

I see the two preference files in ~/Library/Preferences that indicate iCloud Keychain is in use: com.apple.security.cloudkeychain3.keysToRegister.plist has an UnlockedKeys string and MobileMeAccounts.plist has a true/false dictionary for KEYCHAIN_SYNC being enabled. I'm working on the correct PlistBuddy command to use in an Extension Attribute. I figure if I can correctly report on who turns it on, I'll just have InfoSec get the Smart Group notification and we'll put a policy in place that will have the end user contacted to turn it off and reset their password on the spot.

I have an EA that checks to see if iCloud Keychain is enabled. I hope this helps:

#!/bin/sh

currUser=$( /usr/bin/who | /usr/bin/awk '/console/{ print $1 }' )

Keychain=$( /usr/libexec/PlistBuddy -c "Print Accounts:0:Services:7:Enabled" "/Users/$currUser/Library/Preferences/MobileMeAccounts.plist" )

echo "<result>$Keychain</result>"