Ошибка проверки подлинности с согласованием для winrm

Удаленное управление PowerShell

Ошибка проверки подлинности с согласованием для winrm

PS C:\> Enable-PSRemoting # Командлет сконфигурирует и запустит службу WinRM для удаленного управления PowerShell; добавит в исключение Windows Firewall порт для службы WinRM TCP 5985 WinRM Quick Configuration Running command «Set-WSManQuickConfig» to enable this machine for remote management through WinRM service. This includes: 1. Starting or restarting (if already started) the WinRM service 2.

Setting the WinRM service type to auto start 3. Creating a listener to accept requests on any IP address 4. Enabling firewall exception for WS-Management traffic (for http only). Do you want to continue? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»): y WinRM has been updated to receive requests. WinRM service type changed successfully. WinRM service started. WinRM has been updated for remote management.

Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. WinRM firewall exception enabled. Confirm Are you sure you want to perform this action? Performing operation «Registering session configuration» on Target «Session configuration «Microsoft.PowerShell32» is not found. Running command «Register-PSSessionConfiguration Microsoft.PowerShell32 -processorarchitecture x86 -force» to create «Microsoft.

PowerShell32″ session configuration. This will restart WinRM service.». [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»): y WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping… WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping…

WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping… PS C:\>

Настройка через Групповые политики Active Directory удаленного управления PowerShell

Для этого через групповые политики нужно будет настроить такие параметры:

  • Включить автоматическое конфигурирование службы WinRM
  • Добавить исключение в Windows Firewall для порта TCP 5985

Создаем Group Policy Object

[Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service/]

Параметр Allow automatic configuration of listeners устанавливаем в Enabled и указываем с каких IP-адресов серверу WinRM разрешается принимать соединения (* — с любых адресов, пустое поле — не принимать соединения, рис.1).

[Сomputer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/]

Добавляем новое правило: можно воспользоваться предустановленным параметром Predefined (рис.2) при этом снимаем галочку в окне настроек «Windows Remote Management — Compatibility Mode (HTTP-In)» и затем, если необходимо, добавляем правилу настройки Scope, чтобы указать с каких именно IP-адресов разрешается подключение (рис.3)

Подключаемся по имени хоста внутри домена

PS C:\> whoami # узнаем под каким пользователем мы сейчас работаем domain\user01 PS C:\> Enter-PSSession -ComputerName remotehost33.domain.local -Credential domain\admin # устанавливаем соединение с удаленным хостом remotehost33, используя альтернативные учетные данные [remotehost33.domain.

local]: PS C:\> # как видно из приглашения командной строки, мы уже управляем удаленным компьютером [remotehost33.domain.local]: PS C:\> whoami # узнаем под каким пользователем мы работаем в удаленном сеансе domain\admin [remotehost33.domain.

local]: PS C:\> exit # завершаем удаленный сеанс PS C:\> # мы снова на локальном хосте

Подключаемся по IP-адресу

Здесь есть небольшой подвох. Для подключения через WinRM по IP необходимо чтобы удовлетворялись следующие условия:

  1. транспортным протоколом является HTTPS или назначением является узел из списка TrustedHosts;
  2. должны быть явно указанны учетные данные для соединения,

в противном случае подключающаяся сторона (клиент) откажет в соединении:

PS C:\> Enter-PSSession -ComputerName 10.14.1.100 -Credential domain\admin # Получаем ошибку, потому как IP-адрес, к которому мы коннектимся не добавлен в доверенные хосты и мы не используем ключ -UseSSL (необходима настройка сертификатов) Enter–PSSession : Connecting to remote server failed with the following error message : The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to set TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:16 + Enter–PSSession Set-Item WSMan:\localhost\Client\TrustedHosts -Value 10.14.1.100 # Мы выполним добавление только необходимого нам узла. Также не забываем, что если сетевой маршрут к хосту возможно прослушать сниффером, наши учетные данные могут быть перехвачены. Так что не стоит добавлять в TrustedHosts узлы из интернета WinRM Security Configuration. This command modifies the TrustedHosts list for the WinRM client. The computers in the TrustedHosts list might not be authenticated. The client might send credential information to these computers. Are you sure that you want to modify this list? [Y] Yes [N] No [S] Suspend [?] Help (default is «Y»): y PS C:\> Enter-PSSession -ComputerName 10.14.1.100 -Credential domain\admin # Повторяем команду подключения, которая вначале нам выбивала ошибку [10.14.1.100]: PS C:\> # Как видно, мы успешно соединились по IP 

