При работе с Remoting в Windows PowerShell вы можете столкнуться с кое-какими сложными ситуациями. Внимательно следите, сколько раз происходит переход (hop).
Дон Джоунз
Windows PowerShell Remoting - интересная технология, позволяющая управлять несколькими удаленными компьютерами так же легко, как одним. В доменной среде она просто работает. Вместе с тем, необходимо следить за некоторыми "подводными камнями", которые могут по-настоящему сбить вас с толку. "Второй переход" - один из них.
Одна из особенно замечательных сторон Remoting - то, насколько хорошо она интегрирована с определенными технологиями Windows, такими как протокол аутентификации Kerberos. В отличие от менее современных средств, которые могут принимать и выполнять удаленные команды, Remoting не работает под всемогущей учетной записью LocalSystem. Вместо этого, когда вы соединяетесь, ваши удостоверения Windows (под которыми вы вошли или которые указаны при установке соединения) делегируются удаленному компьютеру или компьютерам.
Делегирование - встроенная функция Kerberos и Active Directory. Она совершенно безопасна. Ваш пароль не передается по сети в открытом, зашифрованном или каком-либо еще виде. Он служит не более чем совместно используемым ключом для шифрования.
Делегирование означает, что копия Windows PowerShell на удаленном компьютере выполняет команды так, как это делали бы вы, то есть Remoting прозрачна с точки зрения безопасности. Все, на что вы имеете разрешение, вы можете сделать удаленно. Если вы не имеете разрешения на что-либо, вы не можете это сделать. Remoting выполняет команды так, как если бы это были вы.
Итак, сядьте за свой клиентский компьютер и соединитесь с сервером ServerA, который является удаленным компьютером. Ваше удостоверение делегируется этому компьютеру. С компьютера ServerA попробуйте инициировать еще одно соединение с каким-либо третьим компьютером. Это не обязательно должно быть соединение Remoting. Вы можете сопоставить этому третьему компьютеру сетевой диск, обратиться к хранилищу сертификатов или сделать что-либо еще. Только что вы попытались совершить второй переход.
Первым был переход от вашего клиента к ServerA. Вторым - переход от ServerA к другому компьютеру, с которым вы пытаетесь соединиться. Проблема возникает из-за того, что ваши удостоверения не делегируются во второй раз.
На самом деле, это такая защитная функция, придуманная для того, чтобы никто не мог обойти защиту и использовать ваши удостоверения без вашего ведома. Второй переход потерпит неудачу, поскольку ServerA не сможет передать удостоверения без дополнительных усилий с вашей стороны.
Почти в каждом классе Windows PowerShell, который приходит мне в голову, кто-то сталкивался с таким ограничением. О том, что вы заходите на удаленный компьютер, легко забыть: настолько прост и прозрачен доступ. Поэтому запросто можно, в конце концов, попытаться установить удаленное соединение с третьим компьютером, не осознавая, что вы совершаете второй переход.
Делегирование удостоверений не выполняется, второй переход терпит неудачу, вы видите непонятные сообщения об ошибках, и в результате все приходят в замешательство. Это может случиться, даже если вы совершили только один переход, но пытаетесь выполнить на удаленном компьютере операцию, требующую делегированные удостоверения.
В сообщении блога по Windows PowerShell "CredSSP for second-hop remoting" рассказывается о том, что происходит. Также там описывается решение, которое заключается в активизации нового протокола CredSSP. Его необходимо активизировать на вашем клиентском компьютере и всех компьютерах, к которым вы собираетесь обращаться удаленно. Для этого служат следующие команды:
Enable-WSManCredSSP -Role client -DelegateComputer *
Enable-WSManCredSSP -Role serverДумаю, очевидно, какая команда выполняется на клиенте, а какая на сервере. Можно также активизировать этот протокол через Group Policy Object (объект групповой политики, GPO) в параметрах Windows Remote Management (WinRM). Кроме того, необходимо указывать протокол CredSSP при выполнении Invoke-Command, Enter-PSSession, New-PSSession и любых других командлетов, использующих Remoting.
Ознакомьтесь с нашим бесплатным PDF-документом "A Layman"s Guide to PowerShell 2.0 Remoting", написанным Равикантом Чаганти (Ravikanth Chaganti). В нем более подробно рассказывается о проблеме второго перехода (особенно в главе 10) и о том, как разрешать возникающие из-за него запутанные ситуации. Например, отмечается, что контроллерам домена не нужна активизация CredSSP для того, чтобы сотворить чудо второго перехода, поскольку они настроены на его поддержку по умолчанию.
Имеется ряд других сложных ситуаций, с которыми можно столкнуться при работе с Remoting. Вам могут встретиться компьютер, не входящий в домен, соединение между доменами, удаленный доступ через прокси-сервер и т. д. Выполните команду run help about_remote_troubleshooting в Windows PowerShell, чтобы получить подробные инструкции, связанные с этими и другими ситуациями. А если это не поможет, напишите мне строчку-другую.