У меня есть сценарий, который запускается с веб-сервера через веб-страницу, которая подключается к серверу обмена (Exchange 2013 на Windows 2012 R2). Веб-сервер работает под управлением Windows 2012 R2. Скрипт запускается в контексте пользователя, подключенного к сайту.
Выполняя некоторые тесты, случаются следующие сценарии:
Сделайте пользователя домена локальным администратором на исходном сервере, подключитесь к веб-сайту как этот пользователь и предоставьте учетные данные пользователя с повышенными правами: успешно
Код, который подключается к бирже, выглядит так:
$pw = ConvertTo-SecureString $request['pass'] -AsplainText -Force
$user = $request['login']
$creds = New-Object System.Management.Automation.PSCredential($user,$pw)
$onPremSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://exchangeserver/PowerShell/" -Credential $creds -Authentication Kerberos
В $request Объекты - это то, как сценарий получает учетные данные для подключения для обмена и правильной работы, что подтверждается текстами.
Я думал, что это может быть проблема второго прыжка, но это не объясняло, почему он работает, когда пользователь является локальным администратором на сервере, с которого запускается скрипт?
Единственное, что кажется важным, это то, является ли пользователь, запускающий сценарий, локальным администратором на сервере, с которого он запущен, тогда соединение будет успешным, пока предоставлены учетные данные, которые имеют доступ к обмену.
После дальнейшего расследования я думаю, что мне нужно как-то запустить команду New-PSSession в контексте ее отправки пользователем с повышенными привилегиями, так как у него есть права локального администратора на сервере, но я не уверен, как этого добиться, поскольку я технически не вызывая сценарий, поэтому я могу открыть новый экземпляр Powershell.exe как пользователь с повышенными привилегиями.
Я также должен добавить, что просто использовать для этого оболочку нельзя, цель сайта - избавиться от зависимости от пользователей, подключающихся к удаленному экземпляру PowerShell и выполняющих команды вручную.
Проблема в том, что невозможно открыть сеанс на основе Kerberos на другом сервере, если у пользователя нет прав локального администратора, поэтому ответ состоит в том, чтобы установить инструменты обмена на исходном сервере, а затем открыть сеанс на основе CredSSP с самим собой, используя предоставленные повышенные учетные данные и импортировать нужные мне команды обмена.
********** редактировать
Согласно приведенному ниже комментарию, я фактически использовал Invoke-Command вместо сеанса CredSSP:
Invoke-Command -ComputerName "localhost" -EnableNetworkAccess -Credential $creds -ScriptBlock {
param($creds, $username)
& 'C:\Program Files\Microsoft\Exchange Server\V15\Bin\RemoteExchange.ps1' | out-null;
Connect-OnPremExchange -ComputerName "exchangeserver" -Credential $creds;
try{
Enable-RemoteMailbox "$($username)" -RemoteRoutingAddress "$($username)@network.mail.onmicrosoft.com" | out-null
}catch [Exception]{
$errorFlag = "error"
}finally{
}
return $errorFlag
} -ArgumentList $creds, $request['username']
Интересно также отметить, что, хотя это работает для команд обмена, облегченные службы Active Directory не любят работать таким же образом. Когда я попытался вызвать команду с поднятыми учетными данными на локальном хосте для Add-ADGroupMember, он не смог связаться с сервером или распознать, что AD работает, но это все еще работает с использованием New-PSSession на локальном хосте через CredSSP.
Пожалуйста, проверьте сайт по умолчанию сервера Exchange (IIS) и назначенные сертификаты, они могут быть потеряны.