☰

Обновлять

tag-icon • tag-icon nas samba active-directory qnap
Обновлять

У нас есть TS809U, который мы присоединили к домену. Общие ресурсы и права доступа работают как надо с пользователями домена, и все именно так, как и должно быть. Но через пару недель/месяц пользователи домена и группы исчезают из TS809, и мне приходится вручную заново присоединяться к домену. После повторного присоединения к домену процесс повторяется в течение того же периода времени, и мне приходится снова заново присоединяться к домену.

В журналах веб-интерфейса нет ошибок, и он показывает, что NAS успешно присоединяется к домену. Я обновил TS809U до последней прошивки 4.0.3 (из 3.x) в надежде, что это решит проблему, но проблема все еще сохраняется.

Кто-нибудь сталкивался с этим раньше и может ли он подсказать, в чем может быть проблема или как ее устранить?

Единственное сообщение, которое мне удалось найти в средстве просмотра событий и которое ссылается на NAS, — это 5722, которое может указывать на комментарий ниже:

Настройка сеанса с компьютера NASC473CDне прошла аутентификацию. Имя(я) учетной записи(й), указанной в базе данных безопасности, — NASC473CD$.
Произошла следующая ошибка:
Доступ запрещен.

Время между исчезновением записей и их повторным появлением, похоже, составляет 14 дней. Наш домен (все еще) основан на Windows Server 2003.

Обновлять

Обновление: проблема возникла снова, но логи не показали ничего интересного.wbinfo -t(проверка секрета доверия)не сработало и (что неудивительно) тожеwbinfo -c(изменение секрета доверия). Я обнаружил, что текущее хранилище билетов kerberos5 не было обновлено, а срок действия билетов kerberos истек, что может быть связано. Я добавил /sbin/update_krb5_ticketв crontab, чтобы посмотреть, поможет ли это (теперь он обновляется каждый час).

Обновление 2014-02-25

Все еще нет успеха. log.wb-DOMAINNAMEпоказывает, что нам, по-видимому, отказывают в доступе, вероятно, из-за истекших учетных данных или недействительных секретов. Не уверен, как двигаться дальше, так как список билетов kerberos ( klist) показал действительный билет, когда это произошло.

log.wb-DOMAINNAMEпоказывает:

[2014/02/25 03:05:20.545176,  3] winbindd/winbindd_pam.c:1902(winbindd_dual_pam_auth_crap)
  could not open handle to NETLOGON pipe (error: NT_STATUS_ACCESS_DENIED)
[2014/02/25 03:05:20.545198,  2] winbindd/winbindd_pam.c:2003(winbindd_dual_pam_auth_crap)
  NTLM CRAP authentication for user [DOMAINNAME]\[MACHINE$] returned NT_STATUS_ACCESS_DENIED (PAM: 4)
[2014/02/25 03:05:20.548424,  3] winbindd/winbindd_pam.c:1841(winbindd_dual_pam_auth_crap)
  [20497]: pam auth crap domain: DOMAINNAME user: MACHINE$

(те же сообщения об ошибках появляются при обращении к пользователям). По крайней мере, проблема, похоже, в том, что сервер отвечает, ACCESS_DENIEDкогда samba пытается использовать NETLOGONресурс, насколько я понимаю. Однако я обнаружил, что один из DNS-серверов на TS809 был настроен на внешний сервер, а не на сервер в домене. Я обновил DNS-серверы так, чтобы они оба указывали на наши AD DC-ы, чтобы посмотреть, может ли это быть причиной (если он перейдет на внешний, он получит host not found вместо таймаутов для внутренних хостов на основе домена).

Обновление 2015-03-04. В качестве обходного пути развернут скрипт автоматического повторного присоединения.

Мы все еще не приблизились к определению долгосрочного решения, но в настоящее время мы видим тайм-ауты каждую неделю. Это похоже на то же время, что и действительный билет kerberos, но я не смог найти никаких настроек, которые бы его меняли.

Однако я создал небольшой скрипт, который проверяет, не потеряли ли мы список пользователей домена, и при необходимости повторно подключается к серверу. (Используя Sambanet rpc joinкоманда.) «имя пользователя» — это пользователь в домене, который имеет доступ к присоединению компьютеров к домену (мы создали пользователя для QNAP только для этой цели):

COUNT=`wbinfo -g | grep DOMAINNAME | wc -l`

if [ "$COUNT" -lt "1" ]
then
    /usr/local/samba/bin/net rpc join -Uusername%password
fi

Этот скрипт запускается на qnap с cron (поищите qnap cron в Google, как правильно настроить cron). Это работало прилично в последние месяцы.

решение1

Мне кажется, проблема в пароле учетной записи машины. По замыслу в домене 2k3 сброс генерируется каждые 30 дней, но сброс пароля учетной записи машины может быть запущен клиентом, когда захочется.

Обычно участник сначала создает новый пароль, а затем передает его в DC.

По какой-то причине ваш Qnap генерирует новый пароль через две недели, но затем не может передать его на DC из-за сломанного защищенного канала.

Я не знаю функций, предлагаемых qnap, можете ли вы войти через ssh? Я думаю, что это система на базе unix?! Может быть, есть возможность отключить пароль учетной записи машины. Доверие не перестанет работать после этих 30 дней.

Может быть интересно: Коллекция ссылок:

Связанный контент