Давайте представим вышеупомянутую архитектуру.И предположим, что с вашего компьютера вам нужен «Get-WmiObject -class Win32_Service».Предположим, что вы все настроили нормально, и в конце попытайтесь отправить следующую команду:
$server = "pc01.xxxx.yyy"
$User = "$server\admin_pc01"
$PWord = ConvertTo-SecureString -String "p4ssw0rd" -AsPlainText -Force
$Credential = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList $User, $PWord
Get-WmiObject -class Win32_Service -ComputerName $server -Credential $Credential
Но вы получите: Get-WmiObject: Доступ запрещен.(Исключение из HRESULT: 0x80070005 (E_ACCESSDENIED))
Почему?
Я провожу некоторые исследования и в программе просмотра событий pc01.xxxx.yyy я обнаружил три события: 4776,46724624 с запросом учетных данных, проверкой учетных данных и доступом.Ошибка кода: 0x0 => нет ошибки, учетные данные действительны.На Event Id 4624 в информации о сети я нашел имя моей рабочей станции, мой IP e мой порт источника tcp: (например: 17380)
Хорошо ... но даже безумно!
Тогда я глубоконырните в брандмауэр (часть зеленого Routing Circle) и обнаружите забавные вещи.
С моего компьютера у меня два соединения: 1) с mypc на 192.168.1.1 на порт 135 с порта 17380 2) с mypc на10.10.10.1 в порт 135 из порта 17381
Хахаха ... тогда я понял !!!
Mypc находится в том же домене zzzz.nnn pc01.zzzz.nnn Когда я отправляюКоманда Get-WmiObject открывает сеанс авторизации (исходный порт 17380) с pc01.xxxx.yyy (и все работает хорошо), но после этого Get-WmiObject открывает другой порт для передачи данных (исходный порт 17381), но в этом случае команда НЕ ИСПОЛЬЗУЕТ FQDN, а ТОЛЬКО имя хоста !!!!Это означает, что команда Get-WmiObject send отправляет на pc01, мой компьютер добавляет домен по умолчанию для разрешения DNS (zzzz.nnn) и ... et volià ... отправляет второй запрос 10.10.10.1 !!!!
Очевидно, что если в моем файле hosts я добавлю строку pc01 192.168.1.1, запрос Get-WmiObject сработает.
Но это не приемлемое для меня решение.