Темы статьи

• Аналог AD DS: Samba DC

• Активация, лицензирование и законодательство

• Правильный подход и автоматизация

• Список литературы, методы её изучения

• Синхронизация времени в домене

• 50 примеров задач, решаемых при помощи GPO

AD DS или AD?

Active Directory называлась так до 2008 версии, потом её переименовали. Для корректности я всегда пишу именно "AD DS" – Active Directory Domain Services, чего и вам советую. В статье написал некорректно, т.к. практически все называют эту службу каталогов именно "Active Directory" – кто-то ради сокращения, кто-то по привычке, а кто-то по незнанию.

Samba DC

Пишу этот раздел специально, чтобы меня не считали "фанатом" AD DS.

Есть прекрасная альтернатива – Samba DC, предоставляет практически те же самые возможности, но использовать её я всё же не рекомендую по следующим причинам:

• Linux. Будем честны, далеко не все знают Linux на уровне, достаточном для эксплуатации службы каталогов. Да, вам не придётся учить BIND (потому что есть встроенный DNS-сервер, и его достаточно, если вам так нужен BIND – развёртывайте его на отдельном хосте). Но вот мониторинг, логирование, сертификаты, резервное копирование, синхронизация времени (особенно если DC у вас несколько) – не сложно, но придётся осваивать новые инструменты и набивать шишки с нуля.

• Забудьте про Exchange, изменения, вносимые в схему для работы Exchange, Samba не поддерживает. Лично я с Exchange не работаю, но почему бы не отметить.

• Туда же проблемы с новым LAPS (со старым всё работает нормально) и AD CS/PKI.

• Функциональный уровень. Поддержка 2016 появилась лишь в версии 4.20 Samba (которая вышла в 2024 году, то есть спустя 8 лет). Поскольку сборка из исходников – это зло, в репозиториях Samba DC версии 4.22 появилась лишь в Debian 13 (вышла в середине 2025) и Ubuntu 26 LTS (должна выйти в апреле 2026). Можно предположить, что поддержка 2025 функционального уровня появится в Samba не раньше 2032 года.

• ADBA. Активация любых продуктов M$ во всём лесу, если у вас приобретен ключ CSVLK (которого в 99,9% случаев не будет), однако об активации ниже.

• dMSA не поддерживается (по понятным причинам, новинка в WS 2025). gMSA начал поддерживаться лишь недавно, с версии 4.21.

Также сразу отмечу, что существует множество сторонних инструментов для мониторинга, анализа безопасности, управления объектами и т.п. Я несколько раз использовал те, что имеют бесплатные версии (инструментов с открытым исходным кодом нет), такие как:

• AD Pro Toolkit

• Specops GPUpdate

• AD Tidy

• AD FastReporter

И без них можно спокойно жить, всё и так делается через PS (Powershell) и ADAC, а утилиты эти я, в основном, использую ради создания красивых отчётиков, и пару раз использовал для аудита безопасности (когда приходишь в чужую среду – разобраться сходу крайне тяжело). И в целом, эти инструменты вам ничем не помогут, если вы не понимаете, как работает служба каталогов в целом, и ни разу не пробовали делать всё через PS самостоятельно (т.к. эти инструменты по сути дела просто GUI над PS). Но если вам действительно нужен мощный инструмент для работы с AD DS – читайте книги и документацию. Не существует оснасток, модулей, дополнительных расширений и прочего, которые делали бы вашу работу за вас.

Есть много альтернатив AD DS, вот только работать с ними никто не умеет, и в случае проблем вы останетесь один. Все знают про AD DS, все слышали про Samba, и ещё недавно (5 лет назад) начали узнавать про другие службы каталогов, такие как FreeIPA (из-за импорторазвращения на тот же ALD Porn).

В остальном всё то же: те же оснастки (RSAT: DNS, GPO, ADUC), те же FSMO-роли, те же групповые политики, та же корзина для удалённых объектов и т.д.

Кому я бы порекомендовал использовать или проводить миграцию на Samba:

• Небольшим организациям до 500 клиентов. Если их больше – забудьте про Samba DC.

• Гос. учреждениям (из-за импорторазвращения).

• Всякой нечисти по типу АОшек-обороночек (по той же причине).

• Тем, кто хочет наработать опыт эксплуатации служб каталогов на Linux.

• Тем, кто хочет развить или проверить на прочность свои навыки администрирования Linux в целом.

• Если у вас всё серьезно по лицензированию или если вас самих волнует эта тема.

• IT-компаниям для наработки опыта.

Документация:

https://wiki.samba.org/index.php/Main_Page

Дальше. Перед тем, как начать работать со службами каталогов, вам необходимо навести порядок в голове.

Активация

Я прекрасно знаю, что многие из вас активировать ("ломать") Windows и MS Office не умеют, за использование локальных взломщиков я бы больно бил молотком по пальцам.

https://github.com/Wind4/vlmcsd

Системный администратор не знающий Linux –  это не системный администратор.

Лицензирование

Начиная с WS 2016, лицензирование происходит по количеству ядер. Для нас это означает ровно одно: чем их меньше – тем меньше рисков по лицензированию (в 90% случаев лицензий у вас не будет, а в 10% – будут, но на старые версии).

WS 2008, 2008R2, 2012, 2012R2 – лицензируются количеству CPU (сокетов, не ядер) на сервере.

Честно, с одной стороны я презираю эту конченную политику лицензирования Microsoft (и не только MS, но и ту же VMWare, которая ввела моду на X/6-ядерные CPU). Но вот с другой – существует 146 статья уголовного кодекса РФ, согласно которой (на момент написания статьи) крупным размером является 500.000 рублей, а особо крупным – 2.000.000 рублей.  В первом случае наказание вплоть до лишения свободы на 2 года, во втором – до 6 лет. Ещё есть 273 статья, со сроком до 7 лет, специально для любителей "ломать софт" через тот же KMSAuto, а не просто нарушать лицензионное соглашение.

Под 273 попадают, в том числе и MAS: HWID, KMS38, TSForge. Поэтому ставим GVLK-ключи с VLMCSD, т.к. благодаря этому доказать факт именно что взлома ПО практически невозможно. К тому же, VLMCSD можно удалить и развернуть в любое время, лицензия держится до полугода. Наша задача – исключить 273 статью. Сам VLMCSD должен быть где угодно, но только не в вашей стране.

Политика лицензирования говорит нам, что WS 2016, 2019, 2022, 2025 необходимо приобрести лицензий минимум на 16 ядер на сервер.

Ущерб рассчитывается из рыночной стоимости. Поэтому рекомендую вам самостоятельно ознакомиться с ценами на различных сайтах для вашего региона.

Что делать?

1. Ни в коем случае не использовать редакцию Datacenter, вне зависимости от версии.

2. Приобрести лицензии (не все организации их могут себе купить в принципе: начиная от жадного руководства и заканчивая реестром отечественного ПО).

3. Не развёртывать WS на серверах/кластерах суммарно с более чем 16 ядрами, по возможности покупать CPU с наибольшей производительностью на ядро.

4. Не обновляться сразу, подождать пару лет, новые версии ПО всегда крайне дорогие, и не всегда это оправдано.

5. Развёртывать роли/сервисы на одном экземпляре ОС.

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

Что ещё можно сделать?

1. Изменить должностную инструкцию, чтобы у вас не были прописаны обязанности по установке ПО и т.п. В случае чего вы можете всегда сказать: я этого не делал, это вообще не входило в мои трудовые обязанности. Однако это не панацея, и в любом случае им придётся доказывать, что ПО устанавливали именно вы. Аналогично и с регламентами.

2. Не вестись на провокации. Я даже не знаю, какой пример вам привести, но лучшим считаю допрос шпиона из "Следствие ведут ЗнаТоКи". Всегда всё отрицайте: ничего не видел, ничего не слышал, ничего не делал.

3. Устанавливать и активировать ОС будучи в отпуске/больничном, из-под обезличенных учётных записей.

4. Развёртывать сервера на виртуальных машинах.

5. Использовать BitLocker (для Windows Server) и LUKS (для Linux), т.к. забирают всегда в первую очередь сервера (из рабочих станций забирают только у ГД и сотрудников отдела ИТ, но могут и другие, смотря какая статья), и ещё реле для умного дома вам в помощь.

6. Не говорить вслух, что вы устанавливали то или иное ПО, никогда, даже своим коллегам (могут записать), и нигде в письменном виде это не фиксировать. С другой стороны, фиксировать все приказы и слова ваших коллег и руководства. Они всё равно будут пытаться сделать вас виноватым, но мы им этого не позволим.

7. Собирать компромат на вашего непосредственного начальника и организацию в целом, чтобы у них было меньше желания вас завиноватить. Компромат бывает личным, горячим и рабочим. Нам пока что нужен только рабочий, в него входят: ваши служебки о необходимости приобрести ПО, приказы начальника об установке ПО, зафиксированные заявки из системы типа helpdesk что программа требует ключ и не дает работать, и прочие доказательства того, что это был НЕ ваш личный умысел. Вы – всего лишь бедный и несчастный сотрудник, который должен содержать семью и поэтому был обязан подчиниться, ваша воля подавлена. Самое лучшее, что вы можете собрать – это угроза лишения премии на видео/аудио. Это не спасёт вас от условного срока, но сильно смягчит последствия: вся финансовая и основная уголовная ответственность упадут на руководство предприятия.

8. С другой стороны, вам всегда следует помнить, что все методы, которые хороши против вашего начальника, хороши и против вас.

9. Не трогать устройства ввода и оборудование в аппаратных/серверных помещениях голыми руками, а также носители информации.

10. Всегда помнить, что риски по лицензированию другого ПО ("программ для ЭВМ") могут быть на порядки выше (MS SQL Server, Oracle DB, АСКОН).

11. Отечественное ПО безопаснее, т.к. есть возможность заключить мировое соглашение и возместить причинённый материальный ущерб (если у вас есть деньги). Это значительно уменьшит степень общественно опасного деяния, и суд назначит более мягкий вид наказания.

12. С другой стороны, разработчики отечественного ПО гораздо чаще подсылают своих "экспертов", как раньше делала Microsoft.

13. Почитать судебную практику и понять, что, обращаясь в суд, вы берёте волка за уши, и свидетель может в ходе следствия превратиться в обвиняемого.

14. С другой стороны, всё может обернуться не так, как в судебной практике. И обязательно всё пойдёт не так, как вы себе это представляете (лучший пример – вспомните, как вы представляли себе вашу работу, будучи на 3-5 курсе института, и что получили на деле). Любая бумажка имеет значение. Любая мелочь может перевернуть дело.

15. Всегда помнить, что штрафы никогда не пойдут на благое дело. В первую очередь они пойдут на содержание самих государственных органов, а во вторую… ну, в общем, новости почитайте. И что для государства ваше предприятие и вы (будь то системный администратор или ГД) – лишь тварь дрожащая, которая нарушает закон ради извлечения прибыли или из хулиганских побуждений.

16. Всегда помнить, что на работе союзников не бывает. И тем более их не может быть в лице гос. служащих.

17. При этом лучше дружить с людьми, которые могут сообщить заранее о прибытии нежелательных элементов (благо привязка идёт по районам)

18. Иметь ввиду, что носители информации могут изъять по любому другому уголовному делу, но экспертизу проведут в любом случае. К примеру, 198 и 199 статьи УК РФ (уход от налогов), или ещё что похуже.

19. В мелко-средних организациях судьба системного администратора незавидна, однако на крупных предприятиях руководство будет делать всё возможное, чтобы дело замять (в хорошем для вас смысле). Ибо единиц оборудования много, сотрудников тоже, и на деле окажется, что конкретно вы причинили от силы 5% от общего ущерба. Остальное ляжет на остальных, и им тоже это не надо, либо сгорит по сроку давности.

Образы

Образы всегда берём либо с официального сайта, либо с нормальных сайтов (как тот же massgrave). Не с торрентов. Не с флешек своих собратьев по несчастью. А только оттуда, откуда надо, потому что иначе вы получите очередную говносборку с непонятными изменениями с далеко идущими последствиями. Лучше потратить дополнительно 10 минут своего рабочего времени и сразу сделать всё так, как надо.

 

Редакции

Посмотрите, какие редакции Windows существуют, чем они отличаются, сколько стоят и какие методы активации имеются. А ещё лучше – узнайте на практике. Скажу сразу – используйте редакцию IoT Enterprise LTSC (для Windows 10/11).

 

Унификация

Используйте одну и ту же редакцию ОС. Так будет немного проще их администрировать в дальнейшем, не придётся создавать отдельные WMI-фильтры и прописывать доп. условия в скриптах. То же касается и ПО.

Структура

В техническом плане порядок навели, теперь наведём порядок в голове.

Когда вы приходите на работу, и вам необходимо попасть в 311 кабинет, как вы думаете, на каком этаже он находится? Правильно: на третьем. И вот вы идёте по коридору и видите перед собой кабинеты 308, 310 и 310а. Куда делся 309? И откуда взялся 310а? А когда вы идёте по улице и видите перед собой дом №41, как вы думаете, где находится дом №36? Правильно: на другой стороне улицы. Надеюсь, Америку для вас не открыл. А нумерация портов в сетевом оборудовании и отсеков в СХД начинается слева направо сверху вниз – уже догадываетесь почему? Надеюсь, что да.

Теперь ближе к практике, объясню на своем примере.

У меня имена рабочих станций задаются просто: PCXXYY, где:

PC – это рабочая станция

XX – номер отдела

YY – ID рабочего места

Например, имя хоста на моём АРМ – PC1704. А мой внутренний номер – 1704, на телефоне t1704. Номер начальника ИТ-отдела – 1701, звонок на весь отдел – 1700. Пользователям, абонентам и ИТ‑аборигенам необходимо лишь помнить номер отдела, остальное можно подобрать перебором.

Если вам интересен сетевой уровень, то у PC1704 IP-адрес – 10.4.14.221 (сразу понятно, что VLAN 4). А вот, к примеру, телефон t6001 – имеет адрес 10.6.11.218 (VLAN 6 – другое здание). И никакой статики, никакого резервирования, только последовательная выдача адресов из диапазона 10.V.10.0-10.V.99.255 (остальные как резерв) с завязкой на синхронизацию DHCP с DNS (именно с завязкой, не надо пытаться использовать в роли DNS протокол DHCP с резервированиями и гигантскими сроками аренды свыше 8 дней, он не для этого предназначен).

Правильный подход очень сильно облегчает работу всем, и в первую очередь вам, как системному администратору. У вас должен быть порядок в голове, который затем получит отражение на практике. И чтобы этот порядок появился, необходимо как минимум читать книги и получать хорошее образование (именно что получАть – это бесперебойный процесс), и задавать правильные вопросы (неважно, кому: коллегам, поисковой системе или нейросетям).

Автоматизация

Запомните: службы каталогов созданы в том числе и для автоматизации ваших рутинных задач. Опять объясню на своём примере. Вот добавили вы компьютер с именем PC5113 в домен (скриптом), он появляется в контейнере по-умолчанию Computers. И вот дальше автоматически (скриптом, который запускается по событию 474?), он перемещается в соответствующее OU "51 отдел что-то-там", где находятся и все остальные компьютеры этого отдела с именами хостов PC51??. Поменяли этому компьютеру имя – он переместился в другое организационное подразделение. Следовательно, на него через GPO (скрипты и MSI-файлы) развёртывается новое ПО, удаляется старое (по необходимости), применяются новые правила поведения (компьютеры этого отдела выключаются в 18:30, а компьютеры вот этого отдела – нет). И руками делать ничего не надо. И создавать лишние группы или даже WMI-фильтры (для каждого из сотни отделов) – это идиотия. Всё, что можно упростить – надо упрощать. Лишние промежуточные звенья нам ни к чему.

Этим и отличается администрирование крупной ИТ-инфраструктуры в нормальной организации – степенью автоматизации и систематическим подходом к решению задач, даже самых примитивных.

Далее. Не работайте с отдельными объектами. Если, к примеру, необходимо провести развертывание клиента 1С (с подключением баз, разумеется), скажем, начальнику палаты №44 и его заму, то развертывайте это ПО сразу на весь 44 отдел, а не на отдельные АРМ PC4401 и PC4402. Даже если в отделе 20 АРМ. Нужны им они или нет – неважно, потом рано или поздно всё равно могут понадобится, и придётся опять добавлять отдельный компьютер в группу, пользователи АРМ поменяются местами, или АРМ начальника просто выйдет из строя, а у всех его подчинённых уже развернуты клиенты и подключены базы. Аналогично с учётными записями пользователей. Они приходят и уходят, а отдел остаётся. Ну и разумеется, группы должны быть зеркальным отражением структуры вашего предприятия. Со структурой, с названиями подразделений и групп один-в-один как у отделов и т.п. Делайте их так, как надо, а не так, как вы привыкли. Если у человека написано в паспорте Ромашкова Алёна Тюльпанина, и в систему учёта (ту же 1С) занесёна сотрудница с именем Ромашкова Алёна Тюльпанина – значит, она Ромашкова Алёна Тюльпанина, а никакая не "Алена Т. Ромашкова".

Если вы что-то делаете, попробуйте подумать, как бы вы это делали в случае, если объём работы вырастет в сотню раз.

Зачем нужны книги

Перед тем, как предоставить вам список литературы, я хочу чтобы вы поняли несколько важных вещей.

Первое. Ни книги, ни документация, ни статьи, и даже ответы от нейросетей и видеоролики с ютуба – не несут никакой пользы сами по себе. Ценностью является ваше умение обрабатывать содержащуюся в них информацию, то есть: составлять конспекты и заметки, проверять эту информацию (актуальна ли она, вдруг автор ошибается или что-то не договаривает), самостоятельно развивать те или иные мысли, искать аргументы (почему было сделано именно так), сравнивать (когда делаем так, а когда – вот так) и, что самое главное, применять эту информацию на практике. Книга (даже самая хорошая) не сделает из вас грамотного спеца. Практика – критерий истины, и иногда по итогу оказывается, что написанное в книге – на практике не применимо. Так, к примеру, было с тем, как я организовал структуру и как у меня по ней автоматически перемещаются объекты типа компьютер в зависимости от их имени (и ещё куча моментов на самом деле, но бесплатно я выдам лишь несколько – остальное вам придётся нарабатывать самостоятельно).

Второе. Книги нужны для того, чтобы привести голову в порядок. Если вы как системный администратор ни разу не сталкивались с ситуацией, когда для решения проблемы вам необходимо было обратиться к технической литературе или документации с дальнейшей проработкой нескольких десятков или сотен страниц – то вы кто угодно, но только не системный администратор. Читая книги одну за другой вы со временем поймёте важность фундаментальной подготовки. Поймёте, что начинать всегда надо с основ, снизу вверх. Поймёте, что у команд, которые вы вводите, есть десятки интересных и полезных параметров, что команды эти могут отличаться и т.д.

Третье. Один из моих коллег называет это "рентгеновским зрением". Зная теорию, вы крайне легко и быстро сможете понять причину той или иной проблемы (с полными логическими цепочками, почему так произошло), и решите эту проблему гораздо быстрее тех, кто литературу и документацию последние несколько лет не изучал в принципе. Если же направление для вас абсолютно новое – то вы всё равно разберётесь быстрее, т.к. ваш мозг уже привык разбираться в чём-то для него новом и непонятном. Вы точно также возьмётесь за документацию или книгу, будете составлять конспект, проверять всё на практике, а не просто "гуглить" – потому что ответов в интернете нет (Ааа, групповые политики не применяются!), а нейросеть вам выдаст какую-то ерунду, которая даже близко не совпадает с тем, что есть в действительности.

Четвёртое. Списывание. Речь про то, когда вы просто взяли чьё-то готовое решение (у своих коллег напрямую или из статей) и просто повторяете, не задумываясь и не спрашивая о том, почему было сделано именно таким образом. Не надо так делать. Всегда пробуйте сначала разобраться сами. И повезёт ещё, если ваш коллега или автор статьи попались толковые. Но потом как всегда выяснится, что они сами просто у кого-то скатали готовое решение и выдают за своё, и поэтому объяснить вам в деталях, почему было сделано именно так, они не смогут. Я сам прочитал около сотни статей конкретно по теме AD DS, и большинство их них нормальные, некоторые даже были со ссылкой на источники. Но доверять написанному, даже если это официальная документация, сходу не стоит. Всё необходимо перепроверять и думать своей головой.

Пятое. А теперь самая главная мысль, которую я хочу вам донести. Не знать чего-то – это нормально. Ошибаться – это тоже нормально. А вот считать себя самым умным (книги читать бесполезно) и не учиться ни на своих ошибках, ни на чужих – вот это уже не нормально, это глупо.

Лучший способ чему-то научиться – это учить других, поэтому я и пишу статьи.

Как надо читать книги

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

Например, вам скажут, что конспекты должны быть по объему примерно 10% от самой книги. Это правда. Но вам не уточнят, что процент варьируется от главы к главе, и что по одной главе объёмом 30 страниц у вас будет 20 страниц конспекта, а в другой главе на 20 страниц у вас может не быть конспектов в принципе. По разным причинам: вам эта тема не нужна, вы её уже знаете и т.п. И это абсолютно нормально и правильно. Поэтому читаете абзац, анализируете написанное, и затем ещё раз, в более сжатом и понятном виде перепечатываете текст себе в конспект.

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

Ещё момент, про 10 книг в год. Я не знаю, откуда именно взялась красивая цифра 10, но точно знаю, что люди, которые подобное заявляют, не прорабатывали книги в принципе, и, либо лгут, либо просто их пролистывали (в одно ухо влетело – в другое вылетело). Они не составляли по этим книгам заметки, и, тем более, не искали дополнительную информацию в интернете и не пытались применить полученные знания на практике. Ибо ваша реальная скорость чтения (если вы действительно осваиваете информацию, это вам не художественная литература) не будет превышать 10-12 страниц в час. Давайте подсчитаем. Берём эти 10 книг, по 600 страниц полезной информации в среднем, и получаем 500 часов в лучшем случае. Минимум 500 часов в год, минимум 40 часов в месяц. Без учета практики, без учета документации, видеороликов, статей (которые в сумме увеличивают время в два раза). Если вы – студент, если вы – безработный, я ещё поверю, что вы можете прочитать 10 книг в год, но в реальности, работая, имея какие-то другие обязанности, вы будете прорабатывать не более двух-трёх книг в год или не читать их в принципе, начиная сразу с документации.

Когда я учился в университете, где-то к концу второго курса у меня мозги на место встали (как оказалось, нет, встали сильно позже) и я начал читать вообще всё что видел – пока сидел на лекциях, читал архитектуру компьютера и сети Таненбаума, СКС Самарского, Лимончелли, DNS&BIND и даже (по нашей теме) устаревшую на текущий момент книгу по групповым политикам с гаечным ключом на обложке. И читал – это очень громко сказано. Точно также, как и все начинающие специалистики, просто просматривал страницу за страницей в надежде, что запомню, не составлял конспекты и ничего не записывал. Как итог – к моменту моего "повышения" до системного администратора не помнил практически ничего, а запомнил лишь весёлые опечатки по типу "конченых пользователей", и затем сильно удивился, когда пришлось столкнуться с параметрами DHCP-сервера для iPXE, хотя они были описаны в той же книге Лимончелли (и так по каждой второй технологии). А сколько времени потрачено зря. Нет, разумеется, какая-то часть информации в голове отложилась, но я бы не назвал эти знания полезными для применения на практике. Поэтому, не повторяйте моих ошибок, лучше потратить 100 часов, но усвоить 90% информации, чем потратить 50, но усвоить 10%. Так что, если вы – выпускник, не надо переживать, что знания у вас не отложились. Учились вы пять лет, а работать будете пятьдесят, и переживать о том, что вы, имея сто рублей, потеряли десять – глупо. У большинства людей даже этого нет. Чтобы это понять, просто пообщайтесь со своими одногруппниками и расспросите у них, что они изучали помимо учебной программы.

