An extension attribute to identify violators is fine and dandy, but at that point the damage is already done. Passwords can be changed easily enough, but certificates are a little harder to reissue and redistribute public keys for (especially when that can include email signing certs for both larger number of internal users and any external clients).

Contacts is in a similar state... sure, you can flag people that have violated policy, but they've already synced their contacts to the cloud, and smashed EU privacy law to dust.

@daniel.behan][/url][/url i made a small change to the script so it tests for 10.9, otherwise there are false readings.

#!/bin/sh
OSVersion=$(sw_vers -productVersion)

if [ $OSVersion == 10.9 ]; then
    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>"

else 
    echo "<result>False</result>"
fi

@adkinsan][/url][/url i'm seeing a broken keychain here when i delete the files you suggest. the keychain itself seems to work but the keychain.app won't open and eventually crashes. you see the same results?

@Bendelaat - Yes, we've noted that removal of the CloudKeychainProxy.bundle does not prevent the local keychain, but does prevent Keychain Access from launching. If this bundle is in place, iCloud Keychain seems to work fine with the other two removed (still testing on that).

Back to the lab.

@Bendelaat Thanks for the update. I had a smart group scoped to the EA to only check for 10.9 machines, but that's a nice edit.

@adkinsan I tried your script and Keychain Access.app won't launch afterwards.

as anyone tried something like Wireshark to determine if we can block it at the port it uses?

No expert here but it looks like the iCloud Keychain points to https://p04-escrowproxy.icloud.com:443. I'm not sure if/when this will change but you add an entry to the /etc/hosts file to point it back to 127.0.0.1.

This is one way of blocking it from syncing to the cloud. Obviously doesn't fix any damage that has already been done.

@krichterjr - You'll want to add entries for https://p01... through at least https://p20 (as many as we've seen), possibly more. Nice idea to edit the /etc/hosts file, thanks!

We have tested simply pulling out the iCloud Preference. This doesn't seem to have a ill effect, although more of a broadsword than a scalpel.

Here's a script I threw together that grabs the URL from that plist and the appends the hosts file. I'm sure the script could be cleaned up but this is what I put together.

#!/bin/sh

####################################################
#
# This script checks the url iCloud Keychain uses 
# and adds a record to the /etc/hosts file to point
# it back to itself.
#
# Written by: Kenny 1/17/14
#
#####################################################


# Get the current user.
currentUser=`ls -l /dev/console | cut -d " " -f4`
echo "$currentUser"

# Get the URL iCloud Keychain contacts 
iCloudKC=`defaults read /Users/$currentUser/Library/Preferences/MobileMeAccounts.plist | grep -A 4 "KEYCHAIN_SYNC" | grep "escrow" | cut -d ':' -f 2 | sed 's/[/]//g'`
echo "$iCloudKC"

# Append the /etc/hosts file
echo "127.0.0.1       $iCloudKC" >> /etc/hosts
echo "host file appended"

I seem to remember that /etc/hosts is no longer authoritative - if a fqdn can resolve by DNS but not etc/hosts it will still resolve.

Has anyone tried the /etc/hosts method and can confirm that iCloud is blocked? I also presume this will block all iCloud services, not just keychain, can anyone confirm?

Looking through ~/Library/Preferences/MobileMeAccounts.plist, each service resolves to a unique URL, making it potentially possible to manage individual services within iCloud assuming the proper .mobilemeconfig file can be crafted to specify some fields and allow others to be entered by the end-user.

After making this change, if I ping the url pulled from the plist file (in my case p04-escrowproxy.icloud.com) it responds from the IP (127.0.0.1) I assigned. It's my understanding that the computer would look to the /etc/hosts file before any DNS.

Now, I did read something about if it does not resolve with IPv4 it may try to resolve through IPv6. An additional entry could be added that looks something like this.

::1 XXXX-escrowproxy.icloud.com

Probably not the best, but we've taken a more blunt approach. Our chief problem with iCloud is the KeyChain feature and DO NOT WANT user(s) passwords to be in escrow with Apple. Fellow JAMF/Casper admin adkinsan wire~sharked iCloud and found Apple's servers as using: https://p01-escrowproxy.icloud.com:443
The server(s) also appear to be clustered and using numbers running through at least p01...p20-escrowproxy.icloud.com:443

So far, Mavericks still refers to the /private/etc/hosts file and we've added several entries to the file to redirect network traffic going to Apple's escrow server(s), to instead go to IP# 0.0.0.0 Like this:

##
#Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

# Block the following hosts
0.0.0.0 icloud.com
0.0.0.0 p01-escrowproxy.icloud.com
0.0.0.0 p02-escrowproxy.icloud.com
0.0.0.0 p03-escrowproxy.icloud.com
0.0.0.0 p04-escrowproxy.icloud.com
0.0.0.0 p05-escrowproxy.icloud.com
0.0.0.0 p06-escrowproxy.icloud.com
0.0.0.0 p07-escrowproxy.icloud.com
0.0.0.0 p08-escrowproxy.icloud.com
0.0.0.0 p09-escrowproxy.icloud.com
0.0.0.0 p10-escrowproxy.icloud.com
0.0.0.0 p11-escrowproxy.icloud.com
0.0.0.0 p12-escrowproxy.icloud.com
0.0.0.0 p13-escrowproxy.icloud.com
0.0.0.0 p14-escrowproxy.icloud.com
0.0.0.0 p15-escrowproxy.icloud.com
0.0.0.0 p16-escrowproxy.icloud.com
0.0.0.0 p17-escrowproxy.icloud.com
0.0.0.0 p18-escrowproxy.icloud.com
0.0.0.0 p19-escrowproxy.icloud.com
0.0.0.0 p20-escrowproxy.icloud.com
0.0.0.0 p21-escrowproxy.icloud.com
0.0.0.0 p22-escrowproxy.icloud.com
0.0.0.0 p23-escrowproxy.icloud.com
0.0.0.0 p24-escrowproxy.icloud.com