Читайте также  Проверка айфона по серийному номеру на активацию

Удаленный вызов

Мы также можем и не устанавливать терминальный сеанс с удаленным компьютером, а лишь только вызвать на нем нужный нам скрипт или команду и локально получить его вывод (удаленный вызов процедур). В этом нам поможет командлет Invoke-Command.

Например, давайте вызовем на локальном, а затем на удаленном компьютере с именем «remotehost33», командлет (Get-WMIObject -Class Win32_OperatingSystem).CSName , который выведает нам имя компьютера, и посмотрим что получится:

PS C:\> (Get-WMIObject -Class Win32_OperatingSystem).CSName LocalHost01 PS C:\> Invoke-Command -ComputerName remotehost33 -Credential domain\admin -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} RemoteHost33 PS C:\> Invoke-Command -ComputerName remotehost33, remotehost34, remoteserv02 -Credential domain\admin -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} # скрипт-блок будет выполнен на трех компьютерах, указанных через запятую. Если после запятой стоит дополнительно символ пробела, то скрипт-блок будет выполнятся поочередно. Если же между именами хостов стоит только запятая без пробелов, то скрипт-блок выполнится в обратной очередности

Работа с сессиями PowerShell

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

Источник: http://vam.in.ua/index.php/it/25-ms-powershell/137-powershell-remote-management.html

Выполнение консольных команд на удаленных компьютерах по сети

В данной статье рассмотрены способы выполнения консольных команд на уделенных компьютерах сети, в качестве примеров даются некоторые очень полезные для системных администраторов команды.

Я использую 2 средства удаленного выполнения консольных команд: PsExec и WinRM, у каждого из них есть свои преимущества.

PsExec

Одним из отличных решений поставленной в заголовке задачи является использование программы PsExec от великого Марка Руссиновича.

Программа работает по клиент-серверному принципу: на локальной машине выполняется клиент, который посылает команды серверу на удаленном компьютере. Особенностью этой программы является то, что серверная часть устанавливается автоматически непосредственно перед выполнением команды, а затем удаляется. Таким образом для выполнения команд на удаленных машинах достаточно иметь на них административные права.

Если PsExec запускается от имени администратора, который входит в тот же домен, что и удаленны компьютер, то никаких учетных данных даже вводить не нужно. В противном случае, их можно указать в командной строке, либо PsExec сама их запросит. PsExec работает на ОС начиная с Windows 2000 и заканчивая 64-битным Windows Server 2008 R2.

Очень полезными в PsExec являются следующие возможности:

  • Выполнение команды на группе компьютеров. Пример: следующая команда позволяет принудительно применить самые свежие групповые политики:psexec @group.txt gpupdate /force
  • Выполнение команд от имени системной учетной записи. Пример: следующая команда заставит удаленную систему принудительно проверить обновления:psexec \\computer -s wuauclt /detectnow
  • Копирование выполняемой программы на удаленный компьютер перед выполнением. Пример: следующая команда позволит обновить членство данного компьютера в группе безопасности Active Directory (токен доступа) без перезагрузки:psexec \\computer -c -s klist.exe purge

Трудно переоценить пользу этой программы, если использовать скрипты и возможности консольных команд, встроенных в Windows.

Windows Remote Management

Изначально это была серверная технология для удаленного управления оборудованием, которая появилась в Windows Server 2003 R2 как часть компонента Hardware Management, но недавно Microsoft выпустили пакет Windows Management Framework, который включает в себя PowerShell 2.0 и WinRM 2.0 и устанавливается на клиентские ОС как обновление. Подробности можно прочитать в статье KB968929.

Прелесть WinRM заключается в простоте развертывания в доменной среде через WSUS в качестве факультативного обновления ОС и мощи, которую даёт совместное с PowerShell применение.

Использование WinRM происходит через 2 команды.

winrm.cmd служит для конфигурирования настроек и диагностики клиента и сервера WinRM.

Для того, чтобы сервер WinRM начал принимать команды, должна быть запущена служба Windows Remote Management и произведена её начальная конфигурация. Используйте команду

winrm quickconfig на локальной машине, либо финт ушами
psexec -s \\servername winrm quickconfig по сети, используя PsExec от имени системной учетной записи.

Будет предложено автоматически запускать службу WinRM и разрешить уделенные подключения, соглашайтесь ;)

Чтобы успешно подключаться к WinRM серверу (имеется в виду серверная часть, принимающая команды), не входящему в тот же домен, что и ваш клиентский компьютер, необходимо на клиенте этот целевой сервер добавить в «доверенный список» следующей командой:

