Одељак са значком прилагођен текст

Овај водич ће објаснити како поставити јединствену пријаву коришћењем Microsoft Active Directoryja.

Преглед функција

Као и свака друга веб апликација, Zammad има сопствену логику за регистрацију корисника, чување лозинки, аутентификацију и управљање сесијама.

Ако ваше IT одељење одржава сопствено складиште идентитета корисника (попут Active Directoryja), SSO подршка у Zammad-у омогућава искоришћавање тог постојећег система аутентификације, тако да свако ко има налог на вашој локалној интранету 1) аутоматски ће имати налог у Zammad-у и 2) моћи ће да се пријави једним кликом.

TIP

Ако немате ову IT инфраструктуру, али желите пријаву једним кликом, могуће је користити алтернативе као што су GitHub, Google, Facebook и друге.

Како то уствари функционише?

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

Чек. SSO омогућава пријаву само корисничким именом?

У принципу, да.

Како је то у реду?

У овом водичу конфигурисали смо веб сервер (Apache) да прекине све захтеве ка /auth/sso ендпоинту. Уместо да их проследи на Zammad, Apache иницира процес пријаве са три стране (Kerberos аутентификација) између себе, корисника и сервера Active Directoryja.

Ако Active Directory не препозна корисника или његову лозинку, Zammad никада не види захтев и сесија се никада не креира.

Шта све ово значи?

То значи да постоји много начина како можете поставити SSO—не морате пратити овај водич нити користити Active Directory или Kerberos—али ако не знате шта радите, на крају ћете имати огроман пропуст у безбедности.

Први кораци

TIP

Превише сте заузети да то урадите сами?

Ту смо за вас. Наши стручњаци нуде прилагођене радионице које ће ваш тим брзо покренути и оснажити. Јавите нам се!

Требаће вам:

Microsoft Active Directory окружење са
- роот приступ
- подршка за AES енкрипцију на 256 бита
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
одређено познавање администрације система (нпр. конфигурација Апацха)

За најбоље резултате подесите LDAP интеграцију како бисте осигурали да су ваши Active Directory и Zammad налози увек синхронизовани. Можете је пронаћи у админ интерфејсу Zammad-а под Settings > Security > Third-party Applications.

Корак 1: Клонирање GitHub репозиторија

У Kerberos шеми аутентификације, сервер за аутентификацију (Active Directory) мора да одржава заједничке тајне са услугом (Zammad). Да би се то омогућило, на Active Directory-u морамо регистровати сервице принципал наме (SPN) за Zammad.

INFO

Ове упуте су потврђене на Windows Серверу 2016.

1a. Креирајте сервисни налог

Можете искористити постојећи сервисни налог ако га имате. Администратор овлашћења нису потребна; обичан кориснички налог је довољан.

1b. Ресетуј лозинку

Ресетујте лозинку сервисног налога након укључивања опције "Овај налог подржава 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. Региструјте SPN за Zammad

Замените следеће плацехолдер-е у командама испод:

<zammad-host>: Zammad FQDN
<service-acct>: Корисничко име за пријаву сервисног налога
<password>: Лозинка сервисног налога (Опција /pass * се показала као нефункционална)
<domain>: Windows домен
<master-domain-controller>: IP/FQD master доменског контролера

Команде испод ће тражити лозинку корисника:

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. Забележите тајни кључ и верзионски број

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)

На последњој линији, обратите пажњу на:

тајни кључ у загради на крају (0x5ee827...)
верзионски број тајног кључа који претходи 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.

Инсталација пакета

Затим, хост за Zammad мора бити конфигурисан да подржава Kerberos (и да прихвати аутентификационе креденцијале које пружа Active Directory сервер).

У већини случајева морали бисте прецомпајлирати NGINX из изворног кода са додатним модулом да омогућите подршку за Kerberos. Да бисмо заобишли овај проблем, користићемо Apache, који нуди подршку за Kerberos путем плугин модула.

