У нас є 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коли самба намагається використовувати NETLOGONресурс, наскільки я розумію. Однак я виявив, що один з DNS-серверів TS809 був встановлений на зовнішній сервер, а не на сервер у домені. Я оновив DNS-сервери, щоб обидва вказували на наші AD DC-диски, щоб побачити, чи це може бути причиною (якщо воно потрапить на зовнішній, він отримає хост не знайдений замість таймаутів для внутрішніх хостів на основі домену) .
Оновити 2015-03-04. Автоматизований сценарій повторного приєднання розгорнуто як обхід.
Ми все ще не ближче до визначення довготривалого рішення, але в даний час ми спостерігаємо тайм-аути щотижня. Здається, це той самий час, що і дійсний квиток на kerberos, але я не зміг знайти жодного параметра, який би його змінив.
Однак я створив невеликий сценарій, який перевіряє, чи ми втратили список користувачів з домену, і при необхідності знову приєднується до сервера. (Використовуючи net rpc joinкоманду Samba .) "Ім'я користувача" - це користувач у домені, який має доступ для приєднання комп'ютерів до домену (ми створили користувача для qnap лише для цієї мети):
COUNT=`wbinfo -g | grep DOMAINNAME | wc -l`
if [ "$COUNT" -lt "1" ]
then
/usr/local/samba/bin/net rpc join -Uusername%password
fi
Цей сценарій запускається на qnap with cron (шукайте qnap cron в Google про те, як правильно встановити cron). Це працювало гідно останні місяці.