I have an application built in Access 2003 that uses a system DSN ODBC to connect to a SQL Server. The ODBC uses SQL authentication. When the application is started, the user is prompted to authenticate into the database.
I have another computer set up within the same domain that has Access 2007 installed on it. I log in using the same credentials that I use to get on the machine that has Access 2003.
I converted my application to Access 2007 format and everything works fine. However, when other users try to use the application, they are prompted to enter the database password every time a table is accessed. Thinking it was a problem with my ODBC, I confirmed that the connections were set up the same way on both of my machines, and the user's machine.
Here is the interesting part, when the user logged into my machine, it started prompting for the password every time. When I logged into the user's machine, the application worked fine.
Anyone have any ideas? All help is appreciated!
Be sure to use a System DSN, not a User DSN. It's easy to create the wrong one since the tabs are side by side.
Make sure that the System DSN has SQL Server authentication picked and you have the login id and password set.
A User DSN is only visible to the user that creates it. A System DSN is available to all users and Windows services.
Related
I have an Access DB that I migrated to SQL server recently. The SQL server is on a Windows server. Now I can work normally with the SQL database but when others log into the same windows server with their credentials they are not able to access the database. As soon as they open Access frontend they get an error saying failed connection. Now I created an ODBC connection string(File DNS) and gave it to the other users in the network but they still are not able to connect to the database. They get an error stating "SQL server connection failed. The server rejected the connection: Access to the selected database has been denied". Can someone please help me to solve this issue so that multiple users can connect to the SQL DB without any issues? Thanks
Hard to know with the limited information. Are you using windows authentication to sql server, or are you using SQL logons? Either should work fine. The other issue to watch out for is what sql driver did you use to link with?
If you link say using the native 17 ODBC driver, then that is not installed on workstations by default - you have to download and install that driver.
Or, maybe you linked using the long time "legacy" sql driver - that is by default installed on all workstations.
So, it not clear if you using SQL logons, or using Windows authentication for the connection to the database????
If your using windows authentication, then all those other users will require permissions to be granted to the database.
If you using a SQL logon, then that logon would have been saved when you link the table(s), and again it should work for all users. Its quite common to create ONE logon on SQL server, link using that logon, and thus all users will be connecting to the database using the one same logon id/password.
And, if you linked using a FILE dsn, then zero configeration should be required, since access converts FILE dsn's into what are called dsn-less connections. (the origonal file is not required anymore once you link - you can even delete that FILE dsn, and it will still work).
So, FILE dsn is the best choice, since that dsn is NOT required to be setup on each workstation.
And if you using sql logon's, then make sure you checked the box to remember the password during linking of the tables. That is this check box:
And note during a re-link the above box does not appear - only on first time linking of table(s).
I am using SSMS to interact with a database I have locally on my PC. I also have a software to create reports about data in the database, but first of all I have to connect the software to the SQL Server database.
I'm logging into the database using Windows authentication (credentials WindowsDomain\username) which is my PC name and Windows username. At the beginning I didn't set a password and it connected successfully.
But to connect the software to the database, I have to fill in different fields such as Host Name, Port Number, Database Name, User, Password. I can't leave empty the Password field even if I don't have one, so I need to set a password for my Windows username : OK easy, I just have to set the password account in the Control Panel..
I restart my PC and check if I need to fill the password, now, in SQL Server.. But it still connects without any password, the software does not connect the database with that password, and in SQL Server I can't solve it with a query (alter login on my username), error :
Cannot use parameter PASSWORD for a Windows login.
How can I set a password for this user name ? Or maybe to create a new one with SQL Server authentication or Windows authentication, it's the same for me...
If you are trying to use password with Windows Authenticationthat is not a correct way and also imposible because Windows AuthenticationLogin is different from SQL Login.
In Windows Authentication you don't have a password because Windows tells SQL that I trust this user(who is loged in on this computer) so you can trust him
I'm looking at using SQL LocalDB as the client side database which will replace the current SQL CE 3.5 database inside an in-house application developed in .net 4.
I've come across a problem that I'm not sure how to get around and that's with security setup of the LocalDB instance.
If I setup a script inside .net to create a private LocalDB instance, e.g. (localdb)\T1, then create a new database inside that instance plus add a SQL user account + password (non domain account), how do I stop the local windows users (like my own AD account) with admin level privileges from accessing the 'T1' instance + database using SSMS?
I could see a scenario playing out where we deploy the application, then we have some IT savvy user who goes snooping around and decides to install SSMS and connect to (localdb)\T1 with their windows account, which would give him/her full access to the database, which is exactly what I'm trying to stop from happening.
Some of our staff work remotely with no connection to a domain so we give them local admin rights to their pc so they can install software, so even if I could block their assigned windows login name, there would be nothing stopping them from setting up a new local admin account and logging in with that, opening SSMS then accessing the database.
Any pointers on this would be greatly appreciated!
In fact, it shouldn't be so hard. Install SQL Server on client machine using local admin account. To make you life easier, use Mixed Authentication.
After you have your instance installed, local admin account should have sysadmin server role assigned (that's normal security settings). Now, use the following:
Create new SQL Server user and assign sysadmin server role to that account. Close SSMS and log-in using new credentials. Or simply use sa account (not so good practice but in this case it's OK).
Go to "Security - Logins" and remove sysadmin role from local admin. Also, check in user mappings and take all rights "away" from local admin.
As a test, try to log-in as local admin, I guess you won't be able to log-in into server because there is no "home" database for that user. But even if you can log-in, it has only "public" role.
It's up to you to install your database and secure it - assign permission to user of your choice.
Regarding you fear that local admin can install MSSQL again: he/she can install it, but it would be another instance. That instance knows nothing about users in your instance so you should be safe.
You can also consider usage of application roles in SQL server.
I have a question relating to SQL Server management studio,
I have downloaded the SQL Server Express onto my PC and was told to expect SQL Server to prompt me for a username and password, which I could use to login as "SQL Server Authentication", and use the login and password function.
I followed every single instance of the Installation but was never propted about any such password and user name setting having to be created.
Big deal however I need to practice methods for loging into SQL Server using password and Username functionality ussing vb.net (Automating login procedures).
What are the steps I need to undertake to make correct this?
The Authentication Mode can be changed at any time. In Microsoft SQL Server Management Studio, right-click on your server, and go to properties.
In the Security page, you have the option to change the Server Authentication mode to Windows or Both (Windows and SQL).
Make sure the "sa" user has a strong password (it may be empty or disabled by default).
I brought my laptop home from work hoping I could get some tasks done over the weekend. Unfortunately, I couldn't login to SQL Server using Windows Authentication. I've checked the SQL Server Configuration Manager and the instance (MSSQLSERVER) is set to Log On As Local System, which supposedly means that I should be able to login fine using Windows Authentication... or am I missing something here? Note that in the login window, I tried a lot of different combinations and it always keeps telling me that connection failed because the server is not accessible or I'm not authorized to access it.
A little background about how the instance was installed: I installed and configured it myself. I chose the Mixed Authentication mode and gave a password to the default sa user (which isn't working either by the way). The thing I suspect could be the problem is the fact that I installed the SQL SERVER instance when I was logged in as my Domain User at work (DOMAIN\UserName). Now I'm at home and I do not have access to the LAN at the office, so I'm logged in as the {COMPUTERNAME}\Kassem user.
Any thoughts?
A windows account has to be added to SQL Server to have any rights. If you didn't add {COMPUTERNAME}\Kassem, you can't login to SQL Server.
The recovery option here is the SA password, which should always work.
To connect to the default instance, connect to localhost or .. Connecting to .\MSSQLSERVER won't work, even though MSSQLSERVER is the default instance name.