Single Sign-On für Kerberos nur on-premise

In dieser Anleitung wird beschrieben, wie Sie Single Sign-On mit Microsoft Active Directory einrichten.

Konzeptübersicht

Wie jede andere Webanwendung hat auch Zammad seine eigene Logik, um Benutzer anzumelden, ihre Passwörter zu speichern, sie zu authentifizieren und ihre Sitzungen zu verwalten.

Wenn Ihre IT-Abteilung ein eigenes System für Benutzeridentitäten (wie Active Directory) unterhält, können Sie mit der SSO-Unterstützung von Zammad dieses bestehende Autorisierungssystem nutzen, so dass jeder, der ein Konto in Ihrer Firma hat, 1) automatisch ein Konto in Zammad hat und 2) sich mit einem einzigen Klick anmelden kann.

TIP

Wenn Sie nicht über diese IT-Infrastruktur verfügen, aber trotzdem eine Ein-Klick Anmeldung wünschen, können Sie Alternativen wie GitHub, Google, Facebook und andere nutzen.

Wie funktioniert das?

Zammad does not speak Kerberos itself. It provides the endpoint https://your.zammad.host/auth/sso and relies on the web server in front of it to authenticate the user before a request reaches that endpoint. The web server passes the user name along, Zammad looks up the user by their login and starts a session.

The user name can arrive in one of three forms, which Zammad checks in this order:

• the REMOTE_USER variable of the web server, only when the web server runs Zammad in its own process
• the Remote-User request header, which Zammad sees as HTTP_REMOTE_USER
• the X-Forwarded-User request header

Which one applies depends on your installation:

Package installation : Apache replaces Nginx on the Zammad host, authenticates /auth/sso and sets X-Forwarded-User.

Docker stack

The stack's own Nginx stays in place. An additional container in front of /auth/sso authenticates, sets X-Forwarded-User and forwards the request to Zammad's application server directly.

INFO

Moment, mit SSO ist es möglich, sich nur mit einem Benutzernamen anzumelden?

Im Prinzip ja.

Wie kann das richtig sein?

In dieser Anleitung konfigurieren wir unseren Webserver (Apache) so, dass er alle Anfragen an den Endpunkt /auth/sso abfängt. Anstatt sie an Zammad weiterzuleiten, initiiert Apache einen dreiseitigen Anmeldeprozess (Kerberos Authentifizierung) zwischen ihm selbst, dem Benutzer und dem Active Directory-Server.

Wenn Active Directory den Benutzer oder sein Passwort nicht erkennt, sieht Zammad die Anfrage nie, und die Sitzung wird nie erstellt.

Was bedeutet das alles?

Es bedeutet, dass es viele Möglichkeiten gibt, SSO einzurichten - Sie müssen weder diesem Leitfaden folgen noch Active Directory oder Kerberos verwenden. Aber Sie sollten unbedingt wissen, was Sie tun. Andernfalls kann leicht eine Sicherheitslücke entstehen.

Loslegen

TIP

Zu beschäftigt, um es selbst zu machen?

Wir sind für Sie da. Unsere Experten bieten maßgeschneiderte Workshops an, damit Ihr Team schnell und sicher starten kann. Schreiben Sie uns einfach eine Nachricht!

Sie benötigen:

• eine Microsoft Active Directory-Umgebung mit
  • Root-Zugang
  • Unterstützung für AES 256-bit Verschlüsselung
• a Zammad installation with a fully-qualified domain name (FQDN), either
  • a package installation with root access on the host, or
  • the Docker stack behind a reverse proxy that terminates TLS and routes by path, such as the Nginx Proxy Manager scenario
• gewisse Kenntnisse in der Systemverwaltung (z.B. Apache-Konfiguration)

Am besten richten Sie auch eine LDAP-Integration ein, um sicherzustellen, dass Ihre Active Directory- und Zammad-Benutzerkonten immer synchronisiert sind. Sie finden Sie in der Verwaltungsoberfläche von Zammad unter System > Integrationen > LDAP.

Schritt 1: Active Directory konfigurieren

Im Kerberos-Authentifizierungsschema muss der Authentifizierungsserver (Active Directory) gemeinsame Geheimnisse mit dem Service (Zammad) verwalten. Um dies zu ermöglichen, müssen wir einen service principal name (SPN) für Zammad im Active Directory registrieren.

INFO

Diese Anweisungen wurden für Windows Server 2016 bestätigt.

1a. Erstellen Sie einen Service-Account

Sie können ein bestehendes Konto verwenden, wenn Sie eines haben. Admin-Rechte sind nicht erforderlich; ein normales Benutzerkonto ist ausreichend.

1b. Passwort zurücksetzen

Passwort des Service Accounts zurücksetzen, nachdem die Option "This account supports Kerberos AES 256 bit encryption" aktiviert wurde.

Without this option, the keytab carries only RC4 keys, which current Kerberos libraries reject. The Docker SSO container is one of them.

1c. Registrieren eines SPN für Zammad

Ersetzen Sie die folgenden Platzhalter in den nachstehenden Befehlen:

• <zammad-host>: Zammad FQDN
• <service-acct>: Service-Account Login Name
• <password>: Passwort des Service-Accounts (Option /pass * hat sich als unbrauchbar erwiesen)
• <domain>: Windows Domäne
• <master-domain-controller>: IP/FQDN des Master Domain Controllers

Mit den folgenden Befehlen wird das Passwort des Benutzers abgefragt:

setspn -s HTTP/<zammad-host> <service-acct>

ktpass /princ HTTP/<zammad-host>@<DOMAIN> \
        /mapuser <service-acct> \
        /crypto AES256-SHA1 \
        /ptype KRB5_NT_PRINCIPAL \
        /pass <password> -SetPass +DumpSalt \
        /target <master-domain-controller> \
        /out zammad.keytab

1d. Notieren Sie den geheimen Schlüssel und die Versionsnummer

This step is for the package installation only. The Docker stack uses the zammad.keytab file written by the command above as it is.

The output of the command above contains important data for Step 2f below:

Using legacy password setting method
Failed to set property 'servicePrincipalName' to 'HTTP/<zammad-host>' on Dn 'CN=Zammad Service,DC=<domain>,DC=<tld>': 0x13.
WARNING: Unable to set SPN mapping data.
If <service-acct> already has an SPN mapping installed for HTTP/<zammad-host>, this is no cause for concern.
Building salt with principalname HTTP/<zammad-host> and domain <domain> (encryption type 18)...
Hashing password with salt "<domain><service-acct>".
Key created.
Output keytab to zammad.keytab:
Keytab version: 0x502
keysize 67 <service-acct>@<domain> ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0x5ee827c30c736dd4095c9cbe146eabc216415b1ddb134db6aabd61be8fdf7fb1) 

Die letzte Zeile ist zu beachten:

• den geheimen Schlüssel in Klammern am Ende (0x5ee827...)
• die Versionsnummer des geheimen Schlüssels mit vorangestelltem vno (3)

Step 2: Set up the Kerberos endpoint

Next, requests to /auth/sso must pass a web server that performs the Kerberos authentication before they reach Zammad. How you set this up depends on your installation: follow Package installation or Docker installation.

Paket-Installation

Als nächstes muss der Zammad-Host so konfiguriert werden, dass er Kerberos unterstützt (und die vom Active Directory-Server bereitgestellten Zugangsdaten akzeptiert).

In den meisten Fällen müssten Sie NGINX aus dem Quellcode mit einem zusätzlichen Modul neu kompilieren, um die Kerberos-Unterstützung zu aktivieren. Um dies zu umgehen, werden wir Apache verwenden, der Kerberos-Unterstützung durch ein Plug-in-Modul bietet.

INFO

Alle Befehle in diesem Abschnitt müssen als root (oder mit sudo) ausgeführt werden.

2a. NGINX ausschalten

WARNING

Dadurch ist Ihre Zammad-Instanz offline, bis Apache vollständig konfiguriert ist und läuft.

Nginx stoppen:

sudo systemctl stop nginx

Lassen Sie es nach einem Neustart ausgeschaltet:

sudo systemctl disable nginx

Wenn Sie die Ausfallzeit minimieren möchten, können Sie diesen Schritt zum Schluss ausführen; bedenken Sie jedoch, dass Apache nicht startet, wenn der Port, auf dem gelauscht werden soll, von NGINX verwendet wird.

Wenn Sie dieses Tutorial aus irgendeinem Grund nicht abschließen können, schalten Sie einfach Apache aus und stellen NGINX wieder her:

Details

sudo systemctl stop apache2

sudo systemctl disable apache2

sudo systemctl enable nginx

sudo systemctl start nginx

2b. Apache vorkonfigurieren

Diese Dokumentation setzt eine bereits funktionierende Apache-Konfiguration voraus. Sie sollten einen Blick in die Webserver Konfiguration werfen, bevor Sie fortfahren.

2c. Weitere Apache-Abhängigkeiten installieren

sudo apt update

sudo apt install krb5-user libapache2-mod-auth-gssapi

2d. Apache-Module aktivieren

SSO erfordert Module, die standardmäßig nicht aktiviert sind. Standardmäßig können Sie dafür a2enmod verwenden.

a2enmod auth_gssapi rewrite

sudo systemctl restart apache2

2e. Kerberos konfigurieren

Mit der Kerberos-Realm-Konfiguration teilen Sie dem Zammad-Server mit, wie er den Domänencontroller (Active Directory-Server) erreichen kann.

Ersetzen Sie die folgenden Platzhalter in der untenstehenden Beispielkonfiguration:

• <domain>: Windows Domäne
• <domain-controller>: IP/FQDN(s) des Domain-Controllers
• <master-domain-controller>: IP/FQDN des Master Domain-Controllers (darf nicht read-only sein; kann identisch zum <domain-controller> sein)

# /etc/krb5.conf

[libdefaults]
   default_realm = <DOMAIN>

   default_tkt_enctypes = aes256-cts-hmac-sha1-96
   default_tgs_enctypes = aes256-cts-hmac-sha1-96
   permitted_enctypes = aes256-cts-hmac-sha1-96

   kdc_timesync = 1
   ccache_type = 4
   forwardable = false
   proxiable = false
   fcc-mit-ticketflags = false

[realms]
         # multiple KDCs ok (one `kdc = ...` definition per line)
         <DOMAIN> = {
                  kdc = <domain-controller>
                  admin_server = <master-domain-controller>
                  default_domain = <domain>

                  # below is only for GSSAPI
                  auth_to_local = RULE:[1:$1@$0](.*@<domain>)s/@<domain>$//
                  auth_to_local = DEFAULT
         }

[domain_realm]
         .<domain> = <DOMAIN>
         <domain> = <DOMAIN>

2f. Keytab generieren

Apache benötigt eine Kerberos keytab (Schlüsseltabelle), um seine gemeinsamen Geheimnisse mit dem Domain Controller zu verwalten.

Ersetzen Sie die folgenden Platzhalter in den nachstehenden Befehlen:

• <zammad-host>: Zammad FQDN
• <domain>: Windows Domäne
• <secret-key>: Geheimer Schlüssel (lassen Sie die führende 0xweg)
• <vno>: Versionsnummer des geheimen Schlüssels

The secret key and version number were found in Step 1: Configure active directory above.

Führen Sie ktutil aus:

ktutil

Keytab hinzufügen:

ktutil: addent -key -p HTTP/<zammad-host>@<DOMAIN> -k <vno> -e aes256-cts
Key for HTTP/<zammad-host>@<domain> (hex): <secret-key>

Prüfen Sie, ob der Eintrag erfolgreich hinzugefügt wurde:

ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------------------------------
   1    3 HTTP/<zammad-host>@<DOMAIN>

Keytab speichern:

ktutil: wkt /root/zammad.keytab

Verlassen Sie ktutil:

ktutil: quit

Legen Sie die keytab in das Apache-Konfigurationsverzeichnis und setzen Sie die entsprechenden Berechtigungen:

sudo mv /root/zammad.keytab /etc/apache2/

sudo chown root:www-data /etc/apache2/zammad.keytab

sudo chmod 640 /etc/apache2/zammad.keytab

2g. Apache konfigurieren

Fügen Sie die folgende Parameter am Ende der Konfigurationsdatei des virtuellen Hosts hinzu, um Ihren Kerberos-SSO-Endpunkt unter /auth/sso zu erstellen:

Ersetzen Sie die folgenden Platzhalter in dem unten stehenden Befehl:

• <zammad-host>: Zammad FQDN
• <domain>: Windows Domäne

# /etc/apache2/sites-available/zammad.conf

<LocationMatch "/auth/sso">
   SSLRequireSSL
   AuthType GSSAPI
   AuthName "Your Zammad"
   GssapiBasicAuth On
   GssapiCredStore keytab:/etc/apache2/zammad.keytab
   GssapiLocalName On
   require valid-user

   RewriteEngine On
   RewriteCond %{LA-U:REMOTE_USER} (.+)
   RewriteRule . - [E=RU:%1,NS]
   RequestHeader set X-Forwarded-User "%{RU}e" env=RU
