Global security group windows

Для человека, который сталкивается с многообразием групп в Active Directory, разобраться с ними сходу весьма трудно. Local и Domain Local, Global и Universal, Security и Distribution – всё это осложняется ситуацией “кого в кого можно включать”, и в финале сопровождается выводом “нафиг столько нагородили, уму непостижимо”. Добавляет к этому бардаку сочности то, что в фирменных курсах Microsoft данная тема освещается всё обзорнее и обзорнее – и сводится буквально к паре слайдов “запомните вот эту табличку”, без объяснения причин того, почему всё работает именно так.

Такой подход понятен – задача Microsoft – максимально удешевить чтение курсов, снижая требования по знаниям у MCT, которые обычно сами не могут объяснить, почему с группами в Windows / Active Directory всё сложилось именно так. Нужен меньший уровень знаний, чтобы вслух ртом начитывать сверху вниз слайды – можно меньше платить – ниже расходы – выше прибыль у партнёров Microsoft – больше партнёров – больше прибыли Microsoft. Приводит это к предсказуемому результату – тему “проскакивают” на бегу с логикой “зазубрите табличку, потом дампы почитаете чуток и проходной балл на экзамене кое-как перевалите, да вообще всё это некритично на самом деле”, а после работают с группами наощупь, а-ля “я на форуме читал, что всё надо делать security global, а у distribution SID’а вообще нет, ко-ко-ко”, ну и с подобными мифами. Табличка “кого в куда включать можно”, будучи не понятой, быстро забывается, а вся тема остаётся мистическим облачком “ой там всё мутно, нереально разобраться, да и не нужно никому”.

Как обычно, у нас подход другой. Разберёмся, что и как с группами. Вам понадобится базовая подготовка на уровне материала курса Microsoft 20410D – можете скачать бесплатно его запись у нас и посмотреть, там несложно.

Группы Windows NT и Active Directory – что, зачем, как, почему

• Часть первая – изначальная ситуация – одиночная система
• Часть вторая – домен Windows NT – появление Domain Local и Security-групп
• Лирическое отступление про максимальное количество групп и прочие технические мелочи
• Поведение системы при переполнении маркера доступа
• Часть третья – лес Active Directory – появление Universal-групп и разделения на Security и Distribution
• Universal-группы и режимы работы домена
• Можно ли жить в лесу Active Directory без Universal-групп, только с Global и Domain Local
• Проблемы масштабирования при использовании только Global и Domain Local
• Domain Local-группы и объекты Active Directory
• Миф про сниженное быстродействие Universal-групп
• Миф про одинаковость всех групп, потому что их можно друг в друга переключать

Приступим.

Часть первая – изначальная ситуация – одиночная система

Группы, как объекты, являющиеся участниками системы безопасности – т.н. “security principal” – появились в Windows NT изначально. Так же как и пользователи, группы имеют свой личный и уникальный в пределах системы идентификатор – SID (про них можно поподробнее почитать в статье про FSMO-роль RID Master).

Однако, даже на единичной системе групп уже есть два вида – это встроенные, например BUILTIN\Administrators, и дополнительно созданные – в моём случае это группа TestLocalGroup и некоторые другие:

Как отличить эти два типа групп? Исключая, конечно, то, что мне было лень писать description к тестовой группе, и она выделяется по этому признаку? Всё просто – у этих двух типов групп разные форматы SID’ов:

У встроенных это будет S-1-5-32-abc, где abc – идентификатор от 500 до 1000 (в теории, в реальности полтыщи встроенных групп в системе нет, их меньше полусотни). У обычных это будет S-1-5-21-yyy-zzz, где YYY – это идентификатор системы (его меняет, например, утилита sysprep), а ZZZ – это RID.

Встроенные группы будут стоять особняком – они нужны для предоставления прав учётным записям, исключительно – т.е. ни включать их друг в друга (эта операция будет называться group nesting), ни включать в них обычные локальные группы будет нельзя. Вы можете убедиться в этом, запросив на локальной системе список тех, кто может быть добавлен во встроенную группу:

Если что, ATRAINING-DEMO – это имя локальной машины, это обычная Windows 8.1, разве что на ней заведена учётка пользователя с именем Ruslan.

Т.е. задача этих групп – выдавать права тем или иным локальным пользователям или обладателям каких-то специфичных SID’ов в nt-маркере доступа – например, logon type’ов типа NETWORK или INTERACTIVE.

Возможность же создавать свои собственные группы на локальной машине нужна, чтобы предоставлять доступ к ресурсам – например, общим папкам. Вы можете создавать группы, и включать в них пользователей. Ранее, замечу, можно было включать локальные группы в локальные – для этого трюка нужна утилита net.exe и её контекст LOCALGROUP, но на данный момент этот функционал заблокирован и даже если вы сделаете так на NT 4.0 и проапгрейдите систему до современной версии, то все равно – lsass учитывает у локальных пользователей только группы, в которые они включены напрямую, т.е. в маркере доступа других групп не будет.

Зачем же в этой ситуации, когда можно было бы обойтись, по сути, простым критерием “RID меньше тысячи – значит, встроенная группа – а больше – значит, созданная пользователем”, делать разные форматы SID’ов? Нужно это было для того, чтобы обеспечить перенос ACL’ов между системами. Пример – у вас есть внешний диск, отформатированный в NTFS. Вы создаёте там структуру папок и назначаете права – в эту папку можно участникам группы Administrators, в эту – обычным Users. Если вы перенесёте этот диск на другую систему, то все ACL’ы будут читаемы – потому что SID’ы что Administrators, что Users – одинаковы у любой NT-системы. Но если вы создадите свою собственную группу, то такого никогда не случится – её SID никогда не совпадёт с SID’ом группы на другой системе, потому что включает компонент S-1-5-21-уникальный идентификатор системы-RID. Поэтому если вы создадите у себя локальную группу Special Secret Administrators, а на соседней машине создадут Puny Faggots, то неприятной ситуации, когда добавляли права доступа для участников первой, а при переносе оказалось, что права доступа появились у второй, т.к. SID’ы совпали – вот такой ситуации не будет в принципе.

У пользователей, замечу, такого разделения нет – они всегда привязаны к идентификатору системы:

Что ж, с локальной системой всё ясно и несложно. Теперь – следующий шаг – появляется домен Windows NT.

Часть вторая – домен Windows NT – появление Domain Local и Security-групп

Работа с группами в одиночной системе – штука простая. Сложности появляются, когда надо создать свой authentication domain – т.е. подмножество систем, которые признавали бы не только свои локальные базы security principal’ов (хранящиеся в реестровой ветке HKLM\SAM\SAM), но и некую центральную и общую БД учётных записей.

Если вы берёте систему на базе Windows Server и делаете её контроллером домена – т.е. говорите, что теперь её хранилище security principal’ов будет общим, и ему будут доверять другие системы – она понимает возложенную ответственность и решается на апгрейд своего Security Accounts Manager’а. Ведь одно дело, когда предполагается использование базы только на одной системе – а другое дело, когда на нескольких. Плюс, домены могут доверять друг другу через систему domain trust’ов – а, следовательно, надо ещё и учитывать то, что должна обеспечиваться уникальность security principal’ов в пределах произвольного числа доменов.

Если просто взять и сделать общим SAM локальной машины – сразу появятся конфликты тех же builtin-групп; например, как при идентичных SID’ах группы BUILTIN\Adminstrators на всех системах сделать свой SAM доступным для остальных? Что будет обозначать запись в маркере доступа на произвольной, включённой в домен, машине “входит в группу с SID = S-1-5-32-544” – это значит, что участник локальных Administrators или общих-доменных Administrators? Как решать ситуации с “из соседнего домена придёт группа с таким же SID’ом”? Ситуация требовала и расширения функционала, и введения ограничений – и это произошло.

Было сделано следующее – существующая ситуация со встроенными и обычными группами была усложнена до “Есть два сту вида групп – локальные для этого домена (Domain Local) и глобальные с возможностью ‘выхода наружу’, за пределы домена (Global)”. У Domain Local при этом остаётся разделение на BUILTIN, т.е. встроенных и изначально существующих в домене, и обычных, созданных администраторами. Было два типа групп – стало два с половиной – локальные встроенные, локальные обычные, и глобальные.

Новый тип групп, Global, сразу же был ограничен до “в него могут входить только учётки”. Вложения однотипных групп (т.е. Global в Global) в домене Windows NT не было, поэтому всё, зачем нужны Global-группы – собрать в них ресурсы по какому-либо критерию (например, подразделение организации) и добавить эту группу в чей-нибудь ACL. Например, у папки, или у принтера. У любого объекта NT-системы, в общем. Простой пример – сделать группу BUH, добавить туда учётки всех сотрудников бухгалтерии и выдать этой группе права на папку Otchet2016 на файл-сервере.

Существующий подтип Builtin Local получил ограничение – в силу того, что SID’ы его участников не содержат доменный компонент, групп этого типа не видно при просмотре с рабочих станций и серверов домена. То есть, если в домене есть рабочая станция, и у неё есть своя локальная группа Administrators, то конфликт с имеющимися на контроллере домена BUILTIN\Administrators разрешается просто – что в локальную группу на этой рабочей станции, что в любой ACL на любом объекте на этой рабочей станции – добавить доменных BUILTIN\Administrators не выйдет, их просто не будет видно. Выборка по “потенциально возможным к добавлению” не покажет Builtin Local’ов. Они существуют только на системах, которые разделяют между собой “выросший” локальный SAM самого первого сервера, который стал контроллером этого домена – то есть, на контроллерах домена.

Domain Local же, как наследники “обычных локальных групп”, данного ограничения не имеют – их SID ведь содержит компонент с идентификатором домена – а, следовательно, уникальность в сравнении с локальными группами каждой входящей в домен системы поддерживается. Поэтому вы можете добавить, например, в локальную группу Administrators группу из домена, у которой будет тип Domain Local – никакого потенциального конфликта тут не будет. SID’ы этих групп, кстати, не поменялись при превращении сервера в первый контроллер домена в новом домене – поэтому если вы, например, создали локальную группу и выдали ей права на какой-то папке, то после DC promotion эта группа станет Domain Local и все её права сохранятся – ведь SID тот же.

В итоге ситуация стабильна – каждый домен обладает уникальным идентификатором, есть специальный тип групп, у которых в SID’е всегда этот уникальный идентификатор есть (Global). Назначение групп тоже понятно – в Global добавляем учётки с прицелом “им можно хоть где угодно права раздавать, хоть в другом домене”, Domain Local используем для групп-заглушек на ресурсах, вида “SRV1 Buh-Otchet2016 RO” (Read-Only на общей папке \\srv1\BUH\Otchet2016).

Но потребности растут – и ситуация изменяется ещё раз.

Лирическое отступление про максимальное количество групп и прочие технические мелочи

Возможность создавать много групп и делать сложные схемы вложения одних в другие, безусловно, технически ограничена. В части ограничения количества объектов типа “группа” в домене всё упрётся в размер хранилища NTDS в Active Directory, а также в максимально возможное количество RID’ов в данном домене. Оба этих барьера трудно достижимы – наштамповать миллиарды групп всё ж задачка не из бытовых. Но есть ограничение, которое достигнуть можно – это вопрос про “во сколько групп может входить пользователь”.

Ответ на этот вопрос, за время развития Active Directory, несколько раз изменялся – давайте разберёмся, почему и как.

Первичное техническое ограничение на количество групп, в которых одновременно может состоять конкретный пользователь, вызвано тем, что при логине с использованием протокола Kerberos (его поддержка появляется в Windows NT 5.0 и в Active Directory с момента её создания) будет необходимо передавать по сети сведения о членстве доменного пользователя в группах. Протокол Kerberos по умолчанию работает с использованием транспортного протокола UDP (впрочем, переключаем на TCP начиная с Windows 2000), и теоретически возможный размер Kerberos-данных – это максимальный размер UDP-датаграммы минус заголовок пакета Kerberos. Получается чуть меньше 64КБ (65.5 тысяч байт). Вычитаем минимальный размер маркера доступа (это 1200 байт – это минимум, размер может быть чуть больше, если будет, например, очень длинный FQDN или UPN/SPN). Получаем примерно 62КБ (где-то 63 тысячи байт). Учитываем, что при работе с веб-сервисами, тем же IIS, использующим при работе метод Negotiate, содержимое токена надо будет передавать по HTTP, в Base64 (т.е. упаковывать всё в 6ти битовые символы). В результате получим уменьшение технологически возможного размера до примерно 47КБ (около 48 тысяч байт). Это, повторюсь, техническое ограничение при условиях:

• Наш Kerberos работает по UDP;
• Мы используем Negotiate в IIS как метод авторизации доменных учётных записей;
• Мы не тюнингуем Kerberos в плане доп.информации в заголовке и у нас учётка с нормальным именем (или хост с тривиальным по габаритам FQDN);

Поэтому операционная система, в частности встроенный в неё модуль поддержки Kerberos, имеет настройку, ограничивающую максимальный размер содержимого. Исторически этот размер, появившись в Windows 2000, был 8.000. В Windows 2000 Service Pack 2 он стал 12.000, а с Windows Server 2012 – 48.000. Вы можете его поправить, если что, простой настройкой параметра MaxTokenSize, который сейчас уже есть в стандартных групповых политиках (я предполагаю, что вы обновляете административные шаблоны у себя в домене):

Находится она, если что, в Computer Configuration \ Policies \ Administrative Templates \ System \ Kerberos, а называется Set maximum Kerberos SSPI context token buffer size. Учитывайте только, что это – именно максимальный размер самого содержимого токена, а не токена в смысле “весь керберосовский пакет”. Кстати, на KDC – т.е. на всех контроллерах – можно также выставить полезную настройку “журналировать события, когда токен не влез в указанные размеры”:

Находится она рядом с предыдущей в Computer Configuration \ Policies \ Administrative Templates \ System \ KDC, называется Warning for large Kerberos tickets.

