Проблемы с проверкой подлинности kerberos, когда пользователь принадлежит к многим группам

Настройка многофакторной проверки подлинности на глобальном уровне

1. В диспетчере сервера щелкните Средства и выберите Управление AD FS.

2. В AD FS оснастке щелкните политики проверки подлинности.

3. в разделе многофакторная проверка подлинности щелкните изменить рядом с параметром глобальный Параметры. Можно также щелкнуть правой кнопкой мыши политики проверки подлинностии выбрать пункт изменить глобальную многофакторную проверку подлинностиили в области действия выберите изменить глобальную многофакторную проверку подлинности.

4. В окне изменение политики глобальной проверки подлинности на вкладке многофакторная идентификация можно настроить следующие параметры в рамках глобальной политики многофакторной проверки подлинности:

   • Параметры или условия для MFA через доступные параметры в разделах пользователи, группы, устройстваи расположения .

   • Чтобы включить MFA для любого из этих параметров, необходимо выбрать по крайней мере один дополнительный метод проверки подлинности. Параметр Проверка подлинности по сертификату доступен по умолчанию. можно также настроить другие дополнительные методы проверки подлинности, например Windows Azure Active authentication. Дополнительные сведения см. в разделе Пошаговое руководство. Управление рисками с помощью дополнительной многофакторной проверки подлинности для конфиденциальных приложений.

Предупреждение

Дополнительные методы проверки подлинности можно настраивать только глобально.

настройка основной проверки подлинности глобально в Windows Server 2012 R2

1. В диспетчере сервера щелкните Средства и выберите Управление AD FS.

2. В AD FS оснастке щелкните политики проверки подлинности.

3. в разделе основная проверка подлинности щелкните изменить рядом с параметром глобальный Параметры. Можно также щелкнуть правой кнопкой мыши политики проверки подлинностии выбрать пункт изменить глобальную основную проверку подлинностиили в области действия выберите изменить глобальную основную проверку подлинности.

4. В окне изменение политики глобальной проверки подлинности на главной вкладке можно настроить следующие параметры в рамках глобальной политики проверки подлинности.

   • Методы проверки подлинности, используемые для основной проверки подлинности. В экстрасети и интрасетиможно выбрать доступные методы проверки подлинности.

   • Проверка подлинности устройства с помощью флажка включить проверку подлинности устройства . Дополнительные сведения см. в разделе Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

LastLogonTimeStamp

     LastLogonTimeStamp is the replicable attribute but this attribute is not updated every time a user successfully logs in. This attribute is updated only when its current value is older than the current time minus the value of the msDS-LogonTimeSyncInterval attribute.

Example

Consider the user User1 anddomain controller DC1.

     i.e. msDS-LogonTimeSyncInterval = 14 days
     i.e. Current value of LastLogonTimeStamp = T1 (current value)

Take User1 logs in to DC1 on the time T2 (current time)

   LastLogonTimeStamp value will be updated only if the following case get satisfied.

    If  (T2-14 days) >T1  then LastLogonTimeStamp is updated by the value T2 or else it remain as T1.

Симптомы

При этой проблеме возникает один или несколько следующих симптомов:

• DCDIAG сообщает, что тест репликации Active Directory не справился с ошибкой и 2146893022: целевое основное имя некорректно.

• Repadmin.exe сообщает о сбой попытки репликации и сообщает о состоянии -2146893022 (0x80090322).

  Команды, которые обычно указывают состояние -2146893022 (0x80090322) включают, но не ограничиваются следующими:

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

• Команда репликации в Active Directory Sites and Services возвращает следующее сообщение об ошибке:Целевое основное имя неверно

  Щелкнув правой кнопкой мыши по объекту подключения из источника DC, а затем выбрав репликацию, теперь не удается. Сообщение об ошибке на экране следующим образом:

• Проверка согласованности знаний NTDS (KCC), NTDS General или события Microsoft-Windows-ActiveDirectory_DomainService с состоянием -2146893022 регистрируются в журнале событий службы каталогов.

  События Active Directory, которые обычно ссылаются на состояние -2146893022, включают, но не ограничиваются следующими:

  Источник событий	Код события	Строка события
  Репликация NTDS	1586	Контрольно-Windows NT 4.0 или более ранней репликации с мастером эмулятора PDC не удалось.Полная синхронизация базы данных диспетчера учетных записей безопасности (SAM) с контроллерами доменов, работающими Windows NT 4.0 и ранее, может произойти, если главную роль эмулятора PDC перед следующей успешной контрольной точкой передадут локальному контроллеру домена.
  NTDS KCC	1925	Попытка установить ссылку на репликацию для следующего раздела каталога writable не удалась.
  NTDS KCC	1308	Проверка согласованности знаний (KCC) обнаружила, что последовательные попытки репликации со следующим контроллером домена последовательно срывались.
  Microsoft-Windows-ActiveDirectory_DomainService	1926	Попытка установить ссылку репликации на раздел каталога только для чтения со следующими параметрами не удалась
  Обмен сообщениями между сайтами NTDS	1373	Служба обмена сообщениями intersite не может получать сообщения для следующей службы с помощью следующего транспорта. Сбой запроса для сообщений.

Причина

Код ошибки 2146893022 0x80090322 SEC_E_WRONG_PRINCIPAL не является \ \ ошибкой Active Directory. Он может быть возвращен следующими компонентами нижнего слоя для различных корневых причин:

• RPC
• Kerberos;
• SSL
• LSA
• NTLM;

Ошибки Kerberos, которые Windows кодом на -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL включают:

• KRB_AP_ERR_MODIFIED (0x29 / 41 десятичной / KRB_APP_ERR_MODIFIED)
• KRB_AP_ERR_BADMATCH (0x24h / 36 десятичных «Билет и аутентификация / не совпадают»)
• KRB_AP_ERR_NOT_US (0x23h / 35 десятичных / «Билет не для нас»)

Некоторые конкретные корневые причины для \ -2146893022 0x80090322 \ SEC_E_WRONG_PRINCIPAL включают:

• Сопоставление с плохим именем и IP в DNS, WINS, HOST или LMHOST-файле. Это привело к подключению контроллера домена назначения к неправильному контроллеру домена источника в другой области Kerberos.

• Контроллер домена KDC и исходный домен имеют различные версии пароля учетной записи компьютера контроллера домена источника. Так что целевой компьютер Kerberos (контроллер домена источника) не мог расшифровать данные проверки подлинности Kerberos, отправленные клиентом Kerberos (контроллер домена назначения).

• Служба управления не смогла найти домен для поиска SPN контроллера домена источника.

• Данные проверки подлинности в зашифрованных кадрах Kerberos были изменены с помощью оборудования (включая сетевые устройства), программного обеспечения или злоумышленника.

Дополнительная информация

Эта ошибка является одним из наиболее активных упражнений в следующей лаборатории практических действий TechNet: лаборатория практических действий TechNet: устранение ошибок репликации Active Directory.
В этой лаборатории вы пройдете этапы устранения неполадок, анализа и реализации часто встречающихся ошибок репликации Active Directory. Вы будете использовать сочетание ADREPLSTATUS, repadmin.exe и других средств для устранения неполадок в среде с пятью dc и тремя доменами. Ошибки репликации AD, с которыми сталкиваются в лаборатории, включают -2146893022, 1256, 1908, 8453 и 8606.

Пользователям запрещается доступ к развертыванию, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу

Эта проблема возникает в развертываниях с высоким уровнем доступности, в которых используются не менее двух брокеров подключений к удаленному рабочему столу и Remote Credential Guard в Защитнике Windows. Пользователям не удается войти на удаленные рабочие столы.

Эта проблема связана с тем, что Remote Credential Guard использует Kerberos для проверки подлинности, а также запрещает использовать NTLM. Но в конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos.

Если нужно использовать конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеров подключений к удаленному рабочему столу, эту проблему можно устранить, отключив Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье (Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows).

Сообщения о возможных ошибках и событиях

В следующей таблице описываются события, связанные с группой безопасности «Защищенные пользователи» и политиками проверки подлинности, используемыми для приемников команд.

Эти события фиксируются в журналах приложений и служб, расположенных по адресу Майкрософт\Windows\Проверка подлинности.

Для устранения неполадок с помощью этих событий см. разделы и .

