OTOBO

Italiano

English
Deutsch
Español
Français
Polski
Português
Nederlands

Italiano

English
Deutsch
Español
Français
Polski
Português
Nederlands

Introduzione ​

Kerberos SSO (Single Sign-On) consente un accesso senza soluzione di continuità degli agenti tramite Active Directory, senza che le password vengano trasmesse in chiaro. In un'installazione OTOBO basata su Docker, viene utilizzato NGINX come web proxy con il modulo SPNEGO, che viene compilato in un contenitore "builder" separato. Successivamente, il modulo generato dinamicamente (ngx_http_auth_spnego_module.so) viene trasferito nel contenitore NGINX effettivo e la configurazione standard viene sostituita con una configurazione abilitata per Kerberos :contentReference[oaicite:0]{index=0}.
In questo modo, seguiamo la procedura consolidata nel progetto Docker ufficiale OTOBO, che realizza una chiara separazione tra le fasi di build e runtime .

In questo articolo riceverai:

  • Una panoramica completa delle differenze tra OTOBO e Znuny nel contesto di Kerberos SSO.
  • Una guida passo dopo passo dalla preparazione di AD alla creazione di Keytab e alla configurazione di Docker.
  • Suggerimenti per il debug, la configurazione del browser e le best practice per diverse versioni di OTOBO.

Differenze tra OTOBO e Znuny ​

Sebbene OTOBO e Znuny siano funzionalmente molto simili (entrambi derivano dal progetto OTRS originale), esistono le seguenti sottigliezze nel contesto di Kerberos:

  • Percorsi di configurazione: OTOBO utilizza per impostazione predefinita /opt/otobo-docker/nginx-conf/krb5.conf, mentre Znuny utilizza generalmente /opt/znuny/nginx-conf/krb5.conf.
  • File di template: I template NGINX differiscono leggermente nel nome e nella sintassi dei placeholder; OTOBO fornisce un file otobo_nginx-kerberos.conf.template, mentre Znuny fornisce un file similmente denominato znuny_nginx-kerberos.conf.template.
  • Versione: OTOBO 11.x introduce parametri SSO estesi ("KerberosAdminServer", "KerberosDefaultDomain") che mancano in Znuny 6.x.

Prerequisiti ​

  1. Active Directory con Kerberos (Realm e KDC già configurati).
  2. Un setup OTOBO-Docker in base alle Istruzioni di installazione ufficiali con Docker :contentReference[oaicite:2]{index=2}.
  3. Registri DNS:
    • Un record A per il FQDN di OTOBO (nessun CNAME!), ad esempio otobo.example.com → 192.0.2.10.
    • Un reverse lookup per il nome host, in modo che le risoluzioni SPN di Kerberos funzionino.

1. Utente e SPN di Active Directory ​

1.1 Creazione utente ​

Creare un account di servizio dedicato nel tuo AD, ad esempio HTTP/otobo.example.com (UserPrincipalName). Presta attenzione:

  • Maiuscole in HTTP/; Kerberos si aspetta esattamente questo prefisso :contentReference[oaicite:3]{index=3}.
  • Nessun carattere speciale nella password (ad esempio &).

1.2 Generazione SPN e Keytab ​

Accedi a un DC con autorizzazioni di amministratore e utilizza 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 con Realm in maiuscole.
  • -mapUser: Nome account SAM (pre-W2K), ad esempio otobo-svc ([doc.otobo.de][1]).
  • -out: Percorso della Keytab sul DC.

Spostare successivamente la Keytab nel host 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 con modulo SPNEGO ​

2.1 Fase di build in Dockerfile ​

Il Dockerfile ufficiale utilizza un builder separato con i pacchetti di sviluppo necessari:

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/

In questo modo, il modulo SPNEGO viene compilato in modo compatibile con il tuo rilascio NGINX ([extras.getpagespeed.com][2]).

2.2 Configurazione nel contenitore di runtime ​

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
  • Caricamento modulo: load_module nella riga 4.
  • Script envsubst: generare /etc/krb5.conf da dati di template.

3. Volumi Docker e template NGINX ​

3.1 Creazione volume personalizzato ​

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 Sostituzione di docker-compose ​

Creare docker-compose/otobo-nginx-custom-config.yml:

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

Attivare nel file .env principale:

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

4. Modifiche a .env ​

  1. Salvare la vecchia /opt/otobo-docker/.env:

    bash
    mv .env .env.bak
cp .docker_compose_env_https_kerberos .env

  2. Aggiungere le variabili 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. Certificati SSL e password del database dalla vecchia .env.bak.

Avviare quindi con:

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

## 5. Configurazione OTOBO

### 5.1 Modulo di autenticazione in `Kernel/Config.pm`

Commentare l'autenticazione LDAP/DB e aggiungere nella tua `Kernel/Config.pm`:
```perl
$Self->{AuthModule} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} = '^(.+?)@.+?$';
```
In questo modo, `REMOTE_USER` viene interpretato correttamente come login ([doc.otobo.de][1]).

### 5.2 Attivazione nell'interfaccia di amministrazione

* **Configurazione di sistema**:

    * `Customer::AuthModule` impostato su `HTTPBasicAuth`.
    * `AuthModule::HTTPBasicAuth::ReplaceRegExp` ereditato.
* **Kernel/Config** -> **Deploy** eseguire.

## 6. Configurazione del browser

Affinché SPNEGO funzioni, il tuo browser deve accettare l'host come **trusted**:

### Chrome / Edge / IE

* „Opzioni Internet“ → **Sicurezza** → **Siti di Intranet locali** → **Siti**
* Aggiungere il dominio `https://otobo.example.com` e attivare „Autenticazione Windows integrata“ ([doc.otobo.de][1]).

### Firefox

* `about:config` nella barra degli indirizzi.
* `network.negotiate-auth.trusted-uris = https://otobo.example.com`
* `network.negotiate-auth.delegation-uris = https://otobo.example.com`

## 7. Debug e risoluzione dei problemi

1. **Controllare i log di NGINX**

   ```bash
   docker logs otobo_nginx_1 -f
   ```
2. **Accedere al contenitore**

   ```bash
   docker exec -it otobo_nginx_1 bash
   cat /etc/krb5.conf
   klist -e
   ```
3. **Ottenere il token SPN**

   ```bash
   env KRB5_TRACE=/dev/stdout kvno HTTP/otobo.example.com@EXAMPLE.COM
   ```
4. **Testare la Keytab**

   ```bash
   kinit -VV -k -t /etc/krb5.keytab HTTP/otobo.example.com@EXAMPLE.COM
   ```
   Errore `KDC cannot fulfill request` → DNS/SPN errato ([plugins.miniorange.com][3]).

## 8. Best practice e sicurezza

* **Keytab personalizzato**: non riutilizzare mai l'account di servizio di sincronizzazione LDAP, evitare collisioni di password .
* **Privilegi minimi**: assegnare solo i diritti AD necessari per l'account SSO.
* **Rotazione della Keytab**: rinnovare regolarmente la Keytab ogni 90 giorni.
* **TLS per KDC**: se possibile, attivare `ldaps://` o GSSAPI su TLS.
* **Monitoraggio**: monitorare con strumenti come `klist` e `kvno` le autorizzazioni Kerberos in modo automatizzato.

---

Con questa guida completa, la tua istanza Docker OTOBO è pronta per Kerberos SSO – autenticazione sicura, manutenibile e scalabile inclusa!

---

**Fonti:**

* rotheross/otobo-nginx-kerberos-webproxy su Docker Hub ([hub.docker.com][4])
* SPNEGO HTTP Auth NGINX Module (stnoonan) ([extras.getpagespeed.com][2])
* Documentazione di installazione ufficiale OTOBO (11.0 SSO Kerberos) ([doc.otobo.de][1])
* GitHub Issue #81: NGINX Kerberos broken ([github.com][5])
* Guida alla configurazione di Kerberos SSO di miniOrange ([plugins.miniorange.com][3])
* OTOBO Docker Override HTTPS-Kerberos ([github.com][6])
* Manuali per sviluppatori e amministratori OTOBO
* Microsoft Docs: ktpass.exe ([community.znuny.org][7])
* Mozilla MDN: SPNEGO in Firefox ([doc.otobo.de][1])
* NGINX Docs: moduli dinamici ([extras.getpagespeed.com][2])