Information: We have a 3rd party application we use for production at our company. This program uses a DSN to connect up to our SQL Server 2012 database through ODBC. This application works properly under Server 2003 (MADC 2.8) however when i bring it to Server 2008 x86 (DAC 6.0) i am getting a connection failed with "Microsoft OLE DB Provider SQL Server Login failed for user XXX". I have a feeling this is due to the default of "persist security info" changing from True to False on Windows servers starting with server 2008 and greater (Change made in DAC 6.0). I do not have access to changing the connection string inside the application as it is 3rd party. as seen in this article
Question: Is there any way to change ADO.Net's behavior so that this value is defaulted to True rather than False outside of the connection string. I would like to be able to at least prove or disprove that this is the feature causing the issue.
Note: I realize this is a huge security issue tampering with this setting and we will be taking the correct precautions if it is changed to ensure the server and application are isolated.
Solution: Provided by @William below. If you are updating your SQL Server 3rd party application From Server 2003 to Server 2008+ and you are getting a connection like above where on 2003 you did not, set the password for the SQL account to blank (temporarily or in staging only, this is very dangerous to leave blank in production) to test if the application works again when a blank password is provided. If it does then the application is not setting the Persist Security Info in the connection string and the value that was defaulting to true now defaults to false. Your application may be limited to use under server 2003 and may not function properly on server 2008+. There is no way that i could find to get the value to default back to true.
If the application is using the existing connection object to construct new connection strings, then there could be a workaround for this issue - depending on the application and on security constraints.
Since this issue probably does not exist when using integrated security, we can assume "SQL Server standard security" is a requirement. If a blank password is used for the SQL server account, then, when the new connection string is constructed, it will then be correct (somewhat by accident).