QNAP TS-809U: пользователи / группы домена исчезают, и сервер должен быть присоединен к домену AD

У нас есть 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, чтобы выяснить, может ли это быть причиной (если он переключится на внешний, он получит не найденный хост вместо тайм-аутов для внутренних хостов на основе домена) ,

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

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

Однако я создал небольшой скрипт, который проверяет, потеряли ли мы список пользователей из домена, и при необходимости присоединяется к серверу. (Используя net rpc joinкоманду Samba .) «Username» - это пользователь в домене, у которого есть доступ для присоединения компьютеров к домену (мы создали пользователя для 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). Это работало прилично в последние месяцы.