Secure (hide) Connection String Credentials (detais) in Access Vba - vba

We have several applications in Access/VBA (2013, 64 bits) and the data is stored locally and we want to start saving the data in SQL Server over the network, but connection credentials are visible inside Access and over the network when using ADO.
We only have one password to access the sqlserver (ex. user: s1234, pass: 12345)
I found this post -> How to securely store Connection String details in VBA here in stack overflow, but I easily decompiled the dll generated as described in that thread using .NET Reflector 9.0 and I was able to see the credentials in clear text (it doesn't fit as a secure solution to our problem).
Is there a solution to this using Access or how can I hide (encrypt) these credentials using only access or using a DLL. Is there a solution to this?
Other resources I looked:
http://www.dotnetspark.com/links/2849-protect-it-safeguard-database-connection.aspx
http://social.technet.microsoft.com/wiki/contents/articles/243.security-developer-resources.aspx
How to Hide connection string in windows forms application
Thanks!

I publish my Access applications as .accde, which conceals the source code. Other than that, I'm not so sure there is a surefire way to encrypt your connection strings. If security is a major concern with you Access database, it might be worth looking into setting Windows authentication on your SQL server or migrating your application to a web-based application in something like C#.net

Related

Connection to access database fails after authentication

Using classic ASP on Windows 7pro or Windows 8.1pro, I connect to a Microsoft Access 2003 database with the connection string "Provider=Microsoft.Jet.OLEDB.4.0;Persist Security Info=False;Data Source=D:\INetPub\KN2014\Databases".
This works fine until I call for user authentication with the code:
sAccount=Request.ServerVariables("LOGON_USER")'NT challenge
if sAccount="" then
Response.Status="401 Unauthorized"
Response.End
end if
The authentication is forced on a different page. If I do this in the same window and then return to the page which connects to the database a 80004005: Unspecified error occurs. Only resolution is to close the window and reopen it. If I manually open a second window (same sessionID!) I get the same problem in the second window. The first keeps working fine, even after a refresh.
I've tried to open that second window with program code, but then I get the error in the first window also.
Searching this site, I have done the trick granting read access on sysWOW64/inetsrv. Also: If I do a clean install for Windows 7, it works fine for a while than "Something happens" (maybe installing VS of Office) and the old problem occurs again. Tricks like using basic authentication, using Kerberos or changing the order of authentication protocols seem to have no effect.
I'm an "old school" developer. I hope someone can help me by providing the most simple classic ASP code to do authenticate using windows verification and read/write access to a Microsoft access db.
With Access you need to make sure that your database working in multi-user mode (available on 2010 and later) and you need to detect when user leave your page to close connection to Access upon exiting/closing your site/page.
That is a curse of Access since earliest versions of it.
Or make sure that you open database without locks. IN SQL server that could be achived by executing following upon opening your SQl statement:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
But I am not sure if this even possible in Access, better option just to switch to SQL Express.

Visual Basic Sql Connection String using Windows Authentication Remote Access

There is a long back story to this, but to summarize I am trying to create a SQL Server connection in my VB program to automatically run some queries and display results. I have been able to do this easily when the server is on my network in the past. Now my company is moving to a hosted server and I am running into issues.
I can successfully connect to the server using SSMS when I use the RUNAS command:
runas /netonly /user:[network domain]\[username] "C:\Program Files (x86)\Microsoft SQLServer\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
But I can't figure out how to set the VB program SQL connection string in similar fashion.
I know I can use Integrated Security = SSPI to specify Windows Authentication, but I need to pass the username and password as well, along with the network/domain information.
When I try to do this I get a "Login Failed for User..." message or "The Login is from an untrusted domain and cannot be used with Windows authentication" with Integrated Security=SSPI.
There is something about Windows Impersonation but I haven't been able to get a grip on how it would work here.
If this is possible the changes need to be almost entirely on my end, as the hosting company is very ...picky... about making any changes to their environments or settings.
I appeal to the wisdom of the internet for answers!
Extra Facts:
SQL Server 2008, Windows 7, Microsoft Visual Studio 2013, Windows Form Program
There is a good knowledge base article about that for ASP.NET, but I think the code solution also works on other platforms:
Dim impersonationContext As System.Security.Principal.WindowsImpersonationContext
Dim currentWindowsIdentity As System.Security.Principal.WindowsIdentity
currentWindowsIdentity = CType(User.Identity, System.Security.Principal.WindowsIdentity)
impersonationContext = currentWindowsIdentity.Impersonate()
'Insert your code that runs under the security context of the authenticating user here.
impersonationContext.Undo()
Inside, you can run you connection with SSPI defined as you normally would.

How to build vb.net application so that database is easily connected when published?

I've made VB.NET application in VS2010 that uses a 2007 Access database, called MenuDB.mdb. During development, everything was fine.
Now that I'm publishing it, I'm getting weird errors because for some reason the app isn't connecting to the database.
I install the application and run it but as soon as it opens it gives this error:
System.Data.OleDb.OleDbException (0x80004005): Could not find file
'C:\Users\Administrator\AppData\Local\Apps\2.0\Data\OV86PXJA.K3R\8575R5AY.95Z\menu..tion_0d4fa454d69e8e6b_0001.0000_8340d263807cbb71\Data\MenuDB.accdb'.
I know the problem has to do with the way I'm relating the application to the database, but I don't know which way is right. In Solution Explorer I changed the Build Type of MenuDB.accdb to "Content" (earlier it was embedded resource". But it doesn't work either way. In my App.config I have the following connection string:
connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\MenuDB.accdb"
I want that when I deploy the application, the database should just sit in the application folder, wherever it gets installed. How can I do that?
Edit
I don't mind deploying it in such a way that I need to paste the database somewhere myself on the target machine - as long as it works.
If you have multiple users using the same or similar database, and dont have access to a SQL server (MySQL, MSSQL, or others), then co-locate the database at a central location (preferably network location) that all the users will have access to and change the connection string to accomidate the database location being on the network.
Just let it be known, Access can handle up to 10users when doing simple data retrieval/submission but if you ever have it open while others are accessing via data objects, then you may lock them out.

Permissions issues with SQL 2008, Report Builder 2.0

So here's a bit of context for the horror story:
Win 2003 SP2 64bit running on a VM exposed to outside world for web access.
SQL Server 2008 Std SP2 64bit with Reporting Services (RS) installed for native mode (i.e. not sharepoint mode).
IIS 6 .NET 3.5 web site app written to use the web services from RS. The site has been set to use Windows Authentication and nothing else.
To save writting custom authentication since I don't need it for this demo I have set-up a local account in Win 2003, i.e. servername\myDemoUser, effectively allow fake Windows Authentication.
Default.aspx lists folders on RS and the reports from each folder. It also has a link to the Report Builder 2 on the server.
The rsreportserver.config has been changed so that the only <AuthenticationType> is <RSWindowsNTLM> since <RSWindowsNegoiate> can't work since it's across the internet and users will not be on the same network (hence the local account myDemoUser).
The web site app has url of the form: http://mysite.mydomain.co.uk/ and the link on it to the Report Builder is of the form: http://mysite.mydomain.co.uk/services/reportbuilder/reportbuilder_2_0_0_0.application, in this case RS has been configured so the Web services virtual directory is "services".
The web.config for the website app has been set to <identity impersonate="true /> for <locations> for the ASPX pages that access the RS webservice. I even added a <location path="services/reportbuilder"> with the same thing and also to allow anonymous users.
So after all the above I go to the site from a machine that isn't on the network, I get prompted by IE8 for username/password and I enter servername\myDemoUser and the correct password. The homepage is displayed and correctly shows the list of folders and reports from RS. HOWEVER if I click the RS report builder link I get the pop window saying it's doing it's clickonce verfication stuff but after a couple of seconds it shows simple message box saying there was an authentication error. The details button then shows a text file with a bunch of stacktrace stuff in which eventually says that the server returned 401 while accessing the .application file mentioned above.
I turned on failure auditing for logins on the Win 2003 VM and I can see that when the clickonce fails it is trying to use the local machine account I logged into on the external (to my network) machine instead of the credentials I entered into the browser on that machine when testing it.
Much Googling and granting of permissions to Network service, everyone etc... on various folders involved later nothing the Report Builder bit just won't install via clickonce due to permissions or the incorrect use there of.
I'm looking into maybe changing something in the RS to try and grant permissions to the report builder to anonymous but at this point I'm pretty pessimistic that I'll actually find anything. The annoying thing about this is that this a test that doesn't represent the final thing (we'll be using custom authentication in RS) but unfortunately I have to do it, 8(.
Any ideas would be most appreciated.
It turns out that when using fake Windows authentication in this way when the machine you are accessing the site from a machine where you have not logged into the domain then clickOnce won't work because it won't pass the details you enter into the browser as found.
So the solution is to:
1) Log into a (any) domain on the machine that is going to access the clickonce link on your site.
2) In Control Panel go to User Accounts (XP)/Store Users and Passwords (Win 2003), and manage the network passwords for a user (XP) and add in the URL, username and password.
Whenever clickonce fires up for this URL it will pass the username/password specified as opposed to the local machine account.
Either of the above will solve this problem.

Why Oh Why won't VB.NET connect to this database?

First off, I can connect to both databases with SQL Server Enterprise Manager, so I know the servers are up and available. One of them is SQL1, the other is SQLTEST.
In my program when I use the following connection string, it work connects just fine:
conn = New DBConnect("Data Source=SQL1;Initial Catalog=SignInspection;Integrated Security=SSPI")
However, if I change SQL1 to SQLTEST the connection times out I don't get any errors other than the timeout error.
I can run the profiler on SQLTest and see that it is most definitely NOT even attempting to connect. Nothing happens at all, not a peep, nor hellow.
Any ideas? Thanks
EDIT:
Well, it's a moot point now because I got authentication working properly on our SQL1 server.
I'll post the configuration here so perhaps someone else can benefit.
First off, the web server is running IIS and .NET. Users are logged in to the intranet using Active Directory, and the .NET page needs to retrieve their log-in credentials (username most notably). The database is SQL Server 2005, running on a different machine. But the .NET app needs to impersonate as another user to connect to the database.
To successfully do both of these things go to Windows > Run, enter inetmgr and hit run. Navigate to the site and right click > properties, then click on the tab titled Directory Security, click Edit.., make sure only Integrated Windows Authentication and Digest authentication are enabled. Enter your proper AD realm and click OK. Apply the settings/hit OK.
In web.config you need the following lines
<authentication mode="Windows" />
<identity impersonate="true" username="myDomain\MyUserName" password="123mypasswordgoeshere">
replacing, of course, myDomain\MyUserName and 123mypasswordgoeshere with the username and password that has login rights on both your domain and your sql server. The connection string can probably be modified, but this is mine and it works:
Server=SQL1;Database=SignInspection;Trusted_connection=True;
These are the steps that worked for me and hopefully they'll be of use to someone else.
When you connected with the enterprise manager, was that from the same machine as you're running the VB.Net code on?
Otherwise, it can be quite a few things, ranging from firewall or DNS as mdma mentions to being setup with the wrong network protocol or maybe not accepting remote connections.
This article contains a list of things to look at (it's for SQL 2000 but it's something to get you started at least).
The obvious question - does SQLTEST have a database called "SignInspection"? Also do you log on to SQLTEST via SQL Management Studio using Windows Authentication or SQL Authentication? I would expect if either of these were the problem you would get an exception, but its worth checking.