Question: The scenario is as follows:

* There are clients that users can access and work with.
* These clients can be online or offline.
* There is a central database on a server, holding all the authorization data.
* The clients each hold a mirror of a part of the central database.
* At regular intervals, the client go online to connect to the central server, and update its local database to match that of the central server.

The purpose of the local authentication database is that a program running on the client can determine what levels of access users (when the client is offline) are authorized to when running the program.

Are there any general best practices on how to protect the local database on the client from being viewed and manipulated by unathorized users?

Answer: 
Are these (local and central) databases holding authorization or authentication data (or both)? Your question refers to it using both ways.

But, whichever it is, if the database is local and the user (or, equivalently, a process running as that user) has to be able to read it (e.g. to check that they have valid authentication/authorization) and that read has to be (by definition!) before the user is authenticated and authorized, then you are out of luck -- the user will need to have read access so they will be able to read the data.

You may be able to prevent modification of the data (or at least detect and reject such modification e.g. via a cryptographic signature/public key encryption using a private key held on the server whose public key pair is held on the client machine) but the user could still subvert the authentication/authorization within the client application's "offline" mode by modifying/injecting into the locally running code.

In addition to any such "roadblocks" you'll also need to make sure that when the client reconnects, the server prevents any unauthorised changes which were made while in offline mode from propagating to the server.
I should say two things:

1- This is not a good model if users have strong enough incentive to access the data they are not supposed to have access to (since it looks like they have all the data but the client software prevents them from "seeing" all of it based on the permissions defined in the database)

2- If you must do it the way you say, you need to encrypt the client database.