У наших разработчиков всплыла странная проблема. Дело в том, что проекты лежат на тестовом сервере, работающем под FreeBSD. И работать с файлами им нравится именно через samba. Когда пользовались Windows XP все было в порядке. После перехода на Windows 7 стали возникать странные проблемы.
Проблема заключается в том, что пользователь не может подключиться к share на samba. Получает ошибку о неправильном логине или пароле. Причем не всегда и не у всех. При этом, если пробовать подключиться к тому же ресурсу из-под FAR, то шансов подключиться больше. Если получится это сделать из-под FAR, то можно работать и из-под Windows.
В общем- мистика какая-то.
Думаю, что надо смотреть в сторону подписывания smb (smb signing) и/или поддержки различных версий протоколов SMB.
XP и samba умеют только smb v1, начиная с vista в win появилась поддержка smb v2 (ЕМНИП, samba его не умеет).
http://support.microsoft.com/kb/823659
комментарий от shs — 20.09.2010 @ 19:56 |
Вот еще, в догонку: http://support.microsoft.com/kb/321169/
http://support.microsoft.com/kb/887429
ЗЫ в никсах понмаю примерно так же, как свинья в апельсинах, но думаю, что надо смотреть в эту сторону (в первую очередь)
комментарий от shs — 20.09.2010 @ 20:07 |
Мы где-то туда и смотрим :-) Тут все дело в том, что сама проблема сильно неоднозначна. Т.е. то работает, то не работает и все это не у всех проявляется.
Пока что нами найден workaround — назначение идентичных логинов и паролей как в домене, так и на самбу.
комментарий от itpadla — 20.09.2010 @ 20:30
NTLMv2 ?
комментарий от Planer — 11.11.2010 @ 11:59 |
Да, конечно.
комментарий от itpadla — 11.11.2010 @ 16:07 |
Я у себя решил аналогичную проблему. Правда мой FreeBSD сервер является членом домена Windows и авторизация настроена через winbind.
Тут уже верно отметили: причина в том, что SAMBA не поддерживает NTLMv2. Для нормальной работы Win7 с Samba нужно редактировать локальную политику безопасности на семерке. Если проблема для вас актуальна — могу рассказать подробнее
комментарий от Planer — 15.12.2010 @ 09:54
Как я и писал, workaround мы нашли, хотя это, конечно же, «костыль». Думаю, что ваш метод сводится к изменению групповой политики для клиента, в результате которой о начнет пользоваться NTLM вместо NTLM v2. Если не так — опишите.
Но понижать до NTLM V1 тоже бы не хотелось.
комментарий от itpadla — 15.12.2010 @ 10:41