winrm set winrm/config/client @{TrustedHosts=»servername»}, где вместо servername можно указать IP-адрес, либо * (звёздочку).

Для пользователей Windows Vista и Windows 7, работающим не от имени встроенного администратора (обычно так и бывает), нужно выполнить следующую команду

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

По умолчанию, установлено ограничение на 5 одновременных соединений WinRM от клиента, для увеличения этого числа выполните команду

winrm s winrm/config/winrs @{MaxShellsPerUser=»X»}

winrs.exe — клиент для отправки запросов к серверной части. Пример: следующая команда принудительно перезагрузит удаленную систему…

winrs -r:servername shutdown /r /t 0

В доменной среде при отправке команд используются учетные данные запустившего пользователя. Для посыла команд от имени другого пользователя используются ключи -u:user -p:pass. Пример: следующая команда очистит локальный кэш DNS-имён на удаленной системе

winrs -r:servername -u:user -p:pass ipconfig /flushdns

Источник: http://argon.pro/blog/2010/02/execute-shell-commands-on-remote-computers/

Как вам могут помочь WinRM и WinRS в Windows Server 2008?

WinRM и WinRS являются нововведением в Windows Vista, Windows Server 2003 R2, Windows Server 2008 (и Server 2008 Core).

Это новые мощные средства командной строки, предлагающие системным администраторам улучшенные возможности удаленного управления и удаленного выполнения программ на машинах с Windows.

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

Что такое Windows Remote Management (WinRM) (Удаленное управление Windows)?

Windows Remote Management (сокращенно WinRM) – это новая удобная служба удаленного управления для Windows Server 2003 R2, Windows Vista и Windows Server 2008.

Читайте также  Как проверить озу на ошибки windows xp

WinRM – это «серверный» компонент этого приложения удаленного управления, а WinRS (Windows Remote Shell – удаленная среда Windows) – это «клиент» для WinRM, которые запускается на удаленном компьютере, пытаясь удаленно управлять сервером WinRM. Однако должен заметить, что на ОБОИХ компьютерах должен быть установлен и включен WinRM, чтобы WinRS мог работать и получать информацию об удаленной системе.

WinRM основан на стандартах Web Services for Management (службы для управления) (WS-Management). Это означает, что WinRM использует протокол HTTP (порт 80) и запросы SOAP для выполнения работы. Это хорошо тем, что запросы HTTP легко пересылать через брандмауэр.

Из этого вытекают хорошее и плохое следствия: с одной стороны, так проще будет управлять удаленным компьютером через Internet, но, с другой стороны, злоумышленнику проще удаленно атаковать этот же компьютер. Еще одно небольшое преимущество использования порта 80 в том, что нет необходимости открывать другие порты на сервере, если входящие HTTP соединения уже были разрешены.

Согласно утверждениям Microsoft, WinRM представляет собой «Новое средство от Microsoft для установления основанного на стандартах API для системного управления». Так что, если вы ранее и не были заинтересованы в изучении таких средств, мне кажется, тот факт, что «это новый стандарт Microsoft» делает его достойным изучения.

Возможно, вы уже знакомы с базой данных Windows Management Instrumentation (WMI) (Инструментарий управления Windows). Но, на всякий случай, скажу, что эта база данных содержит всевозможную информацию об аппаратном и программного обеспечении компьютера. Почти каждое приложение, управляющее системой Windows, опускается не уровень базы данных WMI для выполнения всех административных задач на данном ПК.

WinRM будет использовать базу данных WMI для выполнения задач, аналогичных тем, которые вы, возможно, выполняли с помощью других программных средств вроде VBScript. Преимущество WinRM в том, что он использует HTTP(порт 80), как я уже говорил, кроме того, есть даже специальный код, позволяющий WinRM разделять входящие соединения на порт 80 с компонентом IIS, который уже, возможно, работает с этим портом.

WinRM поддерживает различные типы аутентификации для предотвращения выполнения кем угодно административных задач на ваших клиентах и серверах. Конечно, вам необходимо помнить, что, включая WinRM, вы открываете еще один путь для атакования вашей системы. Однако, как я для любого открытого порта, если аутентификация и шифрование установлены как следует, можно считать, что вы приняли все разумные меры предосторожности.

