Переход на репликацию SYSVOL по DFS

Предварительные требования

• Все контроллеры домена должны быть обновлены до функционального уровня Windows Server 2008 или выше
• Перед процедурой миграции необходимо выполнить принудительную полную миграцию разделов Active Directory на каждом из контроллеров домена, выполнив: 

Repadmin /syncall /force /APed

Убедится что репликация работает имеется множество способов один из которых:
Active Directory Replication Status Tool

repadmin /showrepl

Проверяем состояние sysvol

Dcdiag /e /test:sysvolcheck /test:advertising

Проверим состояние службы DFS, выполнив команды:

dfsrmig /getGlobalState

dfsrmig /getmigrationstate 

Начало миграции.

1. Установим флаг подготовки к миграции (global state:
Prepared), выполнив команду:

dfsrmig /setGlobalState 1

2. Текущее состояние контроллеров проверим командой:

dfsrmig /getmigrationstate,

Перенаправление продуктивной папки

• Прежде чем перейди к следующему этапу миграции (состояние Redirected), необходимо убедиться что:
• Все контроллеры домена находятся в состоянии Prepared. Удостоверьтесь, что шара SYSVOL еще доступна.

1. Перейдем к следующему этапу миграции, набрав

dfsrmig /setGlobalState 2

2. Убедимся, что все контроллеры домена находятся в статусе Redirected:

dfsrmig /getmigrationstate

Удаляем каталог SYSVOL

Примечание! Процесс удаления («Eliminated«) не может быть отменен!
Прежде чем перейди в режим Elminated, необходимо убедиться что:

• Все контроллеры домена находятся в статусе Redirected
• Шара SYSVOL все еще доступна

1. Набираем команду:
dfsrmig /setGlobalState 3
2. Проверяем статус командой:
dfsrmig /getmigrationstate
В результате каталог SYSVOL будет мигрирован в папку SYSVOL_DFSR. Теперь для репликации SYSVOL применяется механизм DFS.

Поиск источника блокировки пользователя в Active Ditectory

В работе администратора домена Active Directory довольно часто возникает необходимость найти причину блокировки пользователя. Иногда причиной блокировки пользователя является заражённый вирусом ПК — в таких случаях особо важна скорость обнаружения источника проблемы.

Необходимые исходные условия.

 Должны быть включены следующие подкатегории аудита на контроллерах домена:

Категория аудита	Подкатегория аудита	Тип аудита	Интересующий нас eventID
Audit Account Logon Events (Вход учётной записи)	Kerberos Authentication Service (Аудит службы проверки подлинности Kerberos)	Отказ	4771 Kerberos pre-authentication failed.
Audit Logon Events (Вход/Выход)	Logon (Аудит входа в систему)	Отказ	4625 An account failed to log on.
Audit Logon Events (Вход/Выход)	Account Lockout (Аудит блокировки учётных записей)	Успех	4740 Account locked

Сеанс повторно подключен к рабочей станции.                                         4778

Алгоритм поиска источника блокировки

1. Определить какой контроллер является владельцем роли PDC-эмулятора
2. Найти в журнале безопасности PDC-эмулятора событие с кодом 4740 в поле «TargetUserName», которого указано имя интересующего нас пользователя
3. В поле «TargetDomainName» того же события найти имя контроллера домена, обслужившего авторизацию
4. Найти в журнале безопасности контроллера, обслужившего авторизацию, событие с кодом 4625 (неуспешная NTLM авторизация) или 4771 (неуспешная kerberos авторизация)
5. Из найденного события получить значения полей «IpAddress» — адрес ПК с которого была попытка авторизации

Этих действий будет достаточно для быстрого поиска ПК с вредоносным ПО, подбирающим пароли пользователей. Алгоритм поиска процесса непосредственно вызывающего блокировку пользователя сильно зависит от ПО, установленного на конечном ПК.

Удаление “потерявшихся” доменов

Имеется ситуация – в AD домен, 2 контроллера домена. Было настроено давно. С тех пор куда всё это делось непонятно. В общем пропало и не доступно. В связи с этим куча ошибок при репликации о несуществующем домене. Удалить через dcpromo такой домен не получится, так как физического доступа к “пропавшим” контроллерам домена нет. Решается эта проблема довольно просто с помощью ntdsutil.
1. Сначала удаляем “потерявшиеся” контроллеры домена.
2. Потом удаляем “потерявшийся” домен.
3. Удаляем в DNS записи о “потерявшемся” домене.
У меня между шагом 1 и 2 возникла проблема. При попытке удалить домен выскочила ошибка “DsRemoveDsDomainW error 0x2015″. Как это лечить описано здесь.

Дубликаты интегрированных в AD DNS-зон

С проблемой озвученной в заголовке столкнулся в процессе поиска решения проблемы с регистрациями рабочих станций во внутренней DNS-зоне домена. При вводе сервера в домен всё проходило штатно. Через некоторое время сервер переставал пинговаться, а его имя разрешаться в ip-адрес. При просмотре DNS имя сервера не находилось, хотя оно там должно было бы быть. Неприятная ситуация.
Теперь немного теории. Начиная с Windows Server 2003 доступны три варианта репликации DNS-зон с Active Directory:

• “To all DNS servers in the AD forest”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы леса. Сам объект зоны с записями будет располагаться в разделе ForestDnsZones (полное имя – CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках всего леса.
• “To all DNS servers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы домена. Сам объект зоны с записями будет располагаться в разделе DomainDnsZones (полное имя – CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках домена.
• “To all domain controllers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все контроллеры домена в домене. Сам объект зоны с записями будет располагаться в разделе Default Naming Context (полное имя – CN=MicrosoftDNS,CN=System,DC=domain,DC=com). Репликация зоны будет происходить между контроллерами конкретного домена. Этот вариант используется в домене, в котором присутствуют контроллеры домена на базе Windows 2000 Server. Последние не знают о наличии разделов ForestDnsZones/DomainDnsZones, соответственно не могут с ними работать.

Возникает вопрос – а что будет, если некоторая интегрированная с AD DNS-зона будет присутствовать в нескольких разделах приложений:

• У нас имеется домен на базе Windows 2000 Server (которые не знают о наличии разделов ForestDnsZones/DomainDnsZones). При вводе нового контроллера домена на базе Windows Server 2003 мы можем указать для DNS-зоны тип репликации, который не поддерживается старыми контроллерами домена.
• При создании зоны вручную, мы можем выбрать любой из первых двух вариантов репликации. Затем, на другом контроллере домене, не дождавшись пока эта DNS-зона отреплицируется, создать её тоже вручную.
• При вводе нового контроллера домена, автоматически может ставиться роль DNS-сервера. При этом, существующие зоны, находящиеся в разделах ForestDnsZones/DomainDnsZones, будут среплицированы на новый контроллер домена. Ничто не мешает нам, не дождавшись завершения такой репликации, вручную создать эти зоны.

Стоит заметить, что все эти варианты возникают из-за человеческого фактора и они более чем возможны. Таким образом мы можем относительно легко задублировать зоны, что как раз приведёт к эффекту пропадания записей в задублированной зоне. В ADSI Edit выглядеть задублированная зона будет примерно следующим образом:

Записи, начинающиеся с ..InProgress-[GUID], указывают на зоны, репликация которых не смогла завершиться успешно из-за наличия дубликатов с другим номером USN. Записи, содержащие CNF:[GUID], указывают на зоны, содержащие дубликаты в базе AD.
Что с этим делать? Дубликаты необходимо удалить. Проще всего это сделать через ADSI Edit, удалив записи, которые содержат ..InProgress-[GUID] и CNF:[GUID].

Полное тестирование Active Directory на ошибки

1. Первым делом нужно запустить общий тест:

netdom query fsmo

dcdiag /e /v /q

dcdiag /n:local /e /v /f:c:\adtest.log

Ключи /q можно убрать если нужна информация не только об ошибках.
2. Проверим здоровье DNS серверов. Выполним команду на одном из контроллеров домена:



DCDiag /Test:DNS /e /v /s:controller.contoso.com >DcdiagDNS.txt

дальше полученный отчет открываем:

notepad dcdiagdns.txt

Если всё хорошо то увидим везде слово PASS:

Если полученные ошибки ручками не получается поправить - пробуем:

DCDiag /Test:DNS /e /v /s:controller.contoso.com /fix

А также ipconfig /registerdns на контроллерах.

3. Теперь проверим здоровье репликации Active Directory.

Запускаем общую проверку статуса репликации на контроллере:

repadmin /replsum

Получаем:

 Если значение наиб. дельты не боле часа - с репликацией всё в порядке. Количество сбоев должно быть равно 0.

Если же возникли ошибки то можно использовать следующую команду чтобы посмотреть какой контекст наименования не реплицируется:

repadmin /showreps

Получим такой вывод:

4. Диагностика службы времени.

Общая проверка синхронности часов на контроллерах:

w32tm /monitor

Получим:

Смещение не должно быть больше или меньше 0 целых на всех контроллерах. В нашем случае +2 секунды на одном из них. Как это исправить читаем тут.

5. Диагностика групповых политик.

Сначала проверим расшаренные папки SYSVOL и Netlogon. Через них распространяются групповые политики.

Проверим расшарены ли эти папки. На каждом контроллере домена:

net share

Получаем такой результат:

Всё в порядке шАры на месте.

Теперь тест dcdiag:

dcdiag /test:netlogons

Если тест пройден увидим следующее:

В этом случае с шарами всё в порядке.

Чтобы проверить применяются ли GPO можно запустить мастер результатов групповой политики из оснастки Управление групповой политикой (GPMC). Либо выполнить следующую команду:

gpresult /user domainuser /z >gpresult.txt поправить тут

notepad gpresult.txt

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