No special configuration should be needed for DAViCal's built-in user and group management.
See LDAP Configuration for some detailed examples of configuring DAViCal to use an LDAP server for an authentication source. Here is a brief OpenLDAP working example, however:
$c->authenticate_hook['call'] = 'LDAP_check'; $c->authenticate_hook['config'] = array( 'host' => 'www.tennaxia.net', 'port' => '389', 'bindDN'=> 'cn=manager,cn=internal,dc=tennaxia,dc=net', 'passDN'=> 'xxxxxxxx', 'baseDNUsers'=> 'dc=tennaxia,dc=net', 'filterUsers' => 'objectClass=InetOrgPerson', 'baseDNGroups' => 'ou=divisions,dc=tennaxia,dc=net', 'filterGroups' => 'objectClass=posixGroup', 'mapping_field' => array('username' => 'uid', 'modified' => 'modifyTimestamp', 'fullname' => 'cn' , 'email' =>'mail' ), 'group_mapping_field' => array( 'username' => 'cn', 'modified' => 'modifyTimestamp', 'fullname' => 'cn' , 'members' =>'memberUid' ), 'format_updated'=> array('Y' => array(0,4), 'm' => array(4,2), 'd' => array(6,2), 'H' => array(8,2), 'M' => array(10,2), 'S' => array(12,2)) 'scope' => 'subtree', ); include_once('drivers_ldap.php');
NB: it's important to remember to install the LDAP modules for PHP (the php5-ldap package under debian/ubuntu).
Using a different 'AWL' database
The "AWL" library contains the basic database structure for user data which is used by DAViCal, and it is possible to use this data from a different database. This plugin is written more-or-less as an example of how to write an authentication plugin, but may be useful.
Fallback to internal authentication on failure
In some cases it is desirable that you fallback to DAViCal's internal authentication when external authentication fails. You might desire this if you have some locally configured users in addition to the majority who are in the LDAP server.
In such a case you can set:
$c->authenticate_hook['optional'] = true;
in your configuration file. This doesn't make authentication optional: everyone will still need a username and password! It just means that for someone who is not present in the external authentication system their credentials will then be checked against the internal system and they'll be allowed in if that matches then.
When the Webserver does the authentication
It is quite common that the webserver can do the authentication for you, and you just want DAViCal to trust the username that the webserver will pass through.
In this case you can set something like:
$c->authenticate_hook['server_auth_type'] = 'Basic'; include_once('AuthPlugins.php');
to match the types of authentication which your server is providing to PHP as "$_SERVER['AUTH_TYPE']". DAViCal will then trust the value received as $_SERVER['REMOTE_USER'] (or, beginning with 1.1.2, $_SERVER['REDIRECT_REMOTE_USER']) to be correct.
The above will make the HTTP Basic Authentication from the webserver be used and trusted for authentication within both, the administration websites and CalDAV (i.e. caldav.php). Note: It seems that the "include_once('AuthPlugins.php');" is not necessary if this should only apply to the administration websites but not to CalDAV (i.e. caldav.php).
One could also set an array to accept different types, e.g.:
$c->authenticate_hook['server_auth_type'] = array('Negotiate','Basic');
but of course, these types must exist (it seems Negotiate does not).
This does not work together with the ldap_driver (at least in davical 1.0.2). You may get it working with the $c->authenticate_hook['config']['i_use_mode_kerberos'] = "i_know_what_i_am_doing" though.
When PHP is used as CGI/FastCGI with Apache and mod_ssl, then currently AUTH_TYPE remains unset, even when HTTP Basic Authentication (respectively mod_ssl fakeBasicAuth) was done by the server. This is a bug in Apache and/or limitation in the CGI specification. One workaround is an intermediate CGI wrapper, which sets AUTH_TYPE unconditionally to e.g. "Basic" (currently (see  and ) this is case-sensitive in contrast to the CGI spec).