Unfortunately we can't use a wildcard entry like: *-escrowproxy.icloud.com in the /private/etc/hosts file, so listing two dozen servers is a crap shoot at hopefully blocking every server used we seen used so far and a few more. This should ~in theory~ work in the background to prevent the iCloud from connecting to escrow servers and uploading passwords. So, we've come up with a small .pkg with a "block.txt" file that contains the hostname(s) of Apple's servers as payload and a postflight script to append the text to the existing /private/etc/hosts file. Like this:

###################################
# Append a payload file (block.txt) # to the /private/etc/hosts file
###################################

# Make a copy of the original hosts file beforehand
cp /private/etc/hosts /private/etc/hosts.bkup

# Append the original hosts file with our hostname list in the block file
# Output the result to a new file titled newhosts
cat /private/etc/hosts - /private/etc/block.txt > /private/etc/newhosts

# Replace the original hosts file with our new appended version
mv /private/etc/newhosts /private/etc/hosts

# Remove the building files, but leave the bkup file alone
rm /private/etc/block.txt
rm /private/etc/newhosts

exit 0

Make sure to use Text Wrangler or something similar to ensure the block.txt file is in raw text with no extra formatting characters. Also make sure there is ONLY a carriage return after the last host-name entry. 10.7 and 10.8 don't seem to mind extra items after the list, but 10.9 is more picky. I'm sure somebody, somewhere has found a better solution than this. But it's all we've been able to scrap together so far. Comments welcome.

While you can't use wildcards in /private/etc/hosts, you can in your scripts... so why not, rather than backing uo the file and replacing it with your own, instead just insert the needed entries in a for loop. Without testing it, I would use something like:

#!/usr/bin/env bash

HostFile="/private/etc/hosts"
ditto -v "$HostFile" /private/etc/hosts.bkup
CurrentBlockHosts=$(cat "$HostsFile" | grep -c "icloud")
if [[ "$CurrentBlockHosts" -eq 25 ]]; then
    exit 0
elif [[ "$CurrentBlockHosts" -eq 0 ]]; then
    echo "##" >> "$HostFile"
    echo "# Block the following hosts" >> "$HostFile" 
    echo 127.0.0.1 icloud.com >> "$HostFile"
    for (( i = 1; i < 10; i++ )); do
        echo "127.0.0.1 p0$i-escrowproxy.icloud.com" >> "$HostFile"
    done
    for (( i = 10; i < 25; i++ )); do 
        echo "127.0.0.1 p$i-escrowproxy.icloud.com" >> "$HostFile"
    done
else
    logger "[iCloudBlocker] Found $CurrentBlockHosts iCloud entries"
fi
exit 0

Sorry, forgot to add... I would then set this to run via a Casper policy once a day/week/month/decade (the first logic branch ensures that once it's successfully modified a system it just exits gracefully, allowing you to scope to all systems). I would then make a second policy to look for entries in syslog containing "[iCloudBlocker]" to flag the machine for personal review as it's in some odd state that automation would have difficulty fixing.

Still looking down the surgical path, I moved the following file into a .zip file:

/System/Library/PrivateFrameworks/CloudServices.framework/XPCServices/com.apple.lakitu.xpc/Contents/MacOS/com.apple.lakitu

This caused activating Keychain Sync to authenticate with an Apple ID, prompt for a security code, and ask for a phone number that can receive SMS messages. However, the return code never shows up on the phone.

And Keychain Access launches and tests fine.

Again, I agree with C0n0r that surgery is not desirable, but I also know that those to whom we answer tend to prefer it.

We will still be looking at using the /private/etc/hosts file, as well as the PF firewall for several levels of managerial happiness.

While setting this up in the hosts file, and running Wireshark to test, it turns out I needed to add in lines for p*-keyvalueservice.icloud.com as well, not just the escrowservice. With just the escrowservice url redirected, it looks as if the iCloud keychain still works - I haven't tested this fully yet.

@Aaron

Thanks for reporting this as I haven't run Wireshark to fully test this yet. However, looking at the MobileMeAccounts.plist it looks like the 'p*-keyvalueservice.icloud.com' is associated with the Back to My Mac service. Can you confirm this was not enabled when you ran Wireshark?

@krichterjr

Correct, BTMM is off - but I want to block that as well, so it works out for me in the end.

This is what I see when enabling iCloud Keychain:
external image link

If I just block the escrowservice.icloud.com URL, then the iCloud Keychain still goes through the motions without error (asks me for my Apple ID, asks me to enter a 4 digit PIN, etc) so it would seem that it works ok. I don't really have a spare Mac at the moment to test to see if I can actually download the contents of my keychain.

If I block the keyvalueservice.icloud.com URL as well, I get an error when enabling Keychain saying "iCloud Keychain couldn't be set up because there was a problem communicating with iCloud."

@Aaron][/url

Thanks for sharing that info. Definitely good to know!

My EA showed a false positive. Looking by Service number won't be accurate depending on what services are in use. Here's an updated one that seems to work:

#!/bin/sh

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

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

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