Производитель вашего ПО, управляющего системой, возможно, уже запланировали использовать WinRM в следующих выпусках своего ПО, так что вы, возможно, уже используете WinRM через другие приложения. Однако вы можете использовать этот компонент и собственноручно, с помощью команды winrm.cmd. С этим средством CLI вы можете очень просто извлекать информацию из базы данных WMI для любой решаемой вами задачи.

Как вы увидите ниже, WinRM обладает интерфейсом командной строки с множеством параметров. Справочная информация о WinRM будет вам показана даже в том случае, когда он не включен на вашей системе.

Рисунок 1:параметры командной строки WinRM

Как включать и использовать WinRM?

Если вы используете Windows 2008 Server, WinRM уже установлен, но не включен по умолчанию. Это хорошая предосторожность. Самый простой способ проверить, включен ли WinRM и запущен ли на вашей машине, это перейти к командной строке и набрать:

winrm enumerate winrm/config/listener

Если вы не получаете ответа, значит, WinRM не запущен. Для настраивания WinRM на автоматический запуск и разрешение удаленного доступа используйте команду winrm quickconfig, например:

C:\Users\Administrator>winrm quickconfigWinRM is not set up to allow remote access to this machine for management.The following changes must be made:Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.Make these changes [y/n]? yWinRM has been updated for remote management.Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.C:\Users\Administrator>

После настройки quickconfig, я перезапустил команду перечисления со следующими результатами:

C:\Users\Administrator>winrm e winrm/config/listenerListenerAddress = *Transport = HTTPPort = 80HostnameEnabled = trueURLPrefix = wsmanCertificateThumbprintListeningOn = 10.253.15.98, 127.0.0.1, ::1, fe80::5efe:10.253.15.98%11, fe80::9583:2148:e1ef:6444%10C:\Users\Administrator>

Теперь я знаю, что WinRM включен.

Кстати, если вы хотите отключить WinRM, нужно использовать такую команду:

winrm delete winrm/config/listener?IPAdress=*+Transport=HTTP

Для использования WinRM все узлы, взаимодействующие с ним, должны быть членами того же домена, что и узел с WinRM.

Что такое WinRS и как его использовать?

WinRS – это аббревиатура для Windows Remote Shell (удаленная среда Windows). С WinRS вы можете делать удаленные запросы на машины с Windows, на которых запущен WinRM. Однако не забывайте, что на вашей машине также необходимо запускать WinRM для работы с WinRS.

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

Рисунок 2: параметры командной строки WinRS

Одним из самых обычных способов использования WinRS является выполнение команд на удаленной машине. Конечно же, это взаимодействие происходит с помощью протокола HTTP (порт 80) (по умолчанию).

Ниже представлен пример использования WinRS: я выполнил команды на узле localhost. Я запустил две команды: ‘ ‘ver‘ и ‘dir C:‘. В каждом случае в ответ была получена адекватная информация.

Рисунок 3: демонстрация команд WinRS

Итоги

WinRM и WinRS представляют собой очень мощные новые средства, о которых системные администраторы Windows просто обязаны узнать.

Подумайте о возможностях удаленного управления с WinRM/WinRS! Вы можете устанавливать программы, изменять настройки, решать проблемы (конечно, если проблема не в сетевом взаимодействии). Вы можете пойти дальше и соединить WinRS со скриптом для выполнения этих задач на нескольких компьютерах.

Читайте также  Как проверить автозагрузку windows 10

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

Дэвид Дэвис (David Davis)

Постовой

Автозапчасти для вашего автомобиля в любом регионе.

Иногда бываю в Питере по делам, подкинули ссылку на компанию, которая предлагает посуточную аренду квартир в СПб. Неплохая альтернатива гостиницам.

Источник: http://system-administrators.info/?p=2508

Устранение ошибок WinRM и ошибок запуска средств управления Exchange 2010

Как мы уже обсуждали, инструменты управления в Exchange 2010 зависят от IIS. Там же мы рассматривали ситуации, когда подключение инструментов управления к целевому серверу Exchange может завершиться аварийно, а сообщение об ошибке подключения оказаться сложным для понимания.

Обычно (но не всегда) это случается, когда Exchange 2010 устанавливается на IIS уже находящийся в эксплуатации, или когда в IIS вносятся изменения после установки Exchange 2010.

  Мы видели, что эти изменения обычно вносятся, когда администратор IIS пытается «закрутить гайки» безопасности в IIS, редактируя настройки Default Web Site или PowerShell vdir.

