Аутентификацией базой данных называют аутентификацию учетной записи и пароля непосредственно программным обеспечением Oracle. Однако, хотя аутентификация базой данных проста в настройке, она не является единственным или лучшим средством аутентификации пользователей Oracle. Существует несколько способов аутентификации пользователей базы данных — способов, не зависящих от БД.
В этой моей статье блога будет освещен наиболее часто применяемый способ аутентификации пользователей Oracle посредством базы данных. Затем мы кратко рассмотрим другие средства аутентификации пользователей — внешнюю, прокси- и централизованную аутентификацию пользователей.
Аутентификация базой данных
Аутентификация базой данных — это стандартная проверка полномочий доступа пользователя за счет применения паролей базы данных. При использовании аутентификации пользователей базой данных необходимо располагать строгой политикой управления паролями.
Вот пример аутентификации базой данных:
SQL> CREATE USER scott IDENTIFIED BY tiger;
Управление паролями
В зависимости от способа создания базы данных (вручную или с помощью DBCA) Oracle будет содержать несколько учетных записей с заданными по умолчанию паролями. Если табличное пространство создается вручную, БД может содержать только учетные записи SYS, SYSTEM, DBSNMP (учетная запись агента Intelligent Agent (Интеллектуальный агент) Oracle) и OUTLN (имя пользователя для управления средством управления хранимыми планами выполнения). В некоторых случаях пользователь scott (владелец старой схемы демонстрационной БД Oracle) также создается с заданным по умолчанию паролем tiger. Стандартная база данных, созданная DBCA, может содержать до 32 определенных по умолчанию учетных записей пользователей.
В рамках защиты базы данных необходимо использовать все стандартные методики управления паролями, включая изменение паролей с заданными интервалами, проверку паролей на сложность и предотвращение повторного использования старых паролей.
Рассмотрим, как Oracle создает заданные по умолчанию учетные записи пользователей в новой базе данных. Запрос, показанный в листинге ниже, выводит все имена пользователей и их состояние. Учетная запись может быть открытой или же заблокированной либо утратившей силу.
Открытая (open) учетная запись — учетная запись, с которой можно регистрироваться в базе данных, при условии наличия действующего пароля. Заблокированная (locked) учетная запись должна быть явно разблокирована администратором БД. Обычно заблокированная учетная запись является результатом попыток входа пользователя в базу данных с неправильным паролем большее количество раз, чем разрешено указанным пределом. Утратившая силу (expired) учетная запись — это учетная запись, пароль которой должен быть изменен, что обеспечивает невозможность использования тех же самых паролей.
SQL> SELECT username, account_status 2 FROM dba_users; USERNAME ACCOUNT_STATUS ---------- ---------------- MGMT_VIEW OPEN SYS OPEN SYSTEM OPEN DBSNMP OPEN SYSMAN OPEN SCOTT OPEN OUTLN EXPIRED & LOCKED HR EXPIRED & LOCKED . . . 32 rows selected SQL>
Администратор БД должен изменить пароли всех созданных по умолчанию учетных записей пользователей немедленно после создания базы данных. Все ненужные учетные записи, созданные по умолчанию, должны быть заблокированы и признаны утратившими силу.
Пароли по умолчанию пользователей Oracle
Имя пользователя | Пароль | Зашифрованный пароль |
ADAMS | WOOD | 72CDEF4A3483F60D |
ADLDEMO | ADLDEMO | 147215F51929A6E8 |
APPLSYS | FND | 0F886772980B8C79 |
APPLYSYSPUB | PUB | A5E09E84EC486FC9 |
APPS | APPS | D728438E8A5925E0 |
AQDEMO | AQDEMO | 5140E342712061DD |
AQJAVA | AQJAVA | 8765D2543274B42E |
AQUSER | AQUSER | 4CF13BDAC1D7511C |
AUDIOUSER | AUDIOUSER | CB4F2CEC5A352488 |
AURORA$JIS$ UTILITY$ |
Random Password (Случайный пароль) |
. |
AURORA$ORB$ UNAUTHENTICATED |
INVALID | 80C099F0EADF877E |
BLAKE | PAPER | 9435F2E60569158E |
CATALOG | CATALOG | 397129246919E8DA |
CDEMO82 | CDEMO83 | 7299A5E2A5A05820 |
CDEMOCOR | CDEMOCOR | 3A34F0B26B951F3F |
CDEMOUCB | CDEMOUCB | CEAE780F25D556F8 |
CDEMORID | CDEMORID | E39CEFE64B73B308 |
CENTRA | CENTRA | 63BF5FFE5E3EA16D |
CLARK | CLOTH | 7AAFE7D01511D73F |
COMPANY | COMPANY | 402B659C15EAF6CB |
CSMIG | CSMIG | 09B4BB013FBD0D65 |
CTXDEMO | CTXDEMO | CB6B5E9D9672FE89 |
CTXSYS | CTXSYS | 24ABAB8B06281B4C |
DBSNMP | DBSNMP | E066D214D5421CCC |
DEMO | DEMO | 4646116A123897CF |
DEMO8 | DEMO9 | 0E7260738FDFD678 |
EMP | EMP | B40C23C6E2B4EA3D |
EVENT | EVENT | 7CA0A42DA768F96D |
FINANCE | FINANCE | 6CBBF17292A1B9AA |
FND | FND | 0C0832F8B6897321 |
GPFD | GPFD | BA787E988F8BC424 |
GPLD | GPLD | 9D561E4D6585824B |
HR | HR | 4C6D73C3E8B0F0DA |
HLW | HLW | 855296220C095810 |
IMAGEUSER | IMAGEUSER | E079BF5E433F0B89 |
IMEDIA | IMEDIA | 8FB1DC9A6F8CE827 |
JONES | STEEL | B9E99443032F059D |
JMUSER | JMUSER | 063BA85BF749DF8E |
LBACSYS | LBACSYS | AC9700FD3F1410EB |
MDSYS | MDSYS | 9AAEB2214DCC9A31 |
MFG | MFG | FC1B0DD35E790847 |
MIGRATE | MIGRATE | 5A88CE52084E9700 |
MILLER | MILLER | D0EFCD03C95DF106 |
MMO2 | MMO3 | AE128772645F6709 |
MODTEST | YES | BBFF58334CDEF86D |
MOREAU | MOREAU | CF5A081E7585936B |
NAMES | NAMES | 9B95D28A979CC5C4 |
MTSSYS | MTSSYS | 6465913FF5FF1831 |
MXAGENT | MXAGENT | C5F0512A64EB0E7F |
OCITEST | OCITEST | C09011CB0205B347 |
ODS | ODS | 89804494ADFC71BC |
ODSCOMMON | ODSCOMMON | 59BBED977430C1A8 |
OE | OE | D1A2DFC623FDA40A |
OEMADM | OEMADM | 9DCE98CCF541AAE6 |
OLAPDBA | OLAPDBA | 1AF71599EDACFB00 |
OLAPSVR | INSTANCE | AF52CFD036E8F425 |
OLAPSYS | MANAGER | 3FB8EF9DB538647C |
ORACACHE | Random Password (Случайный пароль) |
. |
ORAREGSYS | ORAREGSYS | 28D778112C63CB15 |
ORDPLUGINS | ORDPLUGINS | 88A2B2C183431F00 |
ORDSYS | ORDSYS | 7EFA02EC7EA6B86F |
OSE$HTTP$ADMIN | Random Password (Случайный пароль) |
. |
OUTLN | OUTLN | 4A3BA55E08595C81 |
PERFSTAT | PERFSTAT | AC98877DE1297365 |
PM | PM | C7A235E6D2AF6018 |
PO | PO | 355CBEC355C10FEF |
PO8 | PO8 | 7E15FBACA7CDEBEC |
PO7 | PO7 | 6B870AF28F711204 |
PORTAL30 | PORTAL31 | D373ABE86992BE68 |
PORTAL30_DEMO | PORTAL30_DEMO | CFD1302A7F832068 |
PORTAL30_PUBLIC | PORTAL30_PUBLIC | 42068201613CA6E2 |
PORTAL30_SSO | PORTAL30_SSO | 882B80B587FCDBC8 |
PORTAL30_SSO_PS | PORTAL30_SSO_PS | F2C3DC8003BC90F8 |
PORTAL30_SSO _PUBLIC |
PORTAL30_SSO _PUBLIC |
98741BDA2AC7FFB2 |
POWERCARTUSER | POWERCARTUSER | 2C5ECE3BEC35CE69 |
PRIMARY | PRIMARY | 70C3248DFFB90152 |
PUBSUB | PUBSUB | 80294AE45A46E77B |
QS | QS | 4603BCD2744BDE4F |
QS_ADM | QS_ADM | 3990FB418162F2A0 |
QS_CB | QS_CB | 870C36D8E6CD7CF5 |
QS_CBADM | QS_CBADM | 20E788F9D4F1D92C |
QS_CS | QS_CS | 2CA6D0FC25128CF3 |
QS_ES | QS_ES | 9A5F2D9F5D1A9EF4 |
QS_OS | QS_OS | 0EF5997DC2638A61 |
QS_WS | QS_WS | 0447F2F756B4F460 |
RE | RE | 933B9A9475E882A6 |
REPADMIN | REPADMIN | 915C93F34954F5F8 |
RMAIL | RMAIL | DA4435BBF8CAE54C |
RMAN | RMAN | E7B5D92911C831E1 |
SAMPLE | SAMPLE | E74B15A3F7A19CA8 |
SCOTT | TIGER | F894844C34402B67 |
SDOS_ICSAP | SDOS_ICSAP | C789210ACC24DA16 |
SECDEMO | SECDEMO | 009BBE8142502E10 |
SH | SH | 54B253CBBAAA8C48 |
SYS | CHANGE_ON_INSTALL | 4DE42795E66117AE |
SYSADM | SYSADM | BA3E855E93B5B9B0 |
SYSTEM | MANAGER | D4DF7931AB130E37 |
TAHITI | TAHITI | F339612C73D27861 |
TDOS_ICSAP | TDOS_ICSAP | 7C0900F751723768 |
TRACESVR | TRACE | F9DA8977092B7B81 |
TSDEV | TSDEV | 29268859446F5A8C |
TSUSER | TSUSER | 90C4F894E2972F08 |
USER0 | USER0 | 8A0760E2710AB0B4 |
USER1 | USER1 | BBE7786A584F9103 |
USER2 | USER2 | 1718E5DBB8F89784 |
USER3 | USER3 | 94152F9F5B35B103 |
USER4 | USER4 | 2907B1BFA9DA5091 |
USER5 | USER5 | 6E97FCEA92BAA4CB |
USER6 | USER6 | F73E1A76B1E57F3D |
USER7 | USER7 | 3E9C94488C1A3908 |
USER8 | USER8 | D148049C2780B869 |
USER9 | USER9 | 0487AFEE55ECEE66 |
UTLBSTATU | UTLESTAT | C42D1FA3231AB025 |
VIDEOUSER | VIDEOUSER | 29ECA1F239B0F7DF |
VIF_DEVELOPER | VIF_DEV_PWD | 9A7DCB0C1D84C488 |
VIRUSER | VIRUSER | 404B03707BF5CEA3 |
VRR1 | VRR2 | 811C49394C921D66 |
WEBDB | WEBDB | D4C4DCDD41B05A5D |
WKSYS | WKSYS | 545E13456B7DDEA0 |
Чувствительность пароля к регистру символов
По умолчанию все пароли в Oracle Database 11g и 12c зависят от регистра. Параметр инициализации SEC_CASE_SENSITIVE_LOGON управляет чувствительностью паролей к регистру символов. Значение этого параметра по умолчанию — true, т.е. по умолчанию все пароли зависят от регистра. Если по какой-либо причине, например, из-за того, что некоторые приложения используют жестко закодированные пароли, которые должны быть независимыми от регистра, то установкой параметра SEC_CASE_SENSITIVE_LOGON в false базе данных можно указать на необходимость игнорирования регистра символов при проверке паролей:
sec_case_sensitive_logon=false
Как изменить пароль пользователя Oracle
При модернизации более ранних версий БД до Oracle Database 11g пароли остаются независимыми от регистра, поскольку таким было поведение предшествующих версий. Чтобы сделать их зависимыми от регистра, необходимо с помощью оператора ALTER USER изменить пароль каждого пользователя.
При обновлении до Oracle Database 11g пароли остаются независимыми от регистра до тех пор, пока они не будут изменены. Если параметр SEC_CASE_SENSITIVE_LOGON установлен в используемое по умолчанию значение true, все новые пароли будут зависимыми от регистра, подобно паролям в новой базе данных версии Oracle Database 11g. В только что обновленной базе данных можно выполнить следующий запрос, чтобы выяснить, в какой версии был установлен или изменен пароль пользователя:
SQL> SELECT username, password, password_versions FROM dba_users; USERNAME PASSWORD PASSWORD -------------------- --------- -------- MGMT_VIEW 10G 11G SYS 10G 11G SYSTEM 10G 11G DBSNMP 10G 11G SYSMAN 10G 11G RMAN 10G 11G SH 10G 11G . . . 39 rows selected. SQL>
Столбец PASSWORD_VERSIONS отображает версию базы данных, в которой пароль был первоначально установлен или изменен. Результат запроса показывает, что все пароли были либо созданы, либо изменены в версии Oracle Database 11g. Этот запрос не позволяет увидеть (зашифрованные) пароли, как можно было в предшествующих версиях, но зашифрованные пароли доступны для просмотра через представление USER$.
При неудачных попытках подключения с применением неправильного пароля после третьей неудачной попытки база данных увеличит временной интервал между последующими попытками максимум до 10 секунд.
Поддержка защищенных паролей
В дополнение к зависимости всех паролей от регистра символов, Oracle предлагает также другие функциональные возможности для обеспечения поддержки защищенных паролей. К ним относится передача всех введенных пользователями паролей посредством надежного алгоритма хеширования (SHA-1, который использует 160-битный ключ) и их сравнение с хранимыми верительными данным этого пользователя, а также дополнение всех паролей уникальным случайным значением для гарантии уникальности результирующих верительных данных.
Блокировка учетных записей
Следующий оператор позволяет разблокировать для свободного доступа любую заблокированную учетную запись пользователя:
SQL> ALTER USER hr ACCOUNT UNLOCK; User altered. SQL>
С помощью оператора CREATE PROFILE или ALTER PROFILE можно вынудить Oracle блокировать любую учетную запись после определенного числа неудачных попыток регистрации. Oracle позволяет задавать продолжительность интервала, в течение которого учетная запись должна оставаться заблокированной после указанного количества неудачных попыток входа в базу данных. По истечении этого времени Oracle автоматически разблокирует учетную запись. Чтобы закрыть эту лазейку, просто установите длительность периода блокирования в значение UNLIMITED (не ограничено).
Ниже приведен пример создания профиля с заданным временным периодом блокирования учетной записи:
SQL> CREATE PROFILE test_profile 2 LIMIT FAILED_LOGIN_ATTEMPTS 5 3* PASSWORD_LOCK_TIME UNLIMITED Profile created. SQL>
База данных заблокирует учетную запись немедленно по достижении предела неудачных попыток регистрации FAILED_LOGIN_ATTEMPTS. Однако с помощью следующей команды администратор БД может разблокировать учетную запись пользователя в любое время:
SQL> ALTER USER hr ACCOUNT UNLOCK; User altered. SQL>
Истечение срока действия пароля
Политики устаревания паролей, гарантирующие, что пользователи не смогут применять один и тот же пароль в течение длительного времени — стандартная составляющая безопасности базы данных. Как только срок действия пароля истекает, пользователь вынужден изменить его. Пароль можно объявить утратившим силу с помощью команды ALTER USER, как показано в следующем примере:
SQL> ALTER USER hr IDENTIFIED BY hr PASSWORD EXPIRE; User altered. SQL>
Этого же можно достичь также командой ALTER PROFILE:
SQL> ALTER PROFILE test_profile 2* LIMIT PASSWORD_LIFE_TIME 30; Profile altered. SQL> ALTER USER hr PROFILE test_profile; User altered. SQL>
Приведенный оператор ALTER PROFILE ограничивает срок действия пароля 30 днями, и об этом можно любезно напомнить пользователю, используя в операторе ALTER PROFILE конструкцию PASSWORD_GRACE_TIME. Как только конструкция PASSWORD_GRACE_TIME определена, при первой регистрации пользователя после окончания срока действия пароля пользователь получит предупреждение о том, что пароль утратит силу через три дня. Если пользователь не изменит пароль в течение трехдневного предупредительного периода, пароль утратит силу. После того как срок действия пароля истекает, пароль должен быть изменен.
SQL> CONNECT hr/hr ERROR: ORA-28001: the password has expired Changing password for hr New password: ** Retype new password: ** Password changed Connected. SQL>
Файл паролей
Oracle позволяет выбирать, как привилегированные пользователи должны подключаться к базе данных. Привилегированные пользователи — это пользователи, которые могут выполнять такие задачи, как запуск и остановка базы данных. По умолчанию только пользователь SYS обладает полномочиями SYSDBA и SYSOPER, которые считаются полномочиями высокого уровня. Пользователь SYS может предоставлять эти полномочия другим пользователям.
Конечно, любой администратор БД, который знает пароль пользователя SYS, может зарегистрироваться в качестве этого пользователя и выполнять привилегированные задачи. Однако, явно предоставляя чрезвычайно важные полномочия SYSDBA и SYSOPER пользователям, вы вынуждаете их указывать свое имя пользователя и пароль, что позволяет легко отслеживать действия привилегированных пользователей. Параметр инициализации REMOTE_LOGIN_PASSWORDFILE указывает, должна БД Oracle проверять наличие файла паролей.
Параметр REMOTE_LOGIN_PASSWORDFILE может принимать перечисленные ниже значения.
- none. Никакой файл паролей не используется, и база данных разрешает только пользователям, подлинность которых установлена операционной системой, выполнять привилегированные задачи по администрированию базы данных.
- exclusive. Только одна база данных может использовать файл паролей. Файл может содержать данные как пользователя SYS, так и других пользователей.
- shared. В системе создан файл паролей, который может использоваться несколькими базами данных. Файл паролей может содержать данные как пользователя SYS, так и других пользователей.
Для обеспечения наивысшей степени безопасности в Oracle рекомендуют применять опцию REMOTE_LOGIN_PASSWORDFILE=SHARED. Существует способ создания файла паролей и указания пользователей, которые могут обладать полномочиями SYSDBA и SYSOPER, вручную, но при использовании опции EXCLUSIVE Oracle будет автоматически добавлять пользователей в файл паролей при предоставлении им полномочий SYSDBA и SYSOPER. Для выяснения того, кому, кроме определенного по умолчанию пользователя SYS, выданы эти полномочия, можно запросить представление V$PWFILE_USERS:
SQL> CONNECT sys/life1 AS SYSDBA; Connected. SQL> GRANT sysoper, sysdba TO tester; Grant succeeded. SQL> SELECT * FROM v$pwfile_users; USERNAME SYSDB SYSOP -------- ----- ----- SYS TRUE TRUE TESTER TRUE TRUE SQL>
Команда orapwd служит для создания нового файла паролей. Следующий вывод демонстрирует значения, которые можно передавать с командой orapwd, а также то, какие из них являются обязательными, а какие — необязательными.
$ orapwd Usage: orapwd file= password= entries= force=<y/n> ignorecase=<y/n> nosysdba=<y/n> where file - name of password file (required), имя файла паролей (обязательно) password - password for SYS (optional), пароль для пользователя SYS (необязательно) entries - maximum number of distinct DBA (required), максимальное количество отдельных администраторов БД (обязательно) force - whether to overwrite existing file (optional), указывает, нужно ли перезаписывать существующий файл (необязательно) ignorecase - passwords are case-insensitive (optional), пароли не зависят от регистра (необязательно) nosysdba - whether to shut out the SYSDBA logon (optional Database Vault only). указывает, нужно ли препятствовать входу SYSDBA (необязательно только для Database Vault) There must be no spaces around the equal-to (=) character. Символ "равно" (=) не должен быть окружен пробелами S
Следующая команда создает новый файл паролей по имени testpwd:
$ orapwd FILE=testpwd PASSWORD=remorse1 ENTRIES=20
Шифрованные пароли
По умолчанию пароли пользователей Oracle не шифруются, и это делает их уязвимыми для несанкционированного использования. Устанавливая следующие переменные среды — одну на клиенте, другую на сервере, — можно обеспечить, что Oracle всегда будет шифровать пароль при его пересылке по сети. Установите на клиенте следующую переменную:
ora_encrypt_login=true
На сервере должна быть установлена следующая переменная:
dblink_encrypt_login=true
На заметку! Все пароли всегда автоматически шифруются во время сетевых подключений. При этом используется модифицированный алгоритм DES (Data Encryption Standard — стандарт шифрования данных).
Внешняя аутентификация
Еще один метод аутентификации пользователей базы данных — метод внешней аутентификации, при котором учетные записи пользователей на уровне операционной системы сопоставляются с именами пользователей в базе данных. Oracle осуществляет управление полномочиями пользователей в самой базе данных, но аутентификация пользователей производится операционной системой, которая является внешней по отношению к БД. Преимущество этого метода состоит в том, что будет требоваться единственное имя пользователя для операционной системы и для подключений к базе данных. Это может также облегчить аудит действий пользователей, поскольку имена в базе данных и учетные записи операционной системы совпадают.
Для применения аутентификации операционной системой вначале потребуется установить параметр конфигурации OS_AUTHENT_PREFIX в файле init.ora:
OS_AUTHENT_PREFIX = ""
Пара кавычек не должна содержать пробел.
На заметку! По умолчанию параметру OS_AUTHENT_PREFIX присваивается значение «OPS$«, но это делается только для поддержания обратной совместимости.
При повторном запуске базы данных можно начать использовать внешнюю аутентификацию средствами операционной системы. Чтобы активизировать аутентификацию операционной системой, пользователей необходимо создавать следующим образом:
SQL> CREATE USER salapati IDENTIFIED EXTERNALLY; User created. SQL>
Обратите внимание, что новому пользователю не присваивается пароль — он в нем не нуждается. До тех пор, пока пользователь может войти в операционную систему, все, что ему нужно сделать для входа в базу данных — это ввести следующую команду:
$ sqlplus /
На заметку! Хорошо известная учетная запись Oracle OPS$ORACLE — это простая разновидность приведенного примера внешней аутентификации. OPS$ — префикс, используемый Oracle, начиная с версии Oracle 5. Для внешней аутентификации операционной системой можно использовать любой префикс или вообще его не указывать.
Внешняя аутентификация операционной системой, описанная в этом разделе, не позволяет пользователям подключаться через службу Oracle Net, поскольку этот метод аутентификации считается не слишком безопасным. Поэтому конфигурации с разделяемым сервером, использующие Oracle Net, по умолчанию не могут применять внешнюю аутентификацию операционной системой. Для изменения этого определенного по умолчанию поведения потребуется установить следующий параметр в файле init.ora:
REMOTE_OS_AUTHENT=TRUE
Прокси-аутентификация
Прокси-аутентификация позволяет одному постоянному сеансу базы данных выполнять переключение на других пользователей без необходимости осуществлять вход/выход из БД. Для поддержки взаимодействия пользователя с базой данных Oracle можно использовать несколько продуктов промежуточного слоя. Часто веб-сервер служит промежуточным слоем или слоем приложения, связывающего клиентов с базой данных. Промежуточный слой может выполнять аутентификацию пользователей или же передавать имя пользователя и пароль в базу данных для выполнения аутентификации. Ниже приведен пример санкционирования подключений посредством регистрации пользователя базы данных из узла промежуточного слоя с применением аутентификации с применением пароля.
SQL> ALTER USER salapati 2 GRANT CONNECT THROUGH appserv 3* AUTHENTICATED USING PASSWORD; User altered. SQL>
В следующем примере показано, как разрешить постоянному сеансу, запущенному на сервере appserv, временно принимать идентичность salapati, если постоянный сеанс предоставляет пароль этого пользователя:
SQL> ALTER USER salapati 2* GRANT CONNECT THROUGH appserv; User altered. SQL>
Централизованная авторизация пользователей
Если используется опция Oracle Advanced Security (Расширенная безопасность Oracle), для выполнения аутентификации пользователей можно использовать службу каталогов, работающую на основе LDAP (Lightweight Directory Access Protocol — облегченный протокол службы каталогов), такую как Oracle Internet Directory (OID). Служба на основе каталога позволяет создавать пользователей предприятия, которым можно назначать глобальные роли. Централизованное управление пользователями позволяет применять однократную регистрацию — т.е. чтобы получить доступ ко всем необходимым им базам данных, пользователи должны зарегистрироваться только один раз.
Поскольку опция Oracle Advanced Security используется не всеми базами данных, подробное описание реализации централизованной авторизации пользователей не приводится. Для ознакомления с подробным описанием этой функциональной возможности обращайтесь к руководству Oracle Advanced Security Administrator’s Guide (Руководство администратора расширенной системы безопасности Oracle), доступном на веб-сайте:
http://tahiti.oracle.com
Вас заинтересует / Intresting for you:
Home » Articles » Misc » Here
This article describes how to change the password for your own user in an Oracle database.
- ALTER USER Command
- SQL*Plus and SQLcl
- SQL Developer
- TOAD
- Proxy Users
Related articles.
- Proxy User Authentication and Connect Through in Oracle Databases
ALTER USER Command
Log on to the database as yourself, using any tool that can send SQL statements to the database.
CONN my_user/MyPassword123@orcl
Once connected, issue to the following ALTER USER
command, specifying the new password.
ALTER USER my_user IDENTIFIED BY MyNewPassword123;
You don’t need any additional privileges to change your own password. The same command can be used to change the password for another user, provided you have a privileged account.
If you want to use special characters, remember to enclose the password in double quotes.
ALTER USER my_user IDENTIFIED BY "MyNewPassword123#";
SQL*Plus and SQLcl
As well as using the ALTER USER
command, you can use the PASSWORD
command from the SQL*Plus and SQLcl utilities. You will be prompted for your current password and the new password.
SQL> password Changing password for MY_USER Old password: ******** New password: ******** Retype new password: ******** Password changed SQL>
SQL Developer
From SQL Developer, do the following.
- Right-click on the connection.
- Select the «Reset Password…» option from the popup menu.
- In the subsequent dialog, enter the current password and the new password with confirmation.
- Click the OK button.
TOAD
From TOAD, do the following.
- From the top menu, select «Session > Change Password».
- In the subsequent dialog, enter the current password and the new password with verification.
- Click the OK button.
Proxy Users
Proxy users allow you to connect to another user with your own credentials. This way you never need to know the credentials of the schema you are connecting to.
You should not attempt to change your password when connected as a proxy. Instead you should connect as yourself, change your password, then reconnect as a proxy user with your new password.
As an example, let’s imagine there is a schema owner called SCHEMA_OWNER
and my user called MY_USER
in a database called ORCL
. My proxy connection would look like this. When prompted I would connect using the password for MY_USER
.
CONN my_user[schema_owner]@orcl
To change my password I might to do something like this.
-- Connect to my user. CONN my_user@orcl -- Change password. ALTER USER my_user IDENTIFIED BY MyNewPassword123; -- Make a proxy connection again. CONN my_user[schema_owner]@orcl
For more information see:
- Proxy User Authentication and Connect Through in Oracle Databases
Hope this helps. Regards Tim…
Back to the Top.
Summary: in this tutorial, you will learn how to use the Oracle ALTER USER
statement to modify the authentication or database resource of a database user.
The ALTER USER
statement allows you to change the authentication or database resource characteristics of a database user.
Generally speaking, to execute the ALTER USER
statement, your account needs to have the ALTER USER
system privilege. However, you can change your own password using the ALTER USER
statement without having the ALTER USER
system privilege.
Let’s create a user named dolphin
and grant the CREATE SESSION
system privilege to dolphin
:
CREATE USER dolphin IDENTIFIED BY abcd1234; GRANT CREATE SESSION TO dolphin;
Code language: SQL (Structured Query Language) (sql)
1) Using Oracle ALTER USER
statement to change the password for a user
The following example uses the ALTER USER
statement to change the password for the user dolphin
:
Code language: SQL (Structured Query Language) (sql)
ALTER USER dolphin IDENTIFIED BY xyz123;
Log in to the Oracle Database using the dolphin user:
Code language: SQL (Structured Query Language) (sql)
Enter user-name: dolphin@pdborcl Enter password: <dolphin password>
The user dolphin
should be able to authenticate to the Oracle Database using the new password xyz123
2) Using Oracle ALTER USER
statement to lock/unlock a user
This example uses the ALTER USER
statement to lock the user dolphin
:
Code language: SQL (Structured Query Language) (sql)
ALTER USER dolphin ACCOUNT LOCK;
If you use the user dolphin
to log in to the Oracle Database, you should see a message indicating that the user is locked:
Code language: SQL (Structured Query Language) (sql)
Enter user-name: dolphin@pdborcl Enter password: <dolphin password> ERROR: ORA-28000: the account is locked
To unlock the user dolphin
, you use the following statement:
Code language: SQL (Structured Query Language) (sql)
ALTER USER dolphin ACCOUNT UNLOCK;
Now, the user dolphin
should be able to log in to the Oracle Database.
3) Using Oracle ALTER USER
statement to set user’s password expired
To set the password of the user dolphin
expired, you use the following statement:
Code language: SQL (Structured Query Language) (sql)
ALTER USER dolphin PASSWORD EXPIRE;
When you use the user dolphin
to log in to the database, Oracle issues a message indicating that the password has expired and requests for the password change as follows:
Code language: SQL (Structured Query Language) (sql)
Enter user-name: dolphin@orclpdb Enter password: <dolphin password> ERROR: ORA-28001: the password has expired Changing password for dolphin New password: <new password> Retype new password: <new password> Password changed
4) Using Oracle ALTER USER
statement to set the default profile for a user
This statement returns the profile of the user dolphin
:
Code language: SQL (Structured Query Language) (sql)
SELECT username, profile FROM dba_users WHERE username ='DOLPHIN';
When you create a new user without specifying a profile, Oracle will assign the DEFAULT
profile to the user.
Let’s create a new user profile called ocean
:
Code language: SQL (Structured Query Language) (sql)
CREATE PROFILE ocean LIMIT SESSIONS_PER_USER UNLIMITED CPU_PER_SESSION UNLIMITED CPU_PER_CALL 3000 CONNECT_TIME 60;
and assign it to the user dolphin
:
Code language: SQL (Structured Query Language) (sql)
ALTER USER dolphin PROFILE ocean;
Now, the default profile of the user dolphin
is ocean
.
5) Using Oracle ALTER USER
statement to set default roles for a user
Currently, the user dolphin
has no assigned roles as shown in the output of the following query when executing from the dolphin’s session:
Code language: SQL (Structured Query Language) (sql)
SELECT * FROM session_roles;
First, create a new role called rescue
from the user OT
‘s session:
Code language: SQL (Structured Query Language) (sql)
CREATE ROLES rescue; GRANT CREATE TABLE, CREATE VIEW TO rescue;
Second, grant this role to dolphin
:
GRANT rescue TO dolphin;
Code language: SQL (Structured Query Language) (sql)
Third, use the user dolphin
to log in to the Oracle Database. The default role of the user dolphin
is rescue
now.
Code language: SQL (Structured Query Language) (sql)
SELECT * FROM session_roles;
Here is the output:
Code language: SQL (Structured Query Language) (sql)
ROLE --------- RESCUE
Fourth, create another role called super
and grant all privileges to this role:
Code language: SQL (Structured Query Language) (sql)
CREATE ROLE super; GRANT ALL PRIVILEGES TO super;
Fifth, grant the role super
to the user dolphin
:
Code language: SQL (Structured Query Language) (sql)
GRANT super TO dolphin;
Sixth, set the default role of the user dolphin
to super
:
ALTER USER dolphin DEFAULT ROLE super;
Code language: SQL (Structured Query Language) (sql)
Seventh, disconnect the current session of the user dolphin and log in to the Oracle Database again. The default role of the user dolphin should be super
as shown in the output of the following query:
Code language: SQL (Structured Query Language) (sql)
SELECT * FROM session_roles;
The following shows the output:
Code language: SQL (Structured Query Language) (sql)
ROLE --------- SUPER
In this tutorial, you have learned how to use the Oracle ALTER USER
to change the authentication or database resource of a database user.
Was this tutorial helpful?