Recently we’ve had quite a few migrations to 10g Release 2 and several times been hit by one issue some users consistently get locked with status
LOCKED(TIMED). One good example is with the
SYSMAN users, but more important are locked production accounts.
It turned out that the
FAILED_LOGIN_ATTEMPTS attribute for the
DEFAULT profile has been changed in 10.2.0.2 (actually 10.2.0.1 and above) from
UNLIMITED to the value of 10. Well, that’s good from security point of view. On the other hand, this is really dangerous, especially during or after migrations while chances are high that some process will try to connect with wrong credentials. This can easily end up with a service outage because an application can’t connect.
One way to resolve it is to change the
DEFAULT profile. However, I would recommend leaving it 10 by default and, instead, create a new profile and assign the critical production users to this profile:
CREATE PROFILE DEFAULT_10GR1 LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED; ALTER USER [USERNAME] PROFILE DEFAULT_10GR1;
The next step should be to review this policy with your security officer. By the way, this must be a substantive discussion â€“ a production DBA should be keen to avoid service outages by any means, while a security officer’s priority is preventing unauthorized access.
PS: Interesting that the issue with the
DBSNMP account is supposed to be resolved by creating a special profile â€“
MONITORING_PROFILE. There are few notes on Metalink about it like 336629.1.