У нас возникла ситуация, когда программное приложение не может быть установлено, поскольку учетная запись администратора, используемая во время установки, блокируется во время проверки предварительных требований. После некоторого расследования мы нашли причину: проверка предварительных требований проверяет удаленные параметры реестра других серверов с помощью вызова RPC к IP-адресу сервера, а не к его полному доменному имени, и по какой-то причине это приводит к сбою аутентификации и блокировке учетной записи.
Мы подтвердили это, выполнив следующие действия:
- При использовании regedit и попытке подключения к реестру другого сервера AD с использованием полного доменного имени сервера подключение происходит без проблем.
- При попытке установить то же соединение с использованием IP-адреса сервера запрашиваются новые учетные данные.
- Все учетные данные AD не будут работать и в конечном итоге заблокируют используемую учетную запись, но использование учетной записи локального администратора не вызывает никаких проблем.
Мы также провели этот тест с других серверов в среде, но у них не было проблем с подключением и аутентификацией по IP. Мы сравнили настройки NIC/DNS/WINS, но не обнаружили заметной разницы. Мы находимся на этапе перекрестной проверки настроек GPO, но не ожидаем, что что-то обнаружим.
Мы, конечно, могли бы просто использовать учетные записи локального администратора, но мы хотим понятьпочемувызов RPC с использованием IP-адреса вместо FQDN приводит к сбою аутентификации AD и блокировке учетных записей AD. Есть идеи?
решение1
Если он блокирует учетную запись, у вас определенно проблема с паролем. В противном случае это может быть связано с тем, что Kerberos не используется, а NTLM отключен или что-то в этом роде. Вам нужно проверить журнал безопасности исходного и целевого сервера и предоставить любую запись журнала, которая может быть связана с проблемой аутентификации.
Вы также можете попробовать это. Однако, менять что-то, когда вы даже не знаете, почему что-то не работает, не очень эффективно и может сломать что-то другое.
Начиная с Windows 10 версии 1507 и Windows Server 2016, клиенты Kerberos можно настроить для поддержки имен хостов IPv4 и IPv6 в именах участников-служб.
По умолчанию Windows не будет пытаться выполнить аутентификацию Kerberos для хоста, если имя хоста является IP-адресом. Он будет использовать другие включенные протоколы аутентификации, такие как NTLM. Однако приложения иногда жестко запрограммированы на использование IP-адресов, что означает, что приложение будет использовать NTLM и не будет использовать Kerberos. Это может вызвать проблемы совместимости, поскольку среды переходят на отключение NTLM.
Чтобы уменьшить влияние отключения NTLM, была введена новая возможность, которая позволяет администраторам использовать IP-адреса в качестве имен хостов в именах участников служб.
Подробнее читайте на
https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip