PaperCut’s Web SSO functionality
(see SSO chapter in manual)
is compelling and in the case of Windows Authentication, easy to implement.
But the technology underlying SSO is complex and there are many Windows policy and configuration
variables that can occasionally cause things to go wrong.
Before implementing SSO it is very important to work through the planning section in the manual.
Complete the post install tests before putting SSO in production.
I’ve turned SSO on and now can’t login to PaperCut!
If you find yourself locked out of PaperCut, you can bypass SSO to get PaperCut’s standard login screen by adding “/nosso” to the URL. For example:
Troubleshooting Common Problems
User is prompted by the Browser to provide username and password
If automatic Windows Authentication cannot proceed, the browser may ask for your credentials. If you provide incorrect credentials, or click Cancel, the request will fail as “Not Authorized”. There are several reasons why you may see this behavior:
- You are not logged into Windows. Users accessing the site from a mobile device or a Mac or Linux computer can expect to see the authentication dialog.
- Your browser does not support Integrated Windows Authentication or needs configuration. Firefox, for example, requires configuration as described here.
- The PaperCut server is not configured to be in the “Intranet Zone”. This applies to Internet Explorer and Chrome browsers. Go to Control Panel → Internet Options → Security. Select Intranet Zone and ensure the PaperCut server is included. By default a URL containing a period ‘.’ will not belong to the Intranet Zone and may need to be manually added.
All I get is a white screen
A white screen with no browser authentication prompt indicates a failure in the Windows Authentication process. For example, there may be a site or browser mis-configuration that makes the Windows Domain controller unreachable. You should ensure that the browser is accessing the PaperCut server directly and not via a proxy server.
Internet Explorer users may see this when they are actually getting a “HTTP 413” error (see below)
Error 413 “Full HEAD”
If using Kerberos SSO the HTTP headers can be large, and can exceed the jetty default max size (4096 bytes). This can be fixed with a
[app-path]/server/server.properties config option “server.request-header-size”. The default size is 10000 bytes. It seems that for kerberos SSO it needs to be higher. e.g. 32000. This can be set in the server.properties file by adding a brand new line with:
The App Server will then need to be restarted.
Note that this will only work with PaperCut build 14.2 (28942) or later
Trying to access admin interface but get user interface instead
If your Windows login does not have PaperCut admin rights, you will not be able to access the admin interface.
Instead, you may be redirected to the PaperCut user interface. If you have been using the built-in “admin” account prior to using SSO, you may login with that account using the
http://mypapercutserver:9191/admin/nosso URL and grant your Windows account the necessary admin rights.
Try to isolate the problem as much as possible. For example, login to the Windows machine running the PaperCut application server and try to access PaperCut from localhost.
If you wish to report an SSO problem to PaperCut support, please collect the following diagnostic information:
- Windows version on PaperCut server and client
- Type of Browser
- Server debug logs
To collect the server debug logs:
- Turn on debug logging (instructions here: https://www.papercut.com/kb/Main/HowToEnableDebugInNG)
- Turn on SSO. Take a screen shot of your SSO configuration.
- Attempt to login (and note the date/time)
- Login using
/nosso and turn off SSO
- Turn off debug logging and set the logs to us along with the time of your SSO login attempt
Categories: Errors, Administration
Keywords: SSO, single signon, sign-on, Authentication, IWA, log-in problem, auth, domain, username,