Теперь добрались до связи всего этого с группами. Каждая запись о том, что данный security principal состоит в группе, занимает место. Больше всего места занимает запись о членстве в Domain Local-группе и в Universal-группе из чужого домена (об Universal чуть далее) – 40 байт. Запись о членстве в Global или Universal-группе своего домена занимает 8 байт. Используя эти данные, можно прикинуть, в каком количестве групп может состоять пользователь – это будет или 1200 Domain Local-групп, или 6000 Global-групп, или хз сколько Universal (зависит от того, из того же они домена, что и вы, или нет).

Но это будет ещё не очень точной прикидкой, потому что есть дополнительные факторы, влияющие на содержимое маркера доступа:

• SID History – если учётная запись мигрировала из другого домена, и этот атрибут не пустой, а содержит SID’ы групп из предыдущего домена, то они тоже занимают место в маркере;
• Delegation – если учётка trusted for delegation, то теоретический максимум можно делить пополам, т.к. в маркере будет 2 комплекта SID’ов;

Чтобы не замучаться поддерживать весь этот дремучий лес из различных ситуаций “много групп или не очень”, Microsoft выпустила статью про жёсткое ограничение количества групп до 1.015, и посоветовала не превышать число в 1.010 (хотя, как видно из вычислений, количество может быть в разы больше). Ситуация на некоторое время успокоилась – для спокойной работы можно выставить на уровне домена MaxTokenSize в 48.000 и не иметь никаких проблем (ещё лучше форсировать Kerberos на TCP-вариант, чтобы не натыкаться на ограничения размера UDP-датаграммы).

Помимо этого, в случае проблем с работой веб-сервисов, возможно, понадобится увеличить максимальный размер одиночного поля в HTTP-заголовке и одиночного запроса. По умолчанию они оба 16K, имеет смысл увеличить их хотя бы до 64К – это решит проблемы с ситуацией “большой маркер доступа и сбой 401.1 при авторизации на IIS” и в подобных:

Данная ситуация была стабильна до Windows Server 2012, в котором появилось сжатие токена – механизм Resource SID Compression.

Идея данного механизма чрезвычайно проста – “давайте от Domain Local-групп передавать только RID’ы”. Данным механизмом можно управлять, включая-выключая его для каждого конкретного DC:

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

Технически (я не буду углубляться в дебри кербероса, это чрезвычайно интересная, но масштабная тема) всё реализуется несложно – если KDC поддерживает сжатие, то он проверяет бит Resource-SID-compression-disabled в поле KerbSupportedEncryptionTypes у своей учётки и у учётной записи krbtgt; если нигде этот бит не установлен в единицу, то KDC формирует маркер доступа, заполнив в структуре KERB_VALIDATION_INFO поле ResourceGroupDomainSid SID’ом текущего домена, и добавляя поле ResourceGroupIds, указывающее на массив “укороченных” SID’ов (которые на самом деле просто RID’ы). В финале в поле ResourceGroupCount пишется суммарное количество записей, и всё готово.

Использование этого механизма способно очень серьёзно снизить затраты места в токене – вместо 40 байт для Domain Local расход падает примерно до 6 байт на группу, плюс заголовок структуры.

Так что если у вас все DC на базе Windows Server 2012, и вы не выключили этот механизм, то токен будет компактнее.

Что же произойдёт, если всё ж SID’ов групп окажется столько, что они не влезут в маркер доступа?

Поведение системы при переполнении маркера доступа

Начиная с Windows Server 2003, есть “аварийный сценарий работы”, нужный для ситуации “я доблестно добавил единственного администратора в домене в тьму групп, и теперь не могу им залогиниться”. Чтобы спастись в этом случае, надо зайти в режиме “Safe mode with networking” на любой DC, используя BUILTIN\Administrator – аварийный сценарий работает только для неё, с RID’ом = 500 – в этом случае в маркер будут добавлены только группы, в которые явно входит эта учётная запись – без вложенных, плюс только BUILTIN и Domain Local. И если групп много даже в этом сценарии, то lsass просто не будет добавлять те из них, которые не влезли – при том, начнёт добавление с:

• Everyone (S-1-1-0)
• BUILTIN\Users (S-1-5-32-545)
• BUILTIN\Administrators (S-1-5-32-544)
• NT AUTHORITY\INTERACTIVE (S-1-5-4)
• NT AUTHORITY\Authenticated Users (S-1-5-11)
• LOCAL (S-1-2-0)
• Domain\Domain Users (S-1-5-21-aaaaaaaa-bbbbbbbb-cccccccc-513)
• Domain\Domain Admins (S-1-5-21-aaaaaaaa-bbbbbbbb-cccccccc-512)
• NT AUTHORITY\This Organization (S-1-5-15)

Такой маркер сгенерить точно получится и вход администратора в аварийной ситуации сработает.

Надеюсь, я не сильно вас запутал, но, в общем, тема “во сколько групп может входить юзер”, как видно, весьма обширная и не ограничивается “в этой версии винды во столько, а в этой – во столько”, как иногда бездумно заучивают на авторизованных курсах Microsoft.

Продолжим про разновидности групп – статья вообще-то именно про это, а не про тонкости реализации Kerberos в современных версиях Windows Server.

Часть третья – лес Active Directory – появление Universal-групп и разделения на Security и Distribution

Active Directory добавляет целую пачку нового – теперь вместо одиночных доменов, связанных ниточками-трастами, есть пачки дружественных друг к другу доменов, называемые лесами. Появляется возможность изменять атрибуты объектов, хранимых в Active Directory, и создавать новые типы объектов. Все эти добавления нуждаются в изменениях в работе групп. Первым делом смотрим на новое разделение групп – на Security и Distribution.

Чем отличаются Security и Distribution группы

Миф про “у Distribution-групп нет SID’ов” – один из самых живучих. Его бездумно копируют преподаватели авторизованных курсов Microsoft, ни разу не работавшие с Active Directory в production и просто ни разу не интересовавшиеся, как оно вообще работает. Его копируют расплодившиеся в последнее время “архитекторы”, павшие жертвой подхода работодателей “давайте сисадмина Ваську переименуем в должности, чтобы зарплату не поднимать”. Его озвучивают набранные по критерию “амбициозный туповатый услужливый региональный сисадмин” сотрудники системных интеграторов, потому что “ребята из МС, эксперты, архитекторы, говорили”.

Технически же всё просто – Distribution-группы отличаются от Security (или, если быть точным, Security Enabled) групп одним битом в атрибуте groupType – у Security-группы этот атрибут будет содержать бит SECURITY_ENABLED:

,а у Distribution – нет:

Вы можете сколько угодно раз переключать группу из Security в Distribution, от этого её SID никуда не девается. Он и не может – ведь SID это атрибут всего класса объектов group, а не какого-то их подвида. Поэтому при создании объекта класса group SID разово создаётся, а смене типа с Security на Distribution – не стирается. Поэтому при переключении между Security и Distribution не запрашиваются новые блоки у RID Master‘а – операции “генерация SID для нового security principal” не происходит. Поэтому, если добавить группу в ACL какого-нибудь объекта, а потом переключить её в Distribution, она оттуда никуда не пропадёт – потому что в ACL записывается SID, а он у этой группы один, с рождения, и никак не зависит от типа группы.

Зачем же нужен этот новый тип группы, Distribution?

Этот тип нужен исключительно для вопросов оптимизации быстродействия и обеспечения безопасности. Смысл существования варианта Distribution – это “lite-version” обычной группы. Отсутствие бита SECURITY_ENABLED анализируется сервисом lsass в момент создания маркера доступа для сеанса пользователя, и доменные группы без этого бита просто не попадают в маркер.

Пример – есть большая фирма, у которой множество тематических групп рассылок. Например, у них внедрено управление проектами, и к каждой задаче привязан список рассылки “кого уведомлять при изменении связанных с задачей документов, или любом другом изменении”. Таких групп, если проектов много, у одного пользователя могут быть тысячи, а то и десятки тысяч. Если этот пользователь, например, является аудитором, которому надо знать про все изменения в ходе работ у N проектов.

Если это реализовывать через простое добавление пользователя во все эти группы, то при его входе – что на локальную рабочую станцию, что по сети – будет формироваться маркер доступа чудовищного размера, набитый SID’ами групп, которые – это ключевое – не применяются для назначения прав, а нужны лишь для упорядочивания списков рассылки. То есть эти группы изначально созданы только для одной задачи – и их никогда не добавят в ACL у общей папки или в локальную группу Administrators.

В результате получается, что при логине пользователя, добавляя SID’ы Distribution-групп, делается куча лишней работы, от этого замедляется вход в систему, а также создаются потенциальные риски безопасности – вдруг кто-то действительно возьмёт и на локальном сервере, где имеет права, добавит в ACL ресурса группу для рассылок? Тогда входящие в неё с одной целью (получать письма) получат совершенно не нужные права.

Добавление бита SECURITY_ENABLED решило оба этих вопроса – составляя маркер доступа, lsass разбирает вложения групп, и, если видит группу без этого бита – не добавляет её в маркер доступа, и идёт дальше. То есть добавить в ACL у общей папки или куда-либо ещё Distribution-группу можно – просто т.к. её SID не попадает в маркер доступа, то пользователь в неё с точки зрения Active Directory входит, но получить доступ на ресурс, где она в ACL – не может.

В официальной документации Microsoft содержится ошибка – Distribution groups are not security-enabled, which means that they cannot be listed in discretionary access control lists (DACLs) – вот никакого cannot be listed нет, вы можете проверить это, явно назначив Distribution группу в любой ACL.

Вот и всё. И весь “волшебный механизм”. Поэтому увидите “иксперта-архитектора” с рассказами о том, что у Distribution-групп нет SID’а – смейтесь над ним и унижайте его, обзывайте его дампером и характеризуйте его “знания” “бауманским качеством”. Показывайте ему SID у Distribution-группы, открыв вкладку Attributes, и выкладывайте в соц.сети реакцию – будет много просмотров.

Ну а мы, разобравшись с этим горе-битом, перейдём к новому типу групп – универсальным.

Зачем нужны Universal-группы

Universal-группы и режимы работы домена

Первым делом зафиксируем тот факт, что само по себе появление типа Universal связано с появлением лесов в Active Directory. Universal-группы – новый тип объектов, которого не было в домене Windows NT, поэтому чтобы этот тип групп появился, ваш домен должен быть в “native”-режиме – то есть без включённого признака “работаем в режиме совместимости с доменами Windows NT”. Это просто проверить – у корневого контейнера доменного контекста есть атрибут nTMixedDomain:

Наличие значения 1 у данного атрибута показывает, что домен работает в режиме совместимости с Windows NT – т.е. на владельце FSMO-роли PDC Emulator запущен сервис, который имитирует для старых контроллеров домена Windows NT (т.н. BDC) работу старого PDC. Этот сервис умеет брать содержимое Active Directory и “пережёвывать” его в понятный для Windows NT 4.0-контроллеров формат. Очевидно, что эти контроллеры ничего про Universal-группы не знают, поэтому в режимах работы домена “совместим со старыми Windows NT-системами” универсальную группу вам создать не дадут – ведь неясно, как в этой ситуации отправить BDC-контроллеру содержимое такой группы, или другой группы, в которую включена Universal. Такая ситуация возникнет лишь в двух старых режимах работы домена Active Directory – Windows 2000 Mixed и Windows 2003 Interim. Как только вы переключитесь в любой из “native” режимов работы домена – возможность создания Universal-групп появится. Впрочем, натолкнуться сейчас на домен, работающий в одном из этих двух режимов, достаточно сложно. Поэтому далее предполагаем, что у вас домен – как минимум Windows 2000 Native.

Итак, зачем же нужны Universal-группы?

Если вы домотали до этого момента, то, пожалуйста, перечитайте верхнюю часть ещё раз – потому что чтобы разово уложить новые сведения в голове, нужно понять всё предыдущее.

Можно ли жить в лесу Active Directory без Universal-групп, только с Global и Domain Local

Начнём с простого – без универсальных групп вполне можно жить. Т.е. Global и Domain Local покрывают все существующие задачи. Глобальные группы, как и было заведено изначально, нужны для консолидации учётных записей – разве что в домене Windows NT нельзя было делать group nesting, т.е. вкладывать глобальную в глобальную, а в Active Directory (речь про Native-режимы) – можно. Вложить в глобальную группу группу из другого домена – что Global, что Domain Local – нельзя, всё, ещё раз повторюсь, чётко – в глобальные вкладываем учётки из нашего домена и другие глобальные группы только из нашего домена.

Domain Local же наоборот – самый “гостепреимный” вариант – в них можно вкладывать и учётные записи, и глобальные группы из любого доступного через trusts домена. Можно даже другие Domain Local – но, как понятно, только из своего домена – ведь домены в силу ряда ограничений (см.начало статьи) не позволяют друг другу добавлять Domain Local из одного домена в члены Domain Local из другого.

Жить, таким образом, можно – собираем учётки по отделам-задачам в Global (например, в каждом домене делаем группы BUHGALTERIA и MARKETING). Эти группы добавляем в Domain Local’ы с названиями вида “SRV1 BUH-Otchets RO” (которым заранее раздаём соответствующие их названию права – этой, например, на файл-сервере SRV1 на общей папке BUH и подпапке Otchets разрешаем Read Only), и удобно управляем доступами для групп пользователей.

Сразу ответ на типовой вопрос “а можно ли вообще всё глобальными делать?” – в пределах одного домена – да, а как только доменов больше одного, то вы не сможете, “повесив” в ACL ресурса Global-группу, включить в неё Global-группу из другого домена, и придётся использовать “гостепреимную” Domain Local, в которую можно запихнуть кого угодно из какого угодно домена.

Но не всё так однозначно – будут и проблемы.

Проблемы масштабирования при использовании только Global и Domain Local

