Автор Тема: Проблема с правами администратора у пользователя, который входит в группу, включ  (Прочитано 8782 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Ильяс

  • Новичок
  • *
  • Сообщений: 9
  • Рейтинг: 0
    • Просмотр профиля
Сервер Windows Server 2008 R2, рабочие станции Windows 7.
Требуется, чтобы аккаунт HelpDesk был локальным администратором на рабочих станциях домена, но не на серверах. Для этого создается следующая групповая политика и применятся на контейнер с рабочими станциями.



Эта политика работает, доменный аккаунт HelpDesk, как и встроенный локальный Администратор, являются администраторами на компьютерах пользователей.
Затем возникает задача дать некоторым пользователям права администратора на их машинах. Просто добавить их в локальную группу «Администраторы» нельзя, потому что вышеуказанная групповая политика постоянно применяется и жестко задаёт список этой группы, убирая все изменения.

Рассматривается вариант отказаться от применения политики на интересующие нас компьютеры и дать админские права учетной записи пользователя. Но тогда теряется контроль над локальный группой «Администраторы». Самоуверенный пользователь легко может удалить оттуда всех, кроме себя, а нам бы этого не хотелось.

Рассматривается вариант когда все пользователи, которые должны быть локальными админами на своих компьютерах, добавляются в одну группу безопасности, эта группа становится членом группы «Администраторы» на всех рабочих станциях, а пользователям-админами вводится ограничение «Вход на…» только их компьютеры. Однако и этот вариант не слишком удобен, ведь приходится каждый раз править свойства пользователя, когда ему надо сменить компьютер или залогиниться с другой машины.

Рассматривается вариант, что для каждого пользователя-администратора создаётся отдельная групповая политика, в которой пользователь добавлен в группу «Администраторы», и эта политика применяется только на компьютеры этого пользователя. Этот вариант принимается и начинается работа по этой схеме. Однако быстро выясняется, что создавать отдельный контейнер и GPO на каждого пользователя-администратора быстро надоедает, да и количество групповых политик начинает быстро расти и захламляет список политик. В общем, вариант работает, но хотелось бы чего-нибудь получше.

Задача формулируется так, чтобы HelpDesk всегда был членом группы «Администраторы», но пользователя можно было сделать и оставить админом на своем компьютере без какой-либо правки AD или GPO.
Возникает идея использовать свойство «Групп с ограниченным доступом», когда вместо жесткой установки списка администраторов, мы просто добавляем определенную группу безопасности к группе «Администраторы» (отдельного пользователя добавить нельзя).

Создается глобальная группа безопасности «Локальные администраторы», туда добавляются Администраторы Домена и HelpDesk. Делается вот такая политика:


Политика вроде бы работает, по крайней мере в консоли «Управление компьютером» группа «Локальные администраторы» совершенно верно находится в группе «Администраторы». Однако возникает проблема.

Если зайти под обычным пользователем и попробовать запустить программу (или ввести изменения в настройки ОС), то выдаётся диалог UAC. При попытке ввести учетные данные пользователя HelpDesk, который входит в группу «Локальные администраторы», которая входит в группу «Администраторы», выдаётся ошибка «Операция требует повышения» и заново появляется запрос учетных данных. Если ввести учетные данные обычного локального Администратора, то все проходит удачно. Более того, если полноценно залогиниться под учеткой HelpDesk (а не пытаться запускать ПО от ее имени), то администраторские права отрабатываются без проблем и HelpDesk прекрасно все запускает.

Итак, вопросы к вам, уважаемые коллеги:
1)   В чем может быть причина того, что не удается запустить программы от имени HelpDesk под другим пользователем?
2)   Есть ли у вас какие-нибудь альтернативные идеи по упрощению схемы добавления пользователей в список локальных админов, с минимальными усилиями и без потери контроля надо локальной группой «Администраторы»?

Оффлайн shs

  • Модератор
  • Ветеран
  • *****
  • Сообщений: 4401
  • Рейтинг: 89
    • Просмотр профиля
    • ShS's blog
  • Откуда: Default city
Политика вроде бы работает, по крайней мере в консоли «Управление компьютером» группа «Локальные администраторы» совершенно верно находится в группе «Администраторы». Однако возникает проблема.

Если зайти под обычным пользователем и попробовать запустить программу (или ввести изменения в настройки ОС), то выдаётся диалог UAC. При попытке ввести учетные данные пользователя HelpDesk, который входит в группу «Локальные администраторы», которая входит в группу «Администраторы», выдаётся ошибка «Операция требует повышения» и заново появляется запрос учетных данных. Если ввести учетные данные обычного локального Администратора, то все проходит удачно. Более того, если полноценно залогиниться под учеткой HelpDesk (а не пытаться запускать ПО от ее имени), то администраторские права отрабатываются без проблем и HelpDesk прекрасно все запускает.
Странное поведение. По идее, все должно отработать нормально, так как вы задумывали (Вы не пробовали повторить неудачный эксперемент с запуском от имени члена группы "локальные администраторы", после " полноценного логина"?). Если бы передо мной стояла такая же задача то я бы действовал именно таким образом.

Единственное, что потребовлось бы учитытвать, так это то, что политики Restricted groups, определенные в различных GPO не складываются, а побеждает только одна из них.

Цитировать
If you create multiple Restricted Groups policies for the same group in multiple GPOs, only one policy will take effect. Restricted Groups policies for the same group do not merge across GPOs. The effective policy is determined by the order of the Group Policy processing. For information about Group Policy hierarchy and processing order, visit the following Microsoft Developer Network Web site:
http://msdn2.microsoft.com/en-us/library/aa374155.aspx
(http://msdn2.microsoft.com/en-us/library/aa374155.aspx)
For example, as illustrated in the following table, two Restricted Group policies are defined for Domain Admins. One is defined at the domain level and adds Domain Admins to the local Administrators group. The other is defined at the OU level and adds the Domain Admins group to My Regional Division Admins. Domain Admins will only be added to My Regional Division Admins (by default, GPOs that are linked at the OU level override those that are defined at the domain level).
http://support.microsoft.com/kb/810076/en-us

Оффлайн Ильяс

  • Новичок
  • *
  • Сообщений: 9
  • Рейтинг: 0
    • Просмотр профиля
Вы не пробовали повторить неудачный эксперемент с запуском от имени члена группы "локальные администраторы", после " полноценного логина"?
Пробовал, эксперимент проходил успешно. На этом компьютере после однократного логина HelpDesk программы с админскими правами от его имени запускались удачно. Однако такая необходимость предварительно осуществлять логин удивляет и напрягает.

Оффлайн shs

  • Модератор
  • Ветеран
  • *****
  • Сообщений: 4401
  • Рейтинг: 89
    • Просмотр профиля
    • ShS's blog
  • Откуда: Default city
Вы не пробовали повторить неудачный эксперемент с запуском от имени члена группы "локальные администраторы", после " полноценного логина"?
Пробовал, эксперимент проходил успешно. На этом компьютере после однократного логина HelpDesk программы с админскими правами от его имени запускались удачно. Однако такая необходимость предварительно осуществлять логин удивляет и напрягает.
Рискну предположить, что, возможно, такое поведение связано с наличием/отсутствием закешированного профиля пользователя, от имени которого вы пытаетесь застартовать приложение. Например, если на проблемном компьютере существует профиль пользователя, ныне входящего в группу "локальные администраторы", и этот закешированный профиль был создан еще тогда, когда данный пользователь еще не являлся членом данной группы, то, при отсутствуии связи с доменом, вход будет произведен с закешированными реквизитами, ЕМНИП. Вариант, скажем, несколько фантастический, но ничего другого, что могло хоть как-то объяснить подобное поведение, мне в голову не приходит. Попробуйте поэксперементировать с командой runas (у нее есть параметры /profile /noprofile).
А есть ли что-либо подозрительное в логах проблемной машины?

Оффлайн Dr.Night

  • Старожил
  • ****
  • Сообщений: 997
  • Рейтинг: 22
  • Пол: Мужской
    • mikhail.penkov
    • Просмотр профиля
  • Откуда: ( ω )
2)   Есть ли у вас какие-нибудь альтернативные идеи по упрощению схемы добавления пользователей в список локальных админов, с минимальными усилиями и без потери контроля надо локальной группой «Администраторы»?
последний вариант не только подходящий, но и многократно опробованный. Это то, что нужно.
На этом компьютере после однократного логина HelpDesk программы с админскими правами от его имени запускались удачно. Однако такая необходимость предварительно осуществлять логин удивляет и напрягает.
Есть предположение, у Вас при логине пользователя Helpdesk обязательно  должно что-то происходить. Например, скрипт запуститься, программа отработать или установиться, настройка создаться, диск подключиться, сервис SCCM или какого-то мониторинга отработать  и т.п. 
И какое-то из этих действий мешает.
найдите все, что запускается при логине пользователя Helpdesk и поотключайте по очереди.
There are ten kinds of people in the world - those who understand binary and those who don't

Оффлайн Ильяс

  • Новичок
  • *
  • Сообщений: 9
  • Рейтинг: 0
    • Просмотр профиля
Решили просто менять пароль локальной учетной "Администратор" и сообщать пользователю. Не идеальный вариант, но компромиссный.