I have Oracle SQL Developer version 4.1.19 (64 bit) with JDK8 included.
This is working for Oracle connections which require a {username, password} combination - no problem there.
My issue is that I cannot connect with an OS Authentication configuration.
Please note that I can connect from the command line with OS authentication by using sqlplus /#MY_TNS_NAME and this works fine.
I have the SQL Developer application configured to use the OCI/Thick driver and also to use the x64 12.1.0.2.0 basic instant client. This seems to be configured ok in that if I check Help->About-Properties then sqldeveloper.oci.available has the value "true".
However, each time that I test the connection I receive the failure message
"ORA-01017: invalid username/password; logon denied"
My OS is Windows 7 Enterprise x64 SP1
I have obviously checked the option "OS Authentication" :).
Is there any other configuration that I need to change/check in order to get SQL Developer to allow me to connect via OS Authentication? (Changing the authentication type is not an option for me).
Thanks in advance.
Had the same issue. The cause is that SQL Developer's lightweight JDBC does not support extended authentication. SQL*Plus, to the contrary, is compiled against native driver, that's why it has no problem.
Solution: in SQL Developer, go
Tools -> Preferences -> Database -> Advanced Parameters
If you have Use Oracle Client already checked, just check Use OCI/Thick driver. That's all. If not, check Use Oracle Client first, and specify driver path. Idea was taken from here
Speaking about clients, Oracle allows to have a zoo of versions. If you have problems selecting working client, the cleanest option would be to use path where your SQL*Plus resides. Just strip \bin from its end, and make sure its CPU architecture matches SQL Developer.
Oracle Sql developer and sqlplus work with OS authentication in absolutely different ways.
Sql developer always tries to authorize by substituting to the user name "\".
SLQPLUS substitutes only the user name. When adding a domain to the user name.
OSAUTH_PREFIX_DOMAIN = TRUE (windows registry). Sqlplus appends the domain name to the name.
Sql developer always tries to authorize by substituting to the user name "\" without domain name.
Example 1.
CREATE USER "OPS$ORACLE.ADMIN" IDENTIFIED EXTERNALLY
PROFILE DEFAULT
DEFAULT TABLESPACE tablespace_oracle_admin
TEMPORARY TABLESPACE TEMP
QUOTA UNLIMITED ON tablespace_oracle_admin
ACCOUNT UNLOCK ;
C:\ORA\DB\product\11.2.0\dbhome_1\bin\sqlplus /
SQL> Select user from dual;
USER
___________________
OPS$ORACLE.ADMIN
To connect from sql developer with the database, it is necessary to put the "/" symbol instead of the
user name without specifying a password.
Select user from dual;
USER
___________________
OPS$ORACLE.ADMIN
Example 2.
CREATE USER "OPS$\ORACLE.ADMIN" IDENTIFIED EXTERNALLY
PROFILE DEFAULT
DEFAULT TABLESPACE tablespace_oracle_admin
TEMPORARY TABLESPACE TEMP
QUOTA UNLIMITED ON tablespace_oracle_admin
ACCOUNT UNLOCK ;
When connecting to using Sql developer, OS authentication work!!!!
Select user from dual;
USER
___________________
OPS$\ORACLE.ADMIN
Where are your Sqlnet.ora and tnsNames.ora files located?
I had to create an environment variable TNS_ADMIN with a custom location that contained my sqlnet.ora and tnsnames.ora files.
Make sure your sqlnet.ora file contains the line:
SQLNET.AUTHENTICATION_SERVICES = (NTS)
You also need to ensure that the instant client location e.g. c:/instantclient12 is the first entry in your PATH variable.
What happens when you press the test button when setting the Oracle client location in sql developer?
Related
I'm trying to create a login on our test server with:
CREATE LOGIN [<DOMAIN>\<LOGIN>] FROM WINDOWS;
GO
As opposed to the live server the test server does not have any active directory. So it fails with:
Windows NT user or group 'DOMAIN\LOGIN' not found. Check the name again.
Worth to be mentioned, that on the test server we use a backup of a database dump from the last release and apply new migrations to this dump. This means, that this error would not occur, if a more recent dump from the live server was used, where the active directory login already exists.
To enable proper testing, we discussed three possible options:
Recreate the active directory on the test server: I would like to avoid this, because nobody really wants to administer an additional active directory clone for testing purposes.
Use a more recent database dump: The problem here is, that the live server is not ours and we only have restricted access to it. It is possible, but still not the optimal solution in regard to practicability. Also, it would mean, that we would play in migrations to the live server before having tested them on the test server.
Alternative SQL syntax: I am aware, that there alternative ways of creating logins, e.g., CREATE LOGIN <login_name> WITH PASSWORD. But I could not think of any way, which allows us to create logins depending on which system we are on.
Option 3 is our strong favorite, but we are missing a piece to the puzzle. Anything we are missing here?
You can create a new user on your local computer.
And then add this new user to the instance.
CREATE LOGIN [<domainName or your hostName>\<login_name>] FROM WINDOWS;
I'm in the process of setting up a new laptop for application development work and today I installed SQL Server 2017 Developer Edition on this computer. I used the Basic install option rather than the Customize install option. Some pertinent facts:
operating system is Windows 10
device name is MARIGOLD
administrator on this computer is an e-mail address and the characters that appear before the # symbol for the e-mail are knot22
When the confirmation screen was displayed after installing SQL Server, it showed the SQL Administrator as MARIGOLD\knot2 (see red line that points this out in screenshot). Notice that there is a 2 missing - was was expected was MARIGOLD\knot22. Why did it chop off the user name? Is there a way to fix this?
Your username on the computer is "knot2".
This may not match the display name.
The following procedure will lose all stored credentials. You may lose program data, bookmarks contact lists... as well as some file permissions
The easiest way to solve this is to:
Create a temporary admin account, Grant the account all privileges in SQL Server.
Login as that user.
Backup the entire C:\users\knot2 directory(including hidden and system files). You may have to reboot to do this.
Delete the "knot2" user.
Create "knot22" user.
Grant the "knot22" account all privileges in SQL Server.
Copy the backup of C:\users\knot2 into C:\users\knot22
Remove or disable the temporary user.
It is up to you to figure out if it is worth it or not.
I have WebLogic 11G (10.3.6) on Linux Server and SQL Server 2012 on Windows 2012. I would like to create the connection pool to SQL Server from WebLogic using Windows Active Directory Kerberos authentication.
I am looking for steps to accomplish the above. I found information in bits and pieces but looking for clear steps. Any help is greatly appreciated.
I have access to WebLogic 10.3.3. So all version numbers are according to that. But the principals are the same.
Login through the console
Lock and Edit. If this isn't a production mode server, you won't need to do this.
Go to Services > JDBC > Data Sources and click "New".
Give it a name and JNDI name. I probably don't need to mention that the JNDI name is the important one. Also, choose the "Database Type" as "MS SQL Server".
Next you'll have to choose the driver. I didn't observe anything about distribute transactions in your question. Thus, I'm assuming you won't need an "XA" driver.
Again, I didn't see anything about Global Transactions in your quesiotn. So in the next step, disable it.
Next is the information about your Database; its name, Host's IP, and Port. If you have a named instance, add the name after the IP like this: \\instance_name. Since you want to use Kerberos, don't enter the Username and Password.
In the next step, you need to tell your datasource to use kerberos. Add ";AuthenticationMethod=kerberos" to end of the URL field. Connection properties are separated with a ";". For example, jdbc:sqlserver://192.168.10.56:17888;AuthenticationMethod=kerberos
Next, specify which Servers in your Domain will have access to this DataSource. Basically, specifying the DataSource's target servers.
Side notes and other important settings:
When you specify the "AuthenticationMethod" connection property with the value of "kerberos", any username or password will be ignored.
Your database server must be administered by the same Domain Controller that administers the Weblogic server.
Under $WL_HOME/server/lib find krb5.conf (Kerberos configuration file containing values for the Kerberos realm and the KDC name for that realm) and open it in a text editor. Specify the system properties java.security.krb5.realm and java.security.krb5.kdc. In Windows Active Directory, the Kerberos realm name is the Windows domain name and the KDC name is the Windows domain controller name.
The application and driver code bases must be granted security permissions in the security policy file of the Java 2 Platform. Something like this:
grant codeBase "file:/WL_HOME/server/lib/-" {
permission javax.security.auth.AuthPermission
"createLoginContext.DDTEK-JDBC";
permission javax.security.auth.AuthPermission "doAs"
permission javax.security.auth.kerberos.ServicePermission
"krbtgt/your_realm#your_realm", "initiate";
permission javax.security.auth.kerberos.ServicePermission
"MSSQLSvc/db_hostname:SQLServer_port#your_realm", "initiate";
};
where:
WL_HOME is the directory in which you installed WebLogic Server.
your_realm is the Kerberos realm (or Windows Domain) to which the database host machine belongs.
db_hostname is the host name of the machine running the database.
SQLServer_port is the TCP/IP port on which the Microsoft SQL Server instance is listening.
I must say though I don't think you searched hard enough. Because almost everything I wrote here came from the online documentation:
http://docs.oracle.com/cd/E12839_01/web.1111/e13753/mssqlserver.htm
I am new to Oracle. I did a fresh installation of Windows 7 x64 on my laptop to install Oracle 12c Enterprise Edition (for learning purpose).
While on admin windows account, I first made a standard windows user with a password to use during the installation. The installation went fine as well as the creation of default ORCL database. The only warning I got was "The selected Oracle home is outside of Oracle base" which I fixed by going back to directories option and setting the directory from "Admin Name" to "Oracle" and it adjusted all directories according to "Oracle" name (I found this solution on internet).
Now after system restart, I am trying to connect to ORCL database using username and password I defined in setup and it just keeps telling me that my logon is incorrect "ora-01017 invalid username/password logon denied" whether I use SQL Developer or SQL Plus command line ?
I have tried searching on internet and didn't find anything much useful or say it's too technical that I don't understand, can anyone explain in simple way that what should I do to make this thing work ?
Thank you and sorry if I sound frustrated, I did this installation twice on Windows 8 which led to errors in my OS then switched Windows 7 and now this third installation is also leading to this error.
Open SQL Plus and type this "Sys as SYSDBA" for username and don't type any password and it will automatically connected.
Enter user-name: Sys as SYSDBA
Enter password: (don't need)
Screenshot
http://i.stack.imgur.com/E4seR.png
remember password is case-sensitive by default, maybe this could be your problem.
in oracle 11g and 12c this parameter is case-sensitive., so check your password and write it as you created.
try to login with a user that have CONNECT grant. sys or system should work.
I can relate since I went through the same thing recently. Under Windows 10 (2020).
In my case, I use Spanish language computers, and by default, Oracle 12c for Windows expects an ENGLISH language character set or whatever.
SOLUTION: Go to Windows Regional Settings and select English as the default "regional format". In my case I went with "Spanish (United States)". Then restarted SQL Developer and BOOM: No more cryptic "ora-01017" errors!
GOOD PRACTICE: I only added "SYS" as SYSDBA to connect for the first time (since I have no other users YET). From the much-expected SQL Developer's Worksheet (SYS as SYSDBA) I created a "normal" user. Then, I created a "default (normal)" connection profile for that new user and started doing DDLs from that connection.
It works flawlessly from there. Hope it helps in your case!
I have an issue with logging a Support user into an Application that has a SQL Server backend.
When configuring the application itself, the SQL set-up asked me to assign whether the Security to access the Application would be Windows Authentication or SQL: server Authentication, I chose Windows Authentication, and as I was using a login called
'LabUser1' I have been able to login to the application fine.
However, when I logon to the server using a different windows login, this time 'Support', SQL keeps giving me the error:
Error accessing the database DSN
Now I know the reason is because the install of SQL happened using the 'Labuser1' profile, but how can I create a script that will allow me to add the 'Support' user to the 'Allowed Logins' so that I can logon to the app server and at least open the Application? (I have seperate logins for when I see the applicatiojn login window, so please don't confuse the matter by thinking it is a simple case of creating a login for Support....I am talking about logging into the server)
The current batch file I am trying to run is:
sqlcmd -S localhost\OCDBB01 -i createSupportlogin.sql
Then I run this batch file after having created the following SQL script:
CREATE LOGIN OCDMW1\Support FROM WINDOWS
GO
Your description of the situation is a bit confusing to me however it appears that the "SQL setup" that is part of the application configuration created a ODBC DSN that uses the credentials of person logging into the machine as the login for SQL Server.
Simply creating a new (correct) login to the SQL instance may not resolve this issue since that does nothing to modify the DSN. If you are tied to using Window Authentication for SQL access it might be necessary to create multiple DSNs for the application to use and find a way to have the correct DSN associated to the right login for the application to use.