</LocationMatch>

2h. Restart Apache to apply changes

sudo systemctl restart apache2

Docker-Installation

The Docker stack runs its web server inside the zammad-nginx image, so you cannot swap it for Apache as in the package installation. Instead, a small additional container does the Kerberos part: the reverse proxy in front of the stack sends only /auth/sso through it, everything else goes straight to zammad-nginx as before. Zammad and the stack's compose files stay as they are. The SSO container is part of your infrastructure, like the reverse proxy that terminates TLS.

browser ──► reverse proxy (TLS)
              ├─ /auth/sso ──► zammad-sso ──(Kerberos ok, sets X-Forwarded-User)──► zammad-railsserver
              └─ everything else ──────────────────────────────────────────────► zammad-nginx ──► zammad-railsserver

The SSO container forwards /auth/sso to Zammad's application server directly and passes the user name in the X-Forwarded-User header, as the package installation does. One hop fewer, and zammad-nginx is not involved in the login.

INFO

Your reverse proxy can do Kerberos itself?

Then you don't need the SSO container. Configure the proxy to authenticate /auth/sso via Negotiate, put the user name without the realm into the X-Forwarded-User header, drop Remote-User and X-Forwarded-User sent by clients on every path, send /auth/sso to zammad-railsserver:3000, pass all other requests unchanged, and continue with Trusted proxies.

Sie benötigen:

• the stack behind a reverse proxy that routes by path. This guide uses the Nginx Proxy Manager scenario. Any proxy with path-based routing works the same way. If your proxy runs in a separate compose project, use the external network scenario and add that network to the zammad-sso service in the override file as well, so that the proxy can reach it.
• the zammad.keytab file written by ktpass in 1c. Register a SPN for Zammad, copied to the Docker host. The ktutil step of the package installation is not needed.

Files

The SSO container consists of the following files next to the stack's docker-compose.yml:

docker-compose.override.yml   adds the SSO container to the stack
zammad-sso/                   build context of the SSO image
  Dockerfile
  apache2-foreground
  zammad-sso.conf
local/zammad-sso/             files mounted into the container
  krb5.conf
  zammad.keytab

Keep the keytab out of the build context: Docker reads every file in zammad-sso/ when it builds the image, and a keytab that only the container's user may read makes the build fail. The container runs as www-data with user ID 33, so on a Linux host:

sudo chown 33 local/zammad-sso/zammad.keytab

sudo chmod 0400 local/zammad-sso/zammad.keytab

zammad-sso/Dockerfile builds Apache with mod_auth_gssapi from the Debian packages and runs it unprivileged:

FROM debian:trixie-slim

