davadmin is definitely not my area of expertise but it should be possible. davadmin communicates with the CS Server using JMX, which is there by default in any JVM so there should not be any need for an admin server.
Did you check whether the values in davadmin.properties (see https://wikis.oracle.com/display/CommSuite/Calendar+Server+7+Command-Line+Utilities#CalendarServer7Command-LineUtilities-ClifileProperties) make sense with regards to your particular configuration ?
Are you running davadmin from the same machine (zone instance) where the CS Server is running ?
I believe I did not follow up on this response (thanks, though). So far the server was left as is - that is, as a node-agent driven instance on a different node than the domain's master server. davadmin locally or remotely does not work despite many attempts to vary configurations, short of reinstalling the calendar server's web-container as an individual domain with its local admin server instance.
It may also be relevant that the node agent does not seem to be trusted by admin server during its log in to the master-server to pull configs, etc., though the admin-server can view and seemingly manage the node-agent's state, etc. Over my years with Sun Appserver/Glassfish I haven't seen such behavior, but we did not pursue this either for the deployment. Errors messages in detailed logs, if any, during davadmin runs do not point to such "distrust", however. So it is just a "gut feeling" that they may be related.
The initial quest (import of calendar data) was solved by other means with WCAP import, so such reinstallation of nodes was put off.