--- url: https://next.zammad.org/it/tutorials/sso-kerberos.md --- # Single sign-on for Kerberos Questa guida tratterà come configurare il single sign-on usando Microsoft Active Directory. ## Conceptual overview Come ogni altra applicazione web, Zammad ha la propria logica per la registrazione degli utenti. Se il tuo reparto IT mantiene un proprio archivio di identità utente (come Active Directory). ::: tip If you don't have this IT infrastructure but still want one-click login, you can use alternatives like GitHub, Google, Facebook and more. ::: ## How does it work? 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 **Wait. SSO allows you to sign in with only a username?** In principle, yes. **How is that okay?** In this guide, we configure our web server (Apache) to intercept all requests to the `/auth/sso` endpoint. Instead of forwarding them to Zammad, Apache initiates a three-sided login process (*Kerberos authentication*) between the itself, the user, and the Active Directory server. If Active Directory doesn't recognize the user or their password, Zammad never sees the request, and the session is never created. **What does this all mean?** It means there are many ways you could set up SSO, you don't need to follow this guide or even use Active Directory or Kerberos, but if you don't know what you're doing, you're going to end up with a *massive* security hole. ::: ## Per iniziare ::: tip **Troppo impegnato per occupartene da solo?** Ci pensiamo noi. I nostri esperti offrono workshop personalizzati per aiutare il tuo team a essere operativo in modo rapido e sicuro. [Scrivici un messaggio](https://zammad.com/contact){target=\_blank}! ::: Avrai bisogno di: * un ambiente Microsoft Active Directory con * accesso root * supporto per crittografia AES a 256 bit * 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](/en/reference/docker-compose-scenarios#add-nginx-proxy-manager) * una certa familiarità con l'amministrazione di sistema (ad esempio configurazione Apache) For best results, set up the LDAP integration to make sure your Active Directory and Zammad user accounts are always in sync. You can find it in Zammad's admin interface under *System > Integrations > LDAP*. ## Step 1: Configure active directory Nello schema di autenticazione Kerberos, il **server di autenticazione** (Active Directory) deve. ::: info Queste istruzioni sono state confermate su Windows Server 2016. ::: ### 1a. Crea un account di servizio Puoi usare un account di servizio esistente se ne hai uno. Non sono richiesti privilegi amministrativi. ![Screenshot impostazioni account di servizio Active Directory](/screenshots/tutorials/sso-kerberos/active-directory-service-account-settings.png) ### 1b. Reset password Reimposta la password dell'account di servizio dopo aver abilitato l'opzione "Questo account supporta Kerberos AES 256. Without this option, the keytab carries only RC4 keys, which current Kerberos libraries reject. The Docker SSO container is one of them. ### 1c. Registra un SPN per Zammad Sostituisci i seguenti segnaposto nei comandi seguenti: * ``: FQDN di Zammad * ``: Nome di accesso dell'account di servizio * ``: Password dell'account di servizio (l'opzione `/pass *` si è dimostrata non funzionante) * ``: Dominio Windows * ``: IP/FQDN del controller di dominio master I comandi seguenti chiederanno la password dell'utente: ```sh setspn -s HTTP/ ``` ```sh ktpass /princ HTTP/@ \ /mapuser \ /cry ``` ### 1d. Annota la chiave segreta e il numero di versione 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: ```sh Usando il metodo legacy di impostazione password Impossibile impostare la proprietà 'servicePrincipalName' su 'HTT ``` Sull'ultima riga, prendi nota di: * la chiave segreta tra parentesi alla fine (**0x5ee827...**) * il numero di versione della chiave segreta preceduto da `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](#package-installation) or [Docker installation](#docker-installation). ### Package installation Successivamente, l'host Zammad deve essere configurato per supportare Kerberos (e accettare credenziali di autenticazione. Nella maggior parte dei casi, dovresti ricompilare NGINX da sorgente con un modulo aggiuntivo per abilitare. ::: info Tutti i comandi in questa sezione devono essere eseguiti come root (o con `sudo`). ::: #### 2a. Turn off NGINX ::: warning Questo metterà la tua istanza Zammad **offline** finché Apache non è completamente configurato e in esecuzione. ::: Disattiva Nginx: ```sh sudo systemctl stop nginx ``` Mantienilo disattivato dopo il riavvio: ```sh sudo systemctl disable nginx ``` Se vuoi minimizzare il downtime, puoi salvare questo passaggio per ultimo; tieni solo presente che. Se non riesci a completare questo tutorial per qualsiasi motivo, disattiva semplicemente Apache e ripristina NGI ::: details ```sh sudo systemctl stop apache2 ``` ```sh sudo systemctl disable apache2 ``` ````sh su ::: #### 2b. Pre-configure Apache Questa documentazione presuppone una configurazione Apache già funzionante. Prima di continuare, si consiglia di consultare la [guida alla configurazione del server web](/en/tutorials/webserver-config). #### 2c. Install further Apache dependencies ::: tabs === Debian & Ubuntu ```sh sudo apt update ```` ````sh sudo apt install krb5-user libapach ::: #### 2d. Enable Apache modules SSO richiede moduli non abilitati per impostazione predefinita. Per impostazione predefinita puoi usare `a2enmod` per. ::: tabs === a2enmod (Debian & Ubuntu) ```sh a2enmod auth_gssapi rewrite ```` ````sh sudo systemct ::: #### 2e. Configura Kerberos La configurazione del realm Kerberos è come dici al server Zammad come raggiungere il _domain controller_. Sostituisci i seguenti segnaposto nella configurazione di esempio sotto: - ``: Dominio Windows - ``: IP/FQDN del controller di dominio - ``: IP/FQDN del controller di dominio master (non deve essere sola lettura, ma ```ini # /etc/krb5.conf [libdefaults] default_realm = 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) = { kdc = admin_server = default_domain = # below is only for GSSAPI auth_to_local = RULE:[1:$1@$0](.*@)s/@$// auth_to_local = DEFAULT } [domain_realm] . = = ```` #### 2f. Generate keytab Apache ha bisogno di un *keytab* Kerberos (tabella chiavi) per gestire i suoi segreti condivisi con il dominio. Sostituisci i seguenti segnaposto nei comandi seguenti: * ``: FQDN di Zammad * ``: Dominio Windows * ``: Chiave segreta (**ometti lo** `0x` iniziale) * ``: Numero di versione della chiave segreta The secret key and version number were found in [Step 1: Configure active directory](#step-1-configure-active-directory) above. Entra in ktutil: ```sh ktutil ``` Aggiungi keytab: ```sh ktutil: addent -key -p HTTP/@ -k -e aes256-cts Key for HTTP/`: FQDN di Zammad - ``: Dominio Windows ::: tabs === Debian & Ubuntu ``` apache # /etc/apache2/sites-available/zammad.conf 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 ```` \=== CentOS & OpenSUSE The configuration for CentOS and OpenSUSE below contains two `Krb5KeyTab` lines! Keep only the one you need. ```apache # /etc/apache2/sites-available/zammad.conf SSLRequireSSL AuthType Kerberos AuthName "Your Zammad" KrbMethodNegotiate On KrbVerifyKDC On KrbMethodK5Passwd On KrbAuthRealms # strips @REALM suffix from REMOTE_USER variable KrbLocalUserMapping on KrbServiceName HTTP/@ # Ubuntu, Debian, & openSUSE Krb5KeyTab /etc/apache2/zammad.keytab # CentOS Krb5KeyTab /etc/httpd/zammad.keytab require valid-user RewriteEngine On RewriteCond %{LA-U:REMOTE_USER} (.+) RewriteRule . - [E=RU:%1,NS] RequestHeader set X-Forwarded-User "%{RU}e" env=RU ``` ::: #### 2h. Restart Apache to apply changes ```sh 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. ```text 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](#trusted-proxies). ::: Ti serve: * the stack behind a reverse proxy that routes by path. This guide uses the [Nginx Proxy Manager scenario](/en/reference/docker-compose-scenarios#add-nginx-proxy-manager). Any proxy with path-based routing works the same way. If your proxy runs in a separate compose project, use the [external network scenario](/en/reference/docker-compose-scenarios#add-external-docker-network-to-nginx) 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](/en/tutorials/sso-kerberos#_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`: ```text 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: ```sh sudo chown 33 local/zammad-sso/zammad.keytab ``` ```sh 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: ```dockerfile 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`: ```sh #!/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: ```apache 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 ``` 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](/en/reference/docker-compose-scenarios#customize-the-stack-locally): ```yaml --- 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](/en/tutorials/sso-kerberos#_2e-configure-kerberos): ```text [libdefaults] default_realm = dns_lookup_realm = false dns_lookup_kdc = false rdns = false [realms] = { kdc = admin_server = } [domain_realm] . = = ``` Add the override file and the reverse proxy as trusted proxy to your `.env`: ```text COMPOSE_FILE=docker-compose.yml:scenarios/add-nginx-proxy-manager.yml:docker-compose.override.yml ZAMMAD_FQDN= ZAMMAD_HTTP_TYPE=https RAILS_TRUSTED_PROXIES=nginx-proxy-manager ``` Then build and start the stack: ```sh 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: ```text 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](/en/reference/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](#step-3-enable-sso-in-zammad) 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 `` with the name of your Zammad stack in Portainer. ```yaml 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: _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](#trusted-proxies). ## Passo 3: Abilita 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](#trusted-proxies) explains which addresses belong there. ::: tip Nelle versioni più vecchie di Zammad, visita `https://your.zammad.host/auth/sso` per accedere. ::: ## Step 4: Configure client system (Windows only) Per l'esperienza SSO completa (ovvero per l'accesso con un clic senza password), gli utenti Zammad devono: 1. essere sulla intranet locale del server Active Directory; e 2. modificare le proprie impostazioni di rete in modo che l'host Zammad sia trattato come un server intranet locale. Senza questo passaggio, gli utenti devono inserire le proprie credenziali Active Directory durante l'SSO. :::: tabs \=== IE / Edge / Chromium ::: tip Questa impostazione può essere gestita centralmente in tutta la intranet usando un \*\*oggetto criteri di gruppo. ::: 1. Aggiungi il tuo FQDN Zammad in Opzioni Internet sotto \_Sicurezza > Intranet locale > Siti > ::: info Questa opzione non può essere gestita centralmente perché è impostata nel browser anziché in Windows. ::: 1. Inserisci `about:config` nella barra degli indirizzi. Fai clic su **Accetta il rischio e continua**. 2. :::: ## Risoluzione problemi * Tutti gli FQDN/hostname rilevanti sono raggiungibili dai tuoi server Active Directory e Zammad ( * Gli orologi di sistema dei tuoi server Active Directory e Zammad sono sincronizzati entro cinque. ### Errors in Apache logs ::: tip **Prova a innalzare temporaneamente il livello di log di Apache.** Aggiungi `LogLevel debug` al tuo virtual host. ::: #### È stato richiesto un meccanismo non supportato Il tuo account di servizio Active Directory ha abilitata la **crittografia Kerberos AES a 256 bit**? Se per qualche motivo il tuo server non supporta la crittografia AES a 256 bit, la wiki di LDAP contiene [ulteriori informazioni sui tipi di crittografia Kerberos](https://ldapwiki.com/wiki/MsDS-SupportedEncryptionTypes){target=\_blank}. #### Impossibile verificare le credenziali krb5: la versione della chiave non è disponibile Did you use the exact **version number** (`vno`) provided by `ktpass` when [generating your keytab](/en/tutorials/sso-kerberos#_2f-generate-keytab)? Prova a generarlo di nuovo, solo per essere sicuro. #### 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](/en/tutorials/sso-kerberos#_2f-generate-keytab)? Prova a generarlo di nuovo, solo per essere sicuro. #### Nessuna voce nella tabella chiavi trovata per HTTP/FQDN@DOMAIN L'impostazione `KrbServiceName` della configurazione del tuo virtual host corrisponde esattamente al \*\*nome del servizio. Questa impostazione fa distinzione tra maiuscole e minuscole. #### Warning: Received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration Il tuo host Zammad è accessibile tramite un FQDN? Questo errore potrebbe indicare che hai configurato il tuo. #### Impossibile decrittografare il ticket per HTTP/FQDN@DOMAIN Ti sei assicurato di cambiare la password sul tuo account di servizio Active Directory \_dopo aver. E ti sei assicurato di registrare lo SPN (con `ktpass`) e generare il tuo keytab (con. Prova a eseguire `kinit -k -t HTTP/@`. Se non viene restituito alcun output. #### Fallito durante la verifica del KDC" e "impossibile verificare le credenziali krb5: controllo integrità decrittografia. Assicurati che `KrbServiceName` sia il ServiceName corretto fornito tramite setspn. Assicurati che il tuo Active Directory supporti il metodo di crittografia configurato. Se tutto quanto sopra è corretto e il resto delle FAQ è anche garantito, assicurati che il tuo client non. ### 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](/en/reference/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](/en/tutorials/sso-kerberos#_1c-register-a-spn-for-zammad).