ora 01017 invalid username password logon denied как исправить

Ora-01017 недопустимое имя пользователя / пароль при подключении к базе данных 11g от клиента 9i

есть ли принципиальная несовместимость версии 9i и 11G?

13 ответов

пользователь и пароль тотже. Учетные данные Oracle 11g чувствительны к регистру.

попробуйте изменить системный набор SEC_CASE_SENSITIVE_LOGON = FALSE; и изменить пароль.

Если все остальное не удается, попробуйте сбросить пароль на то же самое. Я столкнулся с этой ошибкой и не смог обойти ее, но просто сброс пароля до того же значения решил проблему.

некоторое время назад у меня была аналогичная проблема. Вы должны быть осторожны с кавычками и двойными кавычками. Рекомендуется сбросить пароль пользователя, используя учетные данные администратора.

но не используйте двойные кавычки в обоих параметров.

для oracle версии 12.2.X пользователи не могут войти в систему, используя пароли без учета регистра, даже если SEC_CASE_SENSITIVE_LOGON = FALSE, если PASSWORD_VERSIONS пользователя не 10g.

следующий sql должен показывать PASSWORD_VERSIONS для пользователя.

сделать PASSWORD_VERSIONS совместимым с 10g

добавить / изменить строку в sqlnet.ora базы данных, чтобы иметь SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 перезапуска базы изменить / истечь пароль для существующего пользователя новый пользователь созданные также будут иметь те же настройки после вышеуказанных шагов PASSWORD_VERSIONS должно быть что-то вроде этого

еще несколько фактов моего env:

У меня была та же проблема, и я поставил двойные кавычки вокруг имени пользователя и пароля, и это сработало: создайте общедоступную ссылку базы данных «opps», идентифицированную «opps» с помощью «TEST»;

Я не специалист. Если вы получаете ORA-01017 при попытке подключить схему HR от разработчика SQL в Oracle 11g Пожалуйста, попробуйте разблокировать HR следующим образом

alter user HR идентифицируется hr Пользователи табличного пространства по умолчанию временная температура табличного пространства разблокировка аккаунта;

вы можете подключиться к базе данных Oracle с помощью sqlplus:

затем создайте новых пользователей и назначьте привилегии.

подсказка на OTN Oracle = Не вводите пароль в TOAD при попытке подключения и пусть это всплывающее окно диалоговое окно ваш пароль. введите пароль туда и оно будет работать. Не уверен, что они сделали в жабе с паролями, но это обходной путь. Это связано с паролями с учетом регистра в 11g. Я думаю, если вы измените пароль на весь верхний регистр, он будет работать с ЖАБА. https://community.oracle.com/thread/908022

Я также получил то же сообщение об ошибке sql при подключении через odp.net через прокси-пользователя.

моя ошибка заключалась в том, что мой пользователь был создан с кавычками (например, «rockerolf»), и мне также пришлось указать моего пользователя в connectionstring как User >

в конце концов я удалил пользователя с кавычками и создал новый без кавычек..

Я знаю, что этот пост был о 11g, но ошибка в клиенте 12c с тем, как он шифрует пароли, может быть виновата в этой ошибке, если вы решите использовать этот и вы:

все основные проверки.

Fix: попробуйте установить HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled to 0 в реестре (regedit), чтобы отключить ФИПС.

недавно у меня была аналогичная проблема с Oracle 12c. Я создал нового пользователя с паролем нижнего регистра и смог войти в систему с сервера базы данных, но все клиенты потерпели неудачу с ORA-01017. Исправление оказалось простым в конце (сброс пароля в верхний регистр), но потребовалось много усилий, чтобы добраться туда.

Источник

Ошибка ORA-01017: invalid username/password; logon denied, вызванная параметром sec_case_sensitive_logon

При входе в базу данных Oracle может выдаваться ошибка ORA-01017: invalid username/password; logon denied, хотя пароль при вводе набирается правильный. Причин может быть несколько, но в данном посте будет рассмотрена одна из них – инициализационный параметр sec_case_sensitive_logon.

Параметр sec_case_sensitive_logon позволяет включать или выключать чувствительность к регистру паролей в базе данных Oracle (БД). Параметр принимает два значения – TRUE или FALSE, при TRUE – пароли пользователей чувствительны к регистру, а при FALSE, соответственно, нет. Значение параметра sec_case_sensitive_logon можно просмотреть командой show parameter sec_case_sensitive_logon. Запрос ниже показывает, что параметр имеет значение TRUE. Это означает, что чувствительность к регистру паролей в БД включена.

Изменить значение параметра sec_case_sensitive_logon можно командой alter system set sec_case_sensitive_logon = false или alter system set sec_case_sensitive_logon = true. Команда ниже отключает чувствительность к регистру паролей.

Начиная с версии Oracle Database 12.1.0.1, параметр sec_case_sensitive_logon считается устаревшим. Это значит, что Oracle не вносит в него дальнейших изменений, и пользователи не должны менять значение параметра. Значение по умолчанию TRUE. Если же значение будет изменено, то пользователь получит предупреждение при запуске БД:

Также, начиная с Oracle Database 12c release 2 (12.2), по умолчанию версией протокола аутентификации является 12 (известный как Exclusive Mode). Этот протокол для аутентификации требует чувствительные к регистру пароли. Например, для Oracle Database 12c release 2 (12.2) значение по умолчанию для параметра SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле SQLNET.ORA равно 12. Файл SQLNET.ORA по умолчанию находится в следующей директории операционной системы:

Параметр SQLNET.ALLOWED_LOGON_VERSION_SERVER отображает протокол аутентификации, используемый для сервера. И по умолчанию, Oracle больше не поддерживает пароли, не чувствительные к регистру – разрешены только новые версии паролей (11G и 12C). В связи с этим при входе в БД с значением FALSE для параметра sec_case_sensitive_logon можно получить ошибку:

ORA-01017: invalid username/password.

Данная ситуация возникает из-за того, что параметр sec_case_sensitive_logon имеет значение FALSE и параметр SQLNET.ALLOWED_LOGON_VERSION_SERVER имеет значение 12 или 12a. Oracle Database не запрещает использование значения FALSE параметра sec_case_sensitive_logon, когда значение SQLNET.ALLOWED_LOGON_VERSION_SERVER равно 12 или 12a. Но при таких условиях, все учетные записи кроме имеющих роль sysdba становятся недоступными. И именно такие настройки вызывают ошибку ORA-01017: invalid username/password. Есть два способа выхода из этой ситуации.

Первый способ – необходимо присвоить параметру sec_case_sensitive_logon значение TRUE. Это решение рекомендовано, так как обеспечивает более безопасные пароли. В этом случае не нужно будет менять пароли для учетных записей. Система будет поддерживать версии протоколов пароля 11g и 12c, которые используются учетными записями. Хотелось бы отметить, что версия протокола пароля не всегда равна версии Oracle Database. Например, далее в примерах используется Oracle Database 18c Express Edition и при этом используется версия протокола пароля 11g и 12с.

Вторым способом является присвоение параметру SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле SQLNET.ora значение, ниже 12, например, 11 версию протокола аутентификации. Но это решение подразумевает необходимость смены паролей для всех пользователей БД с ролью, отличной от sysdba. Ниже в примерах показывается возникновение ошибки и ее решение двумя вышеописанными способами.

Пример 1. Возникновение ошибки при изменении параметра sec_case_sensitive_logon. Выполняется подключение к подключаемой базой данных (Pluggable Database – PDB) XEPDB1 Oracle Database 18c Express Edition под пользователем sys:

Проверяется текущее значение параметра sec_case_sensitive_logon. Результат команды показывает, что параметр чувствительности к регистру пароля включен:

Назначается пароль пользователю hr и выполняется выход из БД:

Выполняется подключение к базе данных под пользователем hr.

Подключение успешно прошло под пользователем hr.

Далее, выполняется отключение от базы под пользователем hr и подключение к контейнерной базе данных (Container Database – CDB) Oracle Dabase 18c Express Edition под пользователем sys.

Изменяется значение параметра sec_case_sensitive_logon на FALSE.

Проверяется новое значение параметра sec_case_sensitive_logon.

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

ERROR at line 1: ORA-65040: operation not allowed from within a pluggable database

Далее, нужно подключиться к подключаемой базе данных под пользователем hr.

При подключении система выдает ошибку, сообщающую о том, что был введен неверный логин или пароль.

Исправить данную ошибку можно, обратно сменив значение параметра sec_case_sensitive_logon на TRUE. Выполняется подключение к БД под учетной записью sys и запускается изменение значения параметра sec_case_sensitive_logon на TRUE.

Проверяется, поможет ли возврат значения параметра успешно подключиться к базе данных. Подключение к БД происходит под пользователем hr еще раз.

Как можно убедиться, подключение прошло без ошибок после возвращения значения на TRUE.

Пример 2. Возвращается параметру sec_case_sensitive_logon значение FALSE, чтобы смоделировать ошибку и показать второй способ решения. Выполняется подключение к БД под пользователем sys и меняется значение параметра sec_case_sensitive_logon на FALSE.

Ниже видно, что при попытке подключения под пользователем hr система выдает ту же ошибку – ORA-01017: invalid username/password; logon denied.

На подключение к базе данных также влияет значение параметра SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле sqlnet.ora. Как было сказано выше, по умолчанию для версий Oracle Database 12.2 и выше используется версия алгоритма пароля, равная 12. В Oracle Database 18с Express Edition, которая используется в данном примере, параметр SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле sqlnet.ora отсутствует. Это значит, что БД использует версию алгоритма паролей равную 12 по умолчанию. Вручную, добавив строку SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 задается значение параметра равное 11. После этого содержимое файла sqlnet.ora выглядит следующим образом:

Пароли пользователей кроме имеющих роль sysdba должны быть изменены после изменения значения параметра SQLNET.ALLOWED_LOGON_VERSION_SERVER на 11 версию. Иначе они получат ошибку при входе, как показано в примере ниже.

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

Результат выполнения команды показывает, что у hr до сих пор применяются версии протоколов пароля 11g и 12c. Необходимо сменить ему пароль, чтобы в данном случае исключить ошибку при входе пользователя. Для этого, изменяется пароль пользователю hr и проверяется версия паролей пользователя hr.

После смены пароля выполняется подключение под пользователем hr. Ниже результат команды показывает, что подключение прошло успешно.

На этом завершается описание способов решения ошибки ORA-01017: invalid username/password; logon denied, связанной с параметром sec_case_sensitive_logon.

Источник

Ошибка ORA-01017 в sqlplus 12.1, может подключаться к тем же учетным данным в других приложениях

У меня есть SQL * Plus 12.1, установленный на Fedora 19, который пытается подключиться к базе данных Oracle 11g. Я установил instantclient RPM пакеты (основной, развейте, Sqlplus) от сюда. Я могу успешно подключиться к другим базам данных Oracle, используя SQL * Plus, поэтому я знаю, что у меня есть рабочая установка программного обеспечения. Однако, когда я пытаюсь подключиться к этой конкретной базе данных, я получаю эту ошибку:

Вот мой файл tnsnames.ora (с запущенным хостом и портом):

Моя переменная среды TNS_ADMIN установлена в путь к моему файлу tnsnames.ora.

Команда, которую я запускаю для подключения:

После нажатия enter, он зависает от версии и информации об авторских правах в течение примерно 2-3 секунд, прежде чем дать мне ошибку ORA-01017.

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

редактировать

Я просмотрел файл log.xml (в C:\oracle\product\11.2.0\diag\tnslsnr\test\listener\alert\log.xml ) и обнаружил, что есть несколько записей, которые показывают, что я разговаривая с правильным слушателем. Вот пример записи в журнале, но обфускация для возможной конфиденциальной информации:

Я также с тех пор пытался изменить элемент * SERVICE_NAME * в файле tnsnames.ora на SID, без каких-либо различий.

Окружение моего пароля с помощью кавычек также не помогло решить проблему.

Может ли быть проблема с версией? Я использую instantclient и sqlplus версии 12.1, но база данных – версия 11.2.

Изменить 2

Ну, это официально. Я идиот, и это вызвало ошибку. Я набрал неправильный пароль, и я предполагаю, что все, что я копировал, тоже неправильно.

Пара идей, в целях вероятности возникновения этой проблемы:

1) Если ваш пароль начинается с неалфавитного символа, объемного пароля с кавычками: user/»password»@service (обратите внимание, что приложения GUI, например TOAD и SQLDeveloper, не требуют кавычек).

И подтвердите, что ваш результат соответствует записи tnsnames.ora, которую вы думаете, что используете

3) На сервере запустите (или попросите запустить dba)

Убедитесь, что служба, указанная в вашем tnsnames.ora, направляется в соответствующую базу данных.

EDIT: Saw Nathan вопрос, подумал: “Хм, странно, я все время использую tnsp для проверки клиентских установок, почему черт не будет включен в instantclients?” Отвечая на вопрос Google, и, похоже, TNSPING практически бесполезен. ТОЛЬКО думает, что он проверяет, доступен ли хост и что tnslistener работает на указанном порту (который вы можете легко проверить с помощью telnet). H/T в “BillyVerreynne” на форумах Oracle: https://forums.oracle.com/message/10561771

ORA-01017 довольно ясна. Это означает, что вы ошиблись в имени пользователя или пароле, или, возможно, что вы действительно не подключаетесь к базе данных, к которой, по вашему мнению, подключаетесь.

Там действительно не так много сказать. Дважды проверьте свой дескриптор соединения и убедитесь, что вы не ошиблись в имени пользователя или пароле.

В вашем наборе sqlnet.ora

К сожалению, если проблема слишком близка к серверу, трассировка клиента может не помочь. Поскольку это база данных prod, которая может быть немного сложной для диагностики. Если у вас есть контракт на поддержку Oracle, они действительно хороши в разрешении такого рода вещей.

Я понимаю, что это не полный ответ, но я подозреваю, что из этого следа вы найдете другие более интересные ошибки. ORA-01017 имеет тенденцию быть общей ошибкой, которую сетевой уровень переходит на более высокий уровень, а полезные ошибки – это слой вниз в трассировке.

Источник

Oracle 11g r2 ORA-01017: invalid username/password; logon denied when connecting via JDBC driver

I’m not an Oracle expert nor a Database Administrator. But we have this Java program that we created and it used to connect to an Oracle 9i database (Windows environment), using the OCI driver.

But when we migrated to Oracle 11g r2 (Linux environment), we got this error when we tried to run the tool:

ORA-01017: invalid username/password; logon denied

I’ve tried a lot of possible codes to connect to the database (specifying host and port instead of just SID/service name, setting Properties object, using OracleDataSource, switching from OCI driver to thin driver, checking REMOTE_LOGIN_PASSWORDFILE, etc.) But still the same error.

Do you think this is a driver issue? Do we need to configure something in the database? By the way, these are the versions: JDBC => 11.2.0.3.0 Oracle DB => 11.2.0.4.0

In addition, I can’t connect to sqlplus if I indicate the connect string:

However, I can connect without indicating the connect string. The ORACLE_SID is set upon logging in to the server.

Is there a missing configuration that we should have set? Thanks in advance.

6 Answers 6

This is most likely happening because the Database server is using a strong verifier for this user and your client (either sqlplus or JDBC) doesn’t support this password verifier. You can either upgrade sqlplus and JDBC thin or make the server generate both strong and weak password verifiers so that old clients can still connect. To do so please follow this procedure:

In sqlnet.ora on the server set the logon version to 10:

And regenerate the user’s password (to re-generate the verifiers):

ora 01017 invalid username password logon denied как исправить. Смотреть фото ora 01017 invalid username password logon denied как исправить. Смотреть картинку ora 01017 invalid username password logon denied как исправить. Картинка про ora 01017 invalid username password logon denied как исправить. Фото ora 01017 invalid username password logon denied как исправить

ORA-01017: invalid username/password; logon denied

As others have said, this error message says it all. You have not specified a valid username/password combination. It’s that simple. There are some Oracle error messages that can be unclear, but this is not one of those.

Specify the username and password of an Oracle user in the database and your login should succeed.

I’m using a user that accepts any password as long as I’m connected as a root user.

You’re using SQL*Plus while logged on to the same machine as the database is running, and you are logged in to Linux as a user that has membership of the dba group. In this situation, you can log on no matter what username or password you specify. In fact, I’ve just tried to run

to connect to my Oracle 11g XE database, and this connected fine, despite the fact that my database has no blah user.

Please don’t assume that you can connect to Oracle using your OS user credentials. You may be able to log in to SQL*Plus with your OS username and no password, but that’s only because in your situation SQL*Plus lets you in regardless of your credentials. Oracle users are separate to OS users. Just because you can log in to your OS using a given username and password doesn’t mean you can log in to Oracle with the same credentials.

Once you can get a login to SQL*Plus using a connection string to succeed, you can then look at using the same username, password and connection string in JDBC.

Источник

ora-01017 invalid username password in sqlplus

Hi,
I just installed oracle 11g in windows 7, with toad using :

sydba
maypassword
orcl

but when I try sqlplus with the same user password database,I got :

ora-01017 invalid username password

thanks,your help is appreciated.

Answers

First mark helpful/correct answer to those 4 questions, mark those threads if you have got answer, else follow up them. Please follow the forum rule; otherwise no one will help you.

user8692160 wrote:
Hi,
I just installed oracle 11g in windows 7, with toad using :

sydba
maypassword
orcl

but when I try sqlplus with the same user password database,I got :

ora-01017 invalid username password

As I followed the installatin fromthe Cd,I remmeber I entered only one password, when I use this password in toad with user SYSDBA and the oracledatabase orcl it works,but when using sqlplus I got the error :

ora-01017 invalid username password in sqlplus

thanks,
I am your newbie student.

Just copy and paste output of below command :

How many databases you have on this machine? If more than one, then please set oracle_sid as below :
Or As Aman has given you idea; just use system/your_system_user_password when it ask Enter user-name.

Post the output of above text from your command prompt and paste it between [code /code] tages.

Edited by: Girish Sharma on Jun 19, 2010 9:18 AM

user : system
paswwor : the password I put when installation.

I got the connection :

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

thanks,your help is appreciated.

user8692160 wrote:
Now when I used :

user : system
paswwor : the password I put when installation.

I got the connection :

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

The very first thing that you should do is that you should change the password to something that you are typing now. Please note that the passwords from 11g are case-SenSitiVe!

You can change the password of Sys user like this while being connected with System, As a Java developer, you are not supposed to work as Sys or System. You should make a new user in which you are going to work into. You can make your own user like this, Here, I have made a new user with the name called MYUSER having the same password who is going to have the DBA role. Like this, you can make a new user in which you are going to work.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *