Как повысить юзера до администратора из командной строки?

[suvolod]

Идея в следующем:
есть сетка из 20 компьютеров, в каждом из которых права сотрудников ограничены до группы Пользователи + применено достаточно много твиков реестра для того, чтобы обрезать сотрудникам доступ к ненужным с точки зрения админа функциям системы. Но иногда мне надо прийти, сесть за этот компютер, повысить пользователя до админа, разблокировать все недоступные функции (типа просмотра вкладки Безопасность, скрытых апплетов панели управления и т.д.), сделать свою работу по обслуживанию системы, после чего вернуть все обратно... Хочется как-то автоматизировать этот процесс. Хотя-бы через батник. Как его написать, представляю.... но не знаю команды (если она есть конечно) по выполнению первого шага - т.е. повышения прав пользователя до прав админа. Запускать эту команду хочу через runas с учеткой админа

[Telepuzik]

но не знаю команды (если она есть конечно) по выполнению первого шага - т.е. повышения прав пользователя до прав админа. Запускать эту команду хочу через runas с учеткой админа »
Так команда runas и позваоляет запускать приложение с правами администратора. Команда:
runas /profile /user:mydomain\Administrator compmgmt.msc запустит консоль Управление компьютером с правами пользователя mydomain\Administrator.

[monkkey]

suvolod,
повысить пользователя до админа »
А почему бы не загрузиться под локальным администратором?

[suvolod]

Так команда runas и позваоляет запускать приложение с правами администратора. Команда:
runas /profile /user:mydomain\Administrator compmgmt.msc запустит консоль Управление компьютером с правами пользователя mydomain\Administrator. »

Нет, так не пойдет. Смотри: я хочу создать бат-файл, который:
1. Повышает текущего пользователя до админа (путем запуска неизвестной пока мне проги через runas с правами админа)
2. Снимает кучу ограничений через импорт reg-файла с твиками, восстанавливающими заблокированные возможности винды.

Ну и второй батник потом хочу создать чтобы снова "закрыть" и ограничить в правах пользователя.

Проблема в том, что reg-файл, о котором я говорю, в основом содержит ключи для импорта в ветку HKEY_CURRENT_USER. То есть текущего юзера. И если я просто запущу его через админа, то этот файл будет применен именно к той учетке, из под которой он вызван - то есть админской. А юзер как был заблокированным по функционалу, так и останется.. Так что мне надо именно консольную прогу/команду для добавления юзера в группу Администраторы.

[Telepuzik]

Так что мне надо именно консольную прогу/команду для добавления юзера в группу Администраторы. »
net localgroup "Администраторы" "UserName" /ADD - добавляет пользователя UserName в группу локальных Администраторов.

[zero55]

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

Поверьте, пользователь меньше всего нуждается в дополнительных правах т.к. он в 99% случаем не знает что с ними делать или использует неправитьно.

[suvolod]

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

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

Телепузик, большое спасибо за подсказку :).. но в процессе написания кода bat-ника опять сложности возникли. Смотри -
я использую такой код:

-------------------------------------------------------------------------------------------------------------
runas /user:Администратор "net localgroup "Администраторы" "user01" /ADD"
-------------------------------------------------------------------------------------------------------------

Если его прочитать слева направо, он звучит так: от имени пользователя "Администратор" выполнить добавление в группу "Администраторы" пользователя user01.

Если его вставить в Пуск > Выполнить или просто cmd-консоль, то все срабатывает. Если же я пихаю эту строку в bat-ник, то ничего не происходит. Извращался уже по всякому. Даже пробовал Администратора добавить для теста в группу Пользователи (думал может с правами что) - но не помогло. Любая учетка из под любой административной учетки моим кодом успешно меняется, но только если она вставлена непосредственно в командную строку.. Пихаю ее без изменений в батник - и ничего не происходит..

[berk2030]

А у вас DC с Active Directory или нет ? Если да то зачем париться bat-никами или еще чем то? Введите свою учетку Администратора в группу Local Admins и логируйтесь на компьютерах user-ов под своей АДМИНСКОЙ учеткой.

[Telepuzik]

Пихаю ее без изменений в батник - и ничего не происходит.. »
Смотрите в сторону кодировки символов при выполнении bat-файла. Создайте bat -файл следующим образом в консоле cmd наберите следующие: echo "net localgroup "Администраторы" "User" /ADD" > test.bat и затем запустите полученный bat файл и посмотрите выполниться он нормально или нет.

[suvolod]

Да, в таком варианте (сгенерированный эхом файл) работает..
Потестировал возможности и появилось еще пара вопросов. Во первых, еще раз процитирую сам батник:

//------------------------------------------------------
runas.exe /user:Администратор "net localgroup "Администраторы" "user01" /ADD"
shutdown /l
//------------------------------------------------------

проблема в том, что этот батник придется таскать между разными пк, все юзеры сидят под разными логинами, соответственно постоянно придется менять "user01". Может, где-то в переменных окружения храниться константа текущего логина, чтобы я мог забить нечто вроде

runas.exe /user:Администратор "net localgroup "Администраторы" %CURR_USER% /ADD"

... а интерпретатор cmd сам подставил вместо шаблона имя текущего юзера?

Ну и второе. Совсем забыл, что в текущем сеансе сохраняются старые права... Поэтому, несмотря на то, что я смог загнать
батником юзера в админы, до завершения сеанса ему по прежнему ничего не доступно... Потому и пририсовал команду shutdown для завершения сеанса.. но тогда ни о каком импорте reg-файла одновременно с назначением прав и речи не идет.. Это никак нельзя обойти (в смысле применить назначенные права уже в текущем сеансе)?

А у вас DC с Active Directory или нет ? Если да то зачем париться bat-никами или еще чем то? Введите свою учетку Администратора в группу Local Admins и логируйтесь на компьютерах user-ов под своей АДМИНСКОЙ учеткой. »

У нас одноранговая сеть... увы :(

[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 я все же склоняюсь к тому что нормальное разделение полномочий все же более правильное и безопасное решение чем предложенное вами.