Назад | Перейти на главную страницу

Проблема с Windows 7 Samba

У нас есть странная проблема с самбой, затрагивающая только одного пользователя. Наша настройка самбы следующая:

Red Hat Enterprise Linux Server версии 5.4 (Tikanga) - сервер Samba

Samba версии 3.0.33-3.14.el5 - версия Samba

Контроллер домена WIN2008R2 Standard - Windows DC

64-разрядная версия Windows 7 - клиентские компьютеры

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

Windows не может получить доступ \\sambaservername

Текущий способ решения проблемы:

Попробуйте получить доступ к одной общей папке в \\sambaservername например \\sambaservername\sharedfolder1. Но даже при этом сначала появится сообщение об ошибке, сообщение об ошибке выглядит следующим образом

Ошибка входа в систему: неизвестное имя пользователя или неверный пароль.

пользователю необходимо снова ввести учетные данные, и он сможет получить доступ к общему ресурсу. После этого он сможет получить доступ \\sambaservername без проблем. Но как только он перезагрузит компьютер, проблема не исчезнет.

Устранение неполадок выполнено на данный момент:

  1. Обеспечьте следующие настройки:

    Перейдите в: Панель управления → Администрирование → Локальная политика безопасности. Выберите: Локальные политики → Параметры безопасности.

    «Сетевая безопасность: уровень проверки подлинности LAN Manager» → Отправить ответы LM и NTLM «Минимальная безопасность сеанса для NTLM SSP» → снимите флажок: Требовать 128-битное шифрование

  2. Посоветуйте пользователю сбросить пароль и попробовать еще раз, но проблема все еще сохраняется.

  3. Пробовал мою учетную запись на ПК пользователя, проблем нет. Пробовал учетную запись пользователя на нескольких других ПК с Windows 7, включая мой, но проблема все еще сохраняется. В Windows XP такой проблемы нет.

  4. Убедитесь, что на ПК с Windows 7 нет сохраненных учетных данных. Проверил диспетчер учетных данных в панели управления, а также набрал эту команду rundll32.exe keymgr.dll, KRShowKeyMgr

  5. Перезапустите демон winbindd на сервере samba, но безрезультатно.

Я подозреваю, что это связано с какой-то проблемой кеширования, но не уверен, в чем проблема. Всякий раз, когда у пользователя возникает ошибка доступа \\sambaservername, на сервере samba будут регистрироваться следующие ошибки:

[2012/10/10 17:10:26, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

Но после обходного пути ошибок больше не будет. Я подозреваю, что после прочтения статьи, указанной ниже, необходимо внести некоторые поправки в \var\samba\cache каталог:

Несколько пользователей используют сервер samba, и я хотел бы решить эту проблему без каких-либо последствий.

Я увидел такую ​​статью:

"winbind offline logon (G)" Этот параметр предназначен для управления тем, должен ли Winbind разрешать вход в систему с модулем pam_winbind с использованием кэшированных учетных данных. Если этот параметр включен, winbindd будет хранить учетные данные успешного входа в систему в зашифрованном виде в локальном кеше.

По умолчанию: winbind offline logon = false

Пример: winbind offline logon = true "

Есть идеи, как удалить запись для одного пользователя в локальном кеше?

Я не уверен, что nbtstat -R команда (которая "очищает и перезагружает таблицу имен удаленного кэша".) или nbtstat -RR один (который «отправляет пакеты освобождения имени в WIN, а затем запускает обновление».) может сделать что угодно, чтобы добиться нужного вам обновления ...

Если вы хотите ознакомиться с руководством, Смотри сюда..

По моему опыту, это обычно является результатом дрейфа времени либо на контроллере домена, либо, в вашем случае, только с одним клиентом, имеющим проблему, с подключенным клиентским компьютером. Поскольку Kerberos включает параметры, связанные со временем, как в запрос сервера аутентификации, так и в ответ сервера аутентификации (AS_Req и AS_rep), большое несоответствие приведет к отклонению маркера сеанса.

AS_Req включает время жизни для запрошенного токена: AS_REQ = (PrincipalClient, PrincipalService, IP_list, Lifetime)

AS_Rep включает метку времени DC и примененное время жизни: AS_REP = {PrincipalService, Timestamp, Lifetime, SKTGS}

Таким образом, если отклонение во времени находится за пределами срока службы, соединение отклоняется.

ПРЕДПОЛОЖЕНИЕ: мне не удалось подтвердить документацией, что время жизни указано в минутах, но я думаю, это потому, что у меня была машина, которая периодически работала, и единственная причина, о которой я мог думать, это то, что она была прямо на границе. жизни. Так что примерно 30 секунд он будет работать, а затем минута изменится, и соединения будут отклонены.

Убедитесь, что ntpd синхронизирован с контроллером домена. У меня была такая же проблема, до сегодняшнего дня я заметил разницу во времени между сервером-нарушителем и контроллером домена в 45 минут. Как только я запустил ntpdate, все заработало.