Идентификатор события и журнал	Описание
101 AuthenticationPolicyFailures-DomainController	Причина: ошибка подключения при помощи протокола NTLM из-за настроек политики проверки подлинности. Событие фиксируется на контроллере домена, чтобы указать, что проверка подлинности с помощью NTLM оказалась неудачной, поскольку требуются ограничения управления доступом, которые не могут применяться для NTLM. Отображаются имена учетной записи, устройства, политики и приемника команд.
105 AuthenticationPolicyFailures-DomainController	Причина: отклонение из-за ограничений Kerberos произошло, потому что проверка подлинности не была разрешена для конкретного устройства. Событие фиксируется на контроллере домена, чтобы указать, что билет предоставления билетов Kerberos был отклонен, поскольку устройство не соответствует установленным ограничениям управления доступом. Отображаются имена учетной записи, устройства, политики и приемника команд, а также время жизни TGT.
305 AuthenticationPolicyFailures-DomainController	Причина: отклонение из-за ограничений Kerberos могло произойти, потому что не была разрешена проверка подлинности для конкретного устройства. В режиме аудита информация о событии фиксируется на контроллере домена, чтобы определить, был ли отклонен билет предоставления билета Kerberos из-за несоответствия устройства ограничениям управления доступом. Отображаются имена учетной записи, устройства, политики и приемника команд, а также время жизни TGT.
106 AuthenticationPolicyFailures-DomainController	Причина: отклонение из-за ограничений Kerberos могло произойти, потому что устройству пользователя не была разрешена проверка подлинности для подключения к серверу. Событие фиксируется на контроллере домена, чтобы указать, что билет службы Kerberos был отклонен, поскольку пользователь или устройство не соответствует установленным ограничениям управления доступом. Отображаются имена устройства, политики и приемника команд.
306 AuthenticationPolicyFailures-DomainController	Причина: отклонение из-за ограничений Kerberos могло произойти, потому что устройству пользователя не была разрешена проверка подлинности для подключения к серверу. В режиме аудита информация о событии фиксируется на контроллере домена, чтобы указать, что билет службы Kerberos будет отклонен, поскольку пользователь или устройство не соответствует ограничениям управления доступом. Отображаются имена устройства, политики и приемника команд.

LastLogon

    LastLogon is nothing but the latest time of a user logged on into AD based system, which is non replicable attribute. It means the value of this attribute is specific to Domain Controller. So we can’t say the user’s True LastLogon time by simply querying only one DC. To get an accurate value for the user’s last logon in the domain, the LastLogon attribute for the user must be retrieved from every domain controller in the domain. The largest value that is retrieved is the True LastLogon time for that user.

  Example

Consider the user User1and domain controllers DC1 and DC2.

• User1 logs in to DC1 on the time T1
• User1 logs in to DC2 on the time T2            

Таблица 5. Типы предварительной проверки подлинности Kerberos

Тип	Имя типа	Описание
—	Logon без предварительной проверки подлинности.
2	PA-ENC-TIMESTAMP	Это обычный тип для проверки подлинности стандартного пароля.
11	PA-ETYPE-INFO	Тип предварительной проверки подлинности ETYPE-INFO отправляется КДК в KRB-ERROR, указывающее требование о дополнительной предварительной проверке подлинности. Обычно он используется для уведомления клиента о том, какой ключ используется для шифрования зашифрованного времени для отправки значения предварительной проверки подлинности PA-ENC-TIMESTAMP.Никогда не видел этот тип предварительной проверки подлинности в среде Microsoft Active Directory.
15	PA-PK-AS-REP_OLD	Используется для проверки подлинности логотипа смарт-карты.
16	PA-PK-AS-REQ	Запрос, отправленный в KDC в сценариях проверки подлинности смарт-карт.
17	PA-PK-AS-REP	Этот тип также следует использовать для проверки подлинности смарт-карт, но в некоторых средах Active Directory его никогда не видели.
19	PA-ETYPE-INFO2	Тип предварительной проверки подлинности ETYPE-INFO2 отправляется КДК в KRB-ERROR, указывающее требование о дополнительной предварительной проверке подлинности. Обычно он используется для уведомления клиента о том, какой ключ используется для шифрования зашифрованного времени для отправки значения предварительной проверки подлинности PA-ENC-TIMESTAMP.Никогда не видел этот тип предварительной проверки подлинности в среде Microsoft Active Directory.
20	PA-SVR-REFERRAL-INFO	Используется в билетах KDC Referrals.
138	PA-ENCRYPTED-CHALLENGE	Logon using Kerberos Armoring (FAST). Поддерживается начиная с Windows Server 2012 контроллеров домена и Windows 8 клиентов.
—		Этот тип показан в событиях сбоя аудита.

Сведения о сертификате:

• Имя эмитента сертификата — имя органа сертификации, выдав сертификат смарт-карты. Заполнено в Выданном полем в сертификате.