RUN apt-get update && \
    apt-get install -y --no-install-recommends apache2 libapache2-mod-auth-gssapi krb5-user curl && \
    rm -rf /var/lib/apt/lists/*

RUN a2enmod auth_gssapi proxy proxy_http headers rewrite && \
    a2dissite 000-default

COPY zammad-sso.conf /etc/apache2/sites-available/zammad-sso.conf
RUN a2ensite zammad-sso

# Debian's envvars assigns the APACHE_* variables unconditionally. Turn every
# "export VAR=value" into ": ${VAR:=value}; export VAR", so that values from the
# environment win, the same way the official php:apache image does it.
RUN sed -ri 's/^export ([^=]+)=(.*)$/: ${\1:=\2}\nexport \1/' /etc/apache2/envvars

# Run unprivileged: listen on 8080, pid/lock/logs under /tmp.
ENV APACHE_RUN_DIR=/tmp/apache2 \
    APACHE_PID_FILE=/tmp/apache2/apache2.pid \
    APACHE_LOCK_DIR=/tmp/apache2 \
    APACHE_LOG_DIR=/tmp/apache2

RUN echo 'Listen 8080' > /etc/apache2/ports.conf && \
    { echo 'ServerName zammad-sso'; \
      echo 'ErrorLog /proc/self/fd/2'; \
      echo 'CustomLog /proc/self/fd/1 combined'; } > /etc/apache2/conf-available/zz-docker.conf && \
    a2enconf zz-docker

COPY apache2-foreground /usr/local/bin/apache2-foreground

USER www-data
EXPOSE 8080

# Healthy = the keytab is readable and apache answers /auth/sso with the Negotiate
# challenge (401). A keytab with a wrong key is not detected here: apache still
# answers 401 and logs a GSS ERROR for every sign-in attempt.
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s \
  CMD klist -k /etc/apache2/zammad.keytab >/dev/null 2>&1 && \
      [ "$(curl -s -o /dev/null -w '%{http_code}' http://localhost:8080/auth/sso)" = "401" ] || exit 1

CMD ["apache2-foreground"]

zammad-sso/apache2-foreground starts Apache as the container's main process. Make it executable with chmod +x:

#!/bin/sh
# Start apache directly instead of through apache2ctl, so that it runs as PID 1
# and receives the container's signals. The run directory is created on every
# start and a stale pid file from a previous run is removed.
set -e
. /etc/apache2/envvars
mkdir -p "$APACHE_RUN_DIR" "$APACHE_LOCK_DIR" "$APACHE_LOG_DIR"
rm -f "$APACHE_PID_FILE"
exec apache2 -DFOREGROUND "$@"

zammad-sso/zammad-sso.conf authenticates /auth/sso and forwards it to the stack:

<VirtualHost *:8080>
  <Location "/auth/sso">
    AuthType GSSAPI
    AuthName "Zammad SSO"
    GssapiCredStore keytab:/etc/apache2/zammad.keytab
    GssapiAllowedMech krb5
    # strips @REALM
    GssapiLocalName On
    Require valid-user

    # inbound client values never survive
    RequestHeader unset Remote-User
    RequestHeader unset X-Forwarded-User
    RewriteEngine On
    RewriteCond %{LA-U:REMOTE_USER} (.+)
    RewriteRule . - [E=RU:%1,NS]
    RequestHeader set X-Forwarded-User "%{RU}e" env=RU
    # don't leak the Negotiate token downstream
    RequestHeader unset Authorization

    ProxyPreserveHost On
    ProxyPass        http://zammad-railsserver:3000/auth/sso
    ProxyPassReverse http://zammad-railsserver:3000/auth/sso
  </Location>
</VirtualHost>

Add the zammad-sso service to your docker-compose.override.yml. If the stack has no override file yet, create it from the shipped template, see Customize the stack locally:

---
services:
  zammad-sso:
    build: ./zammad-sso
    restart: ${RESTART:-always}
    volumes:
      - ./local/zammad-sso/krb5.conf:/etc/krb5.conf:ro
      - ./local/zammad-sso/zammad.keytab:/etc/apache2/zammad.keytab:ro

local/zammad-sso/krb5.conf tells the container how to reach your domain controller. Replace the placeholders as described in 2e. Configure Kerberos:

[libdefaults]
    default_realm = <DOMAIN>
    dns_lookup_realm = false
    dns_lookup_kdc = false
    rdns = false

[realms]
    <DOMAIN> = {
        kdc = <domain-controller>
        admin_server = <master-domain-controller>
    }

[domain_realm]
    .<domain> = <DOMAIN>
    <domain> = <DOMAIN>

Add the override file and the reverse proxy as trusted proxy to your .env:

COMPOSE_FILE=docker-compose.yml:scenarios/add-nginx-proxy-manager.yml:docker-compose.override.yml
ZAMMAD_FQDN=<zammad-host>
ZAMMAD_HTTP_TYPE=https
RAILS_TRUSTED_PROXIES=nginx-proxy-manager

Then build and start the stack:

docker compose up -d --build

The zammad-sso container reports healthy once the keytab is readable and Apache answers /auth/sso with the Kerberos challenge. If it stays unhealthy, the keytab is missing or not readable by user ID 33.

Configure the reverse proxy

In Nginx Proxy Manager:

1. Create a proxy host for your Zammad FQDN with scheme http, forward host zammad-nginx and port 8080. Enable Websockets Support and set up the certificate on the SSL tab.
2. Add a Custom Location for /auth/sso with scheme http, forward host zammad-sso and port 8080.

Do not rely on the Advanced field to strip headers: proxy_set_header lines entered there do not reach the generated locations and would only give a false sense of security. Client-sent headers are removed in the SSO container.

With Traefik, the equivalent is a router that points at the SSO container, with a higher priority than the router for the rest of the stack and the rule:

Host(`<zammad-host>`) && PathPrefix(`/auth/sso`)

Trusted proxies

Zammad has to trust the reverse proxy, so that it takes the address of the user's browser as the client instead of a container address. That is what RAILS_TRUSTED_PROXIES in .env does. With another proxy, name that one instead, see environment variables. The SSO container does not need to be listed: Zammad takes the address the reverse proxy forwarded and falls back to the sending container only when no untrusted forwarded address is left.

The Trusted SSO Proxy IPs setting in Step 3 then holds the address ranges from which users may sign in via SSO, typically your intranet. A changed value applies after at most 15 seconds. Without the reverse proxy in RAILS_TRUSTED_PROXIES, Zammad takes a container's address as the client, and the setting would have to hold the stack's network range, which admits every container.

WARNING

The setting guards the way in through the reverse proxy only. Inside the stack's network, zammad-railsserver accepts an X-Forwarded-User header from any container, and a container can send the X-Forwarded-For header the check relies on along with it. Keep zammad-railsserver reachable only from the stack's own containers and the SSO container, and set the trusted IPs before you enable SSO.

Portainer

Without shell access to the Docker host, you can build and run the same container through the Portainer UI:

1. Under Images, choose Build a new image, upload a tarball that contains the three files of zammad-sso/ at its top level (not the directory itself) and tag the image, e.g. zammad-sso:local. The image contains no keytab, so it holds no secret.

2. Under Volumes, choose Add volume and create zammad-sso-secrets.

3. Put zammad.keytab and krb5.conf into the volume. Portainer Business has a volume browser with upload. In the Community Edition, deploy a throwaway container (alpine with the command sleep infinity) that mounts the volume at /secrets, paste the files through its console (for example via base64 -d), set owner 33 and mode 0400 on the keytab, and remove the container again.

4. Under Stacks, choose Add stack and deploy the SSO container with the web editor as a stack of its own that joins the Zammad stack's network. Replace <zammad-stack> with the name of your Zammad stack in Portainer.

   services:
     zammad-sso:
       image: zammad-sso:local
       restart: always
       volumes:
         - type: volume
           source: zammad-sso-secrets
           target: /etc/krb5.conf
           read_only: true
           volume:
             subpath: krb5.conf
         - type: volume
           source: zammad-sso-secrets
           target: /etc/apache2/zammad.keytab
           read_only: true
           volume:
             subpath: zammad.keytab
       networks:
         - zammad
   
   networks:
     zammad:
       external: true
       name: <zammad-stack>_default
   
   volumes:
     zammad-sso-secrets:
       external: true

The reverse proxy is configured as above and has to be a trusted proxy of the Zammad stack, see Trusted proxies.

Schritt 3: Aktivieren Sie SSO in Zammad

Next, enable "Authentication via SSO" in Zammad's admin interface under Settings > Security > Third-party Applications. Make sure to configure the trusted SSO proxy IPs for production systems. For the Docker stack, Trusted proxies explains which addresses belong there.

TIP

Öffnen Sie bei älteren Versionen von Zammad https://your.zammad.host/auth/sso, um sich anzumelden.

Schritt 4: Client-System konfigurieren (nur Windows)

Für die vollständige SSO-Erfahrung (d.h. für die passwortlose Anmeldung mit einem Klick) müssen Benutzer von Zammad:

1. sich im lokalen Intranet des Active Directory-Servers befinden; und
2. ihre Netzwerkeinstellungen so ändern, dass der Zammad-Host wie ein lokaler Intranet-Server behandelt wird.

Ohne diesen Schritt müssen die Benutzer ihre Zugangsdaten für Active Directory während des SSO eingeben.

TIP

Diese Einstellung kann zentral für das gesamte Intranet verwaltet werden, indem ein Gruppenrichtlinienobjekt (GPO) verwendet wird.

1. Fügen Sie Ihren Zammad FQDN in den Internetoptionen unter Security > Local Intranet > Sites > Advanced hinzu.
2. Wählen Sie "Require server verification (https:) for all sites in this zone"
3. Wählen Sie unter Security level for this zone > Custom level... > Settings > User Authentication > Logon die Option "Automatic logon only in Intranet Zone".

Fehlerbehebung

• Sind alle relevanten FQDNs/Hostnamen von Ihren Active Directory- und Zammad-Servern (auch die beiden gegenseitig) erreichbar?
• Sind die Systemuhren Ihrer Active Directory- und Zammad-Server innerhalb von fünf Minuten zueinander synchronisiert? Kerberos ist ein zeitkritisches Protokoll!

Fehler in Apache-Protokollen

TIP

Versuchen Sie, das Apache-Log-Level vorübergehend zu erhöhen.

Fügen Sie LogLevel debug zur Konfiguration Ihres virtuellen Hosts hinzu und starten Sie dann den Dienst neu, um die Änderungen zu übernehmen.

An unsupported mechanism was requested

Ist in Ihrem Active Directory-Serviceaccount die Kerberos AES 256-bit encryption aktiviert?

Wenn Ihr Server aus irgendeinem Grund keine AES 256-Bit-Verschlüsselung unterstützt, finden Sie im LDAP-Wiki weitere Informationen über Kerberos-Verschlüsselungsarten.

Failed to verify krb5 credentials: Key version is not available

Did you use the exact version number (vno) provided by ktpass when generating your keytab?

Versuchen Sie sicherheitshalber, sie erneut zu erzeugen.

Unspecified GSS failure. Minor code may provide more information (, no key table entry found for HTTP/FQDN@DOMAIN)

Does the service name you provided to setspn exactly match the one you used when generating your keytab?

Versuchen Sie sicherheitshalber, sie erneut zu erzeugen.

No key table entry found for HTTP/FQDN@DOMAIN

Stimmt die Einstellung KrbServiceName Ihrer virtuellen Hostkonfiguration genau mit dem service name überein, den Sie in setspn angegeben haben?

Bei dieser Einstellung wird zwischen Groß- und Kleinschreibung unterschieden.

Warning: Received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration

Ist Ihr Zammad-Host unter einem FQDN erreichbar? Dieser Fehler kann darauf hinweisen, dass Sie Ihren Zammad-Host stattdessen als IP-Adresse konfiguriert haben.

Cannot decrypt ticket for HTTP/FQDN@DOMAIN

Haben Sie sichergestellt, dass Sie das Passwort für Ihr Konto beim Active Directory-Dienst nach der Aktivierung der 256-Bit-AES-Verschlüsselung geändert haben?

Und haben Sie darauf geachtet, nach dem Ändern Ihres Passwortes den SPN zu registrieren (mit ktpass) und Ihre Keytab zu generieren (mit ktutil)?

Versuchen Sie, kinit -k -t <Pfad zu keytab Schlüsseltabelle> HTTP/<zammad-host>@<DOMAIN> auszuführen. Wenn keine Ausgabe zurückgegeben wird, ist alles gut - wenn Sie "kinit: Preauthentication failed while getting initial credentials" sehen, waren entweder Ihre Zugangsdaten falsch oder Sie haben /pass * während des ktpass-Befehls verwendet.

Failed when verifying KDC" and "failed to verify krb5 credentials: Decrypt integrity check failed

Vergewissern Sie sich, dass KrbServiceName der richtige, über setspn bereitgestellte ServiceName ist.

Stellen Sie sicher, dass Ihr Active Directory die konfigurierte Verschlüsselungsmethode unterstützt.

Wenn alles oben genannte korrekt ist und Sie die Anleitung befolgt haben, stellen Sie sicher, dass Ihr Client die Ergebnisse nicht im Cache speichert. klist purge löscht den Cache des Clients - alternativ können Sie auch einen Neustart des Clients durchführen.

Docker stack

502 Bad Gateway on /auth/sso only, after recreating the SSO container

The reverse proxy still holds the container's old address. Nginx Proxy Manager resolves the name only when it loads its configuration, so reload it: docker compose exec nginx-proxy-manager nginx -s reload.

SSO request from untrusted IP address, after recreating the reverse proxy

Zammad resolves the names in RAILS_TRUSTED_PROXIES when it starts, see environment variables, so it still trusts the proxy's old address, sees the new one as the client and checks it against Trusted SSO Proxy IPs. Restart the services that trust the proxy: docker compose restart zammad-railsserver zammad-websocket.

Signing in via SSO fails although the zammad-sso container is healthy

The health check verifies that the keytab is readable and that Apache issues the Kerberos challenge. It cannot verify the key itself. Check docker compose logs zammad-sso: a line GSS ERROR … cannot decrypt ticket means the keytab does not match the service account's current key, usually because it was exported before the last password reset. Export it again as described in 1c. Register a SPN for Zammad.