I have problem logging in to one of the accounts in our database. The situation is like this.
The user has already logged in to his account environment on Linux, for example from his personal account
su - projectA
The user tries to run SQL*Plus using
[projectA#myDB2]$ sqlplus /
We are getting the message:
ORA-01017: invalid username/password: logon denied
I ran this command below and it has a missing prefix.
SQL> SHOW PARAMETER os_authent_prefix
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
os_authent_prefix string
SQL>
How do I set a prefix on os_authent_prefix?
You're allowed to have no value set for OS_AUTHENT_PREFIX, but if you do then the database account needs to be the same as the operating system account - i.e. projectA instead of OPS$projectA.
If you do want the account to have the OPS$ prefix then the initialisation parameter has to match. You can set it as #kfinity said in a comment:
alter system set OS_AUTHENT_PREFIX='OPS$' scope=spfile;
followed by a DB bounce. But as that is the default value (still, I think!) it's likely someone has intentionally cleared it, so proceed with caution.
The main thing is to be consistent. If you have other user accounts with OPS$ then you probably should have it set (and you can check the old DB you mentioned to see if the users and settings are the same). If you don't have any others then you need to verify whether any of the un-prefixed account names are identified externally via the dba_users.authentication_type column. If there are any then changing the initialisation parameter would break those.
Read more in the documentation:
Related
My organisation has a number of schemas within an Oracle database that need to be accessed by a number of individual developers. In most cases, the developers can login with their own id and access these other schemas through role permissions, but for certain tasks the individual developers need to log into these schemas directly.
An example of this would be schema A which needs to be accessed by users X and Y. User X and user Y can log in with their own ids, but to fully leverage the potential of schema A, they would need the schema A password.
I am interested in tracking if and when user Y for example logs into schema A, using the schema A password. Can this be done?
My need for this is primarily in relation to password security and leaving procedures when staff depart our organisation. For example, if I have schema A and the password is known by at least some of users X, Y, Z and Q, and user Q leaves, is this a threast? If the checks show the password for schema A was not known by user Q, then I don't have a security risk, but if the checks show that user Q knew the password for schema A, then I need to change the password for schema A, potentially impacting users X, Y and Z.
Therefore, my question is, is there a method within Oracle that would enable me as DBA to identify which individuals logged into these schemas, whether it be by tracking their client identifiers or some other route?
Thanks
For this specific scenario, use proxy authentication: it kills several problems related to development environments in a single stroke.
[Proxy authentication] allows a user to connect to a database as one user and on connection
become a different user. This capability was originally deployed by
Oracle as a way for applications to authenticate end users to
individual database accounts through a common application account, but
it works just as effectively the other way around.
In this model ... each developer is given a separate,
personal account in the database. Most application development can now
be handled – and audited – through these personal accounts. Because
the login accounts are associated with individual users there is no
incentive for the developer to share their credentials with anyone
else. It would be relatively simple to tell if a personal account was
being shared, and doing so would be grounds for termination with most
companies.
To demonstrate this in action, I’ll create an application schema and
configure it so that it can only be accessed by means of proxy
authentication:
Connected to: Oracle Database 19c Enterprise Edition Release
19.0.0.0.0 - Production Version 19.3.0.0.0
SQL> create user app_schema no authentication proxy only connect;
User created.
SQL> grant connect, resource to app_schema;
Grant succeeded.
The “no authentication” option creates the shared
account without credentials. [This is not strictly required, but] it eliminates the need to maintain a
password or certificate for an account that will never be used
directly. The “proxy only connect” option allows only proxy
connections to the shared account. [This too is not required, but could be useful depending on your situation.] The “connect” and “resource” roles
grant basic privileges to use the account and create objects. Next, I
will create a sample development user:
SQL> create user dev_user identified by oracle;
User created.
Now the application schema can be altered to allow
connections from individual developer accounts, like this:
alter user app_owner grant connect through dev_user;
Note the syntax:
the APP_OWNER schema is altered to allow connection by or through the
DEV_USER account. This is not a privilege that is assigned directly to
the development user. Once this proxy privilege has been assigned, the
developer can connect to the application schema using their personal
credentials. All they need do is append the application account name
in brackets to the end of their development account name, like this:
SQL> connect dev_user[app_schema]/oracle
Connected.
SQL> show user;
USER is "APP_SCHEMA"
By connecting in this way, the developer can
still perform needed actions but need never be aware of the
application owner account’s real password (assuming one was even
assigned). The proxy account name (the developer’s personal account)
is available in the system session context, and can be automatically
made visible in the v$session view through a database trigger so that
the DBA can tell who is connected to shared accounts at all times.
CREATE OR REPLACE TRIGGER db_session_trig
AFTER LOGON ON DATABASE
v_proxy_user varchar2;
BEGIN
v_proxy_user := sys_context('userenv','proxy_user');
if v_proxy_user is not null then
dbms_session.set_identifier(v_proxy_user);
end if;
END;
select username, osuser, client_identifier
from v$session where username='APEX_040000';
USERNAME OSUSER CLIENT_IDENTIFIER
----------------- --------------- ----------------------
APEX_040000 oracle PETE
Using the PROXY_USERS view it is easy to
determine exactly which developers have access to each application
owner account as well.
PROXY CLIENT AUTHENTICATION FLAGS
------- -------------- -------------- -----------------------------------
PETE APEX_040000 NO PROXY MAY ACTIVATE ALL CLIENT ROLES
Because even basic auditing
captures the OS username of the developer, the audit trail will record
the actual developer behind DDL operations executed as the application
owner.
Sep 4 10:04:07 testdb Oracle Audit: SESSIONID: "12345" ENTRYID: "1"
STATEMENT: "6" USERID: "APP_SCHEMA" USERHOST: "myserver" TERMINAL:
"pts/2" ACTION: "7" RETURNCODE: "0" OBJ$CREATOR: "APP_SCHEMA"
OBJ$NAME: "TEST_TABLE" SES$TID "4567" OS$USERID: "PETE"
Using
individual developer user accounts with proxy account access to
application schemas, it is possible to allow developers to work in
shared accounts while still maintaining account credential security,
visibility of connected users, and an accurate audit history.
Full article here: https://pmdba.wordpress.com/2021/10/15/shared-application-accounts-revisited/
You could use proxy users for this. That way there is no need to share a password and regular auditing can do its job.
An other option could be to define packages in the other schemas that can be called by the developers. The packages need to be defined with definers rights so when a dev calls the package, the execution is done using the privileges that are directly granted to the schema. Doing so avoids nasty ‘any’ privileges.
I am trying to create a new user from Oracle SQL Developer. I made a connection with the user Sys and the password that I entered in the installation of Oracle Database XE 18c.
When creating the user I get the error ORA-65096, I have searched the internet and the solution I found is to write the following:
alter session set "_ORACLE_SCRIPT" = true;
However, I want to know if it is possible to create the new user without using any SQL statement or script and do it from the Oracle SQL Developer interface, do I have to login with a different user than Sys to create a new user? or what do I have to do? Could someone give me a detailed explanation please. I am learning how to use this database and I want to try to understand what I am doing.
oerr ora 65096
65096, 00000, "invalid common user or role name"
// *Cause: An attempt was made to create a common user or role with a name
// that was not valid for common users or roles. In addition to >the
// usual rules for user and role names, common user and role names
// must consist only of ASCII characters, and must contain the >prefix
// specified in common_user_prefix parameter.
// *Action: Specify a valid common user or role name.
This implies that you are connected to the root container instead of to a regular plug in database (pdb) where applications should be built. The solution for you is not to overrule setting to enable building an application in the root container but to connect to the pdb that has been made to host your application.
you can check the available pdb's by viewing v$pdbs. The special pdb cdb$root is as the name already tries to tell, the root container. show PDBS will give similar output.
Using alter session set container = [pdb_name]; can be used to switch to your container of choice where regular rules apply.
Even better is to directly connect to that pdb using sqlnet.
My company has a database for vehicle tracking system. And It has a website for user to log on and use.
After I change the sys and the main user password through "ALTER USER --- identified by' command. The website login became dysfunctional. Our DBA just quit so I have no idea how to troubleshoot.
Is there any guideline I can use?
It appears as though the application has the passwords either hardcoded or in a configuration file somewhere. If you can find where that is, then simply changing the corresponding values (ie passwords) should resolve the problem. If that doesn't work, you can try to change the password back to the what they were before using the same syntax you used to make the initial change ... "ALTER USER --- identified by ...
Can possibly be more help if you can tell what web server is hosting your site.
We use windows domain authentification to connect our users to Oracle. Most of the time it works fine.
But we ran into unexpected problem.
Some usernames are longer than 30 symbols. So the syntax
CREATE USER OPS$SomeVeryLongDomain/SomeVeryLongLogin IDENTIFIED EXTERNALLY
just don't work.
(os_authent_prefix has a standard value OPS$).
Is it possible to use domain authentification for usernames longer than 30 symbols?
UPD
There definitely is a workaround for Kerberos authentication.
If the user's Kerberos principal name is longer than 30 characters, and up to 1024 characters, then create the user as follows:
SQL> CREATE USER db_user_name IDENTIFIED EXTERNALLY AS 'kerberos_principal_name'
For example:
SQL> CREATE USER KRBUSER IDENTIFIED EXTERNALLY AS 'KerberosUser#EXAMPLE.COM';
But I cannot understand how to use the method for OS authentification and is it possible at all.
os_authent_prefix has a standard value OPS$
Well you can't go beyond 30 characters as that is the limit. Read External Authentication.
The os_authent_prefix parameter affects how Oracle matches a Windows username to an Oracle username when you're not using Windows group membership. Early versions of Oracle used a prefix of OPS$, which you would append to the beginning of the Oracle username used in external authentication. Because Oracle usernames are limited to 30 characters, using an OPS$ prefix effectively limited the username to the remaining 26 characters. To avoid using the OPS$ prefix, the Oracle database parameter file, the init.ora file (in the \%ORACLE_HOME%\database folder), should have the following setting (default Oracle9i and Oracle8i installations are configured to include this setting):
os_authent_prefix = ""
The parameter is provided for backward compatibility. Oracle doesn't recommend adding a prefix, thus the default empty setting is as shown. For a change to the OS_AUTHENT_PREFIX setting to take effect, you must shut down and restart the Oracle database instance.
From time to time, Oracle is changing the password for my account. My project has one database pooling for each 60 seconds and another for each 600 seconds.
I don't believe this is the cause, but it abruptlies changes the password causing my code to try to login with wrong username or password that leads to an account lock.
The password is always the same and there's no way the program is trying to connect with a different username/password than the valid ones.
ORA-28000 is not a password change, it is an account lock either by the DBA or because the wrong password has been entered more than FAILED_LOGIN_ATTEMPTS times.
I have to wonder if there isn't one chunck of code somewhere that has a hardcoded, incorrect password that is being run. That or you just get too many people mis-typeing a password in a given time span.
If you want to track failed logins to try and identify what is causing this, check this link: http://www.dba-oracle.com/t_tracking_counting_failed_logon_signon_attempts.htm
Note that, from ORacle 10.2 on, the default for FAILED_LOGIN_ATTEMPTS in profiles is 10, not the unlimited that it used to be. for the default profile, check it with:
SELECT *
FROM DBA_PROFILES
WHERE profile = 'DEFAULT' AND resource_name = 'FAILED_LOGIN_ATTEMPTS';
Bet you get 10 back, and that this is the issue. You can update to a higher value, or backl to unlimited e.g.
ALTER PROFILE default LIMIT failed_login_attempts UNLIMITED;
(I think that is the right syntax - I'm away from my DB at the moment)
Well, it turns out that it was a configuration in the company lib that I was not aware of... sorry for all the mess....