none
Не применяется GPO для группы RRS feed

  • Вопрос

  • Имеется групповая политика "1С", назначенная для нескольких OU. До сего дня все пользователи в этих OU входили в группу "1С". Теперь появился пользователь, не входящий в группу 1С и для него нужно отключить политику "1С". Что я делаю: захожу в Group Policy Management, нахожу мою политику и в Security Filtering вместо "Прошедшие проверку" ставлю "1С". В результате политика прекращает применяться вообще: ни на пользователей 1С, ни на других пользователей.

    На локальной машине запускаю rsop.msc, и вижу, что моя политика действительно не применяется. Проверяю доступ к папке, где лежит политика, - доступ есть.

    Возвращаю "Прошедшие проверку" в Security Filtering - всё снова работает.

    Кто-нибуть подскажет, в чём может быть дело?

    8 января 2011 г. 17:07

Ответы

  • <...> Дело в том, что когда Вы удаляете Прошедших проверку из Security Filtering, никто не имеет возможности чтения этого GPO. <...>

    Это не так. Не путайте "чтение" ("read") и "применение" ("apply").

    //  почему у этой группы, судя по скрину, нет возможности стать глобальной? <...>
    Наверное потому, что домен у автора темы функционирует в смешанном режиме.

    Юрий, по поводу Ваших проверок. Учитывайте, что в общем случае, членство пользователя в группе "выясняется" на "момент входа" ("login"), т.е. если изменили членство в группе для пользователя и ожидаете, что применится фильтр ОГП, основанный на этом членстве, то пользователь должен зарегистрироваться в системе после изменения членства в группе. Важно "дождаться" репликации раздела домена, т.к. ОГП по умолчанию изменяются на PDC, а пользователя может "обслуживать" другой контроллер.

    // Вот и вероятная причина (уже сам увидел): группа "1С" является "локальной в домене". По-этому она не отображается в gpresult (хотя пользователь является членом этой группы) и, по логике вещей , не применяется одноимённая политика. <...>

    Тип группы безопасности здесь роли не играет.

    Пользователей все же лучше объединять в группы глобальные.



    10 января 2011 г. 20:07
    Отвечающий

Все ответы

  • Попробуйте в групповой политике, при Security Filtering = 1С ещё перейти на вкладку Security и добавить туда Прошедшие проверку. Дело в том, что когда Вы удаляете Прошедших проверку из Security Filtering, никто не имеет возможности чтения этого GPO. Также напишите, пожалуйста, результаты команды GPRESULT для пользователя, входящего в группу 1С при Security Filtering = 1С.
    Решаю проблемы...
    9 января 2011 г. 10:10
  • RSOP-результаты для DomainName\UserName на ComputerName : Режим журналирования
    --------------------------------------------------------------------------

    Тип ОС:                     Microsoft Windows XP Professional
    Конфигурация ОС:            Рядовая рабочая станция
    Версия ОС:                  5.1.2600
    Имя домена:                 DomainName
    Тип домена:                 Windows 2000
    Имя сайта:                  SiteName
    Перемещаемый профиль:
    Локальный профиль:          C:\Documents and Settings\UserName
    Подключение по медленному каналу?:        Нет


    Конфигурация компьютера
    ------------------------
        CN=ComputerName,CN=Computers,DC=DomainName,DC=local
        Последнее применение групповой политики:  09.01.2011 at 13:52:31
        Групповая политика была применена с:      ServerName.DomainName.local
        Порог медленной связи групповой политики: 500 kbps

        Примененные объекты групповой политики
        ---------------------------------------
            Default Domain Policy
            MySitePolicy

        Следующие политики GPO не были приняты, поскольку они отфильтрованы
        --------------------------------------------------------------------
            Политика локальной группы
                Фильтрация:  Не применяется (пусто)

        Компьютер является членом следующих групп безопасности:
        -------------------------------------------------------
            Администраторы
            Все
            Пользователи
            СЕТЬ
            Прошедшие проверку
            ComputerName$
            Компьютеры домена


    Конфигурация пользователя
    --------------------------
        CN=UserName,OU=Отдел снабжения,OU=MyDepartmentName,OU=Domain users,DC=DomainName,DC=loc
    al
        Последнее применение групповой политики:  09.01.2011 at 13:53:03
        Групповая политика была применена с:      ServerName.DomainName.local
        Порог медленной связи групповой политики: 500 kbps

        Примененные объекты групповой политики
        ---------------------------------------
            Default Domain Policy
            MySitePolicy

        Следующие политики GPO не были приняты, поскольку они отфильтрованы
        --------------------------------------------------------------------
            1C
                Фильтрация:  Отказано (безопасность)

            Политика локальной группы
                Фильтрация:  Не применяется (пусто)

        Пользователь является членом следующих групп безопасности:
        ----------------------------------------------------------
            Пользователи домена
            Все
            Пользователи
            ИНТЕРАКТИВНЫЕ
            Прошедшие проверку
            ЛОКАЛЬНЫЕ
            ПользователиКлиентБанка

    9 января 2011 г. 12:06
  • Вот и вероятная причина (уже сам увидел): группа "1С" является "локальной в домене". По-этому она не отображается в gpresult (хотя пользователь является членом этой группы) и, по логике вещей , не применяется одноимённая политика.

    Как теперь можно исправить ситуацию? Дело в том, что для группы "1С" заданы права целой кучи ресурсов, и создавать новую группу и вручную задавать такие права для неё - накладно. Можно как-то изменить свойство группы "1С" из "локальная в домене" на "глобальная" ? Или как-то автоматически копировать заданные разрешения файловой системы сервера на новосозданную, уже глобальную, группу?

    И ещё вопрос: как грамотно исключить применение моих политик на сервер? Например тех, что применяются к сайту, к которому принадлежит сервер? А также создать политику для всех рабочих станций домена, но не для сервера?

    9 января 2011 г. 12:14


  •     Пользователь является членом следующих групп безопасности:
        ----------------------------------------------------------
            Пользователи домена
            Все
            Пользователи
            ИНТЕРАКТИВНЫЕ
            Прошедшие проверку
            ЛОКАЛЬНЫЕ
            ПользователиКлиентБанка


    Этот пользователь не входит в группу 1С и политика не применяется.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    9 января 2011 г. 13:14
    Модератор
  • Вот и вероятная причина (уже сам увидел): группа "1С" является "локальной в домене". По-этому она не отображается в gpresult (хотя пользователь является членом этой группы) и, по логике вещей , не применяется одноимённая политика.


    Ну это перебор: локальные и глобальные группы не различаются, пока не вышли за рамки домена.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    9 января 2011 г. 13:16
    Модератор
  • Сдается мне, тут какая-то путаница с группами, возможно с названиями или с пониманием того, что мы называем доменной группой. Можно, пожалуйста, скриншоты группы из оснастки Active Directory пользователи и компьютеры?
    Решаю проблемы...
    9 января 2011 г. 19:02
  • Путаницы не вижу. Пользователь как раз входит в группу 1С, но она не отображается в списке групп по команде gpresult. Других причин, кроме той, что группа является "локальной в домене" а не "глобальной", я не вижу. Кстати с этой группой уже была проблема: не применялись разрешения на пользоваетелей, в неё входящих, для файловой системы рабочей станции. Решилось созданием отдельной группы, уже глобальной.

    Вот скрин: http://fotoifolder.ru/view_foto/y029s.p1z1g7/

    Решил заменить эту группу "глобальной" группой, вручную выставив права. Позже.

    Но вот задать политики только для рабочих станций (не для сервера) хочу красиво и правильно. Подскажите, пожалуйста, как грамотно это сделать? Есть две политики, которые не нужно применять для сервера (он всего один): политика сайта, в который входит также сервер, и политика "Default domain policy".

    10 января 2011 г. 17:14
  • А почему у этой группы, судя по скрину, нет возможности стать глобальной?
    Решаю проблемы...
    10 января 2011 г. 17:34
  • <...> Дело в том, что когда Вы удаляете Прошедших проверку из Security Filtering, никто не имеет возможности чтения этого GPO. <...>

    Это не так. Не путайте "чтение" ("read") и "применение" ("apply").

    //  почему у этой группы, судя по скрину, нет возможности стать глобальной? <...>
    Наверное потому, что домен у автора темы функционирует в смешанном режиме.

    Юрий, по поводу Ваших проверок. Учитывайте, что в общем случае, членство пользователя в группе "выясняется" на "момент входа" ("login"), т.е. если изменили членство в группе для пользователя и ожидаете, что применится фильтр ОГП, основанный на этом членстве, то пользователь должен зарегистрироваться в системе после изменения членства в группе. Важно "дождаться" репликации раздела домена, т.к. ОГП по умолчанию изменяются на PDC, а пользователя может "обслуживать" другой контроллер.

    // Вот и вероятная причина (уже сам увидел): группа "1С" является "локальной в домене". По-этому она не отображается в gpresult (хотя пользователь является членом этой группы) и, по логике вещей , не применяется одноимённая политика. <...>

    Тип группы безопасности здесь роли не играет.

    Пользователей все же лучше объединять в группы глобальные.



    10 января 2011 г. 20:07
    Отвечающий
  • Так и сделаю. Спасибо за коментарии.
    11 января 2011 г. 17:13
  • И как успехи?
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow MSTechnetForum on Twitter

    Посетите Блог Инженеров Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    14 января 2011 г. 8:43
    Модератор
  • Верните прошедших проверку, но уберите у них право на применение политики. и добавьте группу 1С, и только ей дайте права применения политики.

    Кстати - а политики то Вы хотите применить к ПК или к пользователю? а в группу 1С кто входит - ПК или пользователи?


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    14 января 2011 г. 10:11
  • >>>> Верните прошедших проверку, но уберите у них право на применение политики. и добавьте группу 1С, и только ей дайте права применения политики.

    Эффект тот же.

    >>>> Кстати - а политики то Вы хотите применить к ПК или к пользователю? а в группу 1С кто входит - ПК или пользователи?

    К пользователям.

    >>>> И как успехи?

    Нет пока времени. Нужно всё сделать тщательно. Проблемы с работой в 1С недопустимы. Но уверен, что это поможет.

    14 января 2011 г. 16:01
  • Пользователь как раз входит в группу 1С, но она не отображается в списке групп по команде gpresult.
    залогинтесь юзером и проверьте членство командой whoami /groups
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    17 января 2011 г. 14:20
  • По поводу глобальных групп, как и универсальных, позволю себе возразить. Я помню замечательное правило NT: User -> Global Group -> Local Group -> Resource (оно ещё как то красиво 4мя буквами обозначалось). Но в нём, начиная с 2000, есть свои минусы.

    Дело в том, что в билете безопасности Local Group занимает 4 байта, Global - 8 байт, и Universal - 12 байт. А если групп у Вас много (как у меня, например), Вам размера билета, даже максимального в 128К (который почему не стал работать в WIndow 7, пришлось укладываться в 64К) не хватит. Поэтому при выборе типа группы безопасности (только к ним относится) задумывайте и об этом факторе.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    18 января 2011 г. 12:21
  • // <...> Дело в том, что в билете безопасности Local Group занимает 4 байта, Global - 8 байт, и Universal - 12 байт <...>

    Сергей Сергеевич, Вы заблуждаетесь. Группы "занимают место" в PAC таким образом: локальная - 40 байт, глабальная и универсальная - 8 байт. При максимальном "размере токена" (ну, т.е. буфера, для размещения PAC) в 64 Кбайт (максимальное значение, не вызывающее ошибок в приложениях), в нем гарантированно "уместится" 1000 SID локальных доменных групп (они, как правило, существенно превалируют) и останестя достаточно место для групп глобальных и универсальных (не менее 100), а также для другой необходимой информации. PAC также наполнен специальными SID, вроде "Other Organization", но они занимают не так много места. Существенную часть места "неочевидно" может занимать SID-история и данные, сопутствующие делегированию.

    // <...> Вам размера билета, даже максимального в 128К (который почему не стал работать в WIndow 7 <...>

    У NT 5.0-6.1 максимальный размер буфера (LSA-MaxTokenSize) по умолчанию равен 12000 байт. Рекомендуется не устанавливать это значение более 65535, но в развитой/"мигрированной с историей SID" AD увеличить этот буфер LSA на всех членах домена будет полезным.
    Кстати, присутствует жестко заданное ограничение на 1024 SID (т.е. в общем случае пользователь не должен являться членом более 1000 +/- 10-15 групп, т.к кроме SID групп в токен вносятся специальные SID, вроде "Interactive Logon" и т.п., число которых обычно составляет 9-12) в маркере доступа, но это ограничение связано не с Kerberos, а с LSA. И, если это ограничение проявлеяется, то создание сесси/олицетворение пользователя становится невозможным (нельзя зарегистрироваться в системе).

    P.S. Буквы были такие: "A-G-DL-P", "A-G-U-DL-P". ;)

    18 января 2011 г. 20:35
    Отвечающий
  • Сергей Сергеевич, Вы заблуждаетесь. Группы "занимают место" в PAC таким образом: локальная - 40 байт, глабальная и универсальная - 8 байт.

    P.S. Буквы были такие: "A-G-DL-P", "A-G-U-DL-P". ;)


    Огромное спасибо за ответ. Буду крайне благодарен за ссылку на информацию про 40 байт. Мы правильно друг друга поняли - локальные доменные группы? Честно говоря, ради уменьшения размеров PAC я сознательно сценариями менял группы на локальные, благо домен один, лес и доверительные отношения не планируются. И если выяснится, что проделал эту работу зря... Как минимум, придётся всё вернуть на глобальные.

    У меня проблемы с PAC возникали многократно в следующих сценариях:

    - изначально при большом количестве групп возникали проблемы с контроллерами домена, с репликацией AD, но это было ещё на windows 2000 до sp3. Потом ситуацию разрулили увеличением размера PAC.

    - теперь эпизодически возникают сложности с входом в систему на рабочей станции, как правило - для учётных записей системных инженеров (которые доступ слишком ко многим ресурсам имеют). И такое огромное количество групп из-за соблюдения "красивого" правила: учётные записи -> группы учётных записей по орг. структуре, -> и далее по иерархии структуры -> по функционалу -> далее по иерархии функций -> пользователи или операторы приложений -> пользователи или операторы файловых ресурсов приложений, сервисов, члены групп, на которых осуществляется распространение приложений или его компонент через GPO+MSI. Причём натыкаюсь не на ограничение в размере PAC сейчас, а на 1024 группы, судя по всему.

    - на файловых серверах. их немного, все ресурсы файловые держат они, и им приходится формировать и держать PAC для всех 150+ пользователей. И при массовых операциях (конец рабочего дня, сохранение перемещаемых профилей пользователей) очень часто получаю "автономы" для ресурсов этих файловых серверов. При этом по результатам мониторинга очереди на дисках, в служе Сервер и так далее в пределах нормы, выгружаемый и невыгржаемый пулы также имеют запас. И приходится грешить на связь с контроллером домена, так как и пользователи, и контроллер домена по одному сетевому интерфейсу к файловому серверу путь имеют. Почему связываю - в эти "пиковые" периоды вырастает загрузка ощутимо (по мониторингу) DC, хотя опять-таки критических показателей нигде не поймал. Посему и предполагаю, что существует ещё и ограничение на общий размер всех билетов kerberos, которые в конкретный момент времени может удержать один сервер (в данном случае - файловый на базе windows 2003 std 32 bit). Время жизни билета выставлено в 10 часов, поэтому объяснить необъяснимую загрузку DC в этот пик могу только тем, что win 2003 вынуждена многократно запрашивать DC на предмет формирования билета для юзеров, так как не в состоянии удержать все билеты у себя.

    Имеет ли место подобное ограничение? Убил времени не один месяц, не нашёл информации по ограничению на суммарный размер билетов, которые в состоянии удержать один win 2003 std 32 bit. А проблема ощутимо мешает жить.

    P.S. ещё один ньюанс - все ресурсы в DFS, и корень DFS обслуживается тем же контроллером домена. Хотя время жизни ссылки DFS в кеше клиента также поднято выше 8 часов, поэтому не могу утверждать, что загрузка DC в конце "смены" объясняется загрузкой DFS.

    P.P.S за буквы - спасибо, надо будет запомнить. Давно было, уже забыл их совсем.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    19 января 2011 г. 6:34
  • Огромное спасибо за ответ. Буду крайне благодарен за ссылку на информацию про 40 байт. Мы правильно друг друга поняли - локальные доменные группы? Честно говоря, ради уменьшения размеров PAC я сознательно сценариями менял группы на локальные, благо домен один, лес и доверительные отношения не планируются. И если выяснится, что проделал эту работу зря... Как минимум, придётся всё вернуть на глобальные.
    http://support.microsoft.com/kb/327825/en-us - см. More Information
    19 января 2011 г. 7:37
    Отвечающий
  • Спасибо за ссылку.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    19 января 2011 г. 7:50
  • Уважаемый пользователь!

    В вашей теме отсутствует активность в течение последних 5 дней. При отсутствии каких-либо действий в течение 2 последующих дней, тема будет переведена в разряд обсуждений. Вы можете возобновить дискуссию, просто оставив сообщение в данной теме.


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow MSTechnetForum on Twitter

    Посетите Блог Инженеров Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    24 января 2011 г. 7:38
    Модератор