I have couple of reports that I developed and are sitting on http//localhost/reports.
I have everything else set up, including Sql Server 2005 Config Tools. The reports run fine when I run them on my own machine, where IIS and Sql Server 2005 are both loaded. But they don't work when I try from other computers. I have the dir security to windows integrated security checked.
The error i get is -
An error has occurred during report processing. Cannot create a
connection to data source 'time_clock'. Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
How do I make them available for remote users?
Is the reportserver and SQL server on the same box? If SSRS is on a different box and MSSQL is on your box, then you have to configure Kerberos for double hop authentication.
Check this link for help on configuring double hop authentcation.
Raj
SSRS machine authenticates the remote user, it impersonates him and it then tries to authenticate to the SQL machine. The SQL machine needs a proof that SSRS is who it claims it is (the remote user), but SSRS does not have the said proof (namely the password of the remote user), therefore authentication falls back to the anonymous logon.
To enable this scenario you need to enable and configure constrained delegation on the account running the SSRS. If constrained delegation is enabled and properly configured then the domain controller will vouch for the SSRS machine impersonated identity of the remote user and the SQL machine will authenticate it successfully.
In addition to turning Windows Authentication on, you need to turn Anonymous authentication off.
Related
The authentication mode is "Mixed" for my SQL Server 2016.
I'm using SSMS to run cross-server queries.
I've checked the user account & have ensured that the account has proper authority. I can use a different account and run cross-server queries as expected. The account has proper authority to the databases in question and it has authority to them. I've tried everything I've seen on the internet searches I've done and no luck. The account can login using SSMS.
My linked server properties are:
The account's login properties are:
Has anyone else seen this & have a resolution?
** EDIT: rebooting the target server fixed the issue
When creating a linked server you choose the authentication mechanism by which the remote connection will be made. If you select the fourth option (pictured), the remote login must be a Sql Server authenticated login. It cannot be a windows login.
The only way to connect through a linked server using windows authentication is to forward the credentials of the login on the local server. There is no option to specify a windows username and password.
Indeed, there is no way, ever, to specify a password when connecting to a Sql Server with windows credentials, since the whole point of windows credentials is that you're already authenticated. That happened when you logged in to windows in the morning*
You can only (and must always) specify a password if you are using Sql Server authentication.
What seems to be going on in your case is that the linked server may have been created with the wrong security options. This is just easier to explain with an image:
* More precisely, a connection will be made using the account that the client is running under. If you start SSMS using a "runas /user ..." command, then the windows credentials used to connect to servers will be the credentials specified in runas
I have an IIS 7.0 server connecting to an SQL 2012 Database. On the SQL database I have added a number of linked servers and created a distributed partitioned view to consolidate data from the multiple linked servers. I have a common Windows account on the main server and the linked servers that is common to all (same password). Querying this view from SSMS on the SQL server works fine logged in as the common user. The application pool I am using uses this same user (also on the IIS server) to connect to the SQL server using Integrated Security. I have a simple query of SELECT SYSTEM_USER when run from IIS reports the common user. When trying to retrieve the data from the linked server view I get Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. instead of the data in the view.
Help appreciated
This is basically what is happening: If you are running Active Directory, this is the famous "double-hop" problem. Double-hop is a term used to describe Microsoft's method of maintaining Kerberos authentication credentials over two or more connections. You must configure Kerberos delegation on the AD account running the application pool so that it can forward credentials to the SQL 2012 database server. You configure this on the Delegation tab of the AD account. Without Kerberos delegation, the AD credentials are not forwarded and instead local credentials are sent by the IIS server and get denied by the SQL server. Since the SQL Server doesn't understand the local credentials of the IIS 7 server it denies it as an anonymous logon attempt. The link I provided describes the resolution to this problem in full detail and explains how to expand it out to other servers. Note that if you are not using Active Directory and only local authentication then NTLM is being used and NTLM credentials cannot be delegated off the system so authentication to the SQL server will be in the form of anonymous authentication.
I have one web server & one DB server (running SQL SERVER 2008). Both the servers are in different domains. The web server is allowed to communicate(the communication takes place internally without the intervention of firewall) directly with the DB server, it is given Admin privileges & the DB access through SQL is going on without any problems.But whenever the web server tries to access the Reporting Server & its services, its asking for a separate authentication(Local system account authentication has been configured for SQL Server). I want to know whether is there any way to get rid of this separate authentication for Reporting Services
If you are being prompted for credentials when running a report, then your data source is configured to prompt at run time. You'll need to change the DS to use a SQL login if you don't want this to happen. Your windows credentials cannot be passed from one server to another.
If you are being prompted to log on to the RS site - I've only experienced that on firefox but fixed with a firefox config setting to save the cred for the domain.
MSSQL Server is in the "abc" domain and have mixed mode authentication.
I am connecting from the machine which is not in domain or in a domain "xyz" but with in the same network using MSSQL Jdbc driver 2.0. I have logged in as admin or account in xyz domain.
It works fine using following url for connection for "sa" or SQL Mode Authentication.
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;DatabaseName=dbname
It doesn't work For window authentication using credential "MSSQLDomain\username" i.e "abc\username", using following url
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;integratedSecurity=true;DatabaseName=dbname;
Gives following error.
Login failed for user ''. The user is not associated with a trusted
SQL Server connection.
I have tried adding property Trusted_Connection=Yes to url, but still gives same error.
I don't want to map the drive of the SQL Server. I am able to access the any shared folder of the SQL Server Machine by providing "MSSQLDomain\username" and password.
It works fine for both authentication mode, if both machine is in same domain.
If I am using jtDS Driver from the machine which is not in domain or in "xyz" domain within same network i.e same subnet, it works fine.
This is the deliberate and correct behaviour of Windows Authentication.
It is because the Domain from which you are connecting from, is not the same Windows Domain as the one where your SQL Server instance resides.
I believe there are methods for bridging the Domains so to speak, however they require custom and tricky implementation. You also will have to configure a trust relationship between the domains.
The following thread contains discussions which you will likely find useful.
http://sql-server-performance.com/Community/forums/p/24601/137574.aspx
Changing the login credentials might help,
use SQL authentication instead of nt authentication
https://support.microsoft.com/en-us/kb/555332
Symptoms
After you install Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005, or SQL Server 2000 and you try to connect to the server that is running SQL Server, you receive one of the following error messages:
Login failed for user '%.*ls'. The login is a SQL Server login and cannot be used with Windows Authentication.%.*ls
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Login failed for user ''. (Microsoft SQL Server, Error: 18456)
Resolution
This problem occurs if the user tries to log in with credentials that cannot be validated. This problem can occur in the following scenarios:
Scenario 1:
The login may be a SQL Server login but the server only accepts Windows Authentication
To resolve this issue, configure SQL Server in Mixed Authentication Mode.
Scenario 2:
You are trying to connect by using SQL Server Authentication but the login used does not exist on SQL Server
To resolve this issue, verify that the SQL Server login exists. For more information, see Create a login in SQL Server Books Online.
Scenario 3:
The login may use Windows Authentication but the login is an unrecognized Windows principal
An unrecognized Windows principal means that Windows can't verify the login. This might be because the Windows login is from an untrusted domain. To resolve this issue, verify that you are logged in to the correct domain.
I have been involved with making a SQL server connection cross to domains like that, and it is exceptionally painful. In order to use credentials from another domain, the domain where you are assigning the permissions has to trust the domain, where the account is coming from. IT Pro's are generally VERY reluctant to trust another domain in this manner, and for good reason, so if this trust relationship has not been established it might not be very likely to convince the admins to do this.
Once you have the trust relationship established, you will probably need to register the SPN's for your SQL server in Active Directory, and assign delegation permissions. This type of environment is very difficult to setup, troubleshoot and maintain.
I hope that there is some other way that you can do this, because it sounds like you are headed for a very difficult scenario.
Hope it helps
Rihan
Ever since moving to Vista some time ago on my development machine, connecting to SQL Servers in our DMZ active directory domain from client tools like SSMS has not worked like it used to. In XP, as long as I had authenticated in some way on the server (for example directing Explorer to \server.dmzdomain\c$ and entering valid creds into the login prompt), SSMS would use those cached credentials to connect.
However since switching to Vista, when trying to connect SSMS to a server in the DMZ domain I get the message Login failed for user ''. The user is not associated with a trusted SQL Server connection. If I change the connection options to use Named Pipes instead of the default TCP/IP, my cached credentials are sent and everything works fine. This is the case whether Windows Firewall is off or on, and connections to servers in our internal domain (the same domain my dev PC is in) work fine over TCP/IP or named pipes.
I don't mind too much using named pipes for these connections as a workaround, but it seems like TCP/IP is the recommended connection method and I don't like not understanding why it's not working as I'd expect. Any ideas?
"Login Failed for user ' ', the user is not associated with a trusted SQL Server connection".
In this scenario, client may make tcp connetion, plus, running under local admin or non-admin machine account, no matter SPN is registered or not, the client credential is obviously not recognized by SQL Server.
The workaround here is:
Create the same account as the one on the client machine with same password on the target SQL Server machine, and grant appropriate permission to the account.
Let's explain in more detail:
When you create the same NT account (let's call it usr1) on both
workstations, you essentially connect and impersonate the local account of
the connecting station. I.e when you connect from station1 to station2,
you're being authenticated via the station2's account. So, if you set the
startup account for SQL Server (let's assume it's running on station2) to be
station2's usr1, when you connect to SQL from station1 with station1's usr1
login, SQL will authenticate you as station2's usr1.
Now, within SQL, you can definitely access station1's resources. Though, how
much access will depend on station1's usr1 permission.
So far, SQL only deal with an user who is part of the sysadmin role within
SQL Server. To allow other users (non-sysamdin) access to network resources,
you will have to set the proxy account. Take a look at the article for
additional info.
taken from http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
Have you tried running SSMS in elevated mode, and do you have the latest SP installed on the client?
I would assume that this is because Vista runs most applications in isolation from either other.
I would recommend that you either set the DMZ username and password to match the internal domain username and password, or use named pipes to connect.