Новый-PSSession с Exchange В помещении провальный “Доступ запрещен”

У меня есть сценарий, который работает от веб-сервера через веб-страницу, которая соединяется с Exchange Server (обменивайтесь 2013 на окнах 2 012 R2). Веб-сервер запускает Windows 2012 R2. Сценарий работает под контекстом пользователя, подключенного к веб-сайту.

При выполнении некоторых тестов происходят следующие сценарии:

  • Соединитесь с веб-сайтом как пользователь домена, запустите скрипт и предоставьте поднятые удостоверения пользователя (любая учетная запись, которая имеет доступ к Exchange Server): сбои
  • Соединитесь с веб-сайтом как поднятый пользователь, запустите скрипт и предоставьте поднятые удостоверения пользователя: успешно выполняется
  • Сделайте пользователя домена локальным администратором на сервере источника, соединитесь с веб-сайтом как тот пользователь и предоставьте поднятые удостоверения пользователя: успешно выполняется

    Код, который соединяется с обменом, похож на это:

    $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 удаленным экземпляром и выполняющих команды вручную.

1
задан 27 October 2015 в 18:10
2 ответа

Проблема в том, что невозможно открыть сеанс на основе Kerberos с другим сервером, если у пользователя нет прав локального администратора, поэтому ответ состоит в том, чтобы установить инструменты обмена на исходном сервере, а затем открыть Сеанс на основе CredSSP с самим собой с использованием предоставленных повышенных учетных данных и импорт необходимых мне команд обмена.

********** edit

Согласно приведенному ниже комментарию, я действительно в конечном итоге использовал Invoke- Команда вместо сеанса 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.

0
ответ дан 4 December 2019 в 10:58

Пожалуйста, проверьте сайт сервера Exchange (IIS) по умолчанию и назначенные сертификаты, они могут быть потеряны.

-4
ответ дан 4 December 2019 в 10:58

Теги

Похожие вопросы