Помилки входу Proxmox LDAP/AD: де ламається ланцюг автентифікації і як виправити

October 9, 2025 • February 3, 2026 • Читання: 6 хв • Views: 13

Було корисно?

Коли в Proxmox не проходить вхід через LDAP/AD, у вас не «проблема LDAP». У вас розірваний ланцюг: розвʼязування імен, мережа, TLS, bind, пошук, визначення груп, зіставлення користувача, права й нарешті власний стек автентифікації Proxmox. Один слабкий ланцюг — і інтерфейс терпляче відповідає «authentication failure», ніби робить вам послугу.

Цей посібник проходить ланцюг у тому порядку, у якому він реально ламається в продакшні, з командами, які можна виконати прямо зараз, що означає вивід і яке рішення приймати далі. Ніякої загадковості. Ні «спробуйте перезапустити» як світогляд.

Ланцюг автентифікації: що Proxmox реально робить під час входу

Аутентифікація Proxmox VE (PVE) — це не один підсистема. Це набір realm-ів плюс модель прав доступу плюс трохи клею. Якщо ви не розумієте цей клей, ви виправите неправильний шар і «в мене на ноуті працює» приведе вас до інциденту.

Крок 0: Яким realm ви насправді користуєтесь?

Proxmox підтримує realm-и, такі як:

pam: локальні облікові записи Linux, що автентифікуються через PAM (який сам може бути підкріплений LDAP/SSSD, але це інший ланцюг).
pve: локальні користувачі Proxmox, збережені в /etc/pve/user.cfg.
ldap: зовнішній каталог через LDAP (OpenLDAP, AD через LDAP).
ad: realm типу Active Directory (під капотом це теж LDAP, але з AD-парадигмою за замовчуванням, наприклад обробка груп).

Користувачі входять як user@realm. Якщо ваша команда продовжує вводити user@pam з м’язової памʼяті, ви можете налаштовувати LDAP до кінця універсуму — це не допоможе.

Крок 1: Чи досягає PVE сервіс каталогу?

Перед автентифікацією Proxmox повинен розвʼязати імена DC/LDAP, проложити маршрут до них і відкрити TCP-зʼєднання. Для AD це часто означає вибір правильного DC (або кількох) і щоб його не обдурив DNS.

Крок 2: TLS (LDAPS або StartTLS) проходить або ні

LDAP поверх TLS — це перше місце, де «в тесті працює» гине в продакшні. Сертифікати, SNI, SAN, проміжні ланцюги й час — все має значення. Якщо LDAPS падає, Proxmox часто повідомляє про помилку автентифікації, бо bind взагалі не відбувся.

Крок 3: Bind працює

Proxmox може виконувати bind як:

анонімний (рідко дозволений в AD; зазвичай вимкнений у загартованих LDAP).
сервісний акаунт (зазвичай приклад; використовується для пошуку користувачів і груп).
прямий bind користувача (DN користувача виводиться з шаблону, потім bind від імені користувача).

Успішний bind доводить коректність облікових даних і (часто) що TLS пройшов нормально.

Крок 4: Пошук знаходить запис користувача

Тут важливі base DN і фільтри. Якщо пошук повертає нуль записів, Proxmox не може зіставити введене імʼя користувача з DN, і ви отримаєте «login failed», навіть якщо пароль правильний.

Крок 5: Відображення груп/ролей вирішує, що ви можете робити

Навіть якщо автентифікація пройшла, авторизація може провалюватися так, ніби це помилка автентифікації (наприклад, ви «увійшли», але не бачите нічого; або API повертає 401/403). Права в Proxmox — це RBAC-подібна модель, окрема від автентифікації. Членство в групах AD має бути зіставлене з групами/ролями Proxmox, інакше ви створили прекрасну особистість без жодних прав — як видати бейдж, що ні до яких дверей не підходить.

Крок 6: Узгодженість конфігурації кластера Proxmox

Proxmox зберігає конфігурацію автентифікації в кластерній файловій системі (/etc/pve). Якщо кластер розділений або вузол у дивному стані, один вузол може мати конфіг realm-а, якого немає в інших. Тоді «деякі входи» падають — улюблена категорія інцидентів.

Парафраз ідеї Вернера Фогельса (CTO Amazon): «Якщо ви це створили, ви це і експлуатуєте.» Якщо ви експлуатуєте — треба налагоджувати без здогадок.

Швидкий план діагностики (перевірити перше/друге/третє)

Це порядок, що зменшує час до істини. Він навмисно нудний. Нудний — це швидко.

Перше: визначте realm і відтворіть з CLI