Как продолжение предыдущего пункта. Забудьте про всё и сразу. Вы – вездеход, а не формула-1. Вы будете пробираться по болотам и лесам, на незнакомой местности, а не по ровной трассе, которую заранее выучили. И в случае проблем вы останетесь один, и вокруг вас не будет прыгать команда механиков через каждые пять километров. Быстро не получится. Быстро – значит плохо, и ещё хуже, чем медленно. И порой, чтобы выбраться из грязи, необходимо нажимать на педаль газа  по чуть-чуть, а не давить на неё изо всех сил, пробуксовывая часами на одном месте. Поэтому, если вы начали пролистывать книгу и смотреть, сколько там страниц осталось до конца главы – делайте перерыв минут на 15-20, сходите погулять, поотжимайтесь, поприседайте, но ни в коем случае не смотрите в монитор или телефон. Интеллектуальная работа очень сильно выматывает вне зависимости от стажа, именно поэтому я после обеда не занимаюсь сложными техническими вопросами.

Ну и вишенка на торте. Книги быстро закончатся – это раз. Информация в них устаревает – это два. И вы по итогу придёте к тому, что ничего нового из книг вы не узнаёте в принципе (да и информация по новым технологиям в книгах появляется далеко не сразу), и вы ограничитесь лишь документацией и некоторыми статьями. Ещё раз повторяю: книга – это то, от чего вы будете отталкиваться. Книга – это не нейромод или кибермодуль, который вы вставите себе в мозг и тут же освоите какой-либо навык. Такое бывает только в видеоиграх и научной фантастике.

Дальше. Ищите книги в электронном формате. Человека, который ещё не научился прорабатывать книги, отличить можно именно таким образом: он всегда стремится взять бумажную версию. Сами подумайте: как вы будете печатать конспект? Как вы будете осуществлять поиск по тексту? Как вы будете работать с текстом и изображениями в целом? Один глаз на книгу – другой в монитор? Тем более, что книга в бумажном виде, как правило, раз в 5-10 дороже, и просто так сохранить её на множество устройств и с кем-то ею поделиться вы не сможете. Но, разумеется, если вы студент и денег у вас нет, то можете попытаться:

• Найти книгу в интернете бесплатно (не работает с новейшими книгами, потратите время и, скорее всего, получите PDF-файл отвратительного качества), но вариант рабочий.

• Найти её в библиотеке вашего учебного заведения (вариант мёртвый, но теоретически возможный, особенно если книга отечественная и старая).

• Найти единомышленников и скинуться вместе на книгу в электронном виде (вариант тоже мёртвый, сейчас не 90-е, да и среднестатистический студент, скорее, купит новый костюм для своего героя в доте, чем техническую литературу).

Поэтому, скорее всего, вы книгу купите, и купите именно в электронном виде. И не надо сразу покупать/скачивать десяток книг. Лежащие без дела в облаке или на полке книги ума вам точно не прибавят.

Список литературы

Сети

Перед тем, как начать работу со службами каталогов, вам необходимо понять, как устроены компьютерные сети, а именно: как работает служба DNS, как работает протокол DHCP, как работают коммутаторы и как их необходимо настраивать, что такое шлюз по умолчанию, что такое порты, что такое фаервол и т.д. и т.п.

Компьютерные сети (Олиферы или Танебаум)

Выбираете любую, они примерно одинаковые, и отличаются лишь последовательностью разбора тем и картинками. Какие-то темы лучше объяснены в одной книге, а какие-то – в другой. Если сталкиваетесь с трудностями понимания, просто найдите ту же тему в другой книге. Эти книги есть на русском языке, и я рекомендую читать их именно на русском, чтобы вы освоили стиль (особенно полезно для студентов, которые затем будут писать дипломную работу), чтобы исключить из вашей речи такие слова как "разворачивание". Но если вы хотите прочитать книгу по сетям на английском – читайте Таненбаума.

Главный недостаток этих книг в том, что они описывают всё понемногу. То есть для того, чтобы в деталях узнать, как работает сетевое оборудование, линии связи, как устроены кабельные системы, беспроводная связь, службы DNS, DHCP, веб, почта и т.п. – читайте отдельную литературу или лучше сразу документацию. Аналогичная ситуация, к слову, с книгой Unix and Linux Administration Handbook (в плане описания работы в консоли, сетей, служб DNS, DHCP, почты, RAID‑массивов и т.п.). Книги эти вы читаете просто для ознакомления, воспринимайте их как вводный базовый курс, для тренировки мозга и получения навыка составления конспектов, который вам очень сильно пригодится в будущем и проведёт через всю жизнь. Если у вас уже есть опыт работы – можно не читать в принципе, вы ничего не потеряете, однако я бы на вашем месте всё-таки прошелся по оглавлению и поискал информацию об отдельных темах, в которых вы чувствуете пробелы.

Дальше в статье я укажу пару моментов про сеть, и если вы не поймёте, о чём там идёт речь – читайте документацию по Router OS, CISCO CCNA и CCNP (самые полные и бесплатные), можете также рассмотреть MTCNA и Zyxel (платные). Дело не в самих учебных материалах (документация, курсы и т.п.), а в том, как вы их прорабатываете. Также учтите, что работать вы всё равно будете с оборудованием разных производителей. Но почему бы сразу их не читать, минуя книги Олиферов и Таненбаума? Потому что вы не научитесь составлять конспекты и усваивать информацию, а во второй раз вам прорабатывать эти курсы вряд ли захочется.

Windows

Дальше все книги необходимо читать на английском.

Служба каталогов AD DS развёртывается на Windows Server, а GPO характерны только для клиентов под управлением операционных систем Windows, поэтому с операционными системами этого семейства лучше ознакомиться заранее.

Windows Server 2019 Cookbook

Самая простая книга по администрированию WS, где разобраны все основные вещи. Главы про DFS, Hyper-V и контейнеризацию лучше пропустить. И я не считаю, что эти технологии плохие, просто они вам либо не пригодятся, либо вам запретят их использовать из-за невозможности приобретения лицензий. Если вы уже имеете хоть какой-то опыт администрирования WS или хорошо знаете англ. язык – книгу пропускайте. Если найдёте более новую редакцию – читайте именно её. Но на самом деле это не проблема, потому что из версии к версии по сути дела не меняется ничего.

Windows Internals

Хоть я и считаю, что книга по большому счёту написана для разработчиков ПО, однако всё же рекомендую её найти и прочитать главы, посвященные основам, подсистеме ввода-вывода и безопасности (первая и две последние, если брать 7 издание).

AD DS

Теперь по самой службе каталогов и групповым политикам.

Mastering Active Directory

Несмотря на то, что книга откровенно слабая, но для людей, никогда до этого не работавших с AD DS – самое оно. Да, в ней первые главы поверхностные и бесполезные, равно как и предпоследняя глава про Azure (откровенная реклама MS). Но ни в одной другой книге вы не найдёте готовый пример той же миграции с WS 2008 на 2016 (в 3 издании), описание полезных команд траблшутинга или выполнение примитивных задач сразу через PowerShell.

Mastering Windows Group Policy

Самая лучшая книга (из новых) про GPO, небольшая и простая. Проблема лишь в том, что многие очень важные вещи, с которыми вы столкнётесь на практике, здесь описаны очень коротко, и их крайне легко пропустить.

Group Policy

Для закрепления темы GPO, всё же рекомендую прочитать и эту книгу. Несмотря на то, что она может показаться многим неактуальной, на деле она ни на миг не устарела. Лучше её прочитать сразу после Mastering Windows Group Policy, для закрепления теории.

Designing deploying and running Active Directory

Лучшей книги по AD DS не было, нет, и вряд ли будет. Книгу эту я рекомендую читать всем, даже несмотря на то, что она часто затрагивает компоненты, с которыми вы вряд ли когда-либо столкнётесь напрямую (такие как AD FS, AD LDS) – с одной стороны. С другой – в ней в самом начале описано, как работает синхронизация времени, хоть и совсем коротко (чего нельзя сказать о нашей предыдущей книге по AD DS), и вы поймёте, что это есть и что с этим можно как-то работать.

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

Powershell

PowerShell Cookbook

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

https://learn.microsoft.com/en-us/powershell/module/activedirectory/?view=windowsserver2025-ps

Документация по модулю AcriveDirectory для PowerShell. Работать с AD DS вы будете именно благодаря ему (напоминаю, что в службе каталогов ничего не должно делаться вручную – пишите скрипты).

Стоит ли тратить время на изучение SCCM, Intune, PolicyPack и т.п.?

Определенно нет. Учитывая то, что у вас вряд ли будет настолько большая и комплексная (безобразно сложная) ИТ-инфраструктура, что без этих инструментов вы не сможете работать в принципе. Либо у вас просто мало опыта, и вас к её администрированию не подпустят. А в целом всё, что можно упростить, необходимо упрощать. Чем меньше промежуточных узлов – тем дешевле эксплуатация и выше надёжность. К тому же, незнание, скажем, Powershell вас ударит по голове гораздо раньше, чем неумение работать с тем же SCCM/MECM.

Практика

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

1. Автоматическое удаление неактивных компьютеров и отключение неактивных учётных записей, смена их пароля на случайный, а также удаление их из групп (и перенос названий этих групп в описание этой учётной записи, туда же добавляется дата и время отключения), и перенос их в отдельное OU со вложенными OU по годам.

2. Поиск и восстановление удалённых объектов при отключенной корзине.

3. Старые версии WS, такие как 2000/2003, и миграция с них.

4. Поиск компьютеров с одинаковыми локальными SID (когда штатные макаки скопировали ОС чем попало не задумываясь о последствиях, поэтому используем Clonezilla).

5. Группы с количеством членов свыше 5.000.

6. Автоматизация процесса обновления ADMX/ADML-файлов.

7. Миграция между доменами/лесами.

8. Автоматизация процесса переноса и удаления папок пользователей с доменных компьютеров для освобождения места на дисках.

9. Синхронизация времени и её мониторинг.

10. Разработка собственного решения для мониторинга репликации.

11. Траблшутинг инфраструктуры, когда контроллеры были восстановлены из снапшотов виртуальных машин.

12. Мониторинг активности учетных записей (попытки входа, время входа и выхода, и с каких компьютеров).

13. Восстановление Default Domain Policy и Default Domain Controller Policy.

14. Увеличение срока хранения удалённых объектов до трёх лет (больше нет смысла, а полгода мало).

Синхронизация времени

Перед тем, как начать, вам необходимо иметь ввиду следующее:

1. Из-за несовершенства кварцевых резонаторов без синхронизации с внешним источником время будет уплывать вперёд или назад примерно на 3-5 минут в месяц (если температурный режим не соблюдён – то ещё хуже, вплоть до 20 секунд в сутки). У серверных материнских плат погрешность ниже, но крайне незначительно (до 1%). Основная деградация кварцевого резонатора происходит в первые 3 года эксплуатации. Имейте это ввиду и заодно замените батарейки CMOS по необходимости (к слову, к точности они не имеют никакого отношения).

2. Часовые пояса здесь вообще не причём, синхронизация времени это про UTC. NTP-сервера передают количество секунд, а не конкретные даты, часы и минуты.

3. Несколько источников времени нужны для кворума, на случай если один из них станет недоступен или начнёт передавать неверное время. NTP-клиент увидит, что на одном из источников время улетело куда‑то не туда, и пометит его как врунишку (если у него есть в запасе ещё как минимум два, на которых время примерно одинаковое – клиент синхронизирует по среднему значению между ними), или временно перестанет доверять всем источникам (если у вас источников всего два, но не более).

4. Следить за временем необходимо, это крайне важная вещь. Лучше всего – через систему мониторинга (к примеру, Zabbix, при этом на самом сервере время должно быть синхронизировано как надо). Что именно необходимо мониторить и почему – вы узнаете ниже.

5. Постоянной сверхточности на всех клиентах сразу вы всё равно не добьётесь (т.к. старые версии ОС, задержки сети, некоторые компьютеры с севшей батарейкой просто долго не включались, и синхронизируют время не сразу, а также значения по умолчанию некоторых параметров). Честно скажите себе, что отклонение в +/- 5 секунд вашим рабочим станциям для работы более чем достаточно. Не ищите проблемы там, где их нет.

Готовое решение:

Найдите в интернете информацию о командах w32tm, nltest и изучите все их параметры.

То же самое проделайте с веткой реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\

Определите внешние источники. Выбираем по задержкам и территориальному расположению.

По задержкам – самым лучшим будет NTP-сервер вашего провайдера (если есть).

По расположению – всё зависит от страны. Для РФ это…

Четыре сервера из пула ru.pool.ntp.org:

0.ru.pool.ntp.org

1.ru.pool.ntp.org

2.ru.pool.ntp.org

3.ru.pool.ntp.org

К слову, использовать пулы из домена ntp.org в качестве единственного источника не советую. Нет SLA и кто владелец непонятно. В chrony/ntpd они используются по умолчанию только в целях совместимости с любой точкой планеты.

Гос. эталон (смотрите по расположению, какие из них к вам ближе):

ntp1.vniiftri.ru

ntp2.vniiftri.ru

ntp3.vniiftri.ru

ntp4.vniiftri.ru

И ещё Internet Exchange:

ntp.ix.ru

Из глобальных могу выделить:

time.google.com

time.windows.com (наверное, самый нагруженный на планете)

ntp.aliyun.com (если вы на Дальнем Востоке)

time.cloudflare.com

time.apple.com

time.aws.com

При выборе внешних источников руководствуйтесь правилом: чем они сильнее отличаются – тем лучше. Не выбирайте только сервера из одного пула/домена/региона/страны. При этом вам необходимо выбрать 3-5 ближайших.

Важный момент: Stratum (уровень) у всех источников должен быть одинаковым (для того же chrony/ntpd это не так критично).

w32tm /stripchart /computer:ntp-srv.tld /samples:30

Смотрите на стабильность значений в столбце delay.

ping ntp-srv.tld

В идеале задержки не должны превышать 50 мс.

tracert ntp-srv.tld

В идеале их должно быть не больше 12.

Убедитесь, что до вас никто не пытался настроить синхронизацию времени через групповые политики. Чего я только не видел – начиная от указания на клиентах PDC-Emulator (в качестве единственного NTP-сервера напрямую в реестр) и заканчивая изменением параметров службы W32Time (такие как MinPollInterval, MaxPollInterval, SpecialPollInterval, MaxAllowedPhaseOffset). И дело не в том, что люди меняют параметры через GPO, а в том, что они не понимают, что они делают, и для чего это вообще нужно.

Отключать STS необходимо обязательно (он включен на WS 2016-2022, в 2025 Microsoft признала свой косяк и его отключила). Но сделать это можно только путем редактирования реестра. Проблема в том, что ADMX записывают параметры в другую ветку, которая не считывается. Более того, служба времени инициализирует алгоритм STS ещё до того, как применяются групповые политики. Поэтому отключать STS на ВСЕХ компьютерах домена вам придётся через Preferences, отредактировав ветку реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Параметр: UtilizeSslTimeData, значение – 0

