我使用db2stop force停止了我的数据库。启动后重启了备份,然后重启 我无法再从客户端连接到db了: 使用命令
db2使用“user”连接到“dbname”
SQL30082N安全处理失败 原因是“42”(“根本能力” 需要“)。SQLSTATE = 08001
密码和用户名是正确的。当使用命令
连接服务器时db2连接到“dbname”
或
db2连接到“dbnmae”用户“user”
或
db2连接到“dbname”用户db2inst1
工作得很好。 我真的很困惑。任何帮助深表感谢 感谢。
到目前为止我尝试了什么:
db2 get dbm cfg | grep -i auth GSS 本地授权插件
(LOCAL_GSSPLUGIN)=服务器 连接认证
(SRVCON_AUTH)= NOT_SPECIFIED 数据库管理员认证 (AUTHENTICATION)=服务器编目 没有权限允许的 (CATALOG_NOAUTH)=没有可信客户端 认证
(TRUST_CLNTAUTH)=客户旁路 联邦认证 (FED_NOAUTH)=否
切换到客户端但没有使用
db2 update dbm cfg using 身份验证客户端
尽管这个问题已经很久了,但对这个问题有一个可靠的答案会很棒。嗨locojay,你是怎么经营的? : - )
我的Windows PC中存在SQL30082N原因码24问题,今天我们在AIX服务器上遇到了同样的问题。
我用谷歌搜索了几个小时并没有找到一个快乐的答案,这与在服务器和客户端中拥有相同名称的用户有关。 IMO它不适用于我,因为我遇到了一个与域隔离的VBox(没有网络)。
我的情况:我以用户db2admin安装了DB2,没有安全性。然后我将DBADM授予VIRTUALUSR01并为该用户提供了密码。
db2 connect to TheBase
工作正常。但
db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword
返回SQL30082N,原因码为24.
答案 0 :(得分:3)
使用客户端身份验证通常是Bad Idea(TM)。那是因为您现在依赖于您可能无法控制的机器进行身份验证。如果我想破坏你的系统,我可以在本地创建一个新用户,比如db2inst1或VIRTUALUSR01或Administrator,用我知道的密码,然后用它来破坏数据库。但是,如果组织中没有人对其自己的计算机具有root / administrator权限,则可以使客户端身份验证起作用。但是,只需要插入自己的个人笔记本电脑,您的数据库就会面临风险。
相反,请检查文件的权限。如果你以root身份安装,那么~db2inst1 / sqllib / security / db2c [hk] pw(假设db2inst1的实例ID)应该是setuid root。如果没有,请对应该修复权限的实例(./db2iupdt db2inst1
)运行db2iupdt。
如果你没有root权限(“非root安装”)安装,我怀疑,因为你似乎已经有了这个工作,你需要阅读关于非root安装的DB2文档及其局限性 - 我自己不使用非root安装,所以我对它们并不熟悉。但是,应该有一个可以用来启用setuid root的set-root脚本,当然,你必须以root身份运行。
答案 1 :(得分:0)
我遇到了同样的问题,并采用以下方式解决。
由于/ 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`
之后,将使用MD5生成属于userName的密码哈希。
现在向该用户授予用户权限:
# su - db2inst1
(db2inst1)$ db2 connect to databaseName
(db2inst1)$ db2 GRANT DBADM with dataaccess with accessctrl on database to user userName
我希望它也适合你。
感谢Honza的solution
答案 2 :(得分:0)
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.