Configuring SSO in PaperCut NG/MF is easy, but you must work through the preparation steps above, or you might not be able to log in to PaperCut NG/MF!
-
Select Options > Advanced. The Advanced page is displayed.
-
In the Web Single Sign-on (SSO) area, select the Enable Single sign-on check box to enable SSO. Additional configuration items are displayed.
-
Select the SSO method:
-
Integrated Windows Authentication
-
WebAuth
-
-
If you select WebAuth, complete the following fields:
-
WebAuth HTTP header key—the WebAuth HTTP header name.
-
Allowed WebAuth IP addresses—a comma-separated list of whitelisted IP addresses.
-
-
Specify the SSO behavior you want for the user web interface and mobile client, Admin web interface, and other interfaces:
-
Standard (username and password)—don’t use SSO and show the PaperCut NG/MF login screen.
-
SSO with confirmation page—use SSO and present a confirmation page at login.
-
SSO with direct access—use SSO and directly log in the user with no confirmation page.
-
-
If you want to show a Switch User link on the confirmation page, select the Show “Switch User” link on confirmation page check box.
-
In On logout, direct user to URL, enter a URL to go to on logout. A typical example would be the URL for your intranet portal.
Advanced configuration
You can set advanced config keys to fine tune SSO behavior. For more information, see Using the Advanced Config Editor .
-
Some installations want to enable SSO for web users, but not for users of the mobile client and mobile release apps. To disable SSO for mobile users, set the advanced config key:
auth.web-login.sso-enable.mobile-user
toN
. -
By default, Windows SSO does not authenticate users belonging to the “Guest” group. You can change this behavior by setting the advanced config key
auth.web-login.sso-allow-guest
toY
.
Post installation testing
After enabling SSO, perform the following tests to ensure that users can successfully access the PaperCut interface.
-
Verify that you can still log in to the Admin web interface.
-
Verify that a user without admin rights can still access their user web pages.
-
If in use, verify that a user with the appropriate admin rights can still access other interfaces, such as Release Station or Web Cashier.
-
Try logging in from other computers in the domain.
-
Try logging in from different browsers supported in your organization.
-
If using IWA, try logging in from a non-windows client or a PC outside the domain. Verify you can still log in after providing your Windows credentials.
Comments