Is there any way to connect to an MS SQL Server database with python on linux using Windows Domain Credentials?
I can connect perfectly fine from my windows machine using Windows Credentials, but attempting to do the same from a linux python with pyodbs + freetds + unixodbc
>>import pyodbc
>>conn = pyodbc.connect("DRIVER={FreeTDS};SERVER=servername;UID=username;PWD=password;DATABASE=dbname")
results in this error:
class 'pyodbc.Error'>: ('28000', '[28000] [unixODBC][FreeTDS][SQL Server]Login incorrect. (20014) (SQLDriverConnectW)')
I'm sure the password is written correctly, but I've tried many different combinations of username:
DOMAIN\username
DOMAIN\\username
or even
UID=username;DOMAIN=domain
to no avail. Any ideas?
As of at least March 2013, this seems to work out of the box with FreeTDS. I specified the TDS protocol version for good measure--not sure if that makes the difference:
connStr = "DRIVER={{FreeTDS}};SERVER={0};PORT=1433;TDS_Version=7.2;UID={1}\\{2};PWD={3}".format(hostname, active_directory_domain, username, password)
Integrated authentication also appears to be supported in Microsoft's official driver for linux: http://msdn.microsoft.com/en-us/library/hh568450.aspx . I'm not sure how many Linux distributions it actually works on or how much of the source is available. They explicitly mention RHEL 5 and 6 and some dependencies on the download page.
As pointed out in one of the comments, this answer is quite stale by now. I regularly and routinely use GSSAPI to authenticate from Linux to SQL Server 2008 R2 but mostly with the EasySoft ODBC manager and the (commercial) EasySoft ODBC SQL Server driver.
In early 2009, a colleague and I managed to connect to a SQL Server 2005 instance from Solaris 10 using GSSAPI (Kerberos credentials) using DBB::Perl over a FreeTDS build linked against a particular version of the MIT kerberos libraries. The trick was -- and this is a little bit difficult to believe but I have verified it by looking through the FreeTDS source code -- to specify a zero-length user_name. If the length of the user_name string is 0 then the FreeTDS code will attempt to use GSSAPI (if that support has been compiled in). I have not been able to do this via Python and pyodbc as I could not figure out a way of getting ODBC to pass down a zero-length user_name.
Here in the perl code .. there are multiple opportunities for breakage wrt configuration files such as .freetds.conf etc. I seem to recall that the principal had to be in uppercase but my notes seem to be in disagreement with that.
$serverprincipal = 'MSSQLSvc/foo.bar.yourdomain.com:1433#YOURDOMAIN.COM';
$dbh = DBI->connect("dbi:Sybase:server=THESERVERNAME;kerberos=$serverprincipal", '', '');
You will have to know how to use the setspn utility in order to get the SQL Server server to use the appropriate security principal name.
I do not have any knowledge of the kerberos side of things because our environment was set up by an out and out Kerberos guru and has fancy stuff like mutual trust set up between the AD domain that the SQL Server is running in and the Kerberos domain that my client was running in.
There is some code http://code.google.com/p/libsqljdbc-auth/ which does GSSAPI authentication from Linux to SQL Server but it is Java only. The author (who seems to know his stuff) also has contributed a similar patch to the jTDS project which works with more recent versions of Java that have GSSAPI built in.
So the pieces are all there, it is just a big tangled mess trying to get them all to work together. I found the pyodbc to unixODBC to FreeTDS odbc to TDS integration pretty hard to trace/debug. The perl stuff because it was a pretty thin wrapper on top to CT-Lib was much easier to get going.
Probably a bit too late to help you out - but I encountered the same issue. At the time of writing, the latest version of pyodbc allows me to login with windows credentials. Just leave the UID field blank in your connection string like so:
cnxn = pyodbc.connect('DRIVER={SQL Server};SERVER=myserverinstance;DATABASE=mydatabase;UID=;PWD=mypassword')
Now this is using your existing windows credentials when you're logged on... not sure how to specify any arb windows domain credentials...
I haven't done it in a while, but I remember the whole unixodbc + FreeTDS + pyodbc thing being a little tricky. However, it can be done, and once setup it's not that hard.
This website provides very good instructions:
http://www.pauldeden.com/2008/12/how-to-setup-pyodbc-to-connect-to-mssql.html (archived copy on Web Archive)
Also, in my experience pyodbc had issues compiling/running on 64 bit Linux machines. Because of that we eventually used ceODBC. ceODBC isn't quite as stable as pyodbc (encountered more unexpected bugs than in pyodbc when running in python prorgram), but it is very easy to get up and running on Linux 64 bit.
I don't believe you'll be able to log in to a windows domain account in this way. You need to set up a user in sql directly for this manner of passing credentials.
Related
I am trying to connect a Firebird database with Python. I already tried it with pyodbc:
import os
import pyodbc
server = '127.0.0.1/3050'
database = 'Databse-Name'
username = 'Username'
password = 'password'
cnxn = pyodbc.connect('DRIVER={Firebird/InterBase(r)
driver};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
cursor = cnxn.cursor()
I get this error:
OperationalError: ('08004', "[08004] [ODBC Firebird Driver]Unable to connect to data source: library 'gds32.dll' failed to load (-904) (SQLDriverConnect); [08004] [ODBC Firebird Driver]Invalid connection string attribute (0)")
I am not sure why he tries to find 'gds32.dll'. In the ODBC-Connection I used this driver C:\Program Files (x86)\assfinet ams.5\BIN\FB30\x64\fbclient.dll
I am using Firebird as a 64-bit version, so I am a bit clueless because of the 32 in 'gds32.dll'.
I am not sure, if it is the right way to try it with pyodbc. I am open for other advice.
Has anyone an idea why it is not working?
The fact the error mentions gds32.dll means it tried to load fbclient.dll, and that didn't work. Then it tried to fallback to gds32.dll. The gds32.dll is supported historically, because Firebird was forked from InterBase 22 years ago, and InterBase used the name gds32.dll for its client library. The 64-bit version is also called gds32.dll.
The problem is that, unless the C:\Program Files (x86)\assfinet ams.5\BIN\FB30\x64\ folder is explicitly on the path, or you configured the CLIENT connection property, that no library is found (or possibly it's 32-bit not 64-bit).
You need a 64-bit fbclient.dll. If that C:\Program Files (x86)\assfinet ams.5\BIN\FB30\x64\ is really a 64-bit Firebird (then C:\Program Files (x86) is the wrong location), you either need to specify the path of the 64-bit client library in the CLIENT connection property, or you can install it with - from a command prompt started as administrator - instclient i f from a Windows 64-bit Firebird installation, or do a client install using a Firebird installer. Alternatively, you can download the zipkit of a Windows 64-bit Firebird and use its fbclient.dll.
You should also consider using one of the Firebird drivers for Python, instead of using ODBC. You can choose from:
firebird-driver - uses fbclient.dll
FDB - uses fbclient.dll (deprecated and replaced by firebird-driver)
firebirdsql (aka pyfirebirdsql) - a pure Python driver (no native dependencies)
Also, I'm not sure if Gordon's advice about using SQLAlchemy is correct, but I'd recommend investigating that (though below the covers SQLAlchemy will probably use FDB or maybe firebird-driver, so you'd still need a proper 64-bit client library to load).
If you are going to use pandas with a database other than SQLite you should be using SQLAlchemy (ref: here). In your case you would use the sqlalchemy-firebird dialect.
Edit re: comment to original answer
Since we are connecting to localhost we can expect that Firebird has been installed and therefore the client tools are available (which is true for a default install). In that case, the following works on a Windows 8.1 test machine:
import pandas as pd
import sqlalchemy as sa
# note the r"" string
engine = sa.create_engine(r"firebird://SYSDBA:masterkey#localhost/C:\ProgramData\assfinet\assfinet ams.5\Individuell 2022\DB0 - Stand 2022_02-10.FDB")
df = pd.read_sql_query("SELECT * FROM my_table", engine)
although a better approach would be to build the connection URL like this
connection_url = sa.engine.URL.create(
"firebird",
username="SYSDBA",
password="masterkey",
host="localhost",
database=r"C:\ProgramData\assfinet\assfinet ams.5\Individuell 2022\DB0 - Stand 2022_02-10.FDB",
)
engine = sa.create_engine(connection_url)
I am unable to connect to our enterprise Oracle Db using python 3/cx_Oracle.
Installed are:
python 3 -32 bit
cx_Oracle
Oracle Client 12.1.0.2.0
My connection string attempt is:
import cx_Oracle
conn = cx_Oracle.connect(user='user', password='pwd', dsn='working_dsn')
My PATH variable includes the direct path to my working Oracle library (works using SQL Dev
Error message is:
cx_Oracle.DatabaseError: DPI-1050: Oracle Client library is at version 0.0 but must be at version 11.2 or higher
I have researched the Orcale installation instructions and have found no way to connect. I have previously tried with no success, had my computer reimaged and Oracle reinstalled to ensure only one version of Oracle and still no success. I need to move from R to Python and this is the last piece I need to make the switch. I am able to connect with R using JDBC driverclass/dbConnect.
If cx_Oracle wont work, is there another option for connecting to Oracle from Python3?
Any thoughts suggestions or places to look? Other connection types used?
Thanks in advance.
pip3 install cx_Oracle
first method：
db = cx_Oracle.connect('root/root#localhost: 1523/orcl')
Second method：
db = cx_Oracle.connect('root/root#localhost: 1523/orcl')
Third method
makedsn(IP/HOST, PORT, TNSNAME)
dsn = cx_Oracle.makedsn('localhost','1523','orcl')
db = cx_Oracle.connect('root','root',dsn)
The error you are getting suggests that you have an older version of the Oracle client installed on your machine. Search the directories of your PATH environment variable for OCI.DLL. If you find an older version you'll need to remove or rename it -- just be aware that whatever application put the file there will stop working!
Another possibility is to go to a command prompt and do the following
PATH=my_path_to_instant_client;%PATH%
python test_connect.py
Finally, make sure that if your Python is 32-bit, so is your instant client installation, and if your Python is 64-bit, make sure that your instant client installation is also 64-bit.
Working on a python app on Mac (Yosemite OSX 10.10) I ran into this issue:
OperationalError: (2049, "Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)")
With a bit of research it seemed that my client (that is mysql-python) is using secure auth and the user had a password encrypted in an old style, that is prior to pre-4.1.1.
As I do not have ways to handle things on the DB side I was wondering if there was a workaround or a way to deactivate secure_auth on mysql-python?
I am adapting the answer from here:
Eventually you have to tell the client who has an old-style password to change it to a new-style password. Old passwords are not secure.
Now, you are getting the error since the client has secure_auth set, but they have an old password. In order to login with the old password, the client must disable secure_auth on the client side. How exactly you do this varies by which client you're using.
Some other workarounds can be found in the MySQL documentation: Client does not support authentication protocol
I found a cure!
Or rather a workaround. From this post I decided to select slightly older version of MySQL and MySQLdb and this solved the issue.
Here is how I did it:
I had previously installed mysql_python for my python and had the brew version of mysql installed.
I deteleted all of that.
I look for a way to install MySQLdb by looking for it last stable version with the source.
I compiled them (followed the isntructions here), installed them and then I looked for a stable version of MySQL client (MySQL website is the best place for that) and install the 5.5 version which was perfectly fitting my requirements.
I made mysql to launch itself automatically and then restarted my computer (but you can just restart apache) and check that all path were correct and the right includes are in the right places (you can check that against the link above).
And now it all works fine!
Hope it helps.
I had a look at cx_Oracle but I have a couple of problems with it. First , my oracle server is on remote machine. Second I do not know on what platform my software will be deployed. All the examples I have founded
like this
http://www.len.ro/2009/08/cx_oracle-on-ubuntu-9-04-jaunty/
or
this https://stackoverflow.com/questions/592/cx-oracle-how-do-i-access-oracle-from-python
assume to have oracle server on the same machine. Is there possibility to have some static compilation so I can easily move my software from one pc to the other?
thx
Of course cx_Oracle can work with server working on other machine. But on client machines you will have to install Oracle client and configure it. I don't know if Oracle client installation can be added to installer of your application. Normally it is huge (600 MiB or so) so it is not a good idea. Then on all client machines you will have to configure Oracle client: set ORACLE_HOME, run Oracle tools to configure connection with database etc.
The only "light" solution I know is to use JDBC from Jython or Java. In this scenario you can use "thin" version of connect string that requires only some .jar libraries. Such connect string looks like:
db = DriverManager.getConnection('jdbc:oracle:thin:169.0.1.225:1521:test_db', 'user', 'passwd')
On client machines it needs ojdbc6.jar and orai18n.jar on CLASSPATH. No installation, no configuration, simple and easy.
I am attempting to connect to SQL Server running on Windows XP system from a *nix system on a local server via pymssql. However, the connection fails as shown below
db = pymssql.connect(host='192.168.1.102',user='www',password='test',database='TestDB')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "pymssql.pyx", line 457, in pymssql.connect (pymssql.c:6041)
raise InterfaceError(e[0])
pymssql.InterfaceError: Connection to the database failed for an unknown reason.
Things I've tried:
Set SQL Server and browser to run as a network server.
Setup a user 'www'. I also tested this user locally in SQL Studio.
Turned off Windows firewall (temporarily of course).
I am missing SOMETHING - I just don't know what it is. I tried all of the infinite menu options on Windows to no avail. One thing I noticed is that if the Windows Firewall is on (I setup an exception for SQL Server) python pauses a long time and then gives the error. If the firewall is off the error is instant.
Are there any logs I can look at in SQL Server?
Got it! I think the source of the problem was not giving Free TDS the attention it needs. Free TDS is apparently the driver behind pymssql and provides for connectivity to other databases - SQL Server being one of them.
The freetds.conf file is located in /usr/local/etc on my system (Mac Book Pro).
This file contains the defaults from the install. However, I had previously added a definition so that I could connect but forgot about it and unfortunately did not take notes on it.
Anyway, here is an example of what I appended to freetds.conf:
[SomeDB]
host = 192.168.1.102
port = 1219
tds version = 7.0
However, what is puzzling is that I set the port to 1219. I had it set manually to 1433 in SQL Studio. Also, I am using TDS version 0.82 so I don't know how 7.0 fits in.
Next, I tested connectivity using 'tsql' as follows:
tsql -S SomeDB -U www
I enter the password and get a command-line which allows for SQL queries.
Next, I tested connecting using pymssql as follows:
db = pymssql.connect(host='SomeDB',user='www',password='cylon',database='TestDB')
As you can see, I needed to use the host name from the freetds.conf file and NOT the IP directly. I then tested a simple query with additional python code to insure I could read from the database.
I hope this helps someone else in the future.
It looks like you've got this solved, but for anybody else from google that lands here: check to make sure mixed-mode authorization is turned on on your MS SQL Server. It defaults to only allowing Windows authorization, and that will cause this error in pymssql.
is it a windows machine u working on? specify the port 1433.
it seems to be a bug in the mssql client api, which tries to use Namedpipes instead of TCP/IP.