Anmeldung per Single Sign-On (SSO) am Enterprise Server einrichten und Fehler beheben

Mit der Integrierten Windows-Authentifizierung (SSO) melden sich Benutzer ohne separate Password Depot-Zugangsdaten am Enterprise Server an: Der Client verwendet die bestehende Windows-Domänenanmeldung. Dieser Artikel beschreibt Einrichtung und die häufigsten Fehlerursachen.

Voraussetzungen

• Die Benutzer wurden zuvor per Extras → Active Directory-Import in den Server-Manager übernommen (siehe verwandter Artikel) – ohne korrekten AD-Import ist keine SSO-Anmeldung möglich.

• Der Client-PC ist Mitglied der Domäne. Password Depot speichert keine AD-Kennwörter; bei der Anmeldung wird gegen das Active Directory geprüft.

Einrichtung

1. Server: Aktivieren Sie im Server-Manager unter Verwalten → Servereinstellungen → Verbindungen bei den unterstützten Authentifizierungen die Integrierte Windows-Authentifizierung (Single Sign On).

2. Client: Stellen Sie unter Bearbeiten → Optionen → Netzwerk den Standard-Authentifizierungsmodus auf Integrierte Windows-Authentifizierung (SSO). Optional können Sie dort Standard-Domainname, Standard-UPN-Suffix und das Format des Benutzeranmeldenamens vorbelegen.

3. Anmelden: Wählen Sie im Client die Anmeldung am Enterprise Server und geben Sie Server-Adresse und Port an (Version 19: 25019). Bei korrekter Konfiguration zeigt das Anmeldefenster bereits Anmeldename und Domäne an – ein Klick auf ANMELDEN genügt.

Der Server verwendet die Benutzernamen so, wie sie aus dem Active Directory importiert wurden (normalerweise SAM-Accounts). Gültige Anmeldeformate sind DOMÄNE\Benutzername, der UPN (benutzername@domäne.tld) oder – sofern netzwerkweit eindeutig – der einfache Benutzername.

Hinweis: Auch bei SSO-Anmeldungen kann die Zwei-Faktor-Authentifizierung des Enterprise Servers greifen; sie lässt sich pro Benutzer konfigurieren.

Fehler beheben

1. SSPI-Modus testen: Unter Verwalten → Servereinstellungen → Active Directory (Bereich SSPI) wählen Sie den Authentifizierungsdienst: NTLM, Negotiate oder Kerberos. Schlägt die SSO-Anmeldung fehl, wechseln Sie testweise zwischen Kerberos und Negotiate und prüfen Sie die Anmeldung erneut.

2. SPN/FQDN-Konsistenz prüfen: Im selben Bereich wird der Dienstprinzipalname (SPN) ausgewählt. Sprechen die Clients den Server unter einem Namen an, der nicht zum hinterlegten SPN passt (z. B. mal IP-Adresse, mal Kurzname, mal Alias), schlägt insbesondere die Kerberos-Authentifizierung fehl. Verwenden Sie auf allen Clients konsistent den FQDN (z. B. server.firma.local), der dem SPN entspricht.

3. AD-Synchronisation aktuell? Nach Änderungen im Active Directory (neue oder umbenannte Konten) zunächst neu synchronisieren. Nach einem Server-Update auf Version 18.0.7 oder höher können Alt-Importe am strengeren Namensschema (ADStrictNaming) scheitern – Details und Lösung im Artikel zum AD-Import.

4. „Mehrfache Verbindungen … nicht zulässig“: Diese Meldung betrifft den AD-Import bzw. die Synchronisation, nicht die Client-Anmeldung – siehe Artikel zum AD-Import.

5. Alternative ohne SSO: Ist die Integrierte Windows-Authentifizierung im Einzelfall nicht möglich, können sich importierte AD-Benutzer in Version 19 alternativ per Windows Domain Credentials anmelden – dabei geben sie Domänen-Benutzername (DOMÄNE\Benutzername oder UPN) und Windows-Kennwort ein; die Prüfung erfolgt ebenfalls gegen das Active Directory.

Verwandte Themen:

• Active Directory-Import und -Synchronisation: Voraussetzungen, Berechtigungen und typische Fehler

• Entra ID (früher Azure AD) an den Enterprise Server anbinden

• Wie nutze ich die Zwei-Faktor-Authentifizierung (2FA/TOTP) in Password Depot?