Настройка dns на rodc
Составил для вас список DNS серверов, показал одну важную настройку, чтобы интернет соединение при их использовании было стабильным, а также объяснил, как решить проблему, когда уведомления долгое время не исчезают с экрана вашего смартфона Xiaomi.
Уведомления не пропадают с экрана
После очередного обновления MIUI (эта фраза становится классикой), некоторые пользователи обратили внимание на то, что уведомления (например о включении беззвучного режима и так далее) отображаются на экране слишком долго. Без сомнения, это доставляет дискомфорт при использовании смартфона.
Как оказалось, это очередной «подарок» от заботливых разработчиков, который автоматически активируется в настройках MIUI. Решение проблемы простое, но неочевидное и если вы столкнулись с подобным, сделайте следующее:
Для начала заходите в «Настройки» —> Расширенные настройки и следуете в пункт «Спец. Возможности». Далее переходите во вкладку «Физические», находите пункт «Время на выполнение действий» и выставляете значение «По умолчанию»
После этого отображение уведомлений будет происходить в стандартном режиме и перестанет раздражать своим долгим присутствием на экране.
Правильная настройка DNS
В одном из прошлых материалов, я обещал вам более подробно коснуться вопроса настройки DNS серверов, чем мы сегодня и займёмся.
Объяснение того зачем они нужны, можно уместить в нескольких словах: Отключение рекламы и в некоторых случаях улучшение работы интернета. Все, представленные ниже сервера, проверены на работоспособность, но советовать какой-то конкретный я не стану, так как для каждого пользователя результат будет своим, стало быть вам придётся потратить немного времени на подбор оптимального.
Для начала заходите в «Настройки» —> Подключение и общий доступ —> Частный DNS сервер и выбираете «Имя хоста провайдера DNS»
После этого, в появившейся строке пишите адрес любого из серверов представленных на следующем изображении.
Введение
В Windows Server 2008, Microsoft решила вернуть функцию, которую мы не видели со времен Windows NT: это технология контроллеров домена, доступных только для чтения. В этой статье я расскажу про технологию Read Only Domain Controllers и ее преимущества. Я ранее не раз упоминал об этой технологии в своих статьях, например в статье про использование утилиты adprep в Windows 2008.
Хорошим примером циклического характера развития IT технологий является новая функция Windows Server 2008, которая называется Read Only Domain Controller, или RODC. Ведь эта технология впервые появилась уже давно, однако протяжении последних 10 лет практически не применялась.
Windows NT была первой серверной ОС от Microsoft. Как и современные операционные системы Windows Server, Windows NT полностью поддерживала технологию доменов. Одним отличием был тот факт, что только один контроллер домена в каждом домене был доступен для записи. Этот контроллер домена, называемый Primary Domain Controller или PDC, был единственным контроллером домена, в который администратор мог вносить изменения. Основной контроллер домена затем передавал обновления на другие контроллеры домена в домене. Эти контроллеры домена назывались резервными контроллерами домена (backup domain controllers или BDC), и информация на них обновлялась только при обновлении основного контроллера домена, для клиентов домена они были доступны только на чтение.
И хотя эта доменная модель была полностью работоспособной, у нее были и существенные недостатки. В частности, проблемы с основным контроллером домена могли парализовать работу всего домена целиком. Как вы знаете, Microsoft внесла значительные изменения в доменную модель, которую они внедрили в свою новую серверную ОС Windows 2000 Server. В Windows 2000 Server появились две новые технологии для контроллеров доменов, и оба этих нововведения используются и по сей день: это Active Directory и модель с несколькими основными контроллерами (multi master модель).
И хотя роль PDC все еще сохранялась, остальные контроллеры домена в мульти-мастерной конфигурации были доступными на запись. Это означало, что администратор может внести изменения на любом контроллере домена, и эти изменения в виде обновлений в конечном итоге будут распространены на все другие контроллеры домена в сети.
Как вы видите, RODC, являются не чем иным, как пережитком времен Windows NT. Безусловно, Microsoft не вернула бы технологию RODC, если бы не усмотрела бы в их применении существенных преимуществ.
Прежде чем приступить к объяснению того, почему Microsoft решила вновь вернуться к RODC, позвольте мне пояснить, почему использование RODC не является обязательным условием работы с доменами Active Directory в 2008 Server. Если вы хотите, чтобы каждый контроллер домена в вашем лесу был доступен для записи, вы, безусловно, может сделать это.
Я хочу вкратце упомянуть, что несмотря на то, что RODC, очень похожи на резервные контроллеры домена (BDC) в NT, они претерпели ряд изменений. Есть несколько вещей, которые являются новинками в технологии RODC, и я хочу о них рассказать.
Итак, почему Microsoft решила вернуть RODC? Это связано с проблемами поддержки филиальной сети (подразделений и филиалов). Офисы филиалов традиционно достаточно трудно сопровождать и поддерживать из-за их удаленности и особенностей связи между головным офисом и филиалом.
Традиционно применялось несколько различных способов управления филиалами, но каждый из них имел свои собственные преимущества и недостатки. Одним из наиболее распространенных способов организации филиальной сети является установка всех серверов в главном офисе, и предоставление доступа к ним пользователей филиала через глобальную сеть (WAN).
Конечно, наиболее очевидным недостатком такого метода является то, что если канал WAN нестабилен или отвалился, то пользователи, которые находятся в филиале, не в состоянии нормально работать, т.к. они полностью отрезаны от всех ресурсов центрального офиса. Даже если сетевое соединение с головным офисом стабильно, зачастую производительность WAN соединения может быть невысока из-за нагрузки на канал или непосредственно скорости соединения
Другим распространенным вариантом при работе с удаленными филиалами является подход, предусматривающий установку по крайней мере одного контроллера домена в филиал. Часто, этот контроллер домена также выступает в качестве сервера DNS и сервера глобального каталога. Таким образом, даже если WAN подключение разрывается, то пользователи в филиале, по крайней мере, имеют возможность войти в сеть. В зависимости от характера работы организации, в филиальном подразделении могут устанавливать и другие сервера.
Хотя это решение, как правило, работает довольно неплохо, и у него есть ряд недостатков. Основным недостатком является стоимость. Размещение серверов в филиалах требует от предприятия вкладывать деньги в серверное оборудование и лицензии на программное обеспечение. Существенно увеличиваются также затраты на поддержку. Организация должна определить, нужен ли в филиале штат собственных ИТ-специалистов, или в случае неполадок, она готова ждать пока ИТ-персонал из центрального офиса доберется в филиал.
Еще один нюансом при установке собственных серверов в филиале, является вопрос безопасности. В моем опыте нередки случаи, при которых сервера, которые расположены за пределами центрально датацентра, оставались банально без присмотра. Часто сервера просто закрывают в шкафу на ключ!
Как я упоминал ранее, WAN соединения часто бывают медленным и ненадежным. В этом кроется еще одна проблема с размещением серверов в филиале. Трафик репликации контроллеров домена может существенно загрузить такое соединение
Вот это как раз тот случай, когда можно использовать RODC. Размещение RODC в филиал не избавляет совсем от трафика репликации Active Directory, но существенно снижает нагрузку на bridgehead сервера, т.к. они получают только входящий трафик репликации.
RODC могут также способствовать повышению безопасности, ведь персонал в офисе филиала не сможет внести изменения в базу данных Active Directory. Кроме того, никакой информации обо всех пользователях домена и их учетках, не передаются на RODC. Это означает, что если кто-то украл сервер RODC, он не сможет воспользоваться информацией, полученной в результате взлома паролей пользователей.
В следующих статьях этой серии, мы обсудим процесс планирования и развертывания контроллеров домена, доступных только для чтения.
В этой статье мы рассмотрим, как установить новый контроллер домена RODC на базе Windows Server 2022/2019 и особенности управления им.
Что такое контроллера домена на чтение RODC?
Основные отличия RODC от обычных контроллеров домена, доступных для записи (RWDC):
- Контроллер домена RODC хранит копию базы AD, доступную только для чтения. Клиенты не могут вносить изменения в базу такого контролера домена;
- RODC не реплицирует данные AD и папку SYSVOL на другие контроллеры домена (RWDC) (используется односторонняя репликация);
- Контроллер RODC хранит полную копию базы AD, за исключением хэшей паролей объектов AD и других атрибутов, содержащих чувствительную информацию. Этот набор атрибутов называется FilteredAttributeSet(FAS). Сюда относятся такие атрибуты, как ms-PKI-AccountCredentials, ms-FVE-RecoveryPassword, ms-PKI-DPAPIMasterKeys и т.д. Можно добавить и другие атрибуты в этот набор, например пароли компьютеров, хранящиеся в открытом виде в атрибуте ms-MCS-AdmPwd при использовании LAPS;
- При получении контроллером RODC запроса на аутентификацию от пользователя, он перенаправляет этот запрос на ближайший RWDC контроллер;
- Контроллер RODC может кэшировать учетные данные некоторых пользователей (это ускоряет аутентификацию и позволяет пользователям авторизоваться на контроллере домена, даже при отсутствии связи с RWDC);
- Вы можете относительно безопасно предоставить административный доступ и RDP вход на контроллер домена пользователям без предоставления прав на других DC или Domain Admins (например, для доступа к серверу техническому специалисту филиала);
- DNS служба на RODС работает только на чтение.
Требования, которые должны быть выполнены для разворачивания Read-Only Domain Controller.
- На сервере должен быть назначен статический IP;
- Windows Firewall должен быть отключен или корректно настроен для прохождения трафика между DC и доступов от клиентов;
- В качестве DNS сервера должен быть указан ближайший RWDC контроллер;
- Вы можете установить RODC как на Windows Server Full GUI, так и на Windows Server Core редакцию.
- Не стоит размещать RODC в одном сайте с RWDC.
Установка RODC из графического интерфейса Server Manager
Откройте консоль Server Manager и добавьте роль Active Directory Domain Services (согласитесь с установкой всех дополнительных компонентов и средств управления).
На этапе указания настроек нового DC, укажите что нужно добавить новый контроллер домена в существующий домен (Add a domain controller to an existing domain), укажите имя домена и, если необходимо, данные учетной записи пользователя с правами администратора домена.
Выберите, что нужно установить роль DNS сервера, глобального каталога (GC) и RODC. Далее выберите сайт AD, в котором будет находится новый контролер и пароль для доступа в DSRM режиме.
Далее нужно указать пользователя, которому нужно предоставить административной доступ к контроллеру домена (Delegated administrator account), а также список учетных записей/групп, пароли которых разрешено (Accounts that are allowed to replicate passwords to the RODC) и запрещено (Accounts that are denied from replicating passwords to the RODC) реплицировать на данный RODC (можно задать позднее).
Укажите, что данные базы AD можно реплицировать с любого DC.
Replicate from -> Any domain controller
Затем укажите пути к базе NTDS, ее журналам и папке SYSVOL (в случае необходимости их можно перенести на другой диск позднее).
После проверки всех условий, можно запустить установку роли ADDS.
Также вы можете развернуть RODC с помощью функции Staged. Она заключается в предварительном создании учетной записи компьютера RODC в консоли ADUC и базовой настройки. Для этого щелкните правой кнопкой по контейнеру Domain Controllers и выберите Pre-create Read-Only Domain Controller account.
При установке ADDS на сервере с таким же именем, появится надпись:
Выберите опцию Use existing RODC account, чтобы использовать настроенный аккаунт RODC в AD.
После завершения установки роли и перезагрузки сервера вы получите RODC контроллер. Вы можете проверьте состояние контроллера домена согласно статье.
При подключении консолью ADUC (dsa.msc) к RODC все кнопки создания новых объектов AD станут неактивными (серыми). Также на RODC нельзя изменить атрибуты объектов AD. Все остальные действия в консоли Active Directory, в том числе поиск, работают как обычно.
Установка контроллера домена на чтение (RODC) с помощью PowerShell
Для разворачивания нового RODC с помощью PowerShell, нужно установить роль ADDS и PowerShell модуль ADDS.
Add-WindowsFeature AD-Domain-Services, RSAT-AD-AdminCenter,RSAT-ADDS-Tools
Теперь можно запустить установку RODC:
Install-ADDSDomainController -ReadOnlyReplica:$true -DomainName yourdimain.com -SiteName "Default-First-Site-Name" -InstallDns:$true -NoGlobalCatalog:$false
После окончания работы командлет запросит перезагрузку сервера.
Get-ADDomainController -Filter * | Select-Object Name,IsReadOnly
У RODC значение атрибута IsReadOnly должно быть True
Чтобы вывести все RODC в домене, выполните:
Если вы хотите сначала создать аккаунт RODC в домене, исопльзуйте такую команду:
Add-ADDSReadOnlyDomainControllerAccount -DomainControllerAccountName SPB-RO-DC1 -DomainName winitpro.ru -DelegatedAdministratorAccountName "winitpro\kbuldogov" -SiteName SPB_RO_Site
Затем при повышении Windows сервер до DC используйте команду:
Install-ADDSDomainController -DomainName winitpro.ru -Credential (Get-Credential) -LogPath "C:\Windows\NTDS" -SYSVOLPath "C:\Windows\SYSVOL" -ReplicationSourceDC "SPB-DC01.winitpro.ru" – UseExistingAccount
С помощью PowerShell вы также не сможете изменить атрибуты объектов AD при подключении к RODC. Если вы хотите изменить атрибуты объекта из сайта с RODC, указать адрес ближайшего RWDC с помощью параметра –Server , который доступен у командлетов Set-ADUser, Set-ADComputer, New-ADUser и т.д.Политики репликации и кэширования паролей на RODC
На каждом RODC можно задать список пользователей, компьютеров и серверов, чьи хэши пароли можно или нельзя реплицировать на данный контролер домена.
Все компьютеры, пользователи и сервера в кэше RODC смогут аутентифицироваться на этом контроллере домена, даже если отсуствет связь с RWDC.По умолчанию в домене создаются две новые глобальные группы
- Allowed RODC Password Replication Group
- Denied RODC Password Replication Group
Первая группа по умолчанию пуста, а во второй содержатся административные группы безопасности, пароли пользователей которых нельзя реплицировать и кэшировать на RODC с целью исключения риска их компрометации. Сюда по-умолчанию входят такие группы, как:
- Group Policy Creator Owners
- Domain Admins
- Cert Publishers
- Enterprise Admins
- Schema Admins
- Аккаунт krbtgt
- Account Operators
- Server Operators
- Backup Operators
В группу Allowed RODC Password Replication Group обычно добавляются группы пользователей филиала, в котором находится RODC.
Если в домене развернутся несколько контроллеров домена на чтение, лучше создать такие группы для каждого RODC. Привязка групп к контроллеру домена RODC выполняется в свойствах сервера в консоли ADUC на вкладке Password Replication Policy (подробнее).
В окне Advanced Password Replication Policy for RODC_name можно просмотреть:
- Accounts whose passwords are stored on this Read-Only Domian Controller – список пользователей и компьютеров, чьи пароли закешированы на этом RODC
- Accounts that have been authenticated to this Read-Only Domain – список пользователей и компьютеров, которые подключены через этот RODC
На вкладке Resultant Policy можно выбрать учетку пользователя и узнать, будет ли его пароль кэшироваться на RODC.
Вы можете управлять группами RODC с помощью PowerShell. Вывести список пользователей в группе AD:
Get-ADGroupMember -Identity "Denied RODC Password Replication Group" | ft Name, ObjectClass
Добавить в группу RODC всех активных пользователей из определенного OU Active Directory:
Get-ADUser -Filter -SearchBase 'OU=SPBOffice,DC=winitpro,DC=ru' | ForEach-Object
Чтобы закешировать пароль пользователей из OU на RODC, используйте скрипт:
$users = Get-ADUser -Filter -SearchBase 'OU=SPBOffice,DC=winitpro,DC=ru'
foreach ($user in $users) Get-ADObject -identity $user | Sync-ADObject -Source SPB-DC01 ‑Destination SPB-RO-DC1 -PasswordOnly
>
Вывести список пользователей и компьютеров, чьи пароли находятся в кэше RODC можно с помощью командлета:
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity SPB-RO-DC1 ‑RevealedAccounts
Нельзя удалить пароль определенного пользователя из кэша RODC. Но вы можете сделать эти данные недействительными, сбросив пароль пользователя из оснастки ADUC или с помощью Set-ADAccountPassword.
Одним из критически важных компонентов любой корпоративной сети, является сервер DNS. Практически все сетевые приложения основаны на использовании серверов DNS и их услугах, и в том случае если сервер DNS недоступен, практически вся сетевая активность может остановиться. Для того, чтобы обеспечить отказоустойчивость служб DNS, даже в случае выхода из строя сервера DNS, необходимо настроить как минимум один вторичный DNS сервер для каждой зоны.
■ To All DNS Servers In This Forest (на все DNS сервера в лесу) репликация выполняется на все сервера DNS в лесу Active Directory, на контроллеры домена с ОС Microsoft Windows Server 2003 и Windows Server 2008. Данный тип репликации используется, если имеется множество серверов DNS во множестве доменах в лесу.
■ To All DNS Servers In This Domain (на все DNS сервера в этом домене) репликация на все контроллеры домена в текущем домене. Данная опция используется по умолчанию для интегрированных зон Active Directory.
■ To All Domain Controllers In This Domain (на все контроллеры домена в этом домене) – репликация на все контроллеры, в том числе, запущенные на ОС Microsoft Windows 2000 Server. Данная опция используется только в том случае, если у вас в сети есть сервера DNS на Windows 2000 Server. При такой конфигурации объем трафика репликации увеличивается, т.к. выполняется репликация всех записей DNS.
■ To All Domain Controllers In The Scope Of This Directory Partition – репликация на все контроллеры домена в указанном разделе приложений, в том числе и на сервера с Windows 2000 Server. В такой ситуации данные DNS реплицируются на определенные сервера DNS с Windows 2000 Server, тем самым, уменьшая область репликации. Такая опция позволяет уменьшить объем трафика репликации, однако требует дополнительной настройки.
Как работает передача зон
Стандартные запросы DNS используют 53 порт UDP, а для передачи зон используется 53 порт протокола TCP. Протокол UDP более эффективен для пересылки запросов DNS, которые обычно состоят из двух составляющих: пакет с запросом, посылаемый на сервер DNS, и пакет с ответом, отправляемом серверов клиенту. Объем трафика передачи зон может быть достаточно большим (особенно для первой передачи зоны), поэтому решено использовать такие преимущества протокола TCP, как надежность и контроль передачи данных. Стоит отметить, что передача зоны является одним из потенциально уязвимых мест в безопасности сети, ведь получатель зоны может увидеть практически всю структуру вашей организации. К счастью, DNS сервер в Windows Server 2008 не позволяет передать зону на неавторизованные сервера. Для создания дополнительного эшелона защиты, на внешних межсетевых экранах следует закрыть 53 TCP порт (естественно, если это не будет препятствовать нормальной передаче зон).
В том случае, если и первичный и вторичный сервера DNS поддерживают инкрементальную передачу зон (эта функция появилась в Windows 2000 Server, в BIND 8.2.1 и более поздних версиях), будут передаваться только изменения в базе DNS. В том случае, если первичный или вторичный DNS сервер не поддерживает инкрементальную репликацию, каждый раз будет передаваться вся база данных целиком, а при большом количестве записей в зоне, эта передача может существенно утилизировать сеть.
Читайте также: