February 26, 2009 at 10:42 pm
We are implementing a third party app that is supposed to use only sql authentication, because all of the business rules are linked to sql logins. The ODBC DSN is setup to use sql auth. The server is set up for mixed auth and we can log onto management studio with the sql users. However, by monitoring sql profiler, we can see that the app is actually using Windows auth. Every single connection to the database shows the domain user name of the user logged into the workstation, no matter what sql user they enter into the login window.
The vendor is stumped and says there is no way the app is setting up the connection that way.
I have been scouring MS support and this site to see if there is a group policy or registry setting that could override the DSN or connection string settings and fall back to Windows authentication, but I've had no luck.
Has anyone ever seen this before? It doesn't make any sense to me and I've been administering sql server for 10 years.
Thanks,
Steve
February 28, 2009 at 9:47 pm
If you get rid of the ODBC DSN, does it still try to connect to SQL Server? If so, then it's making a direct connection using information stored in the registry, in a .config file, in a .ini file or something. That would be the first thing I would try.
K. Brian Kelley
@kbriankelley
March 1, 2009 at 9:13 am
I just solved it last night, but hadn't had a chance to update this thread. It was indeed an .ini file that they forgot to check. It has the initial connection string in it. The app makes one connection to the DB with this connection string, then loads the user's business rules to use for subsequent connections. The config file had "trusted_connection=yes" in it and it should have had "uid=xxxxxxx". I found it by doing a filemon when the application was launching.
Thanks for the reply.
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy