kamelot,

Второй вариант - перевести базу в режим аутентификации по kerberos'у (пользователь доменный?). На authentication client владельцы базы могут не согласиться - совсем не секъюрно.
Но на authentication по керберосу тоже могут не согласится - уж больно много там приколов может повылезать :) (в том числе можно настроить всё так, что тоже получится не секъюрно).

В любом случае - что говорят "владельцы" базы?

kamelot,

Про Керберос - внутре у неё неонка... виндовая доменная аутентификация работает, собственно, по Керберос протоколу (внутри себя Керберос реализует) и к нему можно подключаться из тех же *NIX'ов Kerberos клиентами.

У DB2 тип аутентификации определяет для работающего экземпляра СУБД, где и с помощью каких механизмов будет эта аутентификация происходить.
Далее берётся username идентифицированного пользователя и от него уже внутри СУБД определяются права на объекты базы.

Наиболее часто употребимый тип - SERVER. В этом случае клиент (или DB2'шный драйвер) отправляет имя пользователя и пароль DB2 серверу (в рамках DRDA handshake), а тот обращается к операционной системе за проверкой, валидны ли userid/password. В Вашем случае ОС с DB2 сервера лезет к контроллеру домена за этой самой проверкой (ну или на сервере, если он не в домене/не под виндами надо заводить пользователей с идентичными доменным именами и паролями).

Для аутентификации типа CLIENT, все проверки происходят на стороне клиента. Т.е. для того, чтобы пробраться в базу под чужим именем достаточно завести локального пользователя с нужным userid и ломиться под ним к базе.

При аутентификации по типу KERBEROS СУБД и клиент обмениваются только полученными от KDC (домен-контроллера) тикетами и обращаются к KDC за проверками/формированием тикетов.


Для аппликух, обращающихся через полноценного DB2 клиента (в том числе JDBC type 2) изменение аутентификации с SERVER на KERBEROS прозрачно.
Есть ньюанс - когда каталогизируем базу, тип аутентификации должен быть либо пропущен, либо указан как KERBEROS вместе с TARGET PRINCIPAL (не будем показывать пальцами, но скажем, что некоторая аппликуха, название которой начинается с Quest и заканчивается на Central, любит навязывать проставить чего-нибудь в качестве типа аутентификации, предлагая по дефолту "SERVER", закаталогизированную таким образом базу нужно сначала uncatalog'изировать и затем добавить по-человечески).

Для обращающихся напрямую в connection string добавляем:
- для .Net аппликух и подобного - ";Authentication=KERBEROS"
- для Java аппликух - ";securityMechanism=11" или ";securityMechanism=KERBEROS_SECURITY".


Там ещё очень много других проблем и проблемок:
- если друг с другом общаются несколько DB2 серверов, работающих под виндами, то надо всех их пускать под различными аккаунтами - в виндах в формировании principal name отсутствует имя хоста :O, а за одинаковое имя они в некоторых случаях "подерутся"
- для возможности обращения к виндовому DB2 серверу по Керберосу с *NIX'ов и из Java необходимо от доменного администратора выполнить:
- для Java в krb5.conf/krb5.ini в частности должны быть прописаны корректные default_tkt_enctypes/default_tgs_enctypes, дефолтовые значения, которые, видимо, отличаются в реализациях JAAS у IBM и SUN, не всегда работают (а когда не работают, без вменяемой диагностики (см. следующий пункт), можно долго биться лбом в эту проблему - общение с IBM premium support'ом на эту тему продолжалось не один месяц, правда не то, чтобы в форсированном режиме).
- в обязательном порядке использовать последние JDBC драйвера (сейчас это от 9.7.7), в них _значительно_ более вменяемая диагностика проблем по сравнению с чуть более старыми (от 9.7.6).
- коннект из Java приложений без указания пары логин+пароль требует предварительного формирования тикета сам по себе не происходит, а требует предварительного формирования тикета со своими особенностями.
- необходимо представлять, какой реально encription type используется, а то от secure'ности кербероса может остаться одни пшик (в то время когда будете думать, что всё "круто").
- свои проблемы/особенности с коннектом к DB2 for LUW со стороны AS/400 аппликух (здесь пока не всё ясно, но есть, вроде, внятные гайды по этому делу).
- свои хитрости с прозрачной аутентификацией в распределённых базах (при работе с никнеймами).
- при работе SAS с AIX'а столкнулись с проблемой - эта тварь на запросах одного типа (не помню уже, INSERT или DELETE, на других нормально) всегда преобразует имя пользователя в upper case, какой бы он ни был указан в конфигурации источника данных. AIX'овый Kerberos клиент (клиентская часть его стандартного NAS) - case sensitive, виндовый - в общем-то тоже (просто внутри себя всегда преобразует регистр перед отправкой к KDC, но в другую сторону), единственный предполагаемый work around на настоящий момент - специальные аккаунты для SAS из одних цифр :/

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


Есть ещё один тип аутентификации - KRB_SERVER_ENCRYPT, который для клиентов, поддерживающих Керберос будет идентичен KERBEROS, а для остальных - SERVER_ENCRYPT (идентичен SERVER, только логин с паролем по сетке не в открытом виде гоняются).

Чем определяется это "поддерживающих" - параметрами connection string/каталогизации на клиенте (т.е. сами выбираем) или ОС клиента - не могу сказать, не проверял. Скорее первое.
Для целенаправленного перевода системы на Kerberos это не очень годится - у всех найдётся 1000 причин, почему именно им сейчас этот переход делать не нужно (сроки, ресурсы, наседающий с требованиями бизнес и прочие, действительно объективные причины), но, возможно, Вам этот метод как раз подойдёт.


PS для проверки "connectivity" .Net аппликух к базе с заданной connection string удобно использовать тулзы из DB2 клиента: