Skip to content

Wprowadzenie

Kerberos SSO (Single Sign-On) umożliwia bezproblemowe logowanie agentów przez Active Directory, bez przesyłania haseł w postaci czystego tekstu. W instalacji OTOBO opartej na Dockerze, NGINX jest używany jako proxy webowe z modułem SPNEGO, który jest kompilowany w osobnym kontenerze „builder”. Następnie dynamicznie generowany moduł (ngx_http_auth_spnego_module.so) jest przenoszony do właściwego kontenera NGINX, a domyślna konfiguracja jest zastępowana konfiguracją obsługującą Kerberos :contentReference[oaicite:0]{index=0}. W ten sposób postępujemy zgodnie z najlepszymi praktykami z oficjalnego projektu OTOBO Docker, który realizuje wyraźne rozdzielenie między etapami budowania a etapami wykonania.

W tym artykule znajdziesz:

  • Kompleksowy przegląd różnic między OTOBO a Znuny w kontekście Kerberos SSO.
  • Instrukcję krok po kroku od przygotowania AD, przez tworzenie Keytab, aż po konfigurację Docker.
  • Wskazówki dotyczące debugowania, konfiguracji przeglądarki i najlepszych praktyk dla różnych wersji OTOBO.

Różnice między OTOBO a Znuny

Chociaż OTOBO i Znuny są funkcjonalnie bardzo podobne (oba pochodzą z oryginalnego projektu OTRS), w kontekście Kerberos istnieją następujące drobne dostosowania:

  • Ścieżki konfiguracji: OTOBO domyślnie używa /opt/otobo-docker/nginx-conf/krb5.conf, podczas gdy Znuny zazwyczaj korzysta z /opt/znuny/nginx-conf/krb5.conf.
  • Pliki szablonów: Szablony NGINX nieznacznie różnią się nazwami i składnią symboli zastępczych; OTOBO dostarcza plik otobo_nginx-kerberos.conf.template, a Znuny podobnie nazwany plik znuny_nginx-kerberos.conf.template.
  • Wersjonowanie: OTOBO 11.x wprowadza rozszerzone parametry SSO („KerberosAdminServer”, „KerberosDefaultDomain”), których brakuje jeszcze w Znuny 6.x.

Wymagania wstępne

  1. Active Directory z Kerberos (Realm i KDC już skonfigurowane).
  2. Konfiguracja OTOBO Docker zgodnie z Oficjalną instalacją z Dockerem :contentReference[oaicite:2]{index=2}.
  3. Wpisy DNS:
    • Rekord A dla Twojego FQDN OTOBO (nie CNAME!), np. otobo.example.com → 192.0.2.10.
    • Odwrotne wyszukiwanie nazwy hosta, aby umożliwić rozwiązywanie SPN Kerberos.

1. Użytkownicy Active Directory i SPN

1.1 Tworzenie użytkownika

Utwórz dedykowane konto usługi w swoim AD, np. HTTP/otobo.example.com (UserPrincipalName). Zwróć uwagę:

  • Wielkość liter w HTTP/; Kerberos oczekuje dokładnie tego prefiksu :contentReference[oaicite:3]{index=3}.
  • Brak znaków specjalnych w haśle (np. &).

1.2 Generowanie SPN i Keytab

Zaloguj się na kontrolerze domeny z uprawnieniami administratora i użyj ktpass.exe:

bash
ktpass.exe \
 -princ HTTP/otobo.example.com@EXAMPLE.COM \
 -mapUser EXAMPLE\\otobo-svc \
 -crypto All \
 -pass SvcUserPassword \
 -ptype KRB5_NT_PRINCIPAL \
 -out C:\krb5.keytab
  • -princ: SPN z Realm w wielkich literach.
  • -mapUser: Nazwa konta SAM (pre-W2K), np. otobo-svc (doc.otobo.de).
  • -out: Ścieżka do Keytab na kontrolerze domeny.

Następnie przenieś Keytab na hosta Docker:

bash
docker_admin> mkdir -p /opt/otobo-docker/nginx-conf
docker_admin> mv /path/to/krb5.keytab /opt/otobo-docker/nginx-conf/krb5.keytab

2. NGINX z modułem SPNEGO

2.1 Etap budowania w Dockerfile

Oficjalny Dockerfile wykorzystuje osobny builder z niezbędnymi pakietami deweloperskimi:

dockerfile
FROM nginx:mainline AS builder-for-kerberos
...
RUN apt-get update && apt-get install -y gcc libc-dev make libpcre3-dev zlib1g-dev libkrb5-dev wget
WORKDIR /usr/src
RUN wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz \
 && wget https://github.com/stnoonan/spnego-http-auth-nginx-module/archive/${SPNEGO_AUTH_COMMIT_ID}.tar.gz
RUN tar -xzf nginx.tar.gz \
 && tar -xzf spnego-http-auth.tar.gz \
 && cd nginx-${NGINX_VERSION} \
 && ./configure --with-compat ${NGINX_CONFIG} --add-dynamic-module=../spnego-http-auth-nginx-module-${SPNEGO_AUTH_COMMIT_ID_FILE} \
 && make modules \
 && cp objs/ngx_http_auth_spnego_module.so /usr/lib/nginx/modules/

Dzięki temu moduł SPNEGO jest kompilowany z Twoją wersją NGINX (extras.getpagespeed.com).

2.2 Konfiguracja w kontenerze wykonawczym

dockerfile
FROM nginx:mainline AS otobo-nginx-kerberos-webproxy

COPY --from=builder-for-kerberos /usr/lib/nginx/modules/ngx_http_auth_spnego_module.so /usr/lib/nginx/modules

RUN apt-get update && apt-get install -y krb5-user libpam-krb5 libpam-ccreds krb5-multidev libkrb5-dev

COPY templates/ kerberos/templates
COPY docker-entrypoint.d/21-envsubst-on-krb5-conf.sh /docker-entrypoint.d/
RUN sed -i '4i load_module modules/ngx_http_auth_spnego_module.so;' /etc/nginx/nginx.conf
  • Ładowanie modułu: Dodaj load_module w linii 4.
  • Skrypty Envsubst generują /etc/krb5.conf z danych szablonu.

3. Wolumeny Docker i szablony Nginx

3.1 Tworzenie niestandardowego wolumenu

bash
docker volume create otobo_nginx_custom_config
mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_nginx_custom_config)
docker create --name tmp-nginx rotheross/otobo-nginx-webproxy:latest-11_0
docker cp tmp-nginx:/etc/nginx/templates/otobo_nginx-kerberos.conf.template.hidden $mp/otobo_nginx.conf.template
docker rm tmp-nginx

3.2 Nadpisanie docker-compose

Utwórz plik docker-compose/otobo-nginx-custom-config.yml:

yaml
version: '3.7'
services:
  nginx:
    volumes:
      - otobo_nginx_custom_config:/etc/nginx/config/template-custom

Aktywuj w głównym pliku .env:

dotenv
COMPOSE_FILE=docker-compose.yml:docker-compose/otobo-nginx-custom-config.yml
NGINX_ENVSUBST_TEMPLATE_DIR=/etc/nginx/config/template-custom

4. Dostosowania .env

  1. Zabezpiecz swój stary plik /opt/otobo-docker/.env:

    bash
    mv .env .env.bak
    cp .docker_compose_env_https_kerberos .env
  2. Dodaj zmienne Kerberos:

    dotenv
    OTOBO_NGINX_KERBEROS_KEYTAB=/opt/otobo-docker/nginx-conf/krb5.keytab
    OTOBO_NGINX_KERBEROS_CONFIG=/opt/otobo-docker/nginx-conf/krb5.conf
    OTOBO_NGINX_KERBEROS_SERVICE_NAME=HTTP/otobo.example.com
    OTOBO_NGINX_KERBEROS_REALM=EXAMPLE.COM
    OTOBO_NGINX_KERBEROS_KDC=dc1.example.com
    OTOBO_NGINX_KERBEROS_ADMIN_SERVER=dc1.example.com
    OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN=example.com
  3. Skopiuj certyfikaty SSL i hasła bazy danych ze starego pliku .env.bak.

Następnie uruchom:

bash
docker-compose down && docker-compose up -d
``` :contentReference[oaicite:6]{index=6}.

## 5. Konfiguracja OTOBO

### 5.1 Moduł uwierzytelniania w `Kernel/Config.pm`

Zakomentuj uwierzytelnianie LDAP/DB i dodaj w swoim pliku `Kernel/Config.pm`:
```perl
$Self->{AuthModule} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} = '^(.+?)@.+?$';

Dzięki temu REMOTE_USER jest poprawnie interpretowany jako login (doc.otobo.de).

5.2 Aktywacja w interfejsie administracyjnym

  • Konfiguracja systemu:

    • Ustaw Customer::AuthModule na HTTPBasicAuth.
    • Zastosuj AuthModule::HTTPBasicAuth::ReplaceRegExp.
  • Kernel/Config -> Wykonaj Deploy.

6. Konfiguracja przeglądarki

Aby SPNEGO działało, Twoja przeglądarka musi akceptować hosta jako zaufanego:

Chrome / Edge / IE

  • „Opcje internetowe” → ZabezpieczeniaWitryny intranetu lokalnegoWitryny
  • Dodaj domenę https://otobo.example.com i aktywuj „Zintegrowane uwierzytelnianie systemu Windows” (doc.otobo.de).

Firefox

  • Wpisz about:config w pasku adresu.
  • network.negotiate-auth.trusted-uris = https://otobo.example.com
  • network.negotiate-auth.delegation-uris = https://otobo.example.com

7. Debugowanie i rozwiązywanie problemów

  1. Sprawdź logi NGINX

    bash
    docker logs otobo_nginx_1 -f
  2. Wejdź do kontenera

    bash
    docker exec -it otobo_nginx_1 bash
    cat /etc/krb5.conf
    klist -e
  3. Pobierz token SPN

    bash
    env KRB5_TRACE=/dev/stdout kvno HTTP/otobo.example.com@EXAMPLE.COM
  4. Przetestuj Keytab

    bash
    kinit -VV -k -t /etc/krb5.keytab HTTP/otobo.example.com@EXAMPLE.COM

    Błąd KDC cannot fulfill request → DNS/SPN nieprawidłowe (plugins.miniorange.com).

8. Najlepsze praktyki i bezpieczeństwo

  • Własny Keytab: Nigdy nie używaj ponownie konta usługi synchronizacji LDAP, unikaj kolizji haseł.
  • Zasada najmniejszych uprawnień: Nadaj tylko minimalne niezbędne uprawnienia AD dla konta SSO.
  • Rotacja Keytab: Regularnie odnawiaj Keytab co 90 dni.
  • TLS dla KDC: Jeśli to możliwe, aktywuj ldaps:// lub GSSAPI przez TLS.
  • Monitorowanie: Monitoruj automatycznie bilety Kerberos za pomocą narzędzi takich jak klist i kvno.

Dzięki tej kompleksowej instrukcji Twoja instancja OTOBO Docker będzie optymalnie przygotowana do Kerberos SSO – bezpieczna, łatwa w utrzymaniu i skalowalna autoryzacja w zestawie!


Źródła: