[suvolod]

так, нужную переменную окружения отыскал, так-что вопрос снимается. Но второй - в силе!

[zero55]

а воспользоваться
runas /user:Administartor cmd.exe
никак?

оттуда запускаете все что считаете нужным... с правами админа.

[suvolod]

Такой вариант не прокатит, я писал уже почему - если я запускаю консоль от администратора, и из этой консоли импортирую рег-файл (regedit /s enableRule.reg), то при импорте все записи, которые начинаются с HKEY_CURRENT_USER, будут записаны в в раздел учетки, от кототорой запустилась консоль (т.е. администратора, а не юзера, из под которого вызвали runas). Если интересно, вот небольшой пример:

;Затереть обои рабочего стола
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop]
"Wallpaper"=""

Если сохранишь этот код в рег-файл и запустишь из под юзера через консоль, вызванную по runas /user:Администратор, обои затрутся именно у администратора.

[zero55]

Прослушал...
У вас рабочая группа или домен?
в первом случае пользователю создается обязательный профиль и тиражирование настроек производится через его изменение.
во втором случае все реестровые настроки замечательно устанавливаются средствами GPO.

Я все же убежден в том что вариант - повысить до админа неправильный, вполне достаточно добавить его в "Опытных пользователей".

[Iska]

Такой вариант не прокатит, я писал уже почему - если я запускаю консоль от администратора, и из этой консоли импортирую рег-файл (regedit /s enableRule.reg), то при импорте все записи, которые начинаются с HKEY_CURRENT_USER, будут записаны в в раздел учетки, от кототорой запустилась консоль »

Что мешает параллельно запустить ещё одну консоль — уже от имени того обычного пользователя, под чьим сеансом сидите? Панель управления и прочие радости Проводника получаются запуском из административной консоли «explorer.exe /separate» (что уже не раз рассматривалось здесь).

[suvolod]

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

Но вылез косяк в другом месте - не могу собрать все это в единый батник, т.к в таком варианте получается путаница с путями.
А именно - при запуске консоли через [runas /user Логин cmd] текущей директорией в новой консоли будет C:\windows\system32. Соответственно, до исходной папки с рег-файлом уже не добраться. Как-то можно это обойти? Чтобы, если я запускю [runas .... cmd], например, из папки "C:\Documents and Settings\vova\Рабочий стол\Новая папка", новая консоль открылась в этой же папке?

[zero55]

cmd /c "cd куда_нибудь_в_другую_папку; следующая_команда"

[Iska]

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

[suvolod]

Добил я все-таки свою задумку. Кому интересно, вот окончательное решение:
Доп. консолей можно вообще не запускать, но чтобы все заработало без перезагрузки, надо из под текущего юзера запустить runas /user:текущий юзер regedit off.reg. Кому непонятно вот пример как заблокировать функционал у юзера:

Пусть у нас есть reg-файл, делающий недоступной панель задач, вызываемую через Ctrl+Alt+Del

Код:

Windows Registry Editor Version 5.00
;запретить запуск Диспетчера задач Windows
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System]
"DisableTaskMgr"=dword:00000001

Из под учетки юзера (с правами пользователя) такой рег-файл в реест добавить не получиться, вылетит ошибка. Выход - пишем батник такого содержания:

Код:

SET name=%USERNAME%
cls 
runas /user:Администратор "net localgroup "Администраторы" %name% /add"
runas /user:%name% "regedit \"%~dp0off.reg\""
runas /user:%name% "net localgroup "Администраторы" %name% /del"
pause

Этот батник ложим в одну папку с рег-файлом off.reg и запускаем на выполнение. Что он делает

Первый runas - дает текущему юзеру права админа
Второй runas - выполняет наш рег. файл от текущего юзера, но уже с админскими правами
Третий runas - текущий юзер сам себя выкидывает из администраторов.

На всякий случай - второй и третий runas-ы нужны именно потому, что мы хотим сделать все одним батником, без перезагрузки пользователя после добавления его в админы! Если попытаться выполнить это без runas-ов, то ничего не получиться, т.к. система будет выполнять команды от имени текущего сеанса, в котором пользователь до сих пор сидит с правами только группы "Пользователи".

Кто-то может возразить, что вводить три раза пароли - это не кашерно, но в качестве альтеративы у нас только только тот-же тройной ввод паролей (вход админом для повышения прав пользователя, вход пользоватлем для применения рег. файла + удаления в конце себя из администраторов, и вход/выход пользователем, чтобы применить пониженые права ), но с перезагрузкой после каждого действия. Если у кого-то есть вариант модернизации батника - будет интересно услышать. Например, интересно, можно или нет запрятать пароль админа в сам батник и подставлять его runas автоматом. Ключ /savecred использовать не хочу, т.к. в этом случае пароль админа остается на компе пользователя, пусть и в зашифрованном виде... а папку с батником все-равно буду таскать на флешке, так что даже при сохранении пароля (если это возможно, конечно) в батнике никто его не увидит.

[zero55]

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

таким образом вам тема для размышления.
1. участники группы администраторы у вас имеют право удаленного входа?
2. участники группы администраторы имеют доступ по сети?

PS я все же склоняюсь к тому что нормальное разделение полномочий все же более правильное и безопасное решение чем предложенное вами.