WOT: ODBC Question, with SQL Server |
|
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. |
|
WOT: ODBC Question, with SQL Server |
richardL |
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. |
richardL |
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 |
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 |
||
Lo-Fi Version | Time is now: 21st September 2024 - 06:46 PM |
All rights reserved 914World.com © since 2002 |
914World.com is the fastest growing online 914 community! We have it all, classifieds, events, forums, vendors, parts, autocross, racing, technical articles, events calendar, newsletter, restoration, gallery, archives, history and more for your Porsche 914 ... |