Вдохновленный мой предыдущий вопрос здесь , я экспериментировал с Psexec.
Цель состоит в том, чтобы отключить некоторые довольно простые скрипты / программы на одном компьютере с WindowsXP с другого, и поскольку PowerShell 2 еще не поддерживает удаленное взаимодействие в XP, PSexec, похоже, хорошо решит мои проблемы.
Однако я не могу получить ничего, кроме ошибки «Доступ запрещен».
Вот что я пробовал до сих пор:
У меня есть пара машин WindowsXP MCE, объединенных в сеть в рабочей группе без сервера или контроллера домена.
Я отключил «простой обмен файлами» на обеих машинах.
В соответствии с политикой безопасности модель «Доступ к сети: общий доступ и безопасность» для локальных учетных записей установлена на «Классический», а не «Гость» для обеих машин.
Для каждого компьютера, к которому я знаю пароли, есть Административный пользователь. :)
При этом команда типа " > psexec \\otherComputer -u adminUser cmd" запрашивает пароль (как и должно быть) и затем завершается с:
Couldn't access otherComputer:
Access is denied.
Итак, на этом этапе я перехожу к сообществу. Какой шаг я здесь пропускаю?
Ответы:
Добавьте следующий реестр DWORD на удаленный компьютер, и это должно исправить проблему.
источник
Задача решена.
Получается, что по умолчанию Windows не позволяет удаленно войти с учетной записью пользователя с пустым паролем. Чтобы поэкспериментировать с PSExec, я изменил пароль учетной записи администратора на целевой машине на ничто, полагая, что это уменьшит количество набираемых текстов. Оказывается, это была моя проблема, и как только я вернул пароль, все заработало отлично.
Однако это вызвало другое расследование. Если кто-то хочет использовать PSExec с пустым паролем, вот что вам нужно сделать (в любом случае под Windows XP MCE):
источник
Я думаю, что PSEXEC полагается на возможность открыть общий ресурс ADMIN $, поэтому проверьте это с теми же учетными данными,
источник
Если вы печатаете
в мой компьютер и аутентифицированные как adminUser это работает?
Я предполагаю, что вы использовали двойную косую черту, и система удалила ее.
Вам нужно, чтобы стандартное совместное использование файлов Windows было включено и разрешено через брандмауэр, чтобы это работало.
источник
Я столкнулся с этой ошибкой при запуске PSExec из командной строки без повышенных прав (в Windows 7). Выполнение команды из командной строки с повышенными правами исправило ее.
источник
Я нашел еще одну причину сбоя PSEXEC (и других инструментов PS) - если что-то (... скажем, вирус или троян) скрывает папку Windows и / или ее файлы, то PSEXEC завершится с ошибкой «Доступ запрещен», PSLIST выдаст ошибку «Объект производительности процессора не найден на», и вы будете оставлены в неведении относительно причины.
Вы можете RDP в; Вы можете получить доступ к admin $ share; Вы можете просматривать содержимое диска удаленно и т. Д. И т. Д., Но нет никаких указаний на то, что причиной является скрытый файл (ы) или папка (и).
Я буду публиковать эту информацию на нескольких страницах, которые вчера просматривал, пытаясь определить причину этой странной проблемы, так что вы можете увидеть это дословно в другом месте - просто подумал, что я выложу слово, прежде чем кто-то еще вырвет их волосы корнями пытаясь понять, почему счетчик производительности имеет какое-либо отношение к работе PSEXEC.
источник
Защитник Windows или другая защита от вредоносных программ работает? Это блокирует? Я знаю, что Защитник Windows способен на это.
источник
Захват трафика с помощью Wireshark часто помогает отследить проблему в этих ситуациях. Вы можете посмотреть на трафик SMB и увидеть, как Windows пытается аутентифицироваться или даже вообще заходит так далеко в случае брандмауэров, блокирующих трафик и т. Д.
источник
Еще одна вещь, чтобы проверить, блокирует ли ваш антивирус psexecsvc.exe. Я только что натолкнулся на это с Софосом. Я получил отказ в доступе и увидел, что Sophos блокирует PSEXEC из журнала приложений.
источник