今天同事反映一个问题,某个测试库修改了密码,并改了相关应用使用的密码后,仍出现一会账户就被锁住,报ORA-28000: the account
今天同事反映一个问题,某个测试库修改了密码,并改了相关应用使用的密码后,仍出现一会账户就被锁住,报ora-28000: the account is locked的错误。
检查过程:
1. 查看资源限制生效参数
sql> show parameter resource
name type value
------------------------------------ ----------- ------------------------------
resource_limit boolean false
false表示未启动资源限制。
2. 查看该用户所用的profile
sql> select resource_name, limit from dba_profiles where profile='default';
resource_name limit
-------------------------------- ----------------------------------------
composite_limit unlimited
sessions_per_user unlimited
cpu_per_session unlimited
cpu_per_call unlimited
logical_reads_per_session unlimited
logical_reads_per_call unlimited
idle_time unlimited
connect_time unlimited
private_sga unlimited
failed_login_attempts 10
password_life_time unlimited
password_reuse_time unlimited
password_reuse_max unlimited
password_verify_function null
password_lock_time 1
password_grace_time 7
其中failed_login_attempts表示连续登陆失败的次数,这里表示连续登陆10次失败则锁定用户。
3. 解除用户锁定alter user pss3 account unlock;后观察现象
sql> select name, lcount from user$ where;
name lcount
------------------------------ ----------
pss3 10
不到一分钟,登陆失败次数就到10次了。
初步结论:
可能有应用仍使用旧的密码登陆,登陆失败后重复尝试,直到10次为止。
但问题就来了:
1. failed_login_attempts设置为10次,但未启动resource_limit,为什么还受到10次的限制呢?
2. 怎么知道还有哪些应用由于未修改密码导致ora错误呢?
问题1:failed_login_attempts设置为10次,但未启动resource_limit,为什么还受到10次的限制呢?
这篇mos文章160528.1(profile limits (resource parameter(s)) are not enforced / do not work)文章说了一些:
after creating a new profile or altering an old one to limit the following profile resources there is no change:
sessions_per_user
cpu_per_session
cpu_per_call
connect_time
idle_time
logical_reads_per_session
composite_limit
private_sga
the resource usage limits are not enforced and the users that are assigned the profile continue to use resources beyond profile's limits.
cause
the initialization parameter resource_limit is set to false (default).
由于未设置resource_limit为true,以上变量修改后不会生效。
这里没有提到failed_login_attempts,换句话说,像failed_login_attempts这些变量是不受resource_limit参数限制的,再看failed_login_attempts这种变量属于用户口令管理方面的,像上面这些变量则属于资源管理方面的,猜测oracle对于资源管理的限制则需要resource_limit为true,对于口令管理方面的限制并不受resource_limit的影响。
ocp教材中正好说了:“profiles are a useful way of managing passwords and resources but can really only apply in an environment where every application user has their own database user account.”注意到这里他将profile分成管理密码和资源两大类,虽然没有明说,但结合以上两段参考,以及上述实际碰到的问题,有理由相信口令管理方面的限制并不受resource_limit参数的影响。
问题2:怎么知道还有哪些应用由于未修改密码导致ora错误呢?
上面尝试了unlock账户后不到一分钟lcount登录失败次数就到了10次,说明这段时间有应用频繁重试密码,进一步,如果我们能找到这段时间访问库的ip,再筛选可能的ip和密码修改的应用,就可能找到“罪魁祸首”。
要想找到访问库的ip,可以通过设置监听日志,查找ip。
监听器的日志类似于alert日志,帖子中说日志默认路径是$oracle_home/network/log/listener.log,但我用的11g,不知道是否修改过,并没有找到这个目录。至于怎么找到的,接下来会说到。
按照@secooler的教程,开启监听器日志的方式有两种:
1. 不需要重启监听器的情况下通过设置log_status参数为off来实现。
2. listener.ora文件中增加logging_
可以根据不同需要选择不同的方式。
这里我选择第一种,执行lsnrctl后执行set log_status on,然后需要找到日志路径:
ora11g@vm-kvm-ora$ lsnrctl status
lsnrctl for linux: version 11.2.0.3.0 - production on 20-aug-2014 11:56:27
copyright (c) 1991, 2011, oracle. all rights reserved.
connecting to (address=(protocol=tcp)(host=)(port=1521))
status of the listener
------------------------
alias listener
version tnslsnr for linux: version 11.2.0.3.0 - production
start date 30-apr-2014 15:22:19
uptime 111 days 20 hr. 34 min. 8 sec
trace level off
security on: local os authentication
snmp off
listener parameter file /oracle/ora11g/product/11.2.0/network/admin/listener.ora
listener log file /oracle/ora11g/diag/tnslsnr/vm-kvm-ora/listener/alert/log.xml
这里我们看到有个信息listener log file,,后面就是对应的日志路径和日志文件名。
11g中使用了log.xml这种xml格式记录监听日志。
内容类似于:
因此只需要找到解锁用户后仍登录的ip,然后再筛选可能的应用就行了。
这里还有个知识点,就是failed_login_attempts设置的是连续登录失败的次数,还是累计登录失败的次数?
failed_login_attempts表示连续登录失败的次数。
Oracle 11g 在RedHat Linux 5.8_x64平台的安装手册
Linux-6-64下安装Oracle 12C笔记
在CentOS 6.4下安装Oracle 11gR2(x64)
Oracle 11gR2 在VMWare虚拟机中安装步骤
Debian 下 安装 Oracle 11g XE R2
本文永久更新链接地址:
Copyright 2014-2024 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号