iChat/iCal 10.6 Deployment via puppet/pkg/radmin etc

[mosen]

Hey there,

Following the research i did on iChat and iCal in 10.6, I came up with a way to deploy iChat/iCal without using MCX. I’m still not sure if iChat/iCal 10.6 MCX is broken out of the box.. I havent had any replies to my latest question.

Even though I might be the only person with broken MCX for these two apps, this manual method might suit some people in mixed environments who don’t want the overhead of managing MCX, even via DSLocal.

I’m going to describe this method in general and with a puppet template, which should force kerberized iCal and iChat accounts to be managed for each workstation.

I could also provide some sorta lifecycle explanation/diagram for ManagedClient too, but I guess thats a separate article 🙂

[mosen]

[u][b]Manual Deployment of Managed Accounts in iCal (Mac OS X 10.6)[/b][/u]

There are a couple of important points to note before deploying iCal manually:

– This works best with a kerberized iCal set up. The password won’t be filled in by iCal, and iCal does not contain (from what I see) a method to supply passwords from a .plist.
– MCX normally relies on ManagedClient to transform ‘%@@yourdomain.com’ to ‘[email protected]’. ManagedClient fails (In many environments), so you need your own script/application which will apply the user details and substitute them into the .plist file (I use puppet, you could use LoginHooks or a Package postflight.. there are a lot of options). This post describes the plist after you have substituted login names.

[u][b]Crafting a plist for iCal on 10.6[/b][/u]

After ManagedClient has done its job. iCal expects a structure similar to the following, which must exist inside com.apple.iCal.plist in the user (~/Library/Preferences) or host (/Library/Preferences) domain
I.E you should insert this into the existing plist (if there is one existing):

[code]

accountsToImport

00000000-0000-0000-0000-000000000000

PrincipalURL
http(s)://ical.host.name:8443/principals/users/johnsmith/
Login
johnsmith
Kerberos
FullName
John Smith
Title
My Company
UID

[/code]

[u][b]A short guide to the dictionary keys:[/b][/u]

[b]PrincipalURL[/b] – This will determine the host name, protocol (SSL on or off), port AND the principal path for this user. Replace ‘johnsmith’ with the short
login name of the user. These are separate keys in the manifest, but iCal expects just this URL in the end.
[b]Login[/b] – Short username login for iCal Server.
[b]Kerberos[/b] – TRUE/FALSE. As stated earlier, non-kerberos may not be viable because you need to go back into the account and set the password, so what’s the point of automating the deployment? 🙂
[b]FullName[/b] – Full display name of the user, should be derived from their open directory full name “John Smith”
[b]Title[/b] – Title of the iCal account. This appears in the iCal “Sidebar” (and accounts listing), and is the heading for all of the iCal server based calendars listed for this user.
[b]UID[/b] – Leave as an empty string. iCal will call GenerateUID or something similar to make sure that the new account is uniquely identified by iCal and SyncServices buddies.

[u][b]Background Information[/b][/u]

ManagedClient is the one mechanism responsible for taking care of MCX in 10.6. It also contains the MCX Compositor, which is used to combine all of your mcx into one set.
A certain number of MCX manifests provided by ManagedClient can’t be constant like the dock (for instance). Dock hiding is on or off, on the left or on the right. iCal and iChat accounts are different for each login. For every manifest that describes something variable (account details will be different for every login), there is a post compositing section in ManagedClient.

The failure of ManagedClient to post composite some parts of the MCX and not others explains why dock might work, but not any of the things that need access to the user id, user short login or full name.

The iCal post compositing sequence goes roughly like this:

– Read user defaults (com.apple.iChat.plist)
– If we have a key called “accountsToImport” in there, proceed.
– Go through all the sub keys and make accounts out of them. By default – the manifest will use the special GUID 00000000-0000-0000-0000-000000000000. For multiple accounts i suppose you could just increment by 1.
– Set up a blank dictionary for all the account info
– Get the principal URL
– Grab the login, shove into dictionary
– Grab the ssl,host,port portions of principalURL, shove into dictionary
– Grab the kerberos flag, set that.
– Set the refresh interval based on default(?) Not 100% sure, but it doesn’t reference the .plist.
– Generate a nice GUID string for our account, set that.
– Set the path.
– Set the full name.
– Set the title.
– Set the flag that says the calendar is enabled, hardcoded to TRUE.
– Set the flag that says the calendar is twisted open/expanded, hardcoded to TRUE.
– Take this account info and give it to the principal manager.
– Make the contents of “accountsToImport” empty, because we processed the account(s), and they shouldn’t be re-executed every time you start iCal.

I hope that my investigation of the ManagedClient MCX post composition and iCal account import functionality has helped you in your environment.
Feel free to add anything or correct any mistakes, I will edit the post as necessary.

Mosen.

[mosen]

