Is Cross-Server Redirection Possible Without Local Administrator Rights?

PaperCut’s Find-Me Printing feature can be configured so that print jobs can be released to queues that are hosted on totally different print servers. We call this “Cross-server job redirection” and discuss it on this page of the manual. For this to work, the PaperCut Print Provider service must be configured to run as a domain user service account with privileges to copy the spool files to the other print server. The “local system” (or “SYSTEM”) account in Windows does not have permission to do this.

For this to work, the service account that the Print Provider is running as needs local admin rights as well as sufficient rights to send a print job to another server.

However we find that many security-conscious customers are reluctant to grant local admin rights to such an account and ask if local admin rights are truly necessary. Normally the PaperCut Print Provider service runs under the SYSTEM account, which allows it to interact with the local Windows printing subsystem to the full extent required for proper functioning. To maintain this level of access when configuring cross-server redirection, we strongly recommend that the service account is granted local administrator rights to the server; this is the only way to absolutely ensure that the Print Provider can perform every action required of it!

This may be a challenge for customers that want to use their Domain Controllers as PaperCut servers, because a local admin account on a domain controller has power over the entire domain. This is one of the reasons why we strongly advise customers not to use a Domain Controller for their print or PaperCut server. Instead we always recommend that a new server or virtual machine be provisioned for PaperCut as opposed to having it share a host with a Domain Controller.

One particular customer was able to workaround this limitation by instead creating a domain user in the “Print Operators” group. In their own testing, this user was able to be employed as a service account for the Print Provider, proving to have sufficient access to both the local printing subsystem, and the remotely hosted print queues.

Whilst we cannot guarantee this level of access will prove sufficient for other deployments, and would suggest that an account with local administrator rights always be the foremost consideration, we did feel that this solution was an excellent find, and well worth documenting!