Підтвердіть формат імені користувача (alice@ad vs alice@ldap vs alice@pam).
Використайте CLI Proxmox, щоб перевірити, чи існує конфіг realm-а на вузлі, що обробляє вхід.
Протестуйте LDAP bind/пошук з вузла за допомогою ldapsearch (або openssl s_client для TLS).

Друге: доведіть мережу + DNS + час

DNS резолвить DC правильно з вузла Proxmox.
TCP підключається до 389/636 і немає фаєрвол/НАТ дивностей.
Часова різниця в межах норми (TLS і Kerberos не пробачають подорожей у часі).

Третє: перевірте bind DN, base DN, фільтр користувача та атрибути груп

Облікові дані bind коректні та не заблоковані/не прострочені.
Base DN правильний і містить очікувані обʼєкти користувачів.
Фільтр користувача відповідає схемі каталогу (відмінності AD vs OpenLDAP).
Атрибути членства груп відповідають тому, що Proxmox очікує для вашого типу realm-а.

Четверте: підтвердьте мапінг авторизації в Proxmox

Користувач присутній у відображенні користувачів/груп Proxmox (або автопропвізіонований, якщо налаштовано).
Ролі й ACL дають принаймні PVEAuditor або подібну там, де потрібно.

П’яте: ескалація до логів і захоплення пакетів

Читай pveproxy і pvedaemon логи для точного рядка помилки.
Використай tcpdump, щоб підтвердити TLS handshake і чи відбуваються bind-операції взагалі.

Девіз в одне речення: не чіпайте Proxmox, поки не зможете відтворити помилку за допомогою ldapsearch з проблемного вузла.

Цікаві факти та контекст (чому це складніше, ніж має бути)

Факт 1: LDAP зʼявився на початку 1990‑х як легка альтернатива X.500. «Легкий» з того часу став рисою характеру, а не гарантією.
Факт 2: Active Directory говорить LDAP, але це не «просто LDAP». AD змішує LDAP з Kerberos, DNS SRV записами та політиками, що дивують тих, хто виріс на OpenLDAP.
Факт 3: LDAPS (LDAP через 636) історично конкурував зі StartTLS (LDAP + оновлення). Багато підприємств досі використовують обидва, залежно від того, в якому десятилітті писався клієнт.
Факт 4: Членство груп в AD часто читають з атрибуту memberOf, але вкладені групи вимагають додаткової логіки (або matching rules), яку не кожен клієнт реалізує однаково.
Факт 5: Microsoft посилила поведінку LDAP в AD з часом (підписування, channel binding, деградація слабких шифрів). Оновлення Proxmox може «зламати LDAP», коли насправді контролер домену ввів сучасні вимоги без сумісності назад.
Факт 6: Сертифікати частіше ламаються через невідповідність імен, ніж через криптографію. Люди чудово перейменовують речі неправильно, особливо під тиском.
Факт 7: Кластерна файлова система Proxmox (pmxcfs) робить конфіг аутентифікації послідовною — поки кластер здоровий; коли ні, послідовність стає ввічливою пропозицією.
Факт 8: Багато LDAP-помилок «invalid credentials» насправді означають «bind DN не знайдено» або «акаунт заблоковано», бо сервери навмисно повертають розпливчасті помилки, щоб не розкривати зайвої інформації.

Практичні завдання: команди, виводи, рішення (12+)

Виконуйте це на вузлі Proxmox, де відбувається збій входу. Якщо у вас кластер за балансувальником навантаження, ця деталь важить більше, ніж комусь хочеться визнати.

Завдання 1: Перелічити налаштовані realm-и і переконатися, що потрібний є

cr0x@server:~$ pveum realm list
Realm    Type  Comment
pam      pam
pve      pve
ad       ad    Corporate AD

Що це означає: Realm ad існує на цьому вузлі. Якщо його немає, ви налагоджуєте не той вузол або конфігурація кластера несинхронна.

Рішення: Якщо realm відсутній на одному вузлі, виправте здоровʼя кластера або відтворіть realm з робочого вузла. Не «додавайте локально»; Proxmox хоче бачити це в /etc/pve.

Завдання 2: Вивести конфіг realm-а (перевірити bind DN, base DN, server)

cr0x@server:~$ pveum realm config ad
base_dn          dc=corp,dc=example,dc=com
bind_dn          svc_pve@corp.example.com
capath           /etc/ssl/certs
default          0
domain           corp.example.com
group_classes    group
password         **********
port             636
secure           1
server1          dc01.corp.example.com
user_attr        sAMAccountName

Що це означає: Це те, що Proxmox використовуватиме. Зверніть увагу на server1, port, secure, base_dn і атрибут користувача.

Рішення: Якщо server1 — коротке імʼя без відповідного SAN у сертифікаті, очікуйте TLS-помилок. Використайте FQDN, який збігається з сертифікатом.

Завдання 3: Перевірити DNS-резолюцію (і впіймати «допоміжні» search domain)

cr0x@server:~$ getent hosts dc01.corp.example.com
10.10.10.11   dc01.corp.example.com

Що це означає: Вузол резолвить DC. Якщо IP відрізняється від очікуваного, ви можете потрапляти на неправильний DC або на застарілий запис.

Рішення: Якщо резолюція неправильна, виправте /etc/resolv.conf (або systemd-resolved), а не Proxmox. Автентифікація залежить від правильного DNS.

Завдання 4: Підтвердити TCP-зʼєднання до LDAP/LDAPS

cr0x@server:~$ nc -vz dc01.corp.example.com 636
Connection to dc01.corp.example.com 636 port [tcp/ldaps] succeeded!

Що це означає: Мережевий шлях відкритий. Якщо не вдається, припиніть і спочатку виправте маршрути/фаєрвол.

Рішення: Якщо 636 заблокований, але 389 працює, вирішіть, чи дозволено вам використовувати StartTLS на 389, або потрібно відкривати 636.

Завдання 5: Інспект TLS handshake і імена сертифіката

cr0x@server:~$ openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = dc01.corp.example.com
issuer=CN = Corp Issuing CA 01, O = Corp
notBefore=Oct  1 00:00:00 2025 GMT
notAfter=Oct  1 00:00:00 2027 GMT
X509v3 Subject Alternative Name:
    DNS:dc01.corp.example.com, DNS:dc01

Що це означає: Сертифікат збігається з іменем, яке ви використали. Якщо SAN не містить FQDN, Proxmox може відмовити в TLS (залежно від налаштувань).

Рішення: Якщо імена не збігаються, використайте імʼя, що відповідає сертифікату, або виправте сертифікат. Не вимикайте перевірку, якщо ви не любите запобіжні інциденти.

Завдання 6: Перевірити CA-ланцюг, якому довіряє Proxmox

cr0x@server:~$ openssl verify -CApath /etc/ssl/certs <(openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com /dev/null | openssl x509)
stdin: OK

Що це означає: Вузол довіряє issuing CA-ланцю.

Рішення: Якщо це не так, встановіть корпоративний CA у системне сховище довіри і оновіть сертифікати. Виправте довіру один раз, а не робіть хаки під кожну програму.

Завдання 7: Доведіть bind з допомогою ldapsearch (сервісний акаунт)

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' -s base '(objectClass=*)' defaultNamingContext
Enter LDAP Password:
dn:
defaultNamingContext: DC=corp,DC=example,DC=com

Що це означає: TLS працює, bind працює, base DN доступний.

Рішення: Якщо бачите Invalid credentials (49), перевірте формат ідентичності bind. AD часто приймає UPN (user@domain) або повний DN; оберіть один і дотримуйтеся.

Завдання 8: Знайти запис користувача так, як це робитиме Proxmox

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' '(sAMAccountName=alice)' dn sAMAccountName userPrincipalName memberOf
Enter LDAP Password:
dn: CN=Alice Nguyen,OU=Users,DC=corp,DC=example,DC=com
sAMAccountName: alice
userPrincipalName: alice@corp.example.com
memberOf: CN=PVE-Admins,OU=Groups,DC=corp,DC=example,DC=com
memberOf: CN=VM-Operators,OU=Groups,DC=corp,DC=example,DC=com

Що це означає: Користувач існує і може бути знайдений за обраним атрибутом.

Рішення: Якщо пошук нічого не повертає, виправте base_dn і фільтр/атрибут користувача. Паролі поки не чіпайте; вони невинні, поки не доведено протилежне.

Завдання 9: Перевірити вкладені групи, якщо RBAC на них залежить

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' '(&(objectClass=user)(sAMAccountName=alice)(memberOf:1.2.840.113556.1.4.1941:=CN=PVE-Admins,OU=Groups,DC=corp,DC=example,DC=com))' dn
Enter LDAP Password:
dn: CN=Alice Nguyen,OU=Users,DC=corp,DC=example,DC=com

Що це означає: AD «matching rule in chain» підтверджує вкладене членство. Якщо вам потрібні вкладені групи, а налаштування їх не враховує, авторизація буде непослідовною.

Рішення: Вирішіть, чи підтримуєте вкладені групи (тоді тестуйте це ретельно), або забороніть вкладення для груп PVE, щоб зберегти передбачуваність.

Завдання 10: Подивитися логи Proxmox під час спроби входу

cr0x@server:~$ journalctl -u pveproxy -u pvedaemon --since "10 minutes ago" | tail -n 30
Dec 26 09:40:12 pve01 pveproxy[2211]: authentication failure; rhost=10.10.20.55 user=alice@ad msg=ldap_bind: Invalid credentials (49)
Dec 26 09:40:12 pve01 pvedaemon[2198]: user authentication failed: alice@ad

Що це означає: Proxmox дійшов до bind (або спробував) і отримав LDAP-помилку. Рядок помилки — ваш компас.

Рішення: Якщо бачите TLS-помилки (handshake/verify), перестаньте дивитися на конфіг користувача і виправляйте довіру/сертифікати/час.

Завдання 11: Примусити синхронізацію realm-а і спостерігати

cr0x@server:~$ pveum realm sync ad
syncing users
syncing groups
OK

Що це означає: Proxmox може запитувати обʼєкти каталогу використовуючи конфіг realm-а. Якщо не вдається, зазвичай виводиться осмислена LDAP-помилка.

Рішення: Якщо sync працює, а вхід ні — підозрівайте невідповідність атрибутів користувача, проблеми з паролем або вибір realm під час входу.

Завдання 12: Переконатися, що користувач існує у вигляді Proxmox і подивитися права

cr0x@server:~$ pveum user list | grep -E 'alice@ad|userid'
alice@ad

Що це означає: Proxmox знає про користувача. Це не гарантує права, лише відображення ідентичності.

Рішення: Якщо користувача немає в списку і ви покладаєтесь на sync — виправляйте фільтри синхронізації. Якщо не покладаєтесь — вирішіть, чи керувати користувачами локально або через sync; оберіть підхід і задокументуйте його.

Завдання 13: Перевірити ACL (бо «вхід працює», але UI порожній — це теж провал)

cr0x@server:~$ pveum acl list | grep -i alice
/ - user alice@ad - role PVEAuditor

Що це означає: Користувач має принаймні одну роль на корені. Якщо цього немає, користувач може автентифікуватися, але майже нічого не бачити.

Рішення: Якщо ви хочете доступ за групами AD, призначайте ролі групам, а не індивідуальним користувачам, і тримайте ACL керованим.

Завдання 14: Перевірити мапінг груп з AD у Proxmox

cr0x@server:~$ pveum group list
Administrators
VMOperators

Що це означає: Це групи Proxmox (не обовʼязково групи AD). Ви повинні зіставити групи AD з групами Proxmox або використовувати ACL безпосередньо проти користувачів.

Рішення: Якщо організація очікує «група AD дає права Proxmox», реалізуйте це явним мапінгом. Очікування — не конфігурація.

Завдання 15: Перевірити здоровʼя кластерної файлової системи (налаштування автентифікації від неї залежить)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             2025-12-26 09:42:33
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.12
Quorate:          Yes

Що це означає: Кластер має кворум і конфіг має бути послідовною. Якщо кворум втрачено — очікуйте дивностей, включно зі застарілою конфігурацією автентифікації.

Рішення: Якщо кворум втрачено, не робіть операцій з автентифікацією; спочатку виправляйте кластер.

Завдання 16: Доказ на рівні пакетів, коли все «виглядає добре»

cr0x@server:~$ tcpdump -i vmbr0 -nn host 10.10.10.11 and port 636 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:43:10.120345 IP 10.10.10.21.49122 > 10.10.10.11.636: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7], length 0
09:43:10.120611 IP 10.10.10.11.636 > 10.10.10.21.49122: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 200 ecr 100,nop,wscale 7], length 0
09:43:10.120744 IP 10.10.10.21.49122 > 10.10.10.11.636: Flags [.], ack 1, win 502, options [nop,nop,TS val 101 ecr 200], length 0

Що це означає: SYN/SYN-ACK/ACK доводять наявність зʼєднання. Якщо ви не бачите трафіку під час спроб входу, ваш вузол Proxmox навіть не робить запит до каталогу — неправильний realm, неправильний вузол або конфіг не застосовано.

Рішення: Якщо пакети є, а автентифікація все одно падає — концентруйтеся на TLS/bind/search, а не на маршрутизації.

Де ламається: режими відмов по шарах

Шар 1: UI і вибір realm-а (проблема «не та двері»)

Екран входу Proxmox має випадаючий список realm-ів. Користувачі вибирають неправильний realm. Вони завжди вибирають неправильний realm. Якщо у вас увімкнені pam і ad, «pam» виграє у популярності, бо звучить знайомо.

Виправлення: Встановіть чіткий default realm, повідомте про це і розгляньте обмеження локальних входів до «break-glass» режиму.

