I use SQL Server Management Studio to manage my SQL Server. I need to add a genericReadOnly and genericReadWrite to use when accessing it from automated vba code in Excel. The file that contains this code will be distributed to a number of people, more than I want to individually add to the server.
I've tried adding this generic user account, but get told
genericReadOnly is not a valid login or you do not have permissions.
The server admin believes that a username has to exist in Active Directory.
Is this standard, or is it a sitting that can be changed, if so how?
If you are using mixed authentication on your SQL Server, you can create a SQL Server login (via the security\logins tree on SSMS object explorer) and then a user on your database.
If you are using windows authentication only, then yes, you need an Windows login account mapped to that user.
To change the authentication mode... http://msdn.microsoft.com/en-us/library/ms188670.aspx
Related
SQL Server 2016 reporting. The SSRS service runs as an account that has read access in the database I'd like to run reports from.
I'd like to create a server level data source object that would use the Windows service account to connect, instead of storing the credentials in the data source itself. Is there a way to do so?
The "Without any credentials" option doesn't work, I've tried.
I Just Completed My Window Application,In Which I Use SQL Server 2008 as Back-End.
I Install My App With Database In Client Machine.
But Problem Is That My Client Can Also See My Database Using Sql Server Mangement Studio.
I Want to Prevent Client To See Database.
How can i do this?
That's the entire purpose of a database server. For any authenticated client to be able to connect to the server. That client may be your application or any other application - Management Studio being one of them.
You can either host your database server anywhere else and set up SQL server to only accept connections from your web application's server. But anyone that knows the IP, instance, and has the proper credentials can connect anyway from that server.
Or you can set up a user on SQL server for your application and configure your application to use that user. Now only the database administrator and that user can access that database.
But anyone that browses your application's configuration files will be able to pull the credentials anyway from there. Unless you are using integrated security, in which case the user your application runs under will be the only one to have access - assuming you grant that Windows user access to the database of course.
I guess the real question is, why are you trying to prevent someone from directly accessing the database?
I am normally a .NET developer so have no experience with classic ASP.
I have been asked by a client to have a look at their classic ASP site. I am trying to recreate their site on my local machine so can have a play with but am having difficulty connecting to my copy of the database. The database has been recreated on SQL Server 2008 using windows authentication and I'm having difficulty with the connection string.
This is what I have so far:
Provider=SQLOLEDB;Data Source=MY-PC\SQLExpress;Initial Catalog=testdb;Integrated Security=SSPI;Persist Security Info=False;
Keeps saying
login failed.
Any ideas?
Modify the anonymous user account details that your local site uses to your own logon account.
The problem is that ASP scripts always run using impersonation either of the user associated with an authenticated connection or as the anonymous user account. The anonymous user is normally the rescricted IUSR account.
You could just turn off anonymous access and turn on Windows Integrated but I find its best for local development purposes to just change the anonymous user.
You need to create a login/user in SQL Server for the identity of the app pool in which your application is running.
I have old classic ASP application (not asp.net) that I need to configure to use Microsoft SQL Server 2008.
It works well with following config string:
SERVER=myServer;DRIVER=SQL SERVER;DATABASE=myDatabase;UID=sa;PWD=somepass
But I need to use integrated security. But got error in any types of declaration that I tried. Something like that and a lot of variations don't work:
SERVER=myServer;DRIVER=SQL SERVER;DATABASE=myDatabase;Integrated Security=SSPI;
So my question is: how connection string should look like for Classic ASP integrated security. Or maybe additional web server configuration is needed?
Note that this will hit SQL based on the authentication of your asp application pool assuming your using anonymous authentication.
I see you have added a comment noting IIS 5, setting a site to use windows auth on ISS5 is possible by going to the properties of your site, selecting the "Directory Security" tab, then clicking the "Edit" button on the "Anonymous access and authentication control" section. Disable anonymous authentication and tick the "Integrated Windows Security" option.
(NOTE: the webserver will need to be able to authenticate the credentials, so you may run into NTLM and kerberos issues depending on your domain configuration - tread carefully!)
This should execute the asp files as the authenticated user, in which case your connection strings would then be able to use trusted connections.
You have a few choices here depending on which providers you have available to you.
For instance, with the SQL Native Client 9.0 OLE DB provider you could use:
Provider=SQLNCLI;Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;
Native Client 10 is slightly different:
Provider=SQLNCLI10;Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;
I prefer the SQLOLEDB provider (ive had trouble with SQL SERVER driver and VARCHAR(MAX) in the past):
Provider=SQLOLEDB;Data Source=Your_Server_Name;Initial Catalog=myDataBase;Integrated Security=SSPI;
NOTE: suddenly changing the authentication may break other stuff - i'd certainly just recommend adding a SQL credential on the SQL server and use that in your connection strings instead.
Its a pity you haven't replied to my inquiry in a comment to your question so I will have to give a wider answer. (Although HeavenCore has actually given you the correct connection string to use, the SQLOLEDB one).
When using anonymous access
When you run a Classic ASP website under anonymous access the security token that the thread executing the acript belongs to the IIS anonymous user. This user by default on IIS5.1 is a local machine user. As a result unless the SQL server is also running on the same box you can't use this user to grant access to a SQL Server.
You would need to create a new user in your domain to act as the anonymous account. Then you would change the anonymous user for your application to this new account. In SQL server you can then grant appropriate database access to this account.
If I recall correctly you can set the anonymous user account by opening the site properties. In the Directory Security tab, click Edit.. under Authentication and access control. In the authentication methods dialog that appears you can change the anonymous account to one that is a member of the domain.
When using windows integrated access
If you running classic ASP without anonymous access but instead are authenticating connections using window integrated security then each script will run using the security token of the authenticated user. Hence when SSPI is used in the SQL connection the user associated with the connection the request has arrived on is used.
To give these users access the SQL DB you would need to create appropriate AD Group(s) and grant these Group(s) access to the DB. Then assign the users to these Group(s).
The downside to this approach is that it gets limited benefit from connection caching however considering the rest of your configuration that may not be too much of a concern.
I have an odd scenario.
I inherited a box that has SQL Server 2008 R2 on it already. The previous user connected to the (local) database with Windows Authentication using their Windows login.
I have a different Windows login. Is there any way for me to be able to log into the (local) database? The old user is no longer around, I don't know their password.
The easiest way is to get the other users password changed, and then login as that person, although this is only appropriate if you're connecting to a domain, using Active Directory etc.
Alternatively, if you are in the local administrators group, or can get yourself added to it, it's quite likely you can connect to the SQL Server instance as yourself with admin rights.
Finally... if you just want access to a particular database, copy the mdf and ldf files, and re-attach them to another instance.