DB2 не может подключиться от клиентов после перезапуска

Question

Я остановил свой дБ с помощью силы db2stop. Запустил сделал бекап перезапустил и после этого я не могу подключиться к БД от клиента больше я получаю: используя команду

db2 подключается к "dbname", используя "user"

SQL30082N Ошибка обработки безопасности с причиной "42" ("ROOT CAPABILITY ТРЕБУЕТСЯ "). SQLSTATE = 08001

пароль и имя пользователя верны. При подключении к серверу с помощью команды

db2 подключается к "dbname"

или

db2 подключается к «dbnmae» пользователю «user»

или

db2 подключается к пользователю "dbname" db2inst1

работает просто отлично. Я действительно смущен. Любая помощь высоко ценится Спасибо.

Что я пробовал до сих пор:

db2 get dbm cfg | grep -i auth GSS Плагин для локальной авторизации
(LOCAL_GSSPLUGIN) = Сервер Аутентификация подключения
(SRVCON_AUTH) = NOT_SPECIFIED Проверка подлинности менеджера баз данных
(АУТЕНТИФИКАЦИЯ) = СЕРВЕР Каталогизация разрешено без разрешения
(CATALOG_NOAUTH) = НЕТ доверенный клиент Аутентификация
(TRUST_CLNTAUTH) = обход клиента федеративная аутентификация
(FED_NOAUTH) = НЕТ

переключился на клиента, но не использовал

Обновление db2 dbm cfg с использованием клиент аутентификации

Обновление:

Несмотря на возраст этого вопроса, было бы замечательно иметь твердый ответ на этот вопрос. Привет, locojay, как ты справился? : -)

У меня проблема с кодом причины SQL30082N 24 на моем ПК с Windows, и сегодня мы столкнулись с той же проблемой на сервере AIX.

Я гуглил пару часов и не нашел, кроме одного счастливого ответа, связанного с наличием пользователей с одинаковыми именами как на сервере, так и на клиенте. IMO, это не относится ко мне, так как я работаю с VBox, который изолирован от домена (без сети).

Мой случай: я установил DB2 как пользователь db2admin, без защиты. Затем я предоставил DBADM VIRTUALUSR01 и дал этому пользователю пароль.

  db2 connect to TheBase

работает отлично. Но

  db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword 

возвращает SQL30082N с кодом причины 24.

Answer 1

Использование аутентификации клиента обычно является плохой идеей (TM).Это потому, что вы теперь полагаетесь на машины, которые вы не можете контролировать для аутентификации.Если бы я хотел подорвать вашу систему, я мог бы создать нового пользователя локально, скажем, db2inst1 или VIRTUALUSR01 или Администратор, с паролем, который я знаю, и затем использовать его, чтобы нанести ущерб базе данных.Если, однако, никто в вашей организации не имеет полномочий root / администратор на своих компьютерах, проверка подлинности клиента может быть выполнена.Но все, что для этого нужно - это подключить собственный персональный ноутбук, и ваша база данных может оказаться под угрозой.

Вместо этого проверьте права доступа к файлам.Если вы установили с правами root, ~ db2inst1 / sqllib / security / db2c [hk] pw (при условии, что идентификатор экземпляра db2inst1) должен быть установлен в root.Если нет, запустите db2iupdt для вашего экземпляра (./db2iupdt db2inst1), который должен исправить разрешения.

Если вы установили без полномочий root («установка без полномочий root»), в чем я сомневаюсь, поскольку вы, похоже,Если бы это работало, вам нужно было бы прочитать документацию DB2 об установках без полномочий root и их ограничениях - я не использую установки без полномочий root, поэтому я не очень знаком с ними.Однако должен быть скрипт set-root, который вы можете использовать для включения setuid root, который, конечно, вы должны запускать как root .

Answer 2

Solutions to specific problem causes described previously in
     this message are:
     1. Run DB2IUPDT <InstName> to update the instance.

     2. Ensure that the username created is valid. Review the DB2
        General Naming Rules.

     3. Ensure that catalog information is correct.

Answer 3

У меня была такая же проблема, и я решил ее следующим образом.

Проблема возникает из-за файла / etc / shadow. Если хэш пароля пользователя создается с помощью SHA, DB2 не сможет аутентифицировать или авторизовать этого пользователя. Вам нужен MD5 для хеширования пароля этого пользователя.

Если вы используете Fedora или RedHat Linux, сначала измените метод хеширования паролей с помощью:

# authconfig –-passalgo md5 –-update

Затем удалите и заново создайте пользователя:

# userdel userName
# useradd userName
# passwd userName

Если вы используете AIX или любой другой дистрибутив Linux, authconfig не будет работать. Поэтому вместо passwd userName введите следующую команду:

# usermod --password `openssl passwd desiredPassword`

После этого ваш хэш пароля, принадлежащий userName, будет сгенерирован с помощью MD5.

Теперь предоставьте пользователю права этого пользователя:

# su - db2inst1
(db2inst1)$ db2 connect to databaseName
(db2inst1)$ db2 GRANT DBADM with dataaccess with accessctrl on database to user userName

Надеюсь, это сработает и у вас.

Спасибо Honza за его решение