Ситуация осложняется тем, что некоторые из представленных ошибок имеют похожие сообщения; кажется, что большинство из них происходит из-за WinRM (Windows Remote Management), и в некоторых случаях в корне различные проблемы могут производить совершенно одинаковое сообщение об ошибке. Другими словами в зависимости от того, насколько хорошо вы знакомы с этими ошибками, их устранение превращается в перебор всех вариантов… а это не забавляет.

И вот результат:  представляем Exchange Management Troubleshooter (или кратко EMTshooter).

Что он делает?

EMTshooter запускается на локальном (целевом) сервере Exchange и пытается определить потенциальные проблемы подключения инструментов управления к этому серверу.

EMTshooter выполняется за два шага. На первом шаге он тестирует IIS Default Web Site, PowerShell vdir и другие критические области, чтобы найти известные проблемы. Если он находит известную проблему, то он выдает сообщение с рекомендациями по ее устранению.

Если все проверки проходят удачно, то он пытается подключиться к серверу точно также как инструменты управления. Если это попытка подключения получит ошибку от WinRM, EMTshooter будет пытаться сравнить эту ошибку со списком текстов (строк) ошибок, который мы составили на основе решений для аналогичных ошибок в службе поддержки.

Если соответствие найдено, то EMTshooter выведет в окно CMD известные причины ошибки. Вот пример того, как это выглядит:

 Когда я разрабатывал EMTshooter, я мог бы просто написать маленький поисковый инструмент для анализа сообщения об ошибке, которую вы получили, но я почувствовал, что это не столь надежное решение, как я хотел (и не дающее мне никакого опыта).

Но EMTshooter выполняет предварительные активные проверки до анализа текста сообщения об ошибке.

Количество предварительных проверок, которые он может выполнить, зависит от свойств операционной системы, на которой вы его запустили, и опций, которые вы на ней установили (например, WMI Compatibility).

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

Журнал событий

Когда вы запускаете  EMTshooter, он пишет сообщения в журнал событий. Все результаты, которые отображаются в окне CMD, также записываются в журнал событий.

События пишутся в журнал Microsoft-Exchange-Troubleshooters/Operational и не требуют пояснений.

Запомните!

В зависимости от текущих настроек вам может потребоваться настройка политики на компьютере, на котором выполняется EMTshooter :

Set-ExecutionPolicy RemoteSigned

или

Set-ExecutionPolicy Unrestricted

Не забудьте вернуть политику в исходное состояние после работы с EMTshooter.

Эта версия EMTshooter  должна запускаться на сервере Exchange, к которому невозможно подключиться с помощью инструментов управления. Хотя наша цель была в том, чтобы запускать EMTshooter  из любого места, где установлены инструменты управления,  но он еще не готов для этого.

У нас были случаи, когда повреждение в PowerShell vdir или в самом IIS приводило к ошибкам, которые, как казалось, были вызваны чем-то другим. Например, мы работали над сервером, у которого была ошибка, которая указала на проблему с сетевым путем в PowerShell vdir. Но путь был правильным.

Затем мы заметили, что PowerShell vdir потерял все свои модули, и отметили еще некоторые моменты. Так или иначе, PowerShell vdir на том сервере Exchange был безнадежно убит и не подлежал восстановлению. В этой ситуации WinRM возвращал лучшую ошибку, какую мог, EMTshooter  взял эту ошибку и перечислил причины. Ни одна из них не решила проблему.

Так что знайте: есть сценарии, в которых даже EMTshooter  не может помочь в настоящее время.

EMTshooter  еще недостаточно отточен, и мы планируем в будущем улучшить и расширить его возможности. Мы также надеемся со временем углубиться в настройки PowerShell vdir. Также отметим, что EMTshooter  не будет делать изменения в конфигурации IIS без вашего разрешения.

Необходимые права

Для того, чтобы запустить EMTshooter, пользователь должен иметь права локального входа (log on locally) на Exchange сервер и права запуска Windows Powershell.

Установка EMTshooter

Во-первых, загрузите ZIP файл с EMTshooter , который находится тут.

Установка EMTshooter очень проста. Извлеките 4 файла из ZIP файла в одну папку, переименуйте их в  .ps1и запустите локально EMTshooter.ps1 из окна PowerShell. Лично я создал ярлык на моем рабочем столе:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command «. 'C:\EMTshooter\EMTshooter.ps1'»

Однако большинство пользователей не запускают его часто, и вы, скорее всего, не захотите иметь ярлык. Только помните, что нужно запускать именно файл EMTshooter.ps1.

Обратная связь

Источник: https://blogs.technet.microsoft.com/exchange_ru/2011/01/21/winrm/

Понравилась статья? Поделить с друзьями: