我们有很多来自前端用户的用户 ID 锁。我们需要向用户提供一个 shell 脚本,他们可以在操作系统级别运行,并在 DBA 不在场时自行解锁 ID。
脚本运行时需要在运行时解密sys密码,并在脚本成功执行后加密。(理想情况下他们不应该看到密码)
我们有多个数据库,因此必须仅以以下方式传递参数。
示例语法:./tmp/unlock_user.sh user instance_name
这个要求太高了。我知道。如果有人可以提供帮助,那就太好了。
操作系统:通用 Linux
数据库:11gR2
好的问题陈述。
比你想象的更常见。
不,你没有。
您需要找出为什么用户如此频繁地锁定他们的帐户并解决该问题的根本原因,而不是尝试修复症状。
不
,只是……不。
用户永远不可能看到SYS密码。
曾经。
请记住:作为 DBA,您的工作是清理其他人造成的混乱。 始终为自己保留最大最好的工具。
这可能是您问题的一部分。
如果用户在不同的数据库中有不同的密码,那么他们就会把自己搞得一团糟,把自己锁在门外。
您的用户真的可以通过 shell 访问您的数据库主机吗?
接下来你会告诉我他们直接连接到数据库并运行 SQL ...
向前进 ...
如果用户和您的数据库之间有一个应用程序层,那么您应该考虑引入一个“应用程序”帐户,其凭据专门由应用程序使用并且用户永远不会知道。 所有数据库连接都将使用这些凭据进行,用户将不会在您的数据库中拥有自己的帐户。好的,这意味着您必须重新实施帐户身份验证,因为数据库不会为您做这件事,但这应该不是一项艰巨的工作。
使用应用程序帐户还有其他好处。
如果用户在此“共享连接”模型中“将自己锁在外面”,应用程序仍然可以支持他们重置密码(或其他),因为应用程序有自己的凭据和与数据库的连接。如果用户拥有自己的凭据和连接,那么他们将无法进入数据库以重置数据库中的密码,因此您目前的困境。
如果在用户和数据库之间没有应用层(我会认真地问“为什么不呢”?),那么您可能不得不考虑一些[很多]更具侵入性的东西,比如将 Oracle 挂接到 Kerberos 或 [间接] Active目录,为您的用户提供真实的单点登录体验。