Home  |  Forums  |  914 Info  |  Blogs
 
914World.com - The fastest growing online 914 community!
 
Porsche, and the Porsche crest are registered trademarks of Dr. Ing. h.c. F. Porsche AG. This site is not affiliated with Porsche in any way.
Its only purpose is to provide an online forum for car enthusiasts. All other trademarks are property of their respective owners.
 

Welcome Guest ( Log In | Register )

> WOT: ODBC Question, with SQL Server
richardL
post Feb 6 2006, 06:07 PM
Post #1


Senior Member
***

Group: Members
Posts: 713
Joined: 27-January 03
From: San Diego, CA
Member No.: 201
Region Association: None



I'm hoping someone here has an answer to this, its driving me crazy.

I have a client using an ODBC connection (on XP Pro), to connect to a SQL Server database. Its set to use NT authentication.

You can create the ODBC Datasource, select the appropriate database on the appropriate server and test the connection - all is fine.

However, when you check it is actually connected to the another database on that Server, apparently the one defined as the defualt for that server.

For instance I created a connection pointing at the standard Northwind database, then I opened Access, linked to an ODBC datasource, selected my new datasource and instead of being offered a list of the tables in Northwind, I was offered a list of the tables in the other default database (not master).

I eventually got it to work as I expected, by logging off of the domain account and doing a login as the adminstrator for the local machine. In that account, the DSN worked as expected.

I have never seen a DSN with NT authentication simply provide access to another database - it should tell me I don't have access rights to the database selected or whatever.

In this case the default database is the clients main live production system, so it appears to be a glaring security risk.

Anybody know why this might happen, or even how to make it happen/stop?

Thanks.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
 
Reply to this topicStart new topic
Replies
richardL
post Feb 7 2006, 03:55 PM
Post #2


Senior Member
***

Group: Members
Posts: 713
Joined: 27-January 03
From: San Diego, CA
Member No.: 201
Region Association: None



QUOTE (SirAndy @ Feb 7 2006, 10:07 AM)
there lies the problem. when you use NT Security, your LOCAL (or domain) credentials are used to connect to the remote source.

That might well be part of the problem - although the user certainly has full rights on the original desired database. However, it is NEVER correct behavior, whether the user has rights or not, to actually substitute another database, to which the user DOES NOT have rights - that is absolutely wrong and should never happen.

In this case it means that anybody, regardless of their rights to access any database, can create a DSN and gain access to a restricted database by default - a huge security hole. If someone does not have access rights they should be refused the connection request, not 'well that didn't work, but have this one instead!'

In this case using domain credentials is completely appropriate since its nothing to do with the web, its local domain users connecting with an internal accounting application within one building. The domain users should be able to access the application, but since the admin login for one specific machine (not the domain administrator) is never used normally, it is invalid that the admin should have rights - and they don't on the SQL Server user list - so thats a bit screwed up also.

Richard
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



- Lo-Fi Version Time is now: 15th June 2024 - 05:14 PM