description:PVE на gefest — добавить настоящий Kerberos SSO (SPNEGO) для веб-логина; пользователь настраивает сам, потом проверить
metadata:
type:project
---
**Задача:** включить настоящий Kerberos SSO (SPNEGO/GSSAPI) автовход в веб-морду PVE на **gefest** (192.168.0.13, кластер MIAC). Пользователь (Vitaly) настраивает сам; моя роль — **проверить после**.
**Контекст (состояние на 2026-07-24):**
- AD = **ETERSOFT.RU**, DC = dc.etersoft.ru (10.20.30.20), Kerberos :88, LDAP :389 (SRV-записи есть).
- gefest **уже в AD через winbind** (`realm list`: `client-software: winbind`, `login-formats: ETERSOFT\%U`), есть `/etc/krb5.keytab`. sssd тоже active/enabled (гибрид/legacy).
- В PVE сейчас realm только `pam` + `pve`. Доменные юзеры сидят как `user@pam` (aalyaev@pam, lav@pam …) — `pam` уже проверяет пароли по AD (PAM→winbind→Kerberos). Т.е. AD-аутентификация УЖЕ работает, просто не как SSO.
-**Важно:** PVE из коробки НЕ поддерживает SPNEGO в web UI → настоящий SSO требует reverse-proxy (nginx/apache + GSSAPI) спереди PVE, либо иной обвязки. Уточнить у пользователя архитектуру когда скажет «готово».
**Как проверять (когда пользователь попросит):**
1. У клиента валидный TGT: `klist` (на lav/builder64 — `kinit lav@ETERSOFT.RU`).
2.`curl --negotiate -u : http(s)://<pve-proxy-url>/` — должен вернуть ответ без падения в 401/логин-форму.
3. Браузер: `network.negotiate-auth.trusted-uris` (Firefox) / group policy (Chromium) на хост PVE-прокси.
4. Падение в форму ввода пароля = SSO НЕ работает (откат на обычную аутентификацию).
5. Уточнить у пользователя: какой URL/порт прокси, на каком хосте он крутится (gefest? отдельный контейнер?), доступ снаружи или только office-LAN.