Oracle error 28000

Account status in dba_users show open but connection on Standby fails as ‘ORA-28000: the account is locked’ (Doc ID 2440122.1) Last updated on OCTOBER 10, 2022 Applies to: Symptoms Account status in dba_users show open but connection fails as ‘account locked’. When connecting to the user via sqldevelope or sqlplus, we are getting user […]

Содержание

  1. Account status in dba_users show open but connection on Standby fails as ‘ORA-28000: the account is locked’ (Doc ID 2440122.1)
  2. Applies to:
  3. Symptoms
  4. Cause
  5. To view full details, sign in with your My Oracle Support account.
  6. Don’t have a My Oracle Support account? Click to get started!
  7. sidadm
  8. Полезное
  9. 24 сентября 2020 г.
  10. Ошибка ORA-28000: the account is locked
  11. 4 комментария:
  12. IT World
  13. Who is locking your accounts (ORA-01017 and ORA-28000 errors) ?
  14. Table of contents
  15. Preamble
  16. ORA-01017/ORA-28000 with AUDIT_TRAIL
  17. ORA-01017/ORA-28000 without AUDIT_TRAIL
  18. Разблокировка и доступ к пользователю HR в Oracle Database 18c Express Edition

Account status in dba_users show open but connection on Standby fails as ‘ORA-28000: the account is locked’ (Doc ID 2440122.1)

Last updated on OCTOBER 10, 2022

Applies to:

Symptoms

Account status in dba_users show open but connection fails as ‘account locked’.

When connecting to the user via sqldevelope or sqlplus, we are getting user account is locked. This is for standby ADG database
SQL> select username,account_status from dba_users where username=’USER1′;

SQL> SQL> conn USER1
Enter password:
ERROR:
ORA-28000: the account is locked

SQL> select open_mode,controlfile_type from v$database;

OPEN_MODE CONTROL
——————— ——-
READ ONLY WITH APPLY STANDBY

Cause

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Oracle offers a comprehensive and fully integrated stack of cloud applications and platform services. For more information about Oracle (NYSE:ORCL), visit oracle.com. пїЅ Oracle | Contact and Chat | Support | Communities | Connect with us | | | | Legal Notices | Terms of Use

Источник

sidadm

записки SAP Basis консультанта

Полезное

24 сентября 2020 г.

Ошибка ORA-28000: the account is locked

Рис. 1. Пример успешной проверки соединения с базой данных.
Рис. 2. Пример безуспешной проверки соединения с базой данных.
Рис. 3. Пример кода ошибки соединения с остановленной базой данных.
Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

SQL> select LIMIT from DBA_PROFILES where PROFILE=’DEFAULT’ AND RESOURCE_NAME=’FAILED_LOGIN_ATTEMPTS’;

SQL> alter user SAPSR3 account unlock;

SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 50;

4 комментария:

Спасибо за статью! Очень полезно.
Скажите, пожалуйста, у меня после миграции системы с Оracle10 на oracle12 получилась такая ситуация, что через полгода истек пароль на пользователя подключения к базе
ERROR: Connect to SAP failed (20200817003713, ORA-28001: the password has expired).
Похожая ошибка, что и описаная в статье, но тут expired.
Не сталкивались ли вы с таким? Есть какой-то способ этой ошибки избежать? Спасибо!

Ruslan, добрый день. Я не сталкивался. Но судя по быстрому поиску за это отвечает параметр PASSWORD_LIFE_TIME, который с Oracle 11 стал иметь значение по умолчанию = 180 дней. Варианта решения я вижу два: поменять значение параметра, а пользователя разблокировать командой, приведённой в статье. Посмотрите вот тут — https://www.stechies.com/error-ora28001-password-expired-during-system-startup/
SQL-команда отключения периода действия пароля примерно такая:
alter profile default limit password_life_time unlimited;
На сколько установка такого значения корректна со стороны рекомендаций SAP, я сходу не нашёл.
Либо второе решение — запланировать периодическую смену пароля владельца схемы. Через BRTools. Такое решение отвечает требованиям безопасности.

Спасибо большое! Все действительно оказалось довольно просто. Всего две команды
SELECT resource_name,limit FROM dba_profiles WHERE profile=’DEFAULT’ AND resource_name=’PASSWORD_LIFE_TIME’; смотрим
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED; меняем
Спасибо!

Источник

IT World

RDBMS, Unix and many more…

Who is locking your accounts (ORA-01017 and ORA-28000 errors) ?

Table of contents

Preamble

I have decided to write this blog post after second time I received question on how to know from where are coming connections that are locking an account in an Oracle database…

Do not smile, I have seen at least two situations where, after a password change, a batch job was initiating plenty of connection (with previous wrong password) and no one was able to know from where this batch job was running (!!).

As a reminder, with default profile in Oracle 11g, accounts are automatically locked 1 day (PASSWORD_LOCK_TIME) after 10 failed login attempt (FAILED_LOGIN_ATTEMPTS):

SQL> set lines 200 SQL> set pages 200 SQL> select * from dba_profiles where profile=’DEFAULT’ order by resource_name; PROFILE RESOURCE_NAME RESOURCE LIMIT —————————— ——————————— ——— —————————————- DEFAULT COMPOSITE_LIMIT KERNEL UNLIMITED DEFAULT CONNECT_TIME KERNEL UNLIMITED DEFAULT CPU_PER_CALL KERNEL UNLIMITED DEFAULT CPU_PER_SESSION KERNEL UNLIMITED DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10 DEFAULT IDLE_TIME KERNEL UNLIMITED DEFAULT LOGICAL_READS_PER_CALL KERNEL UNLIMITED DEFAULT LOGICAL_READS_PER_SESSION KERNEL UNLIMITED DEFAULT PASSWORD_GRACE_TIME PASSWORD 7 DEFAULT PASSWORD_LIFE_TIME PASSWORD 180 DEFAULT PASSWORD_LOCK_TIME PASSWORD 1 DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL DEFAULT PRIVATE_SGA KERNEL UNLIMITED DEFAULT SESSIONS_PER_USER KERNEL UNLIMITED 16 rows selected.

Oracle client session will received 10 times ORA-01017: invalid username/password; logon denied error message and then ORA-28000: the account is locked error message (for one day and then back to ORA-01017 error message).

The final question is how to identify from where (client IP address/name) are coming those tentative connections… I have done my testing using Oracle 11.2.0.3 running on Oracle Linux Server release 6.3.

ORA-01017/ORA-28000 with AUDIT_TRAIL

The first and preferred solution is with Oracle standard auditing feature. Start by setting initialization parameter AUDIT_TRAIL to db and restart your Oracle database as it is static parameter.

Then activate network auditing with (as SYS):

SQL> audit network by access; Audit succeeded.

With below query you get everything needed:

select * from dba_audit_session order by sessionid desc;

Returncode column contains Oracle error code and so different of 0 if logon/logoff issue. The invalid password is the error we are chasing:

]$ oerr ora 1017 01017, 00000, «invalid username/password; logon denied» // *Cause: // *Action:

So if you find 1017 values in this column then we have found what we were looking for. For example with my test case where I intentionally specify a wrong password for my account:

SQL> select username,userhost,returncode from dba_audit_session where username=’YJAQUIER’ order by sessionid desc; USERNAME USERHOST RETURNCODE —————————— ——————— ———- YJAQUIER server1 1017 YJAQUIER GVADT30596 0 YJAQUIER server1 0 YJAQUIER server1 0 . . .

And if you insist, as explained, you get:

SQL> select username, account_status,lock_date, profile from dba_users where username=’YJAQUIER’; USERNAME ACCOUNT_STATUS LOCK_DATE PROFILE —————————— ——————————— ——————— —————————— YJAQUIER LOCKED(TIMED) 23-nov-2012 10:30:37 DEFAULT

If you set AUDIT_TRAIL to db behave the size of SYS.AUD$ table as a small list of audits are already implemented by default:

SQL> set lines 200 SQL> set pages 200 SQL> select * from DBA_STMT_AUDIT_OPTS; USER_NAME PROXY_NAME AUDIT_OPTION SUCCESS FAILURE —————————— —————————— —————————————- ———- ———- ALTER SYSTEM BY ACCESS BY ACCESS SYSTEM AUDIT BY ACCESS BY ACCESS CREATE SESSION BY ACCESS BY ACCESS CREATE USER BY ACCESS BY ACCESS ALTER USER BY ACCESS BY ACCESS DROP USER BY ACCESS BY ACCESS PUBLIC SYNONYM BY ACCESS BY ACCESS DATABASE LINK BY ACCESS BY ACCESS ROLE BY ACCESS BY ACCESS PROFILE BY ACCESS BY ACCESS CREATE ANY TABLE BY ACCESS BY ACCESS ALTER ANY TABLE BY ACCESS BY ACCESS DROP ANY TABLE BY ACCESS BY ACCESS CREATE PUBLIC DATABASE LINK BY ACCESS BY ACCESS GRANT ANY ROLE BY ACCESS BY ACCESS SYSTEM GRANT BY ACCESS BY ACCESS ALTER DATABASE BY ACCESS BY ACCESS CREATE ANY PROCEDURE BY ACCESS BY ACCESS ALTER ANY PROCEDURE BY ACCESS BY ACCESS DROP ANY PROCEDURE BY ACCESS BY ACCESS ALTER PROFILE BY ACCESS BY ACCESS DROP PROFILE BY ACCESS BY ACCESS GRANT ANY PRIVILEGE BY ACCESS BY ACCESS CREATE ANY LIBRARY BY ACCESS BY ACCESS EXEMPT ACCESS POLICY BY ACCESS BY ACCESS GRANT ANY OBJECT PRIVILEGE BY ACCESS BY ACCESS CREATE ANY JOB BY ACCESS BY ACCESS CREATE EXTERNAL JOB BY ACCESS BY ACCESS

So you must put in place a purging policy for this table.

ORA-01017/ORA-28000 without AUDIT_TRAIL

The only drawback of the previous solution is that you have to restart the database. And maybe two times because after problem solved you would like to deactivate auditing. This is most probably not reliable solution on a production database so I have been looking for a better solution with no database reboot.

I initially thought of the AFTER LOGON trigger but you need to be logged-in and the BEFORE LOGON does not exits. Then at same documentation place I found the AFTER SERVERERROR trigger and decided to give it a try.

First I created a dummy table to log server error (columns inherited from dba_audit_session dictionary table):

create table sys.logon_trigger ( USERNAME VARCHAR2(30), USERHOST VARCHAR2(128), TIMESTAMP DATE );

Second I created below trigger:

CREATE OR REPLACE TRIGGER sys.logon_trigger AFTER SERVERERROR ON DATABASE BEGIN IF (IS_SERVERERROR(1017)) THEN insert into logon_trigger values(SYS_CONTEXT(‘USERENV’, ‘AUTHENTICATED_IDENTITY’), SYS_CONTEXT(‘USERENV’, ‘HOST’), sysdate); commit; END IF; END; /

Then third simulated a wrong password access with my account and issued:

Источник

Разблокировка и доступ к пользователю HR в Oracle Database 18c Express Edition

В посте рассматривается способ разблокировки и доступа к учебному и тестовому пользователю (схемы) HR в базе данных Oracle Database 18c Express Edition. Рассмотрены следующие вопросы:

  • Краткий обзор Multitenant архитектуры
  • Разблокировка пользователя HR

Краткий обзор Multitenant архитектуры На сегодняшний день последней актуальной версией бесплатной редакции Oracle Database является Oracle Database 18c Express Edition. Данная версия выпущена в 2018 году. Предыдущая версия бесплатной редакции была Oracle Database 11g Express Edition. В Oracle Database 18c Express Edition включены многие важные опции наиболее функциональной редакции Oracle Database – Oracle Database Enterprise Edition. Ниже приведены некоторые основные опции, которые доступны также в Oracle Database 18c Express Edition:

  • Multitenant
  • Flashback Table
  • Flashback Database
  • Oracle Partitioning
  • In-Memory Column Store и Aggregation
  • Advanced Analytics и Security
  • Online Index Rebuild
  • Online Table Redefinition
  • Query Results Cache и PL/SQL Function Result Cache
  • Oracle Advanced Compression
  • Materialized View Query Rewrite
  • Oracle Spatial and Graph
  • Bitmap Indexes

Для подключения к схеме HR в Oracle Database 18c Express Edition необходимо понимать принцип работы новой опции Multitenant. Начиная с Oracle Database 12с поддерживается новая архитектура – Multitenant, которая предоставляет возможность использовать множество баз данных для консолидации их в составе единой и главной базы данных. Такая консолидация упрощает задачи администрирования баз данных. Единая и главная база данных используется в качестве платформы и называется контейнерная база данных (Container Database – CDB), а база данных из множества работающих в составе контейнерной базы данных называется подключаемой базой данных (Pluggable Database – PDB). Архитектура Multitenat позволяет создать в Oracle Database 18с Express Edition одну CDB базу и до трех PDB баз. Архитектура Oracle Database 11g Express Edition предоставляет возможность создать одну и единственную базу. В Oracle Database 18с Express Edition учебная и тестовая схема (пользователь) HR, которая содержит взаимосвязанные таблицы и данные, располагается в составе PDB. В связи с этим, чтобы подключиться к базе данных под этой учетной записью, необходимо войти в PDB, разблокировать пользователя HR и назначить ему пароль. Ниже пошагово описываются шаги подключения к CDB, PDB и манипуляция настроек пользователя с помощью SQLPlus и SQLDeveloper.

Разблокировка пользователя (схемы) HR

Предполагается, что есть успешно установленная Oracle Database 18c Express Edition. При необходимости, можно установить Oracle Database 18c Express Edition используя следующие материалы: установка Oracle Database 18c Express Edition на Linux и установка Oracle Database 18c Express Edition на Windows. Нижеописанные шаги будут работать с Oracle Database 18c Express Edition, установленной, как на операционную систему Linux, так и на Windows.

Вариант разблокировки с помощью SQL*Plus.

Шаг 1. Подключение к CDB

Выполняется подключение к CDB с помощью пользователя sys с ролью as sysdba:

Подключение успешно прошло к CDB. Далее проверяется имя и идентификатор CDB.

Результат запроса показывает, что CDB имеет имя XE и ее уникальный идентификатор = 0. По умолчанию, после установки Oracle Database 18c Express Edition есть одна PDB с именем XEPDB1. Следующий запрос покажет существующие PDB.

Активная PDB имеет имя XEPDB1 с идентификатором 3 и ее режим работы определен как READ WRITE. OPEN MODE – READ WRITE означает, что база данных (БД) открыта и готова работать в режиме чтения и записи. PDB$SEED используется CDB как шаблон для создания новых PDB баз.

Проверяется наличие пользователя HR в CDB.

Запрос не вернул данные. Это означает, что пользователя HR нет в CDB. Далее необходимо подключиться к PDB и найти там HR.

Шаг 2. Подключение к PDB

Есть два способа подключиться к PDB с использованием SQL*Plus.

Способ 1. Находясь в CDB, подключиться к PDB используя команду alter session. В примере ниже происходит переключение из сеанса CDB к PDB с именем XEPDB1:

Переключение прошло успешно. Для того, чтобы удостовериться в корректности подключения, проверяется имя и идентификатор PDB базы:

Запросы показывают характеристики существующей PDB (Шаг 1.).

Способ 2. Можно подключиться к PDB с консоли операционной системы, указав параметры подключения.

Ниже выполняется подключение к PDB под пользователем sys с указанием IP адреса сервера БД, порта и имени PDB (по умолчанию для созданной PDB (XEPDB1) используется порт 1539):

Подключение прошло успешно.

Для информации: Администраторы баз данных временами выполняют подключение к БД используя аутентификацию на уровне операционной системы с помощью команды sqlplus / as sysdba и без указания пароля. При запуске этой команды в среде с Multitenant архитектурой будет осуществлено подключение к CDB. Для того, чтобы напрямую подключиться к PDB минуя CDB, используется sqlplus / as sysdba и без указания пароля, также необходимо в переменную среду операционной системы добавить новый системный параметр ORACLE_PDB_SID и в его значении указать название PDB. Этот параметр для подключения к PDB без указания пароля могут осуществлять только пользователи sys и system. Остальные пользователи будут автоматически подключены к CDB, если не укажут параметры подключения к PDB. Ниже описываются шаги подключения к PDB для пользователя sys с применением параметра ORACLE_PDB_SID в переменной среде операционной системы. Это очень удобный способ для администраторов баз данных:

Подключение к PDB прошло успешно напрямую из операционной системы без указания пароля и параметров подключения PDB. Далее проверяется имя и идентификатор PDB.

После успешного подключения к PDB c использованием одного из двух способов определяется наличие пользователя HR, а также его статус.

Запускается запрос поиска пользователя HR среди всех существующих пользователей в XEPDB1:

Получен результат, подтверждающий наличие пользователя HR в PDB.

При помощи запроса определяется имя, статус и дата блокировки пользователя HR:

Результат запроса показывает, что статус пользователя «заблокирован» и пароль просрочен (необходимо задать новый пароль) – EXPIRED & LOCKED. Первоначальная дата блокировки равна дате установки Oracle Database 18c Express Edition.

Шаг 3. Разблокировка пользователя HR

После установки Oracle Database 18c Express Edition учетная запись HR заблокирована и пароль у нее просрочен (необходимо задать новый пароль) (см. предыдущий шаг – Шаг 2.). В этом случае, система позволяет сделать запросы к объектам HR (таблицам, представлениям, функциям и т.п.) от имени других пользователей при наличии соответствующих привилегий. Например, при выполнении запроса на определение количества строк в таблице EMPLOYEES пользователя HR под пользователем SYS система успешно выдаст следующий результат:

Для пользователя HR назначается новый пароль:

При попытке подключения к PDB, не разблокировав пользователя, можно получить следующую ошибку:

Необходимо заново подключиться к PDB под пользователем sys:

и разблокировать пользователя HR следующей командой:

Операции назначения пароля и разблокировки пользователя HR прошли успешно. Проверяется статус пользователя:

Пользователь HR разблокирован и новый пароль активен. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

Используя данные для подключения к PDB, выполняется вход систему под учетной записью HR и запускается запрос для определения количества строк в его таблице EMPLOYEES.

На этом завершается определение наличия пользователя, назначение ему пароля и разблокировка HR в PDB Oracle Database 18c Express Edition, а также выполнение запроса к его объекту с помощью SQL*Plus.

Вариант разблокировки с помощью SQL Developer.

Шаг 1. Подключение к CDB

Для этого создается новое подключение в SQL Developer и указываются необходимые параметры подключения к CDB, такие как:

Name: XE_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать CDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XE
SID или имя CDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Role: SYSDBA
Подключение к БД осуществляется пользователем sys. Данный пользователь может подключиться только с ролью SYSDBA.

Password:
Пароль пользователя sys, который был назначен во время установки базы данных.

После нажатия Connect произойдет успешное подключение к CDB с именем XE. Далее проверяется имя, идентификатор и версия CDB, а также выводятся существующие PDB.

Как и ожидалось, выведенные выше данные идентичны полученным с помощью SQL*Plus.

Далее проверяется наличие пользователя HR в CDB.

Запрос не вернул данные, это означает, что пользователя HR нет в CDB. Теперь необходимо подключиться к PDB и проверить наличие HR в PDB.

Шаг 2. Подключение к PDB

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1, такие как:

Name: XEPDB1_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Role: SYSDBA
Подключение к БД осуществляется пользователем sys. Данный пользователь может подключиться только с ролью SYSDBA.

