Setting up Single Sign-On (SSO) login to the Enterprise Server and troubleshooting errors

With Integrated Windows Authentication (SSO), users log on to the Enterprise Server without separate Password Depot credentials: the client uses the existing Windows domain login. This article describes the setup and the most common causes of errors.

Requirements

• The users have previously been imported into the Server Manager via Tools → Active Directory Import (see related article) – without a correct AD import, SSO login is not possible.

• The client PC is a member of the domain. Password Depot does not store AD passwords; the login is validated against the Active Directory.

Setup

1. Server: In the Server Manager, under Manage → Server settings → Connections, enable Integrated Windows Authentication (Single Sign On) among the supported authentications.

2. Client: Under Edit → Options → Network, set the Default authentication mode to Integrated Windows Authentication (SSO). Optionally, you can predefine the Default domain name, the Default UPN suffix, and the User logon name format there.

3. Log in: In the client, choose the Enterprise Server login and enter the server address and port (version 19: 25019). If the configuration is correct, the login window already shows your logon name and domain – a click on LOGIN is all it takes.

The server uses the user names as they were imported from the Active Directory (normally SAM accounts). Valid login formats are DOMAIN\username, the UPN (username@domain.tld), or – if unique across the network – the simple user name.

Note: The Enterprise Server's Two-Factor Authentication can also apply to SSO logins; it can be configured per user.

Troubleshooting

1. Test the SSPI mode: Under Manage → Server settings → Active Directory (section SSPI), select the authentication service: NTLM, Negotiate, or Kerberos. If the SSO login fails, switch between Kerberos and Negotiate for testing and check the login again.

2. Check SPN/FQDN consistency: The Service Principal Name (SPN) is selected in the same section. If clients address the server under a name that does not match the stored SPN (e.g. sometimes the IP address, sometimes the short name, sometimes an alias), Kerberos authentication in particular fails. Use the FQDN (e.g. server.company.local) that matches the SPN consistently on all clients.

3. AD synchronization up to date? After changes in the Active Directory (new or renamed accounts), synchronize first. After a server update to version 18.0.7 or later, old imports may fail due to the stricter naming scheme (ADStrictNaming) – see the article on AD import for details and the solution.

4. "Multiple connections … are not allowed": This message concerns the AD import or synchronization, not the client login – see the article on AD import.

5. Alternative without SSO: If Integrated Windows Authentication is not possible in a specific case, imported AD users can alternatively log in using Windows Domain Credentials in version 19 – they enter their domain user name (DOMAIN\username or UPN) and their Windows password; validation is likewise performed against the Active Directory.

Related topics:

• Active Directory import and synchronization: requirements, permissions, and typical errors

• Connecting Entra ID (formerly Azure AD) to the Enterprise Server

• How do I use two-factor authentication (2FA/TOTP) in Password Depot?