Жарт #1: LDAP — єдиний протокол, де «Invalid credentials» може означати «пароль не той», «акаунт заблоковано» або «місяць у ретрограді».

Шар 2: DNS та вибір DC (тихо катастрофічно)

AD залежить від DNS. Якщо вузли Proxmox не використовують DNS інтегрований з AD (або хоча б не резолвлять його правильно), ви можете отримати:

Резолюції на виведений з обігу DC.
Плутанину split-horizon, коли внутрішні імена резолвляться зовні.
Автодоповнення search domain, що перетворює dc01 в dc01.lab.example.com.

Виправлення: Використовуйте FQDN у конфіг realm-а. Переконайтеся, що вузли Proxmox використовують правильні резолвери. Не спирайтесь на search domains, щоб «допомогти». Вони допомагають як кіт допомагає з пазлами.

Шар 3: Час (TLS і Kerberos обидва чутливі)

Навіть якщо ви використовуєте LDAP binds (не Kerberos), перевірка TLS залежить від часу. Зсув годин дає помилки «сертифікат ще не дійсний» або «прострочено», що виглядає як TLS-збій.

Виправлення: Робіть NTP нудним і резервним. Якщо вузли не можуть тримати час — ваш стек автентифікації стає декоративною фічею.

Шар 4: Довіра TLS і ідентичність сертифіката

Більшість корпоративних AD використовують внутрішню PKI. Якщо Proxmox не довіряє вашому CA — LDAPS падає. Якщо ви підключаєтесь до dc01, а сертифікат каже dc01.corp.example.com — LDAPS падає. Якщо у сертифіката бракує проміжного — LDAPS падає. Якщо політика TLS на DC змінилася — старі клієнти падають.

Виправлення: Покладіть ваш CA у системне сховище довіри. Використовуйте імена, що збігаються з SAN. Зберігайте цілий ланцюг. Віддавайте перевагу сучасній TLS-політиці, але тестуйте її на реальних клієнтах, а не на надії.

Шар 5: Формати ідентичності bind (UPN vs DN vs DOMAIN\user)

AD приймає кілька форматів, але не завжди в однакових контекстах. Конфіг realm-а Proxmox може використовувати UPN-стиль bind (svc_pve@corp.example.com) або повний DN (CN=svc_pve,OU=Service Accounts,...). Якщо сервісний акаунт перемістили між OU і ви захардкодили DN — отримаєте помилки bind. Якщо пароль акаунта змінився і ніхто не оновив Proxmox — також bind не пройде.

Виправлення: Використовуйте UPN для сервісних акаунтів, коли можливо (менш залежний від OU). Документуйте власника цих облікових даних. Ротейть з планом, а не за відчуттями.

Шар 6: Base DN і фільтри (спір «користувач існує, я клянуся»)

Люди ставлять base_dn занадто вузько (в один OU) і потім додають користувачів в інші. Або копіюють фільтр з прикладу для OpenLDAP в AD і дивуються, чому uid нічого не знаходить.

Виправлення: Встановіть base DN в корінь домену, якщо у вас немає суворої причини інакше. Якщо треба обмежити — включіть всі релевантні OU і підтримуйте це в актуальному стані.

Шар 7: Розвʼязування членства груп (вкладені групи, вибір атрибутів)

Ви можете автентифікуватися без правильного оброблення груп, але не зможете правильно авторизуватися. Вкладені групи AD — класична пастка: у користувача в memberOf можуть бути лише прямі членства. Ваша політика говорить «PVE-Admins», але користувачі є членами через вкладення. Половина команди отримує доступ, інша — ні, і всі звинувачують Proxmox.

Виправлення: Вирішіть, чи дозволяєте вкладені групи. Якщо так — тестуйте розвʼязування вкладених груп. Якщо ні — забезпечте це в управлінні каталогом.

Шар 8: Права Proxmox і токени (auth vs authz)

Вхід Proxmox відокремлений від прав. Користувач може автентифікуватися і все одно нічого не бачити. Також: API-токени і сесії користувачів поводяться інакше, ніж інтерактивні входи. Не налагоджуйте помилку з API-токеном, змінюючи LDAP-фільтри.

Виправлення: Дайте користувачам мінімальну роль у потрібному шляху. Використовуйте групи для ACL. Тримайте локальні break-glass облікові записи і суворо їх аудитуйте.

Шар 9: Кластерні дивності (працювало на node1)

У кластері часто тестують на одному вузлі, оголошують перемогу, а потім отримують оповіщення, бо входи падають на інших вузлах. Зазвичай це:

Вузол без кворуму, застаріла конфіг.
Різна DNS або фаєрвол політика на вузлах.
Різні стани сховища довіри CA (хтось колись «виправив це вручну»).