• Серийный номер сертификата : серийный номер сертификата смарт-карты. Можно найти в поле Серийный номер в сертификате.

• Thumbprint сертификата : отпечатки пальцев сертификата смарт-карты. Можно найти в поле Thumbprint в сертификате.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

• Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
• Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.

Microsoft Account Lockout and Management Tools (Инструменты блокировки и управления учётной записью от Microsoft)

Запустите средство Lockoutstatus.exe, укажите имя заблокированной учётной записи (Target User Name) и имя домена (Target Domain Name).

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

Атрибуты badPwdCount и LastBadPasswordAttempt не реплицируются между контроллерами домена.

Вы можете разблокировать учётную запись пользователя или изменить пароль прямо из окна Lockoutstatus.

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

Список флагов свойств

Эти атрибуты можно просматривать и изменять с помощью Ldp.exe или оснастки Adsiedit.msc.

В следующей таблице перечислены возможные флаги, которые можно назначить. Некоторые значения на объекте пользователя или компьютера установить нельзя, так как эти значения можно установить или сбросить только службой каталогов. Ldp.exe показывает значения в hexadecimal. Adsiedit.msc отображает значения в десятичной. Флаги являются накопительными. Чтобы отключить учетную запись пользователя, установите атрибут UserAccountControl 0x0202 (0x002 + 0x0200). В десятичной , это 514 (2 + 512).

Примечание

Вы можете непосредственно изменить Active Directory как в Ldp.exe, так и в Adsiedit.msc. Только опытные администраторы должны использовать эти средства для редактирования Active Directory. Оба средства доступны после установки средств поддержки из исходного Windows установки.

Флаг свойства	Значение в hexadecimal	Значение в десятичной
SCRIPT	0x0001	1
ACCOUNTDISABLE	0x0002	2
HOMEDIR_REQUIRED	0x0008	8
ЛОКАУТ	0x0010	16
PASSWD_NOTREQD	0x0020	32
PASSWD_CANT_CHANGEЭто разрешение нельзя назначить путем непосредственного изменения атрибута UserAccountControl. Сведения о том, как настроить разрешение программным путем, см. в разделе	0x0040	64
ENCRYPTED_TEXT_PWD_ALLOWED	0x0080	128
TEMP_DUPLICATE_ACCOUNT	0x0100	256
NORMAL_ACCOUNT	0x0200	512
INTERDOMAIN_TRUST_ACCOUNT	0x0800	2048
WORKSTATION_TRUST_ACCOUNT	0x1000	4096
SERVER_TRUST_ACCOUNT	0x2000	8192
DONT_EXPIRE_PASSWORD	0x10000	65536
MNS_LOGON_ACCOUNT	0x20000	131072
SMARTCARD_REQUIRED	0x40000	262144
TRUSTED_FOR_DELEGATION	0x80000	524288
NOT_DELEGATED	0x100000	1048576
USE_DES_KEY_ONLY	0x200000	2097152
DONT_REQ_PREAUTH	0x400000	4194304
PASSWORD_EXPIRED	0x800000	8388608
TRUSTED_TO_AUTH_FOR_DELEGATION	0x1000000	16777216
PARTIAL_SECRETS_ACCOUNT	0x04000000	67108864

Примечание

В домене Windows Server 2003 LOCK_OUT и PASSWORD_EXPIRED заменены новым атрибутом ms-DS-User-Account-Control-Computed. Дополнительные сведения об этом новом атрибуте см. в атрибуте ms-DS-User-Account-Control-Computed.

Известные проблемы, влияющие на MaxTokenSize

Для большинства реализаций должно быть достаточно значения в 48 000 bytes. Это значение по умолчанию в Windows Server 2012 и более поздних версиях. Однако, если вы решите использовать большее значение, просмотрите известные проблемы в этом разделе.

• Ограничение размера в 1010 групповых SID для маркера доступа к LSA

  Эта проблема аналогична тому, что пользователь, у которого слишком много членов группы, не может проверить подлинность, но расчеты и условия, которые регулируют проблему, отличаются. Например, пользователь может столкнуться с этой проблемой при использовании проверки подлинности Kerberos или Windows проверки подлинности NTLM. Дополнительные сведения см. в статью Ведение журнала учетной записи пользователя, в которую входит более групп, на компьютере на Windows сервере.

