none
Удаление записей из RunOnceEx под правами пользователя RRS feed

  • Общие обсуждения

  • Ситуация:
    необходимо запускать некий таск в масштабе домена(Windows2003) на всех Рабочих Станциях(РС) (например, запуск блокнота), чтобы он запускался ЕДИНОРАЗОВО в пользовательской сессии(необязательно дожидаться завершения запуска\выполнения таска). Пользователи без прав администратора на своих РС. На РС стоят Windows 2000 Prof 4SP, Windows XP SP2,3

    Сделал следующее:
    на раздел HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx во всем домене с помощью GP даем права на всех РС локальной группе "Пользователи"
    Разрешить: Запрос значения, Перечисление разделов, Уведомление, Чтение разрешений, Удаление
    права на Задание значения раздела , Создание подраздела не даем из соображений безопасности(чтоб вирусы под пользователем не прописывались)
    создаем подраздел HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\!UserTask
    в нем создаем строковой параметр UserTaskExe  со значением Notepad.exe
    права на вложенные подразделы RunOnceEx унаследованы

    Получаем по факту:
    таск выполняется(блокнот при логоне запускается), но !UserTask\!UserTaskExe не удаляется
    и что более интересно, на ряде машин таск выполняется успешно, а на ряде машин нет (по настройке и  состоянию машины единообразны)

    Аудит по данной ветке реестра(на ПК, где не удаляется):

    Открытие объекта:
         Сервер объекта:        Security
         Тип объекта:        Key
         Имя объекта:        \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\!UserTask
         Код дескриптора:    -
         Код операции:        {0,182525}
         Код процесса:        1892
         Имя файла рисунка:    C:\WINDOWS\system32\rundll32.exe
         Основной пользователь:    zutest
         Домен:            TEST
         Код входа:        (0x0,0x280BC)
         Пользователь-клиент:    -
         Домен клиента:        -
         Код входа клиента:    -
         Доступ        READ_CONTROL
                Запрос значения раздела
                Задание значения раздела
                Создание подраздела
                Перечисление подразделов
                Уведомление об изменениях подразделов
         Привилегии    -
         Счетчик ограниченного SID: 0


    Вопрос в следующем:
    Почему процессом запрашиваются такие привилегии(Задание значения раздела,Создание подраздела), хотя прав Удаления вполне достаточно?
    И как решить поставленную задачу

    Рассмотрю все варианты решения проблемы
    Решение с помещением таска в раздел RunOnce отпал сразу, т.к. таск из вложенного подраздела вообще игнорируется для запуска(подраздел с именем Setup тоже пробовал), а если размещать таск !UserTaskExe в корень RunOnce, то он также запускается, но не удаляется потом

    Заранее спасибо

    27 января 2009 г. 9:17

