Choose your language

Choose your login


Popup authentication

This page applies to:

PaperCut NG/MF normally relies on the underlying operating system and the associated print queues to perform authentication. For example, in normal operation, a user logs into a workstation using a domain/network level authentication method such as a username and password. The print queues also use this authentication and PaperCut NG/MF can trust the supplied identity. However, in some network environments, relying on network level authentication is either not possible, or not reliable. Common examples include:

  • All users log in with a common generic username and password meaning that it’s not possible to distinguish between users.

  • A print queue that does not enforce authentication.

For a detailed explanation of print authentication, see Print authentication .

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 NG/MF-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 NG/MF uses the job’s source IP address to determine the PaperCut NG/MF popup client it should contact for authentication.

  • The user is prompted to enter their username and password, which are then verified against PaperCut NG/MF’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 might remember the association between the IP address and the authenticated user for a period of time.

Where and when should popup authentication be used?

Some real life examples include:

The Student Lab

Some student labs are set up so everyone logs in using a generic username and password. For example, username: student, password: student. This is common in Apple Mac labs, where enabling multi-user authentication is complex and can often prevent selected applications from running correctly.


The Line Printer Daemon print protocol, often used in UNIX environments, is a non-authenticated system. The username associated with the print jobs is passed through to the print queue, however, the name is not verified and can easily be forged. An extra level of authentication is required.

CUPS, the modern print system often used on Linux, Apple Mac and some Unix systems, is often implemented in a non-authenticated fashion. Although CUPS can support authentication, technical considerations such as the inability to interface with Active Directory domain authentication often prevent its use.

Mac print queues

Mac OS X server use the CUPS print system. Current Apple implementations prevent administrators from enabling CUPS authentication. This is not usually a problem in an environment where you can control logins at individual workstation level. It does, however, pose a problem if users have local admin access - for example, individual owned laptops. PaperCut NG/MF popup authentication provides a way to work around the non-authentication issue.

For more information, including a discussion of platform specific issues, see Print authentication .

Macs and popup authentication

Popup authentication is often required on Mac networks supporting a mix of lab systems authenticated via a directory service and unauthenticated laptop systems. Advanced administrators might review Eliminating popup authentication via Mac Login Hook to streamline login on the secured lab systems.

iPad / iOS Printing and popup authentication

PaperCut comes with an iPad / iOS app that provides popup authentication and other functionality. For more information see iOS printing (iPad & iPhone) .

What technical considerations do I need to review before implementing popup authentication?

As a general rule, popup authentication should only be used in low-volume, low-complexity scenarios when Protocol-Level Authentication is ruled out. By its design, Protocol-Level Authentication is always the most secure which is 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 NG/MF’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.

The following is a general guide to factors your System, Network and Security teams should consider when implementing popup authentication:

  • Minimize IP address changes. 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 obscures 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 are resolved to IP addresses, both from the client and server. In some situations, hostnames might be reported instead of IP addresses, and resolution results are key to correct behaviour.

  • Any machine relying on popup authentication must have the PaperCut NG/MF client running at all times for printing from that workstation to function.

  • Awareness of IP address spoofing. Large sites 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 can 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 are reported from a single IP address.

A real-life an example of the practical difficulties associated with popup authentication

In 2012 one major university user of PaperCut NG/MF in the USA were 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 NG/MF’s management) decided to make a few network infrastructure changes and enabled NAT for some subnets. This 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.


The following sections cover how to enable popup authentication on either the user account level or the print queue level.

The following notes explain how to enable popup authentication when a user logs in under a generic user account - for example, student.

  1. Add the account to the domain called student. You might already have this account set up.

  2. Perform a User/Group Sync or print a job from this account so the username is listed in PaperCut NG/MF.

  3. Select the generic user and set the account to a zero balance and a restricted status. This ensures that users can’t charge against this account.

  4. Select the Unauthenticated check box; then click Apply to save the changes.

    Turning on popup authentication at the user level

  5. Install client software on workstations. See User Client for details.

  6. When a user logs in as the generic student, they are prompted for their domain level username and password.

     client requesting for authentication

The following notes explain how to enable popup authentication when a user attempts to print to a non-authenticated printer such as one hosted via an LPR/LPD queue or a CUPS print queue:

  1. Add the printer to the system as normal. Perform a few test prints to ensure the printer is functioning and tracking as expected.

  2. Log in to PaperCut NG/MF and check the Unauthenticated option under the relevant print to enable the popup authentication.

  3. Install the client software on any workstation that will print to this printer. See User Client for details.

  4. When a user attempts to print to this printer, they are prompted for their username and password.

User interaction

When running in popup authentication mode, the client offers the following options:

  • Log out

  • Log in as another user

The Logout option is available on Windows via either the right-click option on the task try icon, or when running on Mac or Linux, via a right-click popup menu (Option Click) access via the icon on the balance window.

The Login as option is made available if the client starts as an unauthenticated user. This option allows users to authenticate or quickly switch user identity.

Advanced Popup Configuration

The login box displayed to the user offers the choice of how long their authentication details should remain active. An administrator can control the options presented to the user by modifying the following system configuration keys. These configuration keys are edited under Options > Actions > Config editor (Advanced).

User Client Popup Config Keys
Config name Description
client.config.auth.ttl-values A comma separated list of values to display in the popup authentication login box. Positive numbers represent the number of minutes to remember the authentication for.The value of 0 indicates that the authentication is remembered for “this print job only”. The value of -1 indicates that the authentication is remembered until the user logs out or exits the client.The value of -2 indicates that the authentication is remembered indefinitely, even after restarting the client.For security reasons, you need to make this change in the Config Editor, not the client’s and the client does not save the password. Instead a server generated cookie is placed in a file in the user’s home directory. The default is: 1,5,15,30,60,-1
client.config.auth.ttl-default-minutes The default time-to-live value is automatically selected when the login authentication window is displayed.
client.config.auth.popup-on-startup-if-unauthenticated Determine if the client should request authentication when the client starts if the operating system user is unauthenticated. Set to Y (yes = enabled) or N (no = off).

See Using the Advanced Config Editor to find out how to change config keys.