Comments 18
Я в этих айтишных делах ваших новенький. Объясните, почему статья отхватывает минусы?
И где встроенная windows аунтефикация?
String connectionUrl = «jdbc:sqlserver://sqlcore1.p4.local:1433;integratedSecurity=true;authenticationScheme=JavaKerberos;domain=p4.local;userName=javawin;password =!Qaz123wsx;trustServerCertificate=true»;
integratedSecurity=true;authenticationScheme=JavaKerberos
запрос
select @servernamee as srv, system_user as usr, auth_scheme from sys.dm_exec_connections where session_id=@spid
и результат
SQLCORE1 P4\javawin KERBEROS
Так а зачем username и password? Весь смысл integrated security в том, что их не нужно указывать!
А как в линуксе можно еще запустить в контексте пользователя AD?
Может действительно возможно, было бы инетересно посмотреть, Вы знаете?
Так и чего вы достигли начав с
"создать механизм аудита и плановой смены паролей" - а это плохо
И в решении снова придя к хардкоду пароля в connection string?
Шило на мыло
При SQL аутентификации пароль надо менять на каждом SQL сервере а при AD аутентификации только в одном месте. Ну и естественно в строке подключения приложения.
Конечно, было-бы интересно, запустить приложение в Linux с gMSA AD учетной записью, но я ни какой информации о такой возможности не нашел.
Кратко посмотрел. Это не то?
https://thesecmaster.com/step-by-step-procedure-to-set-up-an-active-directory-on-ubuntu/
Еще раз оговорюсь, что я не специалист Linux.
Как я понял, все эти решения позволяют пользователям AD логинится на Linux машины, а запустить сервис на Linux так, чтобы при подключении к доменному серверу использовался AD контекст безопасности я не встречал.
Поэтому и опубликовал статью здесь, чтобы получить оценку этого метода и возможно более правильное решение.
А вы не про линукс рассказываете, а про JDBC. А значит про Java. А там это означает JAAS, его kerberos login module (который возможно и получит логин и пароль — но скорее keytab и principal, как напишете в jaas.conf). А дальше уже получит TGT, и TGS. И с ними уже пойдет в базу. Но это все вы в статье опустили, уж не знаю по какой причине. При этом первая же статья в поиске гугля ведет на вполне вменяемую русскую инструкцию, где все как раз хорошо описано. Вероятно по этой причине и минусы.
Я может не достаточно глубоко копал эту тему, пойдя по самому простому пути. Расскажите, пожалуйста, в чем преимущество JAAS в сравнении с настройкой параметров Kerberos в krb5.conf?
Это перпендикулярные вещи вообще.
krb5.conf — это, упрощенно, конфиг, который говорит вашему коду, где у вас KDC. Это сильное упрощение, но для начала сойдет. То есть, там внутри где-то написано:
kdc = p4.local
А JAAS — это Java API (Java Authentication and Authorization Service) для аутентификации и авторизации в самом общем виде. К керберосу имеет отношение один его модуль. И указывает его конфиг, тоже сильно упрощенно, как мы собственно будем аутентифицироваться, т.е. скажем, нужно ли спросить пароль, и войти с логином и паролем, или у нас есть keytab, или у нас есть кеш тикетов, где мы уже получили и сохранили TGT и какие-то TGS. Ну и всего с десяток параметров там в наличии:
В общем, это большая и длинная тема, керберос из Java, и тем более применительно к JDBC и конкретной СУБД (потому что еще специфика конкретного драйвера присутствует, и даже его конкретной версии). И вы ее какую-то часть отразили, причем явно не всю.
И указание пароля и логина (ну и домена) в URL меня лично тоже очень смутило сразу. По той же причине, что уже выше описали — если мы пароль прямо тут указываем, это вообще небезопасно, помимо всего прочего.
Логин и пароль в строке подключения для упрощения примера.
Вот рекомендации. Но это уже не относится к основной теме. Если gMSA на Linux использовать не получится, то все равно пароль будет доступен человеку.
Как я понял, если идет подключение только к одному домену, то настройки файла krb5.conf достаточно и это самый простой путь. Если надо работать с несколькими доменами или подключаться еще к каким то сервисам c Kerberos кроме MSSQL, то тогда надо настраивать JAAS. Или я не прав?
Логин и пароль в строке подключения для упрощения примера.
Этим вы всех смутили — это точно.
Как я понял, если идет подключение только к одному домену, то настройки файла krb5.conf достаточно и это самый простой путь.
Еще раз — krb5.conf это описание самих доменов, и где у них KDC. То есть, если нужно несколько доменов — то скорее всего у вас либо будет два конфига, хотя я ни разу не сталкивался с такой схемой, и возможно все можно описать в одном конфиге. Но в любом случае — этот конфиг нужен, чтобы софт знал, куда собственно ходить за тикетами, где KDC.
еще к каким то сервисам c Kerberos кроме MSSQL, то тогда надо настраивать JAAS
Вообще, JAAS это не конфиг. Это API. И там очень много всего можно сделать, например, аутентифицироваться и авторизоваться при помощи двух и более модулей, т.е. скажем керберос и через ОС (или любой другой механизм, скажем LDAP). Причем модули могут комбинироваться разными способами (скажем, для успеха достаточно одного, или нужны все).
С помощью jaas.cong можно точно настроить простые случаи, типа одного модуля Krb5Login, которому вы скажете, что предъявить нужно логин и пароль, или же keytab например. Про более сложные на память не скажу.
В любом случае, керберос для линукса вполне себе родная система, да и для Java есть несколько реализаций (включая реализацию не только клиента, но и KDC). Так что все должно получиться. Я в этой теме с MS SQL не копался давно, но как по мне, указание integratedSecurity=true;authenticationScheme=JavaKerberos вообще должно бы приводить к тому, что JDBC драйвер попытается использовать имеющиеся керберос тикеты, полученные при выполнении команд kinit/knvo.
Kerberos аутентификация при подключении из Java к MSSQL