[u][b]Manual Deployment of iChat (XMPP/Jabber) accounts in Mac OS X 10.6[/b][/u]

This post describes a method of manually deploying iChat jabber accounts via a custom plist.
Again, a couple of points to note (mostly the same caveats with iCal):

– This works best with a kerberized iChat set up. iChat does not recognise any pre-supplied password.
– MCX normally relies on ManagedClient to transform ‘%@@yourdomain.com’ to ‘[email protected]’. ManagedClient fails (In many environments), so you need your own script/application which will apply the user details and substitute them into the .plist file (I use puppet, you could use LoginHooks or a Package postflight.. there are a lot of options). This post describes the plist after you have substituted login names.
– Some people have posted ways of manually inserting iChat accounts using the plist, but they are not regarded as managed (i.e the user may modify those accounts after they are installed). The method I’m describing is for accounts that will be enforced.

[u][b]Crafting a plist for iChat on 10.6[/b][/u]

ManagedClient is expected to take your manifest keys from XMPPAccount, apply formatting, and then write them as a dictionary called ManagedAccounts.
If you have existing accounts, you need to be careful that you won’t overwrite the “ActiveAccounts” or “Accounts” keys inside com.apple.iChat.Jabber.plist. If you clobber those keys then the users will lose their existing accounts. If you don’t care, then go ahead and wipe out the contents.

The GUID here “00000000-0000-0000-0001-000000000001” is special. It indicates the account type (Managed/Jabber), you can’t use another key for a managed jabber account.

This is what iChat expects for a “Managed” account in com.apple.iChat.Jabber.plist (new entry in the root of the plist dictionary):

[code]
ManagedAccounts

00000000-0000-0000-0001-000000000001

AllowSelfSignedSSL
1
AutoDiscoverHostAndPort
1
Description
account title here
LoginAs
[email protected]
ServerHost
ichat.server.hostname
ServerPort
5222
ServerSSLPort
5223
UseKerberos5
1
UseSSL
1

[/code]

[u][b]A short guide to the dictionary keys:[/b][/u]

[b]AllowSelfSignedSSL[/b] – 0/1 whether to allow self signed SSL certificates. I could go into a discussion about self signed SSL but just do your research. Leave it on if unsure.
[b]AutoDiscoverHostAndPort[/b] – 0/1 whether to auto discover host and port. I believe this uses your DNS SRV records to locate the port and host for a particular jabber domain.
[b]Description[/b] – Description of the account. Appears at the top of the iChat window.
[b]LoginAs[/b] – Jabber username, typically this will be user@domain and not just user.
[b]ServerHost[/b] – Name of the server to use for this account.
[b]ServerPort[/b] – Port to use in non-ssl mode.
[b]ServerSSLPort[/b] – Port to use in SSL mode.
[b]UseKerberos5[/b] – 0/1 Whether to use kerberos as authentication.. I think its the best solution to try and utilize SSO.
[b]UseSSL[/b] – 0/1 Whether to use SSL for the iChat connection.

Some other keys may apply to the managed account, although I haven’t personally tried them yet. (Probably all relevant normal account keys apply to managed ones) such as:

[b]UseMachineName[/b] – Use the computer name as the location
[b]XMPPTLSEnabled[/b] – TRUE/FALSE – TLS encryption.
[b]UseKeychain[/b] – Use the keychain for password authentication.

[u][b]Background Information[/b][/u]

Again, ManagedClient is responsible for processing the XMPPAccount dictionary by applying format strings. The formatting fails because it can’t substitute the token for a null value and the post compositing step fails because of this. End result: iChat prefs are composited and then ManagedClient bails.

Unlike iCal which interacts with its own calendar store API to create new accounts, iChat does not move the managed account from the plist at all. iChat doesn’t do any kind of substitution or key renaming when you add the ManagedAccounts key to the preferences file.

If you would like to try, the iChat post compositing step in ManagedClient allows the administrator to define managed accounts for every type of account. The manifest only defines one account type (Jabber). You can even supposedly supply settings for bonjour accounts, although it seems like there are only 2 valid keys anyway.

If you wanted to try, the key names for other types of accounts are:
00000000-0000-0000-0003-000000000001 – For com.apple.iChat.AIM
00000000-0000-0000-0002-000000000001 – For com.apple.iChat.SubNet (Bonjour)

Another point to note: Managed accounts have two reserved GUIDs. They seem to indicate one being the user domain preference and one being the host domain preference.
The GUIDs for those two types are:
00000000-0000-0000-0001-000000000001 – For a host level Jabber account.
00000000-0000-0000-0001-000000000002 – For a user level Jabber account.

If you don’t understand how to apply these different key names.. you probably only need my first example plist structure.

Cheers, and I hope that this will help you deploying your lab/site.
Feel free to add anything or correct any mistakes too!

Mosen.

[Author]

Posts