Ok, with Marc's help (quotes from him below reproduced with permission), I think I'm getting a handle on all of this. Let me brain dump everything I have found so far so others can benefit from the much-appreciated assistance I received from him.
Difference between a resource and a user: (Marc says) Biggest difference is that a resource doesn't show up in a user search, and doesn't use up a license.
I also believe a resource gives you a little auto-accept magic. If you want to have a human or group of humans manually handle reservations and such, see Resource manager
If you want to POST via the REST interface to a resource you need to either use an admin access backdoor (my term, more on this in a sec) or make sure that you can log in to that resource. In my initial testing, this is what tripped me up because we are using an external authentication source.
Marc says there are three different ways to handle the external authentication to a resource:
- add the resource to your external auth source (in our case, an LDAP directory) like any other user
- set zimbraAuthLdapExternalDn for that resource to make it use a specific DN for its authentication. This gives you the benefit of setting that resource (and perhaps all of your resources if you so choose) to use the same DN for authentication and hence they all get the same password.
- turn on zimbraAuthFallbackToLocal so that Zimbra will fall back to its local directory if there exists a password locally and the external directory does not have an entry for the resource.
zmprov md zimbra.example.edu zimbraAuthFallbackToLocal TRUE
If you don't want bother with authentication issues, you can bypass this by having the admin user authenticate instead on the admin port. So this means that your curl command could look something like this (replace resource with the name of the resource in question):
Notice all of those nifty single quotes? Careful quoting is key to making sure this works and so I've quoted everything possible in the command line. Though I didn't need it, you may also need to explicitly specify the domain of the resource in question (hence my @zimbra.example.edu in the URL and in the user name).
curl -u 'email@example.com:passwd' --data-binary '@./file.ics' \
If you'd like to learn more about automated calendar twiddling, I'd recommend also reading this thread started by the inimitable Rich Graves: Auto-provisioning calendar data/shared calendars.
That's where I found the clue to use the admin port.
Hope the above is as helpful to others as it was to me.