User cannot access a system DSN on Windows Server 2008

Question

We run our SQL Server services using a low privileged domain account. That account is NOT a local admin on the OS. Only access I give the user account is assigned during install of SQL: full control over its mount points and then everything else is granted by the SQL Server 2005/2008 installer.

I need to create a linked server in SQL Server 2008 to an ODBC data source. So I remoted into the computer using my domain account, which is part of a group that DOES have local admin privs to the OS. I created a system DSN and configured it to connect to another SQL Server. The DSN works perfectly when I test it. However, when I try to create the linked server, I get an error.

It appears to me that the DSN is invisible to the domain account that SQL Server is running as. It seems that this problem is only happening to me on Windows 2008 servers. Does anybody know whether there's anything that you need to do after creating a DSN to make it visible for other users to access?

Solution

You have to explicitly add the user's Windows login (or just DOMAIN\Domain Users if using AD) to SQL as a DBO of each relevant DB. Through Win2K3 server, a DSN-only SQL login was all that was needed, but as of Win2K8, the DSN-only SQL login alone is not enough. Once I added the Windows login for a given (restricted) user (actually DOMAIN\Domain Users in my case - they are all restricted users) to my SQL server, each user could then use the DSN (setup with its own, separate login) as had always been the case before... What a major PITA this was - thanks for the lack of any note, Microshaft!!!!

Comments

[squillman]

My first question would be, what kind of data source do you have that you have to go through a system DSN for a linked server?

[ColonelPackage]

I see where you're going with your question, squillman. However, this same scenario comes into play when trying to execute an SSIS package the references a system DSN. It's not really a problem with creating a linked server itself. Rather, the problem is that the SQL Server logon account can't access the DSN.. :-/

[Nissan Fan]

Have you created a System DSN instead of a User DSN?

[Alex]

Did you test the DSN entry to make sure it's working?

[ColonelPackage]

Hi, Saif. I did test the DSN with the account that I used to create it. No problems there. Is just the account that SQL Server is running as that I'm having problems with...

[Admin]

SAME HERE! Googling got me this and one or two other unanswered posts, but NO ONE has ANY answers. When we first setup the Win2K8 server with MSSQL, we had this issue, but we had also just migrated and after we ran commands in the Query Analyzer to reconnect the logins and users for the DBs to match the new domain, it seemed to worked fine, so I chalked it up to bad login/user settings after migration, or so I thought... However, the 08/09/2011 updates came and we rebooted the server and now this same maddening issue has come back. Running those same commands NO LONGER WORKS.

[ColonelPackage]

That sounds like an interesting proposal @Zoredache. But I'm not sure what a UAC is or whether that is my job function. Will have to research that. Can you give me more insight?

[Zoredache]

UAC is a thing on Windows Vista/7/2008 that tries to protect users from doing stupid things... It has some unpleasant side-effects when it is enabled. See (en.wikipedia.org/wiki/User_Account_Control).

[Nick Kavadias]

can you please link to your source you found on google that explains this behavior is caused by the UAC :)

[ColonelPackage]

I had our Windows admin turn off UAC on this server. That did not seem to help at all. Any other ideas?