Приложение, которое работает на RedHat 7.5, подключается к SQL Server 2016

Question

Мы внедряем приложение java на RHEL 7.5, этому приложению java необходимо подключиться к SQL Server 2016. В качестве запроса безопасности мы должны использовать встроенную защиту для подключения SQL Server 2016. Следуйте рекомендациям веб-сайта Microsoft Мы внедряем Kerberos в Windows AD Server и RHEL 7.5.

К сожалению, мы столкнулись с проблемой учетных данных. Команда klist отлично работает на RHEL 7.5, означает, что Kerberos cl inet, установленный в RHEL7.5, может нормально общаться с сервером Kerberos (Windows AD сервер). И RHEL7.5 может пропинговать / ta lnet AD Server и SQL Server.

Мы следовали указаниям Microsoft c, чтобы установить SPN следующим образом:

setspn -A HTTP/SERVER_01.devdc.local@DEVDC.LOCAL devdc.local\admin. 

Как Microsoft В целом, мы должны использовать MSSQLSv c, а не HTTP, но это имеет проблему, когда мы используем MSSQLSv c, мы думаем, что причина в том, что версия ОС сервера AD Windows Server 2012, поэтому не может поддерживать протокол MSSQLSv c. После перехода на HTTP Kerberos работает нормально. Можно использовать генерировать билет kinit и использовать klist для просмотра информации о билете.

Часть нашего Java кода, как показано ниже:

System.setProperty("java.security.krb5.conf", "~/krb5.conf"); 
SQLServerDataSource ds = new SQLServerDataSource(); 
ds.setServerName("192.168.100.150"); 
ds.setPortNumber(1234); 
ds.setIntegratedSecurity(true); 
ds.setAuthenticationScheme("JavaKerberos"); 
ds.setDatabaseName("DB_TEST"); 

Подробности ошибок:

Ошибка соединения с базой данных: (с использованием класса com.microsoft.sqlserver.jdb c .SQLServerDriver) GSSException: не предоставлены действительные учетные данные (уровень механизма: сервер не найден) KrbException: сервер не найден в базе данных Kerberos (7) KrbException: идентификатор не соответствует ожидаемому значению (906)

Буду признателен, если вы поможете.

Answer 1

Вы, кажется, не устанавливаете SPN. См.

Имя участника службы (SPN) - это имя, по которому клиент однозначно идентифицирует экземпляр службы.

Вы можете указать SPN, используя свойство соединения serverSpn, или просто позвольте драйверу собрать его для вас (по умолчанию). Это свойство имеет вид: «MSSQLSvc / fqdn:port@REALM», где fqdn - полное доменное имя, порт - номер порта, а REALM - область Kerberos сервера SQL заглавными буквами. Часть области этого свойства является необязательной, если область вашей конфигурации Kerberos по умолчанию совпадает с областью сервера и не включена по умолчанию. Если вы хотите sh поддерживать сценарий межобластной аутентификации, в котором область по умолчанию в конфигурации Kerberos отличается от области сервера, то вы должны установить имя участника-службы со свойством serverSpn.

Например, ваше имя участника-службы может выглядеть так: «MSSQLSvc / some-server.zzz.corp.contoso. com:1433@ZZZZ.CORP.CONTOSO.COM»

Использование встроенной аутентификации Kerberos для подключения к SQL Серверу - участник службы names .

Драйвер попытается создать SPN для вас из других атрибутов соединения, но вместо FQDN у вас есть IP-адрес, поэтому он не может создать правильный SPN. В конфигурации по умолчанию SQL Сервер регистрирует свои собственные имена участников-служб, и вы можете увидеть правильное имя участника-службы в журнале SQL Сервера, но есть сценарий ios, где дополнительные имена участников-служб должны быть зарегистрированы для учетной записи службы, и вам потребуется используйте команду setspn на Windows, чтобы увидеть их.

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

setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\SERVER_01$
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\SERVER_01$

, если вы настроили учетную запись домена в качестве учетной записи службы, скажем devdc\sqlsvc, а затем замените ее.

setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\sqlsvc
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\sqlsvc

TL / DR использует полное доменное имя (FQDN) сервера SQL для setServerName () вместо IP-адреса. Если это не сработает, вам нужно будет спросить сотрудников службы безопасности сети, какие имена SPN зарегистрированы для учетной записи службы SQL. Если вы отказываетесь от Kerberos, вернитесь к NTLM.

Также в более новом драйвере JDB C Microsoft реализовала NTLM, который является прочим Windows протоколом аутентификации .

Но учтите следующее предостережение о безопасности:

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

Драйвер Microsoft JDB C для SQL Сервер поддерживает только NTLM v2, который имеет некоторые улучшения безопасности по сравнению с оригинальным протоколом v1. Также рекомендуется включить расширенную защиту или использовать шифрование SSL для повышения безопасности.

Использование аутентификации NTLM для подключения к SQL Серверу - риски безопасности