• Известная проблема при использовании значений MaxTokenSize более 48 000

  Для смягчения вектора атаки на службу internet Information Server (IIS) использует ограниченный размер буфера http-запроса в 64 КБ. Билет Kerberos, который является частью http-запроса, закодирован как Base64 (6 битов, расширенный до 8 битов). Таким образом, билет Kerberos использует 133 процента от первоначального размера. Поэтому, если максимальный размер буфера в IIS составляет 64 КБ, билет Kerberos может использовать 48 000 битов.

  Если задать запись реестра значению, которое превышает 48000 bytes, и буферное пространство используется для siDs, может возникнуть ошибка IIS. Однако если вы установите запись реестра до 48 000 бит и используете пространство для SID-файлов и утверждений, возникает ошибка Kerberos.

  Дополнительные сведения о размерах буфера IIS см. в странице How to limit the header size of the HTTP transmission that IIS accepts from a client in Windows 2000.

• Известные проблемы при использовании значений MaxTokenSize больше 65 535

  В предыдущих версиях этой статьи обсуждались значения до 100 000 bytes for . Однако мы обнаружили, что у версий администратора SMS возникают проблемы, когда размер 100 000 bytes или больше.

  Мы также определили, что протокол IKE IPSEC не позволяет BLOB-адресу безопасности быть больше 66 536 битов, и он также не будет иметь значения, когда задавалось большее значение.

Идентификатор события блокировки учётной записи 4740

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

Если ближайший к пользователю контроллер домена определяет, что пользователь пытается войти в систему с недопустимыми учётными данными, он перенаправляет запрос проверки подлинности на контроллер домена с эмулятора основного контроллера домена (этот конкретный контроллер домена отвечает за обработку блокировок учётных записей). Если аутентификация на PDC завершается неудачно, он отвечает на первый DC, что аутентификация невозможна. Если количество неудачных проверок подлинности превышает значение, установленное для домена в политике Account Lockout Threshold (Пороговое значение блокировки), учётная запись пользователя временно блокируется.

В этом случае событие с EventID 4740 записывается в журнал безопасности обоих контроллеров домена. Событие содержит DNS-имя (IP-адрес) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех контроллерах домена, проще всего искать события блокировки в журнале безопасности на PDC контроллера домена. Вы можете найти PDC в своём домене следующим образом:

(Get-AdDomain).PDCEmulator

События блокировки учётной записи домена можно найти в журнале безопасности на контроллере домена. Чтобы его увидеть, запустите Event Viewer («Просмотр событий»), его можно открыть в командной строке:

eventvwr.msc

В окне Event Viewer («Просмотр событий») перейдите по пути Event Viewer (Local) → Windows Logs → Security (в русскоязычной версии это Просмотр событий (локальный) → Журналы Windows → Безопасность).

В Event Viewer («Просмотр событий») отфильтруйте журнал безопасности по Event ID («Код события») указав значение 4740, для этого нажмите Filter Current Log («Фильтр текущего журнала») и введите в поле <All Event Ids> («Все коды событий») значение 4740.

