Multiple domain security configuration

PaperCut can be used in a multi-domain Active Directory environment. There are various approaches to import users from multiple domains, and these are discussed in the article Importing users from multiple domains. The first two options described in this article require PaperCut to have permission to query users from multiple domains. If PaperCut does not have permission to query the other domains then only users in the local domain will be imported.

This article discusses options to grant PaperCut permissions to query all domains. It is recommended you read this first.


Windows Active Directory allows differing levels of trust between domains. Often in schools, the trust relationships between the “Staff” and “Student” domains are one way. i.e. the “Student” domain trusts the “Staff” domain but not the other way around. For this reason if PaperCut is installed on the “Student” domain, then it will not have any permissions to query the “Staff” domain.

By default, the PaperCut Application Server service runs under the built-in “System Account”. This account has local admin rights on the machine and has permission to login and query the local AD domain, however it may not have permission to connect to other domains.

To allow PaperCut to query the other domains, PaperCut must run as a user that has permissions to authenticate and query all the required domains.

Allow PaperCut to query multiple domains

To allow PaperCut to query multiple domains it must be configured to run as a domain account that has permission to query all domains. The simplest way to achieve this is to create a user account on all your domains with identical usernames and passwords, and then run PaperCut as this user. By having the same username and password on all domains, it allows PaperCut to authenticate to the other domains when required.

On each of the domains, create a user account for PaperCut to run under:

  1. Create a user called “papercut_service” (or something suitably descriptive).
  2. Set the password to exactly the same on all domains.
  3. Ensure the user’s password is set to never expire.
  4. On the domain where PaperCut is installed, grant the user local admin rights on the server where PaperCut is installed. (If PaperCut is running on a domain controller, you will need to assign the user domain admin rights).

Now configure the PaperCut Application server service to run under as this user account:

  1. On the PaperCut server, open the Windows Services list (Control Panel→Admin Tools→Services)
  2. Stop the PaperCut Application Server service.
  3. Select the PaperCut Application Server service, right-click and select Properties.
  4. Select the Log On tab.
  5. Select the This account option.
  6. Enter the username and password of the papercut_service user.
  7. Press OK.
  8. Start the PaperCut Application Server service.

Once PaperCut has restarted, login and test that PaperCut is working correctly. For example, perform a print job and verify that the print job is logged in the “Prints→Print Log” screen.

Now if you have PaperCut configured as described in this article, then PaperCut will be able to retrieve users from your other domains. You can test that it is operating correctly by performing a user sync from the “Options→User/Group Sync” page.

Alternate approach

Instead of creating a duplicate user with identical usernames/passwords on all domains, it is also possible to use a single account that has permissions on all of your domains. However this approach requires that your domain trust relationships are configured such that PaperCut can be configured to run under this account. It’s for this reason that the above approach is usually recommended.


The error Table does not exist. (-2147217865) suggests that PaperCut is unable to contact one of the other domain servers. If the security related changes discussed above do not work, check network connectivity (i.e. firewalls or routers) between the two networks. Some PaperCut users have reported this error when a router is blocking port 389.

Categories: How-to Articles, User Management

Keywords: multiple domains, AD, trust, user management

Related errors: Error performing AD query: Table does not exist. (−2147217865)