Так вот, основное веселье с ситуацией “используем только глобальные и домен-локальные” начинается, если доменов в лесу много. Тогда штука с “нельзя засунуть в Global из нашего домена Global из другого” сразу же всплывает. В этом случае, если надо будет создать группу вида “Все сотрудники фин.департаментов”, куда логично добавить группы вида “Accountants”, “Fincontrol”, “Finauditors”, то ничего не получится – технически это не реализуется. В результате Domain Local-группы, висящие на ACL’ах у ресурсов, начнут ощутимо тяжелеть, потому что там надо будет в явном виде перечислять все Global из всех доменов леса. Этот процесс вызовет и замедление обработки, и увеличение сложности обслуживания.

Более того, начнёт появляться проблема с логином. Суть её проста – при входе пользователя с использованием UPN-имени (по факту всегда; просто с UPN-именем нагляднее) DC обращается к GC, чтобы выяснить, что это за пользователь такой. Ведь UPN суффиксы уникальны в пределах леса, а не домена – т.е. у вас может быть лес с 8 доменами, в котором 3 UPN-суффикса, и по “хвосту” имени пользователя сходу сказать “да, он из такого домена” просто нельзя.

Обращаясь к GC, контроллер домена запрашивает вначале “кто это ко мне такой за составлением маркера доступа обратился”, а после, узнав кто это (т.е. получив SID по UPN’у), начинает составлять маркер доступа, вычисляя, в каких группах состоит данная учётная запись. Тонкость в том, что состав групп – т.е. поле member у Global и Domain Local, на GC не реплицируется, поэтому получив ссылку вида “Данный пользователь входит в группу Х”, контроллер домена находит у себя эту группу, и уже читая domain naming context, а не ответ GC, вычисляет, в какие группы в свою очередь входит она. Этот итеративный процесс “парсинга вложенных групп” вполне будет достаточно ёмким по количеству итераций и общему объёму.

Почему ж так странно сделали, спросите вы – ну т.е. почему на GC не реплицируется атрибут member у групп? Тонкость в том, что на момент разработки оригинальной версии Active Directory, в NT 5.0, не было механизма частичной репликации multivalued-атрибутов (т.н. LVR, Linked Value Replication). В результате, если бы у GC кэшировался этот атрибут, то для групп с большим числом участников (тысячи, а то и десятки тысяч), любое изменение приводило бы к запуску полной репликации всех GC леса. То есть ещё раз – есть лес с кучей доменов, в одном из них в одной из групп добавляется один участник – вот если бы GC кэшили member, то это заставляло бы все GC леса, во всех доменах, полностью перекопировать этот объект. Эта ситуация уходит с появлением NT 5.2, и уровня леса “Windows Server 2003”, но на момент выхода Active Directory это всё – критично. Каналы слабые (я помню, как регионы реплицировались по диалапу, поверх которого поднимался RRaS’овский VPN, и полоса составляла единицы килобайт), GC не на каждом контроллере (опять же из-за экономии, чтобы меньше репликаций было).

В результате имеем сложную ситуацию – логинящемуся пользователю надо собрать маркер, для этого надо распарсить “матрёшку” из “какая группа в какую вложена”, для этого надо бегать вначале на GC, чтобы узнать, кто логинится, а потом, узнавая в какие группы он включен, бегать за уточнениями “а кто в эту группу входит” уже на DC.

Всё это решается проще, если добавляется новый тип групп – универсальные.

Состав универсальной группы кэшируется на GC – то есть, обратившись к GC, можно получить из этого запроса список участников данной группы. Сразу, без беготни туда-сюда. Притом на любом GC леса есть все Universal-группы этого леса – поэтому можно, если имеет место вложенность одной в другую, сразу же разрешить это с одним GC – вся информация на нём есть.

Это быстрее – и именно поэтому, к примеру, когда вы читаете документацию на Exchange Server, то можете заметить, что почтовые группы предлагается делать Universal – тогда их быстрее можно “раскрывать” в плане состава, за одно обращение к ближайшему GC.

Да, изменение состава Universal-групп инициирует репликацию во всём лесу (и в том домене, в котором эта группа существует, разумеется) – но всё ж, благодаря LVR-репликации, масштаб не настолько критичен и огромен. Суть в том, что если вы реже меняете состав групп, чем их читаете (так обычно и происходит), то Universal-группы выгодны – трафик репликации растёт мало, на фоне явной экономии времени и трафика на запросах о членстве.

Универсальные группы, подчеркну, будут запрашиваться с GC – поэтому необходимо, чтобы в каждом сайте AD был хотя бы один GC – иначе работать будет, но появится большая задержка от round-trip запросов поверх WAN-каналов между сайтами – именно из-за этого на уровне сайта есть опция “включить на всех DC этого сайта кэширование состава универсальных групп”, понимаемая всеми Windows 2003 Server и более новыми:

Эту настройку, как понятно, имеет смысл включать, если теоретически возможна ситуация “в этом сайте не на всех DC есть GC, и есть шанс, что все GC умрут, тогда долго ходить за GC, проще кэш использовать” – если же у вас современная ситуация “каждый DC в сайте – GC”, то эта настройка уже не имеет смысла.

Что же у универсальных групп по части членства? Всё очень хорошо – в универсальную группу могут входить учётки, глобальные группы, и другие универсальные – из любого домена нашего леса. Это очень удобно. Domain Local’ы, как понятно, не могут – они, находящиеся в других доменах, просто не видны из нашего – впрочем, мы это уже много раз подчеркнули.

Кроме того, универсальные группы из нашего же домена занимают 8 байт в PAC’е (т.е. в итоговом маркере доступа) – это выгодно.

Таким образом, вырисовывается следующая картинка с универсальными группами – они действительно гораздо более просты в части “что в них можно положить” – можно всё, кроме не видимых нами из нашего домена Domain Local’ов других доменов ; плюс запрос у GC состава этих групп делается в одно движение; плюс места в токене занимают мало.

Что ж, давайте теперь немного посуммируем то, что имеется на данный момент.

• В Active Directory есть три типа групп – каждый со своей спецификой;
• У каждого типа есть вариант “с пометкой о не-использовании в составе маркера доступа” – это называется Distribution-группой;
• Разные типы групп занимают разное число байт – некоторые занимают 40 байт, т.е. пишется SID целиком, с доменной частью, некоторые 8 – когда только тип и RID;
• Специфика универсальных групп будет связана в основном с фактом появления леса Active Directory – впрочем, некоторое увеличение скорости работы можно будет получить, заменяя Global на Universal и в сценарии “один домен в лесу”;
• Универсальные группы ускоряют работу только если нет проблем с GC – т.е. он доступен, он в нашем сайте (требуется правильная настройка сайтов и подсетей); при риске потенциальной недоступности можно подстраховаться включением кэширования состава универсальных групп на уровне сайта;

Что ещё можно добавить? По мат.части всё – теперь перейдём к отдельным вопросам и тонкостям.

Тонкость в назначении прав с использованием Domain Local-групп на объекты Active Directory.

Domain Local-группы и объекты Active Directory

В Active Directory, назначая права на объекты, не используйте схему “ACL объекта -> в нём группы-заглушки Domain Local -> в них включаются Universal или Global -> в которые включаются учётные записи”. Почему? Дело в том, что когда пользователь из домена Х будет пытаться провести операцию с каким-то объектом Active Directory, подключившись к DC из домена Y (это важно – т.е. у нас лес, много доменов, и есть например лесной раздел Configuration, который есть на всех DC в лесу) – так вот, этот пользователь, когда будет идти проверка “а можно ли ему сделать операцию”, может оказаться в ситуации “на объекте в ACL указана Domain Local группа, но не из домена Y – поэтому данный DC не может её запросить, её состава нет на GC, а контроллер домена, на котором живёт эта группа, не показывает чужим Domain Local-группы”). В этом случае маркер доступа будет сформирован с ошибкой, без SID’ов таких групп, и пользователь может не получить доступ (или наоборот, ему явно запрещено, а он получит).

Поэтому применяемый для доступа к ресурсам доменных рабочих станций и серверов подход с Domain Local-группами – это одно, а специфика Active Directory, как существующей на нескольких системах-DC с общей базой безопасности – другое.

Миф про сниженное быстродействие Universal-групп

Корни данного мифа, формулируемого как “Universal-группы универсальные, поэтому тормозят”, лежит в советах времён Windows 2000, где вся “тормознутость” сводилась к “часто менять будете состав, и большие группы – значит, большая репликация GC”. По факту и добавление LVR, и рост скорости каналов связи на несколько порядков, этот вопрос полностью убрали. Размеры объектов AD-то не выросли вместе со скоростью каналов – сейчас вопрос “скорость репликации GC” совершенно другую актуальность имеет. Так что используйте Universal-группы смело, они дают явный плюс в скорости при использовании. И не пользуйтесь кэшированием состава Universal-групп на уровне сайта AD, пока нет ситуации “очень далёкий очень медленный филиал, где хотя бы 2 DC, и не все из них GC” – если хотя бы одно из этого не является верным, кэширование просто не нужно.

Производительность дополнительно вырастет, если заменять по возможности Domain Local-группы на Universal (из того же домена) – тогда размер маркера доступа, при прочих равных, уменьшится.

Миф про одинаковость всех групп, потому что их можно друг в друга переключать

Все три типа групп могут превращаться друг в друга – схема достаточно проста, группы Global или Domain Local можно сделать Universal, а Universal – превратить в Global или Domain Local. Т.е. нельзя разве что напрямую Global в Domain Local, надо через превращение в Universal:

Из-за этого функционала, визуально “простого”, и рождается миф, что “понаделают тут просто так от скуки типов групп, ведь это подтверждается тем, что любую в любую, по сути, можно переделать, и ничего не поменяется”.

Не любую в любую. Исключением будет попытка превратить Domain Local в Universal в ситуации, когда в Domain Local есть foreign security principal.

Проверим на практике. Исходные данные – корневой домен леса atraining.z и его дочерний домен с удручающим названием dom2.atraining.z. В каждом из доменов создано 3 тестовых группы разных видов и по одному пользователю:

В Domain Local-группе у нас будет одинокий местный участник Vasya:

Ищем ему компаньона-иностранца из другого домена:

И получаем сообщение The following Active Directory Domain Services error occurred: Foreign security principals cannot be members of universal groups., или LDAP-ошибку 50 (0x32) от контроллера – ERROR_NOT_SUPPORTED.

Так что не всё так однозначно – и преобразование групп из одного вида в другой, хоть и выглядит “тривиальным”, является операцией, при которой проводятся доп.проверки, поэтому никакого “любую в любую можно спокойно, поэтому пофигу на все эти виды групп” не нужно.

Что ж. В общем, всё.

Финал

Я надеюсь, что не очень сильно вас запутал, а даже наоборот – что-то распутал. Впрочем, такие темы проще, конечно же, рассказывать на курсах – так что заходите, у нас интересно. Тема Active Directory – огромна и очень увлекательна.

До встреч!

An Active Directory group is a special type of object in AD that is used to group together other directory objects. In other words, group is a way of collecting users, computers, groups and other objects into a managed unit. Active Directory groups can be used to grant permissions to access resources, delegate AD administrative tasks, link Group Policy Objects, and in e-mail distribution lists. In this article, we’ll talk about the different types of Active Directory groups, the differences between them, group scopes, and will show you how to create AD groups and manage them in several ways.

Group Types and Scopes in Active Directory

When you create a new group in Active Directory using the dsa.msc graphical snap-in, you must select a Group Type and Group Scope.

Картинка с сайта: theitbros.com

Active Directory group types

There are two types of Active Directory group, each with three scopes:

• Security Group — this type of group is used to provide access to resources (security principal). For example, you might want to allow a particular group to read files on a shared network folder. To do this, you need to create a security group, edit the share permissions, and add this group to the DACL;
• Distribution Group — used to create e-mail distribution lists (usually used in Microsoft Exchange Server and in Outlook). An e-mail sent to such a group will reach all users (recipients) in the group. This type of group cannot be used to provide access to domain resources, because they are not security enabled.

Note. You can assign email attribute to the security group and use it in distribution lists by converting it to a mail-enabled security group (but it is not recommended).

Active Directory group scopes

There are three group scopes in Active Directory:

• Domain local — used to manage access permissions to various domain only in the domain where it was created. A local domain group cannot be used in other domains (however, a local group may include users from another domain). A local group can be included in another local group, but it cannot be added to the global group;
• Global — used to grant access to resources in another domain. You can only add accounts to this group from the same domain in which the group was created. A global group can be added to other global and local groups;
• Universal — recommended for use in large Active Directory forests. Universal Group allows you to define roles and manage resources distributed across multiple domains. It is desirable to use universal groups only for rarely changing groups. This is because changing the Universal Group causes the Global Catalog to be replicated throughout the organization.

Hint. AD groups can be members of other groups. This is called nested groups. Nested groups are a useful way to manage in AD based on business roles and functions.

There are also local groups. These groups are created in the local Security Accounts Administrator (SAM) database on each computer. The difference from domain groups is that local groups work even if an Active Directory domain controller cannot be contacted.

You can change the Scope or Type of the AD group. But there are some conditions:

• You can convert a Global Security Group to a Universal if the group is not part of another Global group;
• You can convert a Local domain group to a Universal one if it does not contain another local domain group as a member;
• A Universal group can be converted to a Local domain group without any restrictions;
• A Universal group can be transformed into a Global one if it does not include another universal group as a member.

Active Directory Built-in Groups

When you create a new AD domain, several predefined (built-in) security groups are created with a DomainLocal scope. These predefined groups can be used to control access to shared resources and delegate specific administrative permissions on the domain level. The default AD groups are located in a special AD container Builtin.

Картинка с сайта: theitbros.com

You can list the predefined AD group using PowerShell:

Get-ADGroup -SearchBase 'CN=Builtin,DC=theitbros,DC=com' -Filter * | Format-Table Name,GroupScope,GroupCategory,SID -AutoSize

Картинка с сайта: theitbros.com

Administrators DomainLocal Security S-1-5-32-544

Users DomainLocal Security S-1-5-32-545

Guests DomainLocal Security S-1-5-32-546

Print Operators DomainLocal Security S-1-5-32-550

Backup Operators DomainLocal Security S-1-5-32-551

Replicator DomainLocal Security S-1-5-32-552

Remote Desktop Users DomainLocal Security S-1-5-32-555

Network Configuration Operators DomainLocal Security S-1-5-32-556

Performance Monitor Users DomainLocal Security S-1-5-32-558

Performance Log Users DomainLocal Security S-1-5-32-559

Distributed COM Users DomainLocal Security S-1-5-32-562

IIS_IUSRS DomainLocal Security S-1-5-32-568

Cryptographic Operators DomainLocal Security S-1-5-32-569

Event Log Readers DomainLocal Security S-1-5-32-573

Certificate Service DCOM Access DomainLocal Security S-1-5-32-574

RDS Remote Access Servers DomainLocal Security S-1-5-32-575

RDS Endpoint Servers DomainLocal Security S-1-5-32-576

RDS Management Servers DomainLocal Security S-1-5-32-577

Hyper-V Administrators DomainLocal Security S-1-5-32-578

Access Control Assistance Operators DomainLocal Security S-1-5-32-579

Remote Management Users DomainLocal Security S-1-5-32-580

Server Operators DomainLocal Security S-1-5-32-549

Account Operators DomainLocal Security S-1-5-32-548

Pre-Windows 2000 Compatible Access DomainLocal Security S-1-5-32-554

Incoming Forest Trust Builders DomainLocal Security S-1-5-32-557

Windows Authorization Access Group DomainLocal Security S-1-5-32-560

Terminal Server License Servers DomainLocal Security S-1-5-32-561

There are also some built-in privileged groups in Active Directory such as Domain Admins, Enterprise Admins, DnsAdmins, etc.

How to Create a Group in Active Directory with the ADUC Snap-in

You must be a member of the Account Operators, Domain Admins, or Enterprise Admins group to create, modify, or delete a group in Active Directory. You can also delegate the privileges to manage groups in specific OUs to non-admin users.

The easiest way to create a new group in the AD domain is to use the Active Directory Users and Computers snap-in. Go to the target AD Organizational Unit in which you want to create the group, right-click on it, and select New > Group.

Картинка с сайта: theitbros.com

Specify a unique group name, select the group type and scope, and click OK.

Картинка с сайта: theitbros.com

In order to add an object to the group members, go to the Members tab and use the Add button to add users, computers, or other groups.

Картинка с сайта: theitbros.com

Note that when adding members to a group, searches are performed only for the following types of objects: Users, Groups, and Service Accounts. If you want to add an AD object to the security group (such as a computer or contact), click the Object Types, and check the options Contacts and Computers. You can now select any type of Active Directory object.

Картинка с сайта: theitbros.com

You can also add a user to the group by right-clicking on it and selecting the item Add to a group. This is useful if you need to add users to a group in bulk.

Картинка с сайта: theitbros.com

Note that on the Member tab, in the properties of any Active Directory user, its Primary Group is specified. Primary group ID was used to support the UNIX POSIX model to control access to resources. In Active Directory, the PrimaryGroupID attribute for a user must be the RID (relative identifier) of the group to which the user is to be associated. By default, all Active Directory users have a PrimaryGroupID of 513 (Domain User group).

Only Global or Universal security groups can be specified as the primary group.

In most cases, you should not change the Primary Group attribute except in special cases related to POSIX applications and Mac clients.

Картинка с сайта: theitbros.com

You can also create new security groups from the graphical Active Directory Administrative Center (dsac.exe). Right-click on the domain name or OU and select New > Group.

Картинка с сайта: theitbros.com

Fill in the following mandatory fields:

• Group name.
• Group Scope (Global/Domain local/Universal).
• Group type (Security/Distribution).

Here you can also set a description for the group, enable/disable the Protect from accidental deletion option, add users to the group, etc.

Click OK to create the group.

Картинка с сайта: theitbros.com

To remove a user from a group, search for the group by name using Global Search, and open its properties. Go to the Members tab, select the user you want to remove and click the Remove button. Click OK to save your changes.

Картинка с сайта: theitbros.com

Create and Modify Active Directory Group Using PowerShell

To create Active Directory groups, use the PowerShell New-ADGroup cmdlet from the Active Directory for Windows PowerShell module.

The type of the group (Security or Distribution) is specified using the -GroupCategory argument. The scope of the group is specified using the -GroupScope parameter (valid values: DomainLocal, Global, or Universal).

You can use the command to create a new global distribution group in the target OU:

New-ADGroup -Path "OU=Groups,OU=Brasil,DC=theitbros,DC=com" -Name "BrasilUsers" -GroupScope Global -GroupCategory Distribution

To find all the distribution groups in your domain, use the following cmdlet:

Get-ADGroup -Filter 'groupcategory -eq "Distribution"'

Use the following command to create a new security group:

New-ADGroup –Name RemoteAccessUsers -GroupScope Universal -GroupCategory Security -Path "OU=Groups,OU=USA,DC=theitbros,DC=com"

You can change Active Directory group attributes using the Set-ADGroup cmdlet. For example, you want to add a description to the security group you have created earlier:

Set-ADGroup RemoteAccessUsers –Description “Users that can access corporate network over DirectAccess and VPN server”

In addition, you can use the Set-ADGroup cmdlet to change the scope of the group. For example, use the following command to convert the Global Distribution group to the Universal Security group type:

Get-AdGroup RemoteAccessUsers | Set-ADGroup -GroupScope Universal -GroupCategory Security

Now you can add users to this group using Add-ADGroupMember cmdlet:

Add-ADGroupMember RemoteAccessUsers -Members user1,user2,user3

To remove a user from an AD group, use the Remove-ADGroupMember cmdlet:

Remove-ADGroupMember -Identity RemoteAccessUsers  -Members user1, user2

Confirm the user membership removal by pressing Y > Enter.

To completely remove an Active Directory group, run:

Remove-ADGroup -Identity RemoteAccessUsers

When you delete a group, you will be prompted to confirm the deletion. To disable removal confirmation, add the Confirm parameter:

Remove-ADGroup -Identity RemoteAccessUsers  –Confirm:$false

To get all the information about the specified group, use the Get-ADGroup cmdlet:

get-adgroup 'domain admins’

Картинка с сайта: theitbros.com

DistinguishedName : CN=Domain Admins,CN=Users,DC=theitbros,DC=com

GroupCategory : Security

GroupScope : Global

Name : Domain Admins

ObjectClass : group

ObjectGUID : f04fbf5d-c917-43fb-9235-b214f6ea4156

SamAccountName : Domain Admins

SID : S-1-5-21-3243688314-1360023605-3291231821-512

You can calculate the total number of users in the group:

(Get-ADGroupMember -Identity 'Domain Admin').Count

