Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Здравствуйте всем! Есть сервер DB2 UDB 8.2. Создан инстанс с типом аутентификации SERVER. Мы разрабатываем виндовое десктопное приложение, которое устанавливается на стороне клиента и через DB2 RunTime Client удаленно работает с базой данных. В приложении реализовано собственное окно авторизации, которое запрашивает логин и пароль пользователя для формирования строки коннекта. Для соединения с базой данных используется строка коннекта: Код: plaintext Столкнулись со следующей проблемой. В организации на рабочих станциях используется eToken - персональное средство строгой аутентификации и хранения данных. Пользователь знает только свой логин и пинкод, пароль неизвестен. Вследствие чего он не может авторизироваться в программе, не может соединиться с базой данных. Вопрос: Что изменить в системе авторизации приложения или в настройках сервера DB2(его инстанса), чтобы не отказывать пользователям с eToken? Есть предположение, что мне поможет изменение типа аутентификации инстанса DB2 на Kerberos или Client, но тогда, скорее всего потребуется изменить и строку коннекта, а может и всю систему авторизации в приложении. Чем отличаются типы аутентификации экземляров баз данных? Есть ли особенности работы с базой данных при разных типах аутентификации? Заранее благодарен С уважением, Семен Попов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 09:52 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Я так понимаю у вас DB2 берёт пользователей из домена? (DB2_GRP_LOOKUP=DOMAIN) ? Можно перестроить что бы брала локальных пользователей с сервера DB2 DB2_GRP_LOOKUP=LOCAL Заведите их локально на сервере DB2, объедините в группы и логиньтесь под локальными паролями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 10:27 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Ivan IvanichЯ так понимаю у вас DB2 берёт пользователей из домена? (DB2_GRP_LOOKUP=DOMAIN) ? Можно перестроить что бы брала локальных пользователей с сервера DB2 DB2_GRP_LOOKUP=LOCAL Заведите их локально на сервере DB2, объедините в группы и логиньтесь под локальными паролями. Сейчас временно так и вышли из ситуации. Завели таких пользователей локально. Назначили пароли и сообщили им. DB2_GRP_LOOKUP=LOCAL было всегда. Работает и для доменных пользователей. Но не нравится мне это. Если мы работаем с пользователями, то они должны в одном месте. У нас они хранятся в домене. Мне интересно следующее. При удаленном соединении с базой всегда нужно задавать логин и пароль или это зависит от типа аутентификации экземпляра? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 10:47 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Небольшой оффтоп. Вообще-то мы тоже работаем с еtoken и пользователи знают свои доменные пароли. Не проще ли сказать им эти пароли. Пусть они думают, что это для вот этой вашей прикладухи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 10:52 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
вот если только это попробовать покурить: Параметр конфигурации trust_allclnts - доверять всем клиентам Тип конфигурации Менеджер баз данных Применяется к * Серверу баз данных с локальными и удаленными клиентами * Серверу баз данных с локальными клиентами * Серверу многораздельной базы данных с локальными и удаленными клиентами Тип параметра Изменяемый По умолчанию [Диапазон] YES [NO, YES, DRDAONLY] Этот параметр активен, только если для параметра authentication задано значение CLIENT. Этот параметр и параметр trust_clntauth используются для задания места проверки пользователей в среде базы данных. Если принять для этого параметра значение по умолчанию "YES", все клиенты будут рассматриваться как доверенные. Это означает, что сервер считает, что уровень защиты устанавливается на клиенте, и проверка пользователей может проводиться на клиенте. Этот параметр можно изменить "NO", если для параметра authentication задано значение CLIENT. Если этот параметр имеет значение "NO", недоверенные клиенты при соединении с сервером должны сообщать и ID пользователя, и пароль. Недоверенные клиенты - это платформы с операционными системами, где нет подсистем защиты для идентификации пользователей. Если параметр равен "DRDAONLY", то доступ будет запрещен всем клиентам, за исключением клиентов, работающих с DB2 для OS/390 и z/OS, DB2 для VM и VSE или DB2 для OS/400. Только на этих клиентах предусмотрены средства идентификации пользователей. Все остальные клиенты должны проходить аутентификацию на сервере, предоставляя ID пользователя и пароль. Когда параметр trust_allclnts имеет значение "DRDAONLY", параметр trust_clntauth задает, где проводится аутентификация клиентов. Если trust_clntauth имеет значение "CLIENT", аутентификация производится на клиенте. Если trust_clntauth имеет значение "SERVER", аутентификация проводится на клиенте, если пароль не задан, и на сервере, если пароль задан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 11:01 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Ivan IvanichНебольшой оффтоп. Вообще-то мы тоже работаем с еtoken и пользователи знают свои доменные пароли. Не проще ли сказать им эти пароли. Пусть они думают, что это для вот этой вашей прикладухи.Забыл сказать ещё. Безопасники настроили eToken так, чтобы он раз в период менял пароли пользователя в домене. Делается это автоматом. И безопасники не хотят извещать пользователя о новом пароле. Пользователь имеет смарт-ключ, логин и пинкод. Больше ничего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 11:42 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Ivan Ivanichвот если только это попробовать покурить: ...Спасибо. Посмотрим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 11:44 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Тогда не совсем понятно чего вы хотите? Что бы пользователь вводил только логин а пароль нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 11:50 |
|
||
|
Решение по типу авторизации
|
|||
|---|---|---|---|
|
#18+
Ivan IvanichТогда не совсем понятно чего вы хотите? Что бы пользователь вводил только логин а пароль нет?Наверно, да. Или вообще ничего не вводил (ведь запрос авторизации в приложении можно вообще убрать). Я спрашиваю про общее решение. Что можно поменять в системе авторизации приложения и в настройках аутентификации DB2 для того, чтобы таким пользователям можно было работать с приложением(базой данных)? Тип аутентификации KERBEROS не подойдет? Тогда бы пароль не нужен был. Предполагаю, что в этом случае для идентификации пользователя в домене используется некий сертификат. Или я не прав? И как тогда поменяется строка коннекта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 12:21 |
|
||
|
|
start [/forum/topic.php?fid=43&msg=36807654&tid=1602623]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
176ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 323ms |
| total: | 591ms |
| 0 / 0 |
