none
Принцип взаимодействия по RPC рабочей станции в домене и сервера вне домена RRS feed

  • Вопрос

  • Здравствуйте.

    Суть проблемы заключается в следующем:

    1) есть сервер Windows Server 2003 Standard Edition. Сервер входит в рабочую группу.

    2) есть рабочая станция Windows 7. Рабочая станция входит в состав домена (2003).

    3) На сервере и рабочей станции функционирует ПО DeviceLock, использующее в своей работе стандартную процедуру взаимодействия через RPC.

    4) Сервер посылает запрос на создание сессии рабочей станции. Та отвечает серверу и в ходе взаимодействия передает на сервер логи.

    5) Пункт 4) выполняется в четырех случаях:

    5.1) сервер и рабочая станция включены в домен;

    5.2) сервер и рабочая станция исключены из домена;

    5.3) в политике безопасности рабочей станции установлены следующие настройки:

    Network security: Allow Local System to use computer identity for NTLM = Disabled
    - Network security: Allow LocalSystem NULL session fallback = Enabled

    5.4) если взять рабочую станцию с Windows XP, также включенную в домен, то тоже все замечательно работает.

    6) Во всех остальных случаях сессия не устанавливается (в netstat показывает TIME_WAIT).

    Прошу Вас подсказать, можно ли решить проблему альтернативными способами нежели 5.1 - 5.4?

    Проблема связана с какими-то особенностями работы с RPC ОС Windows 2003 или Windows 7?

    P.S. Совершенно осознанно написал на форуме Microsoft, поскольку нет оснований винить в проблеме ПО DeviceLock. Такая уверенность вызвана тем, что решение проблемы обеспечивается настройками именно ОС, а не ПО DeviceLock.

    17 февраля 2012 г. 14:33

Все ответы

  • Правильно понимаю, что на сервере установлен компонент - Devicelock Enterprise Server (для централизованного сбора логов Devicelock)? Под какой учетной записью он запущен - доменной или локальной?

    17 февраля 2012 г. 20:11
    Модератор
  • Да, Вы правильно все поняли.

    Запущена служба из-под учетной записи Local System.

    18 февраля 2012 г. 8:43
  • Попробую поискать ответ на ваш вопрос. Тем не менее, не пренебрегайте технической поддержкой Devicelock. По крайней мере, на мои вопросы они отвечали вполне квалифицированно, и проблемы решали.
    18 февраля 2012 г. 8:56
    Модератор
  • Заранее спасибо. Со службой DeviceLock мы общались по этому вопросу очень плотно на протяжении долгого времени. В конечном итоге, специалисты DeviceLock уверили, что проблема точно не в их продукте, а в некой специфике взаимодействия ОС через RPC.
    18 февраля 2012 г. 9:11
  • Дополнительно хотелось бы отметить также, что в ходе тестирования было выявлено, что в комбинации Windows Server 2008 и Windows 7 метод 5.3 не сработал. Т.е. на текущий момент заставить работать DeviceLock Enterprise Server на сервере с ОС Windows 2008, находящийся вне домена, никак не получается.
    20 февраля 2012 г. 6:28
  • С целью тестирования попробуйте сделать следующее. Проверьте и при необходимости временно выключите Windows Firewall на сервере и на рабочей станции Windows 7. Проверьте, что в локальных политиках безопасности - Уровень проверки подлинности LAN Manager и там, и там выставлены одинаковые значения. На сервере и на рабочей станции Windows 7 создайте одинаковые локальные учетные записи с одинаковыми паролями (сложными) и включите их в локальные группы Administrators. На сервере настройте запуск службы Devicelock Enterprise Server под указанной учетной записью и перезапустите службу. Перезагрузите компьютер с Windows 7. Посмотрите, получает ли сервер логи с рабочей станции в указанной конфигурации.

    Сохраняется ли проблема?

    22 февраля 2012 г. 12:00
    Модератор
  • Здравствуйте.

    Спасибо, буду пробовать. О результатах сообщу здесь.

    24 февраля 2012 г. 6:49
  • 1) Убедился, что Firewall не мешает взаимодействию: выполнил 5.3 из описания методов выше и увидел, что логи с клиента идут.

    2) Вернул все в положение, когда логи не передаются.

    3) По умолчанию на сервере Windows Server 2003 установлен параметр "Network security: LAN Manager authentication level - Send NTLM response only". Повторил эту настройку на рабочей станции Windows 7 (было не определено).

    4) Создал идентичные локальные учетные записи. Перезагрузил рабочую станцию, запустил службу сервера от ее имени, перезагрузил для верности сервер.

    Итог: логи на сервер не передаются. Если снова выполнить 5.3, начинают передаваться.

    24 февраля 2012 г. 14:30
  • Нашел статью на англоязычном сайте техподдержки Devicelock, она знакома вам?

    http://www.devicelock.com/support/kb_view.html?ID=19568&find_message=&find_kb_category_id=0

    28 февраля 2012 г. 5:06
    Модератор
  • Да, конечно.

    Эта статья полностью повторяет мой пункт 5.3 в самом начале этой темы.

    28 февраля 2012 г. 6:38
  • Причина, по которой я завел эту тему, заключается в том, что мне хотелось бы разобраться, почему необходимы такие махинации и есть ли альтернативные методы решения проблемы.

    Описанный в статье метод требует изменения политики безопасности для всех (по крайней мере очень многих) рабочих станций в домене.

    А каковы могут быть последствия не понятно.

    28 февраля 2012 г. 6:40
  • Отвечу только так, как сам понимаю (а понимаю не до конца). Указанные политики безопасности присутствуют только в последних версиях операционных систем, а параметра Network security: Allow Local System to use computer identity for NTLM  нет даже в Vista. И что важно в вашей конфигурации, Windows Server 2003 их не понимает.

    Далее, параметр Network security: Allow Local System to use computer identity for NTLM способен работать только в домене (только в домене компьютеры могут проходить аутентификацию под компьютерными учетными записями). А если данный параметр не включен или не работает, то второй параметр, Network security: Allow LocalSystem NULL session fallback должен быть обязательно включен, иначе аутентификация не произойдет.

    Я не могу объяснить из этих рассуждений, почему у вас все работает, когда и сервер, и рабочая станция находятся в рабочей группе. Однако следует учитывать, что Devicelock Enterpreise Server использует разные методы аутентификации: по учетным записям и по сертификатам. Возможно, аутентификация по сертификату срабатывает в данной конфигурации.


    28 февраля 2012 г. 7:24
    Модератор
  • Обратил внимание, что если предложенный Вами эксперимент провести с параметром "Отправлять LM- и NTLM- ответы", то все работает, даже если запустить службу DeviceLock Enterprise Server из-под учетной записи Local System.

    Спасибо за предоставленную информацию. Получается, что нужно экспериментировать с различными способами аутентификации на Windows 7.

    28 февраля 2012 г. 8:59
  • А вот "Отправлять LM- и NTLM- ответы" я бы не рекомендовал устанавливать - это уже существенное ослабление безопасности. Не знаю, имеет ли это отношение к теме обсуждения, но между протоколами аутентификации NTLM и NTLM версии 2 есть следующее различие: протокол NTLM допускает аутентификацию простым именем пользователя, а в NTLMv2 имя пользователя обязательно должно быть в формате <имя компьютера>\<имя пользователя> или <домен>\<имя пользователя>. Компьютер, находящийся в домене, по моим наблюдениям, всегда добавляет префикс "<домен>\" к имени пользователя.

    Опять же, на уровне рассуждений, но может быть данная информация поможет разобраться в причине проблемы.

    28 февраля 2012 г. 9:55
    Модератор
  • Понял Вас.

    Сообщу дополнительно, что я ошибся с выводами, поскольку в ходе проверки были настроены параметры из 5.3.

    28 февраля 2012 г. 10:44