Authentication is handled by first Flexi Spooler, who receives the job based on configuration and if the first Flexi Spooler is in client or server mode.

Flexi Spooler in client mode (with Desktop Interface) 

On Flexi Spooler in client mode user needs to authenticate when sending print job by providing some credentials based on the configuration of a property authenticationType:

  • Domain username (username of the user logged into the workstation is used)
    • When set, user does not need to enter any credentials
    • For more information about domain username format, see below.
  • Stored username (username will be retrieved from the configuration file spooler.config)
  • Values with required user interaction:
    • Username and password
    • Username
    • Card
    • PIN

The user can be asked for credentials every time when sending print job or credentials can be stored after first print based on property cacheCredentials.

Properties authenticationType and  cacheCredentials  can be set centrally in Dispatcher Paragon management interface in System > Spooler tab, and from version MU6 it can be overridden locally for each Flexi Spooler via spooler.config.  See FlexiSpooler local configuration through spooler.config file

See user documentation Using the Dispatcher Paragon Desktop Interface for more details. 

Flexi Spooler in server mode (without Desktop Interface)

On Flexi Spooler in server mode is authentication bit more complex as authentication options are not exclusive, also taking into account various possible print job sources and username formats (see list of specific behaviors and exceptions below). The job is authenticated according to authentication option with the highest priority. 

Authentication options listed from highest priority to lowest:

  • Parse username from PJL headers 
  • Parse username from job title (for LPR jobs)
  • Stored username if set in authenticationType
  • Domain username (if no other authentication was applied)

For information about how to set parsing username from either the job title or PJL headers see Parsing username from print job.

For more information about domain username format, see below.

Example 1:

Settings:

  • Management interface setting: authenticationType:Card
  • Job is sent via LPR to Flexi Spooler in server mode and does not have username in PJL header nor in job title

Result: 

Domain username is used for authentication.

Example 2 :

Settings:

  • Management interface setting: authenticationType: Domain, parsing user from the title is correctly configured.
  • Job is sent via LPR to Flexi Spooler in server mode and has username in job title that is different from domain username

Result: 

Username from job title is used for authentication.

Username formats used for Domain username authentication mode

Dispatcher Paragon management interface offers setting 

  • NT4 account name (e.g., engineering\someone)
  • User principal name (e.g., someone@engineering)
  • Plain username (e.g., someone)

Based on which mode Flexi Spooler is running in, what is the source of the print job, which username format is selected, which username transformations are set and what are the other circumstances the resulting username may differ from what expected:

Flexi Spooler in client mode (incoming LPR connections)

  • User principal name
    • We will obtain the UPN through proposed system calls.
    • Should it return null (mostly for local accounts, but can possibly happen for domain user accounts without UPN), we will return username in format:
      • ShortDomainName\Username (a.k.a. NT4 Account Format) - in case domain is still known, i.e. only UPN is not set for the used domain account
      • MachineName\Username - if it is not a domain account (as this is more valid full format for such username, instead of the proposed variant Username@MachineName)
  • NT4 account name
    • we will return username in format:
      • ShortDomainName\Username - in case of domain account
      • MachineName\Username - otherwise

Flexi Spooler in server mode

  • Incoming LPR connections
    • We receive jobs via LPR and thus we have only access to username (without anything else)
    • We will try to use system calls to resolve the defined format within the domain assigned to the machine, where Flexi Spooler in server mode is running
    • Should this not work, we fallback to ShortDomainName\Username
      • This may seem like a security breach, but in fact it does not lower security in any way, as the possible attacker can fake the username in LPR to anything
      • This way we can behave as the designer of the environment has probably indented
  • Incoming HTTP connections
    • We do not modify received username, we rely on connecting party being forwarding correctly set username format
  • Parsing job name from title (LPR)
    • We will take the parsed username as is and will not apply any further username format looking up and will be sent as is
  • Parsing job name from PJL header
    • The parsed username will not be subjected to any further username format looking up and will be sent as is (the current state)

Both Flexi Spooler modes

  • Incoming legacy Dispatcher Paragon Client protocol connections
    • We do not modify received username, we rely on Dispatcher Paragon Client being correctly set to the desired username format