WOT: ODBC Question, with SQL Server Options

[richardL]

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]

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