Все ответы

  • Что вы такое интересное задумали?

    Нельзя ли просто запустить "notepad" из logon скрипта?

    27 января 2009 г. 9:53
  • И добавлю еще такое общее замечание. Кроме детальных разрешений, важно еще то, как написана программа, осуществляющая модификацию в файловой системе или в реестре. Например, если программа проверяет перед удалением чего-либо, есть ли у пользователя разрешение Full Control, никакими детальными разрешениями ее не "переубедишь", что она может удалить это и без полных разрешений. К сожалению, эта особенность встречается довольно часто.

    27 января 2009 г. 9:59
    Модератор
  • В данном случае нельзя (выбрано именно такое решение)
    вариант со стартап и логон скриптами не подходит
    т.к.  задачу в реестр прописывает сторонняя программа, со своей периодичностью и избирательностью кого подписывать (речь про инвентаризацию ПК)
    к тому же если реализовывать логику через тот же логон скрипт, то это резко замедлит загрузку ПК(там идет обращение к БД), в нашем случае логика вся происходит на стороне приложения.

    27 января 2009 г. 10:14
  •  osr. написано:

    И добавлю еще такое общее замечание. Кроме детальных разрешений, важно еще то, как написана программа, осуществляющая модификацию в файловой системе или в реестре. Например, если программа проверяет перед удалением чего-либо, есть ли у пользователя разрешение Full Control, никакими детальными разрешениями ее не "переубедишь", что она может удалить это и без полных разрешений. К сожалению, эта особенность встречается довольно часто.


    Речь, по-моему, несколько о другом
    я говорю не о какой-то программе, а об стандартном функцонале OS Windows
    в привилегию "Удаление" входит возможность удалять значение, подраздел из реестра
    в нашем случае этого не происходит, а требуются еще дополнительные привилегии "Задание значения раздела","Создание подраздела".
    Вопрос, почему?
    или я не так трактую эти привилегии? поправьте
    27 января 2009 г. 10:41
  •  

    А почему бы эту задачу не сдать на RonOnce в ветку HKCU и распространить политиками? Почему именно HKLM?
    27 января 2009 г. 11:30
  •  Vadims Podans написано:
    А почему бы эту задачу не сдать на RonOnce в ветку HKCU и распространить политиками? Почему именно HKLM?


    Потому что на момент подписания таска в реестр, на ПК может быть еще никто не залогинился или может быть залогинен другой пользователь(например сисадмин временно зашел настоить\установить что-то) и задача пропишется ему в RunOnce, а он больше не будет логиниться на этот ПК.
    Для данной задачи не нужно зависеть от текущего залогиневшегося пользователя, поэтому и принято решение писать в HKLM
    27 января 2009 г. 13:03
  • ещё раз: задаёте в групповой политике значение реестра, назначаете этот ключ на OU или домен (как больше нравится). И все, кто залогонится на машину после применения политики получит этот ключ. И то, что вы объяснили - на объяснение не тянет, поскольку вы не ту задачу решаете. Ещё раз обратимся к задаче:

    необходимо запускать некий таск в масштабе домена(Windows2003) на всех Рабочих Станциях(РС) (например, запуск блокнота), чтобы он запускался ЕДИНОРАЗОВО в пользовательской сессии(необязательно дожидаться завершения запуска\выполнения таска). Пользователи без прав администратора на своих РС. На РС стоят Windows 2000 Prof 4SP, Windows XP SP2,3

    я до сих пор не вижу причины использовать HKLM ветку.

    27 января 2009 г. 14:16
  •  Vadims Podans написано:

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

    необходимо запускать некий таск в масштабе домена(Windows2003) на всех Рабочих Станциях(РС) (например, запуск блокнота), чтобы он запускался ЕДИНОРАЗОВО в пользовательской сессии(необязательно дожидаться завершения запуска\выполнения таска). Пользователи без прав администратора на своих РС. На РС стоят Windows 2000 Prof 4SP, Windows XP SP2,3

    ситуация описана правильно, но в нашем случае логика записи ключа в реестр слишком громоздкая и времязатратная(требуются обращения к БД, с дальнейшим анализом). Посему принято решение логику отрабатывать на стороне другово приложения, а конечным ее результатом является единственная запись в реестр RunOnce  или RunOnceEx

    (другими словами программа закладывает таск на следующую загрузку ПК)


     Vadims Podans написано:
    я до сих пор не вижу причины использовать HKLM ветку.


    возможно Вы невнимательно читаете, я уже детально описал почему пришел к решению с HKLM
    а вопрос был в том, почему привилегии на доступ к реестру не отрабатывают должным образом. В частности, привилегия "Удаление" не позволяет удалить ключ\подраздел из реестра при логоне пользователя.
    Хотя права у пользователя все же есть, и в ручную пользователь все же может удалить этот ключ\подраздел

    Возможно проблема в распределенной загрузке ОСи
    27 января 2009 г. 15:15
  • Смотрите, дети, и учитесь - феерический пример, какие глупости придумывать НЕЛЬЗЯ.

    27 января 2009 г. 18:27
    Отвечающий
  • давайте начнём с начала:

    необходимо запускать некий таск в масштабе домена(Windows2003) на всех Рабочих Станциях(РС) (например, запуск блокнота), чтобы он запускался ЕДИНОРАЗОВО в пользовательской сессии

    данная задача решается занесением ключа в раздел RunOnce куста HKCU. Всё, что вы говорите - пока что совешенно не обязывает использовать куст HKLM и не препятствует возможности использования куста HKCU.

    27 января 2009 г. 18:45