Проверка подлинности Kerberos обнаружила следующую ошибку: не удается найти компьютер

Обновлено: 02.07.2024

Подключение и управление хостами за пределами вашего домена или в рабочей группе

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

При привлечении хостов за пределами вашего домена возникнет следующая ошибка:

Под капотом диспетчера Hyper-V и других инструментов RSAT используется WinRM/PSRemoting для установления соединения и выполнения действий. По умолчанию WinRM хочет использовать Kerberos, но не может этого сделать. Мы можем убедиться в этом, попробовав установить базовую PSSession:

Обратите внимание, что мы получаем очень похожую ошибку, когда Kerberos не может пройти аутентификацию. По умолчанию для удаленного управления Windows используется Kerberos, и переход на CredSSP не будет работать без дополнительной настройки.

Обзор видео

Если вы предпочитаете формат видео письменной документации, я продемонстрирую, как настроить хост и устройство управления для использования CredSSP:

Управление Hyper-V с помощью CredSSP

Чтобы включить аутентификацию через CredSSP, вам потребуется внести изменения в конфигурацию как хоста, которым вы хотите управлять, так и вашего управляющего устройства.

На хосте

Эта первая команда активирует удаленное управление, а Enable-WSManCredSSP активирует аутентификацию CredSSP.

На устройстве управления