You can list (export) members of the Active Directory group using the Get-ADGroupMember cmdlet.

To list the AD groups that the user account belongs to (including AD nested groups), run the command:

Get-ADUser jbrion -properties memberof | select memberof -expandproperty memberof

Картинка с сайта: theitbros.com

Active Directory functional levels of Windows Server 2012 R2 and newer support Time-based group membership. This feature allows administrators to assign temporary group membership, which is expressed as a Time to Live (TTL) value. This value will be added to the Kerberos ticket. This is also called the expiring links feature.

You can temporarily add a user to a group using PowerShell. For example, you want to add a user to a security group for only 2 days to assign temporary permissions. Run the following PowerShell command:

Add-ADGroupMember -Identity g_CA_Sales -Members b.jackson -MemberTimeToLive (New-TimeSpan -Days 2)

After two days, the user account will be automatically removed from the group. To view the remaining time (in seconds) that a user will remain in a group:

Get-ADGroup g_CA_Sales -Property member -ShowMemberTimeToLive

Картинка с сайта: theitbros.com

We like to convert Global to Universal Security Group with PowerShell. Why with PowerShell? It’s because we have to convert more than a hundred groups. It will take hours of work if we are going to do it with Active Directory Users and Computers (ADUC). In this article, you will learn how to convert Global to Universal Security Group with PowerShell.

Active Directory group types

When creating a new group in the organization with ADUC, we have Group scope and Group type.

Картинка с сайта: www.alitajran.com

Active Directory group scope

There are three group scopes that we can select:

• Domain local groups: Used to assign permissions for access to resources.
• Global groups: Used to organize users who share similar network access requirements.
• Universal groups: Used to assign permissions to related resources in multiple domains.

Active Directory group type

There are two group types:

• Security groups: Used to control access to resources. Security groups can also be used as email distribution lists.
• Distribution groups: Can be used only for email distribution lists, or simple administrative groupings. Distribution groups cannot be used for access control because they are not security enabled.

Now that we have a bit of understanding about the group scope and group type, let’s start converting.

We are going to get the information from one single group named Data. Run PowerShell as administrator.

Note: In ADUC it’s named Group scope and Group type. In PowerShell it’s named Group scope and Group category.

PS C:\> Get-AdGroup "Data" | ft Name, GroupScope, GroupCategory

Name GroupScope GroupCategory
---- ---------- -------------
Data     Global  Distribution

Change the group scope to Universal and the group type to Security. After that, we will check if it’s converted successfully.

PS C:\> Get-AdGroup "Data" | Set-ADGroup -GroupScope Universal -GroupCategory Security

PS C:\> Get-AdGroup "Data" | ft Name, GroupScope, GroupCategory

Name GroupScope GroupCategory
---- ---------- -------------
Data  Universal      Security

Converting Global Distrubition group to Universal Security group went great. What if we have more than a hundred groups that we need to convert from Global to Universal Security group?

Bulk convert Global to Universal Security group

We have an Organizational Unit (OU) named Mailbox with all the groups that we like to convert to Universal Security group. Find the distinguished name in AD. We need to insert that in the PowerShell command.

Start Active Directory Users and Computers. Enable Advanced Features.

Картинка с сайта: www.alitajran.com

Right-click the Organizational Unit with the groups that you like to convert. Click Properties.

Картинка с сайта: www.alitajran.com

Click the Attribute Editor tab. Find the attribute distinguishedName and copy its value.

Картинка с сайта: www.alitajran.com

List all the groups in the OU Mailbox.

PS C:\> Get-ADGroup -SearchBase "OU=Mailbox,OU=Groups,OU=Company,DC=exoip,DC=local" -filter * | Sort Name | Select-Object Name, GroupScope, GroupCategory

Name                 GroupScope GroupCategory
----                 ---------- -------------
All Staff                Global      Security
Data                  Universal      Security
Finance               Universal  Distribution
HR                    Universal  Distribution
IT Admins                Global  Distribution
Management            Universal  Distribution
Payroll Team             Global  Distribution
Payroll Team Leaders     Global  Distribution
Sales                    Global  Distribution

Create a temp folder on the C:\. Export the output to CSV and sort it on Name. This comes in handy if you want to send a list with the details. The name of the CSV will be Mailbox_Groups.csv.

PS C:\> Get-ADGroup -SearchBase "OU=Mailbox,OU=Groups,OU=Company,DC=exoip,DC=local" -Filter * | Sort Name | Select-Object Name, GroupScope, GroupCategory | Export-Csv -Path "C:\temp\Mailbox_Groups.csv" -NoTypeInformation

Bulk convert all groups in OU Mailbox to group scope Universal. After that, check if the Group Scope is showing as Universal.

PS C:\> Get-ADGroup -SearchBase "OU=Mailbox,OU=Groups,OU=Company,DC=exoip,DC=local" -filter * | Set-ADGroup -GroupScope Universal

PS C:\> Get-ADGroup -SearchBase "OU=Mailbox,OU=Groups,OU=Company,DC=exoip,DC=local" -filter * | Sort Name | Select-Object Name, GroupScope, GroupCategory

Name                 GroupScope GroupCategory
----                 ---------- -------------
All Staff             Universal      Security
Data                  Universal      Security
Finance               Universal  Distribution
HR                    Universal  Distribution
IT Admins             Universal  Distribution
Management            Universal  Distribution
Payroll Team          Universal  Distribution
Payroll Team Leaders  Universal  Distribution
Sales                 Universal  Distribution

Do the same, but this time bulk convert all groups in OU Mailbox to group type Security. When done, check if the group type is showing as Security.

PS C:\> Get-ADGroup -SearchBase "OU=Mailbox,OU=Groups,OU=Company,DC=exoip,DC=local" -filter * | Set-ADGroup -GroupCategory Security

PS C:\> Get-ADGroup -SearchBase "OU=Mailbox,OU=Groups,OU=Company,DC=exoip,DC=local" -filter * | Sort Name | Select-Object Name, GroupScope, GroupCategory

Name                 GroupScope GroupCategory
----                 ---------- -------------
All Staff             Universal      Security
Data                  Universal      Security
Finance               Universal      Security
HR                    Universal      Security
IT Admins             Universal      Security
Management            Universal      Security
Payroll Team          Universal      Security
Payroll Team Leaders  Universal      Security
Sales                 Universal      Security

We can run both the above commands in one single command. This will bulk convert the groups in OU to group scope Universal and group type Security.

PS C:\> Get-ADGroup -SearchBase "OU=Mailbox,OU=Groups,OU=Company,DC=exoip,DC=local" -filter * | Set-ADGroup -GroupScope Universal -GroupCategory Security

Conclusion

You learned how to convert Global to Universal Security Group with PowerShell. It’s just a couple of minutes work if we convert groups with PowerShell. We can convert one group only or we can do all the groups in bulk. Microsoft did write documentation regarding the Active Directory Security Groups. Did you enjoy this article? You may also like to read MSExchange ActiveSync 1023 warning. Don’t forget to follow us and share this article.