Проблема с вложенными вызовами с помощью psexec (доступ запрещен)

Question

Прежде всего, извините за мой плохой английский. Я бы попытался объяснить мою проблему.

Я использую psexec в скрипте для перезапуска кластера следующим образом:

script1 на узле 1: выполнять множество задач (отключение служб, проверка состояния и т. Д.) На узле 1 и после завершения всех задач запустить с помощью psexec script2 на узле 2 (psexec-d \ \ node2 script2)

script2 на узле 2: выполняет много задач и запускает script3 на узле 1. Вот когда я получил «отказано в доступе» в psexec, когда я пытаюсь запустить script3 в node1. (psexec-d \ \ nodo1 script3)

Я запускаю скрипт с пользователем, который принадлежит к группе администраторов

По соображениям безопасности я не могу передать имя пользователя и пароль, поскольку оставлять учетные данные в файле .bat небезопасно.

Дополнительная информация:

Я запускаю скрипт на сервере W2k3 Я попытался использовать сеть, и все в порядке Я попробовал psexec с -u username и -p username и все нормально Я попытался выполнить psexec с этим синтаксисом: psexec .exe -d \ node1 cmd.exe "script3.bat" и возвращает ту же ошибку.

Большое спасибо С наилучшими пожеланиями

Answer 1

Наконец, я решил использовать сторожевой процесс во втором сценарии, поэтому сценарий будет запускаться этим процессом вместо запуска psexec.

Большое спасибо за вашу помощь и ваше время, посвященное, чтобы помочь мне.

С уважением

Answer 2

Можете ли вы сделать вызов script2 дождаться завершения, вместо того, чтобы script2 перезвонил на node1:

script1 в node1: выполнить много задачи (отключение сервисов, проверка статус и т. д.) в узле 1 и после завершение всего запуска задачи с помощью psexec script2 в node2 (psexec \ \ node2 script2)

script2 в node2: выполнить много задачи.

script1 в узле 1: запускает script3.

Answer 3

Это может быть связано с проблемой, которая возникает из-за слишком большого числа связанных серверных переходов с использованием встроенной аутентификации - проблема Kerberos с двумя прыжками .

Поскольку встроенная аутентификация Windows охватывает два отдельных механизма аутентификации:

• NTLM v2-and-
• Kerberos,

если вы используете Kerberos, поскольку пароль пользователя никогда не передается на сервер IIS, единственный способ, с помощью которого токен на сервере IIS может перейти на другой компьютер в сети, - через делегирование Kerberos. Если это не доступно или не разрешено, то прыжок не произойдет (как это и звучит)

Учитывая, что вы используете учетные данные по умолчанию, и если текущий контекст безопасности является маркером олицетворения, который не может делегировать, то предоставленные учетные данные не будут надеяться на другая машина. Поскольку встроенная проверка подлинности Windows создает маркер олицетворения, вполне вероятно, что это так.

Источники:

• проблема psexec
• Тема проверки подлинности Windows (форум)