INFO

Све команде у овом одељку морају се извршити као роот (или са sudo).

2a. Искључите NGINX

WARNING

Ово ће довести вашу Zammad инстанцу оффлине док се Apache у потпуности не конфигурише и не покрене.

Искључите Nginx:

systemctl стоп nginx

Задржите искљученим након поновног покретања:

$ systemctl дисабле nginx

Ако желите да смањите време неактивности, овај корак можете оставити за крај; само имајте на уму да се Apache неће покренути ако порт који жели да користи већ користи NGINX.

Ако из било ког разлога не можете да довршите овај водич, једноставно искључите Apache и поново активирајте NGINX:

Details

sudo systemctl stop apache2

sudo systemctl disable apache2

sudo systemctl enable nginx

sudo systemctl start nginx

2b. Предконфигурација Apache-а

Ова документација подразумева већ функционалну Apache конфигурацију. Пре наставка, погледајте водич за конфигурацију web сервера.

2c. Инсталирајте додатне зависности за Apache

sudo apt update

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

2d. Омогућите Apache модуле

SSO захтева модуле који нису омогућени подразумевано. Подразумевано можете искористити a2enmod за ту сврху.

a2enmod auth_gssapi rewrite

sudo systemctl restart apache2

2e. Конфигуришите Kerberos

Конфигурација Kerberos домене одређује начин на који ће Zammad сервер комуницирати са контролером домене (сервером Active Directory).

Замените следеће плацехолдер-е у примеру конфигурације испод:

<domain>: Windows домен
<domain-controller>: IP/FQDN(и) контролера домене
<master-domain-controller>: IP/FQDN главног контролера домене (не сме бити само за читање, али може бити исти као <domain-controller>)

ini

# /etc/krb5.conf

[либдефаултс]
   дефаулт_реалм = <DOMAIN>

   default_tkt_enctypes = aes256-цтс-хмац-sha1-96
   default_tgs_enctypes = aes256-цтс-хмац-sha1-96
   permitted_enctypes = aes256-цтс-хмац-sha1-96

   kdc_timesync = 1
   ccache_type = 4
   forwardable = фалсе
   proxiable = фалсе
   фцц-мит-тицкетфлагс = фалсе

[реалмс]
         # више КДЦ дозвољено (једна `kdc = ...` дефиниција по линији)
         <DOMAIN> = {
                  кдц = <domain-controller>
                  админ_сервер = <master-domain-controller>
                  дефаулт_домаин = <domain>

                  # испод важи само за GSSAPI
                  аутх_то_лоцал = RULE:[1:$1@$0](.*@<domain>)с/@<domain>$//
                  аутх_то_лоцал = DEFAULT
         }

[домаин_реалм]
         .<domain> = <DOMAIN>
         <domain> = <DOMAIN>

2f. Генеришите keytab

Apache-у је потребан Kerberos keytab (табела кључева) за управљање заједничким тајнама са контролером домене.

Замените следеће плацехолдер-е у командама испод:

<zammad-host>: Zammad FQDN
<domain>: Windows домен
<secret-key>: Тајни кључ (изоставите почетно 0x)
<vno>: Верзија тајног кључа

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

Унесите команду ктутил:

ktutil

Додајте keytab:

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

Потврдите да је унос успешно додат:

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

Запишите keytab на диск:

ktutil: wkt /root/zammad.keytab

Напустите ктутил:

ktutil: quit

Затим, поставите keytab у директоријум за конфигурацију Apache-а и подесите одговарајућа права:

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

Додајте следећу директиву на крај датотеке конфигурације виртуелног домена да бисте креирали своју Kerberos SSO крајњу тачку на /auth/sso:

Замените следеће плацехолдер-е у конфигурацији испод:

<zammad-host>: Zammad FQDN
<domain>: Windows домен

apache

# /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

systemctl рестарт apache2