Если DC (неважно, PDC-Emulator или нет) является виртуальной машиной, то:

Отключите синхронизацию времени виртуальной машины с гипервизором.

Отредактируйте ключ реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider

Параметр – Enabled, значение – 0.

Только учтите, что при запуске ВМ, вне зависимости от гипервизора, тот подсунет ей своё время. Это правильно и так должно быть, просто не забывайте настраивать синхронизацию времени в том числе и на гипервизорах. Вводить гипервизоры в домен нельзя.

Сначала настройте NTP-клиент и NTP-сервер на внешнем шлюзе или ином программно-аппаратном комплексе. Если он напрямую синхронизируется со Stratum-0 (к примеру, ваше предприятие приобрело аппаратные GPS-часы), он должен объявить себя Stratum-1. На самом шлюзе допустимо использование 5-7 источников (защита от 2-3 самозванцев) или более. Если у вас внешних шлюзов несколько – задавайте на клиентах в качестве источника только один из шлюзов (смотря, какая у вас схема, если это VRRP, где оба шлюза должны синхронизироваться друг с другом, то такой проблемы не будет).

Давайте для начала рассмотрим способы определения на PDC-Emulator списка NTP-серверов штатными средствами. Всего их должно быть три (на случай, если остальные пропадут), включая внешний шлюз (внешние источники мы задаем именно потому, что есть вероятность того, что ваш текущий шлюз будет заменён каким-нибудь простеньким роутером, и никто не будет тратить время на его настройку в роли NTP-клиента и сервера). Большее количество источников не имеет смысла для W32Time, кворума здесь нет, это вам не chrony/ntpd.

Чтобы каждый раз при миграции FSMO-роли не перенастраивать источники времени вручную, можно просто создать GPO с WMI-фильтром на владельца роли PDC-Emulator.

Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Time Providers

Параметр 0x9 – это два параметра 0x1 и 0x8.

Параметр 0x8 определяет, что клиент будет брать время из указанных источников, а не из доменной иерархии. Если указываете больше одного сервера, служба времени будет синхронизировать время в первую очередь с лучшим по задержкам источником (это всегда будет внешний шлюз), а обращаться к остальным 0x8 будет только если до него задержки будут больше (или он окажется недоступен). Назначать внешние источники на PDC-Emulator необходимо именно с параметром 0x8.

Параметр 0x1 – определяет, что клиент будет обращаться к серверу с определённым интервалом: SpecialPollInterval (по умолчанию обычно 1024-3600). Нам он не подходит, т.к. на DC по умолчанию в 0x8 уже используется интервал опроса от 64 до 1024 секунд. Не задавайте сервера с параметром 0x9.

Как выставить время вручную:

w32tm /config /manualpeerlist:"10.0.0.1,0x8 ext-ntp1.tld,0x8 ext-ntp2.tld,0x8" /syncfromflags:manual /reliable:YES /update

/syncfromflags:manual – параметр, который приказывает хосту игнорировать доменную иерархию и брать время напрямую из заданных серверов. На всех остальных клиентах домена должен быть параметр domhier (NT5DS). Если параметр manual на PDC-Emualtor не выставить, то он в домене не найдёт никого главнее себя, у него снесёт башню и он начнёт считать, что время на нём является эталонным.

/reliable:YES – этот параметр нужен не для рабочих станций, а для других контроллеров домена (если у вас их несколько). Обязательно должен быть на DC с FSMO-ролью PDC‑Emulator, в противном случае другие DC посчитают, что у них самих время ничуть не хуже, и не захотят с ним синхронизироваться.

Клиенты ищут NTP-сервер по доменной иерархии через NetLogon, и синхронизируют время с тем DC, который является надёжным. Если в одном сайте клиент находит несколько DC, которые являются надёжными источниками, и при этом один из них PDC‑Emulator, то клиент всё равно выберет тот, до которого задержки ниже (при этом не закрепляясь за ним навсегда, при следующем обращении к серверу он может выбрать другой, если до него задержки ниже – такая вот своеобразная балансировка нагрузки между DC). Если PDC-Emulator отсутствует, то клиент выберет случайный DC по DNS. Если надёжного DC нет, то поиск выходит за пределы сайта. Если и там нет, то они берут время с PDC-Emulator (даже если он не является надёжным). Если и он недоступен – то с любого DC.

Очень желательно (так рекомендует Microsoft) объявить надёжными все DC (если связь с PDC-Emulator пропадёт, другие DC не смогут раздавать время клиентам), но при этом у них должен быть тип синхронизации NT5DS, а NTP только на PDC-Emulator.

Для этого создаем GPO, закрепляем его над OU со всеми контроллерами, и редактируем реестр с нацеливанием через LDAP-запрос (или WMI-фильтр) на контроллеры домена без роли PDC-Emulator:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Параметр – AnnounceFlags, значение – 10. Значение 5 должно быть только на PDC-Emulator.

При этом, DC может сам объявить себя надёжным источником, но для этого, во-первых, сам PDC-Emulator должен быть надёжным источником, а, во-вторых, разница по времени между ними должна быть минимальной (не более 10 сек) и стабильной (до 5 часов). Но основная проблема не в том, чтобы DC стал надёжным. Проблема в том, что он может перестать себя таковым считать. То есть, если на несколько часов PDC-Emulator потеряет связь с внешними источниками, то он перестанет раздавать время клиентам домена. Но это полбеды. Хуже всего то, что другие DC, увидев, что PDC-Emulator недоступен какое-то продолжительное время или сам стал ненадёжным, тоже перестанут раздавать время клиентам. Но не сразу, а как только накопится та самая разница в 10 секунд (если что – это Root Dispersion). Как быстро эта разница накопится – зависит от кварцевого резонатора вашего сервера. Обычно это занимает где-то 3-6 часов, в зависимости от наработки и условий эксплуатации оборудования (если это виртуальная машина, то расхождение предугадать невозможно).

Если у вас несколько доменов в одном лесу, по умолчанию PDC-Emulator дочерних доменов будут синхронизировать время с PDC-Emulator корневого домена. Как это исправить вы уже знаете.

Заметьте, я не использую выражения в стиле "главный/основной/первичный" контроллер домена, потому что это неправильно. Все DC в AD и AD DS равнозначны. И то что до сих пор используются старые коды совместимости из Windows NT – это не оправдание, прошло уже четверть века как-никак. Тяжело людям без образования, они всегда ищут кого-то главного.

А теперь вам остаётся только ждать. Мониторьте расхождение по времени на всех клиентах через систему мониторинга, и какие-либо выводы вы сможете сделать только через несколько недель, пока время не синхронизируется.

Думали, это всё? Перед вишенкой на торте разберём метод защиты от внезапных путешествий во времени, чтобы никто не переместил ваши компьютеры в 2000/2050 год. Забегая вперёд отмечу, что это единственный оправданный случай, когда обязательно стоит принудительно устанавливать параметры W32Time через групповые политики.

Одна из причин, почему необходимо отключить STS – он игнорирует все ограничения, и при включенном STS рабочая станция спокойно могла оказаться в 2035 году. Для дома – да. Для локального предприятия – строго нет.

По умолчанию защита 48 часов (в старых версиях отключена). Казалось бы, какая разница? Ну, исправим время, клиенты пару часов проработают с неправильными часами, но проработают же. Только вот не забывайте, что у вас в домен входят в том числе и сервера. Крайне важные сервера, будь то СУБД, 1С или СКУД, которые очень сильно завязаны на времени (если для них PDC-Emulator является единственным источником). И вот для них, отдельно, необходимо настроить MaxPosPhaseCorrection и MaxNegPhaseCorrection, скажем, по 1 часу (чтобы записанная информация не так сильно потеряла юридическую ценность).

Ситуация с PDC-Emulator гораздо интереснее. Выше я уже пару раз сказал, что в W32Time нет кворума, как в том же chrony/ntpd. Поэтому я считаю, что для PDC-Emulator тоже необходимо выставить ограничения в 1 час, и при этом иметь возможность независимого подключения (к примеру, через VNC гипервизора или IPMI).

При отсутствии этих ограничений, если вы на шлюзе сдвинете время на 24 часа назад – он моментально уведёт за собой PDC-Emulator, а тот и все клиенты, потому что он является для них единственным источником времени. Дальше только забирайте права на изменение системного времени, настраивайте триггеры на события и т.д.

Можете также попробовать назначить ограничение в 1 час и для рабочих станций, это абсолютно правильное решение… в теории. На практике из-за вас младшему ИТ-персоналу придётся очень далеко ходить, чтобы руками через BIOS поправлять время на компьютерах, которым по 15-20 лет, особенно после новогодних праздников, длительных больничных и отпусков (ситуации на самом деле из моей практики единичные, но смысла ставить 1 час всё равно нет).

А сейчас устраним точку отказа в лице единственного опрашиваемого источника времени на PDC-Emulator и других серверах Windows.

Штатно W32Time никак не защищает нас в случае, если кто-то скомпрометирует время на этом единственном источнике времени, будь то внешний шлюз или независимый источник. Служба W32Time это не полноценный NTP. Для полноценного необходимо установить ntpd (Meinberg NTP) и определить в конфигурационном файле минимум 3-5 источников: шлюз и внешние сервера. Мы получим возможности кворума, и в случае, если сетевой инженер ошибётся в настройке времени на шлюзе, PDC-Emulator пометит его как врунишку, потому что теперь есть полноценный NTP, который умеет сравнивать время между всеми источниками.

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

Этот как раз-таки ответ на вопрос, почему настраивать синхронизацию времени через GPO не имеет смысла – потому что в службе W32Time отсутствует кворум и она не способна распознавать самозванцев.

Теперь ответ на вопрос, почему вы никогда не добьётесь точности секунда-в-секунду сразу на всех рабочих станциях домена.

Рассмотрим параметры MinPollInterval и MaxPollInterval. Первый трогать не рекомендую, минимальный период опроса (64 секунды для DC и 17 минут для остальных) нас полностью устраивает. А вот второй, с 17 минутами (на DC) и 9 часами (для клиентов домена) – как он работает? Можно ли его менять, на какое значение и поможет ли это нам синхронизировать время с точностью до секунды на рабочих станциях?

Служба W32Time после запуска пытается синхронизировать время сразу. Если время в порядке – она увеличивает этот интервал на степень двойки, и так каждый раз до 9 часов.

Но что значит "в порядке"? Интервал опроса увеличивается не из-за точности, а из-за стабильности времени. Даже если у клиента есть постоянно небольшое смещение (скажем, 2 секунды), то интервал опроса будет расти, даже несмотря на то, что время по сравнению с источником на нём неправильное. Интервал опроса не корректирует время сам по себе, но создаёт условия для поддержания высокого уровня точности.

Хорошо, а если там время правильное, а тут – нет, то каким именно образом мы будем его исправлять?

Если разница более 3,75 минуты (или 2,5 для одноядерных хостов, которых уже не осталось), то служба мгновенно это время перенастроит. Если же разница меньше 3,75 минут – то W32Time будет подгонять время плавно. Проблема в том, что расхождение по времени между рабом домена и источником может быть, скажем, 3,5 минуты, и плавная синхронизация времени для этих 3,5 минут может затянуться до двух часов.

Представили картину? Пользователи пришли, с утра включили компьютеры, эти компьютеры накопили разницу в 3,5 минуты (по разным причинам – кто-то вернулся с больничного/отпуска, но это редкость и обычно там накапливается чуть большая разница, которая сразу же срезается при обращении к источнику), и теперь, два часа с момента обращения компьютеров к источнику времени время на них не будет точным.

Проблема усугубляется тем, что в теории разница может держаться немного дольше, потому что алгоритм исправления времени может работать в одну сторону, а вот кварцевый резонатор – в другую. И между ними происходит своеобразное перетягивание каната: либо резонатор победит операционную систему, либо операционная система победит резонатор, разгоняя или замедляя время. А служба что, так и будет пытаться плавно это время исправить? Пока не накопится отклонение в 3,75 минуты?

Нет. Ситуация становится однозначной в пользу операционной системы, если вы уменьшили MaxPollInterval до 17 минут. Кварцевый резонатор, даже в крайне убитом состоянии, вряд ли выдаст вам отклонение более чем на (100 ppm умножаем на 2^10) 0,1 секунды за эти 17 минут, а вот операционная система за те же 17 минут сможет исправить время уже на 25 секунд (а вот для 9 часов – на 75 секунд, но эти 75 секунд размазываются на 9 часов). W32Time может замедлять или ускорять процесс плавной синхронизации, если видит, что разницу с источником в очередной раз (раз в 64/1024 секунды) сгладить не удалось.

На DC время синхронизируется сверхагрессивно, поэтому переживать за них и менять их параметры не стоит.

И это не единственная причина, почему вам может быть полезно уменьшить MaxPollInterval до 2^10 (но можно и до 11-12 степени). Выше я описывал, что W32Time каждый раз увеличивает интервал опроса на степень двойки. Но затык обычно происходит именно на 15 степени (реже – на 14). То есть, рабочая станция включилась, проработала суммарно 9 часов, сверила время… и если оно стабильно, то следующий опрос источника будет только через 9 часов. Казалось бы, раз она уже нормально проработала 9 часов, то по какой причине её часы должны отстать в следующие 9? Чтобы получить ответ на этот вопрос, снова обратимся к системе мониторинга. Берём рабочую станцию PC1234, которая уже бесперебойно отпахала две смены по 12 часов, и видим, что с 8:30 до 11:30 нагрузка на CPU была в среднем 90%, а весь остальной день – около 10%. Следовательно, температура в корпусе системного блока была разной, что и могло привести к уменьшению точности кварцевого резонатора. И поэтому за 9 часов система может накопить отклонение в 3-5 секунд, хотя за предыдущие 9 часов время было идеальным.

Это как раз ответ, почему бесперебойной точности секунда-в-секунду на всех рабочих станциях сразу вы не добьётесь. Поэтому, если у вас есть такие рабочие станции в домене – то выставляйте MaxPollInterval равным 10 (2^10 секунд), но можно больше (главное, чтобы не было периодов по 4,5 и 9 часов).

Но всё-таки перед изменением параметров рекомендую собрать статистику по времени в домене, чтобы понять, есть ли в изменении параметра MaxPollInterval хоть какой-то смысл. Помните, что я говорил в начале?

Честно скажите себе, что отклонение в +/- 5 секунд вашим рабочим станциям для работы более чем достаточно. Не ищите проблемы там, где их нет.

И пытаться создать задачу в планировщике на принудительную синхронизацию после запуска или выставлять значение параметра MaxAllowedPhaseOffset в 1 – крайне не рекомендую, а то ещё напридумываете псевдорешений несуществующих проблем. Подобные "не имеющие аналогов" затеи – лишь пустая трата вашего времени как инженера, лучше бы вам применить этот подход для решения других задач.

Групповые политики

Для самостоятельного изучения, всё что ниже – просто отправная точка с описанием, а не готовое решение. Проработать все пункты вам придется самим. Рекомендую разбирать по 1‑2 в день, как раз хватит на пару месяцев.

Работа с ПО

1. Развёртывание ПО. Самое основное, для чего вы будете использовать групповые политики – это установка и обновление ПО. Делается это либо через msi-файлы, либо через запуск скриптов. К примеру, MS Office и .NET вы будете развёртывать именно через скрипты.

2. Ассоциации файлов под это ПО. И да, я знаю, что у всех системных администраторов проблема именно с форматами rar, pdf, djvu и им подобными.

3. Всегда показывать расширения файлов (чтобы у пользователей не было проблемы file.docx.doc и ne-virus.pdf.exe).

