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.
Related
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
I have a very small test application in which I'm trying to install a Windows Service and create a LocalDB database during the install process, then connect to that LocalDB database when the Windows Service runs.
I am running into huge problems connecting to a LocalDB instance from my Windows Service.
My installation process is exactly like this:
Execute an installer .msi file which runs the msiexec process as the NT AUTHORITY\SYSTEM account.
Run a custom action to execute SqlLocalDB.exe with the following commands:
sqllocaldb.exe create MYINSTANCE
sqllocaldb.exe share MYINSTANCE MYINSTANCESHARE
sqllocaldb.exe start MYINSTANCE
Run a custom C# action using ADO.NET (System.Data.SqlConnection) to perform the following actions:
Connect to the following connection string, Data Source=(localdb)\MYINSTANCE; Integrated Security=true
CREATE DATABASE TestDB
USE TestDB
CREATE TABLE ...
Start the Windows Service before the installer finishes.
The Windows Service is installed to the LocalSystem account and so also runs as the NT AUTHORITY\SYSTEM user account.
The service attempts to connect using the same connection string used above.
I am consistently getting the following error when trying to open the connection to the above connection string from within the Windows Service:
System.Data.SqlClient.SqlException (0x80131904): A network-related or
instance-specific error occurred while establishing a connection to
SQL Server. The server was not found or was not accessible. Verify
that the instance name is correct and that SQL Server is configured to
allow remote connections. (provider: SQL Network Interfaces, error: 50
- Local Database Runtime error occurred. The specified LocalDB instance does not exist.
This is frustrating because both the msi installer custom action and the Windows Service are running under the same Windows user account (I checked, they're both NT AUTHORITY\System). So why the first works and the second does not is beyond me.
I have tried changing the connection strings used in the custom action and the Windows Service to use the share name (localdb)\.\MYINSTANCESHARE and I get the exact same error from the Windows Service.
I have tried changing the user account that the Windows Service logs on as to my Windows user account, which does work as long as I first run a command to add it to the SQL server logins for that instance.
I've also tried running a console application and connecting to the share name connection string and that works as well.
I've also tried connecting to the share name from SQL Server Management Studio and that works as well.
However none of these methods really solve my problem. I need a Windows Service because it starts up as soon as the computer starts up (even if no user logs on) and starts up no matter which user account is logged in.
How does a Windows Service connect to a LocalDB private instance?
I am using SQL Server 2014 Express LocalDB.
Picking up from the comments on the question, here are some areas to look at. Some of these have already been answered in those comments, but I am documenting here for others in case the info might be helpful.
Check here for a great source of info on SQL Server Express LocalDB:
SQL Server 2014 Express LocalDB
SqlClient Support for LocalDB
SqlLocalDB Utlity
Introducing LocalDB, an improved SQL Express (also look at the Q&A section at the end of the main post, just before the comments, as someone asked if LocalDB can be launched from a service, and the answer is:
LocalDB can be launched from a service, as long as the profile is loaded for the service account.
What version of .Net is being used? Here it is 4.5.1 (good) but earlier versions could not handle the preferred connection string (i.e. #"(localdb)\InstanceName"). The following quote is taken from the link noted above:
If your application uses a version of .NET before 4.0.2 you must connect directly to the named pipe of the LocalDB.
And according to the MSDN page for SqlConnection.ConnectionString:
Beginning in .NET Framework 4.5, you can also connect to a LocalDB database as follows:
server=(localdb)\\myInstance
Paths:
Instances: C:\Users{Windows Login}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
Databases:
Created via SSMS or direct connection: C:\Users{Windows Login}\Documents or C:\Users{Windows Login}
Created via Visual Studio: C:\Users{Windows Login}\AppData\Local\Microsoft\VisualStudio\SSDT
Initial Problem
Symptoms:
Database files (.mdf and .ldf) created in the expected location:
C:\Windows\System32\config\systemprofile
Instance files created in an unexpected location:
C:\Users\{current user}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
Cause (note taken from "SqlLocalDB Utility" MSDN page that is linked above; emphasis mine):
Operations other than start can only be performed on an instance belonging to currently logged in user.
Things to try:
Connection string that specifies the database (though maybe a long-shot if the error is regarding not being able to connect to the instance):
"Server=(LocalDB)\MYINSTANCE; Integrated Security=true ;AttachDbFileName=C:\Windows\System32\config\systemprofile\TestDB.mdf"
"Server=(LocalDB)\.\MYINSTANCESHARE; Integrated Security=true ;AttachDbFileName=C:\Windows\System32\config\systemprofile\TestDB.mdf"
Is the service running? Run the following from a Command Prompt:
TASKLIST /FI "IMAGENAME eq sqlservr.exe"
It should probably be listed under "Console" for the "Session Name" column
Run the following from a Command Prompt:
sqllocaldb.exe info MYINSTANCE
And verify that the value for "Owner" is correct. Is the value for "Shared name" what it should be? If not, the documentation states:
Only an administrator on the computer can create a shared instance of LocalDB
As part of the setup, add the NT AUTHORITY\System account as a Login to the system, which is required if this account is not showing as the "Owner" of the instance:
CREATE LOGIN [NT AUTHORITY\System] FROM WINDOWS;
ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT AUTHORITY\System];
Check the following file for clues / details:
C:\Users{Windows Login}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MYINSTANCE\error.log
In the end you might need to create an actual account to create and own the Instance and Database, as well as run your service. LocalDB really is meant to be user-mode, and is there any downside to having your service have its own login? And you probably wouldn't need to share the instance at that point.
And in fact, as noted by Microsoft on the SQL Server YYYY Express LocalDB MSDN page:
An instance of LocalDB owned by the built-in accounts such as NT AUTHORITY\SYSTEM can have manageability issues due to windows file system redirection; Instead use a normal windows account as the owner.
UPDATE (2015-08-21)
Based on feedback from the O.P. that using a regular User account can be problematic in certain environments, AND keeping in mind the original issue of the LocalDB instance being created in the %LOCALAPPDATA% folder for the user running the installer (and not the %LOCALAPPDATA% folder for NT AUTHORITY\System ), I found a solution that seems to keep with the intent of easy installation (no user to create) and should not require needing extra code to load the SYSTEM profile.
Try using one of the two built-in accounts that is not the LocalSystem account (which does not maintain its own registry info. Use either:
NT AUTHORITY\LocalService
NT AUTHORITY\NetworkService
Both have their profile folders in: C:\Windows\ServiceProfiles
While I have not been able to test via an installer, I did test a service logging on as NT AUTHORITY\NetworkService by setting my SQL Server Express 2014 instance to log on as this account, and restarted the SQL Server service. I then ran the following:
EXEC xp_cmdshell 'sqllocaldb c MyTestInstance -s';
and it created the instance in: C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
I then ran the following:
EXEC xp_cmdshell N'SQLCMD -S (localdb)\MyTestInstance -E -Q "CREATE DATABASE [MyTestDB];"';
and it had created the database in: C:\Windows\ServiceProfiles\NetworkService
I was able to solve similar issue in our WiX installer recently. We have a Windows service, running under SYSTEM account, and an installer, where LocalDB-based storage is one of the options for database configuration. For some time (a couple of years actually) product upgrades and service worked quite fine, with no issues related to LocalDB. We are using default v11.0 instance, which is created in SYSTEM profile in C:\Windows\System32\config tree, and a database specified via AttachDbFileName, created in ALLUSERSPROFILE tree. DB provider is configured to use Windows authentication. We also have a custom action in installer, scheduled as deferred/non-impersonate, which runs DB schema updates.
All this worked fine until recently. After another bunch of DB updates, our new release started to fail after having upgraded over the former - service was unable to start, reporting infamous "A network-related or instance-specific error occurred while establishing a connection to SQL Server" (error 50) fault.
When investigating this issue, it became apparent that the problem is in a way WiX runs custom actions. Although non-impersonated CA-s run under SYSTEM account, the registry profile and environment remain that of current user (I suspect WiX loads these voluntary when attaching to user's session). This leads to incorrect path being expanded from the LOCALAPPDATA variable - the service receives SYSTEM profile one, but the schema update CA works with the user's one.
So here are two possible solutions. The first one is simple, but too intrusive to user's system - with cmd.exe started via psexec, recreate broken instance under the SYSTEM account. This was not an option for us as the user may have other databases created in v11.0 instance, which is public. The second option assumed lots of refactoring, but wouldn't hurt anything. Here is what to do to run DB schema updates properly with LocalDB in WiX CA:
Configure your CA as deferred/non-impersonate (should run under SYSTEM account);
Fix environment to point to SYSTEM profile paths:
var systemRoot = Environment.GetEnvironmentVariable("SystemRoot");
Environment.SetEnvironmentVariable("USERPROFILE", String.Format(#"{0}\System32\config\systemprofile", systemRoot));
Environment.SetEnvironmentVariable("APPDATA", String.Format(#"{0}\System32\config\systemprofile\AppData\Roaming", systemRoot));
Environment.SetEnvironmentVariable("LOCALAPPDATA", String.Format(#"{0}\System32\config\systemprofile\AppData\Local", systemRoot));
Environment.SetEnvironmentVariable("HOMEPATH", String.Empty);
Environment.SetEnvironmentVariable("USERNAME", Environment.UserName);
Load SYSTEM account profile. I used LogonUser/LoadUserProfile native API methods, as following:
[DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool LogonUser(
string lpszUserName,
string lpszDomain,
string lpszPassword,
int dwLogonType,
int dwLogonProvider,
ref IntPtr phToken);
[StructLayout(LayoutKind.Sequential)]
struct PROFILEINFO
{
public int dwSize;
public int dwFlags;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpUserName;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpProfilePath;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpDefaultPath;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpServerName;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpPolicyPath;
public IntPtr hProfile;
}
[DllImport("userenv.dll", SetLastError = true, CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool LoadUserProfile(IntPtr hToken, ref PROFILEINFO lpProfileInfo);
var hToken = IntPtr.Zero;
var hProfile = IntPtr.Zero;
bool result = LogonUser("SYSTEM", "NT AUTHORITY", String.Empty, 3 /* LOGON32_LOGON_SERVICE */, 0 /* LOGON32_PROVIDER_DEFAULT */, ref token);
if (result)
{
var profileInfo = new PROFILEINFO();
profileInfo.dwSize = Marshal.SizeOf(profileInfo);
profileInfo.lpUserName = #"NT AUTHORITY\SYSTEM";
if (LoadUserProfile(token, ref profileInfo))
hProfile = profileInfo.hProfile;
}
Wrap this in an IDisposable class, and use with a using statement to build a context.
The most important - refactor your code to perform necessary DB updates in a child process. This could be a simple exe-wrapper over your installer DLL, or stand-alone utility, if your already have one.
P.S. All these difficulties could be avoided, if only Microsoft let uses choose where to create LocalDB instances, via command line option. Like Postgres' initdb/pg_ctl utilities have, for example.
I suggest using a different user account, and not using the System account, by doing the following:-
create a new account on the machine, and set that to be the account
under which the Windows Service runs. It's not good practice to use
the system account just to run an application, anyway, as the
permissions are excessive.
ensure that the permissions on the LocalDB files are set to allow the said user account to access the database (and thus continue to
use Integrated Security)
make sure it works by trying to connect to the DB (once installed) under the same user account by running sqlcmd or Management Studio
under the context of the said user, then connecting with Integrated
Security to ensure it works.
Some other things to try/consider:
have you checked the Windows Event log for any events that might be useful for diagnostic purposes?
Make sure that if you have any other versions of SQL Server (especially prior to 2012) that for the command-line tools, the %PATH% isn't set to find an older tools version first. Older tools don't support LocalDB.
It is possible also (as an alternative) to set up LocalDB to be shared with other users. This involves sharing the instance, and then granting access to other users. See the "Sharing Issues" section in this article: Troubleshoot SQL Server 2012 Express LocalDB.
There's also another SO article that may contain some more useful information there in the links within (change the language in the URL from Polish to English by changing pl-pl to en-us). His work-around is using SQL Server accounts, which might not be OK in your case.
This might also be useful, as it relates to security permissions being denied, and possible resolutions: https://dba.stackexchange.com/questions/30383/cannot-start-sqllocaldb-instance-with-my-windows-account
Trevor, the problem you have is with the MSI custom actions. You must configure them with "Impersonate=false" otherwise the custom actions will be executed under the current user context.
BTW what tool are you using to create the installer?
Depending on the tool you use, could you please provide screenshots or code snippets of your custom actions configuration?
The accepted answer from this post will give you some additional information about the different custom action execution alternatives:
Run ExeCommand in customAction as Administrator mode in Wix Installer
You will find additional information about impersonation here:
http://blogs.msdn.com/b/rflaming/archive/2006/09/23/768248.aspx
I wouldn't create the database under the system's localdb instance. I'd create it under the current user installing the product. This will make life much easier if you need to delete or manage the database. They can do this through sql management studio. Otherwise, you'll have to use psexc or something else to launch a process under the SYSTEM account to manage it.
Once the db is created, then use the share option you mentioned. The SYSTEM account can then access the database through the share name.
sqllocaldb share MSSqlLocalDb LOCAL_DB
When sharing, I've noticed you'll have to restart the the local db instance to actually access the db through the share name:
sqllocaldb stop MSSQLLocalDB
sqllocaldb start MSSQLLocalDB
Also, You may need to add the SYSTEM account as a db reader and writer to the database ...
EXEC sp_addrolemember db_datareader, 'NT AUTHORITY\SYSTEM'
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.
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.
Is there a way in SQL Server Management Studio 2005 (or later) to change the Windows Authentication user (as you could in SQL Server 2000 and older)?
This is the general connection properties dialog(note the greyed out UID/PWD when selecting Windows Auth):
FYI - One workaround is to use runas but I'm looking for a solution that will allow me to work with multiple Windows accounts across multiple servers (and across multiple domains).
While there's no way to connect to multiple servers as different users in a single instance of SSMS, what you're looking for is the following RUNAS syntax:
runas /netonly /user:domain\username program.exe
When you use the "/netonly" switch, you can log in using remote credentials on a domain that you're not currently a member of, even if there's no trust set up. It just tells runas that the credentials will be used for accessing remote resources - the application interacts with the local computer as the currently logged-in user, and interacts with remote computers as the user whose credentials you've given.
You'd still have to run multiple instances of SSMS, but at least you could connect as different windows users in each one.
For example: runas /netonly /user:domain\username ssms.exe
Hold shift and right click on SQL Server Mangement studion icon. You can Run as other windows account user.
One other way that I discovered is to go to "Start" > "Control Panel" > "Stored Usernames and passwords" (Administrative Tools > Credential Manager in Windows 7) and add the domain account that you would use with the "runas" command.
Then, in SQL Management Studio 2005, just select the "Windows Authentication" and input the server you wanna connect to (even though the user that you can see greyed out is still the local user)... and it works!
Don't ask me why ! :)
Edit:
Make sure to include ":1433" after the server name in Credential Manager or it may not connect due to not trusting the domain.
None of these answers did what I needed:
Login to a remote server using a different domain account than I was logged into on my local machine, and it's a client's domain across a vpn. I don't want to be on their domain!
Instead, on the connect to server dialog, select "Windows Authentication", click the Options button, and then on the Additional Connection Parameters tab, enter
user id=domain\user;password=password
SSMS won't remember, but it will connect with that account.
The runas /netonly /user:domain\username program.exe command only worked for me on Windows 10
saving it as a batch file
running it as an administrator,
when running the command batch as regular user I got the wrong password issue mentioned by some users on previous comments.
For Windows 10:
Go to the Sql Management Studio Icon, or Short Cut in the menu:
Right Click > Select Open File Location
Hold Shift and right Click the shortcut, or ssms.exe file that is in the folder. Holding shift will give you an extra option "Run as different user":
This will pop up a login box and you can type the credentials you would like your session to run under.
A bit of powershell magic will do the trick:
cmdkey /add:"SERVER:1433" /user:"DOMAIN\USERNAME" /pass:"PASSWORD"
Then just select windows authentication
There are many places where someone might want to deploy this kind of scenario, but due to the way integrated authentication works, it is not possible.
As gbn mentioned, integrated authentication uses a special token that corresponds to your Windows identity. There are coding practices called "impersonation" (probably used by the Run As... command) that allow you to effectively perform an activity as another Windows user, but there is not really a way to arbitrarily act as a different user (à la Linux) in Windows applications aside from that.
If you really need to administer multiple servers across several domains, you might consider one of the following:
Set up Domain Trust between your domains so that your account can access computers in the trusting domain
Configure a SQL user (using mixed authentication) across all the servers you need to administer so that you can log in that way; obviously, this might introduce some security issues and create a maintenance nightmare if you have to change all the passwords at some point.
Hopefully this helps!
Did anybody tried "plain" runas without parameters? Those /netonly /savcecred all of them sound ambiguous and to me utter nonsense.
C:\Windows\System32\runas.exe /user:DOMAINX\OtherUser02 "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\ssms.exe"
This works just fine. No matter what, runas WILL ask you for the user password. Just type it and be security audit compliant.
The only way to achieve what you want is opening several instances of SSMS by right clicking on shortcut and using the 'Run-as' feature.