PaperCut NG/MF 22.1.1 upgrade checklist

Depending on the features you’re using in PaperCut MF/NG, some functionality could potentially stop working if you’re upgrading from a PaperCut MF/NG version earlier than 22.1.1, to 22.1.1 or later. If you have already upgraded to 22.1.1 or later, and you’re looking to upgrade to an even later version, you don’t need to use this checklist again. info Related articles: Upgrading PaperCut MF & NG (update procedure) ('How do I upgrade?'). PaperCut's Upgrade Policy ('Can I upgrade with my current license?'). Use this checklist to see if there are any actions required after upgrading. Summary checklist Feature in useAction required?Print Scripting or Device ScriptingNO 1Print Scripting with extended Java classesYESDevice Scripting with extended Java classesYESCustom card number conversion scriptsNO 2Custom card number conversion scripts with extended Java classesYESCustom user authentication and user sync programYESDomain user or service account in use for the PaperCut Application Server service or PaperCut Print Provider serviceNO 3 1 Consider reviewing this configuration based on your organization’s functionality and security needs. See Are you using Print Scripting or Device Scripting? below. 2 Consider reviewing this configuration based on your organization’s functionality and security needs - e.g. narrow down the allowed paths for custom scripts. See Are you using a custom card number conversion script? below. 3 Consider reviewing and potentially changing the permissions on the security.properties file. See Are you running any PaperCut services as a domain user account or service account? below. info The new security.properties file referenced below is located on the Application Server file system: [app-server]/server/security.properties Are you using Print Scripting or Device Scripting? I’m not sure: To find out, see the FAQ How do I know if I’m using print or device scripts? below. No: No action is required. However, if you choose to disable it, set the new security.properties file key security.print-and-device-script.enabled to N. See Disabling Print Scripting and Device Scripting for information on how to do this. Yes: No action required - the new security.properties file key security.print-and-device-script.enabled is set to Y on upgrades, so print and device scripting will continue to work. Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes. Note: The ‘old’ config key (print-and-device.script.enabled) in the admin interface config editor will remain listed, but will no longer have any impact on functionality. Are you using Print Scripting with extended Java classes? I’m not sure: To find out, see the FAQ How do I know if I’m using extended Java classes in scripting? below. No: No action required - for upgrades and new installations, the new security.properties file key security.print-script.allow-unsafe-code is set to N (the most secure option). Yes: Action required - if you choose to continue to use extended Java classes in Print Scripts, set the new security.properties file key security.print-script.allow-unsafe-code to Y. See Using extended Java classes in scripts for information on how to do this. Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes. Note: The ‘old’ config key (print.script.sandboxed) in the admin interface config editor will remain listed, but that key will no longer have any impact on functionality. Are you using Device Scripting with extended Java classes? I’m not sure: To find out, see the FAQ How do I know if I’m using extended Java classes in scripting? below. No: No action required - for upgrades and new installations, the new security.properties file key security.device-script.allow-unsafe-code is set to N (the most secure option). Yes: Action required - to continue to use extended Java classes in Device Scripts, set the new security.properties file key security.device-script.allow-unsafe-code to Y. See Using extended Java classes in scripts for information on how to do this. Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes. Note: The ‘old’ config key (device.script.sandboxed) in the admin interface config editor will remain listed, but that key will no longer have any impact on functionality. Are you using a custom card number conversion script? I’m not sure: To find out, see the FAQ How do I know if I’m using a custom card number conversion script? below. No: No action required. However, if you choose to disable custom conversion scripts completely, remove the * option from the new security.properties file key security.card-no-converter-script.path-allow-list. See Disabling card converter scripts for information on how to do this. Yes: No action is required unless you use extended Java classes. However, if you choose to allow a particular script, update the security.properties file key security.card-no-converter-script.path-allow-list to specify the exact card number conversion script path in use (by default this is set to *). In addition, if your card conversion script is using extended Java classes, you can choose to set the security.properties file key security.card-no-converter-script.allow-unsafe-code to Y. See Enabling card converter scripts (and optionally Using extended Java classes in scripts) for information on how to do this. Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes. Are you using a custom user auth or sync program? I’m not sure: To find out, see the FAQ How do I know if I’m using a custom user auth or sync program? below. No: No action required. Yes: Action required - if you choose to continue using your custom auth/sync program, specify the custom program paths in the security.properties file key security.security.custom-executable.allowed-directory-list. See Synchronizing and authenticating user and group details with custom programs (executables) for information on how to do this. Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes. Are you running any PaperCut services as a domain user account or service account? I’m not sure: To find out, see the FAQ How do I know if I’m using a domain user account or service account? below. No: No action required. Yes: No action is required. However, if you choose to continue running the PaperCut Application Server service or PaperCut Print Provider service with a domain user account or service account, you can set the file permissions so that the service does not have edit access to the [app-server]\server\security.properties file. Permissions for the security.properties file: PaperCut Application Server Service account - allow read access, deny write access PaperCut Print Provider Service account - deny write access (read access is not required but it’s ok if the service account has read access) This is to ensure that the service accounts cannot make changes to the security.properties file - only an organization’s Administrator should be able to edit that file manually. FAQs Q Are any other PaperCut MF/NG components impacted? No. This only impacts your configuration for the specific functionality of PaperCut MF/NG mentioned above. You do not have to make any changes to any other components (including Print Deploy, Mobility Print, Multiverse, User clients, and device embedded software). Q How do I know if I’m using print or device scripts? Check the following locations to see if you have checked the Enable print script or Enable device script box for any of your printers or devices, to tell if you are using print scripting or device scripting in your environment: Printers > [select printer] > Scripting > Enable print script Devices > [select device] > Scripting > Enable device script If no scripts are enabled, then you’re not using print or device scripting. Q How do I know if I’m using a custom card number conversion script? In the Admin interface, go to Options > Actions > Config editor (Advanced). Find the config key ext-device.card-no-converter and check if it’s been configured with a converter value. If it has, you’re using a custom card number conversion script. If the value is blank, you’re not using a custom card number conversion script. Q How do I know if I’m using a custom user auth or sync program? In the Admin interface, go to Options > User/Group Sync > Sync Source > Primary Sync source. Check to see if the Primary Source has been set to Custom Program. If it has, then you’re using the custom user auth or sync programs defined in the two text boxes below that. If the primary sync source is set to anything else (for example Azure AD, Google Cloud Directory, LDAP etc) then you’re not using a custom program. Q How do I know if I’m using extended Java classes in scripting? To understand if you’re using extended classes, generally if you are using classes outside of dates, numbers, and strings (those listed on the Print script API reference or Device script API reference) then you may be using extended classes. These may include calling OS-level commands or accessing non-type classes from your print or device script. Generally this is rare. This functionality has also been disabled by default, in any version released since June 2022, including 19.2.7, 20.1.6, 21.2.10 and 22.0.0 or later. For more information see Using extended Java classes in scripts. Q How do I know if I’m using a domain user account or service account? Review the section How to set up PaperCut to run as a different account to see if you’ve set up your PaperCut Application Server or PaperCut Print Provider services to run as / login as a domain user account or some other service account. If you’ve configured one of those services to login as e.g. ‘papercut-service’ or some other service account which isn’t the default SYSTEM account, then you’re using a domain user account or service account. Q Is there a summary of the config key changes available? Yes - see the table below for a summary of old config keys, and new security.properties file keys. It’s also included in the Secure configuration of high-risk features in PaperCut NG/MF page in the manual. Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes. Config editor key (Options > Actions > Config editor)security.properties file key [server install]/server/security.propertiesNew security.properties file defaults in 22.1.1print-and-device.script.enabled 1security.print-and-device-script.enabledY - on upgrade N - new installationsprint.script.sandboxed 1security.print-script.allow-unsafe-codeN - on upgrade N - new installationsdevice.script.sandboxed 1security.device-script.allow-unsafe-codeN - on upgrade N - new installationsN/Asecurity.custom-executable.allowed-directory-list 2(blank/empty) - on upgrade (blank/empty) - new installationsN/Asecurity.card-no-converter-script.path-allow-list 3* - on upgrade (blank/empty) - new installationsN/Asecurity.card-no-converter-script.allow-unsafe-code 3N - on upgrade N - new installations 1 These config editor keys remain in the admin interface config editor, but have no function in version 22.1.1 or later. 2 This key is used in conjunction with the Custom user and Custom auth programs. These are set in the Admin interface: Options > User/Group Sync > Sync Source > Primary Sync source > Custom program, then setting the Custom user program and Custom auth program fields. 3 These keys rely on a custom card number converter being defined in the config editor config key ext-device.card-no-converter. You also have to enable card converter scripts. Q Should I worry about enabling these features? The security hardening features in this release are focussed on reducing the attack surface for potential future vulnerabilities - in short, limiting the tools that potential hackers have at their disposal. For example if you don’t use print scripting at all, we recommend disabling it as above - since that limits the attack surface further. We recommend organizations consider reviewing and potentially changing this configuration based on their functionality and security needs. As always, we recommend following your security best practices, running anti-malware and endpoint security software as appropriate. Q Why did you enable Print and Device scripting by default on upgrade? We understand that many of our customers use print scripting for enhanced functionality - everything from charging, access, routing and much more. For those customers, disabling print scripting could have an immediate impact on end-users ability to print. If you’re not using print and device scripting or custom card number conversion scripts (see the table above), we recommend organizations consider reviewing and potentially changing this configuration based on their functionality and security needs. Ok, but why didn’t you just see if I was using scripting, and then set the new security.properties key accordingly? By design, the PaperCut Application Server service should not have access to update the new security.properties file. Because of this the installer (run by an Administrator) creates the new file and sets the configuration. At the point that the installer runs, we don’t have access to the PaperCut database, and are unable to see what the ‘current’ environment is set up with. Because of this deliberate permissions restriction, we had to go with a set of defaults appropriate for all customers, and then allow customers to change their security settings as appropriate for their environment, post-install / post-upgrade. We have also included a PaperCut MF/NG admin interface alert for administrators, which will alert them to any changes made in their configuration on upgrade. Q Can I clean up the old config keys if they’re no longer in use? Yes! If you prefer to keep things tidy, you can delete the old config keys that are no longer in use after upgrading to 22.1.1. We have kept these keys by default so that you can refer to them historically, but they are no longer required or used. They can be found in the config editor in the PaperCut MF or NG admin interface > Options > Actions > Config editor then searching for the relevant key: print-and-device.script.enabled print.script.sandboxed device.script.sandboxed