К сожелению  просматрев  все темы так и не нашол вопросы на свой ответ
1)что имеем
Контролер домена win 2003
рабочие тачьки с winxp pro

Вроде все парвильно сделали
завели юнит  прикрепили к нему GPO
изолировали чтб не перекрывало DGPO

GPresult показывает что
применяет к машинке и пользователю только  My GPO  которое назначенно на юнит

пользователи являются членами
глобальной группы mygroup
концуперы же my com group

ну и поехали полисить

но ....
1) как  разрешить пользователю инсталировать программы  и ставть дрова
чтоб был типа админа но не совсем .
И чтоб без всякого экстрима типа назначить ему группу Domain Admin

К тому же  как я заметил некоторые настройки для концупера и пользователя
перекрываются .
И для применения некоторых настроек
не достаточьно  GPUpdate /force
Может кто знает знает ссылки на толковые FAQ  по этой теме   было бы очень интересно пчитать ...
Заранее Большое Спасибо !!!

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

Что занчит без всякого экстрима?????
Администраторы домена - есть администарторы домена, *в любом месте домена AD.да перекрываются. приоритет у комьютерных.

например?
сюда Designing Organization-wide Policies
Group Policy Processing
даже лабораторные есть TNT1-08 - Troubleshooting Group Policy Objects in Windows 2000 (Level 200)

Да на локальном все понятно
но трабла в том
что в отличии от локальной
в домене есть только
domain admin
и domain user
и ни каких domain power user

если кто то знает как это реализовать  ?
я конечьно не очень разбираюсь в тонкостях  назначения прав
в виндах на уровне системы
если это делается черезх реестр
то может  просто выставлять нужные  флаги при загрузки GPO
и тогда юзверь  получит свои права power user-а
хотя я так и не нашол  этих разделов

Можно конечьно повключать пользователей в  domain admin
и навесить им  GPO  
но насколько будет  эфиктивны настройки  GPO  
если пользователь  включен в привелигированую группу не извесно.
например будет ли работать запрет на  изменение  настроек сети

GPUpdate   не срабатывает на некоторые изменения в привелегиях конпьютера
так что приходится перегружать  
хотия по другому как мне сказали не сделать  

Sj

Значит так.
Первое - все пользователи - это domain user - и не больше!! - запомни это как отче наш! и отступать от этого правила можно только тогда, когда начнешь что-то *понимать в *политиках безопасности,
но не сейчас.
Затем- делаешь каждого пользователя, администратором на своей машине (т.н. "Локальный админ") (это можно сделать локально или централизованно  - написав скрипт - об этом ниже), затем в домене создаешь OU и включаешь(перемещаешь!) туда всех этих юзеров. *Привязываешь к этому unit - политику, где в "Конфигурации *пользователя- административные шаблоны - виндовс компонент-Microsoft *Management Console"- по самое не хочу, урезаешь возможности управления машиной - в том числе и невозможность, не то что изменения, но и даже просмотра локальной политики, диспетчера устройств, управления дисками, сервисами и тд. Там же - под административными шаблонами в разделе Network можно запретить всё, что касается сетевых наcтроек. После того как создашь всё это зверство - не забудь в настройках политики указать - "не перекрывать", чтобы она не переписалась локальной политикой
После этого для пользователей *жизнь медом не покажется! Так им и надо!

И еще- чтобы особо умные пользователи не вошли локально (т.е. не в домен) и по злобе не выкинули domain admins из локальной группы Администраторы - советую поменять им всем пароли на аккоунт "администратор". *Это можно сделать локально, либо написав скрипт ("net user администратор newpassword") и назначить его для выполнения в той же групповой политике, причем уже не для пользователей, а для машин.
Теперь пользователь сможет войти только с доменным аккоунтом, имеющим привилегии локального админа и *для которого мы обрезали все возможные права. что и требуется в большинстве случаев.
И никаких доменных админов! кроме себя любимого, естесственно.

И еще пару слов. Всё вышеописанное работате в среде домена W2000 (w2003 тоже конечно), где клиентами выступают машины с w2k&XP и режим - native mode
Это не означает, что, например с клиентами NTws или в mixed моде , ничего работать не будет. Просто в таких случаях потребуется дополнительная настройка и не все будет достижимо без использования ресурс кита.
Тоже самое касается и клиентов W9# , но там уже все совсем по-другому


[s]Исправлено: mb, 23:23 21-03-2004[/s]

с тем же самым успехом можно при помощи скрипта на локальных компьютерах добавлять пользоватлей сразу в группу Опытных пользователей (Power Users), а не администарторов.

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

mb
основной режим тут при чем у вас? как он сказывается или влияет на те вопросы которые вы затронули? Те я имею ввиду что изменися если режим останется "смешанным" ?

Это означает только то, что все о чем я написал, я сам проверил именно в этом режиме и именно с этими клиентами.  А например в mixed mode  я этого не проверял, и не уверен на 100%, что там все будет также легко работать , хотя..

=) ну я так и понял..
основной режим разрешает универсальные группы безопасности, вложения групп и несколько изменяет разрешения для prewindows 2000 (кажется просто убирается группа ВСЕ из нее, тем самым сокращая права)

кстати, вот такой сценарий писать: net user администратор newpassword это слабая защита от особо умных пользователей, тк все это хранится в открытом виде. Ну например попробуйте выполнить поиск по слову Администратор или уж net user - и, скорее всего, вы найдете ответ на вопрос о пароле =))
Нельзя запретить локальным администраторам изменять челнство в их группе. Но если они будут выкидывать Администраторов домена - то это уже, извините, беспредет и решается административными методами и наказываться должен как подрыв безопасности.. если не помогает, "сверх умных" просто убирать из локальных администраторов.

Администратора домена никак нельзя ограничить.. никак.
просто пишется скрипт на подобии: net localgroup administrators domain\administrators /add  и назначается на старт компьютеров. Т.о. каждый раз при загрузке компьютера администраторы домена восторжествуют..
или другой вариант - через групповую политику - группы с ограниченным доступом - добавить новую запись Administrators (или Администраторы для локализованных клиентских ОС) и указать что членами этой группы должны всегда являться domain\administrators (или domain\администраторы, если ДК - локализован). НО!!! следует быть осторожным и для подобных настроек создавать новый объект групповой политики и прилинковывать его на отдельные организационные подразделения (с объектами компьютер  на которых работают "умные" пользователи), тк притакой настройке ограниченной группы на всех компьютеры, которые попадут под действе этой политики в локальной группе администраторы останутся только локальная учетная запись Администратор (ее удалить никак нельзя) и та группа, которую вы казали - те domain\administrators, а все остальные учетные записи будут выброшены из локальных админов. В этом неудобство этого подхода.

SkyF
ну разумеется! только кто ж им даст посмотреть?
ведь этот *скрипт мы назначаем машине а не пользователю (я об этом писал) и выполняется он до логона, а пользователю фиг с маслом в виде запрета чтения на соответствующий скрипт

Иногда бывает! - именно из числа особо умных - разумеется их надо пороть в первую очередь административными методами, не давать мороженого, например и *т.д., но *иногда бывает полезно проучить и другими способами, о которых мы с вами и пишем (net localgroup - себя в админы и net user -сменить пароль действующего локального админа) *и рестриктед груп конешно

ps. И все же про *mixed mode ( а ведь по умолчанию, после dcprom именно этот режим, native потом нужно специально устанавливать и у многих он так и стоит-на всякий случай- поскольку опреация необратимая), *я что-то читал нехорошее, в смысле применимости *групповых политик, только не помню где и не помню что:)

[s]Исправлено: mb, 2:11 22-03-2004[/s]

вы удивитесь, но эти файлы сценариев лежат в папке SYSVOL на ваших доменных контроллерах.
примерно тут: \\dc1\sysvol\your.domain\policies\{}\machine\scripts
или где-то рядом, не помню сейчас уже.

я же говорю выполните поиск просто в каталоге \\dc1\sysvol я сразу просто не указал где искать..

SkyF
ну почему ж я удивлюсь-то? Именно на контролллере, именно в сисвол, лежит какой- нибудь файл типа addusr.bat с явным запретом в Ntfs для просмотра всеми домен юзерами - в  третий раз повторяю они предназначаются не для пользователя а для машины и выполняются под аккоунтом system. Попробуйте его просмотреть из под аккоунта какого-нибудь васи пупкина и не то что прсомотреть а просто скопировать. Нен уверен что получится.