CityCat4

смогу ли я ее использовать как полноценный продукт на протяжении этого промежутка времени?

Интересно, а что можно сделать полноценного в течение этого промежутка времени? :)

есть момент с "созданием терминального сервера и его лицензирования"

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

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

Может тогда в "Самокат"? :)

Хех, я так пронял, Вы схитропопить решили и подсунуть в CA обычный сертификат от комода, в расчете на то, что примет и можно будет выпускать сертификаты, в итоге подписанные комодом?
Не, так не пойдет. Сертификаты CA - имеют специальную пометочку "я CA", которую комод Вам никогда не поставит.
Вам нужно свой сертификат сгенерить, но он разумеется будет валидным только внутри Вашей конторы и то при условии распространения его политиками.

Совет отключить юзера Administrator - он в общем-то правильный. Совет не работать с админскими правами - тоже. Завести себе учетку типа vasyan и работать под ней, а для задач администрирования использовать что-то типа adm_vasyan. Правда, это неудобно и этим правилом обычно пренебрегают.
А вот модифицировать что-то в схеме AD вообще - это чревато проблемами. Софт, даже от M$ может ничтоже сумняшеся полагать что нечто находится в некотором состоянии, в котором оно находится всегда. Если в Вас оно не так - получите совершенно непонятную ошибку или программа просто работать не будет.
Если нужно спрятать некоторые обьекты - ну создайте отдельное OU, дайте необходимые права, остальные отберите.

У MS существуют различные облачные решения и они прост завизжат от восторга, предлагая их Вам. Так конечно ни Яндекса ни даже Гугла не будет - только outlook.com (или что у них там), но там полноценная интеграция через AD FS - полноценнее некуда.

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

Есть "альтернативные реализации" AD - платные и бесплатные.

Бесплатные:
- Samba - та же AD, только бесплатная, и с косяками. Полной поддержки AD ждать не стоит, заработают базовые вещи - и то будет хорошо. Никаких гуевых панелей администрирования, разве только виндовые заработают.
- FreeIPA - альтернатива AD, сам никогда спаривать с виндой не пробовал

Платные:
- IPA, только платная, от RedHat

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

Написать можно хоть на vbs, хоть на ps - что знаете, на том и пишите. Задача несложная, решается что там что там. Читать документацию соответствующего языка и MSDN - вот что-то, а MSDN у M$ сделан офигительно.

Автоматизация выпуска почтовых сертификатов - это правильная и естественная вещь. Но тут надо учесть следующее - прежде чем начинать массовое внедрение:
- у админа/ИБ-шника всегда должна быть копия почтовых сертификатов пользователя (у меня их аж три - и все хранятся в разных местах). Потому что почта хранится (то есть на сервере лежит в таком виде) в шифрованном виде и при утере ключа она превращается в тыкву. Абсолютно без шансов на восстановление
- выпуск почтовых сертификатов соответственно должен быть организован так, чтобы .p12 создавался админом вручную, чтобы была возможность переносить сертификаты с компа на комп, потому что выпуск сертификата на локальном компе помещает ключ сертификата (возможно, я не проверял!) в локальное хранилище сразу, без шансов его оттуда извлечь и любая перестановка винды превращает почту в тыкву.
- сертификаты выпускаются на год, их нужно своевременно перевыпускать. Если планируется использовать внешние программы чтения почты с сертфиикатами (типа MailDroid) - обязательно наличие доступного и действующего CRL, без него расшифровка в MailDroid например может и не пойти.
- возможно такой способ сделать это целиком на винде есть, но мне он неизвестен. Раньше я использовал виндовый CA и это реально была попаболь - создать CSR на линухе, вставить его в веб-интерфейс службы CA на винде, экспортировать сертификат в линух, собрать PKCS#12... С некоторых пор я все это делаю на линухе.

UPD: Пиши, еслиф че. Мыло в профиле. Почтовые сертификаты - тема огого какая.

Второй тип - излишняя сущность. Админ домена имеет все права на все компы домена. Делить админов на "админов серверов" и "админов десктопов" конечно можно, но это если контора с тысячами машин...
Как именуем сейчас не скажу, но приведу пару примеров именования в прежних конторах:
(Юзер - Иван Петрович Сидоров)

- i.sidorov (юзер), i.sidorov.adm (админ)
- sidorov-ip (юзер), adm_sidorov-ip (админ)

Где-то в районе прошлой осени в "Системном администраторе" была статья на тему настроек squid и доступа по группам

В конце 2019 года незадолго до того, как сдохнуть в "Системном администраторе" была пара статей по настройке squid по аутентиифкации через керберос и управлении группами через AD. Задача вполне решаема на одном прокси. Она решаема даже без управления группами, но там в статье еще про бампинг, без которого нынче весь контроль доступа сьеживается до контроля первичного захода и то при условии, что DoH не задействован или сервера DoH заблокированы.

Я бы посоветовал что-то, но боюсь автор может последовать моему совету буквально...

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

Пардон, вот это классический пример того, что бывает, когда вместо вникания в суть - ограничиваемся копипастом :)

Авторизация в сквиде - это отдельная тема десятка статей :) Она делается не менее чем тремя способами, но актуален в настоящее время только один - через negotiate_kerberos_auth. Там довольно длинная процедура, я ее уже плохо помню, была статья в "Системном администраторе", давненько правда, еще в 2012 году. Статья называлась "Squid + AD - samba"
Создается учетка в AD
К ней вяжется принципал через ktpass (это виндовая команда)
Этот принципал указывается в конфиге сквида и получается что-то типа:

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/proxy.keytab -s HTTP/fat.zhopa.ruchka@ZHOPA.RUCHKA
auth_param negotiate children 30 startup=0 idle=1
auth_param negotiate keep_alive on

Если нужно рулить еще и группами (а иначе зачем wbinfo_group.pl?) - то в том же Системном администраторе в прошлом году незадолго до того, как ему сдохнуть - была статья про управление группами

Смешались в кучу кони, люди...

"Домен" с точки зрения AD и домен например zhopa.ru - это две кардинальные разницы. Внутренняя инфраструктура сети всегда закрывается от внешней (и в MS есть даже специальный сервис для проброса оной наружу - ADFS)

Поэтому:
- убирайте нафиг ваш DC за роутер
- разворачивайте на нем DNS
- называйте его как угодно, это имя не имеет никакого значения (для тырнета)
- изнутри цепляетесь либо по IP либо по имени

Никак. Сеть не потянет, если у Вас там не оптика на 10G. Так себе идея. Вы сомневаетесь в надежности Windows ACL, что ли? Зря.

Все роли передали с первого DC на второй?

Едрить, negotiate_kerberos_auth работает с неведомо лохматых времен, года ... ну у же не помню, с 2010 наверное... Еще есть ext_kerberos_ldap_group_acl - что эа любовь к некрософту? Разве SquidGuard еще жив?

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

Настроен squid с интеграцией через керберос с AD

В случае отключения основного DC1, squid при запуске браузера начинает запрашивать логин пароль

Ну значит либо такая интеграция, либо такая AD. Потому что в нормальной AD MS где-то там внутри себя обеспечивает переключение между DC.

Строку auth_param, которая настраивает интеграцию с AD покажите