"Ошибка загрузки данных" при входе в веб-интерфейс

Andrey_C · 2 Дек 2024

ALDpro 2.4.0, Астра 1.7.6

При входе в веб-интерфейс учетной записью администратора домена появляется сообщение "Ошибка загрузки данных"
Просьба подсказать, как поправить

r08 · 2 Дек 2024

В АлдПро 2.3.0 было так

ls -la /tmp/systemd-private-* -R | grep krb5cc-httpd

Если права на файл:
ipaapi ipaapi

Необходимо выставить корректные права на файл командой (пример):

chown www-data:www-data /tmp/systemd-private-***-apache2.service-***/tmp/krb5cc-httpd

Andrey_C · 2 Дек 2024

r08 написал(а):
В АлдПро 2.3.0 было так

ls -la /tmp/systemd-private-* -R | grep krb5cc-httpd

Если права на файл:
ipaapi ipaapi

Необходимо выставить корректные права на файл командой (пример):

chown www-data:www-data /tmp/systemd-private-***-apache2.service-***/tmp/krb5cc-httpd

у меня grep ничего не находит похожего, директория /tmp/systemd-private-***-apache2.service-***/tmp/ пустая

rivan · 3 Дек 2024

у меня было такое - помогал ipactl restart

Andrey_C · 3 Дек 2024

rivan написал(а):
у меня было такое - помогал ipactl restart

пробовал, у меня, к сожалению, без изменений

rivan · 3 Дек 2024

И могу ошибаться, но вроде такое было когда пробовал на копиях обновляться и одновременно обновил и астру с 1.7.4 до 1.7.6 и aldpro.
Откатил, закомментировал репозиторий ald и сначала обновил саму астру, после чего уже aldpro.

Andrey_C · 4 Дек 2024

Выяснил, что ломается после выполнения команды по формированию keytab
sudo ipa-getkeytab -p HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN -k /tmp/http.keytab

Если есть еще идеи, как решить проблему - просьба подсказать

raoul · 5 Июн 2025

Добрый день. У меня сходную проблему решила перестановка корневых сертификатов.

NewGriff · 27 Фев 2026

Описываю свой случай

Ошибка Kerberos аутентификации

Произвести проверку владельца файла можно с помощью команды:

sudo ls -la /tmp/systemd-private-* -R | grep krb5cc-httpd

Файл отсутствует в каталоге !!!!

1. Перезапустить Apache2

systemctl restart apache2

2. Перезапустить FreeIPA

ipactl restart

2. Перезапустить АЛД Про

aldproctl restart

3. Перезагрузиться

reboot

4. Проверить права на `/var/lib/ipa/gssproxy/http.keytab`

ls -la /var/lib/ipa/gssproxy/http.keytab

должно быть `-rw------- 1 www-data www-data`

5. Сравнить номер версии ключа Kerberos и содержимого keytab-файла

команда

kvno HTTP/dc1.domain.ru@DOMAIN.RU

Вывод:

HTTP/dc1.domain.ru@DOMAIN.RU: kvno = 2

команда:

klist -kte /var/lib/ipa/gssproxy/http.keytab

Вывод
Keytab name: FILE:/var/lib/ipa/gssproxy/http.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
1 30.09.2025 15:02:55 HTTP/dc1.domain.ru@DOMAIN.RU (aes256-cts-hmac-sha1-96)
1 30.09.2025 15:02:55 HTTP/dc1.domain.ru@DOMAIN.RU (aes128-cts-hmac-sha1-96)

Проблема:

- **В KDC (сервер Kerberos):** KVNO = **2** для принципала HTTP/dc1.domain.ru@DOMAIN.RU
- **В keytab-файле:** KVNO = **1** для того же принципала
- Это классическое расхождение версий ключа. KDC ожидает ключ версии 2, а сервис предлагает ключ версии 1, отсюда и ошибка

Решение:

Обновить keytab до актуальной версии ключа

Нужно извлечь ключ с версией KVNO = 2 из KDC:

Создайте новый keytab с актуальной версией ключа (KVNO=2)
Используем ключ -r (retrieve), чтобы извлечь существующий ключ, а не создавать новый

sudo ipa-getkeytab -r -p HTTP/dc1.domain.ru -k /tmp/http.keytab

Если команда выше не работает (ошибка аутентификации), используйте вариант с Directory Manager:

sudo ipa-getkeytab -r -p HTTP/dc1.domain.ru -D 'cn=directory manager' -w 'ПАРОЛЬ_DM' -k /tmp/http.keytab

Проверьте, что новый keytab содержит ключ с KVNO=2

sudo klist -kte /tmp/http.keytab

Должны увидеть: KVNO: 2 для HTTP/dc1.domain.ru

Остановите службы

sudo systemctl stop gssproxy apache2

Создайте резервную копию текущего keytab

sudo cp /var/lib/ipa/gssproxy/http.keytab /var/lib/ipa/gssproxy/http.keytab.bak.$(date +%Y%m%d)

Скопируйте новый keytab

sudo cp /tmp/http.keytab /var/lib/ipa/gssproxy/http.keytab

Установите правильные права

sudo chown www-data:www-data /var/lib/ipa/gssproxy/http.keytab
sudo chmod 600 /var/lib/ipa/gssproxy/http.keytab

Запустите службы

sudo systemctl start gssproxy
sudo systemctl start apache2

### Проверка

Проверьте, что теперь KVNO совпадают

kvno HTTP/dc1.domain.ru@DOMAIN.RU

Должно быть KVNO=2

Проверьте получение билета

sudo kvno -k /var/lib/ipa/gssproxy/http.keytab HTTP/dc1.domain.ru

Проверьте работу FreeIPA

ipa ping

### Важное замечание

Если команда ipa-getkeytab -r не сработает (например, вернет ошибку "PrincipalName not found" или "Failed to retrieve keytab"), это будет означать, что ключ с KVNO=2 почему-то недоступен для извлечения. В таком случае придется создать **новый** ключ с KVNO=3:

Создайте новый ключ (без -r) - это увеличит KVNO до 3

sudo ipa-getkeytab -p HTTP/dc1.domain.ru -k /tmp/http.keytab

Остановите службы