4. Настройка параметров ПО через административные шаблоны (Zore Touch Config для Outlook, отключение Мастера первого запуска и анимаций для MS Office, установка расширений для браузеров и т.п). Далеко не всё ПО поддерживает административные шаблоны, и пересчитать их можно по пальцам одной руки.

5. Отключение Edge к чёртовой матери.

6. Запуск скриптов (вы их должны придумать сами).

7. Изменение ключей реестра. По ситуации, но может быть полезно для настройки ПО, которое не имеет ADMX или для включения того же WoL на сетевых картах.

Примеры приложений, имеющих MSI-файлы:

Обновление Windows

1. Настройка обновлений Windows (получают ли они у вас их через WSUS или напрямую, и как).

2. Ограничение скорости BITS.

3. Настройка оптимизации доставки (если у вас не используется WSUS).

Безопасность

1. Развёртывание сертификатов.

2. Прокси-сервер для системного, пользовательского уровня или для отдельного браузера.

3. Отключение локальных групповых политик.

4. Политика паролей учетных записей.

5. Автоматическая блокировка экрана при бездействии пользователя.

6. AppLocker. Должен быть обязательно, особенно если у вас нет стороннего AV.

7. Запрет записи в корень диска C:\. Гадить надо пользователям в загрузки, а не в системные файлы.

8. Управление Windows Defender, если у вас нет стороннего AV.

9. Управление Firewall. Некоторые его просто отключают в доменной среде, лично я против такой практики.

10. User Account Control (при запуске исполняемых файлов).

11. Запрет на подключение личных учетных записей Microsoft.

12. Включение Script Block Logging.

13. Запрет запуска исполняемых файлов из архивов.

14. Запрет на установку драйверов без подписи.

15. Запрет на запуск приложений из AppData и проч.

16. Очистка буфера обмена при выходе пользователя из системы.

17. Сбор журналов логов в центральное хранилище (WEF).

18. Отключение NTLM.

19. Отключение FTP.

20. Отключение telnet.

21. Отключение гостевой учетной записи.

22. Шифрование паролей (нужен новый LAPS).

Оптимизация

1. Отключение NetBIOS, LLMNR (если у вас нет старых версий ОС). Избавимся до трети ненужного бродкаста. Отдельно на коммутаторах необходимо настроить IGMP Snooping и ACL на дроп 137, 138, 5355 (UDP) скриптами (или через тот же Ansible), чтобы снизить нагрузку на CPU. На хардсетах отключаем в принципе все протоколы через конфиги (NetBIOS, LLMNR и mDNS).

2. Отключение IPv6, и наоборот.

3. Прокси-сервер (продублировано из предыдущего раздела), для снижения нагрузки на сеть.

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

5. Отключение синхронизации автономных файлов (снижение нагрузки на диск и сеть).

6. Отключение телеметрии (полностью отключить телеметрию вы сможете только на редакциях Enterprise, Education и серверных версиях ОС). Необходимо в первую очередь для снижения нагрузки на CPU, диск и, немножко, сеть. Это один из моментов, почему вам на рабочих станциях необходимо использовать именно редакции Enterprise.

7. Управление дефрагментацией и TRIM. Запускайте только при простое системы.

8. Работа с планировщиком задач (к примеру, автоматическое отключение рабочих станций в заданное время).

9. Автоматическая очистка временных папок (temp). Сразу отмечу, я против практики, когда очищаются корзины пользователей и, что ещё хуже, их папки с загрузками. Снижение обращений в тех. поддержку на 50 заявок в год не стоит потери файлов. Также можно выставить максимальный размер корзины.

10. Отключение всевозможной рекламной ерунды (особенно если у вас редакции Pro*).

11. Включение режима максимальной производительности (и в целом управление электропитанием).

12. Отключение анимаций Windows.

13. Отдельно про индексацию на сетевых папках. К примеру, в TrueNAS разработчики недавно добавили TrueSearch. Служба поиска по файлам и их содержимому это вечная проблема для локальных предприятий, к теме GPO напрямую не относится, просто отметил, чтобы больше людей отказывалось от Windows Server в роли NAS.

Пользователи

1. Развёртывание принтеров. Четверть всей вашей работы с групповыми политиками.

2. Развёртывание ярлыков (рекомендую создать несколько разных GPO по каждому типу ярлыков – будь то сетевые папки отделов или внутренние сервисы предприятия).

3. Развёртывание на рабочих столах пользователей файла .txt с именем рабочей станции и телефоном тех. поддержки (на всякий пожарный).

4. Определение раскладки клавиатуры на экране входа в систему (это всегда будет EN).

5. Включение Num Lock после загрузки.

6. Управление содержимым панели задач.

7. Отключение истории сообщений. Очень спорно, но приучает пользователей наводить порядок на своих рабочих столах и в сетевых папках, некоторые даже начинают использовать тот же Double Commander.

8. Добавление ярлыка "Мой компьютер" на рабочие столы пользователей.

9. Автоматическое включение области просмотра в проводнике Windows.

10. При входе пользователя отображать FQDN вместо NetBIOS.

Бесперебойная работа

1. Принудительное автоматическое включение служб.

   Клиент DNS, DHCP, групповой политики, NLA, RDS, Lanman, RPC, PnP, DCOM, Crypto и другие – важные, их необходимо запускать сразу и всегда;

   Служба времени, служба поиска, служба печати – второстепенные, для них допустимо использование режима отложенного запуска, он запускает службу спустя 2 минуты (по умолчанию) после того, как в автоматическом режиме запустится последняя служба.

   Раньше службы отключали из-за безысходности, потому что ресурсов той же дисковой подсистемы крайне не хватало. Теперь мы их, наоборот, включаем, чтобы нас лишний раз не отвлекали от работы.

2. Приказать Windows пропускать экран автоматического восстановления системы в случае сбоя (он же: "синий экран смерти"). Запустите скрипт с командой:

   bcdedit /set bootstatuspolicy ignoreallfailures

   Очень полезно, когда младшему ИТ-персоналу до рабочих станций далеко топать.

3. Включение CrashOnCtrlScroll. Чтобы наказывать коллег, которые оставляют свои рабочие места незаблокированными.

4. Подмена файлов. К примеру, файла .ini для того же Everything.

5. Отключение быстрого запуска.

6. Отключение гибернации и режима сна.

7. Настройка часового пояса.

8. Включение RDP.

9. Включение WinRM.

10. Мониторинг содержимого файла hosts.

11. Отображать подробные сообщения о состоянии при загрузке. Рекомендую включить только на АРМ системных администраторов и серверах.

12. Запрет на использование EFS.

13. Отключение автоматических перезагрузок системы.

14. Отключение Secure Time Seeding.

15. Ожидание сети перед обработкой GPO.

    А вот это моё любимое, специально оставил напоследок. Страх всех гиперэникеев, когда "групповые политики не применяюцца" или "применяются после 2-3 перезагрузок". По умолчанию после запуска Windows ждет 30 секунд. Однако на коммутаторе службы для защит от петель (STP и Loop Protection) могут держать порт закрытым гораздо дольше (в зависимости от того, как вы их настроили, но рекомендуется всегда оставлять значения по умолчанию). Вам необходимо на коммутаторах для портов, к которым подключены конечные устройства (но ни в коем случае не на транках!), выставить режим PortFast Edge. Если у вас коммутаторы старые и не поддерживают RSTP/MSTP, то придётся установить время ожидания для GPO 120 секунд (золотая середина) или больше, и принять, что групповые политики клиентами будут обрабатываться с такой задержкой.

Как видите, всё довольно просто, необходимо лишь ознакомиться с документацией и внедрить это на практике, и никаких сказок про "400 групповых политик". Вроде из того, что использую я, ничего не забыл, но если вспомню – список дополню. Также вы можете написать в комментарии к этой статье или в личные сообщения, я тоже добавлю.