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