Вы должны увидеть список последних событий блокировки учётной записи. Найдите событие с нужной вам учётной записью пользователя (имя пользователя указано в значении поля Account Name («Имя учётной записи»). В описании события вы увидите строку A user account was locked out («Учетная запись пользователя была заблокирована»).

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

Откройте найденное событие. Имя компьютера (сервера), с которого была произведена блокировка, указывается в поле Caller Computer Name. В моём случае имя компьютера — HACKWARE-WIN.

Управление политикой

В этом разделе описываются функции и средства, доступные для управления этой политикой.

Необходимость перезапуска

Нет. Изменения в этой политике становятся эффективными без перезапуска устройства при локальном сбережении или распространении через групповую политику.

Групповая политика

Этот параметр политики можно настроить с помощью консоли управления групповой политикой (GPMC), которая будет распространяться через объекты групповой политики (GPOs). Если эта политика не содержится в распределенной GPO, эту политику можно настроить на локальном компьютере с помощью привязки к локальной политике безопасности.

Исключение намеренных нарушений или сбоев оборудования

Иногда ошибки репликации возникают из-за преднамеренных нарушений. Например, при устранении неполадок, связанных с репликацией Active Directory, необходимо сначала поочередно отменять подключения и сбои оборудования или обновления.

Намеренные отключения

Если контроллер домена, который попытается выполнить репликацию с помощью контроллера домена, который был создан на промежуточном сайте и в настоящее время ожидает развертывания на окончательном рабочем сайте (удаленном сайте, таком как филиал), сообщает об ошибках репликации, можно учитывать эти ошибки репликации. Чтобы не разделять контроллер домена от топологии репликации для расширенных периодов, что вызывает непрерывные ошибки до повторного подключения контроллера домена, рассмотрите возможность добавления таких компьютеров изначально в качестве рядовых серверов и использования метода установки с носителя для установки служб домен Active Directory Services (AD DS). Программу командной строки Ntdsutil можно использовать для создания установочного носителя, который можно хранить на съемных носителях (компакт-диск, DVD-диск или другой носитель) и поставлять на конечный сайт. Затем можно использовать установочный носитель для установки AD DS на контроллерах домена на сайте без использования репликации.

Сбои оборудования или обновления

Если проблемы с репликацией возникают в результате сбоя оборудования (например, из-за сбоя материнской платы, дисковой подсистемы или жесткого диска), сообщите владельцу сервера о том, что проблему с оборудованием можно устранить.

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

Настройка брандмауэра

По умолчанию Active Directory репликация удаленных вызовов процедур (RPC) выполняется динамически через доступный порт через сопоставитель конечных точек RPC (RPCSS) через порт 135. убедитесь, что Windows брандмауэр с расширенной безопасностью и другими брандмауэрами настроены правильно, чтобы разрешить репликацию. Сведения об указании порта для параметров репликации Active Directory и портов см. в статье 224196 базы знаний Майкрософт.

сведения о портах, которые Active Directory репликации, см. в разделе Active Directory средства репликации и Параметры.

Сведения об управлении репликацией Active Directory через брандмауэры см. в разделе Active Directory репликация через брандмауэры.

Настройка многофакторной проверки подлинности для отношения доверия с проверяющей стороной

1. В диспетчере сервера щелкните Средства и выберите Управление AD FS.

2. В оснастке AD FS щелкните политики проверки подлинностидля отношения доверия с проверяющей стороной, а затем выберите отношение доверия с проверяющей стороной, для которого требуется настроить mfa.

3. Либо щелкните правой кнопкой мыши отношение доверия с проверяющей стороной, для которого требуется настроить MFA, а затем выберите изменить пользовательскую многофакторную проверку подлинностиили в области действия выберите изменить пользовательскую многофакторную проверку подлинности.

4. В окне изменение политики проверки подлинности для relying_party_trust_name > в разделе > вкладка можно настроить следующие параметры в рамках политики проверки подлинности для отношения доверия с проверяющей стороной.

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

Устранение неполадок определенных сценариев

Перепроцес для неправильного сопоставления между хост и IP, из-за этого контроллер домена назначения будет извлекаться из неправильного источника.

Продвижение \ \ dc1 + \ \ DC2 + \ \ DC3 в домене. End-to-end replication occurs without errors.

Остановите KDC на DC1 и DC2 для принудительного трафика Kerberos, который можно наблюдать в \ \ \ \ сетевом следе. End-to-end replication occurs without errors.

Создайте запись файла Host для DC2, которая указывает на \ \ IP-адрес dc в удаленном лесу. Это имитация ненадежного сопоставления между хост-ip в записи A/AAAA или, возможно, устаревший объект Параметры NTDS в копии каталога Active Directory контроллера домена назначения.

Запустите сайты и службы Active Directory на консоли \ \ DC1

Щелкните правой кнопкой \ \ мыши входящий объект подключения DC1 из DC2 и обратите внимание, что целевое имя учетной записи является \ \ неправильной ошибкой репликации.

Перепроцес для несоответствия пароля контроллера исходных доменов между KDC и контроллером исходных доменов.

Продвижение \ \ dc1 + \ \ DC2 + \ \ DC3 в домене. Репликация с концами происходит без ошибок.

Остановите KDC на DC1 и DC2 для принудительного трафика Kerberos, который можно наблюдать \ \ \ \ в сетевом следе

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

Отключение входящие репликации на KDC DC3 для имитации сбоя \ \ репликации на KDC.

Сброс пароля учетной записи компьютера на DC2 три или более раз, чтобы у DC1 и DC2 был текущий пароль \ \ \ \ \ \ для \ \ DC2.

Запустите сайты и службы Active Directory на консоли \ \ DC1. Щелкните правой кнопкой мыши на входящий объект подключения DC1 из DC2 и обратите внимание, что целевое имя учетной записи является \ \ \ \ неправильной ошибкой репликации.

Ведение журнала клиента DS RPC
Установите NTDS\Diagnostics Loggings\DS RPC Client = 3. Репликация триггера. Найди событие категории задач 1962 + 1963. Обратите внимание на полностью квалифицированные кадры, указанные в поле службы каталогов. Контроллер домена назначения должен иметь возможность фиксировать эту запись и иметь возвращенную адресную карту на текущий IP-адрес источника dc.

Рабочий процесс Kerberos
Рабочий процесс Kerberos включает следующие действия:

Клиентский компьютер вызывает функцию IntializeSecurityContext и указывает поставщика поддержки безопасности Negotiate (SSP).

Клиент обращается к KDC с TGT и запрашивает TGS-билет для целевого контроллера домена.

KDC ищет глобальный каталог для источника (e351 или имени хост-кодов) в области контроллера домена назначения.

Если контроллер целевого домена находится в области контроллера домена назначения, KDC предоставляет клиенту билет на обслуживание.

Если целевой контроллер домена находится в другой области, KDC предоставляет клиенту билет на направление.

Клиент контактов KDC в домене целевого контроллера домена и запрашивает билет на обслуживание.

Если SPN контроллера домена источника не существует в области, вы получите KDC_ERR_S_PRINCIPAL_UNKNOWN ошибку.

Контроллер домена назначения связался с объектом и представил свой билет.

Если целевой контроллер домена владеет именем в билете и может расшифровать его, проверка подлинности работает.

Если в целевом контроллере домена размещен UUID-службы сервера RPC, ошибка Kerberos KRB_AP_ERR_NOT_US или KRB_AP_ERR_MODIFIED перенаправляется в следующее:

Примеры использования Get-ADDomainController

Чтобы получить контроллер домена с помощью механизма обнаружения DCLocator, используйте опцию -Discover. Вы можете указать критерии поиска, задав такие опции, как -Service, -SiteName, -DomainName, -NextClosestSite, -AvoidSelf и -ForceDiscover.

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

Get-ADDomainController -Discover

Следующая команда получит один доступный контроллер домена на указанном сайте:

Get-ADDomainController -Discover -Site "Default-First-Site-Name"

Опция -ForceDiscover указывает командлету очистить всю кэшированную информацию о контроллере домена и выполнить новое обнаружение. Если этот параметр не указан, командлет может возвращать кэшированные сведения о контроллере домена.

Get-ADDomainController -Discover -Site "Default-First-Site-Name" -ForceDiscover

Эта команда получает один доступный контроллер указанного домена в данном домене с помощью обнаружения.

Get-ADDomainController -Discover -Domain "user01.com"

Вы можете найти ближайший доступный контроллер домена с активной ролью веб-служб AD:

Get-ADDomainController -ForceDiscover -Discover -Service ADWS

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

• PrimaryDC или 1
• GlobalCatalog или 2
• KDC или 3
• TimeService или 4
• ReliableTimeService или 5
• ADWS или 6

Пример использования опции -Service для поиска PDC (Primary Domain Controller Emulator) в вашем домене:

Get-ADDomainController -Discover -Service PrimaryDC

Эта команда ищет компьютер с функцией Глобального каталога в текущем лесу:

Get-ADDomainController -Discover -Service "GlobalCatalog"

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

Get-ADDomainController -Discover -Domain "corp.contoso.com" -Service "PrimaryDC","TimeService"

Если ваш контроллер домена не найден или не отвечает, вы можете найти его на ближайшем сайте AD (определяется весом межсайтовых ссылок):

Get-ADDomainController -Discover -ForceDiscover -NextClosestSite

Чтобы найти и получить более одного контроллера домена, используйте опцию -Filter.

Чтобы отобразить список всех контроллеров домена в текущем домене, выполните такую команду:

Get-ADDomainController -Filter * | Format-Table

Используя следующую команду, вы можете подсчитать количество контроллеров домена в AD:

Get-ADDomainController -Filter * | Measure-Object

Вы можете отобразить более удобную таблицу, в которой показаны все контроллеры домена, их имена хостов, IP-адреса, версии ОС и имена сайтов AD:

Get-ADDomainController -Filter *| Select-Object Name,ipv4Address,OperatingSystem,site | Sort-Object name

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

Get-ADDomainController -Filter * -Server dc01.test.com | Select Name,ipv4Address, IsGlobalCatalog,Site