Особенности настройки прав для выполнения запросов WMI на удаленной системе


 

Недавно на формах TechnetRU был задан интересный вопрос про удаленный запросы WMI. http://social.technet.microsoft.com/Forums/ru-RU/user/threads?user=Sazonov+ILYA+%5b+sie+%5d&page=3

Обычно удаленные запросы WMI делает администратор или человек, который имеет права администратора на удаленной системе. И это не вызывает никаких затруднений. А что если надо дать права обычной учетной записи для получения некоторой информации с удаленной системы посредством запроса WMI?

Тут надо учесть несколько моментов:

1.       Надо иметь сетевой доступ к удаленной системе. (Это не относится к правам администратора, но упомянуть про это надо обязательно). Фаервол разрешает доступ на локальной и удаленной системе (Remote management Enable) Для удаленной системы команда: netsh firewall set service RemoteAdmin enable

2.       Надо разрешить удаленный доступ для WMI. Настройка описана в статье Securing a Remote WMI Connection

3.       И самое интересное: даже если вы разрешили удаленный доступ по WMI это не значит, что вы сможете выполнить запрос WMI на удаленной системе! Дело в том, что WMI запустит какой-то провайдер для выполнения запроса и далее будет обращение к некоторым компонентам системы – вот на них тоже надо установить права доступа!

Например, в выше упомянутом обсуждении нужен был доступ к счетчикам производительности. Для решения задачи пришлось не только дать права учетной записи на удаленный доступ WMI, но и включить ее в группу Performance Monitor Users на удаленной системе (либо дать права на ветку реестра).

Аналогичная ситуация будет с другими запросами WMI: учетная запись, от имени которой выполняется запрос, должна иметь права доступа на соответствующие элементы удаленной системы.

Загадочное «Component not correctly registered»


При открытии файла Excel с макросами на одном компьютере стала появляться ошибка  «Component not correctly registered» и следом «Unexpected error(336)». Поиск на MSDN показал, что первое сообщение фактически расшифровка ошибки с номером 336. http://msdn.microsoft.com/en-us/library/k363xak1(VS.80).aspx

Вопрос только какой компонент не зарегистрирован: в Windows их очень много! Сообщение об ошибки столь неинформативно, что даже не знаешь что искать. Логично начать с самого VBasic. Оказалось достаточно загрузить и установить runtime библиотеки VBasic 6.0. http://support.microsoft.com/kb/290887

После их установки файл начал нормально открываться, а макросы отрабатывать. Ура! J

Медленный ISA – проблема в DNS. И другие сюпризы распознавания имен.


 

На днях столкнулся с удивительной ситуацией: «вдруг» ISA сервер стал жутко медленно открывать  web-серверы в DMZ при обращении к ним по ip-адресам (задержка 11 секунд!). При этом сайты в Интернете и в локальной сети открывались по-прежнему быстро, сайты в DMZ при обращении по имени открывались тоже быстро.

Самая неприятная ситуация, когда работает, но плохо и не везде плохо. Проще когда не работает и не работает везде – легче найти причину.

Коллеги MVP сразу сказали: медленный ISA – проблема в DNS. Запуск средства трассировки на ISA подтвердил это утверждение. Хотя ISA при этом выдала сообщение: «ISA Server attempted to evaluate the policy rules without resolving the name of the requested destination. Name resolution will now commence.»  (Можно посмотреть тут ISA Server diagnostic logging troubleshooting scenarios)Как хочешь так и понимай: то ли делает он разрешение имен, то ли нет. По факту все же делает.  И после этого сообщения пауза на 11 секунд! Что ж уже легче – известно где искать проблему.

Запускаю nslookup – нет проблемы с DNS-ами! Разрешение имен работает быстро. Но чудес-то не бывает!… J

Следующий вопрос: а что делали с DNS-ами? Действительно в Active directory настраивали forwarding для служебной зоны расположенной на отдельном DNS-сервере, и для этого пришлось удалить корневую зону как описано в статье KB229840. Казалось бы причем тут ISA? А вот …

Как настроены DNS-ы на ISA. Для разрешения внешних имен в Интернет на ISA установлен локальный DNS (Варианты настройки DNS на ISA  описаны в статье Configuring DNS Servers for ISA Server 2004.) и на сетевых интерфейсах он указан как первичный и единственный DNS. Но в этом случае возникает проблема: сервер ISA является членом домена и должен автоматически регистрировать себя на DNS серверах домена. Ручками регистрировать ресурсы доменного сервера не хочется. В качестве компромисса прописали на внутреннем интерфейсе доменные DNS-серверы. (И именно это привело в последствии к появлению задержки в распознавании имен на ISA сервере.)

Как работает распознавание имен на ISA? Делаем запрос по ip-адресу из Internet Explorer. ISA принимает запрос и делает попытку обратного преобразования адреса в имя (такой у нее алгоритм). ISA ничего не знает о распознавании имен: как любая программа она использует стандартный механизм распознавания имен Windows host name resolver. (Описано тут DNS Client Resolver Behavior и тут Host Name Resolution) Резолвер делает запрос к DNS-серверу прописанному на первичном сетевом подключении – это локальный на ISA сервер DNS, который делает запрос в Интернет и получает мгновенный отрицательный ответ. Потом резолвер перебирает остальные интерфейсы и прописанные на них DNS-серверы. Поэтому запрос попадает не только на локальный с ISA сервер DNS, но и на DNS-серверы домена (!), которые пока были корневыми мгновенно давали отрицательный ответ (нет обратной зоны для запрашиваемого адреса), но после того как стали некорневыми, стали отвечать с паузой, т.к. не имеют прямого выхода на корневые домены Интернета. Стоило сделать доменные серверы корневыми как раньше – ISA сразу ожила!

Я до конца не понял, почему задержка составляла именно 11 секунд.  (Точный ответ могла бы дать трассировка DNS, но исправлять ситуацию нужно было быстро – не до экспериментов.)

Вывод 1 очевидный и хорошо известный: основная причина почему ISA работает медленно – проблема, даже не с DNS, а с распознаваем имен.

Вывод 2: диагностика в ISA – спасибо что есть, но детализация и формулировки сообщений такие, что понять что происходит и в чем проблема довольно сложно.

Вывод 3: проблемы распознавания имен не всегда можно диагностировать с помощью утилиты nslookup, т.к. стандартный резолвер работает достаточно хитро, а nslookup его не использует(!!!) (если запустить nslookup, то первая строчка будет «Default Server»)

Вывод 4: я не знаю, есть ли трассировка работы стандартного резолвера (windows name resolver) и как ее запустить. (Альтернатива – сниффер!)