1. Убедитесь, что вы можете разрешить имя хоста. Настройте файл хоста на устройстве управления, если вы не можете пропинговать имя хоста, которым будете управлять.
2. Настройте локальную групповую политику:
   1. Конфигурация компьютера > Административные шаблоны > Система > Делегирование учетных данных > Разрешить делегирование новых учетных данных с аутентификацией сервера только по протоколу NTLM.
   2. Нажмите «Включить» и добавьте wsman/fqdn-of-hyper-v-host. к

   Несколько мыслей об использовании CredSSP

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

   С CredSSP вы отправляете учетные данные непосредственно на удаленный сервер, которым вы управляете, который будет поддерживать учетные данные пользователя. Если удаленный сервер будет скомпрометирован, переданные учетные данные также могут быть скомпрометированы. Следовательно, именно поэтому вам необходимо явно добавить удаленные серверы для управления в вашу группу TrustedHosts, как указано выше.

   Вы должны знать об этом ограничении при использовании его в рабочей среде и передавать учетные данные через CredSSP только на высоконадежные серверы. Джо Биалек описывает некоторые ограничения CredSSP в своей замечательной статье «Случайный саботаж: остерегайтесь CredSSP»

   Наконец, при управлении Hyper-V с помощью CredSSP (или других хостов Windows) фактор риска относительно низок. (Вы сохраняете тот же уровень риска, например, при установлении сеанса RDP с сервером). Просто помните об ограничениях CredSSP и убедитесь, что это имеет смысл для ваших производственных сценариев использования.

   В этой статье мы рассмотрим, почему невозможно присоединить новый компьютер к домену Active Directory из-за ошибки «Не удалось связаться с контроллером домена Active Directory».

   Не удалось связаться с контроллером домена Active Directory: как это выглядит и как это исправить?

   Пользователь или администратор пытается присоединить к домену новую рабочую станцию ​​или сервер Windows. Для этого откройте Свойства системы на рабочей станции, нажмите Изменить настройки > Изменить. Введите новое имя компьютера и выберите, что этот компьютер должен быть членом указанного домена. Введите полное доменное имя домена AD. После нажатия на кнопку ОК может появиться сообщение об ошибке:

   Если имя верное, нажмите «Подробнее», чтобы получить информацию об устранении неполадок.

   
   

   Нажмите кнопку "Подробности", чтобы получить дополнительные сведения об ошибке. В большинстве случаев вы увидите ошибку «DNS-имя не существует» (коды ошибок 0x0000232B RCODE_NAME_ERROR, 0x0000267C DNS_ERROR_NO_DNS_SERVER и 0x00002746 WSAECONNRESET).

   Доменное имя «DOMAIN_NAME» может быть доменным именем NetBIOS.В этом случае убедитесь, что доменное имя правильно зарегистрировано в WINS.

   Если вы уверены, что имя не является доменным именем NetBIOS, следующая информация может помочь вам устранить неполадки в конфигурации DNS.

   При запросе к DNS записи ресурса расположения службы (SRV), используемой для обнаружения контроллера домена Active Directory (AD DC) для домена «DOMAIN_NAME», произошла следующая ошибка:

   ошибка была: «DNS-имя не существует».

   (код ошибки 0x0000232B RCODE_NAME_ERROR)

   Запрос был на запись SRV для _ldap._tcp.dc._msdcs.DOMAIN_NAME

   Распространенные причины этой ошибки включают следующее:

   – Записи DNS SRV, необходимые для обнаружения AD DC для домена, не зарегистрированы в DNS. Эти записи автоматически регистрируются на DNS-сервере при добавлении AD DC в домен. Они обновляются AD DC с заданными интервалами. Этот компьютер настроен на использование DNS-серверов со следующими IP-адресами:

   xx.xx.xx.xx

   xx.xx.xx.xx

   – Одна или несколько из следующих зон не включают делегирование в дочернюю
   зону:

   имя_домена
   local
   .. (корневая зона)

   
   

   Проверьте правильность настроек IP на вашем компьютере

   Чаще всего эта проблема связана с неправильными настройками IP или DNS на вашем компьютере, неправильной настройкой DNS на стороне контроллера домена или блокировкой портов брандмауэром.

   Прежде всего проверьте, имеет ли ваш компьютер правильный IP-адрес на основном сетевом интерфейсе. IP-адрес можно получить с DHCP-сервера или указать вручную в настройках сетевого адаптера. Текущие сетевые настройки компьютера можно получить с помощью команды:

   
   

   Убедитесь, что служба DNS-клиент запущена с помощью командлета Get-Service:

   
   

   Откройте файл hosts (C:\Windows\System32\Drivers\etc\hosts) на компьютере с помощью notepad.exe или другого текстового редактора и убедитесь, что в нем нет записей для имен вашего домена или контроллера домена. Если такие записи существуют, удалите их.

   Вы можете отобразить содержимое файла hosts с помощью команды:

   
   

   Затем очистите кеш DNS и перезапустите службу из командной строки с повышенными привилегиями:

   Затем проверьте, доступен ли контроллер домена с клиента. Откройте командную строку и выполните следующие команды:

   Убедитесь, что ваш контроллер домена отвечает и доступен.

   
   

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

   Если DC доступен, попробуйте добавить полученный IP-адрес в качестве DNS-сервера в дополнительных настройках TCP/IP вашего сетевого подключения.

   1. Откройте Панель управления > Сеть и Интернет > Центр управления сетями и общим доступом > Изменить параметры адаптера.
   2. Выберите сетевой адаптер, подключенный к вашей корпоративной сети, щелкните его правой кнопкой мыши и выберите "Свойства";
      
   3. Выберите Интернет-протокол версии 4 (TCP/IPv4) и нажмите "Свойства".
   4. Нажмите кнопку "Дополнительно" и перейдите на вкладку "DNS";
   5. На вкладке DNS нажмите "Добавить" и введите IP-адрес вашего DNS-сервера (контроллера домена). Не используйте общедоступные IP-адреса DNS в предпочтительных и альтернативных полях, например 8.8.8.8 (google) или 1.1.1.1 (cloudflare);
      
   6. Нажмите «ОК» (если в списке DNS-серверов указано несколько IP-адресов, переместите IP-адрес вашего контроллера домена в начало списка);
      
   7. Сохраните изменения и перезапустите рабочую станцию.
   8. Попробуйте подключить свою рабочую станцию ​​к домену AD.

   Убедитесь, что доступ к службе DNS на контроллере домена не заблокирован брандмауэрами. Самый простой способ проверить доступность порта 53 на контроллере домена — использовать PowerShell:

   В нашем примере TcpTestSucceeded: True означает, что служба DNS на контроллере домена доступна.

   
   

   Кроме того, проверьте, может ли ваш компьютер преобразовать доменное имя в правильный IP-адрес контроллера домена. Используйте командлет Resolve-DNSName с полным доменным именем вашего домена, к которому вы пытаетесь подключить свою рабочую станцию:

   
   

   Команда должна вернуть одну или несколько записей DNS-серверов.

   Кроме того, убедитесь, что компьютер может связаться с DNS-сервером, на котором размещена зона DNS, или разрешить DNS-имена в этом домене. Убедитесь, что правильный DNS-сервер настроен на этом клиенте как предпочтительный, и клиент подключен к этому серверу. Подтвердите, что можете найти домен и получить доступ к контроллеру домена с компьютера с помощью команды:

   
   

   Если ваш компьютер успешно обнаружил домен и контроллер домена, команда должна вернуть информацию о домене, сайте AD и службах, работающих на контроллере домена:

   Подсказка. Еще одно полезное руководство, которое может помочь вам в устранении неполадок с подключением к контроллеру домена через RPC, — «Сервер RPC недоступен»

   Иногда в файле Netsetup.log можно найти полезную информацию об ошибках при присоединении компьютера к домену Active Directory. Это клиенты Windows регистрируют подробности операции присоединения к домену. Этот журнал можно найти здесь %windir%\debug\Netsetup.log. Внимательно изучите ошибки в файле Netsetup.log, они могут помочь вам найти проблему невозможности подключения к домену Active Directory.

   • Не удалось разрешить DNS-имя контроллера домена в присоединяемом домене. Убедитесь, что этот клиент настроен на доступ к DNS-серверу, который может разрешать DNS-имена в целевом домене;
   • Попытка выполнить операцию с несуществующим сетевым подключением — перезагрузите компьютер, убедитесь, что вы вводите имя DNS, а не имя NetBIOS;
   • Не допускается многократное подключение к серверу или общему ресурсу одним и тем же пользователем с использованием более одного имени пользователя. Отключите все предыдущие подключения к серверу или общему ресурсу и повторите попытку — перезагрузите устройство;
   • Сетевое имя не найдено — убедитесь, что ваш компьютер имеет доступ к DNS-серверу, на котором размещена зона DNS домена;
   • В настоящее время к этому удаленному компьютеру больше нельзя установить никаких подключений, потому что уже есть столько подключений, сколько компьютер может принять — удалите все сопоставленные диски и перезагрузите компьютер.

   Кроме того, попробуйте временно отключить встроенный брандмауэр Windows и все сторонние приложения с модулями антивируса/брандмауэра (Symantec, MacAfee, Защитник Windows и т. д.), которые могут блокировать сетевые порты для доступа к контроллеру домена. После отключения брандмауэров попробуйте присоединить компьютер к домену.

   Вот минимальный список сетевых протоколов, портов и служб, которые не должны блокироваться брандмауэрами между клиентом и контроллером домена для успешного присоединения устройства к домену Active Directory:

   • UDP 53 — DNS-трафик;
   • TCP и UDP 88 — аутентификация Kerberos;
   • UDP 123 — синхронизация времени Windows с DC;
   • TCP 135 — локатор удаленного вызова процедур RPC;
   • TCP и UDP 139 — служба сеансов NetBIOS;
   • TCP и UDP 389 (LDAP, локатор контроллеров домена, сетевой вход) или TCP 636 (LDAP через SSL);
   • TCP 445 (SMB/CIFS, сетевой вход);
   • TCP 49152-65535 — порты RPC, случайным образом распределенные высокие порты TCP.

   Проверьте записи репликации и DNS SRV на контроллере домена

   Если описанный выше способ не помог, проверьте, есть ли в зоне DNS вашего контроллера домена SRV-запись расположения контроллера домена.

   Откройте командную строку с повышенными привилегиями и выполните следующие команды:

   Проверьте, есть ли у указанного DNS-сервера запись SRV в следующей форме:

   
   

   Если указанная запись SRV отсутствует, это означает, что ваш компьютер настроен на использование DNS-сервера, который не имеет правильной записи SRV с расположением контроллера домена.

   Если вы не можете изменить настройки DNS на своем компьютере, вы можете вручную добавить две записи (SRV и A) на существующий DNS-сервер, которые помогут вам разрешить IP-адрес контроллера домена:

   Убедитесь, что контроллер домена настроен на использование того же DNS-сервера, или убедитесь, что репликация на DNS-сервере, который использует клиент, выполнена успешно (используйте инструмент repadmin для проверки состояния репликации). Кроме того, убедитесь, что DNS-сервер разрешает динамические обновления.

   Перезапустите службу Netlogon на контроллере домена с помощью команды:

   (или просто попробуйте перезагрузить контроллер домена)

   При запуске он попытается зарегистрировать необходимые записи SRV на DNS-сервере.

   Кроме того, вы можете перерегистрировать DNS-записи контроллера домена с помощью команды:

   Подождите некоторое время, пока записи появятся в DNS и реплицируются в домене.

   Также рекомендуется проверить, созданы ли общие сетевые папки SYSVOL и NETLOGON и доступны ли они на контроллере домена (выполните команду net share на ближайшем контроллере домена).

   
   

   Если каталоги SYSVOL и NETLOGON отсутствуют в списке общих ресурсов:

   
   

   1. Проверьте настройки IP и DNS на вашем контроллере домена (контроллер домена не должен получать IP-адрес от DHCP-сервера, используйте только статический IP-адрес);
   2. Проверьте, содержит ли каталог домена C:\Windows\SYSVOL папки Policies и Scripts;
      
   3. Если вы не перенесли репликацию Sysvol с FRS на DFS, чтобы реплицировать Sysvol с PDC на все контроллеры домена в домене, необходимо остановить службу репликации файлов (net stop NtFrs). Затем запустите Regedit и перейдите в раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/RestoreProcess at Startup, здесь измените значение параметра BurFlags DWORD на D4 (hex) на PDC и на D2 (hex) на всех дополнительных контроллерах домена. После этого запустите службу:

   Доступ к устаревшим контроллерам домена с использованием протокола SMB v1

   Если вы используете контроллеры домена под управлением Windows Server 2008/2003/2000 и пытаетесь присоединить к домену Windows 10 1803 (или более поздней версии) или Windows Server 2019, необходимо включить поддержку протокола SMBv1 на стороне клиента ( этот протокол отключен по умолчанию в более новой ОС Windows). Клиент SMB1Protocol-Client позволяет вашему компьютеру получать доступ к устаревшим серверам.

   Чтобы включить поддержку SMBv1 в Windows 10, выберите Панель управления > Программы > Включение или отключение компонентов Windows. Разверните узел Поддержка общего доступа к файлам SMB 1.0/CIFS, включите параметр Клиент SMB 1.0/CIFS и сохраните изменения.

   
   

   Вы можете проверить состояние клиентского протокола SMB 1.0/CIFS на компьютере с Windows 10 с помощью команды PowerShell:

   
   

   Если статус протокола SMB1Client отключен, вы можете включить его, используя:

   Вы можете проверить, включен ли клиент SMBv1 в Windows Server 2022 или 2019, с помощью следующей команды PowerShell:

   
   

   Чтобы установить клиент SMBv1 на Windows Server 2022/2019, выполните:

   В клиентах Windows 7/Vista состояние протокола SMBv1 можно определить с помощью команды:

   Если вам нужно включить клиент SMB v1 в Windows 7/Windows Server 2008 R2, выполните:

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

   
   

   В этой статье представлен обзор имени участника-службы (SPN) для использования проверки подлинности Kerberos в подключениях к SQL Server. Мы используем аутентификацию Kerberos для безопасной аутентификации пользователей Windows для предоставления доступа к SQL Server.

   Введение имени участника-службы и проверки подлинности Kerberos SQL Server

   Начнем эту статью со сценария, с которым вы могли столкнуться в своей среде. Предположим, у вас есть SQL Server и его службы работают под учетной записью локальной системы. В соответствии с требованиями организации вы изменили учетную запись службы с локальной системы на учетную запись домена. После перезапуска службы SQL вы можете подключиться к SQL Server после принятия RDP в систему, но пользователи приложений не могут подключиться к нему.Мы поймем решение этой проблемы в последней части этой статьи.

   У нас есть два типа методов проверки подлинности сервера в SQL Server.

   < бр />

   • Аутентификация SQL: мы можем создать логин SQL и предоставить соответствующие права для этого логина. SQL Server обрабатывает аутентификацию входа SQL
   • Аутентификация Windows. Мы можем использовать учетные записи домена для добавления в SQL Server и подключения с помощью метода аутентификации Windows. SQL Server не обрабатывает часть аутентификации для учетной записи входа в Windows. Он передает аутентификацию интерфейсу поставщика поддержки безопасности Windows (SSPI), который является компонентом операционной системы.

   Подключитесь к SQL Server и выполните следующий запрос:

   Вы можете увидеть следующие результаты

   • KERBEROS — показывает соединения, использующие аутентификацию KERBEROS.
   • SQL — если соединения используют аутентификацию SQL, мы получаем auth_scheme SQL
   • NTLM – показывает подключения, использующие аутентификацию NTLM.

   < бр />

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

   Вы найдете следующие журналы:

   
   

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

   
   

   SSPI сначала пытается использовать метод аутентификации по умолчанию (начиная с Windows 2000). Kerberos требует SPN для проверки подлинности. Если SPN не существует, он переключает аутентификацию на старый процесс NTLM.

   Если SPN существует, но недействителен, в журналы ошибок SQL Server заносится запись.

   
   

   Давайте подробно разберемся с процессом имени субъекта-службы (SPN).

   • Клиентский компьютер получает IP-адрес и полное доменное имя (FQDN) SQL Server с помощью прямого и обратного поиска.
   • Драйвер клиента создает имя участника-службы в предопределенном формате. Для SQL Server используется формат MSSQLSvc/FQDN: номер порта
   • Он отправляет запросы контроллеру домена с подробными сведениями о параметре имени участника-службы. Для этой работы используется Windows API InitializeSecurityContext
   • Контроллер домена проверяет имя участника-службы. Если существует действительный SPN, он выдает токен, и клиентский компьютер отправляет этот токен на SQL Server для проверки подлинности
   • SQL Server получает пакет TDS, использует другой Windows API AcceptSecurityContext и расшифровывает токен и связывается с контроллером домена для проверки имени участника-службы. Если проверка прошла успешно, SQL Server разрешает пользователю подключаться к экземпляру SQL в соответствии с назначенными разрешениями

   Если в этом процессе AcceptSecurityContext возникает ошибка, SQL Server возвращает следующие сообщения об ошибках:

   • Не удалось войти в систему для пользователя «NT AUTHORITY\ANONYMOUS LOGON». (Microsoft SQL Server, ошибка: 18456)
   • Не удалось войти в систему для пользователя "(null)"
   • Ошибка установления связи SSPI
   • Не удалось войти. Логин относится к ненадежному домену и не может использоваться с проверкой подлинности Windows.

   Вы можете понять процесс аутентификации Kerberos, используя следующее изображение.

   
   

   Необходимые условия для использования проверки подлинности Kerberos в SQL Server

   SQL Server должен соответствовать следующим требованиям для использования проверки подлинности Kerberos в SQL Server.

   • SQL Server и клиентский компьютер должны быть частью домена
   • Мы можем использовать несколько доменов в среде. Мы по-прежнему можем использовать аутентификацию Kerberos, но должны быть доверительные отношения домена.
   • Имя субъекта-службы (SPN) должно быть успешно зарегистрировано для служб SQL.

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

   Библиотека сетевого интерфейса SQL Server успешно зарегистрировала имя участника-службы (SPN) [ MSSQLSvc/SQL.testdomain.in:24629 ] для службы SQL Server.

   
   

   Вернемся к сценарию вводной части. В этом примере предыдущие службы SQL работали в локальной системе. В это время SQL Server успешно зарегистрировал имя участника-службы (SPN), и пользователи могут подключаться к SQL с помощью проверки подлинности Kerberos. Теперь, когда вы изменили учетную запись службы, SQL Server не смог отменить регистрацию старого имени участника-службы, связанного с учетной записью локальной системы. Как только пользователи попытаются подключиться к SQL Server, произойдет сбой, поскольку существующее имя участника-службы не связано с существующей учетной записью службы. В этом случае вы получаете ошибку Cannot Generate SSPI Context.

   Сравнение аутентификации Kerberos и NTLM

   • Kerberos обеспечивает более быстрый метод аутентификации по сравнению с NTLM.
   • NTLM допускает только один переход с клиентского компьютера на SQL Server. В настоящее время нам требуется много надежд между серверами. Например, используя связанный сервер, мы подключаемся к другому серверу или можем подумать о решении SSRS, в котором компоненты и базы данных SSRS находятся на разных серверах

   Kerberos допускает несколько переходов, и мы можем использовать его для связи с конечным компьютером, используя одни и те же учетные данные. Это помогает эффективно управлять решением для аутентификации, а также снижает нагрузку на контроллер домена.

   Сначала клиент получает TGT от контроллера домена после предоставления учетных данных. Клиент использует этот TGT и запрашивает билет службы у контроллера домена. В этом примере он запрашивает билет службы для подключения к SQL Server 1.

   В SQL Server 1 у нас есть связанный сервер, который подключается к другому SQL Server, используя текущий контекст безопасности входа. Если вы раньше использовали связанный сервер, вы, возможно, знаете, что нам не нужно повторно предоставлять учетные данные для пользователя Windows. Он автоматически позаботится о учетных данных. Это связано с методом двойного перехода аутентификации Kerberos.

   Теперь SQL Server использует существующий TGT и подключается к контроллеру домена, чтобы запросить другой билет службы для подключения к SQL Server 2. Получив билет службы, он может успешно пройти аутентификацию в SQL Server 2.

   
   

   • Аутентификация Kerberos более безопасна, чем NTLM
   • Проверка подлинности Kerberos – это решение с открытым стандартом.
   • Вы можете использовать для входа смарт-карту с помощью проверки подлинности Kerberos, хотя NTLM не предоставляет эту функцию

   Обзор имен участников-служб

   Имена участников-служб (SPN) — это уникальный идентификатор для каждой службы. У нас должно быть имя участника-службы для каждого экземпляра SQL. В случае нескольких экземпляров мы должны зарегистрировать все имена участников-служб. Это обязательный шаг для соединений SQL Server с использованием проверки подлинности Kerberos.

   Для служб SQL формат имени участника-службы: MSSQLSvc/SQLFQDN: номер порта.

   SPN для автономного экземпляра SQL по умолчанию

   SPN для экземпляра по умолчанию будет следующим.

   В журнале ошибок SQL появится следующая запись:

   
   

   Имя субъекта-службы (SPN) для именованного автономного экземпляра

   Именованный экземпляр также работает на порту 64234.

   SPN для именованного экземпляра будет следующим:

   В журнале ошибок SQL появится следующая запись.

   
   

   SPN для экземпляра отказоустойчивого кластера

   Если мы используем экземпляр отказоустойчивого кластера, мы не подключаем SQL к отдельным службам SQL. Для этого мы используем виртуальное имя отказоустойчивого кластера.

   FQDN автономного экземпляра

   Виртуальное имя отказоустойчивого кластера

   Предположим, у нас есть следующая среда.

   • Узлы: SQLA и SQLB
   • Виртуальное имя отказоустойчивого кластера: SQLC
   • Порт SQL Server: 1433 (по умолчанию)

   Имя участника-службы этого резервного экземпляра будет следующим:

   В журналах ошибок SQL Server можно увидеть следующие записи.

   
   

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

   
   

   SPN для постоянного прослушивателя SQL

   Мы используем SQL Listener для подключения к первичной реплике в SQL Server Always On. Мы должны создать SPN для каждого прослушивателя SQL группы доступности. Он включает аутентификацию Kerberos для клиентского соединения. Мы должны использовать одну и ту же учетную запись службы SQL для всех реплик группы доступности.

   Нам нужно использовать полное доменное имя прослушивателя SQL вместе с портом прослушивателя, чтобы настроить SPN для SQL Server Always On.

   Предположим, у нас есть группа доступности SQLAGProd-DB-LSN, и все реплики работают с учетной записью службы домена testdomain\SQLprod. Прослушиватель настроен для работы с портом 81234

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

   Команда SETSPN

   Мы можем использовать команду SETSPN, чтобы вывести список доступных SPN для конкретной учетной записи домена. Выполните следующий запрос с правами администратора.

   Список всех зарегистрированных SPN

   Мы можем использовать параметр –L с командой setspn, чтобы вывести список всех доступных SPN, связанных с сервисным аккаунтом.

   Зарегистрировать SPN вручную

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

   setspn – MSSQLSvc/ :1433

   Нам нужно зарегистрировать SPN для каждой службы SQL.

   Автоматическая регистрация основного имени службы

   SQL Server может автоматически регистрировать имя участника-службы во время запуска служб SQL. В этом случае службы SQL должны работать в локальной системе или сетевой службе, либо учетная запись домена должна иметь достаточные разрешения для регистрации имени участника-службы. Требуется чтение имени servicePrincipal и запись разрешений на имя ServicePrincipal в активном каталоге.

   Заключение

   В этой статье мы рассмотрели имя участника-службы и метод проверки подлинности Kerberos для подключения к SQL Server. Знакомство с внутренними процессами помогает устранять неполадки.

   Читайте также:

     
   • Кто отвечает за выпуск сертифицированных электронных подписей для государственного сектора
     
   • Когда в России появились ноутбуки
     
   • Установка расширения Firefox из файла
     
   • Как задать размеры объекта в Sketchup
     
   • Файл TTF, как использовать