Виправлення: Ставте залежності автентифікації (DNS, CA, час, фаєрвол) під управління конфігурацією кластера, а не як ручну роботу на вузлі.

Три корпоративні міні-історії (як це йде шкереберть на роботі)

Міні-історія 1: Інцидент через хибне припущення

Мігрували з legacy vSphere в Proxmox посеред кварталу з типовим фоном дедлайнів. AD-команда передала сервісний акаунт і сказала: «Він може читати користувачів і групи». Команда Proxmox вирішила, що це означає, що він може читати усіх користувачів і групи в домені. Насправді — ні.

В AD їм делегували права читання лише для конкретного OU, де жили «server admins». Base DN Proxmox був коренем домену, тому пошуки переходили в області, де сервісний акаунт не мав прав. У тесті всі, хто пробували ввійти, випадково були в делегованому OU. У продакшні половина NOC була в іншому OU. Для них вхід падав, а для on-call інженера — ні, і це ввело в оману.

Перші реакції були передбачувані: хтось спробував змінити фільтри, потім хтось вимкнув верифікацію TLS «тимчасово». Це не допомогло, бо проблема не в TLS чи фільтрах. Це була авторизація всередині AD для bind-акаунта.

Вирішили узгодити обсяг з правами: або розширити права читання сервісного акаунта (переважно, з мінімальною областю), або звузити base DN до потрібного OU і задокументувати звʼязок. Зробили обидва: тимчасово звузили scope, створили change request на розширення прав і додали тест входу для користувача з іншого OU до чекліста розгортання.

Міні-історія 2: Оптимізація, що відстрілялася в ногу

Інша організація мала «ефективну» ідею: вказати Proxmox на один DC, бо це «зменшує латентність» і полегшує налагодження. Вони вибрали DC у тій же стійці. Все працювало — поки ніч патчів.

Windows-команда патчнула той DC і він перезавантажився. Близько 12 хвилин LDAP/LDAPS були недоступні. Вузли Proxmox намагалися автентифікуватися; входи падали; API почав повертати помилки; автоматика почала агресивно повторювати запити. Навантаження зросло всюди, включно з DC після повернення, і моніторинг перетворився на «перформанс-арт».

Після бурі вони додали server2/server3 до конфіг realm-а і протестували. Це вирішило доступність, але виявився другий ефект: резервний DC мав трохи інший сертифікаційний ланцюг (ще дійсний, але з іншого проміжного). Деякі вузли Proxmox довіряли одному проміжному, але не іншому, бо хтось встановлював сертифікати неконсистентно з часом.

Фінальне виправлення було непривабливе: стандартизувати довіру CA по всіх вузлах, налаштувати кілька LDAP-серверів і припинити оптимізації «на кілька мілісекунд» в тому шляху автентифікації, що використовується багато рідше, ніж I/O зберігання. Також додали runbook для патчей: оновлювати DC по черзі і перед оголошенням успіху перевіряти LDAPS з Linux-клієнтів.

Міні-історія 3: Нудна, але правильна практика, що врятувала вихідні

Одна організація мала звичку: кожна зміна автентифікації супроводжувалася маленьким, повторюваним скриптом, що запускався з кожного вузла Proxmox. Нічого особливого — тільки DNS резолюція, TCP connect, TLS verify, ldapsearch bind і пошук користувача. Скрипт був під контролем версій і очікувані результати документовані.

Під час рутинного ротації CA AD CS команда випустила новий issuing CA і почала віддавати нові ланцюги на контролерах домену. Багато систем мали проблеми. Proxmox — ні, бо команда Proxmox заздалегідь розгорнула новий CA в системне сховище довіри на кожному вузлі як частину плану зміни, за тиждень до цього, з верифікацією.

Те, що виглядало як удача, насправді було дешевою дисципліною: «сховище довіри — це керована конфігурація», а не «щось, що треба лагодити, коли зламається». Їхня автентифікація не заїкнулась, тому віртуалізаційна платформа залишалась нудною, поки інші команди тушкували пожежі сертифікатів.

Це не принесло нагород. Але врятувало вихідні. В корпоративних операціях це найкраща нагорода.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «Login failed» для всіх; логи згадують TLS/handshake

Корінна причина: Proxmox не довіряє ланцюгу сертифікатів AD/LDAP або хостнейм не збігається з SAN сертифіката.

Виправлення: Встановіть корпоративний CA в системне сховище довіри, перевірте через openssl verify, використовуйте FQDN, що збігається з SAN. Уникайте відключення верифікації, якщо не хочете, щоб атаки MITM стали простішими.

2) Симптом: «Invalid credentials (49)» навіть при правильному паролі

Корінна причина: Неправильний формат bind DN, прострочений/заблокований сервісний акаунт або політика AD блокує прості bind-и без TLS.

Виправлення: Підтвердіть bind DN/UPN, перевірте стан акаунта в AD, переконайтеся, що використовується LDAPS/StartTLS. Валідовуйте через ldapsearch -D ... -W з вузла.

3) Симптом: Тільки деякі користувачі можуть увійти

Корінна причина: Base DN занадто вузький, невідповідність OU-скопу або сервісний акаунт не має прав читання в частинах каталогу.

Виправлення: Розширте base DN або відрегулюйте делегування в AD. Тестуйте з користувачами з різних OU.

4) Симптом: Користувач автентифікується, але бачить порожній інтерфейс або немає вузлів

Корінна причина: Відсутні ACL/ролі Proxmox; автентифікація пройшла, але авторизація — ні.

Виправлення: Призначте роль у потрібному шляху (часто / або /vms), бажано через групи.

5) Симптом: Працює на node1, падає на node2

Корінна причина: Кластер не здоровий, конфіг не реплікується або різниця в DNS/фаєрвол/сховищі довіри на вузлах.

Виправлення: Відновіть кворум/здоровʼя кластера, стандартизуйте управління конфігурацією вузлів, перевірте конфіг realm-а на кожному вузлі.

6) Симптом: Синхронізація realm-а працює, але інтерактивний вхід падає

Корінна причина: Невідповідність атрибутів користувача (наприклад, очікують sAMAccountName, а входять з UPN) або користувач вибрав неправильний realm.

Виправлення: Узгодьте формат входу з user_attr і інструкціями в UI. Розгляньте встановлення дефолтного realm-а, щоб зменшити людські помилки.

7) Симптом: Після посилення безпеки LDAP «ламався» випадково

Корінна причина: Змінені вимоги AD щодо підписування/channel binding або посилена TLS-політика, що виявила застарілі припущення клієнтів.

Виправлення: Перейдіть на LDAPS/StartTLS з валідною довірою, переконайтеся, що Proxmox і базові бібліотеки підтримують вимоги, тестуйте в стейджингу з реальними DC-політиками.

8) Симптом: Групові права не застосовуються як очікувалось

Корінна причина: Вкладені групи не розвʼязуються, неправильний атрибут/клас групи або DN груп не збігаються з тим, що мапить Proxmox.

Виправлення: Визначте стратегію для вкладених груп, перевірте запити членства і тримайте назви/DN груп стабільними (або мапте за однозначними атрибутами там, де це підтримується).

Жарт #2: Найшвидший спосіб знайти вашу точку відмови — «оптимізувати» її. Аутентифікація — чудовий вчитель з жахливим таймінгом.

Контрольні списки / поетапний план (зробіть це нудним)

Чекліст A: Коли ви створюєте новий AD/LDAP realm

Оберіть тип realm-а (ad для AD, ldap для загального LDAP). Не будьте хитрі без потреби.
Використовуйте FQDN для DC/LDAP серверів, що збігаються з SAN сертифікатів.
Налаштуйте кілька серверів, якщо доступно (уникати залежності від одного DC).
Встановіть довіру CA у системне сховище довіри на кожному вузлі, консистентно.
Використовуйте виділений сервісний акаунт з мінімальними правами читання до потрібних OU.
Встановіть base DN усвідомлено. Корінь домену — простіше; обмеження вимагають управління.
Визначте формат входу (sAMAccountName vs UPN) і узгодьте user_attr.
Вирішіть політику вкладених груп і протестуйте на реальних прикладах користувачів.
Визначте мапінг груп→ролей в Proxmox і тримайте це під контролем змін.
Тестуйте з кожного вузла (DNS, TCP, TLS, ldapsearch, вхід у Proxmox).

Чекліст B: Коли входи зараз падають і ви на виклику

Підтвердіть використовуваний realm під час входу і вузол, що отримав запит.
Запустіть pveum realm list і pveum realm config <realm>.
Перевірте DNS: getent hosts для налаштованого LDAP-сервера.
Перевірте TCP: nc -vz на 636/389.
Перевірте TLS: openssl s_client і openssl verify.
Запустіть ldapsearch bind і пошук користувача з тим самим base DN і атрибутом.
Подивіться journalctl -u pveproxy -u pvedaemon навколо часу збою.
Перевірте права Proxmox: pveum acl list і мапінг груп.
Якщо мультивузловий: перевірте кворум кластера і консистентність конфігурації.
Лише потім ескалуйтесь до захоплення пакетів.

Чекліст C: Загартування, що не вдарить по вас пізніше

Зберігайте принаймні один break-glass локальний Proxmox-користувач з MFA або сильним контролем (і аудит його використання).
Стандартизуйте управління сховищем довіри CA по вузлах (config management).
Моніторьте доступність LDAPS і закінчення терміну сертифікатів з вузлів Proxmox (не з якогось випадкового monitoring subnet).
Ротейть паролі сервісних акаунтів з runbook і планом тестування.
Обмежуйте фаєрвол правила до DC і потрібних портів, але документуйте це.

Питання та відповіді

1) Чому Proxmox показує «authentication failure», коли реальна проблема в TLS?

Бо з точки зору Proxmox він не зміг вас автентифікувати. Bind не відбувся. Завжди перевіряйте логи і тестуйте TLS окремо з openssl s_client.

2) Користуватися realm типу `ad` чи `ldap` для Active Directory?

Використовуйте ad, якщо нема спеціальної причини не робити цього. Він краще вирівнює налаштування за замовчуванням під AD і зменшує схематичні підводні камені.

3) LDAPS на 636 чи StartTLS на 389?

Обидва можуть бути безпечними. Оберіть те, що підтримує ваша команда каталогів і що ваше моніторинг може надійно перевіряти. У багатьох підприємствах 636 простіше в операціях (чітке розділення), але сильно залежить від сертифікатів.

4) Мій bind DN — повний DN і він зламався після переміщення в OU. Як це запобігти?

Використовуйте UPN-стиль bind-ідентичності (наприклад, svc_pve@corp.example.com), якщо дозволено. Це відвʼязує bind від структури OU. Також: розглядайте переміщення OU як зміну з потенційним впливом, а не «просто прибирання».

5) Користувачі можуть увійти, але права не відображаються згідно з AD-групами. Чого бракує?

Аутентифікація — це не авторизація. Потрібні ACL/ролі Proxmox, повʼязані з користувачами чи групами. Якщо хочете доступ керований AD, визначте, як групи AD мапляться на ролі Proxmox і реалізуйте це явно.

6) Чи потрібно синхронізувати користувачів і групи через `pveum realm sync`?

Залежить від вашої операційної моделі. Sync може полегшити управління групами, але це ще одна рухома частина. Якщо використовуєте — моніторьте та запускайте у контрольованому порядку.

7) Чому входи працюють для прямих членів групи, але не для вкладених?

Тому що memberOf часто відображає лише прямі членства. Вкладені групи потребують спеціальних matching rules або явного розгортання. Або підтримуйте вкладення і тестуйте, або забороніть вкладення для груп Proxmox.

8) Можу я «просто вимкнути перевірку сертифікатів», щоб вийти з глухого кута?

Можете, як можете зняти пасок безпеки, щоб легше дістатися до рації. Якщо вимкнути перевірку, ви вразливі до MITM і шахрайських кінців каталогів. Виправляйте довіру правильно.

9) Чому це падає тільки на одному вузлі Proxmox?

Зазвичай тому, що цей вузол має інший DNS, фаєрвол або стан сховища довіри CA. Іноді — несумісність конфігурації кластера через проблеми з кворумом. Перевірте обидва: залежності вузла і pvecm status.

10) Який найчистіший спосіб відокремити break-glass від нормального доступу?

Тримайте локального pve користувача (або строго контрольований pam акаунт) для надзвичайних випадків, але вимагайте change ticket або процесу з аудитом для його використання. Використовуйте AD для щоденного доступу.

Наступні кроки, які слід виконати після відновлення роботи

Домогтися роботи LDAP/AD один раз — це не кінцева мета. Мета — щоб воно залишалося працездатним під час рутинних змін.

Напишіть односторінковий runbook з налаштуваннями realm-а, підтримуваними форматами входу і точною командою ldapsearch, що використовується для валідації bind-ів і пошуків.
Стандартизируйте сховища довіри по всім вузлам Proxmox і відслідковуйте ротацію CA. Якщо ваш CA змінюється раз у кілька років — цього достатньо, щоб зіпсувати тиждень.
Додайте моніторинг для доступності LDAPS і закінчення терміну сертифікатів з вузлів Proxmox (не з якоїсь випадкової мережі моніторингу).
Зробіть авторизацію явною: мапінг груп→ролей у Proxmox, задокументований і переглянутий як правила фаєрволу.
Протестуйте відмовостійкість, тимчасово виводячи один DC з обслуговування і перевіряючи, що входи працюють через запасний сервер.

Якщо ви це зробите, LDAP перестане бути моторошним будинком і стане тим, чим має бути: залежністю, яку ви розумієте, вимірюєте і можете полагодити під тиском.