Everybody Staze...

Nobody leavz...

You are here: Home / Archives for Mac OS X

CardDAV CalDAV autodiscovery on Mac OS X and iOS

By

UPDATE 2 4/8/2012: It’s been a year and a half (almost), but Apple finally fixed CalDAV SRV record discovery in, I believe, iOS 5.0.2 (and therefore 5.1). So all of this is now completely valid, and supported by Apple (finally)!

UPDATE 12/18/2010: It’s taken me a bit to post this (sorry), but I can say that iOS 4.2.1 (the released version of 4.2) supports discovery of CardDAV servers over SRV records. However, CalDAV does NOT work. I’ve been told by people in the know that it’s coming, it just didn’t make it into 4.2.1. Now, I have no idea why… one would think it’s the same back-end, but who knows. Anyway, CardDAV works, CalDAV doesn’t, but hopefully 4.3 (or whatever they call it) will fix that.

Part of being a systems administrator is making the life of your customers easier. Whether it’s having a file share auto-mount when they login, having to only remember a single password (or just having to login once via SSO), or in this case, not having to remember what server provides what services. So, over the past few days I’ve been playing with autodiscovery of CalDAV and CardDAV for Mac OS X and iOS.

Address Book and iCal in 10.6 use SRV records nicely. If I tell iCal that my server is www.example.com, and I have an SRV records that say:

_caldav._tcp.www.example.com. 86400 IN SRV 0 0 8008 caldav.example.com.
_caldavs._tcp.www.example.com. 86400 IN SRV 0 0 8443 caldav.example.com.

iCal magically figures out that my actual caldav server is caldav.example.com (it defaults to lookup caldavs first, then caldav if caldavs isn’t available). I have a similar SRV record set up for CardDAV:

[Read more…]

Hardware UUID “Attribute Not Mapped”

By

Since I have been pouring over OD the last few days, I decided to look again at a change in WGM that came with 10.5. Computer records now have a place for Hardware UUID. UUIDs offer a theoretically truly unique identifier as opposed to MAC address, which I’ve seen not be unique (mind you, this was a manufacturing defect that happened when I was working at 3com, where some customers were getting boxes of NICs all with the same MAC address). Trying to populate it, however, results (for me) in a “Attribute not mapped” error, saying I should contact the sys admin. So, self… this doesn’t work.

A quick search around resulted in a Apple mailing list discussion list thread that talks about this very issue. It seems the 10.6 update added these attributes to the schema, but didn’t map them to anything. Cool.

So, here’s the scoop. Open up Directory Utility on the OD Master in /System/Library/CoreServices, then unlock. Open up LDAPv3, then click on 127.0.0.1, then Edit. Now “Search & Mappings”, and scroll down on the left to “Computers”. Open that up, then click “Add”. You should see the option to add “HardwareUUID”. Select and Click “Okay”. Now with that new one selected, on the right, type in “apple-hwuuid”. Now “Write to Server” and authenticate. Hit Okay. Now you should notice that “LDAP Mappings” is set to “Custom” or “From Server”. You should be able to change that back to “Open Directory Server” and click “Okay”.

HardwareUUID in WGM should now work. Have Fun!

Kerberos brokeage

By

I assist other departments on campus with Mac related issues fairly regularly, since I’m one of the few Sysadmin’s on campus that really know Mac OS X Server. The issue they were seeing (and have been seeing since they upgraded to 10.6 about 4 months ago) was any time someone tried to login to a client, or really anything as a user that was part of the OD, it would take about 60 seconds to authenticate. If they used their server’s local admin account, however, it worked instantly.

Everything seemed to be running, but it just took a long time. Investigating further, everything seemed to point to Kerberos just not functioning. It was running, but kinit would take about 60 seconds to come back asking for a password. And for some reason, the REALM for the Kerberos server had been set as SERVERNAME.LOCAL. Which, shouldn’t be an issue in of itself, but it was certainly not “proper”.

[Read more…]