Windows Integrated Authentication
Enabling the Integration in YSoft SafeQ
Log into the YSoft SafeQ management interface as a user with rights to modify the system configuration (for example, as the default user admin).
Navigate to System > Configuration and search for the webAuthenticationMethod property.
Change the property value to Windows Integrated Authentication to enable the single sign-on method.
Additionally, the cutUsernameDomainDuringWindowsIntegratedAuthentication property can be disabled if necessary (see the info box below).
Restart YSoft SafeQ Management Service to apply the settings. In case the service is part of the cluster, all nodes must be restarted.
In the case when YSoft SafeQ users have been replicated from multiple LDAP domains and the domain information is part of the replicated usernames (in domain\username format), the configuration option cutUsernameDomainDuringWindowsIntegratedAuthentication must be disabled otherwise parsed names from a single sign-on authentication token would not match the usernames in the product database.
Setting Up LDAP Integration
All the users the system will authenticate must be replicated into the database. You can find more information about LDAP integration and how to set it up on this dedicated page.
Additionally, semi-online mode can be enabled in the LDAP integration settings to replicate users on demand in the case when the authenticated user is not found in the database.
Setting Up the Internet Browser
Microsoft Edge
Ensure that Integrated Windows Authentication is enabled.
Open Internet Options on Control Panel.
Click the Advanced tab.
Scroll down to Security.
Check Enable Integrated Windows Authentication.
Restart the browser.
The target website must be in the Intranet Zone.
Navigate to the website.
Open Internet Options on Control Panel.
Click the Security tab.
Click the Local Intranet icon.
Click the Sites button.
Check Automatically detect intranet network.
If the steps above do not work, click Advanced. Add the https://server_hostname/ to the list of intranet sites.
Chrome
The instructions are the same for Microsoft Edge and Chrome as both use the same intranet settings.
Firefox
Type about:config in the address bar and hit enter.
Type network.negotiate-auth.trusted-uris in the Filter box.
Put your server name as the value. If you have more than one server, you can enter them all as a comma-separated list.
Close the tab.
In case of problems, it is possible to use a third-party add-on providing Windows Integrated Authentication (search the Firefox add-on repository for the currently most used one).
Logging Into the YSoft SafeQ Management Interface
When this feature is enabled following the instructions above, and you enter any page that is not the login page (e.g., the root page, Dashboard, etc.), you will be logged in automatically without the need to enter your credentials.
When you enter the YSoft SafeQ login page (https://server_hostname/login) for the first time after the Management Service restart, you can either log in automatically by clicking the Continue as current user button (in which current user refers to the credentials under which you are logged into your operating system) or you can choose to log in by entering your credentials manually. The latter is important when no Active Directory user has super administrator rights assigned in YSoft SafeQ, or in the case when the single sign-on integration was not configured correctly and it needs some additional setup changes.
When you enter the login page next time after the first successful login, the Continue as current user button will be changed to Continue as <FIRST_NAME LAST_NAME> because the browser now knows your name (it was stored in the cookie owned by the Management Service interface page).
When you log out of the system, you will end up on the login page.
Caveats
Tenants
The Windows Integrated Authentication feature and its setting are available only in single tenant mode due to the technical limitations of the integration.
Windows domains
The YSoft SafeQ server must be installed on the Windows operating system that is part of the same domain the users are authenticating against from their browsers.
Problems with saving requests in Microsoft Explorer or Microsoft Edge browser
Symptoms: When user signs in through SSO or try to sign in through login form after SSO login attempt - user cannot save the form, the 403 page occurs; Access Forbidden 403 page randomly showed to the user.
Solution: Windows Registry must be changed to disable Explorer's re-authentication feature, follow resolution at https://www.itprotoday.com/compute-engines/jsi-tip-8574-you-cannot-post-any-data-non-ntlm-authenticated-web-site-after-you.
Workaround: User have to bypass SSO without "touching" SSO - open clean browser, go directly to http://<sever_url>/login/<tenant_domain> and login through form. In this case, Explorer shouldn't try to re-authenticate.
Behind the scene: The problem occurs because Microsoft's browsers decide to try re-authenticate a user with SSO and send a 0-length request with "Authorization: Negotiate ... " header even if the user is already signed in and it should send a regular request with data to save. It is the same issue and has the same resolution as described here: https://www.itprotoday.com/compute-engines/jsi-tip-8574-you-cannot-post-any-data-non-ntlm-authenticated-web-site-after-you (and here https://support.microsoft.com/en-us/help/2749007/an-unexpected-401-1-status-is-returned-when-using-pre-authentication-h).
YSoft SafeQ End User Interface
If the single sign-on is enabled in YSoft SafeQ, users will be logged into the End User Interface automatically.
YSoft SafeQ Payment System
Single sign-on authentication was also implemented for Payment System. Read more about how to configure sign-on authentication on Advanced Configuration of YSoft SafeQ Payment System section Sign-on Authentication.
Troubleshooting
In case there are still troubles making the feature works, try the following additional steps:
Enable session cookies for the browser.
Try to verify the following registry keys in \[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\] (https://www.itprotoday.com/compute-engines/jsi-tip-8574-you-cannot-post-any-data-non-ntlm-authenticated-web-site-after-you):
"EnableNegotiate"=dword:00000000
"DisableNTLMPreAuth"=dword:00000001
SSO may not work well with the username different from format "username" and "domain\username". This typically happens when a username is replicated from LDAP attribute userPrincipalName (instead of default sAMAccountName ) and the format is "[email protected]". To resolve this map the LDAP attribute msDS-PrincipalName as an alias and perform the full LDAP replication.