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.
Related
Does anyone know how access a Access 2013 web app deployed on SharePoint via Azure? I have built an app and the db gets deployed into SQL Azure. I want to have full access to it via Azure. Is it possible?
After you publish the Access web application, then in the Access client you MUST enable external use. When you enable external use then a user name + password is generated for you. You can then view these values by again view the connections in Access.
These connection strings can be used in Excel, the sql management studio, or even a regular non web Access database. In fact such connection strings should work even for a web site and .net.
So just about anything can connect to these SQL Auzre tables, and the "enabling" of the connections is done from the Access client.
The connection opens are found via
File->and then click on mange connections. You see these options:
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 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
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 few ssrs 2008 reports.I have created group of users and gave all required permissions to that group.
Now when I am running those reports I am getting strange error.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
I don't know from where it came.
I got suggestion that its a issue related to Kerberos authentication. Please some one knows how to solve this let me know.
Or some one knows to solve this kerberos issue also tell me in steps if possible.
Thanks
Vik
Are your reports using pass-through integrated authentication, defined user integrated authentication, or sql user authentication? I suspect the first, in which case you're dealing with the difference between impersonation and delegation.
When connecting to a web server using integrated authentication, behind the scenes you are actually using NTLM or Kerberos. Both allow the process running your web server to act as you. NTLM's impersonation via security token prevents the server from connecting to yet another server as you (that is, to the DB server) and there acting as you again—this is the "double-hop" problem. Kerberos instead uses delegation, passing a ticket around that each server can check for validity and allow.
To get Kerberos working there are several requirements.
If you're connecting to the web server using a name other than its main DNS name (using as an alias) you have to register the alias as valid for the machine with SetSPN. You can have problems with the SPN (Service Principal Name) even without this. Check the SPN on your servers carefully to see if it matches what you expect.
The server you initially connect to must be "trusted for delegation" in your domain policy.
The user that your web server is running under must be "trusted for delegation" as well.
You can work around all this stuff by just making your reports have stored credentials of some sort rather than using pass-through authentication.
The difference between dev and test could be the IIS user, or the data source.
Now, I am assuming here that you're not using SharePoint and are just doing a normal SSRS web install. So if that is not correct please say so.