Popup Authentication is a feature in PaperCut which may be used when Protocol-Level Authentication is not available for user print jobs. Typically Popup Authentication is not used as the primary authentication mechanism but is used to support secondary printing services such as desktops that logon under a generic username (i.e. general access PCs in a library) or Mac systems where setting up an authenticated protocol may be beyond available system administration resources. Popup Authentication uses IP-address matching, which is explained in more detail below.
Q What is Protocol-Level Authentication?
The standard Windows print system is an example of printing using Protocol-Level Authentication. Before a user is able to print, they must be authenticated into the environment (generally a Active Directory domain). Any jobs submitted to the print queue is encapsulated within this authentication as part of the transmission protocol. Due to this, the username with the print event can be trusted for the purposes of accounting and security.
Q How does Popup Authentication work?
Popup Authentication matches the source IP address of the print job with the user confirmed to be operating from the popup client IP address. The workflow is as follows:
The user initiates a print job to a server-hosted, PaperCut-managed, queue (printer) via unauthenticated print protocol.
The print job arrives in the print queue and because of the unauthenticated protocol, the username cannot be trusted.
PaperCut uses the job’s source IP address to determine the PaperCut popup client it should contact for authentication.
The user is prompted to enter their username and password, which are then verified against PaperCut’s configured directory source. If the credentials are correct, the user is considered authenticated at that client.
The print job is attributed to the authenticated user.
Depending on configuration, the server may remember the association between the IP address and the authenticated user for a period of time.
Q When should Popup Authentication be used?
As a general rule, Popup Authentication should only be used in low-volume, low-complexity scenarios when Protocol-Level Authentication has been ruled out. By its design, Protocol-Level Authentication is always the most secure and hence this is the reason why it is used in Windows and authenticated protocols such as HTTP, SSH or Novell’s iPrint protocol.
A good example of a situation where Protocol-Level Authentication is not ideal would be a public-access PC in a library set to auto-logon as the insecure, generic account “public”. In this case the Protocol-Level Authentication is passing through the insecure user of “public”. PaperCut’s client software and IP address authentication can overlay these insecure user credentials and request authentication from the user at the time of print via a popup.
Q What do I need to know when implementing Popup Authentication?
The following is a general guide to factors your System, Network and Security team should consider when implementing Popup Authentication:
IP address changes should be minimized. If you are using DHCP, consider the lease time as well as the re-use rate of IP address and DNS scavenging timeouts.
Do not use any form of NAT between the clients and print server. NAT will obscure the IP address seen by the server.
Consider the authentication session time (TTL - Time To Live) options offered to your users. This is detailed further in the Popup Authentication configuration page of the manual. TTL settings are a trade-off; the shorter the time, the smaller the window of mismatch, but the greater the inconvenience to the user. There is no one-size-fits-all answer, this must be taken on a site-by-site basis.
Ensure that hostnames can be resolved to IP addresses, both from the client and server. In some situations, hostnames may be reported instead of IP addresses, and resolution results are key to correct behaviour.
Any machine relying on Popup Authentication must have the PaperCut client running at all times for printing from that workstation to function.
Awareness of IP address spoofing. Large sites will often actively monitor this and/or endeavour to prevent it, as IP address spoofing is something that affects network application security in general.
Always reconsider your choice of Popup Authentication. Protocol-Level Authentication may become viable with changes in technology, infrastructure or internal procedure.
Popup Authentication is not a viable solution for simultaneous multi-user systems such as Terminal Server or Citrix, as multiple users will be reported from a single IP address.
Q Can you give me a real-life an example of the practical difficulties associated with Popup Authentication?
In 2012 one major university user of PaperCut in the USA was using Popup Authentication to support authentication on print jobs issued via the LPR protocol (for Unix desktop systems). This setup had been in place successfully for 5 years with no reported problems. The site’s networking team (independent of the server team responsible for PaperCut’s management) decided to make a few network infrastructure changes and enabled NAT for some subnets. The NATing caused a subtle set of authentication issues that took a number of days to detect and diagnose. During this time some jobs were incorrectly attributed.
This release contains an updated Java version which no longer supports 32-bit workstations. If you have any 32-bit users launching the User Client or Release Station from a network share, see this Knowledge Base article for more information.