Инсталација пакета

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.

Потребно вам је:

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:

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:

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:

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:

#!/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

<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:

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:

text

[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:

text

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:

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.
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(`<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:

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.
Under Volumes, choose Add volume and create zammad-sso-secrets.
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.

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.

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: <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.

Корак 3: Укључите SSO пријаву за 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

На старијим верзијама Zammad-а посетите https://vaš.zammad.host/auth/sso да се пријавите.

Корак 4: Конфигуришите клијентски систем (само за Windows)

За потпуно искуство SSO (односно, пријаву једним кликом без лозинке), корисници Zammad-а морају:

бити на локалном интранету сервера Active Directory; и
изменити своја мрежна подешавања за домаћина Zammad-а да би се третирао као сервер локалног интранета.

Без овог корака, корисници морају унети своја креденцијала Active Directory током SSO.

TIP

Ово подешавање се може централно управљати на целом интранету користећи објекат групне политике (GPO).

У Опцијама интернета додајте FQDN свог Zammad-а под Безбедност > Локални интранет > Сајтови > Напредно.
Означите "Захтевај проверу сервера (хттпс:) за све сајтове у овој зони".
У оквиру Ниво безбедности за ову зону > Прилагођени ниво... > Подешавања > Корисничка аутентификација > Пријава, изаберите "Аутоматска пријава само у зони интранета".

Решавање проблема

Да ли су сви релевантни FQDN/хостнаме-и доступни са сервера Active Directory и Zammad (укључујући међусобно)?
Да ли су системски сатови сервера Active Directory и Zammad синхронизовани у оквиру пет минута један од другог? Kerberos је протокол осетљив на време!

Грешке у Apache логовима

TIP

Покушајте привремено повисити ниво логовања Apache-а.

Додајте LogLevel debug у конфигурацију виртуелног домена, затим рестартујте сервис да примените промене.

Затражен је неподржан механизам

Да ли ваш сервисни налог Active Directory има омогућено Kerberos AES енкрипцију од 256 бита?

Ако из неког разлога ваш сервер не подржава AES енкрипцију од 256 бита, LDAP Wiki пружа више информација о типовима Kerberos енкрипције.

Неуспешна провера krb5 креденцијала: Верзија кључа није доступна

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

Покушајте да га поново генеришете, само да будете сигурни.

Непозната грешка GSS-а. Мањи код може пружити више информација (, Није пронађен унос у табели кључева за HTTP/FQDN@DOMAIN)

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

Покушајте да га поново генеришете, само да будете сигурни.

Запис у keytab-u за HTTP/FQDN@DOMAIN није пронађен

Да ли подешавање KrbServiceName ваше конфигурације виртуелног домаћина тачно одговара називу сервиса који сте унели у setspn?

Подешавање је осетљиво на велика и мала слова.

Упозорење: примљени токен вероватно је NTLM, који није подржан од стране Kerberos модула. Проверите своју IE конфигурацију

Да ли је ваш Zammad хост доступан путем FQDN-a? Ова грешка може указивати на то да сте уместо тога конфигурисали Zammad хост као нумеричку IP адресу.

Није могуће дешифровати тикет за HTTP/FQDN@DOMAIN

Да ли сте се побринули да промените лозинку на свом корисничком налогу сервиса у Active Directory-u након омогућавања AES енкрипције од 256 бита??

И да ли сте се побринули да региструјете SPN (са ktpass) и генеришете свој keytab (са ktutil) након промене лозинке??

Покушајте да покренете kinit -k -t <putanja do keytaba> HTTP/<zammad-host>@<DOMAIN>. Ако нема излаза, све је у реду - ако видите "кинит: Неуспешна провера аутентификације при дохватању почетних акредитива" ваши унесени подаци су нетачни или сте користили /pass * током ктпасс команде.

Није успела провера KDC-а" и "није успела провера krb5 акредитива: Није успела провера интегритета дешифровања

Проверите да ли је KrbServiceName тачан ServiceName достављен путем сетспн.

Проверите да ли ваш Active Directory подржава конфигурисану методу енкрипције.

Ако је све горе наведено тачно и сва остала питања у FAQ-u су решена, побрините се да ваш клијент не кешира резултате. klist purge брише кеш клијента - рестартовање клијента би такође помогло.

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.

Одељак са значком прилагођен текст ​

Преглед функција ​

Како то уствари функционише? ​

Први кораци ​

Корак 1: Клонирање GitHub репозиторија ​

1a. Креирајте сервисни налог ​

1b. Ресетуј лозинку ​

1c. Региструјте SPN за Zammad ​

1d. Забележите тајни кључ и верзионски број ​

Step 2: Set up the Kerberos endpoint ​

Инсталација пакета ​

2a. Искључите NGINX ​

2b. Предконфигурација Apache-а ​

2c. Инсталирајте додатне зависности за Apache ​

2d. Омогућите Apache модуле ​

2e. Конфигуришите Kerberos ​

2f. Генеришите keytab ​

2g. Конфигуришите Apache ​

2h. Restart Apache to apply changes ​

Инсталација пакета ​

Files ​

Configure the reverse proxy ​

Trusted proxies ​

Portainer ​

Корак 3: Укључите SSO пријаву за Zammad ​

Корак 4: Конфигуришите клијентски систем (само за Windows) ​

Решавање проблема ​

Грешке у Apache логовима ​

Затражен је неподржан механизам ​

Неуспешна провера krb5 креденцијала: Верзија кључа није доступна ​

Непозната грешка GSS-а. Мањи код може пружити више информација (, Није пронађен унос у табели кључева за HTTP/FQDN@DOMAIN) ​

Запис у keytab-u за HTTP/FQDN@DOMAIN није пронађен ​

Упозорење: примљени токен вероватно је NTLM, који није подржан од стране Kerberos модула. Проверите своју IE конфигурацију ​

Није могуће дешифровати тикет за HTTP/FQDN@DOMAIN ​

Није успела провера KDC-а" и "није успела провера krb5 акредитива: Није успела провера интегритета дешифровања ​

Docker stack ​

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

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

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

Одељак са значком прилагођен текст

Преглед функција

Како то уствари функционише?

Први кораци

Корак 1: Клонирање GitHub репозиторија

1a. Креирајте сервисни налог

1b. Ресетуј лозинку

1c. Региструјте SPN за Zammad

1d. Забележите тајни кључ и верзионски број

Step 2: Set up the Kerberos endpoint

Инсталација пакета

2a. Искључите NGINX

2b. Предконфигурација Apache-а

2c. Инсталирајте додатне зависности за Apache

2d. Омогућите Apache модуле

2e. Конфигуришите Kerberos

2f. Генеришите keytab

2g. Конфигуришите Apache

2h. Restart Apache to apply changes

Инсталација пакета

Files

Configure the reverse proxy

Trusted proxies

Portainer

Корак 3: Укључите SSO пријаву за Zammad

Корак 4: Конфигуришите клијентски систем (само за Windows)

Решавање проблема

Грешке у Apache логовима

Затражен је неподржан механизам

Неуспешна провера krb5 креденцијала: Верзија кључа није доступна

Непозната грешка GSS-а. Мањи код може пружити више информација (, Није пронађен унос у табели кључева за HTTP/FQDN@DOMAIN)

Запис у keytab-u за HTTP/FQDN@DOMAIN није пронађен

Упозорење: примљени токен вероватно је NTLM, који није подржан од стране Kerberos модула. Проверите своју IE конфигурацију

Није могуће дешифровати тикет за HTTP/FQDN@DOMAIN

Није успела провера KDC-а" и "није успела провера krb5 акредитива: Није успела провера интегритета дешифровања

Docker stack

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

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

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