Password:
Пароль пользователя sys, который был назначен во время установки базы данных. Пользователи sys и system могут подключиться с одним и тем же паролем и к CDB и к PDB.

После нажатия Connect произойдет успешное подключение к подключаемой БД XEPDB1. Далее проверяется имя и идентификатор.

Результаты показывают, что было подключение к PDB с именем XEPDB1 и идентификатором 3. Определяется наличие пользователя HR в этой PDB. В иерархии дерева надо выбрать «Other Users» в соединении с именем XEPDB1_18c как показано на скриншоте:

В списке пользователей необходимо найти пользователя HR и нажать на правую кнопку. Из контекстного меню выбрать «Edit User». Откроется новое модальное окно «Edit User» как показано на скриншоте. Как видно на скриншоте учетная запись HR заблокирована (Account is Locked) и пароль у нее просрочен (Password Expired):

Шаг 3. Разблокировка пользователя HR:

В продолжение предыдущего шага необходимо:

  1. Задать идентичный пароль в полях New Password (новый пароль) и Confirm Password (подтвердить пароль).
  2. Снять галочку из пункта Password Expired (user must change next login).
  3. Снять галочку из пункта Account is Locked для разблокировки пользователя.
  4. Нажать Apply.

Пользователь HR разблокирован и ему назначен пароль. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1 с пользователем HR, такие как:

Name: XEPDB1_18c_hr
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении с пользователем HR.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: HR
Указывается имя пользователя для подключения к БД.

Role: default
Подключение к БД осуществляется пользователем HR. Данный пользователь не может использовать роль SYSDBA.

Password:
Пароль, который был назначен пользователю HR на третьем шаге, то есть hr.

После нажатия Connect произойдет успешное подключение к PDB с именем XEPDB1 под пользователем HR. Выполняется запрос для определения количества строк в таблице EMPLOYEES:

На этом завершается определение наличия пользователя, назначение ему пароля и разблокировка HR в PDB Oracle Database 18c Express Edition, а также выполнение запроса к его объекту с помощью SQL Developer.

Источник

Источник

Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.

Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. SAP GUI выдавал сообщение о том, что база данных системы недоступна. 

Первая мысль была: «Ну, наверное, по какой-то причине затянулся бэкап». Но переход на уровень операционной системы сервера показал, что база данных запущена, а процессов резервного копирования в операционной системе нет. Правда, со стороны Oracle работают только фоновые служебные процессы и нет ни одного shadow-процесса. 

Вы наверное знаете, что при оффлайн резервной копии базы данных (или как её ещё называют «холодный» бэкап) процессы ABAP инстанции не останавливаются, а остаются работать, потеряв коннект к базе данных. При этом рабочие процессы с настойчивостью и периодичностью пытаются открыть соединение к базе данных. Поэтому, как только база данных становится доступной для соединения, рабочие процессы открывают соединения, а Oracle запускает для каждого рабочего процесса SAP инстанции отдельный shadow-процесс. Подробнее о том, как рабочие процессы SAP системы подключаются к базе данных я описывал в статьях: «Как рабочие процессы SAP соединяются с базой данных Oracle — I» и «Как рабочие процессы SAP соединяются с базой данных Oracle — II». 

Так вот, shadow-процессов Oracle не наблюдалось. Я подключился к базе данных через SQLPlus, используя пользователя SYSTEM. Соединение установилось успешно. На всякий случай перестартовал базу данных. Проверил: shadow-процессов как не было, так и нет. При этом рабочие процессы SAP инстанции в списке процессов операционной системы висели.

Хорошо. Последний рестарт SAP системы был давно, вдруг что-то подглючило на уровне сервера приложений, подумал я. И решил перезапустить сервер приложений. Но скрипты запуска системы выдают: «База данных не запущена, будем запускать. Попытка запуска базы данных заканчивается ошибкой — «база данных недоступна». Стоит отметить, что скрипты запуска SAP системы для проверки доступности базы данных используют утилиту R3trans, входящую в состав SAP Kernel, запуская её с опцией «-d» (рис. 1 и 2).

Рис. 1. Пример успешной проверки соединения с базой данных.

Рис. 2. Пример безуспешной проверки соединения с базой данных.

Проверка переменных окружения пользователей, настроек Oracle client, процесса Listener ничего не дала. 

И только в третий раз просматривая журналы рабочих процессов SAP инстанции (файлы dev_w*), обратил внимание, что код ошибки при попытках коннекта к Oracle отличается от типичного. Когда база данных остановлена, выдаётся код ошибки 1034. 

Рис. 3. Пример кода ошибки соединения с остановленной базой данных.

А тут выдавался код 28000 (рис. 4). 

Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

По коду ошибки удалось выяснить, что ошибка заключается не в недоступности Oracle, а в блокировке пользователя. Как вы уже знаете, из вышеупомянутых статей, что рабочие процессы SAP системы при подключении к Oracle используют пользователя владельца схемы в базе данных. В данном случае это пользователь SAPSR3. Так вот этот пользователь и оказался заблокированным. 

К блокировке пользователя привёл параметр базы данных Oracle — FAILED_LOGIN_ATTEMPTS. Начиная, с версий Oracle 10g значение данного параметра, по умолчанию, равно 10. В предыдущих версиях СУБД по умолчанию стоит значение UNLIMITED. Посмотреть значение в текущей базе данных можно запросом вида:

SQL> select LIMIT from DBA_PROFILES where PROFILE=’DEFAULT’ AND RESOURCE_NAME=’FAILED_LOGIN_ATTEMPTS’;

или

SQL> show parameter FAILED_LOGIN_ATTEMPTS;

Как вы помните из моего поста, при соединении с базой данных, до версии Oracle 11g в SAP системе использовался механизм хранения пароля пользователя владельца схемы в отдельной табличке OPS$<USER>.SAPUSER. Так как в момент оффлайн бэкапа база данных недоступна, то рабочий процесс не может получить к ней доступ и прочитать продуктивный пароль пользователя. И как видно из скриншота (рис. 3), каждый раз делается ещё и дополнительная попытка открыть соединение с дефолтным паролем, который зашит в коде ядра. Допускаю, что случилась такая ситуация, что в момент старта базы данных было сделано больше 10 попыток логина к базе данных со стороны SAP системы с этим стандартным паролем (который отличается от продуктивного пароля). В результате этого Oracle автоматически заблокировал пользователя (владельца схемы) и последующие попытки SAP системы присоединиться к базе данных проваливались уже по этой причине, вплоть до моего вмешательства. 

Разрешение ситуации: разблокировка пользователя. Разблокировать пользователя можно в SQLPlus командой вида:

SQL> alter user SAPSR3 account unlock;

После этого рабочие процессы корректно подключаются к базе данных. Для предотвращения возникновения ситуации в будущем —  установка параметра в большее значение, вплоть до UNLIMITED. Сделать это можно SQL-командой вида:

SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 50;

P.S. Думаю, что описанная ситуация довольно таки редкая и возможна только в узком круге версий систем SAP и базы данных Oracle. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.

Источник

Preamble

I have decided to write this blog post after second time I received question on how to know from where are coming connections that are locking an account in an Oracle database…

Do not smile, I have seen at least two situations where, after a password change, a batch job was initiating plenty of connection (with previous wrong password) and no one was able to know from where this batch job was running (!!).

As a reminder, with default profile in Oracle 11g, accounts are automatically locked 1 day (PASSWORD_LOCK_TIME) after 10 failed login attempt (FAILED_LOGIN_ATTEMPTS):

SQL> SET lines 200
SQL> SET pages 200
SQL> SELECT * FROM dba_profiles WHERE PROFILE='DEFAULT' ORDER BY resource_name;
 
PROFILE                        RESOURCE_NAME                    RESOURCE LIMIT
------------------------------ -------------------------------- -------- ----------------------------------------
DEFAULT                        COMPOSITE_LIMIT                  KERNEL   UNLIMITED
DEFAULT                        CONNECT_TIME                     KERNEL   UNLIMITED
DEFAULT                        CPU_PER_CALL                     KERNEL   UNLIMITED
DEFAULT                        CPU_PER_SESSION                  KERNEL   UNLIMITED
DEFAULT                        FAILED_LOGIN_ATTEMPTS            PASSWORD 10
DEFAULT                        IDLE_TIME                        KERNEL   UNLIMITED
DEFAULT                        LOGICAL_READS_PER_CALL           KERNEL   UNLIMITED
DEFAULT                        LOGICAL_READS_PER_SESSION        KERNEL   UNLIMITED
DEFAULT                        PASSWORD_GRACE_TIME              PASSWORD 7
DEFAULT                        PASSWORD_LIFE_TIME               PASSWORD 180
DEFAULT                        PASSWORD_LOCK_TIME               PASSWORD 1
DEFAULT                        PASSWORD_REUSE_MAX               PASSWORD UNLIMITED
DEFAULT                        PASSWORD_REUSE_TIME              PASSWORD UNLIMITED
DEFAULT                        PASSWORD_VERIFY_FUNCTION         PASSWORD NULL
DEFAULT                        PRIVATE_SGA                      KERNEL   UNLIMITED
DEFAULT                        SESSIONS_PER_USER                KERNEL   UNLIMITED
 
16 ROWS selected.

Oracle client session will received 10 times ORA-01017: invalid username/password; logon denied error message and then ORA-28000: the account is locked error message (for one day and then back to ORA-01017 error message).

The final question is how to identify from where (client IP address/name) are coming those tentative connections… I have done my testing using Oracle 11.2.0.3 running on Oracle Linux Server release 6.3.

ORA-01017/ORA-28000 with AUDIT_TRAIL

The first and preferred solution is with Oracle standard auditing feature. Start by setting initialization parameter AUDIT_TRAIL to db and restart your Oracle database as it is static parameter.

Then activate network auditing with (as SYS):

SQL> AUDIT network BY ACCESS;
 
AUDIT succeeded.

With below query you get everything needed:

SELECT *
FROM dba_audit_session
ORDER BY sessionid DESC;

Returncode column contains Oracle error code and so different of 0 if logon/logoff issue. The invalid password is the error we are chasing:

[oracle@server1 ~]$ oerr ora 1017
01017, 00000, "invalid username/password; logon denied"
// *Cause:
// *Action:

So if you find 1017 values in this column then we have found what we were looking for. For example with my test case where I intentionally specify a wrong password for my account:

SQL> SELECT username,userhost,returncode
     FROM dba_audit_session
     WHERE username='YJAQUIER'
     ORDER BY sessionid DESC;
 
USERNAME                       USERHOST             RETURNCODE
------------------------------ -------------------- ----------
YJAQUIER                       server1                    1017
YJAQUIER                       GVADT30596                    0
YJAQUIER                       server1                       0
YJAQUIER                       server1                       0
.
.
.

And if you insist, as explained, you get:

SQL> SELECT username, account_status,lock_date, PROFILE FROM dba_users WHERE username='YJAQUIER';
 
USERNAME                       ACCOUNT_STATUS                   LOCK_DATE            PROFILE
------------------------------ -------------------------------- -------------------- ------------------------------
YJAQUIER                       LOCKED(TIMED)                    23-nov-2012 10:30:37 DEFAULT

If you set AUDIT_TRAIL to db behave the size of SYS.AUD$ table as a small list of audits are already implemented by default:

SQL> SET lines 200
SQL> SET pages 200
SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;
 
USER_NAME                      PROXY_NAME                     AUDIT_OPTION                             SUCCESS    FAILURE
------------------------------ ------------------------------ ---------------------------------------- ---------- ----------
                                                              ALTER SYSTEM                             BY ACCESS  BY ACCESS
                                                              SYSTEM AUDIT                             BY ACCESS  BY ACCESS
                                                              CREATE SESSION                           BY ACCESS  BY ACCESS
                                                              CREATE USER                              BY ACCESS  BY ACCESS
                                                              ALTER USER                               BY ACCESS  BY ACCESS
                                                              DROP USER                                BY ACCESS  BY ACCESS
                                                              PUBLIC SYNONYM                           BY ACCESS  BY ACCESS
                                                              DATABASE LINK                            BY ACCESS  BY ACCESS
                                                              ROLE                                     BY ACCESS  BY ACCESS
                                                              PROFILE                                  BY ACCESS  BY ACCESS
                                                              CREATE ANY TABLE                         BY ACCESS  BY ACCESS
                                                              ALTER ANY TABLE                          BY ACCESS  BY ACCESS
                                                              DROP ANY TABLE                           BY ACCESS  BY ACCESS
                                                              CREATE PUBLIC DATABASE LINK              BY ACCESS  BY ACCESS
                                                              GRANT ANY ROLE                           BY ACCESS  BY ACCESS
                                                              SYSTEM GRANT                             BY ACCESS  BY ACCESS
                                                              ALTER DATABASE                           BY ACCESS  BY ACCESS
                                                              CREATE ANY PROCEDURE                     BY ACCESS  BY ACCESS
                                                              ALTER ANY PROCEDURE                      BY ACCESS  BY ACCESS
                                                              DROP ANY PROCEDURE                       BY ACCESS  BY ACCESS
                                                              ALTER PROFILE                            BY ACCESS  BY ACCESS
                                                              DROP PROFILE                             BY ACCESS  BY ACCESS
                                                              GRANT ANY PRIVILEGE                      BY ACCESS  BY ACCESS
                                                              CREATE ANY LIBRARY                       BY ACCESS  BY ACCESS
                                                              EXEMPT ACCESS POLICY                     BY ACCESS  BY ACCESS
                                                              GRANT ANY OBJECT PRIVILEGE               BY ACCESS  BY ACCESS
                                                              CREATE ANY JOB                           BY ACCESS  BY ACCESS
                                                              CREATE EXTERNAL JOB                      BY ACCESS  BY ACCESS

So you must put in place a purging policy for this table.

ORA-01017/ORA-28000 without AUDIT_TRAIL

The only drawback of the previous solution is that you have to restart the database. And maybe two times because after problem solved you would like to deactivate auditing. This is most probably not reliable solution on a production database so I have been looking for a better solution with no database reboot.

I initially thought of the AFTER LOGON trigger but you need to be logged-in and the BEFORE LOGON does not exits. Then at same documentation place I found the AFTER SERVERERROR trigger and decided to give it a try.

First I created a dummy table to log server error (columns inherited from dba_audit_session dictionary table):

CREATE TABLE sys.logon_trigger
(
USERNAME VARCHAR2(30),
USERHOST VARCHAR2(128),
TIMESTAMP DATE
);

Second I created below trigger:

CREATE OR REPLACE TRIGGER sys.logon_trigger
AFTER SERVERERROR ON DATABASE
BEGIN
  IF (IS_SERVERERROR(1017)) THEN
    INSERT INTO logon_trigger VALUES(SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY'), SYS_CONTEXT('USERENV', 'HOST'), SYSDATE);
    COMMIT;
  END IF;
END;
/

Then third simulated a wrong password access with my account and issued:

SQL> ALTER SESSION SET nls_date_format='dd-mon-yyyy hh24:mi:ss';
 
SESSION altered.
 
SQL> SET lines 200
SQL> col USERHOST FOR a30
SQL> SELECT * FROM sys.logon_trigger ORDER BY TIMESTAMP DESC;
 
USERNAME                       USERHOST                       TIMESTAMP
------------------------------ ------------------------------ --------------------
yjaquier                       STGVADT30596                  23-nov-2012 11:05:56

And that’s it !!

About Post Author

Источник

oracle tutorial webinars

ORA-28000

In Oracle, as in just about any other type of computer-based interface, is set up to extend a security option for its users. Unfortunately, as we all know, sometimes the good old-fashioned username/password combination can prove to be the most difficult component of working with a particular computer application. For some websites, a message in a bright red font is triggered at a false combination; for Oracle, an error such as the ORA-28000 is the result. However, the ORA-28000 only applies to specific login circumstances. So what are they?

The Problem

The ORA-28000 is triggered by attempting an invalid password too many times, resulting in getting locked out of the system. Sounds simple, right? The catch is that you may not be the user triggering the error; in fact, it may be nobody at all. This is because of the DBSNMP, an artificial user that Oracle’s Enterprise Manager (OEM) would employ for certain activity, such as instance target discovery. The problem arises when the reset password for the DBSNMP account and the actual password are not synchronized. The DBSNMP account will try repeatedly to log in, until it is locked out at the max of ten attempts.

Maybe you had no idea about the DBSNMP password. It’s possible that the default setting during installation is set to locked. Another source of the error can be the 9i Intelligent Agent trying to connect as the DBSNMP with an invalid password and failing. Regardless of the journey to the problem, it’s safe to bet that your ORA-28000 error may very well be the result of faulty DBSNMP settings.

The Solution

The DBSNMP, if set to default settings, may attempt repeatedly to log in to the account on a particular schedule and possibly fail over and over. There are ways to circumvent this. First, you can check your password settings in the DEFAULT profile by issuing a query:

SELECT resource_name, limit

FROM dba_profiles

WHERE profile = ‘DEFAULT’

AND resource_type = ‘password’;

You can also change the password schedule to unlimited. You can also run a check on the database target for the OEM credentials by going to targets > database > database target name > monitoring configuration > test connection. If you find this navigation to fail, you can unlock the DBSNMP account and set its password to the same as the one you used to run the initial navigation. Furthermore, by ensuring that every task associated with the DBSNMP is attempting to operate using the same password, you can eliminate the error from your system.

Looking forward

Preventing this type of error is relatively simple for database managers. By configuring the account with a secured password and unlocking it immediately following installation, you can avoid the ORA-28000 in many instances. It just involves a bit of proactive thinking now that you know what to keep in mind. In the event that you are not the administrator for your system, contacting your administer about recurring ORA-28000 issues with the information you now have at your disposal can save you both a great deal of time. If you find that you are still having trouble with DBSNMP-generated errors or having continued difficulties logging into Oracle, consider contacting a licensed Oracle consultant to assist you with minimizing the amount of times you wind up locked out of your Oracle system.

Источник

We often come across the error ORA-28000 the account is locked in day to day activities. This can happened with developers and DBA both.

ORA-28000 the account is locked

Reasons

This can happen due to multiple reasons

a. Oracle DBA has purposely locked the account

alter user <username> account lock;
select status from dba_users where username='&1';

b. Wrong password has been attempted many times resulting in locking. The number of FAILED_LOGIN_ATTEMPTS  can be found using the below query

select username , profile from dba_users where username='&1';
-----  ------
SCOTT TECH_PW

select * from dba_profiles
where profile='&1' and resource_name='FAILED_LOGIN_ATTEMPTS';

SQL> select RESOURCE_NAME,resource_type,LIMIT from dba_profiles where PROFILE='TECH_PW' ;
RESOURCE_NAME RESOURCE LIMIT
-----------    -------  -----
COMPOSITE_LIMIT KERNEL DEFAULT
SESSIONS_PER_USER KERNEL DEFAULT
CPU_PER_SESSION KERNEL DEFAULT
CPU_PER_CALL KERNEL DEFAULT
LOGICAL_READS_PER_SESSION KERNEL DEFAULT
LOGICAL_READS_PER_CALL KERNEL DEFAULT
IDLE_TIME KERNEL DEFAULT
CONNECT_TIME KERNEL DEFAULT
PRIVATE_SGA KERNEL DEFAULT
FAILED_LOGIN_ATTEMPTS PASSWORD 5
PASSWORD_LIFE_TIME PASSWORD 90
PASSWORD_REUSE_TIME PASSWORD UNLIMITED
PASSWORD_REUSE_MAX PASSWORD 10
PASSWORD_VERIFY_FUNCTION PASSWORD DEFAULT
PASSWORD_LOCK_TIME PASSWORD DEFAULT
PASSWORD_GRACE_TIME PASSWORD DEFAULT

Default values can be found by querying the default profile
SQL> select RESOURCE_NAME,resource_type,LIMIT from dba_profiles where PROFILE='DEFAULT';
RESOURCE_NAME RESOURCE LIMIT
-------------  -------   ------
COMPOSITE_LIMIT KERNEL UNLIMITED
SESSIONS_PER_USER KERNEL UNLIMITED
CPU_PER_SESSION KERNEL UNLIMITED
CPU_PER_CALL KERNEL UNLIMITED
LOGICAL_READS_PER_SESSION KERNEL UNLIMITED
LOGICAL_READS_PER_CALL KERNEL UNLIMITED
IDLE_TIME KERNEL UNLIMITED
CONNECT_TIME KERNEL UNLIMITED
PRIVATE_SGA KERNEL UNLIMITED
FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITED
PASSWORD_LIFE_TIME PASSWORD UNLIMITED
PASSWORD_REUSE_TIME PASSWORD UNLIMITED
PASSWORD_REUSE_MAX PASSWORD UNLIMITED
PASSWORD_VERIFY_FUNCTION PASSWORD NULL
PASSWORD_LOCK_TIME PASSWORD UNLIMITED
PASSWORD_GRACE_TIME PASSWORD UNLIMITED

We can also found where all failed login attempt happened by enabling auditing

audit session whenever not successful;

select OS_USERNAME,USERNAME,USERHOST,to_char(timestamp,'MM-DD-YYYY HH24:MI:SS'), returncode
from dba_audit_trail
where returncode > 0

Solution

In case this is not happened purposely , we can solve the problem using the below approach accordingly

(1) Unlock the account using below command

alter user <username> account unlock;

Before executing above query  make sure reason for the error is sorted out.Otherwise again the error will happen.

(2) If the reason for error is unknown and Till the issue is resolved, we can create another profile with unlimited FAILED_LOGIN_ATTEMPTS

SQL> CREATE PROFILE TECH_TMP LIMIT
FAILED_LOGIN_ATTEMPTS UNLIMITED
;

And Assign it to the user which is experiencing the issue

alter user scott profile TECH_TMP;
alter user scott account unlock;

Once the cause is established and we know the source from where invalid password is coming, we can change user profile to previous one and dropped the newly created profile

alter user scott profile TECH_PW;
drop profile TECH_TMP;

Hope you like this post on ORA-28000 the account is locked and it will help in your day to day activities. Please do provide feedback on it

Related Articles

ORA-01017: invalid username/password; logon denied
How to login as user without changing the password in Oracle database
Create User in Oracle
How to create Users and Roles in Oracle database 12c
ORA-00904
ORA-28002
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4003.htm

Reader Interactions

Источник

The users password were expired and in their grace period.Here is what it looked like:

SQL> select username,account_status,expiry_date
from dba_users;

USERNAME              
      
ACCOUNT_STATUS         
     EXPIRY_DATE

——————————
————————   ————

SELFLOAD              
       OPEN

PROD                  
       OPEN

TECHNO                
      
EXPIRED(GRACE)                
11-JAN-14

SCOTT                 
       EXPIRED & LOCKED
             
08-JUL-14

ORACLE_OCM            
       EXPIRED & LOCKED
             
15-AUG-09

XS$NULL
              
       EXPIRED & LOCKED
             
15-AUG-13

MDDATA                
       EXPIRED & LOCKED
             
15-AUG-13

DIP                   
       EXPIRED & LOCKED
             
15-AUG-09

APEX_PUBLIC_USER      
       EXPIRED & LOCKED
             
15-AUG-09

SPATIAL_CSW_ADMIN_USR         LOCKED                         15-AUG-09

So here is what I did:-

connect to sql like- sqlplus «/ as sysdba»

SQL> select password from sys.user$
where name=’TECHNO’;

PASSWORD

——————————

7A0F2B316C212D67

This gave me the hashed password for
the user TECHNO

Then again set the same password for user TECHNO:

SYS> alter user TECHNO identified by
values ‘7A0F2B316C212D67’;

Now the account is open again and not expired or in grace period:

USERNAME              
      
ACCOUNT_STATUS         
     EXPIRY_DATE

———————-    
——————-          
—————

SELFLOAD                      OPEN

PROD                          OPEN

TECHNO                        OPEN                           11-JAN-14

SCOTT                         EXPIRED & LOCKED               08-JUL-14

ORACLE_OCM                    EXPIRED & LOCKED               15-AUG-09

XS$NULL                       EXPIRED & LOCKED               15-AUG-13

MDDATA                        EXPIRED & LOCKED               15-AUG-13

DIP                           EXPIRED & LOCKED               15-AUG-09

APEX_PUBLIC_USER              EXPIRED & LOCKED               15-AUG-09

SPATIAL_CSW_ADMIN_USR         LOCKED                         15-AUG-09

The above option may not work completely on the case «EXPIRED & LOCKED» it may remain LOCKED although it will no longer appear EXPIRED like:-

USERNAME                      ACCOUNT_STATUS               EXPIRY_DATE

———————-     ——————-           —————

SCOTT                           LOCKED                       08-JUL-14

So in that case unlock the user as illustrated below:-

connect to sql as- sqlplus «/ as sysdba»

Once logged in as SYSDBA, you need to unlock the SCOTT account 


SQL> alter user scott account unlock;


SQL> grant connect, resource to scott;

The other way to to open the expired password is to try to connect the
user using the command prompt, it will ask to you to change the password as
follows,  It will ask you for the password provide the password,account
will be open.

SQL> conn techno/password

ERROR:

ORA-28001: the password has expired

Changing password for techno

New password:

Retype new password:

Password changed

Connected.

 

XS$NULL

Although by above methods one can unlock the users but the following user XS$NULL  remains «EXPIRED & LOCKED»

Explanation for the same:-

Oracle
introduced a new user in version 11g called XS$NULL.
It is for Oracle’s internal use only and you should leave it alone. For this
reason it is locked and expired when it is created:

SQL> select
account_status from dba_users

  2  where
username = ‘XS$NULL’;

ACCOUNT_STATUS

———————————

EXPIRED & LOCKED

SQL>

You are
advised not to alter this account in any way, even if an auditor asks you to.
Oracle does not let you change its password:

SQL> conn / as
sysdba

Connected.

SQL> alter user
xs$null identified by new_pwd

  2  /

alter user xs$null
identified by new_pwd

                                
*

ERROR at line 1:

ORA-01031:
insufficient privileges

SQL>

Although you
can do so with the password command:

SQL> select
password from sys.user$

  2  where
name = ‘XS$NULL’;

PASSWORD

——————————

DC4FCC8CB69A6733

SQL> password
xs$null

Changing password for
xs$null

New password:

Retype new password:

Password changed

SQL> select
password from sys.user$where
name = ‘XS$NULL’;

PASSWORD

——————————

C17AE3B0A14EA63F

SQL>

This is
because of bug 12822989 and you must not do this.

ERROR: ORA-28002: the password will expire within 6 days. 

Lets see what we can do about resolving this issue.

You could simply just change the users password. In an ideal and secure world, this is exactly what you would do. Though this may not be practical, there may be a whole host of reasons for postponing the change.

In Oracle 11g, users are assigned to a profile, the default profile is named “DEFAULT”. This default profile comes configured with a maximum password lifetime of a 180 days.

[box type=»info»] Just note that this document’s steps have been performed on Oracle 11g Release 11.2.0.3.0 running on Red Hat Enterprise Linux 6.3. The SQL syntax provided “should” work on all Oracle 11g platforms.[/box]

Step 1: Identify the Users Profile

Log into Oracle 11g using SQL*Plus tool as sysdba

Step 1: Identify the Users Profile

Log into Oracle 11g using SQL*Plus tool as sysdba

[oracle@oracle1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Tue Nov 20 12:18:08 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Release 11.2.0.3.0 — 64bit Production

SQL>

Lets confirm that the user is running the default profile. Note you must capitalize the username.

SQL> SELECT profile FROM dba_users WHERE username = ‘USER1’;

PROFILE

——————————

DEFAULT

we can change the password ,

As you can see, the user has the profile of “DEFAULT” configured.

Step 2: View the Profile settings

Lets examine the settings of the profile

SQL> select
resource_name,resource_type, limit from dba_profiles where profile=’DEFAULT’;
 
RESOURCE_NAME                                                          
RESOURCE LIMIT
——————————— ———                 —————————————-
COMPOSITE_LIMIT                                                        KERNEL   UNLIMITED
SESSIONS_PER_USER                                                     KERNEL   UNLIMITED
CPU_PER_SESSION                                                          KERNEL   UNLIMITED
CPU_PER_CALL                                                             
KERNEL   UNLIMITED
LOGICAL_READS_PER_SESSION                                        KERNEL   UNLIMITED
LOGICAL_READS_PER_CALL                                             KERNEL   UNLIMITED
IDLE_TIME                                                                    KERNEL   UNLIMITED
CONNECT_TIME                                                              KERNEL   UNLIMITED
PRIVATE_SGA                                                                  KERNEL   UNLIMITED
FAILED_LOGIN_ATTEMPTS                                          
PASSWORD 10
PASSWORD_LIFE_TIME                                               
PASSWORD 180
PASSWORD_REUSE_TIME                                          PASSWORD
UNLIMITED
PASSWORD_REUSE_MAX                                         PASSWORD
UNLIMITED
PASSWORD_VERIFY_FUNCTION                              PASSWORD NULL
PASSWORD_LOCK_TIME                                              
PASSWORD 1
PASSWORD_GRACE_TIME                                          
PASSWORD 7
 
16 rows selected 

As you can see the PASSWORD_LIFE_TIME is to 180 days, you may configure this however you want.

Step 3: Set PASSWORD_LIFE_TIME

In this example, we’re going to make the password life unlimited so that it never expires. This may not be the wisest thing to do in a production environment. However there may be circumstances that require a password change at a later date.

To make this change we simply need to run the following command:

SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

Profile altered.

Step 4: Re-Enter the Password

You may notice that even after setting the password expiry to unlimited you are still getting the “ERROR: ORA-28002: the password will expire” message. I’m guessing this is due to additional processes that Oracle does in the background for checking password age etc. So this forces us to “reset” the password to it’s current value to remove the error.

This is done via the following SQL

SQL> alter user USER1 identified by «password»;

User altered.

Just note that the password must be double quoted and not single quoted.

…and that’s it, you should no longer receive the “ORA-28002: the password will expire” message for USER1 when logging in.

[box type=»warning»] Just note that having never expiring passwords probably isn’t the best password policy to maintain. Oracle’s password expiration setting is a great way to remind users and admin’s to change their passwords regularly.[/box]

In the End:-

It should serve as a warning that when the account has a status of
EXPIRED & LOCKED after initial database creation it is much different than
if that account is altered to that status after an account has been assigned a
password and unlocked. Some tools, such as SQL*Plus will allow the user the
chance to change the password if the old password is properly supplied. 

For
example:

1.  We can easily expire the password for the ANONYMOUS
account

SQL> ALTER USER anonymous PASSWORD EXPIRE;
User altered.

And the status would clearly be:

USERNAME              ACCOUNT_STATUS    LOCK_DATE EXPIRY_DA
--------------------- ----------------- --------- ---------
ANONYMOUS             EXPIRED                     11-SEP-09

2.  The ANONYMOUS account would be prompted for a password
and allowed to connect after entering a new password:

SQL> connect anonymous/abc
ERROR:
ORA-28001: the password has expired
 
Changing password for anonymous
New password: xyz
Retype new password: xyz
Password changed
Connected.

By contrast, if you really
wanted to lock out a user from connecting in the future, regardless of password
expiration, you should LOCK the account. For example:

3.  We can easily lock the ANONYMOUS account

SQL> ALTER USER anonymous ACCOUNT LOCK;
User altered.

And the status would clearly be:

USERNAME              ACCOUNT_STATUS    LOCK_DATE EXPIRY_DA
--------------------- ----------------- --------- ---------
ANONYMOUS             LOCKED            11-SEP-09 10-MAR-10

4.  The ANONYMOUS account is totally locked out and unable to
connect:

SQL> connect anonymous/abc
ERROR:


ORA-28000: the account is locked

Expiring and locking user
accounts are one of the first steps to securing who can connect to an Oracle
database. The expiration of account passwords is not an effective lock-out
mechanism but should instead be used to encourage users to just change their
passwords over time. Locking an account though has the effect of truly locking
out an account so no one can use it to connect to the database. If you need to
disable an account this is the preferred method other than dropping it. Just be
warned that expiring an account leaves the prior password intact. Under this
condition if you were to lock the account and someone came up behind your work
and unlocked the account, the user could still log in by changing the password.
It is therefore suggested to alter the password before expiring and locking.
That way even if the lock were removed the user would have no way of ever
connecting again.

Thank You.

Источник

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Oracle error 12899
  • Ora 00600 internal error code arguments ошибка
  • Ora 12571 ошибка
  • Oracle error 12537
  • Oracle error 1017

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии