Запуск программы на удаленном компьютере (Продолжение темы).

Вопрос уже обсуждался, но у меня похитрее задачка.

При запуске программы (cmd, exe и т.д.) на удаленном компьютере с правами текущего пользователя или правами любого другого пользователя в домене, происходит некий глюк. Возможно это не глюк, а фича Майкрософта, но ОНА мне очень мешает и я хочу ее как-то обойти.

Глюк:
Запущенная программа на удаленном компьютере совсем не понимает или не умеет работать с сетевыми ресурсами! Т.е. при попытке скопировать какой-нибудь текстовый файл из разшареной в сети папки ничего не получается :( .

А теперь исходники...
remoteexec.vbs



c:\24.cmd - CMD-файл, который уже лежит на удаленном компьютере.

Задачка файлика 24.cmd - это записать на диск C:\ небольшой лог, о том что запуск выполнялся, а вторая задачка - это скопировать с сетевого ресурса текстовый файл "text01.txt" на диск C:\ .


Мои наблюдения...
Программа 24.cmd успешно запускается. Лог-файл фиксирует ее запуск. На моем компьютере даже выводится номер запущенного процесса на удаленном компьютере.
Но блин копировать текстовый файл не хочет :(

Чего не хватает в моем VB-скрипте ???

Сразу - не нравится мне этот NULL в objProcess.Create 

Как полагаете, какой путь у вызывающего процесса? Попробуйте явно указать, к примеру, "С:\"

Попробовал указать путь "C:\" результат тот же. :(

Но я еще дополнительно попробовал пускать пинги из файла 24.cmd .
Получается. Значит сеть этому процессу доступна.

Попробую как-то промониторить на каком этапе у файла 24.cmd не получается
вытащить текстовый файл из ресурса в локальной сети.
Может у файла 24.cmd нет каких-то прав ? 

А локальное копирование из него выполняется?

Копирование выполняется:
1. Выполняется если я (через удаленный рабочий стол) вручную запускаю файл 24.cmd .
2. Выполняется если ручками открываю Проводник, указываю расшареную папку.

Вот такие вот пироги.



А вот что я еще успел нарыть...
Я зашел на сервер (там где лежит текстовый файл, который я никак не могу скопировать своим скриптом). Открыл я Журнал Событий и вот что там обнаружил:

User: NT AUTHORITY\ANONYMOUS LOGON
Successful Network Logon:
    User Name:    
    Domain:        
    Logon ID:        (0x0,0xA064F6B)
    Logon Type:    3
    Logon Process:    NtLmSsp 
    Authentication Package:    NTLM
    Workstation Name:    COMPUTER1
    Logon GUID:    -
    Caller User Name:    -
    Caller Domain:    -
    Caller Logon ID:    -
    Caller Process ID: -
    Transited Services: -
    Source Network Address:    192.168.1.100
    Source Port:    0


Короче говоря, видно что мой скрипт 24.cmd, почему-то ходит по сети с правами АНОНИМА 
Хотя в реальности он запускается с правами конкретного юзера. Я бы даже добавил, с правами юзера, который является администратором в домене. Т.е. для этого юзера все компы в сети открыты.

Какие будут идеи?

А просмотр на компе, где выполняется задача, подтверждает, что процесс запущен именно от доменного админа?

Да. 
Если смотреть в МенеджерЗадач, то там видно, что процесс cmd.exe ("24.cmd") 
работает от имени доменного админа.

И кстати, если я в файлик 24.cmd вставлю строчку
ping server1 -t

то компьютер будет выполнять пинг до бесконечности.
Пока компьютер выполняет пинг, я посмотрел на имя владельца процесса ping.exe.
Этот процесс тоже запущен от имени доменного админа.

Видимо где-то еще нужно назначать права :(
Почему при запуске вручную хватает даже прав обычного доменного юзера,
а при запуске через скрипт, не достаточно даже прав доменного админа?

Может где-то процессу нужно назначать особые права? Типа права запуска? Или права в окружении?
Короче я тут без руля. Сам ничего не знаю :( поэтому сижу и жду дальнейших советов.

Так... стоп!
А что за странная строка такая 

Насколько я помню, UNC путь - это \\server\share[\folder]\filename.ext
Не вижу имени шары.

Акина, сорри, я просто на форуме неправильно написал путь :(

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

Путь у меня указан правильно \\server1\folder1\text1.txt
За путь не беспокойся, он нормальный. 
Ведь вручную файл 24.cmd работает.


P.S.
Сорри, за неточность.

Попробовал счас (правда, домена у меня нет, eDir) - вижу удалённое подключение от имени гостя...

Попробовал временно подключить шару локальным драйвом (NET USE, первый раз с /SAVECRED, локально), скопировать файл и отключиться - прошло без проблем.

Продолжаю свои наблюдения...

Вот сделал еще один скриптик "CheckLogonType.vbs". Этот скрипт читает список процессов на удаленном компе и выдает LogonType запущенного процесса.


Затем я запустил на удаленном компе (192.168.1.134) два бесконечных процесса ping.exe.
Запускал вручную, т.е. подключился RAdmin-ом и ручками запустил бесконечные пинги на два левых компа в сети.

Затем запустил со своего компа свой первый скрипт remoteexec.vbs. Этот скрипт успешно запустил третий бесконечный процесс ping.exe.

В итоге получилось, что удаленный компьютер стал "озадачен" тремя процессами ping.exe.
 

А теперь прикол...
Я запустил скрипт CheckLogonType.vbs...

Скрипт смог найти только два процесса ping.exe !!!
Скрипт показал, что эти два процесса имеют тип = "CachedInteractive 11" (Attempt cached credentials without accessing the network.)
Ссылка на MSDN: http://msdn.microsoft.com/en-us/library/aa394189(VS.85).aspx

Но третьего процесса этот скрипт не нашел. Третий процесс ping.exe - это тот процесс, который я запустил удаленно скриптом remoteexec.vbs.

Из этого опыта видно, что процессы запускаемые скриптом remoteexec.vbs. Совсем не такие как процессы запущенные локально вручную пользователем!!!

Какие будут мысли?

P.S.
Пока писал свои наблюдения, увидел твой ответ "Дата 4.5.2009, 14:12". Сейчас тоже подумаю.

Похоже, если есть подключение сетевого диска - идёт обращение с правами подключения, если нет - идёт обращение по UNC с гостевыми правами. В принципе, наверное, это логично - "вассал моего вассала - не мой вассал"...

Вероятно, происходит всё-таки следующее.
Скрипт стартует на втором компе, но от имени пользователя первого компа. Тут сбивает с толку совпадение имён. Само собой скрипт не может транслировать права учётной записи с первого удалённого компа на третий комп - отсюда и проблема.

Да по большому счёту он и не должен этого делать - или вся система безопасности рушится к чертям.

:( таки да.

Но я всеравно наблюдаю запускаемые процессы в МенджереЗадач:
wmiprvse.exe запускает 24.cmd, 
24.cmd запускает ping.exe.

владелец wmiprvse.exe - NETWORK SERVICE
владелец 24.cmd           - domain\username
владелец ping.exe         - domain\username

Задачу нужно полюбому решить. Как-то же люди запускают удаленно процессы, которые потом без ограничений работают.

:(

Народ!!! У кого какие еще будут идеи?!!!

Попробуйте докопаться до SID учётных записей, от имени которых работают эти процессы...

И всё-таки попробуйте выполнение из скрипта локальной или удалённой аутентификации (прямо или косвенно) от имени юзера на компе, где исполняется скрипт (компа Б).