Создание групп серверов и управление ими create and Manage Server Groups

Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

В этом разделе описывается создание пользовательских групп серверов, определяемых пользователем, в диспетчер сервера в Windows Server. This topic describes how to create custom, user-defined groups of servers in Server Manager in Windows Server.

Группы серверов Server groups

Серверы, добавленные в пул серверов, отображаются на странице все серверы в Диспетчер сервера. Servers that you add to the server pool are displayed on the All Servers page in Server Manager. Вы можете создавать настраиваемые группы из уже добавленных серверов. You can create custom groups of servers that you have added. Группы серверов позволяют просматривать и управлять меньшим подмножеством пула серверов в качестве логического устройства. Например, можно создать группу « серверы учета » для всех серверов в бухгалтерии организации или группу под названием « Чикаго » для всех серверов, географически расположенных в Чикаго. Server groups allow you to view and manage a smaller subset of your server pool as a logical unit; for example, you can create a group called Accounting Servers for all servers in your organization’s Accounting department, or a group called Chicago for all servers that are geographically located in Chicago. После создания группы серверов на домашней странице группы в диспетчер сервера отображаются сведения о событиях, службах, счетчиках производительности, анализатор соответствия рекомендациям результатах, а также об установленных ролях и функциях группы в целом. After you create a server group, the group’s home page in Server Manager displays information about events, services, performance counters, Best Practices Analyzer results, and installed roles and features for the group as a whole.

Серверы могут входить в несколько групп. Servers can be a member of more than one group.

Создание новой группы серверов To create a new server group

В меню Управление выберите команду создать группу серверов. On the Manage menu, click create Server Group.

В текстовом поле Имя группы серверов укажите понятное имя для вашей группы серверов, например Серверы учета. In the Server group name text box, type a friendly name for your server group, such as Accounting Servers.

Добавьте серверы в выбранный список из пула серверов или добавьте другие серверы в группу с помощью вкладок Active Directory, DNS или Импорт . add servers to the selected list from the server pool, or add other servers to the group by using the active directory, DNS, or import tabs. Дополнительные сведения об использовании этих вкладок см. в разделе Добавление серверов в Диспетчер сервера в этом руководство. For more information about how to use these tabs, see add Servers to Server Manager in this guide.

После добавления серверов в группу нажмите кнопку ОК. When you have finished adding servers to the group, click OK. Новая группа отобразится в области навигации диспетчер сервера в группе все серверы . The new group is displayed in the Server Manager navigation pane under the All Servers group.

Изменение существующей группы серверов To edit an existing server group

Выполните одно из следующих действий. Do one of the following.

В области навигации диспетчер сервера щелкните правой кнопкой мыши группу серверов и выберите команду изменить группу серверов. In the Server Manager navigation pane, right-click a server group, and then click edit Server Group.

На домашней странице группы серверов откройте меню задачи на плитке серверы и выберите команду изменить группу серверов. On the home page for the server group, open the Tasks menu on the Servers tile, and then click edit Server Group.

Измените имя группы или добавьте или удалите серверы из группы. change the group name, or add or remove servers from the group.

Удаление серверов из группы серверов не приводит к удалению серверов из диспетчер сервера. removing servers from a server group does not remove servers from Server Manager. Удаленные из группы серверы сохраняются в группе Все серверы в пуле серверов. Servers that you remove from a group remain in the All Servers group, in the server pool.

После изменения группы нажмите кнопку ОК. When you are finished with changes to the group, click OK.

Удаление существующей группы серверов To delete an existing server group

Выполните одно из следующих действий. Do one of the following.

В области навигации диспетчер сервера щелкните правой кнопкой мыши группу серверов и выберите команду Удалить группу серверов. In the Server Manager navigation pane, right-click a server group, and then click delete Server Group.

На домашней странице группы серверов откройте меню задачи на плитке серверы , а затем щелкните Удалить группу серверов. On the home page for the server group, open the Tasks menu on the Servers tile, and then click delete Server Group.

Чтобы подтвердить удаление группы серверов, нажмите кнопку Да. When you are prompted to make sure you want to delete the server group, click Yes.

Удаление группы серверов не приводит к удалению серверов из диспетчер сервера. deleting a server group does not remove servers from Server Manager. Удаленные из группы серверы сохраняются в группе Все серверы в пуле серверов. Servers that were in a deleted group remain in the All Servers group, in the server pool.

После изменения группы нажмите кнопку ОК. When you are finished with changes to the group, click OK.

Группы Windows NT и Active Directory

Local и Domain Local, Global и Universal, Security и Distribution — вокруг них много фантазий и мифов. Разбираемся.

Для человека, который сталкивается с многообразием групп в 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-групп
• Миф про одинаковость всех групп, потому что их можно друг в друга переключать

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

Однако, даже на единичной системе групп уже есть два вида – это встроенные, например 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-группы и режимы работы домена

Наличие значения 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 – огромна и очень увлекательна.

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

Обновления личного кабинета — доступны также по RSS.

• 4 апреля: Образ Kali Linux 21.01 с обновлениями за апрель 2021
• 4 апреля: Минималистичный образ Debian Linux 10.9 с обновлениями за апрель 2021
• 4 апреля: Рабочий образ нового Windows Server 2022
• 4 апреля: Специальный образ старого Windows Server 2003 R2
• 4 апреля: Обновлённые образы Windows Server 2019
• 8 января: Образ Ubuntu Server 21.04 (hirsute hippo) с предустановленными инструментами разработчика и Kali Linux 2021 с браузерами Chrome/Firefox — соответственно серверная и клиентская часть для грядущих вебинаров по HTTP/TLS/Security
• 4 января: Январское обновление домашней лабы — с QEMU 5.2.0 и всякими другими интересностями (подробнее см. новость на сайте)
• 2 января: Новый год — новый дизайн личного кабинета. Если найдёте ошибки — пишите, поправим.
• 26 декабря: Обновлённый образ CentOS (8.2 -> 8.3) и Kali с апдейтами за декабрь 2020
• 25 декабря: Образы Ubuntu Server 20.10 и VMware ESXi 7.0 U1c

Новое в архиве Knowledge Assurance. Часть из этих записей доступна бесплатно, на нашем канале YouTube.

• HCIA 2.5 — Первый модуль курса Huawei HCIA Routing and Switching
• AT-NETLAB — Обновлённый вебинар по созданию и настройке домашней лабы
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 7
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 6
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 5
• Cisco IINS 3.0 — Шестое занятие CCNA:Security 2020
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 4
• Cisco SPNGN1 1.0 — CCNA Service Provider (последнее прочтение) занятие 3
• AT-NETLAB — Вебинар по созданию и настройке домашней лабы
• Cisco IINS 3.0 — Пятое занятие CCNA:Security 2020