Для работы скрипта потребуется конфигурационный файл в формате *.csv, в котором будет содержаться информация о том, какие OU в домене будут использоваться для поиска учетных записей пользователей и заполнения ими определённых групп репликации паролей. Каждая строчка файла представляет собой связку DN доменной группы безопасности репликации паролей и DN OU. Файл должен иметь примерно такое содержание:
В одной из прошлых заметок я уже писал о проблеме выбора ближайшего RWDC при вводе в домен компьютера попадающего в сайт с RODC. В процессе перевода RODC на Windows Server 2012 на одной из удалённых площадок столкнулся с ситуацией, до боли напоминающей старую проблему… В процессе работы мастера повышения сервера до RODC при попытке выбрать в домене группу для Администраторов RODC или же группы для репликации паролей, диалоговое окно выбора доменных объектов не открывалось и возникала странная ошибка, говорящая о невозможности определения состояния RWDC находящегося совершенно “в другой степи” и не имеющего отношения ни к местному сайту ни к ближайшему RWDC.
Конечно можно было бы не менять настройки на этом шаге мастера и выполнить установку с настройками по умолчанию, а уже после окончания установки назначить группу Администраторов RODC и задать группы репликации паролей, но в голову пришла мысль о том, что выполнить повышение до RODC можно и с помощью PowerShell сразу указав при этом в явном виде все необходимые группы доступа. Собственно далее – небольшая шпаргалка как это сделать.
В большой доменной инфраструктуре AD DS с большим количеством сайтов можно столкнуться с ситуацией, когда при вводе в домен новых компьютеров в сайте с единственным контроллером RODC операция ввода в домен происходит не на ближайшем RWDC а на отдалённом. Это приводит к тому, что перед тем как можно будет начать использовать в домене такой компьютер, потребуется выждать репликацию от удалённого DC до местного RODC. Избежать данной ситуации можно используя утилиту NETDOM, явным образом указывая ближайший контроллер домена, на котором мы хотим произвести процедуру джойна:
Но так как по умолчанию в клиентских системах этой утилиты нет, хочется воспользоваться каким-то подручным средством без выполнения дополнительным манипуляций. И тут нам на помощь приходит PowerShell с командлетом Add-Computer… но когда я решил воспользоваться им на практике, то выяснилось что встроенный хелп PowerShell об этом командлете (равно как и сайт TechNet Script Center) о чём-то нам не договаривает.
Попытка выполнить ввод в домен строго по описанию не сработала, то есть при использовании командлета в виде…
Как видно из лога, имя домена формируется как то не совсем адекватно. Немного поигравшись с использованием разных вариантов передачи параметров и проведя аналогию с использованием утилиты NETDOM, был найден работающий вариант, а именно:
То есть вместо параметра Server можно использовать передачу имени DC в параметре DomainName. Данный способ проверен и работает как на Windows 7, так и на Windows XP SP3.
Если у кого-то есть комментарии по поводу того, как можно ещё обуздать механизм ввода в домен для компьютеров в сайте с RODC будет интересно их здесь услышать.
При использовании контроллеров домена «только на чтение» (RODC) для каждого RODC должна быть определена доменная группа безопасности, в которую входят учетные записи пользователей, чьи учетные данные могут реплицироваться на этот RODC. В крупной географически распределённой инфраструктуре с большим количеством контроллеров домена задача поддержания состава этих групп безопасности «в рукопашную» может стать проблемой, особенно если учесть «человеческий фактор», когда например, в каком-то из удалённых подразделений местный администратор создаёт новую учетную запись доменного пользователя, а включить в группу репликации паролей эту запись забывает. Для того чтобы исключить в данном случае «человеческий фактор», можно автоматизировать данный процесс с помощью PowerShell. Рассмотрим пример скрипта, который можно включить в планировщик задач на контроллере домена на периодическое выполнение.
Как и в предыдущей заметке было решено оптимизировать скрипт изложенный ранее в заметке PowerShell – Поддержание групп безопасности политики репликации паролей RODC в актуальном состоянии для выполнения с использованием новых командлетов из PowerShell модуля ActiveDirectory на Windows Server 2012 R2 таким образом, чтобы в результате работы скрипта не происходило полное переписывание членства пользователей в группах безопасности. 
При использовании контроллеров домена «только на чтение» (RODC) для каждого RODC должна быть определена доменная группа безопасности, в которую входят учетные записи пользователей, чьи учетные данные могут реплицироваться на этот RODC. В крупной географически распределённой инфраструктуре с большим количеством контроллеров домена задача поддержания состава этих групп безопасности «в рукопашную» может стать проблемой, особенно если учесть «человеческий фактор», когда например, в каком-то из удалённых подразделений местный администратор создаёт новую учетную запись доменного пользователя, а включить в группу репликации паролей эту запись забывает. Для того чтобы исключить в данном случае «человеческий фактор», можно автоматизировать данный процесс с помощью PowerShell. Рассмотрим пример скрипта, который можно включить в планировщик задач на контроллере домена на периодическое выполнение.
Последние комментарии